过来领你的Bug之“质量度量“篇_测试bug如何衡量测试质量

前言

之前我讲解了Bug记录平台以及如何对Bug进行分析。基本是在单个Bug详细内容的维度单点进行分析和改进，为我们的项目、产品进行质量提升。

其实我们需要更高一层的思考问题，如何利用现有的数据评估我们的项目质量呢，这就涉及到关于质量度量的问题。

质量度量简单来说就是一个项目或一个产品经过一段时间产品、开发、测试的迭代周期后，如何评估这个产品质量是否能够满足预期。可能会包含很多方面，例如短期来看的软件运转的是否良好，是否存在一些潜在的风险或遗留问题，是否能够直接发布上线。长期来看就是整个流程是否存在优化的空间，开发人员在日常工作中是否疲于修改Bug，而不是做新功能或架构优化，是否一个功能反反复复修改才能满足业务需要等。这些很多的问题抛出来，如果没有一个直观、客观、可量化的质量度量的话，我相信再牛的测试人员也不可能给出这些问题的答案。

质量度量的起源

提到质量度量的概念，不得不说他的起源，SATC（Software Assurance Technology Center），他是美国航空航天局（NASA）的一个部门，该机构成立于1992年，作为其在戈达德航天飞行中心的系统可靠性和安全办公室的一部分。它的宗旨是“成为软件保证方面的卓越中心，致力于在GSFC为NASA开发的软件的质量和可靠性方面作出可衡量的改进”。该中心一直是关于软件度量、保证和风险管理的研究论文的来源。很多和测试相关的依据也都是依从该中心发表的论文。

该机构给出了Bug率和源码复杂度的一些关系，然后在这之上提出了关于质量的度量模型。由于它是基于C语言进行分析的，虽然可能具体的指标不一定适用于目前互联网大部分在用的Java、Go的后端语言。但是还是值得参考的，例如当时给出了的一些结论，每个函数代码行需要小于100行，圈复杂度需要小于10。据我所知，在华为等传统领域的IT公司还是作为一个强代码检查规范落地的。在SATC之后，也有很多国内外的组织提出来质量度量的一些维度和指标，例如SE