测试用例（Test Case）是为实施测试而向被测系统提供的输入数据、操作或各种环境设置以及期望结果等信息的一个特定集合。测试用例要解决的问题是：要测什么，怎么测，如何衡量。如果不写测试用例的话，就无法判断是否较全面地测试了所有的功能；测试的覆盖率也无法衡量；对新版本的重复测试很难实施；无法对测试质量进行有效评估；无法形成有效的知识积累。

测试用例可以证明被测软件的某功能符合需求说明书中规定的要求，我们的测试首先要符合需求规格说明书；可以保证一个软件被测试的有效性；指导测试的工作，不至于盲目测试；可以为评估测试结果和编写测试报告提供依据。

一个好的测试用例应该符合以下几个特性：

有效性：是测试人员测试过程中的重要参考依据。
可复用性：良好的测试用例具有重复使用的功能，使得测试过程事半功倍。
易组织性：可能在数月甚至几年的测试过程中被创建和使用，正确的测试计划会很好地组织这些测试用例 。
可评估性：从测试的项目管理角度来说，测试用例的通过率是检验代码质量的保证。
可管理性：可以作为检验测试人员进度、工作量以及跟踪／管理测试人员的工作效率的因素 。

测试用例编写的原则主要有对需求覆盖的完整性、有效性、可理解性、清晰性、可维护性，下面我们针对这几个方面展开来讲一下。
对需求覆盖的完整性就要求我们做到对需求的完全理解, 从全局上把握需求。还应对需求进行归类，做到对需求的100%覆盖。
有效性指的是测试用例应该包含清晰的输入数据以及预期输出。如果环境或者业务发生变更后，测试用例及相关数据必须进行更新维护。
测试用例的可理解性，这一点很重要，它要求测试用例步骤必须描述清晰，使用陈述句，不能出现模棱两可以及重复的话语或者夹杂个人情绪。测试用例要按照一定的顺序进行编写，这样执行的时候效率比较高。

清晰性，测试用例的验证点必须明确清晰重点突出，一个用例进行一个功能点的验证。测试用例包含前置条件的必须描述清楚，包括入口等。因为我们一些比较小的项目可能是专门有一个人写用例，一个人去执行测试，一些比较大的项目可能还会有专门编写测试用例的组。所以测试用例的清晰性和可理解性都会直接影响到测试人员的效率。

可维护性，测试用例因为业务需求发生变更的时候，需要及时更新维护测试用例，做到测试用例的实时性与有效性。测试用例需要细化和不断的完善，是个循序渐进的过程。通过测试实践检验测试用例并添加，删除，修改测试用例。

测试用例应该按照一定的顺序进行编写，这样执行的时候效率比较高。
因为我们在写测试用例的时候，可能是依据文档，或者根据以往经验来编写的，在测试执行的时候，可能会发现有遗漏的地方，或者我们的软件、业务、需求发生变更的时候，都需要对我们的用例进行维护，所以我们的测试用例需要具有可维护性。
测试用例的编写是非常重要的，它直接影响到下面一个环节，测试执行环节。无论是我们自己执行还是其他的测试人员、测试组去执行这个测试用例，都需要测试用例是完整、有效、可理解、清晰和可维护的，以上就是测试用例的特点。下面我们就一起来看一下测试用例的设计方法。

黑盒测试用例设计方法

下面我们将要讲到的内容是测试用例书写的灵魂，是编写测试用例的设计理念，这一部分是比较重要的。

黑盒测试（Black-box Testing)，又称为功能测试或数据驱动测试,是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。
大家都知道，黑盒就是把一个软件/被测的一个功能/产品功能/软件功能/系统功能都看成一个黑匣子，然后输入内容，得到一个输出内容，我们并不需要知道它的内部结构或者处理的过程，只要知道输入和输出对了就可以了。

黑盒测试行常见的测试方法主要有以下几大类，等价类划分方法、边界值分析方法、错误推测方法、因果图方法、场景法。它不限于这几项，我们列举的是现在比较常用的一些方法。

等价类划分法

等价类划分法是指依据需求对输入的范围进行分类，然后在分出的每一个区域内选取一个有代表性的测试数据开展测试。

等价类划分法是比较容易理解的，我们现在设计测试用例用等价类划分法比较多，它适用的场景也比较多。

我们为什么使用等价类划分法呢？是因为我们的穷举测试是根本穷举不完的，所以我们要把它进行分类，取一些有代表性的数据，就产生等价类了。做完合理的分类之后就可以设计测试用例了，它适合于任何一个测试过程，不受局限。

等价类划分法的划分方法

等价类是指某个输入域的子集合。分为有效等价类和无效等价类。

有效等价类 : 符合需求说明，合理地输入数据集合
无效等价类 : 不符合需求说明，无意义地输入数据集合
我们也可以把无效等价类看作反向用例，也可以看作在健壮性测试时我们设计的一个测试用例。有效等价类是用来验证需求的，无效等价类是用来经受考验的。

等价类划分法的步骤

简单来说就是，划分等价类，把有效等价类和无效等价类划分出来，然后建立图表并编号，然后再设计用例。
下面我们介绍一下等价类划分法常用的几种方法。

等价类划分法常用方法1
在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。
例如：输入值是学生成绩，范围是0～100。
分析：
有效等价类：0≤成绩≤100
无效等价类：成绩＜0 或 成绩＞100
在数轴上表示：

等价类划分法常用方法2
在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类。
例如：某系统注册页面用户密码规定为4位的串。
分析：
有效等价类：长度为4位的串
无效等价类：长度不是4位的串
等价类划分法常用方法3

在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。
例如：某系统注册时，性别输入必须为男（true）。
分析：
有效等价类：输入true
无效等价类：输入false

等价类划分法常用方法4

在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。
例如：某校员工管理系统对老师工资进行维护，按老师学历（博士、研究生、本科与专科）设置基本工资。
分析：
有效等价类：学历取博士、研究生、本科与专科
无效等价类：其他学历均为无效等价类

等价类划分法常用方法5

在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则） 。
例如：某系统注册时用户名必须以“a”字母开头。
分析：
有效等价类：字母a开头的用户名
无效等价类：字母b开头的用户名、数字2开头的用户名等等

等价类划分法常用方法6
在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。
例如：某系统注册时用户名必须以字母开头，并且必须包含数字。
分析：
有效等价类：字母开头且含有数字（有效，如a1），字母开头且不含数字（无效，如a）
无效等价类：非字母开头的，如数字开头（1a）等

等价类划分法举例
我们针对等价类划分法举一个例子，QQ账号为5-11位自然数，请用等价类划分方法设计测试用例。界面原型如下：

第一步：确定并划分等价类：
有效等价类：5-11位，类型是自然数
无效等价类：小于5位，大于11位，非自然数
第二步：建等价类表并编号

第三步：设计测试用例

我们按照前面划分的等价类就可以生成9个测试用例，如果我们不按照等价类划分法这一系列的步骤来执行的话，设计的用例就可能会有遗漏。

边界值分析（boundary value analysis）

接下来我们来介绍一下第二大常用的方法，边界值分析法。

由于程序的错误经常在定义域和等价类的边界处被发现，所以在等价类分析还应该对于每个测试的变量加上边界值的分析。
一般情况下我们会设计5组边界值，取一个中间值，一个最小值，一个最大值，一个略小于最小值，一个略大于最大值。

边界值分析法与等价类的关系：
边界值分析假定错误存在于划分的边界上，因此在等价类的边界上以及两侧的情况设计测试用例。

边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。


如何设计边界值测试用例：
首先确定边界情况，通常输入或输出等价类的边界就是应该着重测试的边界情况。
正常选取（正向）：最小值、略高于最小值、正常值、略低于最大值和最大值处变量值。
健壮性测试（反向）：还需考虑小于最小值，大于最大值
例如，在某程序的需求规格说明中，对输入条件的限制为：
“…… 年龄可以输入从15到60的整数 ……”
边界值正常用例分析：输入应选择15、16、30、59、60

同时我们还要考虑它的健壮性或者容错性，就需要设置健壮测试（反向用例），一个是小于最小值，一个是大于最大值，所以输入还需考虑：14、61

常见的边界值：
并不是所有的值都需要考虑边界值，通常情况下，软件测试所包含的边界检验有几种类型：数字、字符、位置、质量、大小、速度、方位、尺寸、空间等。
相应的，以上类型的边界值应该在：
最大/最小、首位/末位、上/下、最快/最慢、最高/最低、最长/最短、空和满等情况
一旦我们的需求说明书里对这些方面有相关的描述的时候，就一定要考虑，这个时候是不是需要增加边界值的测试。

下面这个图是边界值分析的取值，我们前面也讲了，正常选取（正向）包括五种：最小值、略高于最小值、正常值、略低于最大值和最大值处变量值。健壮性测试（反向）：还需考虑小于最小值，大于最大值。

边界值分析法常用方法

边界值分析法常用方法1：

如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。(中间正常的再取一位)

例如，如果程序的规格说明中规定：“重量在10公斤至50公斤范围内的邮件，其邮费计算公式为……”。

分析：设计测试用例时，我们应取边界是10~50，还应取9,10,11,30,49,50,51

边界值分析法常用方法2：

如果输入条件规定了值的个数,则用最大个数，最小个数，比最小个数少一,比最大个数多一的数作为测试数据。

例如：一个输入文件应包括1~255个记录，则测试用例可取1和255，还应取0及256等。

边界值分析法常用方法3：

将方法1和方法2应用于输出条件，即设计测试用例使输出值达到边界值及其左右的值。

例如，某程序的规格说明要求计算出“每月保险金扣除额为0至1165.25元”，其测试用例输出考虑0.01及1165.24、还要考虑-0.01及1165.26。
再如一程序属于情报检索系统，要求每次”最少输出1条、最多输出4条情报摘要”，这时我们应考虑的测试用例的输出包括1和4，还应包括0和5等

边界值分析法常用方法4：

如果程序的规格说明给出的输入域或输出域是有序集合（如有序表、顺序文件等），则应选取集合的第一个元素和最后一个元素作为测试用例。
边界值分析法常用方法5：

分析规格说明，找出其它可能的边界条件。

边界值分析法举例

请用边界值分析方法为NextDate函数设计测试用例，规定了变量month和变量day的取值范围为1≤month≤12和1≤day≤31，并设定变量year的取值范围为1912≤year ≤2050 。

第一步：确定边界值：month为1-12，day为1-31，year为1912-2050
第二步：设计测试用例（假设中间值year=2000，month=6，day=15）
第三部：健壮考虑，month<1或>12，day<1或>31，year<1912或>2050

测试用例如下表所示：

错误推测法

错误推测法是基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。带有破坏性的输入错误的值或方法去进行测试，如果程序要求输入数字，那么我们就输入特殊字符，如果软件只接受正数，我们就输入负数。
例如：输入数据和输出数据为0的情况；
输入表格为空格
输入超长字符
删除全部数据或记录为空的情况
......
这个方法没有太大的规律，就是靠经验和直觉，我们做测试工作时间长了，就可以积累出这方面的能力了。

例如：如对某个公司的销售工作人员某一天的销售额进行排序。可推测列出以下几项需要特别的测试的情况：
分析：
当天所有销售工作人员均无销售额；
当天所有销售工作人员只有一人有销售额；
当天所有销售工作人员的销售额均相同；
当天销售额均已升序排列好；
当天销售额均已降序排列好。

因果图法

这种方法是有适用条件的，不是所有的场景都可以用这种方法的。它是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。
等价类划分方法和边界值分析方法，都未过多考虑输入条件之间的联系，相互组合、相互制约等。

考虑输入条件间的相互组合不是一件易事, 即使把所有输入条件划分成等价类，他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图（ Cause一Effect Graphics ）方法。

采用因果图方法能够帮助我们按一定步骤，高效率地选择测试用例，同时还能为我们指出，程序规格说明描述中存在着什么问题。

步骤：
1、提取因和果，赋予标识符：根据软件规格说明书分析并确定因（输入条件）和果（输出结果），并给每个因和果赋予一个标识符。

2、提取因果关系，标识因果：分析软件规格说明书，提取因果关系，根据这些关系，画出因果图。

3、标明约束条件：由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现，为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件。

4、转换成判定表：把因果转换为判定表。

5、设计测试用例：把判定表的每一列拿出来作为依据，设计测试用例。

例1：某软件规格说明要求：第一列字符必须是A或B，第二列必须是一个数字，在此情况下进行文件修改，但如果第一列字符不正确，则给出信息L；如果第二列字符不是数字，则给出信息M。
分析：第一步：确定因果关系，画出因果图

注：⑤是中间过程， ①和②不能同时满足，所以用⑤来施加约束

第二步：因果图转判定表

场景法

场景法也就是事件流，现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。流，是指一系列的步骤。
一般情况下我们会分基本流和备选流，所谓的基本流是能够顺利执行的一个场景，从开始到结束一切都顺利的场景。备选流是指除基本流之外的另外一些正常场景、偶尔发生的场景、异常或错误处理。

基本流和备选流如下图所示：

图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。

备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。

设计测试用例的步骤：
1、确定基本流和备选流
2、根据已确定的基本流和各项备选流生成不同的场景
3、为确定的场景生成相应的测试用例
4、复审和验证测试用例，取消多余和等效的。


例1：ATM取款测试的场景设计方法。

第一步：确定基本流和备选流

第二步：根据基本流和备选流确定场景

第三步：根据场景设计测试用例

测试用例的内容

一个测试用例需要包含：对一个特定的测试对象（test object）在规定的条件或环境下（前置条件和后置条件）输入一组输入数据或执行操作步骤后，生成一组相应的期望的结果。
测试用例=〈输入数据+，期望的结果+，测试对象，边界条件*〉
这些因素就组合成了一个测试用例。我们的测试用例分为逻辑测试用例和具体测试用例。逻辑测试用例没有具体的数据的描述，它是对测试数据的抽象描述。具体测试用例是对测试数据的具体化，具体的测试用例对于我们后续的回归有非常重要的作用。

下表是定义一个测试用例所需的项：

其实我个人认为，这里面还应该包含测试用例的设计方法，比如说我们这个测试用例是用等价类划分法设计的？还是边界值法设计的？如果加上这样一列的话，可以起到更加有效的说明作用。
这个也是看要求的，像比较大型的如金融行业，对用例要求比较精准的情况下，我们就要标注这个测试用例的设计方法。
为了方便追溯，测试用例还应该包含编写人是谁，执行人是谁。

如果测试用例的内容是一个可执行的序列，我们称之为测试套件（“手动测试脚本”）

下面是一个测试用例模板的举例，这是一个比较通用的测试用例的模版，包含编号、模块、功能、测试需求、正向还是反向用例、测试步骤、预期结果、实际结果、如果实际结果和预期结果不符，就是一个缺陷，我们后面还会讲，如何精准地把这个缺陷描述给开发人员。开发人员进行bug修复之后，我们就可以有一个再测试影响分析以及执行结果。最后为了可追溯性，会有一个编写人和执行人。

测试用例编写常见问题

接下来我们一起来看一下测试用例编写中存在的问题，这里我简单列举了一下：
测试用例虽有步骤，但太过简单，且缺少测试数据，导致该用例无法执行，没有可用性。我们的测试步骤里面要尽量明确测试数据，是精准的数据，还是模糊的抽象数据，这点对于编写人员、执行人员、包括后面的回归人员来说都是非常重要的，所以希望大家在设计测试用例的时候要准备无误、全面地来设计。

测试用例步骤描述不清晰，过于冗余。像下图的例子，当你这个用例写完了之后，交给执行人员看，如果你执行100条数据都这样写的话，这个时候执行人员是很懵的。

这个是我们曾经做过的一个简单的测试用例，如果测试不同过的话，我们会标红，然后写到缺陷里面去，大家可以参考。

我们今后书写测试用例的时候要注意哪些事项呢？通过前面的一些分析，大家也看出来了一些好与坏的差距，最后我们再总结一下它的注意事项：
1、正确性：
设计的测试用例保证至少覆盖需求规格说明书内容、计划任务书内容、或测试文档内容。不要没有任何文档依据，简单测测。
2、完整性：
对测试依据文档进行全面覆盖，尽可能地测试的完整和充分，尽量避免未被测试用例设计到地潜在bug。
3、全面性：
设计的测试用例尽可能地全面，多角度去考虑问题；尽量做到测试用例的各要素完整全面，且尽量包含必要地测试数据和步骤。
4、清晰简洁：
书写地测试用例尽量描述清晰，每一步都应有相应，有很强的针对性，不应出现一些无用的操作步骤。
5、可重用性：
书写完测试用例，自己可以想一下，其他的测试人员，在同样的测试环境下使用该的测试用例是否都能得出相应的结论。

以上就是我们为大家整理的功能测试的方法、步骤和内容，后面的文章会继续为大家分享缺陷分析技巧等内容，欢迎大家继续关注。

更多推荐：