什么是灰色 Box 测试？技术，示例

什么是灰色 Box 测试？

灰色 Box 测试与验证 （也拼作 Gray） Box 灰色测试（Grey Testing）是一种软件测试技术，它在对软件产品或应用程序的内部结构了解有限的情况下对其进行测试。灰色测试的目的是…… Box 测试的目的是查找和识别由不当的代码结构或不当的应用程序使用引起的缺陷。

在此过程中，通常会识别出与网络系统相关的特定上下文错误。该技术提高了 测试覆盖率 通过关注复杂系统的所有层面，而不是关注其中的某一层面。

灰色 Box 测试是一种结合了以下要素的软件测试方法： 白色 Box 测试与验证 和 黑色 Box 测试与验证三者之间的区别归根结底在于测试人员能够看到多少内部结构：

• 白色 Box 测试内部结构（代码）的方法已为人所知。
• 黑色 Box 内部结构（代码）的测试方法未知。
• 灰色 Box 内部结构（代码）的测试方法已部分了解。

下图将这三种方法置于同一可见度尺度上。

In 软件工程， 灰色的 Box 测试能够对应用程序的两个方面进行测试，包括表示层和其背后的代码。它主要在以下方面非常有用： 集成测试 和 渗透测试.

灰色示例 Box 测试： 在测试网站功能（例如链接或孤立链接）时，如果测试人员遇到这些链接的问题，可以立即在 HTML 代码中进行更改并实时检查。

为什么是灰色 Box 测试与验证

灰色 Box 进行测试的原因如下：

• 它兼具黑盒测试和白盒测试的优点。
• 它结合了开发人员和测试人员的意见，提高了整体产品质量。
• 它减少了测试功能类型和非功能类型的漫长过程所带来的开销。
• 它能让开发人员有足够的空闲时间来修复缺陷。
• 测试是从用户的角度进行的，而不是从设计者的角度进行的。
• 测试人员可以看到故障发生的层，因此可以解释故障原因，而不仅仅是报告故障。

灰色 Box 测试与黑色 Box 对阵白队 Box 测试与验证

这三种方法与其说是相互竞争的选项，不如说是三种不同的访问层级，每一种都回答了不同类型的问题。将它们并列比较，就能让选择变得清晰明了。

大多数球队都会使用这三种方法。 软件测试生命周期而灰盒层通常是用户界面和数据存储之间的缺陷被发现的地方。

灰色 Box 测试策略

执行灰色 Box 在测试中，测试人员无需访问源代码。测试的设计基于对算法、架构、内部状态或其他程序行为高级描述的了解。

执行灰色 Box 测试：

• 它采用了黑盒测试的直接方法。
• 它基于需求驱动的测试用例生成，因此在通过断言方法测试程序之前，它会预先设定所有条件。

用于灰色制作的技术 Box 测试内容包括：

• 矩阵测试： 该技术包括定义程序中存在的所有变量，以及每个变量所带来的风险，以便显示未使用的变量和高风险变量。
• 迭代测试: 检查先前版本中的更改是否导致新版本中程序的其他方面出现倒退。这可以通过多种策略来实现，例如重新测试所有内容、重新测试高风险用例以及在防火墙内重新测试。
• 正交阵列测试 或 OAT： 以最少的测试用例实现最大的代码覆盖率。
• 模式测试： 基于先前系统缺陷的历史数据进行的灰盒测试。与黑盒测试不同，灰盒测试是对黑盒测试和灰盒测试的混合测试。 Box 测试会深入代码，确定故障发生的原因。

灰色 Box 方法论通常采用自动化方式 软件测试工具 为了进行测试，系统会创建存根和模块驱动程序，这样测试人员就无需手动生成代码。

灰度操作步骤 Box 测试内容包括：

• 第一步：确定输入。
• 步骤 2：确定输出结果。
• 步骤 3：确定主要路径。
• 步骤 4：确定子功能。
• 步骤 5：制定子功能的输入。
• 步骤 6：为子功能开发输出。
• 步骤 7：执行子功能的测试用例。
• 步骤 8：验证子函数的结果是否正确。
• 步骤 9：对其他子功能重复步骤 4 至 8。
• 步骤 10：对其他子功能重复步骤 7 和 8。

Grey 的测试用例 Box 测试可能涵盖图形用户界面、安全性、数据库、浏览器和操作系统等方面的问题。每个生成的测试用例仍然需要进行常规的测试。 测试用例 属性，因为无法根据自身描述重现的案例在回归分析中几乎没有用处。

灰色地带 Box 测试方法

当缺陷只能通过同时观察两层结构才能诊断时，这种技术便能发挥作用。以下是它最常应用的场景：

• 基于数据库的工作流： 通过用户界面执行操作，然后直接查询结果行，以确认值、类型和关系是否按预期存储。
• Web 服务和 API： 发送请求后，将响应状态、标头和有效负载与已发布的配置进行比较。tract，这是日常用语形式 API测试.
• 集成点： 检查跨越两个模块边界的消息时，这两个模块都被视为正在运行的系统，而不是源文件。
• 安全评估： 渗透测试人员获得普通用户帐户和架构概览后，即可模拟内部人员的角色，这是标准的灰盒测试模型。
• Web应用程序和图形用户界面： 在部分可见标记和请求流程的情况下，检查断链、孤立页面、会话处理和客户端验证。

综上所述，由于问题在进一步扩散到其他环节之前就被发现并得到解释，因此系统缺陷的总体成本得以降低。 系统测试 或生产。

灰色 Box 测试工具

没有工具能执行灰色 Box 单独进行测试。该类别需要的是接口驱动程序、底层检查工具以及将两者结合起来的脚本方法。

• API 和 Web 服务客户端 如 Postman 和 SoapUI用于发出请求并断言状态码和响应主体。
• 数据库客户端和 SQL 查询工具用于验证接口操作后持久化的状态。
• 浏览器开发者工具和HTTP代理 如 Burp Suite用于在安全会话期间检查和修改请求。
• UI自动化框架 如 Selenium用于驱动内部的表示层 自动化测试 套房。
• 日志和监控工具用于将观察到的故障与应用程序当时内部记录的内容进行关联。

选择不如接线重要：除非接口驱动程序和检查步骤在同一个脚本流程中运行，否则结果是两次单独的手动检查，而不是一次灰盒测试。

灰色 Box 测试挑战

部分可见性引入了两种纯粹方法所没有的问题，以下是团队最常遇到的问题：

• 当被测组件发生某种故障时，可能会中止正在进行的操作，导致剩余的序列无法执行。
• 测试可能完整执行，但结果内容不正确，因此验证步骤必须检查值而不是完成情况。
• 完全代码路径覆盖是不可能的，因为测试人员永远看不到白盒测试会到达的每个分支。
• 测试所依赖的设计文档可能已经过时，过时的模式或接口规范会悄无声息地使测试设计失效。
• 测试人员需要既有领域知识又有技术深度，这是一个比较窄的技能要求，招聘起来比较困难。
• 分布广泛且大量tracTED架构使得很难将观察到的故障归因于特定的内部组件。

这些局限性表明，应将灰色疗法应用于其他疗法。 Box 测试只是多个层面中的一个层面，而不是其他层面的替代，这一点在更广泛的范围内都得到了体现。 软件测试技术 和 软件测试类型它与旁边环境自然融合。 功能测试 以及诸如以下规范驱动的方法： 基于模型的测试.

常见问题