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

1. 黑盒测试

黑盒测试也称功能测试、数据驱动测试或基于规格说明书的测试,它是通过测试来检测每个功能是否都能正常使用。在测试中,把程序看作一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性的情况下,在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构,不考虑内部逻辑结构,主要针对软件界面和软件功能进行测试。
在这里插入图片描述

黑盒测试是以用户的角度,从输入数据与输出数据的对应关系出发进行测试的。很明显,如果外部特性本身设计有问题或规格说明的规定有误,用黑盒测试方法是发现不了的。
在这里插入图片描述

作用

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

  • 功能不正确或遗漏;
  • 界面错误;
  • 输入和输出错误;
  • 数据库访问错误;
  • 性能错误;
  • 初始化和终止错误等。

黑盒测试的主要测试方法

等价类划分法;边界值分析法;因果图法;场景法;正交实验设计法;判定表驱动分析法;错误推测法;功能图分析法。

流程

  1. 测试计划

首先,根据用户需求报告中关于功能要求和性能指标的规格说明书,定义相应的测试需求报告,即制订黑盒测试的最高标准,以后所有的测试工作都将围绕着测试需求来进行,符合测试需求的应用程序即是合格的,反之即是不合格的;同时,还要适当选择测试内容,合理安排测试人员、测试时间及测试资源等。

  1. 测试设计与开发

将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程,并为每个测试过程选择适当的测试用例(测试用例选择的好坏将直接影响到测试结果的有效性)。

  1. 测试执行

执行测试开发阶段建立的自动测试过程,并对所发现的缺陷进行跟踪管理。测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成,测试人员应本着科学负责的态度,一步一个脚印地进行测试。

  1. 测试评估

结合量化的测试覆盖域及缺陷跟踪报告,对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。

优点

  1. 对于较大的代码单元来说,黑盒测试比白盒测试效率较高。
  2. 测试人员不需要了解细节,包括特定的编程语言。
  3. 有助于暴露与任务规格不一致或者有歧义的地方。
  4. 测试用例可以在需求规格完成之后马上执行。
  5. 从用户的角度zd测试,很容易被理解和接受。

缺点

  1. 不可能覆盖所有的代码, 覆盖率较低,大概只能达到总代码量的30%
  2. 如果测试人员,不被告知开发人员已经执行过的用例,在测试数据上会存在不必要的重复。
  3. 很多测试路径没有测试到。
  4. 不能直接对特定程序权段进行测试,改程序段可能隐藏更多错误。
  5. 大部分和研究相关的测试都是直接针对白盒测试的。
  6. 自动化测试的复用性较低。

工具选择

私用的话去找一些开源的工具就好,像OWASP ZAP、Arachni、Wfuzz、Nikto这几个都是免费开源的。
更多介绍:
https://www.cnblogs.com/parachuteInk/p/4419734.html

2.白盒测试

白盒测试又称结构测试或逻辑驱动测试。白盒测试是一种测试用例设计方法,盒子指的是被测试的软件,白盒指的是盒子是可视的,你清楚盒子内部的东西以及里面是如何运作的。"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。贯穿程序的独立路径数是天文数字。
在这里插入图片描述
在这里插入图片描述
采用什么方法对软件进行测试呢?常用的软件测试方法有两大类:静态测试方法和动态测试方法。其中软件的静态测试不要求在计算机上实际执行所测程序,主要以一些人工的模拟技术对软件进行分析和测试;而软件的动态测试是通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序,而达到发现程序错误的过程。在动态分析技术中,最重要的技术是路径和分支测试。下面要介绍的六种覆盖测试方法属于动态分析方法。

白盒测试的主要测试方法

白盒测试的测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、路径覆盖和程序变异。
白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。

六种覆盖标准发现错误的能力呈由弱到强的变化:

  1. 语句覆盖每条语句至少执行一次。
  2. 判定覆盖每个判定的每个分支至少执行一次。
  3. 条件覆盖每个判定的每个条件应取到各种可能的值。
  4. 判定/条件覆盖同时满足判定覆盖条件覆盖。
  5. 条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
  6. 路径覆盖使程序中每一条可能的路径至少执行一次。

要求

  1. 保证一个模块中的所有独立路径至少被使用一次。
  2. 对所有逻辑值均需测试 true 和 false。
  3. 在上下边界及可操作范围内运行所有循环。
  4. 检查内部数据结构以确保其有效性。

目的

通过检查软件内部的逻辑结构,对软件中的逻辑路径进行覆盖测试;在程序不同地方设立检查点,检查程序的状态,以确定实际运行状态与预期状态是否一致。
特点
依据软件设计说明书进行测试、对程序内部细节的严密检验、针对特定条件设计测试用例、对软件的逻辑路径进行覆盖测试。

实施步骤

  1. 测试计划阶段:根据需求说明书,制定测试进度。
  2. 测试设计阶段:依据程序设计说明书,按照一定规范化的方法进行软件结构划分和设计测试用例。
  3. 测试执行阶段:输入测试用例,得到测试结果。
  4. 测试总结阶段:对比测试的结果和代码的预期结果,分析错误原因,找到并解决错误。

优点

  1. 帮助软件测试人员增大代码的覆盖了吧,提高代码的质量,发现代码中隐藏的问题;

缺点

  1. 程序运行会有很多不同的路径,不可能测试所有的运行路径
  2. 测试基于代码,只能测试开发人员做的对不对,而不能知道设计的正确与否,可能会漏掉一些功能需求;
  3. 系统庞大时,测试开销会非常大。

局限

但即使每条路径都测试了仍然可能有错误。可能出现的情况如下:
穷举路径测试决不能查出程序违反了设计规范,即程序本身是个错误的程序。
穷举路径测试不可能查出程序中因遗漏路径而出错。
穷举路径测试可能发现不了一些与数据相关的错误。

工具挑选

白盒测试常用工具介绍:
https://blog.csdn.net/yrryyff/article/details/83715990

3.灰盒测试

灰盒测试,是介于白盒测试与黑盒测试之间的一种测试,灰盒测试多用于集成测试阶段,不仅关注输出、输入的正确性,同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整,但又比黑盒测试更关注程序的内部逻辑,常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。
在这里插入图片描述

定义

灰盒测试由方法和工具组成,这些方法和工具取材于应用程序的内部知识和与之交互的环境,能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。

学术含义

灰盒(Gray Box)是一种程序或系统上的工作过程被局部认知的装置。
灰盒测试,也称作灰盒分析,是基于对程序内部细节有限认知上的软件调试方法。测试者可能知道系统组件之间是如何互相作用的,但缺乏对内部程序功能和运作的详细了解。对于内部过程,灰盒测试把程序看作一个必须从外面进行分析的黑盒。
灰盒测试通常与web服务应用一起使用,因为尽管应用程序复杂多变,并不断发展进步,因特网仍可以提供相对稳定的接口。由于不需要测试者接触源代码,因此灰盒测试不存在侵略性和偏见。开发者和测试者间有明显的区别,人事冲突的风险减到最小。然而,灰盒测试相对白盒测试更加难以发现并解决潜在问题,尤其在一个单一的应用中,白盒测试的内部细节可以完全掌握。 灰盒测试结合了白盒测试和黑盒测试的要素。它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。灰盒测试由方法和工具组成,这些方法和工具取材于应用程序的内部知识和与之交互的环境,能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。灰盒测试涉及输入和输出,但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。

目的任务

软件测试是软件开发过程的重要组成部分,是用来确认一个程序的品质或性能是否符合开发之前所提出的一些要求。软件测试就是在软件投入运行前,对软件需求分析、设计规格说明和编码的最终复审,是软件质量保证的关键步骤。软件测试是为了发现错误而执行程序的过程。软件测试在软件生存期中横跨两个阶段,通常在编写出每一个模块之后就对它做必要的测试(称为单元测试)。编码和单元测试属于软件生存期中的同一个阶段。在结束这个阶段后对软件系统还要进行各种综合测试,这是软件生存期的另一个独立阶段,即测试阶段。

目的

第一是确认软件的质量,其一方面是确认软件做了你所期望的事情(Do the right thing),另一方面是确认软件以正确的方式来做了这个事件(Do it right)。
第二是提供信息,比如提供给开发人员或程序经理的反馈信息,为风险评估所准备的信息。
第三软件测试不仅是在测试软件产品的本身,而且还包括软件开发的过程。如果一个软件产品开发完成之后发现了很多问题,这说明此软件开发过程很可能是有缺陷的。因此软件测试的第三个目的是保证整个软件开发过程是高质量的。

测试任务

  1. 寻找Bug;
  2. 避免软件开发过程中的缺陷;
  3. 衡量软件的品质;
  4. 关注用户的需求。

目标

  1. 确保软件的质量;
  2. 提高软件质量功能。

感谢您的浏览!

转载于:https://blog.csdn.net/zhang150114/java/article/details/90694717

  • 1
    点赞
  • 40
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值