测试用例评估方法

ZDNet至顶网软件频道 测试用例设计是测试人员必须掌握的基本技能之一，也是个难点之一。那么写好的测试用例如何去评估有效性呢？最近一直在思考这个问题，本来想年前来一篇的，但是一直偷懒，直到现在，网上的资料很多，这里就结合自己的思考简单谈谈自己的看法吧。

<!--[if !supportLists]-->1. 从测试用例的形式分析

首先，每个公司有每个公司的测试用例模板，如包括模块、子模块、优先级、前置条件、操作步骤、操作数据、预期结果、用例状态、缺陷严重级、概率、实际测试结果、备注；字体格式以及字体大小；测试用例的设计是按照之前约定的按流程来设计还是按照模块设计；测试用例放置的位置以及执行的先后顺序，上面执行过的测试用例是否可以作为下面测试用例执行的输入数据，也就是说测试数据是否具有连贯性等等，这是我们判断测试用例有效性的首要条件。

再则，查看各个用例对应的各个列的编写是否有效，如操作步骤是否简洁，优先级设置是否合理（当然优先级的设置跟实际项目的版本次数的测试策略也有很大关系），预期结果是否明确，之前查看过好多测试用例的预期结果都很含糊，如修改设置项后点击【保存】，预期结果“保存成功”，我感觉这样的预期结果跟没写一样；我们可以优化为：数据库数据更新与修改设置一致且页面显示与数据库数据保持一致。这样测试用例完成后交给另一个人来测试就能有一个明确的判断标准。

用例格式的评估方法：采用同行用例评审的方式进行。

<!--[if !supportLists]-->2. <!--[endif]-->从测试用例的覆盖率分析

<!--[if !supportLists]-->1> <!--[endif]-->测试用例的总数和颗粒度

好多理论书上写的设计测试用例的原则：用最少的测试用例完成最大的覆盖率。一直以来很怀疑这个原则，个人认为测试用例的覆盖率跟测试时间、测试总数以及测试颗粒度有关，如果给你足够的时间大家都可以设计出覆盖率很高的测试用例，但是用例总数和颗粒度会出现相应的变化。颗粒度细点，不管你怎么设计，测试用例的总数肯定会上升，覆盖率也会有相应提高。现在想想上面这句话作者可能要表达的意思是：使用合适的测试用例设计方法完成覆盖率的提升，同时用例总数相对较少，那么我们需要做的就是寻找把握这种平衡。

用例评审时我们的判断标准就可以从以下几个方面去把握：颗粒度是否把握得当，用例是否冗余，对应模块使用的测试用例设计方法是否得当（这个没有对错之分，只有好与更好的区别）等等

<!--[if !supportLists]-->2> <!--[endif]-->测试用例的覆盖率和遗漏率

<!--[if !supportLists]-->a. <!--[endif]-->覆盖率

个人感觉覆盖率是测试用例设计中最重要的一环，特别是对主要功能的覆盖，不管你颗粒度如何，测试用例总数多少，使用什么测试用例设计方法，只有把必须要覆盖的功能覆盖了这整个测试用例才算真正的有效。那么如何判断有没有覆盖到呢？

首先，对比需求说明书，是否覆盖需求上的所有需求点（包括显性和隐性的，当然这个跟测试目的和测试策略也有关系，如进行主要功能测试还是验证性测试抑或详细测试等等）

再次，让其他测试同行和开发帮忙评审，查看功能检测点是否覆盖到。

最后，分析发现的bug（注意要关注bug质量而不是数量）

<!--[if !supportLists]-->b. <!--[endif]-->这里简单说下遗漏缺陷（遗漏缺陷也是覆盖率的一个侧面反映）搜集的方法（以下主要是进入到执行阶段后）

<!--[if !supportLists]-->a> <!--[endif]-->用户现场反馈；

<!--[if !supportLists]-->b> <!--[endif]-->一个项目多个Build测试时，后期发现的bug分析是否是测试用例未覆盖到，还是测试用例有但是之前测试人员未执行引起的；

<!--[if !supportLists]-->c> <!--[endif]-->交叉测试，不同的测试人员执行测试用例或者进行相关模块测试时的思维方式不同，可能会发现隐藏的功能之前的测试用例未覆盖到的情况。

以上是自己想到的测试用例有效性分析方法，测试用例有效性分析应该是一个综合各方面平衡的一个过程和活动。有些同行也用缺陷率来反映测试用例的有效性，如发现的总bug除以总测试用例数，一条测试用例发现的bug数，个人感觉这是不科学也不具有实用性，bug数的多少并不能真正反映测试用例的有效性，bug的质量、主要功能的覆盖以及使用的测试策略才应该是我们分析的基石。