3. 评估阶段
在确保输入的 ODC 数据正确性的前提下，就可以对这些缺陷进行分析了。根据 ODC 的不同属性进行分类统计，可得出不同方面的结论。以此来反映测试、开发或产品设计方面的问题，指出潜在的改进的机会。比如：缺陷被发现的如何、产品是否稳定等。下面挑几个典型的评估方法进行说明。
对测试工作的评估
利用不同的 ODC 属性的组合，可以从多方面来评估测试工作的完成情况。例如利用测试阶段和 activity 属性来评估是否应在某一测试阶段中发现的缺陷却被在下一测试阶段中才发现；利用 activity 和 trigger 属性来评估是否每个 activity 都使用了足够多的与之对应的 trigger 来发现缺陷；利用时间和 trigger 属性来评估是否随着时间的推移测试变得更加复杂等。下面就利用第一种评估方法来进行举例。
不同的测试阶段有不同的测试重点。例如在功能测试阶段，所对应的 activity 就是 Function Test( 功能测试 )。而在系统测试阶段，所对应的 activity 就是 System Test（系统测试）。我们可以通过统计在每种测试阶段中发现缺陷的 activity 来判断是否本应在该测试阶段中发现的缺陷被遗留到了下一测试阶段。以此来评估测试工作的完成情况。如图 5 所示。
图 5. 利用测试阶段和 activity 属性得到的评估图
由上图我们可以看出，该项目在系统测试阶段，有近一半缺陷的 activity 是功能测试。这说明本应该在功能测试阶段发现的缺陷，却被遗留到了系统测试阶段才得以发现。可见功能测试阶段的测试工作做得不够全面。
经验和建议
- 这个评估方法常用于衡量是否本应该在功能测试阶段发现的缺陷没有被发现，而是到了系统测试阶段才被发现。因此该评估方法最好在系统测试开始后使用，因为在此之前的阶段使用没有太大的帮助；
- 客观上讲，在系统测试阶段发现一些功能测试阶段的缺陷是正常现象，这不会影响系统测试的正常运行。反而如果在系统测试阶段没有任何功能测试阶段的缺陷，就说明有问题了。很可能是由于测试人员对 activity 属性理解不正确导致的错误输入引起的；
- 上图所表现出来的问题是过多的本应在功能测试阶段发现的缺陷却在系统测试阶段被发现。针对该问题，我们可以通过增加功能测试阶段的测试用例来增加功能测试的覆盖面。或是修改功能测试阶段的退出标准，例如必须发现多少缺陷才能进入系统测试阶段等等。
对产品稳定度的评估
利用 ODC 属性不仅可以评估测试工作的完成情况，同时还可以评估产品的稳定度。例如：随着项目的进展，定期统计 qualifier 属性的变化趋势，以此来评估产品是否变得更加完善；或者定期统计 impact 属性的变化趋势，以此来评估影响产品功能性和可靠性的缺陷是否在减少。下面就以一个实例中的 qualifier 属性为研究对象，来评估一下该实例是否随着项目进展的过程而变得更加完善。如图 6 所示。
图 6. Qualifier 属性趋势图
图 6 显示了 missing 和 incorrect 的百分比随项目进展而发生的变化趋势。对于一个逐渐趋向于稳定的产品来说，Qualifier 为 missing 的缺陷应该逐渐减少。因为任何未经测试过的新代码的加入，都会增加潜在的风险。
但是从图 6 中我们可以看到这个实例的稳定度并不乐观。Qualifier 为 missing 的缺陷并没有随着项目的发展而有减少的趋势。
文章来源于领测软件测试网 https://www.ltesting.net/
