测试人社区

测试开发实战 | 如何拆解一个任务?

高效测试开发 | 如何拆解一个任务?

刘晓光 [霍格沃兹测试学院](javascript:void(0):wink: 3月26日

为了提升研发和测试效能,需要先明确一个目标:

把研发任务拆解为“可测试”的交付物

如何理解“可测试”?

首先,要摒弃“可以做端到端的测试才叫可测试”的观念。

  • 接口可以测试;
  • 方法/函数可以测试;
  • 业务需求逻辑可以测试;
  • 拆分后,尽量提供可端到端测试的测试物(这一点和上一点并不矛盾,因为早晚要做端到端的测试);

如何拆解?

  1. 做好排期。
  • 做好排期,是做好拆解的基础。
  • 双周的排期是一个非常合适的排期工作的周期。
  • 对自己团队的交付能力有比较清晰的认识(可以通过过去的迭代总结不断看清楚)
  • 所有干系人参与排期(项目经理,需求,开发,测试,运营),不然对不齐。
  • 留出一定的富余量。
  • 在排期会上,对排期内的任务进行分解,测试和开发人员均应该在场,对任务进行评估。
  1. 做好可测性分析。
  • 一定要达成一个“可测”的协议。
  1. 尽可能的按照业务功能去拆解,而不是按照技术层次去拆解。
  • 如果采用了"用户故事"的方法,按照用户故事去拆分
  • 最好对应一个完整的功能。例如增、删、改、读功能同时具备。
  • 基于功能的垂直式开发模式优先。
  • 拆解的粒度:能够每天交付被测物,是非常理想的状态,如果做不到,可以先从拆解到 2~3 天做起。只要愿意花心思拆解,过一段时间以后,你就会发现,根本不难。
  • 如果功能仍旧过大,不能拆成 2~3 天交付,可以拆解成“半成品”,如一些接口,一些方法。
  1. 考虑架构和设计对任务拆分的影响
  • 好的解耦设计才能拆开。反模式:大面积违反迪米特原则。正向案例:面向接口编程
  • 如果联调的成本高,提前考虑 mock。mock 是基础设施,要投入精力建设。
  • 如果可以低成本不 mock,则可以考虑不 mock,这项能力也应该投入精力建设。
  • 架构应该是面向服务的(现代架构基本如此,不要乱搞就行)。

关于高效研发和测试的建议,欢迎大家在评论区留言探讨!