测试用例理论

测试用例的定义

什么是测试用例：

它是每个业务目标，用编制的一组由测试输入，执行条件以及预期结果的案例

测试用例的好处及作用：

在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。

测试用例的使用令软件测试的实施重点突出、目的明确。

在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。

检验软件是否满足客户需求、体现一个测试人员的工作量、展现测试用例的设计思路.

测试用例的4个特性

代表性：能够代表并覆盖各种合理的和不合理、合法的和不合法、边界和越界以及极限的输入数据、操作等。

针对性：对程序中的可能存在错误有针对性的测试

可判定性：测试执行结果的正确性是可判定性，每一个测试用例都应有相应的结果

可重现性：对同样的测试用例，系统的执行结果应当是相同的。

测试用例通常包括以下几个组成元素：

测试用例模板

用例编号、测试模块、用例标题、用例级别、前置条件、测试输入、执行输入、预期结果、实际结果、测试人员、结束时间

测试报告模板

测试目标、测试依据、测试范围、测试环境、测试进度、执行结果、缺陷分布、遗留缺陷、测试结论、建议、附录…

常见黑盒测试用例设计方法

等价类

方法：根据需求列出输入，并对每一个输入的规则进行分析，然后对每一条规则进行正确和错误的罗列，最后将的所有的输入进行正确和错误用例的组合，一条正确的用例尽可能多的覆盖每个输入的不同有效数据，一条错误的用例只能含有一个无效数据（控制变量）。 对于一个输入应考虑它的：数据类型、长度、取值范围、是否可重复，是否为空（为空可分为不输入和输入空格），组成规则等内容 。

优点：简单高效，能快速评估测试用例数量；

缺点：只考虑了输入的有效和无效，对数据的组合比较随机，边界缺陷不容易发现 ；

适用范围：只在存在输入的需求都适用。

等价类划分法

等价类是指输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效，并合理地假设：测试某等价类的代表值就等于对这类其他值的测试。

等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。

等价类划分有两种不同的情况：有效等价类和无效等价类。

• 有效等价类：指对于程序的规格说明书来说是合理的、有意义的输入数据构成的集合。利用有效等价类可以检验程序是否实现了规格说明书中所规定的功能和性能。
• 无效等价类：与有效等价类的定义恰巧相反。
  设计测试用例时，要同时考虑这两种等价类。因为，软件不仅要能接收合理的数据， 也能经受意外的考验。这样的测试才能确保软件具有更高的可靠性。

确定等价类的原则

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

确定测试用例步骤

1. 划分等价类

2. 为每一个有效等价类和无效等价类规定一个唯一的编号

3. 设计一个测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类， 重复这一步直到所有有效等价类均被测试用例所覆盖

4. 设计一个测试用例，使其只覆盖一个无效等价类，重复这一步，直到所有无效等价类均被覆盖

等价类实例

三角形：

一个程序输入3个整数，三个数看作三角形的三条边，这个程序要打印出信息，说明这个三角形是不等边的，是等腰的，还是等边的。
先假设三条边为A，B，C。
判断三条边是否组成三角形必须满足两条边相加大于第三边，所以：
A>0,B>0,C>0且A+B>C,A+C>B,B+C>A
等腰三角形必须满足：A=B或A=C或B=C
等边三角形必须满足:A=B=C

输入条件	有效等价类	无效等价类
是否构成三角形	A>0 (1) B>0 (2) C>0 (3) A+B>C (4) A+C>B (5) B+C>A (6)	A<0 (7) B<0 (8) C<0 (9) A+B<C (10) A+C<B (11) B+C<A (12)
是否是等腰三角形	A=B （13） A=C （14） B=C （15）	A≠B≠C （16）
是否是等边三角形	A=B=C （17）	A≠B （18） A≠C （19） B≠C （20）

编号	[A,B,C]	覆盖等价类	输出
1	[3,4,5]	(1) (2) (3) (4) (5) (6)	普通三角形
2	[0,4,5]	(7)	不是三角形
3	[3,0,5]	(8)	不是三角形
4	[3,4,0]	(9)	不是三角形
5	[3,4,8]	(10)	不是三角形
6	[3,16,5]	(11)	不是三角形
7	[10,4,5]	(12)	不是三角形
8	[3,3,5]	(1) (2) (3) (4) (5) (6) (13)	等腰三角形
9	[7,5,5]	(1) (2) (3) (4) (5) (6) (14)	等腰三角形
10	[3,5,3]	(1) (2) (3) (4) (5) (6) (15)	等腰三角形
11	[3,4,2]	(1) (2) (3) (4) (5) (6) (16)	非等腰三角形
12	[3,3,3]	(1) (2) (3) (4) (5) (6) (17)	等边三角形
13	[3,4,4]	(1) (2) (3) (4) (5) (6) （15） (18)	非等边三角形
14	[3,3,4]	(1) (2) (3) (4) (5) (6) （13） (19)	非等边三角形
15	[3,4,3]	(1) (2) (3) (4) (5) (6) （14） (20)	非等边三角形
16	[,4,5]	无效等价类	空
17	[3,4,]	无效等价类	空
18	[3,5]	无效等价类	空
19	[@,4,5]	无效等价类	特殊字符
20	[3,!,5]	无效等价类	特殊字符
21	[3,4,#]	无效等价类	特殊字符
22	[一,4,5]	无效等价类	汉字
23	[3,二,5]	无效等价类	汉字
24	[3,4,三]	无效等价类	汉字
25	[-3,4,5]	无效等价类	负整数
26	[3,-4,5]	无效等价类	负整数
27	[3,4,-5]	无效等价类	负整数

qq号进行注册：

需求：QQ号注册用户，账号必须6-10位⾃然数, 同⼀QQ号不能重复注册

有效等价类	有效数据	无效等价类	无效数据
6-10位自然数	1234567	小于6位自然数	12345
		大于10位自然数	123343536566
		6-10位字母	sadfdaf
		6-10位汉字	而附近的复活节地方的
		6-10位符号	，。、@#￥%%￥#
		不填写
		重复输入	1234567

边界值

边界值分析方法的理论基础是假定大多数的错误是发生在各种输入条件的边界上，如果在边界附近的取值不会导致程序出错，那么其他取值导致程序错误的可能性也很小。

方法：对于存在边界的输入取边界的上点、内点、离点进行测试。

上点：边界上的点

内点：边界内的点

离点：闭区间间靠近上点但在区间外的一点，开区间则是在区间内的一点 主要是用于对等价类的补充

优点：能更容易发现边界，更全面系统的测试边界上可能存在的问题；

缺点：只能做为一个对其他设计方法的补充；

适用范围：有输入参数且存在取值边界或长度边界时。

因果图

因果图提供了一个把规格转化为判定表的系统方法，且它最终生成的就是判定表。

方法：把大的系统规格划分成可以测试的规格片段；分析哪些是原因、哪些是结果；画出因为图；把因果图转换成判定表；简化判定表；

优点：能帮助我们按照一定步骤，高效的选择测试用例，设计多个输入条件组合用例；能考虑到多个条件组合起来可能出错的情况；

缺点：输入条件与输出条件的因果关系有时很难从SRS中得到，即便得到了也会因为因果关系复杂导致因果图非常庞大，从而使测试用例数目非常多；

正交排列

从大量的测试点中挑选出适量的有代表性的点，应用依据迦罗瓦理念导出的正交表，合理安排测试数据的方法 。

优点：用于考虑到所有的组合又使例数量最少 ；

适用范围：输入的参数之间是独立的，不存在相互依赖的关系。

错误猜测法

基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的 方法.

错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况, 根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前 产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为 0 的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择 这些情况下的例子作为测试用例.

因果图

因果图提供了一个把规格转化为判定表的系统方法，且它最终生成的就是判定表。

方法：把大的系统规格划分成可以测试的规格片段；分析哪些是原因、哪些是结果；画出因为图；把因果图转换成判定表；简化判定表；

优点：能帮助我们按照一定步骤，高效的选择测试用例，设计多个输入条件组合用例；能考虑到多个条件组合起来可能出错的情况；

缺点：输入条件与输出条件的因果关系有时很难从SRS中得到，即便得到了也会因为因果关系复杂导致因果图非常庞大，从而使测试用例数目非常多；

场景法：

通过场景描述的业务流程（业务逻辑），也包括代码实现逻辑。设计用例来遍历场景（路径），验证软件系统功能的正确性。

1、为什么用场景法设计测试用例？

大多数业务软件由后台管理（比如：用户管理、角色管理、权限管理等等各种管理）和工作流等几个部分组成。终端用户，期望软件能够实现业务需求，而不是简单的功能的组合。对于单点功能利用等价类、边界值、判定表用例设计方法能够解决大部分问题。涉及业务流程的软件系统，采用场景法比较合适。

2、什么是场景法？

场景业务流通常分为基本流、备选流、异常流程

基本流：基本流表示通过业务流程时输入都正确，能达到目标的流程。(插卡–》输入正确密码–》输入金额–》取款–》取卡)

备选流：备选流表示通过业务流程时输入错误（或者操作错误）导致流程存在反复，但是经过纠正后仍能达到能达到目标的流程.（插卡–>输入错误密码–》输入正确密码–》输入金额–》取款–》取卡）

异常流：异常流表示通过业务流程时输入错误（或者操作错误）产生异常终止流程 （插卡–>输入3次错误密码–》吞卡） .

3、场景法设计测试用例的步骤？

步骤一:理解需求，确定业务流程（基本流程、备选流程、异常流程）

步骤二：绘制流程图，再次确认流程路径

步骤三：根据业务流程图，抽取测试路径（每一路径需含一个未走过得路径）

步骤四：细化路径，利用等价类边界值方法细化路径，抽取测试用例

4、场景法设计测试用例的优缺点？

优点：涉及到业务流程的业务需求适合用场景法

缺点：只验证业务流程，不验证单点功能，一般先采用先用等价类，边界值，错误推断，判定表等方法对单点功能进行验证，验证通过后再采用场景法进行业务流程的验证。

用例场景例子

用户登录到网站后，进行书籍的选择，当选好自己心仪的书籍后进行订购，这时把所需图书放进购物车，等进行结帐的时候，用户需要登录自己注册的帐号，登录成功后，进行付款交易，交易成功后，生成订购单，整个购物过程结束。

第一步：画出流程图，确定基本流和备选流；

基本流：登录在线网站→选择书籍→放入购物车→登录账号→付款→生成订单

备选流１：用户不存在→注册用户

备选流２：密码不正确

备选流３：账户余额不足→充值

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

场景１（成功购物）：基本流；

场景２（账户不存在）：基本流 备选流１

场景３（账户密码错误）：基本流 备选流２

场景４（账户余额不足）：基本流 备选流3

第三步：对每一个场景生成测试用例；

状态迁移法

状态迁移法主要关注在测试状态转移的正确性上面。对于一个有限状态机，通过测试验证其在给定的条件内是否能够产生需要的状态变化，有没有不可达的状态和非法的状态，是否可能产生非法的状态转移等。通过构造能导致状态迁移的事件，来测试状态之间的转换。

该方法适合功能的状态比较多的情况下，需测试各种状态的转换，且这些状态转换的测试在实际工作中容易被遗漏。比如播放器、遥控按键等。

状态迁移法的步骤

1. 分析需求，整理所有状态；
2. 画出状态迁移图；
3. 列出状态-事件表；
4. 得到状态转换树(测试路径)；
5. 根据状态转换树得到测试用例

案例

得到测试路径：

1. 未支付–> 已取消
2. 未支付–> 已支付–> 已出票–> 改签成功–> 退票成功
3. 未支付–> 已支付–> 已出票–> 改签成功–> 已使用
4. 未支付–> 已支付–> 已出票–> 退票成功
5. 未支付–> 已支付–> 已出票–> 已使用
6. 未支付–> 已支付–> 改签成功–> 退票成功
7. 未支付–> 已支付–> 改签成功–> 已使用
8. 未支付–> 已支付–> 退票成功
9. 未支付–> 已支付–> 已使用

详细的描述一次测试用例设计的完整的过程。

就说最近的这次网站功能的测试吧

首先：得到相关文档（需求文档和设计文档），理解需求和设计思想后，想好测试 策略（测试计划简单点就 OK 了），考虑到测试环境，测试用例，测试时间等问题。

第二步：设计测试用例，测试策略是：把网站部分的功能点测试完，然后在进行系统测 试（另外个模块呢有另一个测试人员负责，可以进行联调测试），网站模块的测试基本 是功能测试和界面测试（用户并发的可能性很小，所以不考虑）：这次的网站的输入数 据呢是使用数据库中的某张表记录，如果表中某一数据记录中新加进来的（还没有被处 理的，有个标志位），网站启动后会立刻去刷那张表，得到多条数据，然后在进行处理。 处理过程中，会经历 3 个步骤，网站才算完成了它的任务。有 3 个步骤呢，就可以分别 对 这 3 个步骤进行测试用例的设计,尽量覆盖到各种输入情况（包括数据库中的数据， 用户的输入等），得出了差不多 50 个用例。界面测试，也就是用户看的到的地方，包括 发送的邮件和用户填写资料的页面展示。

第三步：搭建测试环境（为什么这个时候考虑测试环境呢?因为我对网站环境已经很熟 了，只有有机器能空于下来做该功能测试就可以做了），因为网站本身的环境搭建和其 他的系统有点不同，它需要的测试环境比较麻烦，需要 web 服务器（Apache,tomcat）， 不过这次需求呢，网站部分只用到了 tomcat，所以只要有 tomcat 即可

第四步：执行测试

测试用例模板下载