详解：黑盒测试和白盒测试

一、概述

    黑盒测试和白盒测试都是测试平时经常使用的，往往贯穿于我们的测试流程，不过在你测试的过程当中你使用了可能你自己都不知道，这也侧面显示出来黑盒白盒的重要性，因此我们今天就来聊一聊这两种测试。

    黑盒测试，顾名思义：黑盒测试基于名字来理解就是对于一个黑色的盒子进行测试，什么叫黑盒？黑色的盒子吗？不对，在我们测试的世界里面黑盒是指不关注盒子里面的具体内容，直接对盒子的外部进行测试，说人话就是：黑盒测试不关注软件内部的实现，比如软件内部的代码是怎么编写的，用什么语言编写的，用到了什么算法等等，黑盒测试不关注这些东西，黑盒测试关注的是这个软件的功能完整性，用户体验感。

    白盒测试，顾名思义：对一个白色的盒子进行测试吗？不是的，白盒测试是指把盒子透明化，能够了解到内部的具体实现，针对于盒子内部实现进行测试。说人话就是：白盒测试关注的是软件内部的具体实现，比如说软件内部的代码是怎么编写的，算法是怎么写的，白盒测试是针对于这些代码进行测试，要求对软件里面的全部代码都需要测试，考虑的是代码的完整性，以及代码逻辑完整性，工作量极大

总结：
    黑盒测试和白盒测试是软件测试领域的两大核心方法，主要核心区别在于测试人员对于软件的“内部结构”的了解程度不同，两者在测试视角，测试方法，使用场景方面都存在一定的差异，在工作当中需要灵活使用或者是两者搭配进行使用。

    举个荔枝，我们是程序员，我们自己的电脑在出问题的时候我们应该具备一些检查电脑的能力，那么就可以分为两种：一种是直接在电脑里面（不拆机）进行检查，一种是直接拆机，拿出电路板进行检查

    比如检查键盘按动没有反应

1. 不拆机检查：不打开电脑内部，只对电脑进行操作检查，是不是设置里面禁用键盘了？或者是键帽底下有异物卡住了？或者是当前页面处于键盘禁用只能操作鼠标的状态？
2. 拆机检查：拆机拿出电路板，用工具检查电阻是否正常，键盘是否能够正常通电

    第一种对应黑盒测试：不关注内部电路，只通过输入（按键）观察输出（屏幕反馈）来定位问题，第二种这对应白盒测试：深入内部结构，检查代码逻辑（电路）是否连通，是否存在逻辑断路或短路

二、特点

2.1、黑盒测试

2.1.1、黑盒测试详解

    黑盒测试主要是站在用户的角度来进行测试，主要关注的是用户的体验感，以及当前软件的功能是否完整。

    黑盒测试把软件看成为 “ 黑盒子 ” ，仅仅依靠需求规格说明书进行设计测试用例，不关注内部的具体实现逻辑，程序猿只需要知道操作软件，输入A能够得到预期的输出B，那么这个功能就是正常的，比如：登录功能，输入正确的账户密码，就可以登陆进入软件，输入错误的密码，就无法登陆进入软件。

    黑盒测试对于测试人员的水平要求比较低，对于代码的理解程度也不需要很高

2.1.2、黑盒测试的方法

    黑盒测试进行测试比较常用的测试方法：

• 等价类划分（把数据划分为有效的和无效的）
• 因果图法（分析输入条件和输出条件之间的因果关系）
• 边界值（测试临界值的最大值或者是最小值）
• 场景法（根据用户的使用场景进行头脑风暴，考虑用户会在那些场景下使用）

2.1.3、黑盒测试的优点

• 测试者不需要了解被测系统的内部实现细节和代码结构，测试可以在软件开发的不同阶段由不同的测试人员进行，降低了测试的难度
• 黑盒测试的测试用例基于软件的需求规格说明书进行设计，也就是测试用例是基于软件开发和功能设计进行设计的，是真实的模拟用户的使用，可以很好的从用户视角进行验证系统功能是否能够满足用户预期

2.1.4、黑盒测试的缺点

由于不了解软件的内部实现细节以及内部结构，可能难以覆盖所有的代码路径，存在测试盲点
生成高覆盖率的测试用例比较困难，需要全面的需求文档和功能说明

2.2、白盒测试

2.2.1、白盒测试详解

    白盒测试主要是站在代码层面上的视角（其实本质就是开发者的角度 ）进行测试，白盒测试关注的是代码层面上的结构完整性以及代码逻辑覆盖，要求测试要覆盖所有的代码，代码的每一个分支循环，逻辑都要确保正确，没有代码层面的BUG。

    白盒测试是将软件看成 “ 白盒子 ” ，直接从代码层次进行设计测试用例， 要求测试人员了解代码结构，算法，接口等，根据源代码，数据库设计，接口文档进行设计测试用例。

    白盒测试关注的是代码层面上的结构完整性以及代码逻辑覆盖，不会真实的考虑用户的使用场景，只要代码的逻辑，结构完整，那么就是测试成功，测试人员需要按照代码的逻辑进行测试，比如检查“账号密码输入为空的时候，是否有非空判断”，“密码加密解密是否正确”等等。

    白盒测试对于测试人员的代码能力有极高的需求，但是对于用户视角方面不需要太过考虑

2.2.2、白盒测试的方法

    白盒测试关注代码逻辑覆盖与结构完整性，比较常用的方法：

• 条件覆盖（验证每一个布尔表达式的真假）
• 分支覆盖（每一个if-else的条件都需要测试）
• 语句覆盖（确保每一行代码都会执行一次）
• 路径覆盖（遍历所有可能执行的路径）

2.2.3、白盒测试的优点

• 测试者了解代码的内部结构，可以通过逻辑和代码路径测试，确保实现的所有代码都经过验证，保证代码层次上没有BUG
• 能够发现隐藏在代码内部的缺陷，包括代码逻辑错误，边界情况等，以及不常见的特殊输入条件

2.2.4、白盒测试的缺点

• 需要测试者具备较高的编程能力和对系统内部结构的深入理解，学习成本比较高
• 一旦代码发生变化，测试用例需要经常更新，维护代价比较高

2.3、实际案例分析

1. 电商支付功能 测试：

• 黑盒测试 ：验证用户支付流程（如：选择支付方式，输入金额，成功 跳转，取消支付，输入金额错误）
• 白盒测试：检查支付接口的异常处理逻辑(如：网络中断，重复支付，金额计算错误)

2. 软件登录功能测试：

• 黑盒测试：验证用户登录流程（如：选择登录方式 ，输入账号密码，输入特殊字符，错误的账号密码 ）
• 白盒测试：检查 登录接口的异常处理逻辑（如：网络中断，账号密码输入异常检测，密码加密解密是否正确）

3. 电商促销活动测试

• 黑盒测试：验证交易功能是否符合需求（如：满“100”减“10”）
• 白盒测试：通过路径覆盖确保所有条件组合（如 高金额消费但是黑名单用户）可以被正常测试到，避免逻辑遗漏

三、总结

    黑盒测试保障“软件是否符合用户需求”，本质是基于用户视角（需求规格说明书）进行测试，白盒测试保障“代码 是否正确实现功能”，本质是基于代码层面（结构完整性，逻辑完整性）进行测试，一个确保“用户能用”，一个确保“软件靠谱”。

    在测试体系里面两者不是对立关系，而是相辅相成——只有将黑盒测试的“广度验证”与白盒测试的“深度排查”相结合，才能够全面覆盖软件质量风险 ，构建真正可靠的软件系统。（比如说黑盒测试发现某一个功能，偶尔可以正常使用，偶尔会没有反应，那么此时就需要白盒测试去代码深度排查定位问题根本）

    黑盒测试完全站在最终用户的视角，关注的是“用户体验”与“功能闭环”。测试人员依据《需求规格说明书》设计用例，无需知晓代码是用Java还是Python编写，也不必关心内部算法用的是冒泡算法还是快速排序算法。

    白盒测试则是站在开发者的视角，关注代码层面的“结构完整性”与“逻辑覆盖”。测试人员必须掌握源代码、数据库设计及接口文档。测试的重点不再是用户好不好用，而是代码写得对不对。