【发布时间】：2009-12-15 08:56:52
【问题描述】：
我试图从一个与另一个的比较方面来理解它。
是可以看到代码的白盒测试和看不到代码的黑盒测试吗？
【问题讨论】：
标签： testing black-box white-box
【发布时间】：2009-12-15 08:56:52
【问题描述】：
Q) 是可以看到代码的白盒测试和看不到代码的黑盒测试吗？
黑盒测试
这是一个将输入提供给系统并检查系统输出的过程，而不用担心系统如何生成输出。它也被称为行为测试、数据驱动测试或 I/O 驱动测试、功能测试。
仅基于需求分析（规范、用户文档等）的测试
优点：
1) 在较大的代码单元上比玻璃盒测试更有效。
2) 测试员和程序员是相互独立的。
3) 根据用户的观点进行测试。
4) 一旦规范完成，就可以设计测试用例。
缺点：
1) 它可能会留下许多程序路径未经测试。
2) 实际上只能测试少量可能的输入，以测试所有可能的输入。 输入流几乎要花很长时间。
白盒测试
这是一个向系统提供输入并检查系统如何处理输入以生成输出的过程。
测试人员必须具备代码知识。
优势：
1) 这种类型的测试有助于发现结构层面的缺陷。测试低于顶层和功能层以发现缺陷
缺点：
1) 不能确保满足用户要求
2) 不确定决策、条件和路径。
【讨论】：
-
很好的答案。不过好像最后一句被截断了？
-
白盒测试的缺点还在于它与实现高度耦合，并且只要对不改变行为的实现进行偶然更改，就需要进行更改。所以白盒测试的维护性更高。
基本上是的。
在黑盒测试中，您测试对象的预期输入是否会产生预期的输出，而无需更改底层代码。
在白盒测试中，您可以看到代码并测试所有可能的路径。
【讨论】：
-
他们应该称之为明盒测试而不是白盒测试。
-
另外请注意，如果您有一个代码分支无法使用有效的黑盒测试用例进行练习，那么您要么尝试测试一些偶然且不相关的东西，要么您发现了一些死代码。
-
我有一个问题：“你可以通过它测试所有可能的路径”。那么我应该做哪一个呢？通过程序的UI测试所有可能的路径还是只是在代码中编写测试场景来做测试？
维基百科：
White box testing 使用 系统内部视角 基于内部设计测试用例 结构体。它需要编程 识别所有路径的技能 软件。
对
Black box testing 需要一个 测试的外部视角 派生测试用例的对象。
【讨论】：
是的，你几乎拥有它。黑匣子在不了解（或访问）任何内部事物的情况下测试外部事物。白盒测试能够查看（并且可能修改）您正在测试的内部状态。它们都有不同的用途。单元测试通常（但不总是）是白盒测试。
【讨论】：
-
单元测试通常在非常精细的级别测试特定功能。它们是最低级别的测试，通常由应用程序的开发人员创建并形成一个由数百或数千个测试套件组成的回归测试套件，可以在任何情况发生变化时运行以检测回归。
白盒测试
一旦知道s/w的内部工作，就进行测试以确保s/w的所有内部操作都按照规范进行。
黑盒测试
一旦为每个软件组件设计了指定的功能，就会执行测试以确保每个功能都在执行。
【讨论】：
白盒测试就像使用（玻璃）透明盒进行输入和验证输出 即在此您提供输入观察输入处理（功能流、变量值、计算）并验证输出是否符合预期。
黑盒测试就像使用（木制）不透明盒子提供输入和验证输出 即在此您提供输入不要观察输入处理（功能流、变量值、计算）并验证输出是否符合预期。
【讨论】：
白盒测试：在白盒测试中，我们使用系统内部结构的知识，即测试人员需要具备编程语言和编码知识。
而在黑盒测试中，我们忽略了系统的内部，专注于输入和输出之间的关系。
【讨论】：
白盒测试：- 需要编程和实施知识。
黑盒测试：- 不需要编程和实施知识。
【讨论】：
-
您可以编写黑盒单元测试。对于那些你绝对需要能够编写代码的人。