软件测试之优秀的产品质量评估模型的特征

　　产品质量评估中的几个场景：

　　场景1：项目计划的时间到了，就发布产品。

　　场景2：将缺陷修复率作为产品的质量目标。产品必须达到一定的缺陷修复率，才能发布。

　　场景3：我们为产品建立了很多指标来作为质量目标，如缺陷修复率、测试代码覆盖率等。产品必须达到制订的质量目标，才能发布。

　　结果：

　　场景1说明测试团队当前还没有产品质量评估的具体办法

　　场景2和场景1相比，已经有了判断标准，可以说是有质的改变，但场景2也有“软肋”，就是评价的标准太过于单一

　　场景3看起来很好，但是在实际操作的时候，我们往往会发现，我们费时费力地对这些指标进行了统计、分析和跟踪，最后也都达到了，但是我们对产品质量的好坏依然感到心里没底

　　

　　​

　　我分析出现场景3中的问题，主要原因有3点：

　　第一，这些指标覆盖的维度可能不全，我们可能遗漏掉了一些重要的考察项。

　　第二，“指标”本身比较容易被“聪明人”绕过去，变得形同虚设。

　　第三，整个质量评价体系中全是指标，缺少定性的分析

　　例如，我们以测试的代码覆盖度要达到90%作为一项质量目标。为了达到这个目标，我们可能会选择一些容易进行测试“覆盖”，但实际上风险并不大的地方进行测试。虽然最终能达到90%的测试覆盖目标，但