黑盒测试需要了解实现细节么？

tjj006

做黑盒做了两年了，但是一直有一个问题，究竟需不需要了解代码的具体实现方式。
系统越来越复杂，和另外各个模块的耦合度也很高，个人认为，想要做好必须了解实现方式，至少是掌握数据的处理与流向。
现实是项目开发人员没有详细设计文档，没有清晰的流程图，由于是老项目的改造和二次开发，以前文档要么没写，要么也已经老得不能看了。

希望大家发表一下看法：
1. 黑盒测试需要了解实现细节么？
2. 如果是，在没有详细的文档情况下，如何实现？
看代码是不现实的，几个模块加起来有上百万行代码，求助开发么？
3. 作为QA，能够在项目流程或是工作方式上做些什么防止类似的问题出现呢？

tjj006

看到一个名词“软件考古学”，莫非对这种老项目，需要把以前的实现逻辑都像考古一样发掘出来？代价好大……

tjj006

大家都不了解么？？
那是怎么做的呢？

Nio

对于这个问题的回答是肯定的，肯定要了解。但能了解到什么程度，要看个人的时间与能力了。

说实话，程序员在写代码时想到的可能并不比测试人员多。因此，首先自个想想，如果由你来实现，你会如何考虑？然后再看看开发人员是怎么考虑的？当然如果是开发人员漏了或错了，那就是BUG。如果开发人员的想法是对的，但没有真正实现，那也是BUG。

虽然这些个问题可能很多很烦，但还是建议楼主能静下心，理一理，把该想的想一想，该问的问一问。并整理一份文档，一个一个的解决。

对逻辑问题考虑的是否全面，个人认为可以看出开发人员或测试人员基本能力的高下。

sm_zx

学习一下！说的在理！

calepyz

能了解更好啰

dabeixiong

你都说了是黑盒测试还要啥代码阿晕倒~
你说的问题可以考虑用灰盒测试来解决~
要看代码~那就涉及到白盒测试了，如果你不做白盒测试，看代码纯粹浪费时间...
要更好的了解系统，可以看需求和开发文档还有以前的经验和文档...就够了，也可以是在系统执行过程中的探索性测试逐渐帮助熟悉并更好的改进执行测试...

tjj006

原帖由 Nio 于 2008-2-29 19:06 发表
对于这个问题的回答是肯定的，肯定要了解。但能了解到什么程度，要看个人的时间与能力了。

说实话，程序员在写代码时想到的可能并不比测试人员多。因此，首先自个想想，如果由你来实现，你会如何考虑？然后再看看 ...

我不知道你说的改写的文档是什么文档？
如果不了解实现细节，那楼上各位是如何设计测试用例的？
纯粹按照功能有时候在划分等价类的时候就容易遗漏，因为有些时候开发的实现方式是与你想象的不同的。

tjj006

原帖由 dabeixiong 于 2008-3-2 20:44 发表
你都说了是黑盒测试还要啥代码阿晕倒~
你说的问题可以考虑用灰盒测试来解决~
要看代码~那就涉及到白盒测试了，如果你不做白盒测试，看代码纯粹浪费时间...
要更好的了解系统，可以看需求和开发文档还有以前的经验 ...

关键是需求文档不明确，以前文档也过时了，很多东西多不用了。
难道要测试人员来整理？
熟悉整个系统确实需要时间，不过有没有办法缩短这个过程?
仅仅靠个人能力慢慢熟悉代价有些大。。。

Nio

原帖由 tjj006 于 2008-3-3 11:23 发表


我不知道你说的改写的文档是什么文档？
如果不了解实现细节，那楼上各位是如何设计测试用例的？
纯粹按照功能有时候在划分等价类的时候就容易遗漏，因为有些时候开发的实现方式是与你想象的不同的。

有句话，叫好记性不如烂笔头。把你想知道的东西，一条一条写下来，才有利于问题的解决，越细越具体越好。

要做这个工作，首先要明确的知道是那一块的需求不明确，还要了解可以通过那些途径和方法来弄清楚需求。即使有个详细的需求文档给你，你也要看，也要理解不是？看不懂了，找谁？坐在那解决不了问题，问题的关键在于要弄清需求（不是有没有这个文档，谁来写这个文档）。

lianger

学习了。。。以后自己也得注意了！

tjj006

原帖由 Nio 于 2008-3-4 11:13 发表


有句话，叫好记性不如烂笔头。把你想知道的东西，一条一条写下来，才有利于问题的解决，越细越具体越好。

要做这个工作，首先要明确的知道是那一块的需求不明确，还要了解可以通过那些途径和方法来弄清楚需求 ...

这么说就是要测试人员通过测试把系统的功能逐步理出来喽？？

drdrtracy

我觉得很简单，什么都不要，直接拿着开发过着折磨一顿就好。。

Nio

其实你也认识到这个问题应该怎样解决了：正如你所说要“把系统的功能逐步理出来”，至于通过什么方法都行。
试问，如果连功能都不清楚，那还乍测试呢？

不管外届的因素如何，但要清楚作为测试来说，需要做些什么，为了测什么而要首先弄清楚什么？

LZ还有一个顾虑可能是“很烦”，主要是工作量和时间上的问题，如果没有具体做一做，是没有说服力的……

ouyu

原帖由 Nio 于 2008-2-29 19:06 发表
对于这个问题的回答是肯定的，肯定要了解。但能了解到什么程度，要看个人的时间与能力了。

说实话，程序员在写代码时想到的可能并不比测试人员多。因此，首先自个想想，如果由你来实现，你会如何考虑？然后再看看 ...

感谢您的点评，赞同！

yyjzxyghj

原帖由 tjj006 于 2008-3-3 11:34 发表


关键是需求文档不明确，以前文档也过时了，很多东西多不用了。
难道要测试人员来整理？
熟悉整个系统确实需要时间，不过有没有办法缩短这个过程?
仅仅靠个人能力慢慢熟悉代价有些大。。。

需求文档不明确，你可以要求提供最新的需求文档
这个当然不是测试人员整理的，测试人员是要根据需求文档制定测试计划，编写测试用例，执行测试用例，回归测试等，这些资料的整理应该是项目提供的
如果没有的话，只能自己慢慢熟悉，有不懂得就去问项目或软件的人。

ZH_0211

在现实项目实践过程中，确实存在很多这种类似的问题，往往手头上接到的项目是什么也没有，更不用说什么详细的需求文档，根本就是做梦！！

我目前做的项目就是，什么需求文档也没有，还是半中间插进来做的，更是什么资料也不全，正儿八经有问题了，那些人还忙着！！！

rien2128

看时间，当然对系统内部实现了解得越详细，对测试也会更有帮助。

cfanliang4

我觉得没有必要全部了解，只是在出现某些问题的时候，如果你能了解开发人员是如何实现的，可以更好地掌握这个问题的规律，从而能够重现它。

ysq1980

单从黑盒测试角度看，之气然不知其所以然足够了。
如果想提升自身能力，追求发展，还是要对具体实现细节多少了解一下，毕竟多学学没有坏处