黑盒测试方法

作用

黑盒测试法注重于测试软件的功能需求，主要试图发现下列几类错误。

功能不正确或遗漏；

界面错误；

输入和输出错误；

数据库访问错误；

性能错误；

初始化和 终止错误等。

 

测试方法

概述

黑盒测试行为必须能够加以量化，才能真正保证 软件质量，而 测试用例就是将测试行为具体量化的方法之一。具体的黑盒 测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、 因果图法、判定 表驱动法、正交试验设计法、功能图法、 场景法等。

 

等价类划分的办法是把 程序的输入域划分成若干部分（子集），然后从每个部分中选取少数代表性数据作为测试 用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。该方法是一种重要的，常用的黑盒 测试用例设计方法。

 

划分等价类

1) 划分等价类： 等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露 程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试.因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据.取得较好的测试结果. 等价类划分可有两种不同的情况：有效等价类和无效等价类。

 

有效等价类：是指对于 程序的规格说明来说是合理的，有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

 

无效等价类：与有效等价类的定义恰巧相反。

 

设计 测试用例时，要同时考虑这两种等价类.因为，软件不仅要能接收合理的数据，也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性。

 

2）划分等价类的方法：下面给出六条确定等价类的原则。

①在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。

②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个 无效等价类.

③在输入条件是一个 布尔量的情况下，可确定一个有效等价类和一个无效等价类。

④在规定了输入数据的一组值（假定n个），并且 程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。

⑤在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个 无效等价类（从不同角度违反规则）。

⑥在确知已划分的等价类中各元素在 程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。

 

3）设计 测试用例：在确立了等价类后，可建立等价类表，列出所有划分出的等价类：

输入条件

输入条件 有效等价类  无效等价类

然后从划分出的等价类中按以下三个原则设计 测试用例：

①为每一个等价类规定一个唯一的编号。

②设计一个新的 测试用例，使其尽可能多地覆盖尚未被覆盖地有效等价类，重复这一步.直到所有的有效等价类都被覆盖为止。

③设计一个新的 测试用例，使其仅覆盖一个尚未被覆盖的 无效等价类，重复这一步.直到所有的无效等价类都被覆盖为止。

 

边界值分析法

边界值分析是通过选择等价类边界的 测试用例。边界值分析法不仅重视输入条件边界，而且也必须考虑输出域边界。它是对等价类划分方法的补充。

 

（1）边界值分析方法的考虑：

长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部.

 

错误推测法

错误推测法是基于经验和直觉推测 程序中所有可能存在的各种错误，从而有针对性的设计 测试用例的方法.

错误推测方法的基本思想： 列举出 程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择 测试用例。 例如，在 单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等，这些就是经验的总结。

 

因果图法

检查输入条件的组合不是一件容易的事情，因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计 测试用例. 这就需要利用 因果图（逻辑模型）。

因果图方法最终生成的就是判定表。它适合于检查 程序输入条件的各种组合情况。

 

生成 测试用例

(1) 分析软件规格说明描述中，哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。

(2) 分析软件规格说明描述中的语义。找出原因与结果之间，原因与原因之间对应的关系. 根据这些关系，画出 因果图。

(3) 由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现. 为表明这些特殊情况，在 因果图上用一些记号标明约束或限制条件。

(4) 把 因果图转换为 判定表。

(5) 把 判定表的每一列拿出来作为依据，设计 测试用例。

 

从 因果图生成的 测试用例（局部，组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况，构成的测试用例数目达到最少，且测试用例数目随输入数据数目的增加而线性地增加。

 

前面 因果图方法中已经用到了 判定表。判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的情况下的工具.在 程序设计发展的初期，判定表就已被当作编写程序的 辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。

 

判定表组成法

条件桩（Condition Stub）：列出了问题的所有条件.通常认为列出的条件的次序无关紧要。

动作桩（Action Stub）：列出了问题规定可能采取的操作.这些操作的排列顺序没有约束。

条件项（Condition Entry）：列出针对它左列条件的取值.在所有可能情况下的真假值。

动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。

规则：任何一个条件组合的特定取值及其相应要执行的操作.在 判定表中贯穿条件项和动作项的一列就是一条规则.显然，判定表中列出多少组条件取值，也就有多少条规则，既条件项和动作项有多少列。

 

判定表的建立步骤

①确定规则的个数。假如有n个条件.每个条件有两个取值（0,1），故有2n种规则。

②列出所有的条件桩和动作桩。

③填入条件项。

④填入动作项.等到初始判定表。

⑤简化.合并相似规则（相同动作）。

 

B. Beizer 指出了适合使用 判定表设计 测试用例的条件：

①规格说明以 判定表形式给出，或很容易转换成判定表。

②条件的排列顺序不会也不影响执行哪些操作。

③规则的排列顺序不会也不影响执行哪些操作。

④每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。

⑤如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要。

 

正交试验设计

就是使用已经造好了的正交 表格来安排试验并进行数据分析的一种方法，目的是用最少的 测试用例达到最高的测试覆盖率。

 

场景法

软件几乎都是用事件触发来控制流程的，事件触发的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。

基本流和备选流

 

常用方法

功能测试就是对产品的各功能进行验证，根据功能 测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下

1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。

2. 相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。

3. 检查按钮的功能是否正确：如update,cancel,delete,save等功能是否正确。

4. 字符串长度检查： 输入超出需求所说明的字符串长度的内容，看系统是否检查字符串长度，会不会出错.

5. 字符类型检查： 在应该输入指定类型的内容的地方输入其他类型的内容（如在应该输入整型的地方输入其他字符类型），看系统是否检查字符类型，会否报错.

6. 标点符号检查： 输入内容包括各种标点符号，特别是空格，各种引号， 回车键.看系统处理是否正确.

7. 中文 字符处理： 在可以输入中文的系统输入中文，看会否出现 乱码或出错.

8. 检查带出信息的完整性： 在查看信息和update信息时，查看所填写的信息是不是全部带出.，带出信息和添加的是否一致

9. 信息重复： 在一些需要命名，且名字应该唯一的信息输入重复的名字或ID，看系统有没有处理，会否报错，重名包括是否区分大小写，以及在输入内容的前后输入空格，系统是否作出正确处理.

10. 检查删除功能：在一些可以一次删除多个信息的地方，不选择任何信息，按”delete”，看系统如何处理，会否出错；然后选择一个和多个信息，进行删除，看是否正确处理.

11. 检查添加和修改是否一致： 检查添加和修改信息的要求是否一致，例如添加要求必填的项，修改也应该必填；添加规定为整型的项，修改也必须为整型.

12. 检查修改重名：修改时把不能重名的项改为已存在的内容，看会否处理，报错.同时，也要注意，会不会报和自己重名的错.

13. 重复提交 表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。

14. 检查多次使用back键的情况： 在有back的地方，back，回到原来页面,再back，重复多次，看会否出错.

15. search检查： 在有search功能的地方输入系统存在和不存在的内容，看search结果是否正确.如果可以输入多个search条件，可以同时添加合理和不合理的条件，看系统处理是否正确.

16. 输入信息位置： 注意在 光标停留的地方输入信息时，光标和所输入的信息会否跳到别的地方.

17. 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。

18. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*

19.  快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对 快捷方式是否也做了限制。

20.  回车键检查： 在输入结束后直接按回车键，看系统处理如何，会否报错。

 

黑盒测试技术（ Black Box Testing ）：黑盒测试的内容主要有以下几个方面，但是主要还是功能部分。主要是覆盖全部的功能，可以结合兼容，性能测试等方面进行，根据软件需求，设计文档，模拟客户场景随系统进行实际的测试，这种测试技术是使用最多的测试技术涵盖了测试的方方面面，可以考虑以下方面：

1.正确性 (Correctness) ：计算结果，命名等方面。

2.可用性 (Usability) ：是否可以满足 软件的需求说明。

3.边界条件 (Boundary Condition) ：输入部分的边界值，就是使用一般书中说的等价类划分，试试最大最小和非法数据等等。

4.性能 (Performance) ： 正常使用的时间内系统完成一个任务需要的时间，多人同时使用的时候响应时间在可以接受范围内。 J2EE 技术实现的系统在性能方面更是需要照顾的，一般原则是 3 秒以下接受， 3-5 秒可以接受， 5 秒以上就影响易用性了。如果在 测试过程中发现性能问题，修复起来是非常艰难的，因为这常常意味着 程序的算法不好，结构不好，或者设计有问题。因此在产品开发的开始阶段，就要考虑到 软件的性能问题

5. 压力测试(Stress) ： 多用户情况可以考虑使用压力测试工具，建议将压力和性能测试结合起来进行。如果有负载平衡的话还要在服务器端打开监测工具 , 查看服务器 CPU 使用率，内存占用情况，如果有必要可以模拟大量数据输入，对硬盘的影响等等信息。如果有必要的话必须进行 性能优化( 软硬件都可以 ) 。这里的压力测试针对的是某几项功能。

6.错误恢复 (Error Recovery) ：错误处理，页面 数据验证，包括突然间断电，输入 脏数据等。

7.安全性测试 (Security) ：这个领域正在研究中，防火墙、补丁包、杀毒软件等的就不必说了，不过可以考虑。破坏性测试时任意看了一些资料后得知 , 这里面涉及到的知识、内容可以写本书了 , 不是一两句可以说清的，特别是一些商务网站，或者跟钱有关，或者和公司秘密有关的 web 更是需要这方面的测试，在外国有一种专门干这一行的人叫安全顾问，可以审核代码，提出安全建议，出现紧急事件时的处理办法等，在国内没有听说哪里有专门搞安全技术测试的内容。

8. 兼容性(Compatibility) ：不同浏览器，不同应用程序版本在实现功能时的表现不同的上网方式，如果你测试的是一个公共网站的话。

 

 

参考：

［1］百度百科： https://baike.baidu.com/item/%E9%BB%91%E7%9B%92%E6%B5%8B%E8%AF%95?fromtitle=%E9%BB%91%E7%9B%92%E6%B5%8B%E8%AF%95%E6%B3%95&fromid=4138019

 

 

 

转载于:https://www.cnblogs.com/smart-lily/p/11303607.html