常用的用例设计方法论（一）

常用的测试用例设计方法：

• 等价类划分
• 边界值分析法
• 因果图方法
• 正交实验设计方法
• 功能图分析方法
• 错误推测法
• 需求文档转化法
• 随机测试和探索式测试

等价类划分法

等价类划分，指的是一种典型的、重要的黑盒测试方法。其就是解决如何选择适当的数据子集来代表整个数据集的问题，通过降低测试的数目去实现“合理的”覆盖，以此发现更多的软件缺陷。

等价类划分法将程序所有可能的输入数据（有效的和无效的）划分成若干个等价类。然后从每个部分中选取具有代表性的数据做测试用例，测试用例由有效等价类和无效等价类的代表组成，从而保证测试用例具有完整性和代表性。

• 有效等价类

1. 有效等价类指对于程序规格说明来说，是合理的、有意义的输入数据构成的集合；
2. 有效等价类可以是一个，也可以是多个
3. 等价类是输入域的集合

• 无效等价类

1. 无效等价类是指对于软件规格说明而言，没有意义的、不合理的输入数据集合。
2. 利用无效等价类，可以找出程序异常说明情况，检查程序的功能和性能的实现是否有不符合规格说明要求的地方。

边界值分析法

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

1. 边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。
2. 应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，

因果图/判定表法

因果图(Cause-Effect Graph)是用于描述系统的输入、输出以及输入和输出之间的因果关系、输入和输入之间的约束关系。

根据系统输入和输出间的因果图可以得到判定表，根据判定表产生设计测试用例。

(因果图/判定表法比较适合测试组合数量较少的情况，一般少于20种)

 

• 基本图形符号

因果关系图, 表示的是因与果之间的关系

因：输入条件

果：输出结果

输入和输出之间的关系有下面几类：

1. 恒等

 

1. 与(A): 只有所有条件都为1时，结果为1，有任何一个条件为0（或者所有条件为0）那么结果为0.

1. 或(V): 只有所有条件都为0时，结果为0，有任何1个条件为1（或者所有条件为1）时，结果为1

1. 取反()

 

• 限制关系图形符号

限制关系图形要么在因（输入条件）之间，要么在果（输出结果）之间。

 

互斥（E-exclude）含义：可以不选，如果选的话只能选1个。

 

唯一（O-Only）含义：有且只有1个（必须要选，而且只能选1个）

唯一和互斥的区别：互斥可以不选，唯一必须要选1个

包含（I-include）含义：至少选1个（可以多选，不能不选，最少得选1个）

要求（R-required）含义：如果a=1 那么要求b必须是1，反之如果a=0，那么b值无所

 

屏蔽（M-masked）含义：当a=1时，b=0；当a=0，b的值有可能是1，也有可能是0

 

四、测试步骤
　　被测程序：交通一卡通充值模拟系统
　　步骤1：了解需求，找出所有的输入条件（因）
　　　　投币50元
　　　　投币100元
　　　　充值50元
　　　　充值100元
　　步骤2：找出所有的输出结果（果）
　　　　成功充值并退卡
　　　　找零
　　　　错误提示并退卡
思考一下：输入之间的组合关系　

判定表：　

将因和果填入《判定表》中　　

输入条件	1	2	3	4	5	6	7	8
投币50元	1	1			1
投币100元			1	1		2
充值50元	1		1				3
充值100元		1		1				4
成功充值并退卡	1		1	1			1	1
找零			1		1	1
错误提示并退卡		1			1	1

 

根据判定表导出测试用例。实际应用中，程序会有判断条件。其中第2，7，8三个用例，可能会存在对应的异常分支处理逻辑。

错误推测法

错误推测法是指：在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法。

错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例.

随机测试

软件测试中除了根据测试用例和测试说明书进行测试外，还需要进行随机测试(Ad-hoctesting)，主要是根据测试者的经验对软件进行功能和性能抽查。

随机测试最好由具有丰富测试经验的熟悉被测软件的测试人员进行测试。对于被测试的软件越熟悉，执行随机测试越容易

探索式测试

 

探索性测试强调测试设计和测试执行的同时性，这是相对于传统软件测试过程中严格的“先设计，后执行”来说的。测试人员通过测试来不断学习被测系统，同时把学习到的关于软件系统的更多信息通过综合的整理和分析，创造出更多的关于测试的主意。

 

优点与缺点

优点

• 鼓励创造性。
• 可增加机会找到新的、未知的程式缺陷。
• 允许测试者花较多的时间去测试一些有趣或复杂的状况。
• 可较快速的对受测的系统做出快速的评量。
• 可让你知道系统是否容易使用。
• 可变通的，有弹性的。
• 它比脚本测试有趣，因为它不会一成不变。

缺点

• 不容易被协调及调整。
• 无法对系统作全面性的测试。
• 提供有限的测试可信度。
• 非常的依靠测试者的领域知识（domain knowledge）以及技术。
• 无法保证最重要的程序错误一定被发现。
• 并不适用要执行很久的测试（例如执行一整个晚上的测试）

 

烟雾测试（SmokeTest）

烟雾测试是一组用以确定系统处于稳定状态、所有的主要功能都具备并且能够在 “ 正常 ” 条件下运行的测试用例。烟雾测试不能由测试小组独立来建立；它应该是通过联合的方式，至少是在与开发达成一致的情况下建立的。烟雾测试的目标是显示稳定性、而不是发现系统的每个 bug ，必须在系统测试环境中运行。

烟雾测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。烟雾测试的执行者是版本编译人员

参考文献：

https://zhuanlan.zhihu.com/p/55147816

https://www.cnblogs.com/test-123/p/9686346.html

https://zhuanlan.zhihu.com/p/55370187