黑盒测试用例设计方法-全
黑盒测试用例设计方法
1、等价类
基本原理：
有效等价类：是指对于程序的规格说明来说是合理的、有意义的输⼊数据构成的集合，它能检验程序是否可以实现规格说明中所规定的功能需求。每条测试用例尽可能覆盖多的有效等价类
无效等价类：是指对程序的规格说明是不合理的或⽆意义的输⼊数据所构成的集合，它能检验程序在不符合规则的数据输⼊下，是否会有异常。每条测试用例覆盖一个无效等价类
使用场景：
1、数据量过大且数据操作可以分类
2、输入框较少且数据类型多样（多个条件时需要组合按照基本原理生成测试用例）
3、输入条件独立
案例：
假设有一个程序要求输入值x的取值范围为1到100，我们可以将输入数据划分为以下等价类
有效等价类：1≤x≤100
无效等价类：x<1和x>100
测试用例：
类型 输入/测试步骤 期望结果
有效等价类 50 正常
无效等价类 0 错误
101 错误
2、边界值
基本原理：
考虑输入和输出的边界，在略低于最小值、最小值、略高于最小值、正常值、略低于最大值、最大值、略高于最大值、特殊值范围内取值
使用场景：
1、在有数据输入时使用，通常可以和等价类结合使用
2、输入条件独立
案例：
假设有一个程序要求输入值x的取值范围为1到100，使用边界值的方法设计测试用例
边界值：0、1、100、101
测试用例：
类型 输入/测试步骤 期望结果
小于最小边界 0 错误
等于最小边界 1 正确
等于最大编辑 100 正确
大于最大边界 101 错误
3、判定表
基本原理：
1、通过建立决策规则的表格来清晰的列出输入条件和对应的输出条件，包括条件桩、条件项，动作桩、动作项，
2、适用于逻辑关系复杂、有依赖的场景
3、假设有n个条件，每个条件有真假两个取值，用例数为2的n次方个
4、4个条件以下用判定表，多于的话建议用正交法
使用场景：
IF - then- else结构突出，多条件依赖且无需先后顺序，每个条件有两个取值
简化：
1、规则合并
两条或多条规则中动作项相同，条件项只有一个不同，可以合并
2、规则包含
动作项相同的无关条件项“-”可以进一步合并
案例：
手机被呼叫场景：若用户欠费或者关机，则不允许呼叫
识别条件和动作：
条件1:是否欠费
条件2:是否关机
动作1:不允许被呼叫
动作2:允许被呼叫
生成判定表
1 2 3 4
条件 是否欠费 Y N Y N
是否关机 Y Y N N
动作 允许被呼叫 ✅
不允许被呼叫 ✅ ✅ ✅
生成用例
标题 输入/测试步骤 期望结果
欠费关机时不允许被呼叫 1、欠费
2、关机 无法呼叫
不欠费但是关机时不允许被呼叫 1、不欠费
2、关机 无法呼叫
欠费但是未关机时不允许被呼叫 1、欠费
2、不关机 无法呼叫
不欠费但是未关机时可以被呼叫 1、不欠费
2、不关机 可以呼叫
4、因果图
基本原理：
通过图形化表示输入条件和输出结果之间的逻辑（因果）关系
用节点表示输入条件和变量，用有向边表示因果逻辑（恒等、非、与、或），再将因果图转换为判定表，然后生成测试用例
常见关系表达：
(a)恒等。若原因出现，则结果出现；若原因不出现，则结果不出现。
(b)⾮。若原因出现，则结果不出现；若原因不出现，则结果出现。
©或。若⼏个原因中有⼀个出现，则结果出现；若⼏个原因均不出现，则结果不出现。
(d)与。若⼏个原因都出现，结果才出现；若⼏个原因中有⼀个不出现，则结果不出现。
E：exclude，互斥，可以不选，否则只能选一个
O：only，唯一，必须选一个
I：include，包含，至少选一个
R：required，要求，如果输入A为1，则输入B也必须是1，如果输入A为0，则输入B无要求
M：masked，屏蔽，如果输入A为1，则输入B为0，如果输入A为0，则输入B无要求
使用场景：
适用于业务逻辑复杂，变量间相互影响、需求描述存在隐含逻辑的场景
案例：
某活动设立了一个自动售货机，售货机里售卖饮料、与啤酒，需求如下：
1）若售货机没有零钱找，则一个显示 “零钱找完”的红灯亮，以提示顾客在此情况下不要投入1元钱，否则此红灯不亮。
2）顾客投入5角硬币，然后按下“橙汁”或“啤酒”按钮，则相应的饮料被送出。
3）顾客投入1元硬币并按下“橙汁”或“啤酒”按钮后，若售货机没有零钱找，则显示“零钱找完”的红灯亮，1元硬币被退出，且无饮料送出；若有零钱找，则五角硬币被退出且饮料被送出。
输入（原因）：
输出（结果）：
中间节点：
状态图：
由因果图转换为判定表：
在构成的判定表中，原因、中间节点、结果的取值为0表示其代表的状态不出现；为1表示状态出现。
中间节点与结果没有值，代表因违反约束而不会出现的情况，16、32列没有做任何操作，8、12、24、28列不符合常理（投币却没有选择饮料）为无效列，14、15、30、31列不符合常理（只选择饮料却没投币）为无效列。
用例设计：
5、正交法
基本原理：
研究多因素多水平的一种设计方法，，将因素和取值列出，使用正交表生成用例，再根据经验补充特殊场景。用最少的测试用例覆盖最多的场景
正交表说明：
最简单的正交表是L4(2^3)，含意如下：
“L”代表正交表；
L 下角的数字“4”表示有 4 横行，简称行，即要做四次试验；
括号内的指数“3”表示有3 纵列，简称列，即最多允许安排的因素是3 个；
括号内的数“2”表示表的主要部分只有2 种数字，即因素有两种水平1与2。
使用场景：
适用于影响因素较多，且每个因素都有两个取值的场景
案例：
注册某软件账号页面，需要填写账号，密码，确认密码，验证码，每一个选项都有两种情况可测试，填写或者不填写：
利用正交表来设计部分测试用例，这个过程要借助工具allparis或者pairwise程序（可自行从第三方网站查找）。
1、找到因素和水平（取值），并写到Excel表中
账号 密码 确认密码 验证码
填写 填写 填写 填写
不填写 不填写 不填写 不填写
2、在allparis.exe目录下新建一个txt格式文件，将excel中的内容复制到txt文件中，保存txt文件。
3、使用allparis.exe文件对txt文件生成正交表
›allpairs. exe test. txt › result.txt
4、根据正交表生成测试用例
6、状态图
基本原理：
一种专门解决动态说明问题的测试用例设计方法，抽象出待测系统的若干状态以及状态之间的转换条件和转换路径，然后从状态迁移路径覆盖的角度设计用例
1）一个状态迁移图中包含如下几种状态：
•初态(即初始状态) ——实心圆
•终态(即最终状态) ——一对同心圆(内圆为实心圆)
•中间状态——圆角矩形
2）在一张状态图中只能有一个初态，而终态则可以有0至多个。
3）状态图既可以表示单程生命周期，也可以表示系统循环运行过程
使用场景：
一个功能的状态比较多的情况下使用，比如音乐播放、堆栈操作，但是无效路径覆盖需要补充设计，无法覆盖
案例：
针对客服系统事件状态流转过程设计测试用例：
1）分析客服事件可能存在的所有状态。
•已创建/待分配
•已分派
•处理中
•已解决
•已关闭
•升级待分派
•再次打开
2）梳理状态之间的转换关系和触发条件，得到状态-条件表。
3）根据状态-条件表，画出功能图/状态图
4）根据功能图生成状态迁移树
5）生成测试用例
7、场景法
基本原理：
通过运用场景来对系统的业务流程或者功能点的描述，包括基本流和备选流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历整个的基本流和备选流来完成整个场景
使用场景：
功能业务流程，比如购物流程、ATM流程、离职流程
案例：
用户进入一个在线购物网站进行购物，选购物品后，进行在线购买，需要使用帐号登录，登录成功后，进行付钱交易，交易成功后，生成订购单，完成整个购物过程。
1、画出业务流程图注:描述正常流程和异常流程：
2、确定基本场景，考虑路径覆盖率
场景1 成功购物
场景2 账号不存在
场景3 账号或者密码错误
场景4 用户账号余额不足
3、设计用例，每个场景结合用例设计方法设计测试用用例
编号 场景/条件 账号 密码 余额 预期结果
1 场景1:成功购物 V V V 成功购物
2 场景2:账号不存在 I n/a n/a 提示账号不存在
3 场景3:账号错误 I V n/a 提示账号错误
4 场景3:密码错误 V I n/a 提示密码错误
5 场景4:用户账号余额不足 V V I 提示余额不足
4、设计数据
编号 场景/条件 账号 密码 余额 预期结果
1 场景1:成功购物 Lily 123456 2000 成功购物
2 场景2:账号不存在 Jack n/a n/a 提示账号不存在
3 场景3:账号错误 LILI 123456 n/a 提示账号错误
4 场景3:密码错误 Lily 123457 n/a 提示密码错误
5 场景4:用户账号余额不足 Lily 123456 0 提示余额不足
8、错误推测
原理：
基于经验或者直觉推测程序中可能存在的错误，从而有针对性的设计测试用例
使用场景：
需要深度熟悉被测系统的业务、需求。对被测系统或类似系统之前的缺陷分布情况进行过系统的分析，包括功能缺陷，数据缺陷，接口缺陷和界面缺陷等等。
案例：
根据历史经验分析可能出错的地方