黑盒白盒

oac

关于黑盒与白盒，我是从the art of software testing这本书上读到的，以下是我的一些理解，欢迎大家交流讨论。
关于白盒：
One important testing strategy is black-box, data-driven, or input/output driven
testing. To use this method, view the program as a black box.
Your goal is to be completely unconcerned about the internal behavior
and structure of the program. Instead, concentrate on finding circumstances
in which the program does not behave according to its
specifications.
In this approach, test data are derived solely from the specifications
(i.e., without taking advantage of knowledge of the internal structure
of the program).
If you want to use this approach to find all errors in the program,
the criterion is exhaustive input testing, making use of every possible
input condition as a test case.
我的理解是黑盒不关心内部逻辑与结构，仅按照规格说明中的一些输入输出定义来测试，重点的测试对象是规格说明中那些没有明确定义的行为，利用每一种可能的输入条件作为用例。
再来看一下白盒的定义：
Another testing strategy, white-box or logic-driven testing, permits you
to examine the internal structure of the program. This strategy
derives test data from an examination of the program’s logic (and
often, unfortunately, at the neglect of the specification).
The goal at this point is to establish, for this strategy, the analog to
exhaustive input testing in the black-box approach. Causing every
statement in the program to execute at least once might appear to be
the answer, but it is not difficult to show that this is highly inadequate.
Without belaboring the point, since this matter is discussed in
more depth in Chapter 4, the analog is usually considered to be
exhaustive path testing. That is, if you execute, via test cases, all possible
paths of control flow through the program, then possibly the program
has been completely tested.
白盒主要检查内部逻辑与结构，确保所有控制流的分支路径都能执行一遍，这些通常不会定义在规格说明中。
有一种观点认为从执行测试时代码是否可见来区分白盒与黑盒，我觉得有些片面，通常我们在设计测试用例时，这两个方面都会考虑，在白盒方面，会咨询开发人员，确保路径覆盖尽量全面，我们这边测试用例都会经过相关开发的评审。所以通常测试人员做测试时，基本都是介于黑盒与白盒之间的，没有很纯的黑盒测试。许多人说做底层测试，接触不到代码，感觉进步不大，跟黑盒与白盒其实没多大关系。