到底什么是白盒测试？

cleverman

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

fengerapple

Thank you very much for sharing!The good man!The good life of peace!

zz45509

rosinahua

x<0返回了，你输入负数返回了，怎么会有9

libingyu135

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

void test(x)
{
   
   if (x
seifer1754 发表于 2007-7-8 13:40

        很好的例子，但是x不一定保证是正数啊？我们做黑盒的时候会考虑x很多情况，也会考虑到负数的情况的，不是就可以输出9了么？

libingyu135

回复 7# seifer1754


    很好的例子，但是x不一定保证是正数啊？我们做黑盒的时候会考虑x很多情况，也会考虑到负数的情况的，不是就可以输出9了么？

zz45509

mysmd

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

cleverman

Thanks for sharing.

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

多谢。

seifer1754

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

cleverman

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

seifer1754

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

cleverman

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

seifer1754

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

cleverman

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

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

cleverman

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

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

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

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

cleverman

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



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

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

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

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

seifer1754

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


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

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

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

cleverman

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


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

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

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