到底什么是白盒测试？

cleverman

白盒测试，黑盒测试是刚学测试时候的基本概念。我们大部分人可能做的都是黑盒测试，也就是看不到代码，对产品进行功能测试。
可是什么才算是白盒测试呢？
Code coverage算不算白盒测试？
自己和别人一样做黑盒测试，可是自己没事的时候也看看代码，在黑盒测试的时候发现bug，自己可以去在代码里定位，找到root cause。那算不算是白盒测试呢？
如果不算的话，因为测试的过程中也分析了代码，明显不算是黑盒测试。如果算得话，自己跟同事做同样的工作，只是自己没事看看代码就可以说别人做黑盒，自己做白盒？
要不算灰盒测试？
我们公司并没有白盒，黑盒测试的概念。可是这又是测试最基本的概念。我有点confused.大家讨论一下好吗？

wyzwise

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

白盒、黑盒
自动化、手工
回归等等

具体做事的时候没有区分的那么细致，很少是只做其中一种，基本是交叉着本着解决测试问题的效率来采用。

cleverman

原帖由 wyzwise 于 2007-7-8 11:43 发表
White box 就是在全部理解系统的基础上去go through source code和architecture documents。
Code coverage（当然是拉） 是White box 的一个重要的优势和black box比较。。

首先做white box 的时候要有计划 ...

那我说的第二种情况,算不算白盒?

还有就是能不能举个灰盒的例子.

cleverman

原帖由 shanxi 于 2007-7-8 11:52 发表
白盒、黑盒
自动化、手工
回归等等

具体做事的时候没有区分的那么细致，很少是只做其中一种，基本是交叉着本着解决测试问题的效率来采用。

我也有这种认为,感觉测试很多理论上的东西,在工作中很不相关.
我现在倒是感觉,真正用的上的,还是开发的理论,而不是测试的理论.

wyzwise

原帖由 cleverman 于 2007-7-8 12:05 发表


我也有这种认为,感觉测试很多理论上的东西,在工作中很不相关.
我现在倒是感觉,真正用的上的,还是开发的理论,而不是测试的理论.

这个一部分是对得，我以前得公司，计划，管理不是很好，所以每次经常什么东西都混在一起，不是很明确。。。

其实如果管理好，这些测试的理论是很有用得。。。我现在得team就是按照成型得MVC得testing phase一步一步走，每一步每个在team里面得人都很清楚，都知道什么时候在什么事情。。。 测试还是要根据不同阶段做不同得事情得。。。

seifer1754

既然白盒，黑盒 的概念你都知道了，那么举个例子来说明一下好了。

void test(x)
{
   
   if (x<0) return;

   if( (x+1) < 0 )
   return 9;

}

看看上面这个函数，很明显 第二个 if 判断是永远不可能为 真，也就是说，采用黑盒的方式，用输入 参数x 来测试，是永远不可能出现9 这个输出的。
那么我们用不用考虑第二个if的成立情况呢？
我这个例子是简单了一些，也没有什么意义。不过在实际的开发中，还是会出现类似无法被黑盒测试覆盖的路径的，也许这些路径在正常情况下永远不可能被走到，可是我们在做软件设计的时候，必须要考虑到会出现的异常，而专门设计了一个对这种异常情况做出处理的分支。
例如，计算机的寄存器被恶意软件所篡改，如果没有一个对异常处理的分支，很可能会造成系统的崩溃。
那么，既然这种分支需要测试，我们就必须想办法来覆盖这个分支，这就是白盒测试需要考虑的事情了。我们可以在这个分支判断上设置断点，然后通过修改寄存器的方法来改变装载参数x的 寄存器的值，从而使程序能够走 x+1<0 的分支，使输出结果为 9 。

这就是白盒测试需要考虑的事情，是对程序的逻辑与路径进行分析测试。

我举的例子可能不是特别恰当，希望你能够明白。

cleverman

原帖由 seifer1754 于 2007-7-8 13:40 发表
既然白盒，黑盒 的概念你都知道了，那么举个例子来说明一下好了。

void test(x)
{
   
   if (x

我明白你的例子，不过你认为我说的第二种情况算白盒测试吗？也就是说跟黑盒测试没有任何区别。可是，遇到bug自己可以去代码里找到root cause.

wyzwise

"可是自己没事的时候也看看代码，在黑盒测试的时候发现bug，自己可以去在代码里定位，找到root cause。那算不算是白盒测试呢？"

这个不是testing...是bug fixing:)

cleverman

“例如，计算机的寄存器被恶意软件所篡改，如果没有一个对异常处理的分支，很可能会造成系统的崩溃。
那么，既然这种分支需要测试，我们就必须想办法来覆盖这个分支，这就是白盒测试需要考虑的事情了。”

请问你们公司是必须要测试这种case吗？我问题的意思是，概念可能没什么难理解的，可是到了实际中去，情况就复杂了。以我的经验，你说的这种情况是不需要进行测试的。因为，重要的是怎样防止恶意软件侵入你的计算机，真正侵入进来之后，就麻烦大了。如果要考虑这种情况的话，那可以设计无数的case了，不算很现实。请问，你用“必须”这个词是理论上来说呢，还是你们公司就这么要求的呢？
还有就是以我所知，无论是系统软件还是杀毒软件都是注重恶意软件的侵入，而不是侵入之后如何保证自己的程序不受影响。当然了，现在的UAC是这样考虑的，不过他们也不是在硬件的level来进行测试的。

cleverman

原帖由 wyzwise 于 2007-7-8 14:32 发表
"可是自己没事的时候也看看代码，在黑盒测试的时候发现bug，自己可以去在代码里定位，找到root cause。那算不算是白盒测试呢？"

这个不是testing...是bug fixing:)

不对。真正好的测试人员report bug的时候，是要写明白代码的root cause的。这只是发现bug，怎么能算fix呢？
真正的fix是要开发人员来做的，测试人员没有这个权力。
你找到代码里的问题，不代表就解决了这个问题。明白吗？

seifer1754

通过黑盒测试的方法发现bug,然后去代码中定位，找出原因。
这个不属于白盒测试，白盒测试和黑盒测试 在测试的理念上是不同的，也就是说，设计的用例都是不同的，采用黑盒测试方法设计的用例，不见得能够100%的覆盖代码的所有路径和逻辑。例如我上文举的例子。 虽然你能够根据黑盒测试方法发现的bug而定位错误，这也只能说明你的编程功底比较强，对代码的理解比较强。可是这并不能说明你设计的用例能够覆盖所有的代码逻辑和路径。也就是说，这并不能说明你做的是白盒测试。
在嵌入式白盒测试领域，经常需要追踪寄存器和内存，这些都是典型的白盒测试，你需要在程序中设置很多断点来追踪程序流程。而黑盒测试，只是考虑函数的输入和输出，对程序的内部逻辑是忽略的，很可能，同样的输入和输出，代码采用了不符合需求的方式而实现了。
所以，即便你能够定位代码的错误，可是你做的是黑盒测试，手中获得的可能只是一份功能需求文档，而不是一份详细的代码流程图，你定位的错误，只是表示程序的功能有问题，不能证明程序的逻辑设计有问题。
这就是白盒测试与黑盒测试的根本区别。

cleverman

那么什么是黑盒测试呢？不是说黑盒测试是不接触代码的吗？我以上的例子是有review code的工作的，应该和黑盒测试定义相矛盾呀。
我明白你说的嵌入式白盒测试是属于白盒测试，可是白盒测试肯定不限于只是这种类型吧。按照你的理解，如果我有详细的代码流程图，做黑盒测试，而我定位的错误也发现了是逻辑设计有问题，那怎么算呢？你也不能说我用黑盒测试，review代码就一定不能发现逻辑设计有问题吧？

为什么要问这个问题呢？我所在的公司，当然不是测试嵌入式的，是测试系统软件的。我们有所有的资源，可是我们的test case是按照功能来设计的，也就是说不会在代码级设计测试用例。如果只是设计，执行，那么肯定是算黑盒测试。可是我们也review code，要求发现bug尽量找到root cause写到report里。因此，我们有详细的代码流程图，也可以发现逻辑设计有问题。我们甚至要在functional spec阶段就要involve进去。当然了，在找root cause的时候，我们也要用debugging tools,向你所说，要追踪内存，寄存器，堆栈等等。那么这算不算白盒测试呢？

cleverman

你以上的解释有点已经先定性了我就是黑盒测试，在这个基础上来解释的。我想现在唯一的区别就是从功能设计test case和从代码设计test case了。
但是，我想这不是黑盒，白盒的根本区别。你说的根本区别也不是这个。

seifer1754

如果要详细的划分黑盒与白盒，不是从是否能看到代码来划分。
我想应该是从设计case的角度去划分。
例如，作功能测试，测试一个登陆窗口，这是典型的黑盒测试了，那么你肯定是根据需求文档，输入有代表性的字符来验证这个窗口是否正常。如果输入某一个特殊字符，窗口的功能实现出现问题，你也许可以定位到某一个条件判断语句有异常。然后根据测试的步骤，异常的现象，自己推测的原因来提交缺陷报告。
可是你所设计的用例，都是围绕着这个窗口的功能而设计的，你肯定不会去考虑这个实现这个窗口的代码有多少个循环，多少个判断。

但是用白盒测试来测试这个窗口的代码，就需要根据具体的代码流程图来设计，要判断程序的逻辑，实现的方法 是否与程序设计需求一致。甚至需求中会规定内存分配需要多少空间，你也要对内存空间进行用例设计与测试。 所有的设计都是根据代码需求文档来设计的。

你介绍了你工作的内容，能够接触到详细的代码流程，甚至也需要追踪代码逻辑。那么我认为，如果你设计的case， 是为了追踪代码的逻辑而设计的，这就是一个白盒测试用例，你做的就是一个白盒测试工程师所应该做的事情了。
虽然公司可能把你划分为黑盒测试，可是不代表你所有的case都是采用黑盒的角度去设计，也不代表你不能根据代码流程发现逻辑错误。
我们只是讨论黑盒与白盒测试的区别，不代表一个黑盒测试工程师就无法接触到白盒测试。
一个好的测试工程师确实需要能够协助开发人员定位错误，可是最需要的是能够采用多角度去设计
case，然后发现bug。


至于我楼上举的例子，因为我是做航空嵌入式系统的，所以对代码的异常处理非常严格，要求所有的路径都要覆盖一次以上，才有了“必须”这一说法，有些职业化了，到让别人产生了误解。

wyzwise

原帖由 cleverman 于 2007-7-8 14:35 发表


不对。真正好的测试人员report bug的时候，是要写明白代码的root cause的。这只是发现bug，怎么能算fix呢？
真正的fix是要开发人员来做的，测试人员没有这个权力。
你找到代码里的问题，不代表就解决了这 ...

sdlkfj5
也许你们公司的特殊要求吧。。。我对我的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

楼主应该自问一下：“在发现错误之前的测试过程中，我是否只关心软件的内部构造？”
答案如果是肯定的，那么就是白盒测试。
至于定位错误，我想大部分的情况都要翻看代码才能确定哪里出了问题，但这不代表就是白盒测试。sdlkfj2

DERYCK

看了以上几位的看法，我觉得还是在测试过程中你是根据外部功能设计的用例进行测试，还根据内部代码的结构设计的用例进行测试。
只要分清楚这两种区别就明白什么是黑盒测试和白盒测试了。
我个人认为定位错误不是测试。

cleverman

原帖由 scorix 于 2007-7-8 18:25 发表
楼主应该自问一下：“在发现错误之前的测试过程中，我是否只关心软件的内部构造？”
答案如果是肯定的，那么就是白盒测试。
至于定位错误，我想大部分的情况都要翻看代码才能确定哪里出了问题，但这不代表就是 ...

不对呀。我们在functional spec的时候就involve进去了，很关心软件的内部构造呀。我们对Windows Internal Knowledge的实现都要精通，更不要说自己的软件了。好像这不能说明是白盒测试呀。

cleverman

原帖由 wyzwise 于 2007-7-8 17:28 发表


sdlkfj5
也许你们公司的特殊要求吧。。。我对我的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 编辑 ]