软件测试要不要追究BUG发生的原因（转贴）

xulin168

软件件测试到底要不要追究BUG发生的原因呢？这个问题的争议很多，有人认为寻找BUG的原因是开发的事情，软件测试只要能发现BUG就够了；还有人认为软件测试可以尽自己所能尽可能的去寻找BUG的原因。到底哪个观点正确？我个人认为这个问题是仁者见仁，智者见智，站在一个产品不同的层面看，会有不同的看法。这里所谈到的观点，也仅代表个人看法。


要搞清楚这个问题，先要明确几个定义，首先要明确什么是QA？简单从字面上理解是Quality Assure（质量保证），CMM对QA的要求主要有下面几点：保障制度体系；促使过程改进；指导项目实施；增加透明度；评审项目活动；审核工作产品；协助问题解决；提供决策参考；进行缺陷预防；实现质量目标。其次什么是软件测试，软件测试是根据软件开发各个阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期结果），并利用这些测试用例去执行程序，以发现程序错误的过程。


而软件测试人员就是这一过程的执行者。

从上面的定义可以看到，QA重点关注的不仅仅是质量，而是整个软件过程，保证的首先是过程和体系，也就是说只有规范了过程和体系，才有可能做出好的产品。而软件测试就是通过自己的活动，来给QA人员提供尽可能的有效的信息和数据，使他们能够发现过程上的异常或者制度上的不妥之处。可见软件测试的任务不仅仅是测试，还要把项目的异常情况向QA报告，所以只能报出BUG是不够的。

其实QA和软件测试的目的都是一样的，就是尽可能的使发布出去的产品更加符合用户的需要，尽可能的没有bug。不同之处只是一个关注的是整个软件过程，一个只是关注最终的质量。所以为了搞清楚软件测试要不要追究BUG发生的原因，先要明确的是弄清楚BUG发生的原因对整个软件过程有什么好处，或者说对最终的质量有什么好处？

对于开发来说，一般是能够重现这个BUG就够了，这样对于那些发生几率在100％的bug来说，软件测试人员只要详细清晰的描述出bug发生的步骤，写明bug的发生条件，执行这些操作的用户的角色以及权限，使用的操作系统和浏览器，然后写清楚实际结果和期望结果，基本上就差不多了，开发根据这些描述能够知道是如何出现的问题，并且知道应该改成什么样。到时候软件测试人员（可能不是原来报BUG的那个人了）进行回归测试时根据BUG的描述，也可以很清楚的知道这个BUG是否真的改好了。但是如果一个BUG的发生几率不是100％，或者说在某些特定的条件下的发生几率是100％，但是一般情况下都不存在。测试人员可能只是偶然发现这个问题，却会认为是100％出现，报BUG时也就没有指明这个问题出现的条件，开发看到这种BUG，根本无法重现，再打给测试人员，如此反复几次，虽然最终问题得以解决，但是对于整个项目来说，却是浪费了很多的时间。如果在发现问题时。能够多试几下，或者换个环境试试，可能就会找到发生几率不是100％的原因，比如非法数据，特殊字符，特殊用户权限，特殊日期，或者在系统中还有其他自己不知道的参数的影响，或者是操作系统的问题，又或者是浏览器的设置问题，还有可能是浏览器的版本问题等等，寻找这些原因的过程，是一个自我提高的过程，也是积累自己测试经验的过程，同时也是证明测试角色重要的过程，是证明测试人员价值的过程。

当然目前国内的软件公司中测试人员的水平还不是很高，想看懂开发的代码并且进行测试难度还比较大，所以我也不主张去看着开发的代码进行测试，只需要在测试的时候，多考虑一下，尤其是出现问题的时候，多想想这个问题为什么会发生，会影响到系统中其他什么地方，还会有其他哪些地方有可能存在这样的问题，这样等到开发修改好之后，提交测试进行回归检测时也可以做到有的放矢，尤其是在回归测试时间很短的情况下，如何进行有效的回归测试，并且保证不漏掉重大隐患，我想和开发水平固然有关，但是关系最大的还是测试人员对系统的熟悉程度，以及是否具有软件开发的思想。
追究bug的原因，不是一朝一夕的事，需要长期的摸索和总结，开始会很烦，可能还会很郁闷，但是慢慢的你会发现其中的乐趣，想一想当你报给开发一个Bug的时候，随着bug的报告还有一个详尽的发生这个bug的条件数据，以及测试平台等数据，开发根据这些很容易重现这个问题，会对测试人员的专业度有很大的认可，那时我想自己心里的成就感不是几句话可以说完的了！

yumjuntest

楼上讲得太有理了.
好的软件测试人员应该是好的软件开发人员,追究BUG原因是提高技术的一种途径.测试人员不但要知其然,还要知其所以然.这样,在参加评审会议时才能提得出问题啊!

安心

我也觉得测试人员应该追究BUG原因,当然,要在不影响自身正常的测试工作的情况下.

不过，个人认为其实很多时候，测试出BUG在对BUG进行重现的过程中，测试人员有时不可避免地会对BUG原因进行一定猜测，以确定到底是哪种情况造成了BUG的出现，这种错误是否在软件的其他部分也可能出现，等等。有时还会补充用例去对BUG进行进一步的验证与确认。

我觉得，好的测试人员就是要有这种打破沙锅的精神。思考BUG原因，提出高质量的BUG报告，一方面可以帮助开发人员缩小错误定位的范围，得到其认同，进而使今后的测试与开发的沟通工作更加顺利。另一方面，对于测试人员自身的技术能力的提升也有很大的帮助。测试人员一定要有探索精神和求知欲，不能仅仅满足于找出BUG扔给开发就不管了。

fishfish

我个人觉的如果想要更好的发展自己,追究BUG的原因是必要的,
我个人比较认同这个观点,也认同大呢的这句话

archonwang

个人觉得应该去追究，测试人员需要对整体系统框架与实现形式了解更深入。有经验的开发人员一看到报错可能会非常清楚该错误发生可能的位置，可以及时修改，而相对刚接触系统的开发人员，修改工作的进程可能会受到一定阻遏。软件测试人员的职责之一是帮助开发人员对于系统的更深度的理解，从这一点上讲，系统在整体上，测试人员的理解与熟悉程度必须要强于开发人员。

yaindilly

能定位就定位，不能定位就规避~
不让BUG暴露出来就行。极端点说：这个BUG如果是10年内不会出现的，把它扔在一边不管也可以。

B2CPC

个人认为：找出bug原因，也许更多的是leader们做的事，如果你现在不做，你将来怎么做leader和manager。这对开发组错误趋向分析（提醒他们哪块是他们的弱点），和测试组重点测试区域的界定（提醒自己哪块改重点测试）都有大大的好处。能做到如此的话，应该差不多到CMM4或CMM5（过程改进）了吧！

Tender

swallow0918:
我的意思是测试应该在开发找出原因的基础上，向开发询问是什么原因，而不是自己去找原因。毕竟了解出错原因对测试也是有帮助的。

大妮

喜欢这句话“多想想这个问题为什么会发生，会影响到系统中其他什么地方，还会有其他哪些地方有可能存在这样的问题”，很有用的

kpxl

Originally posted by swallow0918 at 2005-8-12 09:08:
就好比我们测试一个简单的计算器的加法功能，测试结果发现3+5的结果不是8而是别的答案，你说让测试怎么去找bug发生的原因？当然是提交开发，让他们去程序中找原因，是不是？

不是要你找到3＋5为什么结果不是8，而是找到是3＋5出错
这里根据这样的现实可以有几种Bug的描述
1，计算器加法计算出错。
2，3加上一个数出错
3，一个数加上5出错

当然这个例子不是很好，因为这种计算器的软件看起来简单，但是测试很复杂，因为不可能完全测试。

kpxl

这份文件中也说了这是个见仁见智的问题。
关键是看大家的公司是否重视质量，自己是否想在测试这条路上有更大的发展。
这里说的Bug发生的原因也不是指具体是哪个文件，甚至哪行代码引起的，而是指Bug发生的规律性，我做测试有快要3年的经验了，从普通的测试一直做到Team Leader，我有个习惯，就是每天都会Review组员报的Bug，有时间的话还会试着重现这些问题，经常我会遇到一些不可重现的问题。不得已只能找提交者，他们也会发现不存在了，这时有的人就会直接的把Bug给取消，我通常都会和他一起来找原因，分析为什么会有这样的问题，是测试环境的问题，还是测试数据的问题，还是某些特殊的操作？

这样时间久了，自己对bug 就会有一种感觉，就是那种看到Bug就能知道大概会和哪些地方有关系，自己的水平也就自然得到了提高。

kpxl

这篇文章是我写的。

swallow0918

楼上的朋友，“如果测试人员只会测试，只知道在界面上点来点去，那就没什么长进了。”这句话不同意。谁说测试只知道在界面上点来点去？点不是随便点的，测试如果只是那么简单的事情，为什么一定要我们来做？
测试的目的是发现系统存在的bug，而不是知道bug发生的原因，追究发生的原因应该是开发人员的事情吧。
就好比我们测试一个简单的计算器的加法功能，测试结果发现3+5的结果不是8而是别的答案，你说让测试怎么去找bug发生的原因？当然是提交开发，让他们去程序中找原因，是不是？

Tender

测试人员多少应该知道BUG的原因！这对测试人员了解系统内部实现是个好的方法。如果测试人员只会测试，只知道在界面上点来点去，那就没什么长进了。

ggstar

测试人员不用深究bug的原因吧
“……但是一般情况下都不存在。测试人员可能只是偶然发现这个问题，却会认为是100％出现，报BUG时也就没有指明这个问题出现的条件……”一般来说，测试人员没有通过的测试用例进行反复，确定bug的必然性或者出现的概率，应该可以避免绝大部分操作失误导致的测试用例不通过