测试用例的基本方法

什么是测试用例

测试用例的定义
测试用例是执行测试的依据，把测试系统的操作步骤用文档的形式描述出来

1：测试用例是为达到最佳的测试效果或高效的揭露隐藏的错误，而精心设计的少量测试数据，包括测试输入、执行条件和预期的结果，实际结果:
2：测试用例是执行的最小实体。
3：测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障

测试用例的特征

1：正确性：测试用例最好是要求输入用户实际数据已验证系统是否满足需求规格说明书的需求，并且测试用例中的测试的应保证至少覆盖需求规格说明书中的各项功能。
2：完整性：一些基本功能，如有遗漏，那是不可原谅的。
3：准确：按测试用例输入实施测试后，要能根据测试用例描述的输出得出正确的结论，不能出现模糊不清的语言。
4：清晰、简洁：好的测试用例描述清晰，每一步都应有相应的作用，有很强的的针对性，不应出现一些无用的操作步骤。
5：可维护性：由于软件开发过程中需求变更等原因的影响，常常对测试用例进行修改、增加、删除等，以便测试用符合相应测试要求。
6：适应性：测试用例应该适合特定的测试环境以及符合整个团队的测试水平。
7：可重复性：要求不同测试者在同样的测试环境下使用同样测试用例都能得出相应结论。
8：可追溯性、可移植性

测试用例的基本方法

等价类划分法

等价类划分法设计步骤和原则
1）分析需求，先确定其有效等价类和无效等价类
2）在确立了等价类之后，建立等价类表或者思维导图，列出所有划分的等价类
3）再划分出的等价类中选择测试用例
设计一个新的测试用例数据，使其尽可能多地覆盖尚未覆盖的有效等价类，重复这一步，直到所有的有效 等价类都覆盖为止-----减少测试用例的数量，避免重复，提高效率
设计一个新的测试用例数据，使其仅覆盖一个尚未覆盖的无效等价类，重复这一步，直到所有的无效等价 类都被覆盖为止-----为了确定是哪个因素触发错误，每一种错误都被正确处理

微信发红包
1）分析需求
有效等价类：1）0.01~200 4）数字 6）不能超过两个小数 无效等价类
2）小于0.01 3)大于200 5）非数字(中文，字符，字母) 7）超过两个小数
2）等价类表：

3）等价类划分的测试用例

边界值法

	1：定义：边界值分析法是对等价类划分法的一个补充，边界值一般都是从等价类的边缘值去寻找 
	2：原则和步骤：确定边界：应当选取正好等于，刚刚大于或者刚刚小于边界的值作为测试数据-----范围相关 有效等价类和无效等价类的边界 
	3：边界值的作用：人们长期的测试工作经验得知，大量的错误是发生在输入或者输出范围的边界上，而不是在 输入范围的内部。因此针对各种边界情况设计测试用例，可以查询更多的错误---提出更多的bug

边界值的应用场景：如果需求规定范围或者规定了取值的个数时，可利用边界值进行测试

[1~100]，，(1,100]，，(1,100)，,[1,100)
上点： 离点： 内点：

因果图法

*定义：是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况
特点:
-考虑输入条件的相互制约及组合关系
-考虑输出条件对输入条件的依赖关系
因果图法要注意考虑：
-所有输入/输出条件的相互制约关系以及组合关系
-输出结果对输入条件的依赖关系，也就是什么样的输入组合 会产生怎样的输出结果，即“因果关系”

因果图基本图形符号
恒等：若原因出现，则结果出现；若原因不出现，则结果不出现。
非（～）：若原因出现，则结果不出现；若原因不出现，则结果出现。
或（∨）：若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现。
与（∧）：若几个原因都出现，结果才出现；若其中有一个原因不出现，则结果不出现。

因果图的约束符号
E（互斥）：表示两个原因不会同时成立，两个中最多有一个可能成立
I（包含）：表示三个原因中至少有一个必须成立
O（惟一）：表示两个原因中必须有一个，且仅有一个成立
R（要求）：表示两个原因，a出现时，b也必须出现，a出现时，b不可能不出现
M（屏蔽）：两个结果，a为1时，b必须是0，当a为0时，b值不定

正交表法

	 正交表能够在因素变化范围内均衡抽样，使每次试验都具有较强的代表性，由于正交表具备均衡分散

的特点，保证了全面实验的某些要求，这些试验往往能够较好或更好的达到实验的目的。
应用场景：在一个界面中有多个控件，每个控件有多个取值，控件之间可以相互组合

场景法

1：什么是场景法？
通过场景描述的业务流程(业务逻辑)，也包括代码实现逻辑，设计用例来遍历场景，验证软件系统功能的正确性
2：如何使用场景法
2.1:画出流程图–产品需求文档，画好了；或者是需要测试自己画–wps,office-visio,在线processon
矩形：表示步骤（操作，输入，输出结果）
菱形：判断条件–是，否
箭头：流向
2.2:遍历场景，提取测试用例
1）覆盖正常的路径–冒烟测试
2）走每一个分支–找菱形–正常场景下没有覆盖的路径，分支
3）出错步骤重新回到主流程，建议多走一走正确的步骤

注意：场景法的重点是测试流程，因此每个流程一个用例验证即可，流程测试没有问题并不能说明系统
功能没有问题了，还需要针对单步的功能进行测试，—输入项
只有单个功能点和流程流程测试，才算的充分的测试+等价类，边界值-----细化测试

错误推测法

	错误推测法：根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用 例的黑盒测试方法。 
	它的要素有三个：经验，知识，直觉---探索性测试 
	考虑程序可能触发的错误场景---不能正常运行

例如，测试手机终端的通话功能，可以设计各种通话失败的情况来补充测试用例：

1. 无SIM 卡插入时进行呼出（非紧急呼叫）
2. 插入已欠费SIM卡进行呼出
3. 射频器件损坏或无信号区域插入有效SIM卡呼出
4. 网络正常，插入有效SIM卡，呼出无效号码（如1、888、333333、不输入任何号码等）
5. 网络正常，插入有效SIM卡，使用“快速拨号”功能呼出设置无效号码的数字

使用场景：(考虑的可能不全)不单独使用—可以作为其他方法的补充！

总结
场景法—业务流程梳理，核心业务逻辑场景；
等价类和边界值—细化分析；
错误推测法对最终用例进行错误场景下的补充；

判定表法