黑盒测试比白盒测试更难，技术要求更高

chech28

原帖由 seifer1754 于 2008-11-19 14:53 发表



你怎么知道他看的不是UI部分的代码？而且你怎么知道他不是测界面的？ 黑盒测试哪个方面需要了解源代码？

呵呵，我确实不知道他是不是。我只是在问你是怎么得出那些论断的。
此外“黑盒测试又不等于界面测试。” 同“黑盒测试哪个方面需要了解源代码”完全没有关系。
不是同你抠字眼，也不是想和你争论，就事论事，我觉得你做的结论做的太轻率了。

taziji

为什么我说看了代码，事情会变得简单。举个发生过的小例子，有个项目要产生个一个从某天起一周以内的一个数据报表，不过开发的LINQ写错了多算了一天；如果用黑盒测试的话，就要准备好前后总共8天的数据，才能测出它的边界值是否正确。

觉得比较庆幸的地方，是我呆的地方让我有足够的自由度去做事情。而代码这东西就向cleverman说的可以让我有更多的信息，从而能更好地定位问题。

m2b2x

我还在第2阶段，代码坚决不让访问

cleverman

原帖由 dawee 于 2008-11-19 13:12 发表
帖子中的思路比较认同。
对其中一点有疑问：
拿功能测试来说，功能测试用例首先依据的应该是详细的需求规格说明书。当功能满足需求说明书（业务）之后，再来考虑有没有功能实现上的bug，这个阶段（如果层次够深的话 ...

这是部分。另一部分是，如果你具有代码的访问权利，即使你做黑盒测试，你可以完全引进白盒测试的技术用于工作上。从测试的大面上可以分为黑盒，白盒。但作为一个测试工程师，无论是做黑盒，还是白盒，都没有必要把自己只限制在一个方面。黑盒，白盒的互补性是相当高的。白盒测出的bug，往往要通过黑盒测试验证一下才更确定。比如，我看代码发现一个security的bug，我还是要通过黑盒测试的方法去验证这个bug是真正存在的。

cleverman

原帖由 飘渺的风 于 2008-11-19 09:48 发表
黑盒和白盒只是针对点不同，这两者我觉得拿来做比较就已经是个错了
他们只是我们测试一个手段
黑盒从外面看功能，白盒从里面分析问题
他们之间是互相补充，相辅相成的关系
我们的发展方向可以从黑盒到白盒，因为 ...

你分析得不错，你的观点也是我的观点。测试技术没有高低贵贱，只有测试人员水平的高低。我发这个帖子的意思并不是拿黑盒，白盒进行PK，我自己也不是有很多白盒的经验，很难客观评价。我主要是从黑盒测试人员的角度去分析测试技术的提升。

cleverman

原帖由 afeng 于 2008-11-19 13:29 发表
问题是现在国内公司的环境,如果妮去作一些妮份外的事情,公司知道了,只会把更重的活压给妮,妮就要不断的去提高自己的能力,一份付出,一份回报吗,这可不是在学校,多解一道难题,多一份荣耀,现在是多一份责任的压力,这个问 ...

我写这个文章的目的是针对那些想提升自己测试技术的人来说的，如果安于现状的话就没什么意义了。当然你说的问题很现实，我个人也存在这些问题。最好的解决办法就是全职做高端测试，比如安全测试，可是没有多年的积累沉淀还是很难的，而如果你想做到那个职位，还是要付出辛苦的。

cleverman

我想目前绝大多数人，尤其是论坛上的人，并不是真正了解什么是黑盒测试。黑盒测试其实还是包罗万象的，UI测试只是一个开始，也是最低级的测试。当然UI测试也不是黑盒测试的专利，我们也可以用白盒测试的方法和手段去测试UI。

seifer1754

原帖由 chech28 于 2008-11-19 19:29 发表

呵呵，我确实不知道他是不是。我只是在问你是怎么得出那些论断的。
此外“黑盒测试又不等于界面测试。” 同“黑盒测试哪个方面需要了解源代码”完全没有关系。
不是同你抠字眼，也不是想和你争论，就事论事，我觉 ...

原帖由 chech28 于 2008-11-19 19:29 发表

为什么我说看了代码，事情会变得简单。举个发生过的小例子，有个项目要产生个一个从某天起一周以内的一个数据报表，不过开发的LINQ写错了多算了一天；如果用黑盒测试的话，就要准备好前后总共8天的数据，才能测出它的边界值是否正确。

源代码的数量是庞大的,功能也是多样的.很多接口部分的源代码是不会在最终的用户界面上有具体的表现,何况程序之间还存在一定的控制耦合.
通过访问源代码来推测最终的输出,设计黑盒测试用例,本来就是错误的.
测试是基于需求的,无论是黑盒还是白盒.
如果根据需求的描述,你设计的用例需要准备8天的数据,本来就是无可厚非的,你通过访问源代码,使你的用例简化了,并不能说明你的用例设计的完善,反而说明你没有基于需求来进行测试,你的测试是基于代码来测试的,这是测试人员的大忌.
如果源代码很庞大,控制耦合很复杂,你这个简化版的用例,反而无法很准确发现BUG.

不是说你看了源代码会使黑盒测试变得简单, 看了源代码,反而使你的黑盒测试变得不够完善.

taziji

What I agree is by reading code I can get more information, thaz all...

seifer1754

Maybe, the information isn't correct.
Test base on requirement.

cleverman

"测试是基于需求的,无论是黑盒还是白盒."

能不能具体展开来谈谈呢？这个需求指的用户的需求吗？

chech28

原帖由 seifer1754 于 2008-11-20 09:19 发表




源代码的数量是庞大的,功能也是多样的.很多接口部分的源代码是不会在最终的用户界面上有具体的表现,何况程序之间还存在一定的控制耦合.
通过访问源代码来推测最终的输出,设计黑盒测试用例,本来就是错误的.
...

这段说到点子上了，DDS -> 测试计划 -> 测试， 一环环紧紧相扣，如果测试人员看了代码，这个流程就有点失去意义了，因为他会犯和开发一样的错误，而忽略某些场景，这是由人的认知偏见导致的。很同意你的观点。 我们一般是这样做的，在计划阶段和测试阶段，要避免读代码，只有当bug提交后，QA可以抽空读代码帮助找到问题。

taziji

原帖由 cleverman 于 2008-11-20 10:12 发表
"测试是基于需求的,无论是黑盒还是白盒."

能不能具体展开来谈谈呢？这个需求指的用户的需求吗？

In terms of white box testing, just wondering how it can be related to requirement, especially for user requirement. My perception is that to achieve the user requirement, we may have different ways, hence, its a bit hard to say whether its in line with user requirement.

seifer1754

原帖由 cleverman 于 2008-11-20 10:12 发表
"测试是基于需求的,无论是黑盒还是白盒."

能不能具体展开来谈谈呢？这个需求指的用户的需求吗？

一个软件开发的项目,肯定要迎合客户的需求来进行设计. 而且在开发的过程中,客户的需求可能会有变动,从而导致代码的变动.
一般来说,公司会有专门的人员去和客户沟通,进行用户需求的确定. 然后在公司内部,会对需求文档,系统架构,开发流程,测试流程等等进行会议讨论.
当需求确定后,会产生 概要设计文档 和 详细设计文档, 这些文档,都要经过客户的评审才能生效,然后才能进行软件开发.
在产品验收中,客户的评审标准就是结合需求文档,对你的测试用例和测试结果进行抽查.
所以,测试用例必须是基于需求来进行设计的,否则,客户会对你的用例提出质疑,从而对整个测试流程都会产生质疑,这是非常严重的事情.

对于任意的一个程序,或者函数. 只要可以编译通过,都可以认为是正确的,但是我们需要验证这段程序是否正确实现了需求中描述的功能.否则,即使你的测试用例能够完全对逻辑进行覆盖,也是毫无意义的事情.
对于黑盒测试也是如此,所有的测试用例都是按照需求的描述来设计的.
对于测试,你首先要有一个明确的预期输出,而这个预期输出就是需求中明确说明的.无论黑盒,白盒都是如此.

chech28

原帖由 taziji 于 2008-11-20 10:26 发表


In terms of white box testing, just wondering how it can be related to requirement, especially for user requirement. My perception is that to achieve the user requirement, we may have different wa ...

not necessarily user requirement, but you gonna have sth to test against with. Every project is divided into pieces, which could be further divided into tiny pieces.  Each stage or sub task have to comply to its own requirement. e.g: There is a user requirement at first place, then the product manager write product requirement against it, maybe with some other inputs as well. And the dev write Design specification, QA follow those Design Specification to write test plan ... so on and on.

cleverman

就我的经验来说，需求文档，设计文档及最后的代码是很不同步的。如果测试人员只是从需求文档，设计文档去设计测试用例或进行测试会产生不少误解。最好的办法就是去读代码进行有效的信息补充。当然，这不代表设计用例完全依照源代码，源代码只是信息的有效补充。我们这里有经验的测试人员都离不开源代码了。开发人员每天都在修改源代码，你必须要知道最新的情况才能调整你的测试工作。
当然如果有公司能做到文档，代码完全同步的话，倒未必真需要读代码，不过我不知道有多少公司能做到这样。

seifer1754

原帖由 cleverman 于 2008-11-20 10:42 发表
就我的经验来说，需求文档，设计文档及最后的代码是很不同步的。如果测试人员只是从需求文档，设计文档去设计测试用例或进行测试会产生不少误解。最好的办法就是去读代码进行有效的信息补充。当然，这不代表设计用例 ...

对于黑盒测试,如果产品实现了错误的功能,也许能够直观的表现出来.
可是对于白盒测试,一段代码,实现了错误的功能,如果没有一个明确的需求,测试人员如何知道这段代码到底要实现什么功能?测试人员又要如何设计用例?

我公司的需求文档,不仅要得到客户的认可,还要通过国际航空标准委员会的认可.对于底层代码的需求,甚至明确到一个变量在内存中要占几个字节.

需求不够明确,会给测试工作带来极大的困难,而且对产品的质量也会带来隐患.

cleverman

原帖由 seifer1754 于 2008-11-20 10:38 发表


一个软件开发的项目,肯定要迎合客户的需求来进行设计. 而且在开发的过程中,客户的需求可能会有变动,从而导致代码的变动.
一般来说,公司会有专门的人员去和客户沟通,进行用户需求的确定. 然后在公司内部,会对需求 ...

这主要是功能测试吧？很多测试跟用户的需求关系并不大。当然，满足用户的需求永远都是首位的。一个软件的设计也并不完全都是用户需求来驱动的，很多用户并不是真正了解自己的需求，所以我们的宗旨是帮助用户发挥他们的潜力。也就是说我们会给用户定义需求。

cleverman

原帖由 seifer1754 于 2008-11-20 10:57 发表


对于黑盒测试,如果产品实现了错误的功能,也许能够直观的表现出来.
可是对于白盒测试,一段代码,实现了错误的功能,如果没有一个明确的需求,测试人员如何知道这段代码到底要实现什么功能?测试人员又要如何设计用例 ...

一个变量占几个字节我们也有这种需求。你们的需求跟代码是非常同步的吗？你的产品的特点当然会要求比一般软件要高多了，只是想了解一下你们的需求一旦确定真的就不会变了吗？

cleverman

还有，我们公司没有专门的白盒测试人员,AFAIK.