黑盒测试方法

黑盒测试：是一种常用的软件测试方法，它将被测软件看作一个打不开的黑盒，主要根据功能需求设计测试用例，进行测试。

几种常用的黑盒测试方法有等价类划分法、边界值分析法、因果图法、决策表法。在实际运用中要选择合适的方

等价类划分法是一种典型的黑盒测试用例设计方法。采用等价类划分法时，完全不用考虑程序内部结构，设计测试用例的唯一依据是软件需求规格说明书。

等价类划分法：

等价类中任意一个输入数据对于揭露程序中潜在错误都具有同等效果。

• 后续我们只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。
  等价类划分有效等价和无效等价。

等价类：某个输入的集合，集合中每个输入条件都是等效的，如果其中一个输入无法发现问题，集合中其它输入也是无效的

有效等价类：合理的输入数据

无效等价类：不合理的输入数据

所谓等价类，是输入条件的一个子集合，该输入集合中的数据对于揭示程序中的错误是等价的。等价类又分为有效等价类和无效等价类。有效等价类代表对程序有效的输入，而无效等价类则是其他任何可能的输入（即不正确的输入值）。

有效等价类和无效等价类都是使用等价类划分法设计用例时所必须的，因为被测程序若是正确的，就应该既能接受有效的输入，也能接受无效输入的考验。

等价类划分的原则

• 如果输入条件规定了一个取值范围，那么就应该确定一个有效等价类以及两个无效等价类。
• 规定了输入值的集合必须如何的情况下可以确定一个有效等价类和一个无效等价类。
• 在输入数据是一个布尔值的情况下，可以确定一个有效等价类和一个无效等价类。
• 已经划分的等价类中各个元素在程序中的处理方式不同，可以将等价类再次细分
• 在规定了输入条件必须遵守一定规则轻客下，可以确定一个等价类（符合规则）与多个无效等价类

等价类划分法设计测试用例步骤

• 为每个输入划分等价类，且标记唯一编号
• 设计测试用例，使其尽可能多的覆盖尚未覆盖的有效等价类，重复步骤，使得所有有效等价类被覆盖。
• 设计测试用例，使其只覆盖一个无效等价类，重复步骤，使得所有无效等价类被覆盖。
  驾考年龄限制

示例

驾驶证年龄新规

对于小型手动(C1驾驶证)、自动(C2驾驶证)、残疾人专用自动挡载客汽车(C5驾驶证)的，驾考的年龄为18—70周岁。

有效等价类：驾驶人年纪18~70整数
无效等价类：年纪<18；年纪>70

网易邮箱注册

账号限制条件

6~18个字符，可以使用字母、数字、下划线、需以字母开头

实战案例一
微信红包，可以发送的金额范围

• 有效金额范围：0.01-200
• 有效类型：数字有效范围0.01<有效值 < 200
• 无效类型：字母，特殊符号，中文
  

边界值分析法

边界值分析法是一种补充等价划分的测试用例设计法则，它不是选择等价类的任意元素，而是选择等价类边界的测试用例。

• 边界值分析方法，是选取输入、输出的边界值进行测试。
• 因为通常大量的软件错误是发生在输入或输出范围的边界上，所以需要对边界值进行重点测试，通常选取正等于、刚刚大于或刚刚小于边界的值作为测试数据。

从方法论上可以看出来，边界值分析是对等价类划分的补充，所以这两种测试方法经常结合起来使用。

实战案例二
学生管理系统中，可以录入考试成绩，成绩范围在0~100，考试成绩合格分是60分。

为了测试这个输入框，当然不会从0_{100挨个测试，根据需求可知，0}59任意整数，60~100任意整数可以看做是等价的，都可以揭露输入框潜在的缺陷。

等价类划分法

在0_{59之间和60}100之间随机抽取整数验证，就成为”有效等价类”。

显然如果输入的成绩是负数，或是大于100的数，都成为”无效等价类”。

因此，测试用例的设计：

有效等价类

• 0~59之间的任意整数
• 59~100任意整数

无效等价类

• 小于0的负数
• 大于100的整数
• 0~100之间的任意浮点数
• 其他任意非数字字符

边界值分析法
我们继续看学生信息系统中“考试成绩”的例子，选取的边界值数据应该包括：-1，0，1，59，60，61，99，100，101。

因果图

等价类划分法和边界值分析方法都是着重考虑输入条件，而不考虑输入条件的各种组合、输入条件之间的相互约束关系。

如果输入之间有关系，例如，约束关系、组合关系，这种关系用等价类划分和边界值分析是很难描述的，测试效果难以保障，因此必须考虑使用一种适合于描述对于多种条件的组合，产生多个相应动作的测试方法，因果图正是在此背景下提出的。

比如注册功能，填写地区信息，条件一输入了北京地区，条件二的输入只能是昌平、海淀、朝阳等等信息，这就是种约束关系。

因果图(逻辑模型)是一种适合描述多种条件的组合、产生多种相应动作的测试方法，这就需要用因果图。

因果图-判定表

• 因果图基于这样的思想：一些程序的功能可以用决策表的形式来表示，并根据输入条件的组合规定相应的操作。
• 为决策表中的每一列设计一个测试用例，以便测试程序在输入条件的某种组合下的输出是否正确。
• 因果图就是从程序规格说明书的描述中找出因(输入条件)-果(输出结果或程序状态的改变)
• 判定表可以理解是个表格，是分析和表达多逻辑条件下执行不同操作的工具
• 判定表可以把复杂的逻辑关系和多种条件组合的情况表达的非常具体
  

判定表通常由四个部分

• 条件桩：列出问题的所有条件(如上表，你累了吗)
  • 条件项：列出针对条件的取值，所有可能情况的真假值
• 动作桩：已列出的问题可采取的操作(停止阅读，洗洗睡吧)
  • 在条件项的情况下应采取的动作
    因果图案例实战

分析输入条件与输出条件

输入1与输入2的数值区间：

• 0<=x<=99
• -99<=x<0
• x<-99
• x>99

输出信息

• 正确计算结果
• 错误输入

判定表绘制

得到测试用例

从”用户登录”谈起

用户登录，是我们耳熟能详的基本功能，基本上你接触到的网站都需要登录，我们只需要输入用户名和密码，然后点击登录按钮，查看页面是否登录。这就是最基本，最典型的一种测试用例。

作为测试工程师，你的目标是要保证系统在各种应用场景下的功能是符合设计要求的，所以你需要考虑的测试用例就需要更多、更全面。

在具体的用例设计时，首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，最后再针对每个测试需求点设计测试用例。

有趣的面试题

面试官可能会问：”一个登陆页面，你给我设计一些测试用例吧。”

新人测试工程师的思路

现在，针对“用户登录”功能，基于等价类划分和边界值分析方法，我们设计的测试用例包括：

• 输入已注册的用户名和正确的密码，验证是否登录成功；
• 输入已注册的用户名和不正确的密码，验证是否登录失败，并且提示信息正确；
• 输入未注册的用户名和任意密码，验证是否登录失败，并且提示信息正确；
• 用户名和密码两者都为空，验证是否登录失败，并且提示信息正确；
• 用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确；
• 如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入正确的验证码，验证是否登录成功；
• 如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入错误的验证码，- - 验证是否登录失败，并且提示信息正确。

经验丰富测试工程师的思路

• 用户名和密码是否大小写敏感；
• 页面上的密码框是否加密显示；
• 后台系统创建的用户第一次登录成功时，是否提示修改密码；
• 忘记用户名和忘记密码的功能是否可用；
• 前端页面是否根据设计要求限制用户名和密码长度；
• 如果登录功能需要验证码，点击验证码图片是否可以更换验证码，更换后的验证码是否可用；
• 刷新页面是否会刷新验证码；
• 如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性；
• 用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面；
• 不同级别的用户，比如管理员用户和普通用户，登录系统后的权限是否正确；
• 页面默认焦点是否定位在用户名的输入框中；
• 快捷键Tab和Enter等，是否可以正常使用。

上面所有的测试用例设计都是围绕显式功能性需求的验证展开的，换句话说，这些用例都是直接针对“用户登录”功能的功能性进行验证和测试的。

但是，一个质量过硬的软件系统，除了显式功能性需求以外，其他的非功能性需求即隐式功能性需求也是极其关键的。

显式功能性需求（Functional requirement）

• 指的是软件本身需要实现的具体功能， 比如“正常用户使用正确的用户名和密码可以成功登录”、“非注册用户无法登录”等，这都是属于典型的显式功能性需求描述。

非功能性需求（Non-functional requirement）

• 从软件测试的维度来看，非功能性需求主要涉及安全性、性能以及兼容性三大方面。 在上面所有的测试用例设计中，我们完全没有考虑对非功能性需求的测试，但这些往往是决定软件质量的关键因素。

安全性测试用例

• 用户密码后台存储是否加密；

• 用户密码在网络传输过程中是否加密；

• 密码是否具有有效期，密码有效期到期后，是否提示需要修改密码；

• 不登录的情况下，在浏览器中直接输入登录后的URL地址，验证是否会重新定向到用户登录界面；

• 密码输入框是否不支持复制和粘贴；

• 密码输入框内输入的密码是否都可以在页面源码模式下被查看；

• 用户名和密码的输入框中分别输入典型的“SQL注入攻击”字符串，验证系统的返回页面；

• 用户名和密码的输入框中分别输入典型的“XSS跨站脚本攻击”字符串，验证系统行为是否被篡改；

• 连续多次登录失败情况下，系统是否会阻止后续的尝试以应对暴力破解；

• 同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期；

• 同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。
  性能压力测试用例

• 单用户登录的响应时间是否小于3秒；

• 单用户登录时，后台请求数量是否过多；
  -高并发场景下用户登录的响应时间是否小于5秒；

• 高并发场景下服务端的监控指标是否符合预期；

• 高集合点并发场景下，是否存在资源死锁和不合理的资源等待；

• 长时间大量用户连续登录和登出，服务器端是否存在内存泄漏。
  兼容性测试用例

• 不同浏览器下，验证登录页面的显示以及功能正确性；

• 相同浏览器的不同版本下，验证登录页面的显示以及功能正确性；
  -不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性；

• 不同分辨率的界面下，验证登录页面的显示以及功能正确性。

可见，一个普通的登录功能，在不同的考虑场景下，居然涵盖如此多的测试用例，一个优秀的测试工程师必须具有很宽广的知识面，能够对被测系统的深入理解，明白安全攻击基本原理，掌握性能测试基本方法，才能设计出有的放矢的测试用例

穷尽测试
尽管我们提出了如此多的测试用例，一定还会有未涉及到的所有测试方法。

穷尽测试指的是包含了软件输入值和前提条件所有的可能的组合的测试方法，完成穷尽测试的系统中不该残留任何未知的软件缺陷，因为必须去做更多的测试去找到他们。

但是在绝大多数软件中，测试受到时间和经济成本的影响，不可能完成穷尽测试，而是基于风险驱动模式，侧重的设计测试用例，寻求缺陷和研发成本的平衡。

经典面试题之水杯测试用例

在软件测试的面试中，经常会碰到类似的问题，比如：如何测试一个杯子，或者如何测试一只笔。

要求你设计20个以上的测试用例。

这类的面试题目，是考察面试者是否熟悉各种软件测试方法，设计test case的能力。

回答这类问题的思路, 应该从软件测试的各种不同方法来联想，具体如下

功能测试角度
能否盛水
能否装其他液体，如雪碧，醋，硫酸，茶叶
杯子的容量
杯子的材质，纸质，玻璃，塑料
杯子是否有异味
….
界面测试
杯子客户是小孩，还是老人，还是年轻人，杯子封面设计
杯子颜色
杯子形状
….
安全性测试
杯子材料是否通过了可食用
是否结实，摔在地板上，水泥地，土地，是否会坏
是否容易破损，缺口是否会伤人
是否能够微波
….
性能测试
是否耐热
是否耐寒
如果纸质的，盛水几天后会漏水
杯子上的图案多久会掉色
…
易用性测试
杯子是否烫手
杯子把手是否好拿
杯子是否防滑
杯子是否容易喝到