效率提升 之 团队测试流程优化

[HXWfromDJTU]

前言

毕业前几年时间一直在小公司小团队中度过，对项目组的测试流程有些总结:

• 小公司小团队一般在测试上，就更依赖于开发本身。
• 即使公司在测试上有投入，但一般不会太大，测试角色有时候被边缘化。
• 测试组的测试用例没有最大化地利用起来

主要问题有以下几种:

1. 测试组编写的用例文档，常常在本地维护(Word/Excel)，既不安全也不利于共享补充。
2. 测试用例文档，只在测试组进行测试的时候使用，利用空间有限。

优化流程

总体思路应该是，一个项目(需求)的测试用例文档，应该由测试组为主导，开发组、设计组、产品组进行补充，并持续补充、迭代。总体思路，简单可以概括为下面的流程图。

测试文档规范

协作形式

• 测试用例要在石墨等在线协作平台进行维护。
• 测试文档的组织形式(word/excel/思维导图等)，原则上由测试组根据项目类型决定。

版本号与迭代

• 测试用例可以进行迭代，应该有对应的版本号。
• 每一个用例被创建后，不可被硬删除，应保留并标记旧用例，新创建用例进行版本迭代。

用例分级制度

• 每个用例必须要有优先级/重要程度的属性，原则上由测试组决定
• 对应”重要程度“用例的通过与否，决定了项目是否可以提测，是否可以上线。

测试用例介入开发

需求定型期间

• 测试组根据产品的需求编写基础的测试用例。
• 产品交互稿提交给开发组进行开发后，需求/交互稿有很任何变动，产品组需要在对应需求但/设计稿评论处标明，并通知测试组。测试组抽时间对应补充测试基础用例。

开发组开发期间

• 开发组进行项目开发的时候，需求文档+原型为主，设计图 和 基础测试用例为辅。

• 开发组在开发过程中，发现一些特殊逻辑、新的边界条件，也加入到云文档的“待整理用例”区。

• 测试用例评审会

  • 内容：开发对自己新增的”新增用例“进行简单解释，测试组进行整理
  • 时间: 前后端联调完，开发准备开始自测前。最迟的时间定为，项目原定开发完成时间前的72小时。

提测期间

• 开发组在提交内部体验版本前，须保证测试用例中“关键路径”的全部通过。
• 测试组整理“待整理用例”到总用例中，然后再开展测试工作。

上线后

• 开发组每次修复bug后，也应由开发组将本次复现的路径，添加到“待整理用例区”，测试组定期进行整理。

持续开发期间

• 测试组根据需求的迭代，不断迭代测试用例。
• 完整的测试用例文档，可以反哺于开发单元测试的编写，增加测试覆盖率。

总结

过程总结

• 测试用例文档帮助开发补充一些边界条件
• 开发、设计、产品帮助测试组补充一些特殊的逻辑场景
• 测试用例应该区分用例的优先级高低
• 测试用例文档应该是长期维护、完善的

以上内容，都是是根据已有的工作经验和经历过团队的实际情况总结出来的。能不能借鉴，具体情况必须具体分析。

参考文章

[1] 软件测试的流程