“单元测试”属于白盒测试还是黑盒测试？答案

【问题标题】：Does "Unit Testing" falls under white box or black box testing?“单元测试”属于白盒测试还是黑盒测试？
【发布时间】：2012-03-27 15:44:57
【问题描述】：

“单元测试”属于白盒测试还是黑盒测试？还是与其他两种测试完全不同？

【问题讨论】：

【解决方案1】：

我认为article by Kent Beck 更多地提到了 TDD 和单元测试，这很好地总结了这一点。基本上，这取决于您实际编写测试的方式*。 Here is another article on the subject 这可能有助于澄清事情。

*如果您在应用程序中进行测试，则它是白盒。如果您正在测试它，就像一个局外人只会调用您面向公众的 API 一样，那么它就是黑盒。

【讨论】：

在这两种情况下，它们都是白盒测试。似乎许多人混淆了这两种测试的定义。单元测试只是测试“代码”的每个单元类。这是一个白盒测试。黑盒测试测试您的“应用程序”的整体功能。如果需要，您可以编写任何方式并使其自动化。但是单元测试......嗯，它总是白盒测试:)
如果您在代码之后编写单元测试并且在代码的帮助/基础上 - 单元测试是白盒测试。如果您在代码之前编写单元测试或根据规范编写单元测试 - 单元测试就是后备箱测试。
在我看来，这取决于您对“单位”的定义。当将代码类作为 the “单元”进行测试时，您会了解周围的代码库，从而使其成为白盒/玻璃盒测试。但是，如果您说 the “单元”是您作为用户使用的整个应用程序，那么它是一个 backbox 测试，因为您作为测试用户无法查看 inside “单元”又名应用程序。但是，如果应用程序由不同的模块组成，我会将后者更多地称为集成测试。在这种情况下，您将测试所有模块如何在它们的集成中协同工作。

【解决方案2】：

白盒测试的常用标准是执行路径和数据结构敏感度。这些有时被称为“分支测试”、“路径测试”、“数据流测试”。请参阅有关白盒测试的 Wikipedia。

也就是说，单元测试是指测试在系统结构中发生的级别，而白盒和黑盒测试是指在任何级别，测试方法是否基于内部设计或仅根据设备的外部规格。

因此，如果您的单元测试对您正在测试的单元中的所有执行路径和数据结构都敏感，那么它就是白盒测试。但是，如果您的单元不能对单元的大部分路径和数据结构敏感，那么它就不能声称是白盒测试。

请注意，在某些组织中，单元测试称为白盒测试，无论单元测试是否基于单元的设计，而不仅仅是其 API。最好不要在这一点上与你的老板争论。

【讨论】：