聊聊我对质量度量的看法

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

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

质量需不需要度量？

先聊第一个问题：质量需不需要度量？

答案显而易见：质量需要度量，而且需要持续的度量！为什么呢？

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

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

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

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

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

质量度量有哪些指标？

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

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

那么，质量度量有哪些指标呢？

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

需求设计质量

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

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

• 需求评审通过率（是否有遗漏、描述不清、存在逻辑漏洞等）；
• 设计评审通过率（设计是否满足需求要求、是否合理美观友好）；
• 方案评审通过率（方案实现难易程度、可测性、是否需要更多资源）；
• 用例评审通过率（场景是否尽可能覆盖、和技术方案实现是否吻合）；

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

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

研发过程质量

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

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

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

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

• 提测准时率（便于评估进度、资源投入和风险）；
• 构建成功率（构建成功率很大程度能反映出研发提测质量。如果经常编译构建失败或自动化测试通过率较低，因为这意味着最基本的需求实现出了问题）；
• 缺陷收敛率（反映缺陷在研发过程阶段的变化趋势和缺陷修复的时效性问题。一般在测试阶段的中前期即单测&集成测试阶段会暴露大量缺陷，到系统测试和回归阶段缺陷就应该有明显下降和收敛，降低产品验收和交付风险）；
• 缺陷reopen率（问题修复可能会带来新的问题，reopen指标可以从一定程度上评估缺陷修复的质量。如果reopen率比较高，那么很可能研发侧出现了问题，需要引起重视和寻找原因，尽快解决）；

用户使用质量

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

• 线上缺陷逃逸率（线上发现的缺陷）；
• 线上问题留存率（线上发现的缺陷留存时长，可以用来评估修复的时效和对线上质量的重视程度）；
• 用户反馈建议量（这里仅针对的是用户针对功能的反馈或者客诉，不包含业务活动的范围）；

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

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

• 质量保障不仅仅是QA同学的事情，因此质量度量也不能只关注测试维度；
• 度量指标需要根据团队特性和业务具体情况来制定，并且需要评估是否合理，而不是强行制定强行执行；
• 质量度量是为了保障最终交付质量能更好的满足用户需要，进一步达成业务目标，而非为了度量而强行度量；
• 质量度量并非一蹴而就，在软件不同的生命周期和团队成熟度阶段，度量的范围和执行严格程度要灵活变通；