|
在GJB5000A/CMMI的V&V（验证和确认）两个过程域中，都有一条实践叫“分析确认/验证结果”。这里的确认/验证结果，主要指的就是测试结果。分析确认/验证结果，就是分析测试结果。 可是，在实践当中，很少有做好测试结果分析的。常见的情况都是这样：罗列测试用例数，给出测试用例通过率，按问题等级（比如12345级）和问题类型（通常是按文档问题、程序问题、设计问题、其它问题等）给出发现的BUG数。这些数据对我们有多少帮助呢？大概只能对软件缺陷数多少有个感官上的认识。而对于测试是否充分，这样的测试结果是否表明测试完美收官，或者对将来软件避免发生类似问题等方面，并没有太大的帮助。 那要怎样分析测试结果才会对我们有更大的帮助呢？
通过对测试问题的分析，很容易找出问题等级最严重的程序类的测试问题，并定位到对应的代码块。 根据测试公理：随着软件中某个部分已发现的缺陷的不断增多，其中存在更多未发现的缺陷的概率也会增大。所以这些发现严重问题的代码块，有可能存在尚未发现的缺陷。应对这些代码块所在的软件单元、软件模块的程序设计和测试设计进行分析。 对于单元测试，分析其测试用例的路径覆盖率，如果BUG出现在未覆盖到的路径中，应增加单元测试用例。 对于功能测试，使用因果图和决策表来分析测试的完整性。
问题原因分析是非常实用非常重要的一种分析方法。在GJB5000A/CMMI的L5中CAR过程域有专门的要求，常用的手段就是帕累托分析和直方图分析。通过这些分析方法，可以定位问题产生的根本原因。 而要使帕累托分析方法有效，首要的就是建立问题的类别。通过建立的问题类别，对收集到的测试问题数据进行分类，这样就会将问题进行有效的细化，能够发现数量最多的问题类型。而集中精力解决这些问题，根据二八原则，将会很大程度上降低软件发现的BUG数，提高软件的质量。而且，在某一模块中发现问题数较多的问题类型在其他模块中也可能存在，应该检查其他模块是否存在该类型的问题。同样，在同一项目或同一软件组开发的产品中，缺陷类型的分布基本相似，所以在同一项目或同一软件组开发的产品中，也要检查是否存在该类型的问题。 问题类型的最佳数量是6~10。类别太少，将不足以把问题进行有效的细化，类别太多，又使研究范围变得太宽。一些组织定义的问题类型如文档问题、程序问题、设计问题、其他问题等，并不太适用于对代码测试问题的分类（可以说都是程序问题），而应进一步划分为接口问题、功能问题、性能问题、界面问题、其他问题等。
在对测试结果进行分析时，还应注意分析哪些测试用例具有最好的测试效率，即在单位时间内发现的有效BUG数最多。对于这些测试效率高的测试用例，应将其纳入回归测试用例集当中，这样，可以使用回归测试的绩效大大增加。每次测试结果都进行这样的分析，并利用分析得到的高测试效率的测试用例不断更新回归测试用例集。 开展以上三种分析活动，会使测试结果的分析取得很好的效果，对后续软件质量的提高大有裨益。 参考书目：《软件过程管理》 微信号：IdeaofSE |
|
|
