文章系列
[质量提升之道]-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 自动化、接口自动化、工具开发等领域,有不少是重复造轮子。希望有更多的能理解测试工作的本质,契合工作痛点应用技术,说白了,我们测试学技术最终是为质量服务的。