黑盒测试用例设计方法(转自他处)

常用测试用例设计方法

1、等价类划分
2、边界值分析方法
3、因果图方法
4、正交实验设计方法
5、功能图分析方法
6、错误推测法
7、需求文档转化法
8、随机测试
9、对象属性分析法

等价类划分：

1）输入条件中规定了输入数据的取值范围，可分为一个有效等价类和另两个无效等价类
2）输入条件中规定了输入数据的个数，可分为一个有效等价类和两个无效等价类
3）若规定了输入数据必须遵循的原则，则可分为一个有效等价类和若干个无效等价类
4）若输入条件中规定了输入数据的一组取值，且软件对不同的输入值对应有不同的处理，则每个允许值构成一个有效的等价类，其他值构成一个无效的等价类
5）若规定输入为整数，则正整数、负整数。零构成有效三个等价类，小数构成无效的等价类

等价类划分例子：

边界值分析方法：

意义：测试输入数据规则的边界是否有问题
较常用
1)若输入条件规定了取值范围，则选择恰好落在边界上和处在边界内、边界外的测试值
2）若规定了输入数据的个数，则选择最小个数，比最小个数多1、少1，比最大个数多1少1等几种测试情况作为测试时输入数据的个数
3）若输入数据为有序集合，则选择有序集合中的第一个、最后一个以及越界输入作为测试用例
边界值分析方法例子：
1）对16-bit位整数而言，32767和-32768是边界值
2）屏幕上光标在最左上和最右下位置
3）报表的第一行和最后一行
4）数组元素的第一个和最后一个
5)循环的第0，1和倒数第1次和倒数第2次

因果图：

等价类和边界值方法，着重考虑输入条件，没有考虑输入条件之间的联系和相互组合，若考虑输入条件中的相互组合可能会产生一些新的情况，将等价类和边界值的方法做一些组合来考虑，最终生成一个判定表
因果图方法最终生成的就是判定表，它时候检查程序入条件中的各种组合情况
根据需求分析中的条件来进行一些组合来生成判定表

因果图——生成判定表
1）分析软件规格说明书描述中，那些是原因（输入条件和输入条件的等价类），那些是结果（即输出条件），并给每个原因和结果赋予一个标志符
2）分析软件规格说明书描述中的语义，找出原因与结果之间、原因与原因之间的对应关系，根据这些关系，画出因果图
3）由于语法与环境限制，有些原因与原因之间、原因与结果之间的组合情况不可能出现，在因果图上用一些记号表明约束或者限制条件
4）把因果图转换成判定表
5)把判定表的每一列作为依据拿出来设计测试用例
判定表的例子;

s

正交实验设计方法：

实验里面有很多数据，数据量比较大，只挑选一些有代表性的点来进行科学实验，即从大量的元素中抽取一些代表性的元素来进行测试

功能图分析方法：状态迁移图和逻辑功能模型构成的，主要关注输入条件和输出之间的对应关系

功能图用在白盒测试比较多
功能图方法要用到逻辑覆盖和路径测试的概念和方法，其属于白盒测试中方法的内容。逻辑覆盖是以程序中逻辑结构为基础的测试用例设计方法，该方法要求对程序逻辑结构有较清楚的了解，由于覆盖测试的目标不同，逻辑覆盖分为：
1）语句覆盖:程序中每条语句至少执行一次
2）条件覆盖
一个判定语句中有多个条件组合而成的复合判定。构成一组测试用例，使得每一条判定语句每一个逻辑条件的值至少满足一次
3）判定覆盖
设计足够的测试用例，使得程序中的每一个判定至少获得一次“真值”或者“假值”，或者说使得程序中的每一个分支“真值”分支或者“假值”分支至少执行一次，因此判定覆盖又称分支覆盖。
4）条件组合覆盖
设计足够多的测试用例 ，使得每个判定中条件的各种组合至少出现一次，显然满足多条件覆盖的测试用例一定满足判定覆盖、条件覆盖和条件组合覆盖。

面试问题：
语句覆盖什么意思？
程序中的每条语句都至少被执行一次，表示语句被执行过
什么叫做判定覆盖？条件覆盖？条件组合覆盖？
判定覆盖：
程序中有if else时，至少执行一次取True和取False时，都能覆盖到，能执行正确
条件覆盖：
多个条件组合，至少每个条件都被触发过一次
条件组合覆盖：
所有条件的排列组合都遍历到，所有的取值都做组合，工作量海量（工作中一般不会做）

流程图

输入条件进行判断，yes的时候是一种情况，no的时候是另外一种分支情况，那么逻辑图里面所有的分支都要覆盖到

错误推测法

根据经验和直接来推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法
猜测哪有错，程序中有可能出现错误的地方，基于代码评审来看
根据经验推测可能出现的错误
1）程序中所有可能出现的错误
2）容易发生错误的特殊情况
3）以前产品测试中曾经发现的错误

建议：
知识积累和分享：
总结常见的错误，常见bug类型，分析总结错误的原因
面试问题：
你觉得测试的项目中有哪些最严重的bug?

需求文档转化法

所见即所得的思想：
1）将需求文档描述中所有的文字信息，全部转化成测试用例
2）所有的示意图、流程图、状态图直接转成测试用例
3）所有项目需求达成口头的共识，需求确认的邮件沟通信息，直接转成测试用例

随机测试法：条件比较多的情况，选择一些代表性条件组合来测试
组合
随意测试，完全不考虑需求和测试用例，站在用户的角度对产品进行试用
适用的场景：
1）之前设定的测试用例已经完全执行完毕
2）海量组合条件无法一一遍历的时候

对象属性分析法：
被测系统的中的元素被定义为一个对象，并且给这个对象设定关联的相关属性和状态，并且不同对象的相关属性和状态进行不同的组合，以扩展测试用例
例如：
文件
属性：
大小、路径（本地、网络）、文件名、文件编码（文本、二进制？）、文件内容、文件读写属性、文件共享属性

沟通：

测试一个产品前，根据获得的信息，想像一下这个产品是什么样子的，在脑子里生成产品的一个状态，包括页面，流程 的一个理想的状态
都想清楚了，写测试用例，写好用例，再和开发的产品进行比对，和自己想的样子比对，是否满足产品发布的要求，如果发现产品实现和自己想象的不一样，那么一定是有问题，这样可以做很多的事情。
沟通：
如果提供一些文档，我就会读懂文档的每一句话，如果有说的不完全的地方，就会来做提问，以文档方式发给相关人员来进行确认问题或者有二意性的东西，这样有一个基本测试逻辑的一些东西

需求变更机制：