|
|
51CTO旗下网站
|
|
移动端

黑盒、白盒与灰盒测试的区别

本文将帮助您梳理黑盒、白盒与灰盒测试方法的特点、用途、及其优缺点。

作者:陈峻译来源:51CTO|2020-05-28 07:00

黑盒、白盒与灰盒测试的区别

【51CTO.com快译】

常言道:没有经历测试,您怎么能够判定软件开发的质量呢?对于一名测试人员来说,他需要通过测试来确定目标软件是否满足所有既定的要求?软件是否安全、易用?响应是否迅速、完整?这些对于确保软件在发布之后得到良好反馈,并避免技术性的补救都是至关重要的。

作为一个“调查”的过程,测试人员会通过各种测试来捕获软件中隐藏的错误、缺陷、意料之外的运行结果、以及功能上的不一致性。测试人员通过提交详细的测试报告,以帮助开发人员修复所有发现的问题,使其能够按照预期平稳运行。

总的说来,目前业界常用的软件测试方法有三大类:黑盒、白盒和灰盒测试方法。它们在开展方式上截然不同,在功能用途上也各有优缺点。下面,让我们一起来深入讨论吧。

黑盒测试

黑盒测试方法的主要特点是:执行测试的人员并不了解被测软件的内部结构和源代码。可以说,他们甚至不需要具备对于编程语言的深入了解,或出色的编程技能,便可开展测试。毕竟此类测试方法的目标并非深入研究代码,遍历软件内部,而是直接与用户界面进行交互,测试其功能,并确保系统的每个输入与输出,均符合既定的标准与要求。因此,黑盒测试也可以被称为功能测试(请参见--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

【51CTO译稿,合作站点转载请注明原文译者和出处为51CTO.com】

【责任编辑:庞桂玉 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

思科交换网络安全指南

思科交换网络安全指南

安全才能无忧
共5章 | 思科小牛

78人订阅学习

云计算从入门到上瘾

云计算从入门到上瘾

传统IT工程师的转型
共26章 | 51CTO阿森

239人订阅学习

从头解锁Python运维

从头解锁Python运维

多维度详解
共19章 | 叱诧少帅

353人订阅学习

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微