测试人员应该怎样编写一份高质量的测试用例？

什么样的测试用例算好的测试用例呢?

1、不要以为“发现了软件缺陷的测试用例就是好的用例”

2、也不要以为“发现软件缺陷可能性大的测试用例就是好用例”

3、更不要以为“发现至今未被发现的软件缺陷的测试用例就是好用例”

其实，是你定义“好的”测试用例的思路错了，这就有点像“傻子吃烧饼”，连吃五个不饱，吃完第六个终于饱了，于是他说：早知道吃了第六个就会饱，何必吃前面五个呢。细想，他吃的六个烧饼其实是一个整体，一起吃下去才会饱，而你无法找到吃一个就能饱的“好”烧饼。

对于测试用例其实也是同样的道理，“好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而跟能否发现缺陷无关。

如果把被测试软件看作一个池塘，软件缺陷是池塘中的鱼，建立测试用例集的过程就像是在编织一张捕渔网。“好的”测试用例集就是一张能够覆盖整个池塘的大渔网，只要池塘里有鱼，这个大渔网就一定能把鱼给捞上来。

如果渔网本身是完整的且合格的，那么捞不到鱼，就证明池塘中没有鱼，而渔网的好坏与池塘中是否有鱼无关。

“好的”测试用例必须具备哪些特征?如何设计一个好的测试用例?

1. 整体完备性：“好的”测试用例一定是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求。

1. 等价类划分的准确性：指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。

1. 等价类集合的完备性：需要保证所有可能的边界值和边界条件都已经正确识别。

做到了以上三点，就可以肯定测试是充分且完备的，即做到了完整的测试需求覆盖。

从理论层面来讲，设计用例的方法有很多，如果你去翻阅测试图书或网络教程，会发现一堆让人眼花缭乱的测试方法，比如等价类划分法、边界值分析法、错误推测方法、因果图方法、判定表驱动分析法、正交实验设计方法、功能图分析方法、场景设计方法、形式化方法、扩展有限状态机方法等等，但是从软件企业实际的工程实践来讲，真正具有实用价值并且常用的只有前三种方法。

等价类划分方法

现在，我给你看一个具体的例子：学生信息系统中有一个“考试成绩”的输入项，成绩的取值范围是0~100之间的整数，考试成绩及格的分数线是60。

为了测试这个输入项，显然不可能用0~100的每一个数去测试。通过需求描述可以知道，输入0~59之间的任意整数，以及输入60~100之间的任意整数，去验证和揭露输入框的潜在缺陷可以看做是等价的。

那么这就可以在0~59和60~100之间各随机抽取一个整数来进行验证。这样的设计就构成了所谓的“有效等价类”。

你不要觉得进行到这里，已经完成了等价类划分的工作，因为等价类划分方法的另一个关键点是要找出所有“无效等价类”。显然，如果输入的成绩是负数，或者是大于100的数等都构成了“无效等价类”。

在考虑了无效等价类后，最终设计的测试用例为：

• 有效等价类1：0~59之间的任意整数;

• 有效等价类2：59~100之间的任意整数;

• 无效等价类1：小于0的负数;

• 无效等价类2：大于100的整数;

• 无效等价类3：0~100之间的任何浮点数;

• 无效等价类4：其他任意非数字字符。

边界值分析方法

边界值分析是对等价类划分的补充，你从工程实践经验中可以发现，大量的错误发生在输入输出的边界值上，所以需要对边界值进行重点测试，通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。

我们继续看学生信息系统中“考试成绩”的例子，选取的边界值数据应该包括：-1，0，1，59，60，61，99，100，101。

错误推测方法

错误推测方法是指基于对被测试软件系统设计的理解、过往经验以及个人直觉，推测出软件可能存在的缺陷，从而有针对性地设计测试用例的方法。这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，当然还有个人的能力。

错误推测法和目前非常流行的“探索式测试方法”的基本思想和理念是不谋而合的，这类方法在目前的敏捷开发模式下的投入产出比很高，因此被广泛应用。但是，这个方法的缺点也显而易见，那就是难以系统化，并且过度依赖个人能力。

比如，Web界面的GUI功能测试，需要考虑浏览器在有缓存和没有缓存下的表现;Web Service的API测试，需要考虑被测API所依赖的第三方API出错下的处理逻辑;对于代码级的单元测试，需要考虑被测函数的输入参数为空情况下的内部处理逻辑等等。由此可见，这些测试用例的设计都是基于曾经遇到的问题而进行的错误推测，很大程度上取决于个人能力。

在软件企业的具体实践中，为了降低对个人能力的依赖，通常会建立常见缺陷知识库，在测试设计的过程中，会使用缺陷知识库作为检查点列表(checklist)，去帮助优化补充测试用例的设计。

对于中小企业，可能最初的方法就是建立一个简单的wiki页面，让测试工程师完成测试用例的最初设计后对应这个wiki页面先做一轮自检，如果在后续测试中发现了新的点，就会继续完善这个wiki页面。

对于测试基础架构比较成熟的中大型软件企业，通常会以该缺陷知识库作为数据驱动测试的输入来自动生成部分的测试数据。

测试用例常识：

1.测试用例设计方法

等价类划分法

边界值分析法

因果图

决策表

正交试验

场景法

状态迁移

错误推测法

2.测试用例的组成元素

用例编号

用例标题

功能模块名称

前置条件

输入数据

操作步骤

预期结果

优先级

执行结果

编写人

执行人

以上元素在一个测试用例中并不是需要完全包括，但是像用例编号，用例标题，前置条件，输入数据，操作步骤，预期结果，优先级，执行结果则是每一条测试用例必要元素。

3.用例标题

• 字数不能太多

• 概括性-看到标题就能清楚这条用例测试点是什么

• 不能歧义性

4.测试用例的特点

• 步骤清晰

操作步骤要清楚明了，如果刚开始不知道怎么写，建议就按执行测试的步骤一步一步写清楚

例如现在有一个QQ登录成功的用例，操作步骤就可按如下写：

1.点击QQ应用程序

2.输入正确的用户名

3.输入正确的密码

4.点击登录

• 结果唯一

一条测试用例只允许有一个测试结果；一条测试用例只包含一个测试点；一条测试用例可以有多个检查点；预期结果中不要包含有歧义性或二义性的字

• 可操作性强

这一点主要体现在不同的测试人员在不同的测试平台上运行，最终的结果都是相同的

注意点：不管是用例标题还是预期结果，尽量不要使用含糊不清的语句