测试全程度量探索

前言

当下互联网的时代，业务形态呈现多样化，业务模式趋向敏捷、Devops流程，大家不仅仅关注于上线后的效果，同时，也关注从需求孕育到线上运行整个过程是否为最优。QA作为质量守护者，在全过程化链路中，如何平衡质量和效率？如何建立一套质量和效率的度量体系？

测试全程解析

质量是构建的，不是靠测试测出来的。在此理念下，业界很多测试同行分别扩展了测试域，以业务流程过程为依据，分别向左、右侧扩展，引领出测试左移、测试右移新阶段。如下是小编所在项目组测试过程化解析：

测试左移：有数据分析，单元测试可以发现代码中60%~70%的问题。测试左移即将测试工作前置，提前发现问题。

• 参与到开发的方案设计讲解会，以测试的角度驱动设计架构边界值及异常场景的覆盖；
• 建立静态代码扫描平台、驱动开发建立Code Review流程机制，以校验代码规范度及提前暴露架构层面Bug；
• 配合开发搭建单元测试平台、接口自动化框架，以提前暴露底层、接口层面的Bug；
• 前置产品、交互走查时机，以提前暴露产品形态的Bug。

测试右移：为满足产品目标，开展线上测试或带Bug上线，且是业务线各方已知的风险。测试右移即实时发现线上数据趋势及变化、线上问题，及时调整修复。

• 建立线上接口监控平台，以实时发现线上问题并及时解决；
• 开展线上测试实验，实时收集线上目标用户的反馈，及时作出策略调整。

系统测试：开发提测后，对于提测任务需进行全面测试。系统测试即对测试开展测试计划及全程把控、测试分析及方案设计、兼容性测试、性能测试、安全性测试等。

测试全程度量指标思考

针对测试全程度量，其目标是围绕着测试质量和效率这两个基本目标展开的。《全程软件测试》一书中，软件测试过程度量指标如下：

• 需求评审阶段：评审预留时间、评审需求修改数、需求评审轮数、需求文档齐全数；
• 开发设计及实现阶段：方案讲解会次数、单元测试覆盖率、代码评审覆盖率、开发提测进度、自测case执行轮次、开发工期；
• 用例设计及执行阶段：需求修改轮次、需求插入/变更任务数、Bug功能类别、Bug分布图、连带Bug数、千行Bug率、用例功能点覆盖度、每人日执行用例数、缺陷误报率、一轮后期Bug数、用例设计工期、一轮执行工期；
• 回归冒烟阶段：回归阶段需求确认数、回归阶段需求变更/插入数、接口测试覆盖率、回归发现Bug数、二轮测试工期、冒烟测试工期；
• 上线及线上阶段：版本整体Bug修复率、灰度发布频次、线上崩溃率、线上问题数、性能指标数据、线上安全漏洞频次； 注：上述部分内容及图片，引用自书籍《全程软件测试》

测试全程度量指标落地

有效的度量指标选取、快速的可视化平台采集、精准的数据分析定位，对于全程度量起到关键的作用。小编所在的项目组度量指标落地情况如下：

• 测试左移、右移域复盘：以测试任务或版本为维度，针对产品方（产品运营域）、开发方（研发域）过程测试度量指标，进行采集输出，三方结合数据，实时与上一版本对标，制定优化的方案并落地。

• 集成测试域复盘：以测试任务或版本为维度，针对集成测试域度量指标，进行采集输出，测试方结合数据，实时与上一版本对标，制定优化的方案并落地。

过程化度量指标有助于分析项目中的瓶颈和问题，更好的制定下一阶段的目标。

写在最后

测试全程度量的目标是质量和效率，QA不仅仅局限于单一的测试及工具开发，也需站在项目全程的角度进行质量、效率的度量，优化全程测试指标。