原创：软件测试要不要追究BUG发生的原因

kpxl

软件测试到底要不要追究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的条件数据，以及测试平台等数据，开发根据这些很容易重现这个问题，会对测试人员的专业度有很大的认可，那时我想自己心里的成就感不是几句话可以说完的了！

gaha

协助开发人员定位bug出现的位置和原因，应该是每个tester应做工作的一部分，对于这项工作不同的态度，决定了tester工作发展好坏的隐形条件。

testsyou

我是新手，學習

美元测试

为什么是QA的定义而不是QC

helios

个人认为能复现BUG的规律和条件及步骤，就可以说明该BUG的查找就可以告一段落，提交开发进行处理，能进行编程和调试的测试人员是目标也是对测试人员的基本要求！
但目前看来，不要求测试人员熟悉开发语言的比比皆是，这是现状，以后会好的，我一直在努力中。。。

fx999

学习

shanxi

测试人员真正做到很难

除了分析bug需要的时间外，测试人员的技术能力很差是不争的事实。

ananbo

追，bug源头哪里会有更多的bug。。。

caocao176

要对Bug产生的原因进行分析，

小贝流浪记

这个要看个人了 ，如果对开发感兴趣的话 ，最好要定位下问题 。前提是必须要有开发方面的知识 。如果对开发义务所知的话 ，那就不用了 。 只要发现问题就行了  
……   个人观点 ，仅供参考

samham

最好能了解。

lanfish319

顶个！！～

ivyhuan

调试是开发人员做的事情啊，怎么要测试人员来做，调试是开发人员在编程的过程中进行的对代码的语法等编码进行的，不属于测试范围。

owenyuan

请问各位版主，你们现在都是在从事公司的软件测试工作吗，可不可讲点你们实际工作上的经历

changlang530

个人觉得要追究，我做手机测试对部分问题，就会自己去查代码看是什么原因。
只有知道更多，思维才能广，想到的testcase才有独见性和对问题测试的明确性

grubbysong2

其实我认为没有必要。。。

我最近在培训。 讲师也提到过

walker_lai

tester不一定都有开发能力哦
还是让dev来吧

hzkid

肯定要，测试人员不是仅仅发现BUG就可以的

ceba

测试人员并不要求对代码很熟悉，但是一定要对软件中各个模块之间的相互影响有一定了解，发现了BUG后提供详细的证据，保持环境，以协助开发定位BUG。
定位BUG并不是测试工程师的主要责任，在定位BUG过程当中，测试人员只是起到一个协助定位的过程，对于BUG的最终定位必然是开发来做，这是工作职责分工所决定的。
但是对于出现BUG的最终原因却是必然要清楚的，以便后续的测试中调整测试策略和测试方法。
所以测试人员最重要的并不是定位BUG，而是在有短的时间内发现尽可能多的BUG，提供足够的信息协助开发定位BUG。

haiyan_1027

我还是认为，测试人员不是仅仅发现BUG就可以的，最重要的是定位BUG的原因和重现的概率