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

jackei

楼主说的问题其实还是“测试人员是否可以明确的给出重现缺陷的缺陷记录”。
虽然有些时候，测试人员给出的缺陷记录中包含的信息无法重现缺陷，但是并不是说存在100％重新的缺陷，和非100％重新的缺陷。缺陷只要被发现一次，就说明它一定是存在的，问题在是否可以找到重新缺陷的方法。这的确包括了软硬件环境、操作步骤和顺序、数据等多方面的原因，但是测试人员的工作职责之一就是要找到这个规律。我还是原来那句话，要衡量成本和效益，不同的缺陷不同对待，有些可以考虑交由开发人员来定位，或者协助重现，也不要自己钻牛角尖。
另外，楼主如果想从根本上解决无法重新缺陷的问题，那么就要增强对测试工作的事先计划，减少随意性较大的测试。关键在于执行测试之前就要有的放矢。

fly-bird

我有一次被考核时，部门经理提出的意见就是不会对程序进行调试，我不知道自己要不要掌握这些呢？因为不会delphi（公司的编程语言）所以就不会调试，而一些bug到底是不是由于程序原因引起的有时是不是很清楚的，所以到底要不要会调试比较苦恼，因为自己对开发感觉不是很大兴趣，所以学起来感觉不是很快，比较辛苦的感觉，总也学不会，觉得要学会调试要学会整个delphi的开发过程才行啊～～

jackei

假如对开发工作熟悉，那么可以找到更多的缺陷。但是要求每个测试人员都熟悉开发，在当前来说还是不现实的。不过以后可能会做为测试人员的一个必要条件。

songfun

jackei，昨天在csdn杂志上看到了你的文章，呵呵，欣喜之下打算这几天通过china-pub购买一本。
^_^

至于楼主提的“软件测试要不要追究BUG发生的原因”，我倾向于要知道原因（当然你得有相关的知识背景，这里需要很多开发的知识），多和dev沟通沟通。

jackei

songfun，非常感谢你的支持，如果对《程序员》杂志的其他内容有兴趣，那么建议购买合订本，不过如果只是为了这几篇文章，我还觉得有点不好意思，我正在重新整理和修改已经发表的三篇文章，包括“测试需求与测试用例”、“测试计划”和“缺陷跟踪管理”，如果时间宽裕，争取这个月底发到网上。^_^
另外，《程序员》的合订本没有包含第12期的“缺陷跟踪管理”一文。

李逍遥

我是新手！
有很多地方向各位斑竹学习！
很佩服你们啊！

测试之神

个人认为，发现bug和协助开发人员定位bug

测试之神

个人认为，发现bug和协助开发人员定位bug

wanfali

楼主的前半部分本人是比较赞同的，对于不同的产品的测试对测试人员的要求肯定是不一样的，如如对于镶入式软件的测试，不懂开发环境是不好下手的！

haiyan_1027

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

ceba

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

hzkid

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

walker_lai

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

grubbysong2

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

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

changlang530

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

owenyuan

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

ivyhuan

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

lanfish319

顶个！！～

samham

最好能了解。