其他分享
首页 > 其他分享> > 漫谈测试覆盖率

漫谈测试覆盖率

作者:互联网

写这篇文章的动力其实源自昨晚饭后在马路上散步时的一些想法,要谈的内容如标题所述:测试覆盖率。

我在之前的文章,写过对质量保障体系建设的一些思考,也写过对质量度量的一些看法,

所谓测试覆盖率这个词,大多源于质量度量的一个指标或者说维度。因为要度量,要可量化,才有了覆盖率这一维度。

当然,由于是漫谈,本篇文章不会有很立体的结构和清晰的逻辑,我尝试通过对几个问题的思考,来谈测试覆盖率。

 

需求是什么

在聊测试覆盖率之前,我们先回到测试工作最初的对象:需求。

需求是什么?广义来说,所有来自于用户的不满和痛点,能直接或间接带来商业价值的诉求都是需求。

如果要仔细定义的话,那么来自于产品经理详细描述的PRD和原型图,就是需求的具象化呈现。

需求是测试工作的本质对象,所有测试工作都是围绕需求来展开,当然也会有同学说测试的对象是业务,其实两者本质没差,业务是抽象的定性的,而需求是对业务的具象化定义和描述。

而测试的第一对象,则是产品(软件系统APP都可),它将需求进行了实质性转化,变成了一个可观测可度量的东西。

 

质量度量的意义

聊完需求接着聊质量度量,先说质量。

最初软件测试工程师的岗位,业内称之为QC,即Quality Control(质量控制),指的是对产品进行质量检验、发现问题并进行分析、改善不合格问题的人员。记得我刚入行做软件测试时,很多公司内部都是统称为QC。

后来对软件测试工程师的定义,逐渐变成了QA,即Quality Assurance(质量保障),通过建立和维持质量保障体系来确保产品质量没有问题。

QA不仅要知道问题出在哪里,还要知道这些问题解决方案如何制订,今后如何预防,QC仅仅是有问题就去控制,但不一定要知道为什么要这样去控制。

这个演化的过程,有点像测试左移的概念,即:由事中检测逐渐移动到事前评估预防。

至于解决方案如何制定,其实就是将经验通过流程固化以及对风险的评估控制。

那如何定义问题确实得到了控制和预防并有效解决呢?这就是质量度量的意义。

质量度量的本质是将不确定性的问题,通过流控控制和前置的风险评估,转化为确定的可控制可量化的过程。

 

如何看待测试覆盖率

质量度量的本质是控制问题带来的风险并解决问题,通过量化手段评估最终质量的过程。

而测试覆盖率,就是质量度量过程中很重要的一个评估维度。

我的观点是:测试覆盖率和需求挂钩,高度依赖研发过程,需要分阶段执行不同粒度,最终结果和线上交付质量成比例。

测试的本质对象是需求,需求的定义是否明确,需求是否符合真实的业务场景和用户痛点,对最终交付质量影响很大。

在将需求转化为可观测可度量的产品过程中,研发构建的质量本身就决定了最终交付质量的好坏。

这里打个岔,并不是说构建的质量是唯一,而是软件工程本身的特性决定了质量、成本、时间三要素需要做平衡和取舍。

至于分阶段执行不同的测试覆盖粒度,则取决于产品的成熟度、用户量及用户类型、具备的商业价值以及企业发展阶段。

为什么说测试覆盖率和线上交付质量成比例呢?

我的观点是测试覆盖率是无法前置评估的,只能通过最终交付质量来度量。

简单理解就是,产品没上线前你不知道线上交付质量如何。只能通过上线后的质量来度量测试覆盖率做的怎么样。

线上没出bug,没有客诉,带来了大量的订单,那就证明了这个阶段的质量没有问题,测试覆盖率做的好。

否则测试case设计的再严密,线上有bug,有大量用户投诉,也没有达到预期的业务目标,你很难说测试覆盖率做的好。

 

核心内容总结和回顾

  1. 业务是抽象和定性的;
  2. 需求是对业务的具象定义和描述;
  3. 测试工作的本质对象是围绕产品展开;
  4. 产品研发是将需求转化为可观测可度量的产品的过程;
  5. 质量度量的本质是控制问题带来的风险并解决问题,通过量化手段评估最终质量的过程;
  6. 测试覆盖率和需求挂钩,高度依赖研发过程,需要分阶段执行不同粒度,最终结果和线上交付质量成比例;

 

标签:需求,交付,覆盖率,漫谈,质量,测试,度量
来源: https://www.cnblogs.com/imyalost/p/16361735.html