作者: cleverman 时间: 2007-7-8 10:49 标题: 到底什么是白盒测试？
白盒测试，黑盒测试是刚学测试时候的基本概念。我们大部分人可能做的都是黑盒测试，也就是看不到代码，对产品进行功能测试。
可是什么才算是白盒测试呢？
Code coverage算不算白盒测试？
自己和别人一样做黑盒测试，可是自己没事的时候也看看代码，在黑盒测试的时候发现bug，自己可以去在代码里定位，找到root cause。那算不算是白盒测试呢？
如果不算的话，因为测试的过程中也分析了代码，明显不算是黑盒测试。如果算得话，自己跟同事做同样的工作，只是自己没事看看代码就可以说别人做黑盒，自己做白盒？
要不算灰盒测试？
我们公司并没有白盒，黑盒测试的概念。可是这又是测试最基本的概念。我有点confused.大家讨论一下好吗？
作者: wyzwise 时间: 2007-7-8 11:43
White box 就是在全部理解系统的基础上去go through source code和architecture documents。
Code coverage（当然是拉） 是White box 的一个重要的优势和black box比较。。
首先做white box 的时候要有计划，不要无计划地去看source code, 应该去根据你所在的project的design document去做特定地区的code 分析，还要看看algorithm..这个部分主要通过peer review去发现，当你感觉可能有问题的时候，应该去和senior developer 讨论，并把问题，写成书面的报告报告给经理。。。 有经理决定它的priority. 在决定是否是需要fix这个。。。
现在你是有点混淆了white box 和grey box的概念， white box 是在正常情况下，你的project 一切的design documents 都很全的情况下去进行的。意味这你有 full knowledge of the system。
而grey box是在limited knowledge of the internals of a system..只有在这个project 的 design documents 不全的情况下，进行的。。。
不知道有没有解决你的问题：）
[ 本帖最后由 wyzwise 于 2007-7-8 12:00 编辑 ]
作者: shanxi 时间: 2007-7-8 11:52
白盒、黑盒
自动化、手工
回归等等
具体做事的时候没有区分的那么细致，很少是只做其中一种，基本是交叉着本着解决测试问题的效率来采用。
作者: cleverman 时间: 2007-7-8 12:02
QUOTE:
原帖由 wyzwise 于 2007-7-8 11:43 发表 
White box 就是在全部理解系统的基础上去go through source code和architecture documents。
Code coverage（当然是拉） 是White box 的一个重要的优势和black box比较。。
首先做white box 的时候要有计划 …
那我说的第二种情况,算不算白盒?
还有就是能不能举个灰盒的例子.
作者: cleverman 时间: 2007-7-8 12:05
QUOTE:
原帖由 shanxi 于 2007-7-8 11:52 发表
白盒、黑盒
自动化、手工
回归等等
具体做事的时候没有区分的那么细致，很少是只做其中一种，基本是交叉着本着解决测试问题的效率来采用。
我也有这种认为,感觉测试很多理论上的东西,在工作中很不相关.
我现在倒是感觉,真正用的上的,还是开发的理论,而不是测试的理论.
作者: wyzwise 时间: 2007-7-8 12:09
QUOTE:
原帖由 cleverman 于 2007-7-8 12:05 发表
我也有这种认为,感觉测试很多理论上的东西,在工作中很不相关.
我现在倒是感觉,真正用的上的,还是开发的理论,而不是测试的理论.
这个一部分是对得，我以前得公司，计划，管理不是很好，所以每次经常什么东西都混在一起，不是很明确。。。
其实如果管理好，这些测试的理论是很有用得。。。我现在得team就是按照成型得MVC得testing phase一步一步走，每一步每个在team里面得人都很清楚，都知道什么时候在什么事情。。。 测试还是要根据不同阶段做不同得事情得。。。
作者: seifer1754 时间: 2007-7-8 13:40
既然白盒，黑盒 的概念你都知道了，那么举个例子来说明一下好了。
void test(x)
{
if (x<0) return;
if( (x+1) < 0 )
return 9;
}
看看上面这个函数，很明显 第二个 if 判断是永远不可能为 真，也就是说，采用黑盒的方式，用输入 参数x 来测试，是永远不可能出现9 这个输出的。
那么我们用不用考虑第二个if的成立情况呢？
我这个例子是简单了一些，也没有什么意义。不过在实际的开发中，还是会出现类似无法被黑盒测试覆盖的路径的，也许这些路径在正常情况下永远不可能被走到，可是我们在做软件设计的时候，必须要考虑到会出现的异常，而专门设计了一个对这种异常情况做出处理的分支。
例如，计算机的寄存器被恶意软件所篡改，如果没有一个对异常处理的分支，很可能会造成系统的崩溃。
那么，既然这种分支需要测试，我们就必须想办法来覆盖这个分支，这就是白盒测试需要考虑的事情了。我们可以在这个分支判断上设置断点，然后通过修改寄存器的方法来改变装载参数x的 寄存器的值，从而使程序能够走 x+1<0 的分支，使输出结果为 9 。
这就是白盒测试需要考虑的事情，是对程序的逻辑与路径进行分析测试。
我举的例子可能不是特别恰当，希望你能够明白。
作者: cleverman 时间: 2007-7-8 14:21
QUOTE:
原帖由 seifer1754 于 2007-7-8 13:40 发表
既然白盒，黑盒 的概念你都知道了，那么举个例子来说明一下好了。
void test(x)
{
if (x
我明白你的例子，不过你认为我说的第二种情况算白盒测试吗？也就是说跟黑盒测试没有任何区别。可是，遇到bug自己可以去代码里找到root cause.
作者: wyzwise 时间: 2007-7-8 14:32
"可是自己没事的时候也看看代码，在黑盒测试的时候发现bug，自己可以去在代码里定位，找到root cause。那算不算是白盒测试呢？"
这个不是testing…是bug fixing:)
作者: cleverman 时间: 2007-7-8 14:32 标题: 还有
“例如，计算机的寄存器被恶意软件所篡改，如果没有一个对异常处理的分支，很可能会造成系统的崩溃。
那么，既然这种分支需要测试，我们就必须想办法来覆盖这个分支，这就是白盒测试需要考虑的事情了。”
请问你们公司是必须要测试这种case吗？我问题的意思是，概念可能没什么难理解的，可是到了实际中去，情况就复杂了。以我的经验，你说的这种情况是不需要进行测试的。因为，重要的是怎样防止恶意软件侵入你的计算机，真正侵入进来之后，就麻烦大了。如果要考虑这种情况的话，那可以设计无数的case了，不算很现实。请问，你用“必须”这个词是理论上来说呢，还是你们公司就这么要求的呢？
还有就是以我所知，无论是系统软件还是杀毒软件都是注重恶意软件的侵入，而不是侵入之后如何保证自己的程序不受影响。当然了，现在的UAC是这样考虑的，不过他们也不是在硬件的level来进行测试的。
作者: cleverman 时间: 2007-7-8 14:35
QUOTE:
原帖由 wyzwise 于 2007-7-8 14:32 发表
"可是自己没事的时候也看看代码，在黑盒测试的时候发现bug，自己可以去在代码里定位，找到root cause。那算不算是白盒测试呢？"
这个不是testing…是bug fixing:)
不对。真正好的测试人员report bug的时候，是要写明白代码的root cause的。这只是发现bug，怎么能算fix呢？
真正的fix是要开发人员来做的，测试人员没有这个权力。
你找到代码里的问题，不代表就解决了这个问题。明白吗？
作者: seifer1754 时间: 2007-7-8 14:43
通过黑盒测试的方法发现bug,然后去代码中定位，找出原因。
这个不属于白盒测试，白盒测试和黑盒测试 在测试的理念上是不同的，也就是说，设计的用例都是不同的，采用黑盒测试方法设计的用例，不见得能够100%的覆盖代码的所有路径和逻辑。例如我上文举的例子。 虽然你能够根据黑盒测试方法发现的bug而定位错误，这也只能说明你的编程功底比较强，对代码的理解比较强。可是这并不能说明你设计的用例能够覆盖所有的代码逻辑和路径。也就是说，这并不能说明你做的是白盒测试。
在嵌入式白盒测试领域，经常需要追踪寄存器和内存，这些都是典型的白盒测试，你需要在程序中设置很多断点来追踪程序流程。而黑盒测试，只是考虑函数的输入和输出，对程序的内部逻辑是忽略的，很可能，同样的输入和输出，代码采用了不符合需求的方式而实现了。
所以，即便你能够定位代码的错误，可是你做的是黑盒测试，手中获得的可能只是一份功能需求文档，而不是一份详细的代码流程图，你定位的错误，只是表示程序的功能有问题，不能证明程序的逻辑设计有问题。
这就是白盒测试与黑盒测试的根本区别。
作者: cleverman 时间: 2007-7-8 15:08
那么什么是黑盒测试呢？不是说黑盒测试是不接触代码的吗？我以上的例子是有review code的工作的，应该和黑盒测试定义相矛盾呀。
我明白你说的嵌入式白盒测试是属于白盒测试，可是白盒测试肯定不限于只是这种类型吧。按照你的理解，如果我有详细的代码流程图，做黑盒测试，而我定位的错误也发现了是逻辑设计有问题，那怎么算呢？你也不能说我用黑盒测试，review代码就一定不能发现逻辑设计有问题吧？
为什么要问这个问题呢？我所在的公司，当然不是测试嵌入式的，是测试系统软件的。我们有所有的资源，可是我们的test case是按照功能来设计的，也就是说不会在代码级设计测试用例。如果只是设计，执行，那么肯定是算黑盒测试。可是我们也review code，要求发现bug尽量找到root cause写到report里。因此，我们有详细的代码流程图，也可以发现逻辑设计有问题。我们甚至要在functional spec阶段就要involve进去。当然了，在找root cause的时候，我们也要用debugging tools,向你所说，要追踪内存，寄存器，堆栈等等。那么这算不算白盒测试呢？
作者: cleverman 时间: 2007-7-8 15:11
你以上的解释有点已经先定性了我就是黑盒测试，在这个基础上来解释的。我想现在唯一的区别就是从功能设计test case和从代码设计test case了。
但是，我想这不是黑盒，白盒的根本区别。你说的根本区别也不是这个。
作者: seifer1754 时间: 2007-7-8 15:43
如果要详细的划分黑盒与白盒，不是从是否能看到代码来划分。
我想应该是从设计case的角度去划分。
例如，作功能测试，测试一个登陆窗口，这是典型的黑盒测试了，那么你肯定是根据需求文档，输入有代表性的字符来验证这个窗口是否正常。如果输入某一个特殊字符，窗口的功能实现出现问题，你也许可以定位到某一个条件判断语句有异常。然后根据测试的步骤，异常的现象，自己推测的原因来提交缺陷报告。
可是你所设计的用例，都是围绕着这个窗口的功能而设计的，你肯定不会去考虑这个实现这个窗口的代码有多少个循环，多少个判断。
但是用白盒测试来测试这个窗口的代码，就需要根据具体的代码流程图来设计，要判断程序的逻辑，实现的方法 是否与程序设计需求一致。甚至需求中会规定内存分配需要多少空间，你也要对内存空间进行用例设计与测试。 所有的设计都是根据代码需求文档来设计的。
你介绍了你工作的内容，能够接触到详细的代码流程，甚至也需要追踪代码逻辑。那么我认为，如果你设计的case， 是为了追踪代码的逻辑而设计的，这就是一个白盒测试用例，你做的就是一个白盒测试工程师所应该做的事情了。
虽然公司可能把你划分为黑盒测试，可是不代表你所有的case都是采用黑盒的角度去设计，也不代表你不能根据代码流程发现逻辑错误。
我们只是讨论黑盒与白盒测试的区别，不代表一个黑盒测试工程师就无法接触到白盒测试。
一个好的测试工程师确实需要能够协助开发人员定位错误，可是最需要的是能够采用多角度去设计
case，然后发现bug。
至于我楼上举的例子，因为我是做航空嵌入式系统的，所以对代码的异常处理非常严格，要求所有的路径都要覆盖一次以上，才有了“必须”这一说法，有些职业化了，到让别人产生了误解。
作者: wyzwise 时间: 2007-7-8 17:28
QUOTE:
原帖由 cleverman 于 2007-7-8 14:35 发表
不对。真正好的测试人员report bug的时候，是要写明白代码的root cause的。这只是发现bug，怎么能算fix呢？
真正的fix是要开发人员来做的，测试人员没有这个权力。
你找到代码里的问题，不代表就解决了这 …
也许你们公司的特殊要求吧。。。我对我的team的要求是，tester不需要去找到原因，找到哪里出了问题。。如果每一个tester都花时间去看code，找root cause，这个涉及到成本问题，毕竟人工是一个人每小时上百人民币。。。呵，cost and timeframe 是一个trade off…
最省事省力的做法是，找到问题，report to manager,assign to the function owner…fix bug…new build version…regression…….这个是常规做法。。。
还有一个就是white box 和black box 。。简单说是，white box is to test the design(defect),black box is to test the system without going through the code inside…
作者: scorix 时间: 2007-7-8 18:25
楼主应该自问一下：“在发现错误之前的测试过程中，我是否只关心软件的内部构造？”
答案如果是肯定的，那么就是白盒测试。
至于定位错误，我想大部分的情况都要翻看代码才能确定哪里出了问题，但这不代表就是白盒测试。
作者: DERYCK 时间: 2007-7-8 21:14
看了以上几位的看法，我觉得还是在测试过程中你是根据外部功能设计的用例进行测试，还根据内部代码的结构设计的用例进行测试。
只要分清楚这两种区别就明白什么是黑盒测试和白盒测试了。
我个人认为定位错误不是测试。
作者: cleverman 时间: 2007-7-9 01:18
QUOTE:
原帖由 scorix 于 2007-7-8 18:25 发表
楼主应该自问一下：“在发现错误之前的测试过程中，我是否只关心软件的内部构造？”
答案如果是肯定的，那么就是白盒测试。
至于定位错误，我想大部分的情况都要翻看代码才能确定哪里出了问题，但这不代表就是 …
不对呀。我们在functional spec的时候就involve进去了，很关心软件的内部构造呀。我们对Windows Internal Knowledge的实现都要精通，更不要说自己的软件了。好像这不能说明是白盒测试呀。
作者: cleverman 时间: 2007-7-9 01:23
QUOTE:
原帖由 wyzwise 于 2007-7-8 17:28 发表
也许你们公司的特殊要求吧。。。我对我的team的要求是，tester不需要去找到原因，找到哪里出了问题。。如果每一个tester都花时间去看code，找root cause，这个涉及到成本问题，毕竟人工是一个人每 …
不是我们公司有特殊要求，最top的公司很多都这样要求的。对于一个strong的测试人员来说，他还需要跟开发人员讨论solution options，在fix之前就发现可能引起的其他问题。别说测试人员了，就是pm很多都很精通coding。他们都会code review去报bug。这里的人工比你们贵多了。还有就是，
white box is to test the design. What design? internal design or funcationality design, or code design?
Backbox is to test the syste without going through the code inside. If so, my second example is a not a black box at all. right?
[ 本帖最后由 cleverman 于 2007-7-9 01:24 编辑 ]
作者: cleverman 时间: 2007-7-9 01:27
QUOTE:
原帖由 DERYCK 于 2007-7-8 21:14 发表
看了以上几位的看法，我觉得还是在测试过程中你是根据外部功能设计的用例进行测试，还根据内部代码的结构设计的用例进行测试。
只要分清楚这两种区别就明白什么是黑盒测试和白盒测试了。
我个人认为定位错误不 …
不只是定位错误，是要找到错误的root case。 不然的话，你不能定bug的优先级别和严重程度。
比如我不久前发现了一个bug，会导致windows重启。你怎么定优先级呢和严重程度呢？windows重启也够常见了吧？
因此一定要找到root cause，最后我们发现是一个安全漏洞，可能被黑客利用进行攻击。因此就给了最高的优先级和严重程度。开发人员当天就fix了。
这就是我们为什么要求测试人员有这个能力。大公司里，老板不可能管任何事情，很多都需要测试人员来drive。但是，你必需要有个好的判断，不能出错。
[ 本帖最后由 cleverman 于 2007-7-9 06:45 编辑 ]
作者: cleverman 时间: 2007-7-9 06:43 标题: 回复 #15 seifer1754 的帖子
随便Google一下definition of black box and white box.
Blackbox:Also known as functional testing. A software testing technique whereby the internal workings of the item being tested are not known by the tester. For example, in a black box test on a software design the tester only knows the inputs and what the expected outcomes should be and not how the program arrives at those outputs. The tester does not ever examine the programming code and does not need any further knowledge of the program other than its specifications.
里边明确说明了，在黑盒测试中，测试人员不知道internal working, 而且测试人员只知道输入和输出，不知道程序怎样得到这个输出。测试人员从来不检查代码，而且不需要任何规格说明之外的知识。我想我举的第二个例子，和黑盒测试的定义是相矛盾的。从我的理解上来看，我举的例子是不应该属于黑盒测试的范畴。
White Box：Also known as glass box, structural, clear box and open box testing. A software testing technique whereby explicit knowledge of the internal workings of the item being tested are used to select the test data. Unlike black box testing, white box testing uses specific knowledge of programming code to examine outputs. The test is accurate only if the tester knows what the program is supposed to do. He or she can then see if the program diverges from its intended goal. White box testing does not account for errors caused by omission, and all visible code must also be readable.
里边说明了，internal working是需要的，要有专门的coding的知识。从定义上来看，黑盒白盒的主要区别应该是在knowledge of internal working 和 knowledge of programming code上面。也就是说是否你的测试中需要内部工作原理和编程知识。很明显，我举的第二个例子是比较符合白盒的定义，而且跟黑盒定义很矛盾。因此，literally, it should belongs to white box testing. Right?
你的观点，“从case设计的角度来划分黑盒，白盒”，有没有理论依据呢？从定义上来说，黑盒白盒指的是一种测试技术。测试技术应该是包括很多东西的说法，设计case只是其中一种吧。你可以认为从代码来设计case就是白盒测试，可是是否能说不是从代码设计case就是黑盒测试呢？毕竟设计case只是测试过程的一小部分。比如，我从功能设计case，可是在执行case，发现bug，定位bug，finding root cause的过程中，用到了大量的coding 技术和内部工作原理。也就是白盒测试定义中提到的技术，难道还是算黑盒测试吗？
作者: cleverman 时间: 2007-7-9 07:08
我想单纯的来区分黑盒/白盒本身肯定不是件很容易的事情，不然就不会有灰盒测试的概念了。
Definitions of Gray box testing:
Gray box testing – Tests involving inputs and outputs, but test design is educated by information about the code or the program operation of a kind that would normally be out of scope of view of the tester.[Cem Kaner]
我第二个例子比较满足这个定义。
Gray box testing – Test designed based on the knowledge of algorithm, internal states, architectures, or other high -level descriptions of the program behavior. [Doug Hoffman]
这个定义好象比较满足你所定义的白盒。从设计测试用例的角度。
Gray box testing – Examines the activity of back-end components during test case execution. Two types of problems that can be encountered during gray-box testing are:
A component encounters a failure of some kind, causing the operation to be aborted. The user interface will typically indicate that an error has occurred.
The test executes in full, but the content of the results is incorrect. Somewhere in the system, a component processed data incorrectly, causing the error in the results.
这个定义非常满足我的第二个例子。是从case的执行角度来说的。
Even though you probably don’t have full knowledge of the internals of the product you test, a test strategy based partly on internals is a powerful idea. We call this gray box testing. The concept is simple: If you know something about how the product works on the inside, you can test it better from the outside. This is not to be confused with white box testing, which attempts to cover the internals of the product in detail. In gray box mode, you are testing from the outside of the product, just as you do with black box, but your testing choices are informed by your knowledge of how the underlying components operate and interact. ;
这个定义也非常满足我说的第二个例子。
因此，从概念上来看，我说的例子绝对不属于黑盒测试，非常接近灰盒测试的概念。另外，灰盒和白盒也没有明确的分界线，灰盒本身也没有一个统一的定义。不同的定义也有一定的差别。这里我的理解是，
不懂代码，不懂内部工作就是黑盒。
从代码级详细的进行测试就是白盒。
中间的部分就是灰盒。
不过中间的分界线应该是模糊的，很多例子可能很难清晰的去划分。不过我举的第二个例子，应该算是灰盒。
作者: seifer1754 时间: 2007-7-9 09:39
Done………….
作者: shanxi 时间: 2007-7-9 10:35
按分工来说Tester只需要找出bug
但实际工作中，如果在时间允许的情况下，运用Windbg等工具对bug进行比较准确的定位难道不是一个资深或者高级的Tester应该具备的技能吗？
另外，当软件代码行数异常庞大后，整个软件的逻辑交叉也会异常繁杂，这时候已经不适合看某部分代码来fix bug的可能性(因为Cross function和组件开发部门保密性加强导致沟通很困难)，这时候需要Windgb等工具去辅助定位。Tester也会通过问题的定位及时发现类似的问题。
克莱沃曼 
Leave a comment