文章系列
[质量提升之道]－Code Review
[质量提升之道]－UT&Coverage

前言

上一篇介绍了 UT&Coverage，本篇将介绍测试左移动和提测质量管控。
所谓测试左移，以版本提测为界限，界限以左的测试工作。测试左移，能帮助到提测质量，提测质量的好坏直接反映出一个团队的管理水平、技术能力。
目前大部分公司，测试在左移阶段还比较薄弱，一般只参与需求评审，测试用例等工作，其余的要么不带测试玩，要么没有能力参与。
其实，能发现更多质量问题的还是在左移阶段，这是提升测试人员核心竞争力的舞台，也是测试人员为提升测试行业影响力的星星之火。

左移清单

1.需求评审，测试人员必须对业务熟悉，甚至成为领域内的专家，敢于合理的挑战产品经理；
2.技术方案评审，测试人员能读懂和理解技术方案，凭丰富的经验的敏锐的嗅觉，挖掘技术方案的不足之处。例如：方案中的补偿场景是否合理充分、业务场景不断增加后的可扩展性、业务量大幅增加后的性能问题、可测试性等；
3.测试用例和业务编码并行，包括接口测试用例、功能测试用例的编写；
a.提供接口服务的，要求开发人员在编写业务代码之前，先给出接口设计文档；
b.引入 Swagger 等自动生成工具的，先定义好接口（request 和 response 的参数、参数类型、必填项、取值范围、其他约束等），编写业务代码前，先编译生成文档；
4.单元测试的质量，除了保障代码覆盖率等硬性指标，还要从测试角度检查 UT 代码的有效性；
5.代码静态分析，测试也可以拉取代码进行检测，协同开发一起保障代码质量；
6.代码审查，有问题的代码不能轻易带病入库，测试协同开发一起把好代码入库前的最后一道关；
7.测试用例评审，版本提测前组织产品、研发、测试一起完成，提测后可直接使用。

提测质量管控

相信大多数同行切身体验过随意发版的各种负面影响：
1.提测版本问题一大堆，测试大多数时间耗费在基本功能的验证，而极端场景、复杂场景基本没时间测试；
2.养成开发不自测的陋习，皮球踢给测试，发版质量越来越差；
3.缺陷收敛期拉的比较长，造成迭代次数不可控，测试疲于应对，不得不靠堆人力、堆时间完成。

所以，提测质量管控，势在必行：
a.代码静态扫描通过提测标准，例如：没有严重级别的问题；
b.单元测试的覆盖率达到要求的指标，例如：method 覆盖率不低于 90%，line 覆盖率不低于 70%；
c.接口测试快速回归脚本全部通过；
d.冒烟测试通过提测标准，例如：危险 P0=0、 严重 p1<=1。

后话

这几年，IT 行业对懂技术的测试人才需求量越来越大，测试技术领域的人才也越来越多。目前大多数的讨论都集中在了 UI 自动化、接口自动化、工具开发等领域，有不少是重复造轮子。希望有更多的能理解测试工作的本质，契合工作痛点应用技术，说白了，我们测试学技术最终是为质量服务的。

下一次，会介绍代码审核工具－Phabricator 的安装和使用。