常言道：没有经历测试，您怎么能够判定软件开发的质量呢?对于一名测试人员来说，他需要通过测试来确定目标软件是否满足所有既定的要求?软件是否安全、易用?响应是否迅速、完整?这些对于确保软件在发布之后得到良好反馈，并避免技术性的补救都是至关重要的。
作为一个“调查”的过程，测试人员会通过各种测试来捕获软件中隐藏的错误、缺陷、意料之外的运行结果、以及功能上的不一致性。测试人员通过提交详细的测试报告，以帮助开发人员修复所有发现的问题，使其能够按照预期平稳运行。
总的说来，目前业界常用的软件测试方法有三大类：黑盒、白盒和灰盒测试方法。它们在开展方式上截然不同，在功能用途上也各有优缺点。下面，让我们一起来深入讨论吧。
黑盒测试
黑盒测试方法的主要特点是：执行测试的人员并不了解被测软件的内部结构和源代码。可以说，他们甚至不需要具备对于编程语言的深入了解，或出色的编程技能，便可开展测试。毕竟此类测试方法的目标并非深入研究代码，遍历软件内部，而是直接与用户界面进行交互，测试其功能，并确保系统的每个输入与输出，均符合既定的标准与要求。因此，黑盒测试也可以被称为功能测试(请参见--https://testfort.com/functional-testing)、或基于规范的测试。
在软件测试生命周期(STLC)内，黑盒测试通常是由独立的测试团队，从最终用户的角度开展的。通过提供有效或无效的输入，他们会根据预期结果去验证软件的输出，将任何意外的结果和偏差都记录在案，并最终反馈给开发团队，以协助尽早发现并消除软件在功能上的不足与错误。
黑盒测试方法几乎适用于软件测试的每个阶段，包括：单元、集成、系统和验收。
- 在单元测试(请参见--https://testfort.com/blog/thing-avoid-unit-testing-ios-apps)中，黑盒方法可被用于根据客户端给出的不同规范，去测试接口。
- 在集成测试中，黑盒方法的目标是：发现并消除接口在集成组件之间的交互错误。
- 在系统测试中，黑盒方法可以有效地分析系统是否符合各项要求。
- 在验收测试中，黑盒方法通过针对各种意外情况的模拟测试，以协助验证软件产品的可接受性。
目前，最常见的黑盒测试设计技术有：
- 决策表测试在基于嵌入式if-then-else和switch-case之类的决策表语句调试时，非常实用。据此，测试人员可以有效地查找到哪些错误对应于哪些条件。
- 错误猜测可以让测试人员根据他们的直觉和过往的测试经验，来设计测试用例。据此，他们可以确定可能导致软件故障或出现错误的具体原因。
- All-pairs测试是一种用于测试每一对输入参数的所有可能性的离散组合技术。据此，测试人员可以发现那些隐藏在参数对的交互过程中的常见错误。
- 等价类划分技术涉及到将输入数据分成不同的较小分区，以及可以从测试用例中导出的数据等价类。据此，测试人员可以构建出覆盖每个分区的测试用例，从而减少测试所需要的时间。
黑盒测试的利与弊
黑盒测试可以协助测试人员识别出功能规格中的任何歧义、模糊、以及矛盾。他们能够在并不触碰软件大量代码段的情况下，评估和提高功能实现的质量。
黑箱测试的无偏见性体现在：由一个独立的团队以最终用户的观点去执行，因此它有别于开发人员的视角。相比另两种方法，黑盒测试具有最快的测试用例开发能力，毕竟它既不需要编程知识，又可以由没有技术背景的测试人员去轻松地执行。
不过，黑盒方法的有效性仅限于测试小型软件。而对于大型复杂软件进行全面测试时，它不但效率低下并且非常耗时。此外，该方法需要事先提供明确而周详的规范，否则，我们不但难以设计测试用例，并且测试覆盖的范围也将十分有限。
白盒测试
与侧重于功能的黑盒测试相反，白盒测试方法的目标是对软件的内部结构、及其背后的逻辑进行分析。因此，白盒测试有时也被称为结构测试、或逻辑驱动测试。此类方法不但比较耗时，并且要求测试人员具有强大的编程能力，能够对所测软件进行全面了解，并且可以访问到所有的源代码、以及体系架构的相关文档。否则，测试人员将无法设计出适当的测试用例。
因此，白盒测试通常是由专业开发人员去执行的。他们运用专业知识，以及源代码分析与调试专用工具，在弄清软件的内部结构和代码细节的基础上，逐步检查语句和条件、代码的路径、数据流、以及各种有效或无效的输入，验证程序是否能按照预期输出结果。据此，开发人员可以开展有针对性的修复，以确保没有隐藏的错误、或容易产生缺陷的元素。
虽然白盒测试可以被应用于单元测试，但是如今它被主要用在集成测试(请参见--https://testfort.com/integration-testing)和回归测试(请参见--https://testfort.com/regression-testing)中。
- 在单元测试中，测试人员可以检查出内部路径里的代码缺陷，以及其他可能导致软件无法按照预期工作的问题。
- 在集成测试中，白盒方法有助于分析不同的接口和子系统之间的交互。
- 在回归测试期间，测试人员可以有效地使用在单元和集成测试级别上“回收”的白盒测试用例。
目前，最常见的白盒测试设计技术有：
- 控制流测试是一种结构化测试策略。凭借着软件的控制流，它可以通过执行各种输入值，来检查它们是否满足既定的结果，进而验证测试代码的逻辑。
- 数据流测试可以检测对于数据值的不当使用，以及由编码错误所造成的数据流异常。该技术旨在通过更多的测试，来捕获不可靠的代码区域，进而修复或消除相应的错误。
- 分支测试侧重于验证那些被分离出来，执行不同真假条件的特定功能，进而消除异常。
白盒测试的利与弊
与黑盒测试不同，白盒方法是在理解源代码的基础上，通过删除多余的代码段，以发现隐藏在代码中的错误。此外，它可以在源代码级别上通过跟踪每一项测试，来捕获对于软件的各种代码级别的变更。可以说，该方法为开发团队提供了最大的覆盖范围，以及清晰、简洁的反馈。凭借着白盒测试的自动化，开发团队能够更容易地维持和优化代码的质量。
当然，无论是否自动化，白盒测试通常都是耗时且复杂的。它要求测试人员具有一流的编程技能，并对被测软件有着透彻的代码级理解。这就意味着项目组要聘请顶尖的测试工程师来提高测试效率，这也在无形中拉高了成本。此外，由于白盒测试的结果会与代码本身强关联，因此代码内容一旦发生了变化，哪怕其实现的功能是相同的，测试人员也需要重新开展白盒测试，毕竟过往的测试用例肯定是无效的。
灰盒测试
至此，您一定已经看出：由于黑盒测试和白盒测试的关注点各不相同，它们在实际使用中也是各有利弊。而灰盒测试则综合了黑盒与白盒方法的优势，并有效地避开了两者各自的缺陷。
灰盒方法通过涵盖被测软件的所有层面，以增加技术的覆盖范围。如果说黑盒测试人员需要确保界面和功能方面的正常;白盒测试人员通过深入研究软件的内部结构，以修复源代码级别的错误，那么灰盒测试则是以非干扰的方式(non-intrusive)同时处理两方面的测试。
面对复杂的系统，灰盒方法借用简单的黑盒方法，让开发人员、测试人员、以及最终用户都能够上手测试。在测试用例方面，工程师需要具备部分内部结构的相关知识，其中包括：数据结构、体系架构、以及软件功能规范的文档。在此基础上生成的测试用例，可以有效地发现并消除由于软件使用不当，而暴露出的结构缺陷问题。
灰盒测试非常适合于集成测试，包括：缺乏源代码和二进制文件的Web应用，以及某些业务领域的需求规范性测试。
目前，最常见的灰盒测试设计技术有：
- 矩阵测试通过跟踪并映射用户的需求，以确保测试用例能够涵盖所有的方面。它能够像状态报告那样，通过全面的验证测试，来轻松地识别出任何缺少的功能。
- 回归测试是一种软件变更的影响分析。它往往能够检查出软件在被修改后是否还能够正常工作。据此，测试人员能够确保软件的变更既不会阻碍现有的功能，又不会引入新的错误。
- 模型测试会分析和检查在过往的构建、设计和软件体系架构中，测试到的缺陷。此类分析可被用于查找根本原因，以及某些给定缺陷背后的具体根源，进而防止复发。
灰盒测试的利弊
由于灰盒测试方法是基于功能规范、接口和文档等非干扰的方式开展的，因此它使得测试人员仅在宏观上获悉软件的体系架构，而不必完全访问其源代码或二进制文件。这就意味着测试人员和开发人员之间存在清晰的界线，进而保障了此类测试方法不带有任何的“偏见”。此外，灰盒测试还可以针对一些特殊的智能化授权测试场景，实现对数据类型、通信协议、以及各种异常的分析。
开展灰盒方法往往需要测试团队具有出色的项目管理能力。也就是说，如果开发人员已经运行过了相关的测试用例，则不一定非要开展灰盒测试。与此同时，如果测试人员对于软件内部结构的了解非常有限，并且无法访问到其对应的源代码，那么灰盒测试可能会出现许多未经测试的代码路径，进而造成覆盖面的不足。它显然不适用于各种算法领域的测试。另外，如果您使用灰盒方法，在分布式系统中识别关联缺陷时，也往往会感觉到力不从心。
总结
通过上述讨论，我们基本了解了测试团队在确保其产品代码的质量，并严守软件需求规范时常用的三种主要测试方法。从长远来看，它们有助于软件开发企业消除那些将来有可能变成巨大技术债务(technical debt)潜在问题。
那么您一定很好奇：到底哪一种软件测试方法最好呢?客观地说：不同的方法有着不同的适用场景和实现目标。黑盒测试能够通过从需求视角，来获得外部期望，并消除功能上的错误与不一致。白盒测试通过审查源代码，以确保没有隐藏的错误、或容易暴露缺陷的元素。而灰盒测试则能够使用高级数据和功能规范，来捕获各种缺陷，并确保软件满足各项最终的要求。
原标题：Difference Between Black-Box, White-Box, and Grey-Box Testing，作者: Andrew Smith
