一般我们在做软件测试的时候，会遇到黑盒测试，白盒测试，我们今天主要说的是黑盒测试的 主要测试方法有那些。接下来就是干货了。
最常见的是
边界值 等价类 错误推测法 场景法 因果图法 判定表组成法 正交实验设计
下面是详细的解释：
前言：在期末考到来的时候复习下黑盒测试。文章copy&paste了很多别人的东西。文章里有很多不足之处。欢迎拍砖！！！！！
黑盒测试仅需知道系统的【输入】和【输出】，不需要知道代码是怎么写的。
一、边界值测试
经实践总结：大量的软件缺陷发生在输入域和输出域的边界上。所以在设计测试用例的时候，应该重视边界。
例如只有一个输入条件时，可以这么选取测试用例。（以坐标轴举例。以红点表示测试用例）
例如当有两个输入条件的时候，可以这么选取测试用例。（以红点表示测试用例）
ps：要测试健壮性（软件有没有金刚不坏之身）的时候，可以这么设计测试用例。
选取略小于最小值的无效测试数据（或者略大于最大值的无效测试数据）。
（以蓝点表示测试用例）
小结：边界值测试是一种最基本的黑盒测试方法，它是“等价类划分”这种测试方法的良好补充。但该方法会有较大的冗余和漏洞。
边界值测试对布尔型无效（因为布尔型不是“true”就是“false”，不存在边界值的概念）
边界值测试并非黑盒测试独有，它也可以应用在白盒测试（比如数组边界的测试、对循环次数边界的测试……）
————————————————————————————————————————-
二、等价类划分
要做到穷尽测试是不可能的，所以在设计测试用例时往往要先划分等价类再选取“人大代表”。
划分的子集应该满足如下因素：
（1）每个子集内部所有的数据都是等价的
（2）子集之间互不相交
（3）所有子集的并集是整个输入域或输出域
PS:
（1）【有效等价类】是相对于规格说明合理的、正确的、有意义的输入数据构成的集合。
（2）【无效等价类】是相对于规格说明不合理的、错误的、无意义的输入数据构成的集合。
小二啊，上一个例子：
如网站注册用户名的时候，输入框要求“用户名由字母开头，后跟字母或数字的任意组合，且长度<=8”。
（1）有效的等价类划分
username = {0<全字母的长度<8}
username = {0<（字母开头 数字）的长度<8}
（2）无效的等价类划分
username = {0<全数字的长度<8}
username = {0<（数字开头 字母）的长度<8}
username = {全字母的长度>8}
username = {全数字的长度>8}
username = {（数字开头 字母）的长度>8}
username = {0<（字母开头 数字）的长度>8}
小二啊，再上一个例子
例：每个学生可选修1-3门课程
•可以划分一个有效等价类：选修1-3门课程。
•可以划分两个无效等价类：未选修课；选修课超过3门。
——————————————————————————————————————
针对缺陷相关性假设，可将等价类测试分为【弱等价类测试】和【强等价类测试】。
在现实情况中，由于缺陷的可能情况非常多，一个子集中的数据对某种缺陷是等价的，但对另外一种缺陷可能又是不等价的。
弱一般等价类（WN）测试:
考虑单缺陷假设; 测试用例使用每个等价类中的一个值。
强一般等价类（SN）测试:
考虑多缺陷假设; 测试用例集合为等价类笛卡儿积。
小二啊,再上一个例子。
1、 弱等价类
弱等价类是考虑某个单一缺陷情况下的等价情况，子集里所有数据在这种缺陷假设下是等价的，并且划分成的几个等价类能够覆盖整个测试空间的单一缺陷。比如以下一段程序：
void Func（unsigned int x）
{
if ( x > 10 )
{
Func1();
}
else
{
Func2();
}
}
我们可以将数据划分为两个等价类，0~10为1个等价类，大于10的数据为1个等价类，
在考虑“>”号误写成“<”号这种缺陷的情况下，这两个等价集中的数据都是等价的，比如0～10这个等价类中，使用0或使用10来进行测试都能发现缺陷。这两个等价类中各自抽取一个测试数据进行测试，都能代表其他数据揭示出“>”号误写成“<”号这种缺陷来，因此整个测试空间都被覆盖了。
2、 强等价类
强等价类是在多个缺陷假设前提下，各个等价类中的可测数据在单个或多个缺陷假设下是等价的，并且划分的各个等价子集中各自取一个测试数据可以覆盖整个测试空间的多个缺陷情况。
再考虑前面弱等价类中的例子程序，出错的可能性有那些呢？除了大于号会错写成小于号外，
实际上还有可能写成大于等于号，
10有可能写成1或100等大于10或小于10的数，
【为方便描述以错写成1和100为例】，事实上错误写成其他数和错写成1和100是等价的。这样将各种可能出错的情况组合起来，程序中的判断条件有可能有以下12种情况：
判断条件 | 揭示缺陷的等价类 | 判断条件 | 揭示缺陷的等价类 | 判断条件 | 揭示缺陷的等价类 |
|---|---|---|---|---|---|
x>10 | 是正确的代码 | x>1 | {10} | x>100 | {11} |
x<10 | {>10} | x<1 | {>10} | x<100 | {0～9},{10} |
x<=10 | {10},{>10} | x<=1 | {>10} | x<=100 | {0～9},{10} |
x>=10 | {10} | x>=1 | {10} | x>=100 | {11} |
考虑0～10这个集合，在误写成中间一列条件中情况下，里面的数据并不等价，比如误写成x>1的情况下，使用1做测试和使用2做测试揭示缺陷是不同的，使用1做测试发现不了缺陷，但使用2测试就能发现缺陷。
在判断条件误写成x>=10条件下，10和0~9中的任一数据也不等价，并且使用大于10的数据也无法揭示出条件错写成x>=10这个缺陷，因此整个测试空间的多个缺陷无法被已划分的两个等价类来覆盖，10需要单独划分成一个等价类。
这样将数据划分成三个等价类{0～9}、{10}、{大于10的数据}，再看看这三个等价类是否可以覆盖表中各种出错情况，显然在x>100和x>=100两种情况下，大于10的数据集合中的数据是不等价的，使用大于100的数据不能揭示出缺陷，但使用大于10小于100的数据却能揭示出缺陷，因此需要对大于10的数据再划分等价类，实际上只要将边界值{11}划一个单独的等价类就可以了。
这样总共得到四个等价类{0～9}、{10}、{11}、{大于11的数据}，从这四个等价类中各取一个数据的话就可以将以上列出的所有可能的缺陷情况都揭示出来，但是各个等价类并不是对所有缺陷都等价的，这种划分的等价类由于可以将各种缺陷情况覆盖到，把它叫叫做强等价类。
PS:
在等价类测试当中，强指的是多缺陷假设，而弱指的是单缺陷假设，前者表明了一个笛卡尔乘积的概念；一般指的就是正常值，即不需要考虑异常者，而健壮性则刚好相反，即需要考虑异常者。 弱一般等价类：单缺陷假设，不考虑异常区域 强一般等价类：多缺陷假设，不考虑异常区域 弱健壮等价类：单缺陷假设，要考虑异常区域 强健壮等价类：多缺陷假设，要考虑异常区域；即一个全笛卡尔乘积 |
|---|
小二啊,再上一个例子
• 某城市电话号码组成规则是：地区码 前缀 后缀。 地区码：空白 | 3位数字； 前缀：非0且非1开头的3 位数字； 后缀：4位数字。 被测试程序模块接受符合以上条件的电话号码，拒绝所有不符合规定的号码。 请用等价分类法设计测试方案。 1）划分等价类
输入条件 | 有效等价类 | 无效等价类 |
|---|---|---|
地区码 | j：空白、k：3位数字 | n：有非数字字符、o：少于三位数字、p：多于三位数字 |
前缀 | l：200-999之间的任意数字 | q：有非数字字符、r：起始位为0、s：起始位为1、 11：少于三位数字、12：大于三位数字 |
后缀 | m：4位数字 | 13:有非数字字符 14:少于四位数字 15：大于四位数字 |
2）设计测试用例
小结：等价类测试可以处理布尔型和逻辑型的问题。建议在划分等价类后对每个等价类进行编号，这样可看起来会更清晰。
———————————————————————————————————–
三、因果图
毛泽东《反对本本主义》：“因为他们有丰富的经验，不但懂得现状，而且明白因果。”
基于因果图的测试方法要考虑如下问题
（1）规格说明书有哪些原因？
（2）规格说明书有哪些结果？
（3）规格说明书中各种原因之间的关系怎么样？
（4）规格说明书中各种结果之间的关系怎么样？
（5）规格说明书中原因和结果之间的约束条件怎么样？
（6）如何从规格说明书中的原因和结果设计测试用例？
因果图
【a】恒等: 若c1为1，则e1也为1。若c1为0，则e1也为0；
【b】非: 若c1是1，则e1是0.若c1为0，则e1是1；
【c】或: 若c1与c2中有一个是1或者两个都为1,则e1是1。若c1和c2都为0，则e1是0；
【d】与: 当且仅当c1和c2都是1,则e1为1,否则e1为0.
——————————————————————————
E约束(异；异或): a,b最多有一个可能为1,不能同时为1.
————————————————————————————————–
约束(或；包含): a,b,c中至少有一个必须为1,不能同时为0.
——————————————————————————————————–
O约束(惟一): a和b必须有一个且仅有一个为1
———————————————————————————————————————–
R约束(要求):a是1时,b必须是1,即a为1时,b不能为0
———————————————————————————————————————–
M约束:对输出条件的约束,若结果a为1,则结果b必须为0.
———————————————————————————————————————-
小二啊，上一个例子。
某个软件的规格说明书中规定:第一个字符必须是A或B,第二个字符必须是一个数字字符,在此情况下进行文件的修改。
但如果第一个字符不正确,则给出信息L;如果第二个字符不正确,则给出信息M.
可按照如下步骤设计测试用例： (1)根据软件规格说明书,列出原因和结果. (2)找出原因和结果之间的关系,原因和原因之间的约束关系,画出因果图. (3)将因果图转化为判定表 (4)根据判定表设计测试用例
解：
原因: C1:第一个字符是A; C2:第一个字符是B; C3:第二个字符是一个数字字符. 结果: E1:给出信息L; E2:修改文件; E3:给出信息M;
转化成决策表
小结：因果图可以用于描述输入与输出的相互关系。但是其绘制过程比较繁琐。 因果图可以转化成决策表。 建议直接绘制决策表。
———————————————————————————————————————————————–
四 、决策表
决策表能让你的逻辑更严谨些
小二，先上菜，再看菜单：
……对功率大于50马力的机器并且维修记录不全,或者已运行10年以上的机器，应给予优先的维修处理……” 。这里假定，“维修记录不全”和“优先维修处理”均已在别处有更严格的定义 。请建立判定表。 •解答： –①确定规则的个数：这里有3个条件，每个条件有两个取值，故应有2*2*2=8种规则。 –②列出所有的条件桩和动作桩
•③填入条件项。可从第1列条件项开始，逐列向右填满。如第1列是： Y Y Y ，第二列是： Y Y N 等等。
•④填入动作顶。这样便得到形如图的初始判定表：
条件桩：列出了问题的所有条件。 动作桩：列出了问题规定可能采取的操作。 条件项：列出针对它所列条件的取值，在所有可能情况下的真假值。 动作项：列出在条件项的各种取值情况下应该采取的动作。 规则：由动作项和条件项组成。
决策表的建立步骤
1、列出所有的条件桩和动作桩； 2、填入条件项； 3、填入动作项，制定初始判定表； 4、简化；合并相似规则或者相同动作。
小二，上一个例子。
已知a、b、c三边，判断是否能构成三角形？如果是三角形的话，是什么哪种三角形？
小结 ：决策表测试仅适合对输入域展开分析，不适合对输出域展开测试。
———————————————————————————————
五 、错误推测法
代码语言：javascript复制（阿克琉斯的脚踵？希腊神话的传说人物阿克琉斯，他除了脚踵以外全身刀枪不入，后来被射中脚踵而死亡，意思是指一个人的致命缺点！）错误推测法凭借的是测试人员的 直觉和经验 来推测系统中可能出现的各种缺陷。
常常是列举出系统中所有【可能的缺陷和容易发生缺陷的特殊情况】，并根据它们来设计测试用例。
小二啊，上几道例子
例如: 测试一个对线性表（比如数组）进行排序的程序，可推测列出以下几项需要特别测试的情况： I. 输入的线性表为空表； II. 表中只含有一个元素； III. 输入表中所有元素已排好序； IV. 输入表已按逆序排好； V. 输入表中部分或全部元素相同。
例如：查询功能 A、无条件查询 B、是否支持模糊查询 C、查询的关键字之间是否可用连接符 D、输入正确的查询条件以前加上空格，看是否能正确地查出相应的数据 E、若查询结果为空，是否给与相应提示
例如：登录功能 A、输入的数据前存在空格，是否能够正常登录 B、输入的密码是否能够加密显示 C、密码框的复制、粘贴功能是否被屏蔽掉 D、用户在注销之后是否能够再登录成功 E、输入的数据有误，用户是否可以无休止地尝试登录
小结：
优点：充分发挥个人的经验和潜能，命中率高 缺点：覆盖率难以保证；过多的依赖于个人的经验
———————————————————————————————————————-
六、场景法
软件的工作流程往往对应着现实生活的场景。应该从更高些的视角来 把握系统的业务流程，了解功能模块。
在熟悉流程的基础上才能讨论局部细节的测试设计。 场景法的核心是事件流和场景。
这是一个场景法的示意图。
在这个图中，有一个基本流和四个备选流。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：
场景 1 基本流
场景 2 基本流 备选流 1
场景 3 基本流 备选流 1 备选流 2
场景 4 基本流 备选流 3
场景 5 基本流 备选流 3 备选流 1
场景 6 基本流 备选流 3 备选流 1 备选流 2
场景 7 基本流 备选流 4
场景 8 基本流 备选流 3 备选流 4
从上面的实例我们就可以了解“场景”=“基本流” “备选流”。
基本流：采用直黑线表示，是经过用例的最简单的路径（无任何差错，程序从开始直接执行到结束）
备选流：采用不同颜色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流，或终止用例，不在加入到基本流中；（实际上是各种“非主流”的情况）
下面是场景法的基本设计步骤
1. 根据说明，描述出程序的基本流及各项备选流 2. 根据基本流和各项备选流生成不同的场景 3. 对每一个场景生成相应的测试用例 4. 对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值
小二啊，上一个例子：
有一个在线购物的实例，用户进入一个在线购物网站进行购物，选购物品后，进行在线购买，这时需要使用帐号登录，登录成功后，进行付钱交易，交易成功后，生成订购单，完成整个购物过程。
step1：来确定基本流和备选流：
step2：根据基本流和备选流来确定场景：
step3：设计用例
对于每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。
下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。
本例中，对于每个测试用例，存在一个测试用例ID、场景的条件、测试用例中涉及的所有数据元素、以及预期结果。
通过从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景，至少要确定包含执行场景所需的适当条件的测试用例。例如，在下面的矩阵中，
V（有效）用于表明这个条件必须是 VALID（有效的）才可执行基本流，
而 I（无效）用于表明这种条件下将激活所需备选流。
“n/a”（不适用）表明这个条件不适用于测试用例。
step4：设计用例设计数据，把数据填入上面的用例表中。
注：测试用例只是购物的一部分测试用例，应该还可以继续补充以达到比较好的覆盖。
————————————————————————————————————————-
注释：功能图法、正交实验法也是黑盒测试法
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/179571.html原文链接：https://javaforall.cn
