【软件测试】测试用例的设计方法

一、 测试用例的评价标准

• 用例表达清楚，无二义性。
• 用例可操作性强。
• 用例的输入与输出明确。一条用例只有一个预期结果。
• 用例的可维护性好。
• 用例对需求的覆盖率高。

二、测试用例的设计方法

1. 基于需求进行测试用例的设计

基于需求设计测试用例是测试设计和开发测试用例的基础。

1. 第一步先分析测试需求，验证需求是否正确、完整、无二义性，并且逻辑自洽。
2. 在需求正确的基础上细化测试需求，从测试需求提炼出一个个测试点或者测试项，然后根据每一个测试点进行测试用例的设计。

在分析测试需求时，一般分为功能测试需求和非功能测试需求

---

Ⅰ. 功能需求测试分析

针对具体的需求，可以根据：「业务类型」「用户角色」（餐厅的会员系统）「用户操作区域」等将系统的功能，分解成若干个功能模块，然后按照功能模块进行测试需求分析。

• 对于功能测试中，可以借助「功能框图」来帮助我们进行测试的需求分析。
• 也可以采用思维导图的方式，更为方便，有效，也可以更好的支持测试分析思路的连贯性。

实例：对日历根据Web界面的功能布局分析出的功能框图如下：

概括起来，功能测试需求通常包括以下几个方面：

• 系统各个功能界面的验证
• 借助业务把功能串起来进行测试
• 功能的一致性，交互性（多功能互操作）的测试
• 系统的不同输入，结果输出的业务数据测试。
• 功能的错误操作，异常操作的测试（属于负面测试）
• 功能实现用到的算法验证，有时需要用运代码评审
• 用户操作的易用性，用户体验，往往结合功能测试同时验证

Ⅱ. 非功能需求测试分析

非功能测试需求主要涉及性能，安全性，可靠性，兼容性，易维护性和可移植性等。
从测试需求分析来看，每一类非功能特性测试都需要根据需求单独分析，他们之间可能会存在相互影响，如安全性越高，就越有可能给易用性，性能带来更大的挑战。

这里要说明的是对于每一个应用软件系统，非功能特性的质量需求都是存在的，但是不同的项目类型对各个非功能特性的要求是不一样的，这个需要根据具体的项目、具体需求和不同产品应用的特点进行分析。

• 纯客户端软件，比如办公软件（Word，PPT)，媒体（音频/视频）播放软件（电脑自带的）等。这类软件对系统的功能测试要求是最低的，但是对兼容性和稳定性，可移植性有一定的要求。

• 企业内部的客户端/服务端（C/S)应用系统。比如电子邮件，即时通信系统（飞书，企业微信）等，在系统功能测试需求上比纯客户端复杂，要求功能正确，稳定性能好。但是整体上看，对性能，安全性，兼容性要求不高。

• 外部大型复杂网络应用系统，比如电子商务，网上银行，视频网站（腾讯，优酷）等，除了有复杂的系统的功能测试需求外，在系统的性能，安全性，兼容性，容错性，可靠性等都有很高的要求。

此外，对于大型企业级应用系统，由于应用模式，系统架构的不同（分布式，微服务等），我们必须结合架构和应用模式来具体分析非功能性测试需求，特别是可扩展性，可靠性，安全性等。技术架构对功能的影响小，但是非功能性测试就要深入架构分析，才能更好的把我测试范围和测试方法。

下面是以我们常用的百度云盘手机端为例进行分析并设计测试用例：

2. 具体的设计方法

Ⅰ.等价类

等价类通过将输入数据划分为不同的等价类，从每个类中选择代表性测试用例来覆盖所有可能的情况，这种方法能有效减少测试用例的数量并提高测试效率。

• 有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能
• 无效等价类：根据需求说明书，不满足需求的集合。

---

场景：
假设我们有一个需求，判断线段的长度是否在10 - 25cm，它接受一个浮点数作为输入，并返回布尔值。
这种情况下输入的集合是所有可能的浮点数（这种情况下输入的集合是无穷的，不能全都覆盖到），我们可以使用等价类划分来简化测试用例设计。

在本例中：

• 有效等价类：[10, 25]
• 无效等价类 ： (负无穷， 10） (25, 正无穷）

---

等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充。

Ⅱ. 边界值

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

边界值分析法中有三种点，找到了这三种点就掌握了边界值分析法：

• 上点： 边界上的点
• 内点：边界内的点
• 离点：边界外的点(闭区间找区间外最近的点，开区间在区间内找最近的点)

例如还是上面的例子，只不过这次我们给的数据要求要在[10, 25) 之间，那么其上点，内点，离点，如下。

• 上点： 10， 25
• 内点： 18（也可以是其他边界内的值）
• 离点： 9， 25

Ⅲ. 因果图

因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。因果图法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。

因果图符号

因果图法设计测试用例的步骤如下。

1. 分析所有可能的输入和可能的输出。
2. 找出输入与输出之间的对应关系。
3. 画出因果图。
4. 把因果图转换成判定表。
5. 把判定表对应到每一个测试用例。

案例一：
假设业务单据的处理规则为：“淘宝618活动，订单已提交，订单合计金额大于300元或有红包，则进行优惠”。

1. 对于这条业务规则，首先通过分析所有可能的输入和可能的输出，可以得到如下结果：

• 输入：订单已提交、金额大于300、有红包。
• 输出：优惠、不优惠。

2. 然后，进行第二步，找出输入与输出之间的对应关系。通过分析，可以看出有以下的对应关系。

• 订单已提交，订单金额大于300元，则优惠。
• 订单已提交，订单金额小于等于300元，无红包，不优惠
• 订单已提交，有红包，则优惠。
• 订单已提交，订单金额大于300元，有红包，则优惠。
• 订单未提交，不优惠。

3. 为了方便画出因果图和判定表，需要对所有输入和输出编号，现在编号如下。
   1：订单已提交。
   2：订单金额大于300元。
   3：有红包
   21：优惠
   22：不优惠
4. 画因果图

5. 画判定表：有3个条件,输出有2个取值，所以表的列数为2x2x2=8

6. 最终的测试用例: 1，2，3，4，5，6，7，8

Ⅳ. 正交排列

对于因果法，当条件较多时会导致设计用例太多，为了用尽量少的用例覆盖输入的两两组合，有了正交法，正交法的目的是为了减少用例数目。

正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。正交试验设计是一种基于正交表的、高效率、快速、经济的试验。

---

下面是正交表中的一些专有名词：

• 因素（Factor）：在一项试验中，欲考察的变量称为因素（变量）。
• 水平（Level)：在试验范围内，因素被考察的值称为水平（变量的取值）

正交表的构成：

• 行数(Runs)：正交表中的行的个数，即试验的次数,用N代表。
• 因素数(Factors)：正交表中列的个数，用C代表。
• 水平数(Levels)：任何单个因素能够取得的值的最大个数。正交表中的包含的值为从0到数“水平数-1”或从1到“水平数”，用T代表。

正交表的表示形式： L=行数(水平数*因素数) L=N(TC)

例如下面的一个示例：
L₈(2⁷)，8 表示正交表中有 8 行，即安排试验的次数为 8 次；7 表示正交表中有 7 列，试验至多可安排 7 个因素（包括交互作用的因素）；2 表示每个因素只有两个水平值。

正交表的两条性质：

• 每一列中各数字出现的次数都一样多。
• 任何两列中的各有序数对出现的次数都一样多。

---

正交法设计测试用例的步骤：

1. 理解需求
2. 确定因素和水平
3. 画正交表
4. 补充正交表（加上你认为可疑且没有在表中出现的用例组合）
5. 将正交表转换为测试用例（正交表除了表头行以外，每一行都是一个测试用例）

---

案例：
以注册为例：姓名、邮箱、密码、确认密码、验证码必须全部输入，才能进行注册。

1. 因素：姓名、邮箱、密码、确认密码、验证码。
2. 水平：填写、不填写。

这里画正交表我们采用一个自动生成工具——allpairs，其使用方法可以看这篇文章正交表测试用例自动生成工具–Allpairs的使用

我们先准备一个txt文件，然后按照下面的格式填写因素和水平值：

然后使用命令行进行生成正交表，生成以后我们保留下面的主要部分就可以了。

注意，其中~表示这个给值既可以是「填写」也可以是「不填写」。

Ⅴ. 场景设计法

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，使测试用例更容易理解和执行。

典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。

案例：注册为例

想象注册的场景来设计用例，这与根据需求的业务流来设计差不多，主要是想象各种业务流来设计用例。
例如我们可以再想象以下场景：

1. 用户激活后再次点击邮件激活链接。
2. 已注册用户再次注册。

Ⅵ. 错误猜测法

错误猜测法是对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。

这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。
错误推测法和目前流行的“探索式测试方法”的基本思想一致，这类方法在敏捷开发模式下的投入产出比很高，被广泛应运于测试。

这个方法的缺点是难以系统化，并且过度依赖个人能力。

以注册为例:

1. 校验中特殊字符空格的处理?
2. 密码校验中的大小写？
3. 姓名中的特殊字符？
4. 密码发送是否明文?

三、测试用例的粒度和评价

一个好的测试用例：一个不熟悉业务的人也能依据用例来很快的进行测试

1. 测试用例的粒度

指测试用例编写的详细程度。

测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。

而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法， 具体到界面元素的操作步骤，指定测试的方法和工具等。

1. 测试用例写得过于复杂或详细，会带来两个问题：一个是效率问题，另一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。
2. 测试用例写得过于简单，则可能失去了测试周例的意义。过于简单的测试用例设计其实并没有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。

大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。

主要考虑可以参考如下内容：

• 产品的质量要求
• 项目对用例的要求
• 测试时间和资源是否充分

2. 测试用例的评价

测试用例设计出来了，如何提高测试用例设计的质量？就像软件产品需要通过各种手段来保证质量一样，测试用例的质量保证也需要综合使用各种手段和方法。评审分为正式和非正式评审。

• 同行评审
• 用户检查
• 项目组评审

1. 测试用例的检查可以有多种方式，但是最敏捷的应当属临时的同行评审。同行评审，尤其是临时的同行评审，应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例。
2. 除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让用户参与评审，从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛，关键在于如何定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场人员或领域专家）；如果测试是被定义为对开发提供帮助和支持，那么顾客显然就是程序员了。
3. 由测试负责人组织协调开展会议，用例编写人对用例进行讲解，参会人员有异议的当场提出。