您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试技术 > 其他相关 > 正文

测试全程度量探索

发表于:2020-06-04 作者:Lizzy 来源:搜狗测试

前言

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

测试全程解析

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

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

参与到开发的 方案设计讲解会 ,以测试的角度驱动设计架构边界值及异常场景的覆盖;

建立 静态代码扫描平台、 驱动开发建立 Code Review流程机制 ,以校验代码规范度及提前暴露架构层面Bug;

配合开发搭建 单元测试平台、接口自动化框架 ,以提前暴露底层、接口层面的Bug;

前置 产品、交互走查时机 ,以提前暴露产品形态的Bug。

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

建立线上接口监控平台,以实时发现线上问题并及时解决;

开展线上测试实验,实时收集线上目标用户的反馈,及时作出策略调整。

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

测试全程度量指标思考

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

 

因不同产品形态、项目阶段,软件测试过程度量维度是可以适度调整的,结合小编所在业务线,过程度量指标如下:

测试过程化度量指标,是依据项目全过程,从产品、开发、测试维度对质量和效率进行评估。

需求评审阶段 :评审预留时间、评审需求修改数、需求评审轮数、需求文档齐全数;

开发设计及实现阶段 :方案讲解会次数、单元测试覆盖率、代码评审覆盖率、开发提测进度、自测case执行轮次、开发工期;

用例设计及执行阶段 :需求修改轮次、需求插入/变更任务数、Bug功能类别、Bug分布图、连带Bug数、千行Bug率、用例功能点覆盖度、每人日执行用例数、缺陷误报率、一轮后期Bug数、用例设计工期、一轮执行工期;

回归冒烟阶段 :回归阶段需求确认数、回归阶段需求变更/插入数、接口测试覆盖率、回归发现Bug数、二轮测试工期、冒烟测试工期;

上线及线上阶段 :版本整体Bug修复率、灰度发布频次、线上崩溃率、线上问题数、性能指标数据、线上安全漏洞频次;

注:上述部分内容及图片,引用自书籍《 全程软件测试》

测试全程度量指标落地

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

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

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

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

写在最后

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