51Testing软件测试论坛

标题: 到底什么是白盒测试？ [打印本页]

作者: 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

原帖由 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

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

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

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

作者: wyzwise 时间: 2007-7-8 12:09

原帖由 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

原帖由 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

原帖由 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

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

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

作者: cleverman 时间: 2007-7-9 01:18

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

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

作者: cleverman 时间: 2007-7-9 01:23

原帖由 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 编辑 ]

作者: cleverman 时间: 2007-7-9 01:27

原帖由 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也会通过问题的定位及时发现类似的问题。

作者: cleverman 时间: 2007-7-9 14:11
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 时间: 2007-7-9 14:18

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

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

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

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

你说的不属于black box..

作者: cleverman 时间: 2007-7-9 14:33

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

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

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

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

作者: wyzwise 时间: 2007-7-9 15:54

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

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

作者: cleverman 时间: 2007-7-10 01:31

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

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

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

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

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

作者: cleverman 时间: 2007-7-10 01:41

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

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

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

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

作者: cleverman 时间: 2007-7-10 04:59
标题: One more question for seifer1754
我相信你们对于测试的要求应该很高很高才对。
对于代码覆盖率的问题，你们是要求100%覆盖代码，还是也要100%覆盖所有路径呢？
比如
A-〉B-〉C
A-〉B-〉D
X-〉B-〉C
X-〉B-〉D

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

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

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

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

作者: cleverman 时间: 2007-7-10 12:56
你们有没有工具来统计覆盖率呢？还是从test case设计来确定100%cover了？

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

作者: cleverman 时间: 2007-7-10 13:21
标题: Cool.
Thanks for sharing.

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

多谢。

作者: mysmd 时间: 2007-7-16 10:59
看了这么多，还是不太明白！我是做开发的，单元测试、黑盒测试都做过，但是严格的用例编写、白盒测试都没做过，现在有需要，但不知如何入手！

作者: zz45509 时间: 2012-12-4 18:30

作者: libingyu135 时间: 2012-12-5 09:58
回复 7# seifer1754

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

作者: libingyu135 时间: 2012-12-5 09:59

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

void test(x)
{

if (x
seifer1754 发表于 2007-7-8 13:40

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

作者: rosinahua 时间: 2012-12-5 13:02
x<0返回了，你输入负数返回了，怎么会有9

作者: zz45509 时间: 2012-12-5 17:01

作者: fengerapple 时间: 2013-1-25 18:00
Thank you very much for sharing!The good man!The good life of peace!

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)