测试全程度量探索

2020/04/09 08:00
阅读数 204

前言

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


测试全程解析

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



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

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


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


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


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


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


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

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

 

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

测试全程度量指标思考

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



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



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


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


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


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


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


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


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

测试全程度量指标落地

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


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

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

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

写在最后

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


搜狗测试微信号:Qa_xiaoming

搜狗测试QQ粉丝群:459645679

本文分享自微信公众号 - 搜狗测试(SogouQA)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部