从测试角度度量项目质量的7个维度

　　首先因为我本身是作测试的，所以这篇文章页主要是从测试的角度出发，对几个测试相关的维度进行分析，说明它们是如何影响项目质量的。这7个维度是根据 以往作项目的经验再加上网上一些前辈的总结提炼出来的，并不是来自于教科书，因此仅供参考。这7个维度也只是从功能测试出发，对于性能测试、安全性测试、用 户体验测试等并无过多的涉及，至于从这些方面如何去度量，之后再作讨论。

　　首先，咱们要明确几个概念，就是“严重Bug”和“缺陷修复率”。这7个维度，有不少都和这两个概念有关。“严重Bug”指的是在项目中，优先 级为A和B的Bug。因为咱们公司用的JIRA不像Bugzilla那样，对Bug分为“严重程度”和“优先级”两个维度，所以咱们在报Bug时根据状况 综合这两点的影响，统一以“优先级”来衡量Bug级别。A级Bug是指程序没法正常运行或者是测试没法正常进行；B级是指各个主要功能模块出现用户不可接 受的错误。C级和D级大多也是一些功能方面的问题，还有一些用户体验易用性的问题，用户能够接受少许这种类型的Bug。

　　好，下面开始讨论这7个维度，我会说明计算方法，以及它们的战略意义。

　　一、严重bug数 / 测试用例数

　　这个维度表明了一个项目的严重bug数量是否正常，让测试用例参与计算，是为了平衡规模不一样的项目的数据。

　　二、第三轮系统测试出现的严重bug数 / 严重bug总数

　　因为需求变动和 项目并行比较常见，又不可避免，所以目前咱们的测试流程尽量的控制不超过四轮系统测试，四轮的目标分别是：发现bug、验证bug并响应变动、继续验证 Bug、稳定回归。若是在第三轮系统测试时，还出现大量严重bug，那说明多是以前的测试作的不到位，或者有新的变动，再或者开发修改缺陷带来的成本太 高，确定是不正常的，也会对第四轮的回归带来巨大风险。所以这个数字应该要控制在一个很低的水平。

　　三、被重开的严重bug / 严重bug总数

　　重开指开发修复缺陷后，测试验证不经过，或者是已经关闭的Bug又复发。这个维度也应该被控制在一个很低的水平，若是偏高，说明开发修复bug的效率偏低，代码不稳定，发布后出现bug的概率可能会增长。

　　四、第二轮、第三轮测试用例平均经过率

　　由于第二轮和第三轮的目标就是修复bug，因此若是第三轮结束的时候，严重bug所有被修复，而且第三轮没有出现新的严重bug，那么能够说项 目的质量是很是稳定的。这里断定第二轮、第三轮用例经过与否的标准，就是看这两轮测试结束时，若是有严重bug没有关闭，那相关的测试用例就是 failed。此外，C、D级bug若是没有关闭，除非有肯定的用例与之对应，不然不会影响用例的经过率。

　　五、测试工做量（人月） / 测试用例数

　　这个维度表明投入的测试资源是否充足，这里的工做量，指的是从测试设计到测试执行的全部人月数。若是数字太低，说明测试资源紧张，没法保证测试质量；若是太高，说明有可能测试效率低，测试负责人须要进行解释。

　　六、严重bug平均关闭时间（天）

　　bug 关闭时间，指bug从建立开始，到close为止，通过的时间，要精确到小数点后1位。只有状态是closed的bug，才会计算关闭时间。平均关闭时间 的计算方法也很简单，把全部closed严重bug求平均值便可。这个维度表明项目组解决bug的效率，若是时间太长，说明项目组对bug重视不够，或者 开发组资源不足。

　　七、已修复Bug / Bug总数

　　这个维度表明测试人员所报Bug的整体修复率，若是修复率太低说明在测试过程当中对于项目的控制出现了问题，多是在测试过程当中产品变动过于频繁，对变动的控制不合理，或者测试组对于项目的理解有误差，项目经理和测试负责人须要给出解释。

　　其实要度量项目的质量，还有不少维度要考虑，好比需求文档、设计方案、代码等等，不过咱们仍是先在测试的范畴进行讨论，欢迎你们对这些维度提改进建议，或者提出新的维度。

转载请注明：http://www.spasvo.com/news/html/2013129100733.html