高效测试开发 | 如何拆解一个任务？
刘晓光 [霍格沃兹测试学院](javascript:void(0)
3月26日
为了提升研发和测试效能，需要先明确一个目标：
把研发任务拆解为“可测试”的交付物
如何理解“可测试”？
首先，要摒弃“可以做端到端的测试才叫可测试”的观念。
- 接口可以测试；
- 方法/函数可以测试；
- 业务需求逻辑可以测试；
- 拆分后，尽量提供可端到端测试的测试物（这一点和上一点并不矛盾，因为早晚要做端到端的测试）；
如何拆解？
- 做好排期。
- 做好排期，是做好拆解的基础。
- 双周的排期是一个非常合适的排期工作的周期。
- 对自己团队的交付能力有比较清晰的认识（可以通过过去的迭代总结不断看清楚）
- 所有干系人参与排期（项目经理，需求，开发，测试，运营），不然对不齐。
- 留出一定的富余量。
- 在排期会上，对排期内的任务进行分解，测试和开发人员均应该在场，对任务进行评估。
- 做好可测性分析。
- 一定要达成一个“可测”的协议。
- 尽可能的按照业务功能去拆解，而不是按照技术层次去拆解。
- 如果采用了"用户故事"的方法，按照用户故事去拆分
- 最好对应一个完整的功能。例如增、删、改、读功能同时具备。
- 基于功能的垂直式开发模式优先。
- 拆解的粒度：能够每天交付被测物，是非常理想的状态，如果做不到，可以先从拆解到 2~3 天做起。只要愿意花心思拆解，过一段时间以后，你就会发现，根本不难。
- 如果功能仍旧过大，不能拆成 2~3 天交付，可以拆解成“半成品”，如一些接口，一些方法。
- 考虑架构和设计对任务拆分的影响
- 好的解耦设计才能拆开。反模式：大面积违反迪米特原则。正向案例：面向接口编程
- 如果联调的成本高，提前考虑 mock。mock 是基础设施，要投入精力建设。
- 如果可以低成本不 mock，则可以考虑不 mock，这项能力也应该投入精力建设。
- 架构应该是面向服务的（现代架构基本如此，不要乱搞就行）。
关于高效研发和测试的建议，欢迎大家在评论区留言探讨！