软件测试(4) 测试用例和设计方法

1 测试用例

1.1 测试用例的定义

• 设计一个情况，软件程序在这种情况下，必须能够正常运行并达到程序所设计的预期结果。
• 如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就表示软件程序人员已经测出软件有缺陷，这时候就必须将问题标识出来，并通知开发人员。软件开发人员接到通知后，将这个问题修改完成于下一个测试版本内。
• 软件测试人员取得新的测试版本后，必须利用同一个用例来测试上述出现的缺陷问题，确保该问题已修改完成。

测试用例模板：

测试用例编号	测试项	依赖用例	测试步骤	输入数据	预期结果	测试结果	测试人	备注

测试用例说明：

• 用例编号：一般编号规则：TestCase_项目名称_模块名称_功能名称_0001
• 测试项：测试用例的测试目的。一般情况下，用一句话表明目的。（表明测试模块、测试对象、方式、事件）。
• 依赖用例：一般功能流程上，下游的功能测试依赖于上游的功能测试的用例。
• 测试步骤：用最朴实的语言，写出来软件的操作步骤。要尽量详细。
• 测试数据：单独整合测试数据。必须和测试步骤中的数据保持一致。
• 预期结果：对象的准确，内容的准确。原则上每一个操作，都要有一个结果。在重要步骤之后，设定预期结果。一般和测试目的密切相关。
• 测试结果：要求在测试执行完成后添加。没有执行保持为空。测试结果只有两种：通过/失败；Pass/Failed。
• 测试人：测试的执行人。可以和设计者相同或不同。
• 备注：为了测试用例正常执行而做的特殊准备。

测试用例可以分为：功能（Function）、界面（UI）、性能（Performance）、安全（Security）、接口（Interface）

1.2 用例设计和编写的作用

• 有效性：测试用例是测试人员测试过程中的重要参考依据。
• 可复用性：良好的测试用例具有可重复使用的功能，提高测试效率。
• 易组织性：即使是小项目，也可能会有几千甚至更多的测试用例，测试用例可能数月甚至几年的测试过程中被创建和使用。
• 可评估性：从测试的项目管理角度来说，测试用例的通过率是检验代码质量的保证。
• 可管理性：测试用例也可以作为检验测试人员进度、工作量以及跟踪/管理测试人员的工作效率的标准。

2 测试用例编写注意事项

• 不要设计“穷举测试用例”
• 在详细测试用例与有效测试时间中找到平衡点
• 好的测试用例应该多关注“反向测试问题”
• 测试用例库应该不断更新和维护
• 测试用例可以复用，但要注意数据有效性与环境变化
• 测试用例是设计出来的，不是写出来的
• 多去学习经验丰富的测试工程师所设计的测试用例
• 针对不同的需求类型和测试对象，灵活采用不同的测试用例设计方法

3 黑盒测试用例设计方法

3.1 测试数据选择

等价类划分法

1. 原理：

• 把程序的输入域划分为若干部分，然后从每个部分中选取少量数 代表性数据作为测试用例
• 每一类的代表性数据在测试中的作用等价于这一类中其他值，如果某一类中的一个数据发现错误，那么这一等价类中的其他例子也能发现同样的错误
• 反之，如果某一类中的一个数据没有发现错误，则这一类中的其他数据也不会发现错误

2. 步骤：

（1）确定等价类原则：

• 输入条件给出取值范围或值的个数时，可以确定一个有效等价类和两个无效等价类
• 输入条件给出输入值的集合或规定 “必须如何让”的条件时，可以确定一个有效等价类和一个无效等价类
• 输入条件为布尔量时，可确定一个有效等价类和一个无效等价类
• 规定输入值为一组（若为n个），并且程序要对每一个输入值分别处理时，可确定n个等价有效类和一个无效等价类
• 规定了输入数据必须遵守的规则时，可确定一个等价有效类（符合规则）和若干个无效等价类（从不同角度违反规则）
• 在已知划分的等价类中，各元素在程序中处理方式不同时，应该将该等价类进一步划分为更小的等价类

（2）划分等价类和列出等价类表：

• 有效等价类
• 无效等价类

（3）确定测试用例

• 为每个等价类规定一个唯一编号。
• 设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例覆盖。 设计一个新的测试用例，使其覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖。

以百度注册页面为例进行分析：
用户名：设置后不可更改；中英文均可；最多14个英文或7个汉字；
（隐性条件：用户名不可重复；不可为空；）

• 将等价类划分组成表格分析：

	有效等价类	数据	无效等价类	数据
	中文、英文	yY哈哈	数字、特殊符号	123456
	14个英文	YyDddd	英文超过14个	qwertyuiopasdfgh
	7个中文	羊羊	中文超过7个	哈哈哈哈哈哈哈哈哈
	不能为空	YYY	空
	不能重复	咩咩羊	使用重复数据测试

• 编写测试用例：
  

边界值分析法

1. 原则

• 如果输入条件规定了值的范围，则应取刚达到这个范围的值，以及刚刚超过这个范围边界的值作为测试输入数据。
• 如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1的数作为测试数据
• 分析规格说明，找出其他可能的边界条件。根据规格说明，使用上两条
• 如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例
• 如果程序中使用了一个内部数据结构，则应该选择这个内部数据结构边界上的值作为测试用例
  
  边界值只是一个特定的数据。例如文本框需要输入6到18位字符。边界值有：1）6个字符；2）18个字符。
  次边界：边界附近的值，按照系统规定的单位或者计算方式，一个数据的差异。

举例： 1）6≤x≤12，测试中x的边界值要选取哪几个值进行测试？
5，6，7，11，12，13
2）6＜x＜12，测试中x的边界值要选取哪几个值进行测试？
6，7，11，12

---

实战案例

• 一个程序读入3个整数，把这3个数值看作是一个三角形的3条边的长度值。
• 这个程序会给出弹窗提示信息，说明这个三角形是普通的、是等腰的、是直角的、还是等变的，以及相应的错误提示信息。
• 等价类划分
  
• 测试用例
  

3.2 测试步骤设计

因果图法

• 因果图法是一种适合于描述对于多种输入条件组合的测试方法；
• 根据输入条件的组合、约束关系和输出调价的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法
• 适合于检查程序输入条件涉及的各种组合情况

• 画图步骤
  step1： 根据功能说明书中规定的原因结果之间的关系画出因果图

• 原因和结果的关系
  恒等：原因A成立，结果B一定成立
  非：原因A成立，结果B一定不成立
  或：原因A、B、C三者只要一个成立，结果D一定成立
  与：原因A、B、C三者都成立，结果D成立

step2： 根据功能说明在因果图中加上约束条件

假如原因成立用1表示，不成立用0表示，则

• 原因之间的约束：
  互斥（exclusive）：不同时为1，即A+B+C≤1
  包含（include）：至少一个为1，即 1≤A+B+C≤3
  唯一（only）：有且仅有一个为1，即A+B+C=1
  要求（request）：原因B成立，要求A先成立
• 结果之间的约束：
  屏蔽（mask）：结果A出现，结果B一定不出现，即A=1，则B=0。例如：提示注册账号成功时，就一定不会收到数据填写错误的提示。

• 因果图使用实例
  有一个饮料自动售货机（处理单价为5角钱）的控制处理软件，它的软件规格说明如下：

  • 若投入5角钱的硬币，按下“橙汁”或“啤酒”的按钮，则相应的饮料就送出来
  • 若投入1元钱 的硬币，同样也是按“橙汁”或“啤酒”的按钮，则自动售货机在送出相应饮料的同时退回5角钱硬币。

  阅读和分析功能说明书，识别出“原因”和“结果”，并加以编号。

第一步：分析原因和结果；
第二步：画出原因和结果之间的关系；
第三步：根据需求描述原因、结果间的约束；

因果图使用中的局限性： 当原因和结果很多时，他们之间的关系连线就会很多，导致因果图可读性变差。因此常用于局部小功能（原因和结果不多）分析。

第四步：列出所有原因和结果的列表，设计初步的测试用例步骤；

C5是一种bug，不能做测试设计。
经分析发现：
1）只选择饮料，没有投币时，软件没有任何结果。
2）只投币，没有选择饮料的时候，软件没有任何结果。
3）不能把软件的缺陷设计成测试用例。

因果图优势在于能够发现设计中存在的不足。

第五步：写测试用例。

---

判定表法

判定表法是分析和表达多逻辑条件下执行不同操作的情况工具。主要适用于多条件的内容组合与结果分析。它由以下几个内容组成：

• 条件桩（Condition Stub）：列出了问题的所有条件。通常认为列出条件的次序无关紧要。
• 动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排序顺序没有约束。
• 条件项（Condition Entry）：列出针对它所列条件的取值。在所有可能情况下的真（1）假（0）值。
• 动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。
  使用条件： 所有的条件桩在表中的位置和顺序互不影响；所有的动作桩的顺序不会因为条件顺序的变化而产生不同。
  实现步骤：
  1）识别出 操作条件（原因）和对应的动作（结果）；
  2）分析条件的条件项（组合数量）：如果有n个条件，每个条件有成立和不成立两种情况，那么最后一共会有2ⁿ个数量；
  3）简化和优化结果，排除一些不可能存在的情况。

判定表使用实例1
需求：订购单的检查

• 如果金额超过500元，又未过期，则发出批准单和提货单；
• 如果金额超过500元，但过期了，则不发批准单；
• 如果金额低于500元，则不论是否过期都发出批准单和提货单，在过期的情况下还需要发出通知单。

第一步：分析条件桩和动作桩、条件项和动作项

条件1	条件2	动作
金额＞500	未过期	发出批准单和提货单
金额＞500	过期	不发批准单，发提货单
金额≤500	未过期	发出批准单和提货单
金额≤500	过期	发出批准单、提货单和通知单

金额超过500	时效过期	批准单	提货单	通知单
0	0	1	1	0
0	1	1	1	1
1	0	1	1	0
1	1	0	1	0

第二步：列出条件桩、动作桩、条件项、动作项

第三步：对判定表进行简化和优化
由上表看出，只要未过期，就会发批准单、提货单。（在测试时间不充足的情况下，可以选择二者中的一个情况测试）

第四步：将判定表中的每一列（条件项和对应的动作项）作为测试用例的数据、操作以及对应的的预期结果

判定表使用实例2

该判定表为某杂志的阅读指南判定，指导读者能够良性阅读。请对该判定表进行优化，将重复内容去掉，并说明原因。
1）合并1，2，3，4。只要疲倦就休息
2）合并7，8.只要疲倦且不感兴趣就跳下一章

---

场景法

• 原理
  • 现在的软件几乎都是用事件触发来控制流程的。测试时，可以生动地描绘出事件触发时地情景，有利于设计测试用例，同时使测试用例更容易理解和执行。
  • 基本流：软件功能按照正确的事件流实现的一条正确流程。通常一个业务仅存在一个基本流，且基本流仅有一个起点和终点。（软件功能正确实现的流程）
  • 备选流：除了基本流之外的各种支流，包含多种不同的情况。（基本功能流程之外的过程）
    
• 场景设计：
  • 场景1：基本流
  • 场景2：基本流 备选流1
  • 场景3：基本流 备选流2
  • 场景4：基本流 备选流1 备选流2
  • ……
• 设计用例的步骤
  • 根据说明，描述程序的基本流及各项备选流
  • 根据基本流和各项备选流生成不同的场景
  • 对每一个场景生成相应的测试用例
  • 对生成的所有测试用例重新复审，去掉多余的测试用例
  • 测试用例确定后，对每一个测试用例确定测试数据值

案例：ATM机的取款流程
基本流：