黑盒可以覆盖白盒测试

Question

你好，我是新来的SW测试。

WBT-Developer这样做，确保每一行都被执行，并检查所有条件语句。

BBT——在黑盒中，我可以做与WBT相同的事情，我可以输入各种参数并检查输出，确保通过生成测试用例覆盖所有条件语句，还可以覆盖循环执行。

白盒测试和黑盒测试的真正区别是什么？对我来说，这看起来像是，做一个广泛的投入，角落案例覆盖BBT，这将是一个WBT。

Answer 1

黑盒测试——在不检查内部代码结构、实现细节和软件内部路径知识的情况下测试AUT应用程序功能的测试技术。

黑盒测试告诉你软件系统的输入和输出，你不必担心软件程序的知识。检查用户对性能和应用程序的看法。

白盒测试技术检查系统的内部功能。测试是为了检查代码语句的覆盖面。白盒测试中的分支、路径或条件被认为是低级测试。这种测试的另一个名字是玻璃框、透明框、透明框或基于代码的测试。

这种类型的测试需要技术知识和测试专业知识。知识的实现对于执行白盒测试也很重要。因此，白盒测试由软件开发人员或软件测试专家执行。在白盒测试中发现的最常见错误有：

语法错误逻辑错误设计错误

为视觉学习者提供资源和良好的形象。

Answer 2

黑盒测试迫使你关注接口而不是实现。从任何外部角度来看，任何系统都是它的接口，所以你只需要证明它是有效的。从理论上讲，一个系统内部如何实现并不重要，只要它确实做了它声称做的事情。

因此，黑盒测试迫使您关注系统的需求和定义。有时，最好“后退一步”，与用户或客户确认它应该做什么，以便您可以适当地测试它。如果一个系统满足了它的需求，那么它就是按定义工作的。许多系统没有正确定义，这就是导致许多QA失败的原因，部分原因是意见分歧，而不是实际的错误。

因此，由于黑盒方法迫使您编写接口规范，以便您可以编写接口测试，因此这迫使项目全面运行得更好。质量保证是一个比测试代码行写得好更广泛的过程。

黑盒方法的一个缺点是系统可能只是在工作，内部一片混乱！或者如果测试没有100%完成，那么你可能没有覆盖所有的路径或场景。大多数单元测试工具都有覆盖图，即使在黑盒测试期间也会这样做，所以你仍然可以看到你是否需要添加更多的测试，而不需要“了解”太多的代码。（然而，代码覆盖率报告具有误导性，因为大多数系统每个代码行都有许多场景，即上下文、数据、输入等的变化。因此，相同的代码需要在数据矩阵上运行，以确保涵盖所有真实世界的场景）。

我发现开发人员往往“离代码太近”，无法对其进行充分或广泛的测试。他们根据自己的知识做出假设，并限制自己的测试范围。白盒测试有助于一种独立或同行评审的形式，在这种形式中，假设较少，将执行更典型的用户行为（例如错误或破坏性地使用系统）。

我想说你需要做两种类型的测试。开发人员应该进行白盒测试（事实上，他们可能只能在了解代码的情况下进行测试！）在他们建造的时候。“QA人员”应进行黑盒测试，作为用户验收测试的一部分，并证明其满足其定义的功能。

Answer 3

测试的目标是确保事情按预期工作，所以黑盒和白盒测试的主要区别是这些技术考虑的表面，以确定一个软件是否正常工作：

• 黑盒测试将软件视为黑盒。测试操作发生在用户界面级别，断言基于从系统外部可观察到的系统响应，主要是系统响应，但也包括响应时间和其他从用户角度可观察到的事件
• 白盒测试，也称为玻璃盒测试，将软件视为一个透明的盒子，因此从测试人员的角度可以看到它的内部结构。测试操作发生在比用户界面级别更低的级别，并从该较低级别向上对系统行为进行断言，包括从用户角度可能无法观察到的事件（代码分支错误、错误日志、部分操作响应时间等）

例如，在给定的用户界面中，如果在输入值X后，我们期望响应Y，这就是用户得到的，那么从黑盒的角度来看，测试将是成功的，但是如果查看代码执行，我们知道某个事件对于最终用户来说是不可见的，当它应该被触发时，那么从白盒的角度来看，测试将失败。

就代码的哪些区域被执行而言，黑盒和白盒测试之间肯定有一些重叠，但是只有当从用户界面可以执行所有代码行和分支时，它才可能是完全重叠的。此外，在透视图方面根本没有重叠，因为在一个透视图中，您充当最终用户，而在另一个透视图中，您直接查看代码语句和分支。

最后要注意的是，谁最终会做什么类型的测试完全取决于软件开发过程、角色和可用的技能。如果你的团队没有可用的手动测试人员，那么其他人将不得不冒充最终用户进行测试。如果你的团队有技术含量高的测试人员，白盒测试可以由他们成功地执行。