到底什么是白盒测试？

cleverman

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

不只是定位错误，是要找到错误的root case。 不然的话，你不能定bug的优先级别和严重程度。
比如我不久前发现了一个bug，会导致windows重启。你怎么定优先级呢和严重程度呢？windows重启也够常见了吧？
因此一定要找到root cause，最后我们发现是一个安全漏洞，可能被黑客利用进行攻击。因此就给了最高的优先级和严重程度。开发人员当天就fix了。
这就是我们为什么要求测试人员有这个能力。大公司里，老板不可能管任何事情，很多都需要测试人员来drive。但是，你必需要有个好的判断，不能出错。

[ 本帖最后由 cleverman 于 2007-7-9 06:45 编辑 ]

cleverman

随便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

我想单纯的来区分黑盒/白盒本身肯定不是件很容易的事情，不然就不会有灰盒测试的概念了。

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

Done.............

shanxi

按分工来说Tester只需要找出bug
但实际工作中，如果在时间允许的情况下，运用Windbg等工具对bug进行比较准确的定位难道不是一个资深或者高级的Tester应该具备的技能吗？

另外，当软件代码行数异常庞大后，整个软件的逻辑交叉也会异常繁杂，这时候已经不适合看某部分代码来fix bug的可能性(因为Cross function和组件开发部门保密性加强导致沟通很困难)，这时候需要Windgb等工具去辅助定位。Tester也会通过问题的定位及时发现类似的问题。

cleverman

Thanks all for joining the discussion. I believe I have understood the basic concepts through everyone's help.
Seems like shanxi and I have closer perspectives.

wyzwise

原帖由 cleverman 于 2007-7-9 01:23 发表




不是我们公司有特殊要求，最top的公司很多都这样要求的。对于一个strong的测试人员来说，他还需要跟开发人员讨论solution options，在fix之前就发现可能引起的其他问题。别说测试人员了，就是pm很多都很 ...

呵。。。你挺偏激的有的时候，国内人工比国外便宜多了，所以大批公司才在中国大陆做研发。。。呵。。

PM做code review 第一次见，也许分工不明确把。。一般国外公司都是分工明确，只作自己的事情。。呵。。

你说的不属于black box..

cleverman

原帖由 wyzwise 于 2007-7-9 14:18 发表


呵。。。你挺偏激的有的时候，国内人工比国外便宜多了，所以大批公司才在中国大陆做研发。。。呵。。

PM做code review 第一次见，也许分工不明确把。。一般国外公司都是分工明确，只作自己的事情。。呵。 ...

好像是你偏激吧？你怎么知道我不在国外的公司呢？我出国的时间比你长。

wyzwise

原帖由 cleverman 于 2007-7-9 14:33 发表


好像是你偏激吧？你怎么知道我不在国外的公司呢？我出国的时间比你长。

呵。。。。whatever...反正是怎么说呢。。。你的性格的关系吧。。无论其他人说什么，总是喜欢反驳。。。如果你是领导，对下属应该太fussy。。如果是员工，经常顶撞上司不好。。。You can always learn from others....So plz respect other...that's the first rule..sdlkfj5

没关系，你的性格和我以前一个同事很象，技术很强，如果个性能在改改发展应该更大。。。：）

seifer1754

wyzwise兄弟，我相信cleverman兄的年龄一定比你大，你的这种口气不太合适。
另外，我们只是讨论一下白盒与黑盒测试的区别，帮助cleverman定位自己的工作性质，没有必要谈论到别人的性格上面去。
更何况就凭这么几篇帖子就可以定义一个人的性格么？


另外我还是希望cleverman能够明白，
一个好的测试工程师确实需要能够协助开发人员定位错误，可是最需要的还是能够采用多角度去设计case，然后发现bug。
毕竟我们做的是测试，是从需求的角度去对软件的质量进行检测。黑盒，白盒的方法也不需要太明确的来划分，我们在设计用例的时候，相信也不会去仔细分辨使用的是哪一种方法来设计的用例。
多角度的去测试软件，才是一个测试工程师所应该具备的。

cleverman

原帖由 wyzwise 于 2007-7-9 15:54 发表



呵。。。。whatever...反正是怎么说呢。。。你的性格的关系吧。。无论其他人说什么，总是喜欢反驳。。。如果你是领导，对下属应该太fussy。。如果是员工，经常顶撞上司不好。。。You can always learn fr ...

我想喜欢反驳也是做测试人员的一个特点吧？我就是喜欢即使在生活的很多谈话中也去发现很多逻辑漏洞。当然了，也不能说是喜欢，是自然而然吧。我认为目前在我周围，很少有人说话犯有逻辑错误，或者说凭感觉或者简单的理解就轻易的发表一些观点。因为一旦你这样做了，对方一下就知道你水平怎么样了。因此，我不懂得东西我不会发表什么观点，只能是听，学习，等自己有了深入理解之后才会。但是，一旦我研究过的东西，我的观点就会很少犯错误。因为，我已经考虑了很多了。其实，这里我不是反驳大家，大家考虑过的，有些我也考虑过了，自己早就反驳了自己了。反驳没有什么大不了的，道理越辩越轻，我就不怕别人反驳我。

我对下属做事情确实是非常德挑剔，当时大家不理解。可是后来，都很高兴碰到我这样的领导。因为，他们在我这里获得了巨大的进步。我从来不顶撞上司，因为上司的技术比我牛多了。我也没任何资本和能力去跟他顶撞。如果技术一般的上司，他们都是放手让我去做，尽量提供我任何的资源，我总能给总部一个非常满意的结果。

我想你还不了解我的发展情况。我的发展已经超乎我自己，或者所有人的想象和理解了。现在世界上有我这样发展的人也是极少数。当然了，我现在还没有成为行业的leader,可是这是我领导对我的要求。我也喜欢很挑剔的领导，这样自己才能进步。

cleverman

原帖由 seifer1754 于 2007-7-9 19:51 发表
wyzwise兄弟，我相信cleverman兄的年龄一定比你大，你的这种口气不太合适。
另外，我们只是讨论一下白盒与黑盒测试的区别，帮助cleverman定位自己的工作性质，没有必要谈论到别人的性格上面去。
更何况就凭这 ...

你说的这点我很赞同。设计case按道理来说是比定位错误要重要的多。毕竟，发现bug还是需要好的测试用例。
我不否认你的观点。
只是，因为我们是做测试的。因此，已经有了很多case设计的经验了，也就是说设计case不是一个大问题了。
可是debugging技术基本来说，是属于开发的范畴。因此，对我们来说就陌生了很多。

因此，一个测试人员的发展，设计case是在前边的阶段，而debugging是在后来的阶段。

不知道我说的是否是一个普遍的事情。至少对于我来说，是这样的。目前我设计case没有任何问题，当然我不能说我设计的水平有多么高，另外就是肯定还有很大的提高，在这方面。
但是，debuging的技术来说，我就比较少了。因此，我下一个阶段的发展，就要在这方面了。因此，我觉得好的测试人员能debugging很重要。

cleverman

我相信你们对于测试的要求应该很高很高才对。
对于代码覆盖率的问题，你们是要求100%覆盖代码，还是也要100%覆盖所有路径呢？
比如
A-〉B-〉C
A-〉B-〉D
X-〉B-〉C
X-〉B-〉D

以上每个字母代表一个函数。
如果你走过了A->B->C和X->B->D, 代码就100%覆盖了。可是只是走过了50%可能的路径。还有50%没有覆盖。你们有没有要求到所有的可能路径都走一遍呢？

seifer1754

我这里采用的是MC/DC（Modified Condition / Decision Coverage） 的方法来设计case，
你说举的例子，如果B是中间的一个判断，那么只需要考虑B的条件不同的情况下，能够覆盖下面的C,D两个语句即可。
也就是说，如果B的条件仅有2种改变，A->B->C, X->B->D 就可以看成是完全覆盖了。

cleverman

B是中间的一个函数。A和X调用的时候输入可能会不同。
当然了，如果你单独把B拿出来做unit test的话。就没什么问题。
只是很多code coverage的工具不会把这个计算进去。因此，结果是100%代码覆盖，路径覆盖就不是100%了。

seifer1754

出现一个函数中包含有多个函数的调用时，我这里采用的是只验证被调用的函数是否被正常调用了，如果被调用的函数有输出，影响到下面的分支。可以直接修改寄存器，改变函数的输出，达到覆盖下面分支语句的效果。
这样做可以减少桩函数的开发，节省测试的人力。

cleverman

你们有没有工具来统计覆盖率呢？还是从test case设计来确定100%cover了？

seifer1754

统计工具是本公司自己开发的一款小软件，专门针对我们设计case的 MC/DC 手法来对代码进行验证。
基本原理和市面上的工具差不多，也是在代码分支处插入flag，然后对flag进行统计，来判断分支是否完全覆盖。
所以当出现死代码 （即正常逻辑无法运行到的代码）时，也需要增加case来对分支进行覆盖。
一般统计工具还是根据本公司的情况来自行开发比较好，这样统计出来的数据准确一些。
不过中小型公司不会考虑自己开发。sdlkfj5

cleverman

Thanks for sharing.

看的出你们那里很重视测试，水平也挺高。难得。当然跟你们的产品性质有很大的关系。
有时间再向你讨教。

多谢。

mysmd

看了这么多，还是不太明白！我是做开发的，单元测试、黑盒测试都做过，但是严格的用例编写、白盒测试都没做过，现在有需要，但不知如何入手！