unit-testing - 黑盒可以覆盖白盒测试

Question

嗨，我是 SW 测试的新手。

WBT - 开发人员执行此操作，确保执行每一行并检查所有条件语句。

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

白盒测试和黑盒测试之间的真正区别是什么？对我来说，做一个广泛的输入，极端案例覆盖 BBT，这将是一个 WBT。

Answer 1

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

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

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

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

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

Answer 2

黑盒测试迫使您专注于接口而不是实现。从任何外部的角度来看，任何系统都是它的接口，所以你只需要证明它是有效的。从理论上讲，一个系统如何在内部实现并不重要，只要它完全按照它声称的去做。

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

因此，当黑盒方法迫使您编写接口规范以便您可以编写接口测试时，这会迫使项目全面运行得更好。QA 是一个比测试代码行是否写得好更广泛的过程。

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

我发现开发人员通常“过于接近代码”而无法对其进行充分或广泛的测试。他们通过他们拥有的知识做出假设并限制自己的测试范围。白盒测试促进了一种独立或同行评审的形式，其中假设更少，并且将执行更典型的用户行为（例如不正确或破坏性地使用系统）。

我会说你需要做这两种类型的测试。开发人员应该在构建时进行白盒测试（事实上，他们可能只有在知道代码时才能这样做！）。“质量保证人员”应该将黑盒测试作为用户验收测试的一部分，并证明它履行了其定义的功能。

Answer 3

WBT 可以为您提供更多额外的想法，因此可以使用 BBT 进行检查。您会发现直接查看代码更快的问题。从代码库的角度了解应用程序的工作原理将为您在产品开发中打开更多机会。

Answer 4

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

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

白盒测试技术检查系统的内部功能。进行测试以检查代码语句的覆盖率。白盒测试中的分支、路径或条件被视为低级测试。此测试的另一个名称是玻璃盒、透明盒、透明盒或基于代码的测试。

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

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

视觉学习者的资源和漂亮的图像。