聊聊我对质量度量的看法

更新日期: 2022-05-23阅读: 975标签: 测试

这篇文章要聊的话题,源于某个测试交流群一位测试同学的提问。

关于质量度量,业内已经有很多资深的同学分享过他们的观点和看法,也有很多文章聊过这个话题。这篇文章我想从我的角度出发,聊一些关于质量度量,不一样的理解。

质量需不需要度量?

先聊第一个问题:质量需不需要度量?

答案显而易见: 质量需要度量,而且需要持续的度量! 为什么呢?

我们所从事的软件测试工作(随着技术不断发展,现在也叫作质量保障),工作的目标就是一个个软件系统。经过需求设计、需求评审、技术设计、代码开发、测试验证、发布上线等很多环节,才能保障这些软件的交付。

实际上这就是一个将不确定性(需求)转化为确定性(具有严密逻辑的软件系统)的过程。

确定性,需要一定的衡量标准来评估它是否满足预期的设计,因此是需要一定的数据度量的。

而持续度量的原因,是业务和技术本身就处在一个不断变化发展的状态,需要持续的度量和评估,才能保障软件系统的质量长期处在一定的水准之上,满足用户需要和保障业务目标达成。

质量度量的本质,是 具体的定量,而非抽象的定性 。

质量度量有哪些指标?

前面的文章聊到过,质量保障需要达到 “风险可识别+问题可追踪+结果可验证+数据可量化” ,才能最大限度的实现其价值。

CKL老师也在之前的文章《团队交付质量如何评估》中,提到过“ 业务可验收、研发可实现、测试可验证、部署可交付 ”等类似的理念,其实本质都是在描述质量度量和评估的目标。

那么,质量度量有哪些指标呢?

我们可以从软件质量保障和交付生命周期的三个阶段来做不同的定义。

需求设计质量

我们谈软件质量,不可避免要从它的源头说起,而源头就是需求和设计阶段要做的事情。这个阶段包括原型图、PRD文档、交互设计、技术方案、测试用例等几项重要产出物,当然他们有一定的前后依赖关系。

在需求设计阶段,我个人认为比较重要的有如下几点指标:

  • 需求评审通过率 (是否有遗漏、描述不清、存在逻辑漏洞等);

  • 设计评审通过率 (设计是否满足需求要求、是否合理美观友好);

  • 方案评审通过率 (方案实现难易程度、可测性、是否需要更多资源);

  • 用例评审通过率 (场景是否尽可能覆盖、和技术方案实现是否吻合);

注意,这里我提到的都是评审,为什么要做大量的评审工作呢?因为如果源头存在问题,那么研发过程和后面的用户使用质量,就无从谈起。方向错了就全错了。

评审的价值在于从用户使用场景角度出发,通过评审提问, 把需求逐步澄清并形成验收条件,产、研、测三方共同确认,形成共识 ,以保证大家对需求的认知不发生偏差,为后续团队正确的做事提供有价值的指导。

研发过程质量

“ 软件质量是构建出来的,不是测试出来的 ”。

测试的本质是 验证研发交付的产出物是否达到需求设计及预期的标准 。并不能直接带来质量的提升,只能通过种种手段多维度的去验证是否达标,并通过流程规范、度量标准等去保障最终的交付物达标。

因此,我们常说的各种测试技术手段,都是验证和保障交付质量的手段,而不是构建质量的手段。当然,开发有自己的一套体系,比如编码规范、单元测试覆盖率等,这里不做详细描述,我们重点关注测试维度。

在研发过程阶段,我个人认为比较重要的有如下几点指标:

  • 提测准时率 (便于评估进度、资源投入和风险);

  • 构建成功率 (构建成功率很大程度能反映出研发提测质量。如果经常编译构建失败或自动化测试通过率较低,因为这意味着最基本的需求实现出了问题);

  • 缺陷收敛率 (反映缺陷在研发过程阶段的变化趋势和缺陷修复的时效性问题。一般在测试阶段的中前期即单测&集成测试阶段会暴露大量缺陷,到系统测试和回归阶段缺陷就应该有明显下降和收敛,降低产品验收和交付风险);

  • 缺陷reopen率 (问题修复可能会带来新的问题,reopen指标可以从一定程度上评估缺陷修复的质量。如果reopen率比较高,那么很可能研发侧出现了问题,需要引起重视和寻找原因,尽快解决);

用户使用质量

用户使用质量,指的是软件线上发布后,我们 对用户使用过程进行追踪并采集数据进行评估度量的过程 。常见的度量指标有:

  • 线上缺陷逃逸率(线上发现的缺陷);

  • 线上问题留存率(线上发现的缺陷留存时长,可以用来评估修复的时效和对线上质量的重视程度);

  • 用户反馈建议量(这里仅针对的是用户针对功能的反馈或者客诉,不包含业务活动的范围);

质量度量要注意哪些方面?

质量保障是一个体系化和长期建设的过程,而质量度量作为最重要的一环之一,在落地过程中需要持续跟进和优化。从我个人的工作经历和实践出发,我总结了下面几点经验教训,供大家参考。

  • 质量保障不仅仅是QA同学的事情,因此质量度量也不能只关注测试维度;

  • 度量指标需要根据团队特性和业务具体情况来制定,并且需要评估是否合理,而不是强行制定强行执行;

  • 质量度量是为了保障最终交付质量能更好的满足用户需要,进一步达成业务目标,而非为了度量而强行度量;

  • 质量度量并非一蹴而就,在软件不同的生命周期和团队成熟度阶段,度量的范围和执行严格程度要灵活变通;

原文 https://mp.weixin.qq.com/s/RFM00b0AJcC9xm4KOhKBsg


链接: https://fly63.com/article/detial/11590

测试工具比较:选Jest,不选Mocha

Jest的未来看起来非常令人激动!看到Jest推陈出新如此快速,我感觉它将很快成为整个React生态系统中大部分项目的首选工具。我建议,应该把测试迁移到Jest上去。

你需要了解的前端测试“金字塔”

如果您正在测试前端应用程序,则应该了解前端测试金字塔。在本文中,我们将看到前端测试金字塔是什么,以及如何使用它来创建全面的测试套件。

web网页性能测试工具都有哪些

作为前端开发,我们不仅需要满足产品需求功能的实现,同时也需要对自己做的网站进行安全、易用性、性能等方面的考虑。随着目前技术不断进步,web页面的性能测试工具也在不断完善,通过这些工具,我们可以客观的评价web网站的质量水平。

js单元测试工具-jest自动化测试

jest 是 facebook 开源的,用来进行单元测试的框架,可以测试 javascipt 和 react。jest 提供了非常方便的 API,可以对下面的场景方便的测试:一般函数、异步函数、测试的生命周期、react 测试

web测试要点、方法_web端测试大全总结

web测试大全,测试web网站有哪些点呢?主要包括:功能测试、兼容性测试、安全测试、输入框测试、用户权限测试等

前端性能测试工具整理简介_性能测试工具都有哪些?

前端性能测试工具都有哪些:Favicon、Open Graph、图片优化-压缩图像、CSS 优化-Autoprefixer、Purifycss、minify CSS、减少载入时间、GZIP、CDN、优化平台-Sentry、Google Tag Manager

不用写代码,也能做好接口测试

本文你将了解到:1、接口测试基本概念,包含什么是接口,什么是接口测试,为什么要做接口测试;2、接口测试用例设计,3、怎样不用写代码,也能快速的根据开发的API文档完成接口自动化测试脚本

Selenium打开浏览器加载慢的原因

在自动化元素定位操作中经常使用智能等待来加强定位的强壮性,主要就是因为WebDriver没有提供页面加载场景的方法;在使用JavaScript知识的突然心生灵感,可以使用JavaScript来配合验证页面加载,结果发现我真是井底之蛙。

power assert_更智能、优雅的全方位 assert 断言库

在写测试代码时,以往我们需要翻阅文档,学习各种 API 才能明白如何操作断言。而现在我们可以透过 power-assert 的 assert 方法来减轻调试压力。不仅如此,它还提供更加直观,具体的运行效果,帮助 DEBUG。写测试代码,其实可以很容易。

常用的web网站负载/压力/性能测试工具

在网站上线发布之前,我们除了必要的安全、功能测试外,往往还需要进行压力测试。通过模拟实际应用的软硬件环境及用户使用过程的系统负荷,长时间或超大负荷地运行测试软件。包括:Apache JMeter 、LoadRunner、NeoLoad等

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!