Bug定位技术杂谈

fzx

好的测试人员，应该为开发人员提供关于Bug的更多信息，包括错误原因，更改建议等。欢迎大家就如何精确定位Bug话题展开讨论。

前提说明 ： 测试人员有必要的编码知识。

limei

我很赞成你的说法！！我就是这样测试的！但要谈到精确的定位BUG，我对这个概念很模糊。

fzx

：）你们都怎么做的？快说说，我只是初学，想想的方法如下：

要作到Ｂｕｇ比较精确地定位，一定是黑盒结合白盒。先利用黑盒，粒度很粗地确定Ｂｕｇ所在模块，然后，分析其内部结构，进一步划分测试粒度，如此迭代测试，会把Ｂｕｇ限定在一定范围内。

babybear315

我并不赞成这样定位bug，其实这样就意味这你做测试的同时还在调试程序，这样对于测试效率会大大的降低，目前，对于大型系统的质量保证，测试是唯一的方法，所以测试的效率就显的非常的重要，你只要找出错误就可以了，当然你可以简化操作来定位bug（如果是黑盒测试），不要给开发建议怎么改错来限制他的思路。随着你对系统的熟悉程度的提高，你对bug的定位也会更加准确！

upselfever

对于大型系统的质量保证，测试是唯一的方法

不同意这样的说法！对于任何一个系统，质量保证都有其共性。测试不是唯一的方法。
测试只是质量保证中最直接的方法。而质量保证体现在整个软件生命周期中的方法包含很多，比如，前期的标准，流程，评审；中期的代码控制，版本控制，需求变更控制等等，后期的测试，维护管理等。我甚至更情愿把测试理解为开发的一部分。

测试对BUG的定位是很关键的，如果测试只是发现了BUG，那么我个人认为只完成了第一步。在发现BUG后，要根据自己的技术和经验，来分析BUG出现的原因或位置。最直接的，可以丰富你的测试经验，对于类似的单元或模块，你再测试不是效率高很多吗！另外，根据你的分析和建议，程序员修改的速度也会加快，不是提高整体项目的效率吗？最表面的，让开发人员感觉你的测试有份量。（在国内，开发人员鄙视测试的例子不少吧？）

另外：测试另外一个很重要的意义就是对发现的BUG进行归类，分析。（在CLEARQUEST中就提供了很多统计分析功能）你可以发现一个项目，一组人员的BUG分布规律，提供项目的管理人员参考，发现目前项目中存在的问题，以便及时的调整，尤其是进度上的和技术上的。

如何准确定位bug，我想这个和技术和经验是密不可分的。测试是需要技术的，甚至超过开发。不了解一个技术，对这个技术产生的东西肯定测的深度会有欠缺。所以，加强技术是关键。另外，经验也很重要，经验到了，对于一些错误的信息，很自觉的就会想到背后的问题。
一个好的开发管理对BUG的定位也是有决定性意义的。需求明确，设计清晰，代码规范都能减少BUG定位的难度。代码错综复杂，聚合性大，耦合性低，你如何定位？一个BUG牵扯了3个开发人员的模块，你只有头大！

个人杂谈，仅供参考

jody

至于是不否黑白盒之间跨跃去DEBUG，这是因人，因环境而异，象我们不允许这样，因为我的黑盒测试机上是不允许装编译程序的。所以你不可能再去跨环境测试，这样太浪费时间，也有点得不偿失。不过我还是尽我所能去在黑盒的环境下帮他们定位，比如说通过横向和竖向测试比较结果，环境比较等等，分析日志，其实我这样做也是在DEBUG，因为我们的程序员也就这样。
大家在努力定位BUG的同时，就会发现自己的用例也会越来越多，因为你对产品了解的越来越多，越来越广。对于自己的测试技术也会有很大的提高。
至于说DEBUG浪费时间，我想我们测试的主要任务是找BUG，不是必须得安计划完成你所要完成的。
经我测试这么多年的经验来看，DEBUG帮我的测试技术提高了不少。

smartbaby

非常赞同前面“不要给开发建议怎么改错来限制他的思路”，bug定位仅仅是根据测试人员的能力来进行一个可能的发生问题的范围，通常不主张普通测试人员给出bug定位的建议，由测试经验丰富的测试人员来确定bug定位要可行一些。
对于定位bug来说，不同的架构可以给出不同的方法：
1.对于bs架构的来说，可以给出出错的页面地址、jsp提示、服务器日志。
2.对于CS架构的来说，可以尽可能的给全错误提示信息、日志、准确的异常描述。

jody

[quote]Originally posted by smartbaby at 2004-12-13 01:38 PM:
非常赞同前面“不要给开发建议怎么改错来限制他的思路”，bug定位仅仅是根据测试人员的能力来进行一个可能的发生问题的范围，通常不主张普通测试人员给出bug定位的建议，由测试经验丰富的测试人员来确定bug定位要 ... [/quote



上面提到的这两点,这是描述BUG最基本的要求,只能说对开发人员或测试人员定位BUG的有所帮助,也是定位BUG的前提。定位BUG更多的需要DEBUG。

skinapi

还是比较同意babybear315的观点。
1.作为测试人员还是要区分测试和调试的，虽然目前不少测试人员实际上也承担了初步调试的工作，但必须牢记自己更重要的工作是测试。
2.测试人员用自己的力量精确定位了导致Bug的缺陷，测试人员是蛮有成就感的，但换一种思路，如果让开发人员来定位，需要的时间可能要少很多。
3.我的理解，测试人员的Bug定位包含三方面：一是通过测试让出现Bug的环境、操作具体化、明确化，以便开发人员更好的解决Bug；二是通过测试将不同缺陷导致的相似的Bug区分开；三是通过测试有可能会发现一些和这个Bug相关的Bug（我们知道Bug具有群居的特性）。
4.如果测试由于该Bug受阻，可考虑和开发人员一起或者单独通过调试的方式来发现导致Bug的缺陷。

森林一木

我认为帮助开发人员定位bug很重要，可能我们很多测试人员没有实际的编码经验，但是对于bug出现的时机，场景应该很清楚，能够缩小bug出现的范围，我们在提出bug的时候，要求测试人员尽量描述bug出现的步骤，如果无法用语言描述清楚的时候，必须将出错的图形附在bug后，这样有助于开发人员准确定位bug，开发人员和测试人员同属于一个项目，是一个共同体，不能分彼此，可能职位不同，但是协同工作的目的不变，所以我们可以帮助开发人员定位bug，但不能帮助他们解决bug。

叶子0929

非常赞同前面“不要给开发建议怎么改错来限制他的思路”
这个很重要，而且，实际中也碰到一些，毕竟测试人员对程序构架及内部结构没有开发人员那么熟悉，比较有深度或关联比较复杂的bug，测试人员其实是很难定位到的，而测试人员能够定位到的，也不过是些相对独立或简单的问题，而这些问题开发人员是很容易定位到的。（这并不强调测试人员水平不如开发人员，只是强调，测试人员对内部结构和关联并不清楚），所以并没有起到太多作用。这样做除了限制开发人员的思路，还有比较大的一个负面效果是：容易引起开发人员的反感-------他会觉得你有点指手划脚的意思，当然如果某次定位正确了，他没什么话说，但如果一旦定位错了，他就有我刚才提到的想法了，几次不正确的定位描述下来，很容易降低开发人员对测试人员的重视和信任。
也有同学说，开发，测试是一个整体，应该协调合作，不分彼此。。。。。这话我觉得对一半，错一半，作为一个项目团队来说，的确是一个整体的，需要协调合作，但并不意味着就不分彼此，否则也就不用分职责分类了，所谓的协调合作应该是各尽其责任，而不是不分彼此。虽然目的一样，但责任还是不一样的，工作重点也是不同的。---------为了累计经验，比较有意思的bug，测试人员自己可以定位，自己记录，等开发人员回复之后，看看跟自己当初的想法是否一样，长期积累，也许以后碰到类似的问题就可以提点有建设性的意见了，也能让别人信服。所以我的建议是不太确定的就不要轻易给定位了，如果能明确当然定位最好了。

无需定位问题，并不等于测试人员发现问题就一锅端上去，描述也不是越多越好，有时候可能操作很多步骤或输入很多内容后出现某个bug，但真正引起bug的却只是其中一步和一项内容不对，测试人员要做的应该是，尽量精炼步骤和输入内容，找出那一条，精准描述问题是对开发人员最好的帮助。

wzb521

这个问题还不好回答吗？

能短时间准确定位的就定位，不能定位的就不定，定位错误会对开发人员有误导。

做为测试人员，你只要写出出错的步骤就好了，具体其它的还是专业人员来找吧！

：）

森林一木

你说的对，真正引起bug的往往只是其中一步合作一项，我们一般在问题出现后，都不会立即提出bug，必须在几次验证后，找出出现问题的最简步骤，帮助开发人员定位bug

wzb521

DO THINGS SIMPLE BUT NOT TOO SIMPLE

stilldeeppool

根据你的经验和对程序模块的了解
经验来自于你的知识,一是对环境的知识,二是对程序的知识
其实程序只有三个地方:环境的交流,模块之间的交流,模块的自处理,输入和输出
四者构成了BUG的基本要素

我相信任何一个BUG都逃不过这四个方面,根据你的错误信息去联系这四个因素,其实很多错误的再现是轻而易举的

luckhj

测试只要描述清楚就行了，开发人员看了，自然清楚问题出在什么地方。除非不是他做的。

[ Last edited by luckhj on 2005-3-29 at 15:42 ]

u572

测试员和其他开发组成员应密切配合， 但不能摄入太多的设计问题。 测试员发先BUG（严重的）后，可直接告知开发人员。 并可向开发人员询问其他可能与此相关的错误的可能性及模块。提高测试效率。

piao_604

我觉得对BUG的详细描述是对程序员来解决BUG的最好办法,最好能把发现BUG问题的输入数据,及输出结果进行详细的描述,这样对于自己和程序员都有帮助,可以提高程序员解决BUG的效率.

jiepeach

新手说说个人看法：作为一个测试人员，发现bug只要能指定bug所在的模块或功能点就ok了，至于具体出现在哪个地方，是开发人员的事。测试人员在提交bug时，一定要清楚的描述bug，不能出现歧异，不然会误导开发人员，将本来正确的修改错了，错的仍然没有修改。在开发人员修改bug过程中需要帮助时，测试人员应该积极的配合，这样会使得bug快速得到修正。还有测试人员的思维一定要开阔，发现一个问题一定要联想到与此相关的一些模块是否有问题，是否有类似的问题存在。

evemond

如果测试人员有兴趣，有时间，又精力，当然可以做bug定位。

但是，需要记住的是debugging <> testing!!!测试人员的任务是find failures，measure quality，不是bug定位！