51Testing软件测试论坛

标题: Bug定位技术杂谈 [打印本页]

作者: fzx 时间: 2004-11-24 08:42
标题: Bug定位技术杂谈
好的测试人员，应该为开发人员提供关于Bug的更多信息，包括错误原因，更改建议等。欢迎大家就如何精确定位Bug话题展开讨论。

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

作者: limei 时间: 2004-11-24 08:57
我很赞成你的说法！！我就是这样测试的！但要谈到精确的定位BUG，我对这个概念很模糊。

作者: fzx 时间: 2004-11-24 17:57
标题: 多谢楼上的支持，使我对这个贴子有了些信心：）
：）你们都怎么做的？快说说，我只是初学，想想的方法如下：

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

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

作者: upselfever 时间: 2004-12-10 14:17

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

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

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

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

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

个人杂谈，仅供参考

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

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

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

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

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

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

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

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

作者: wzb521 时间: 2005-3-21 18:45
这个问题还不好回答吗？

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

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

：）

作者: 森林一木 时间: 2005-3-22 10:10
标题: TO叶子0929
你说的对，真正引起bug的往往只是其中一步合作一项，我们一般在问题出现后，都不会立即提出bug，必须在几次验证后，找出出现问题的最简步骤，帮助开发人员定位bug

作者: wzb521 时间: 2005-3-24 16:28
DO THINGS SIMPLE BUT NOT TOO SIMPLE

作者: stilldeeppool 时间: 2005-3-28 14:54
标题: 你需要比程序员更为了解程序的模块信息和系统信息
根据你的经验和对程序模块的了解
经验来自于你的知识,一是对环境的知识,二是对程序的知识
其实程序只有三个地方:环境的交流,模块之间的交流,模块的自处理,输入和输出
四者构成了BUG的基本要素

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

作者: luckhj 时间: 2005-3-29 15:25
测试只要描述清楚就行了，开发人员看了，自然清楚问题出在什么地方。除非不是他做的。

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

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

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

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

作者: evemond 时间: 2006-10-24 01:38
如果测试人员有兴趣，有时间，又精力，当然可以做bug定位。

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

作者: 423799223 时间: 2006-12-12 17:46
多试多做吧

作者: jzq1314 时间: 2007-4-20 14:58
在测试过程中.软件不满足需求和质量要求的情况下,由测试人员提出的缺陷.......

作者: kxllr 时间: 2007-4-23 12:28
同意叶子0929 的说法

作者: oxygen001 时间: 2011-7-15 11:39
靠!测试人员的职责是清楚地报告BUG,而不是试图去修改BUG.
是否定位BUG,那时测试组内部的事情,即可有可无,目的是督促测试人员更多地了解被测系统.
我们知道:开发人员解决一个BUG包括定位和修改,而定位是非常困难的,定位出来后修改则是非常容易的.
我靠!让测试人员给开发人员把问题定位出,那要开发人员干什么鸟?! 还不如这样:让测试人员测试,测出问题,自己改,改完之后再自己回归测试. 因此得到的结论是: 软件公司不需要开发人员!!!

作者: oxygen001 时间: 2011-7-15 11:41
TMD!部分SB,你们知道吗:在华为这个公司,原则上是不让测试人员接触代码的!!!而这个做法是正确的,因为取得了很大的成功!!!!

作者: oxygen001 时间: 2011-7-15 11:49

你说的对，真正引起bug的往往只是其中一步合作一项，我们一般在问题出现后，都不会立即提出bug，必须在几次 ...
森林一木发表于 2005-3-22 10:10

恩，测试人员应该跟开发人员合作嘛！因此，开发人员也要协助测试人员做各个级别的测试工作，测试人员需要修改部分BUG,因此理想状态下：没有测试和开发之分，每个成员自己测试自己修改，改好了之后再自己测试！！！

作者: magicwin 时间: 2011-7-20 21:10
我个人觉得，先描述清楚问题产生的步骤，然后描述问题现象，在分析问题的原因：原因有多种可能，经验丰富者，可很快确定，初学者，可能需要时间，但是每个问题的发生，与操作的环境和步骤有关，从这个里面找，十有八九可找到线索。

作者: 没翅膀的飞鱼 时间: 2011-7-28 23:25
看到上面各位大虾的观点，感觉学到很多东西，谢谢各位

作者: javaweb2006 时间: 2011-7-29 23:48
如果是效率测试的话，就黑盒，对表象能够准确定位才能帮助开发找到问题，如果白盒的话太耗时间了。

作者: renee_ye 时间: 2011-8-2 14:02
同意楼上的说法“debugging <> testing!!!测试人员的任务是find failures，measure quality”
不过在能力能及和时间允许的时候，还是可以做下BUG定位的，这个是很好的成长机会。个人是这么认为的，O(∩_∩)O~

作者: 暗香世家 时间: 2011-8-14 18:45
楼上观点

同意楼上的说法“debugging <> testing!!!测试人员的任务是find failures，measure quality”

，个人觉得这是测试人员的主要任务，但不是全部任务。
关于是否需要定位BUG的问题：

是否定位BUG,那时测试组内部的事情,即可有可无,目的是督促测试人员更多地了解被测系统.
我们知道:开发人员解决一个BUG包括定位和修改,而定位是非常困难的,定位出来后修改则是非常容易的.

测试人员如果有能力将BUG定位出来，然后可以提交给开发人员修改，很大程度上提高开发人员的效率，对整个项目组而言是非常关键的。在这个过程中，测试人员也可以更多了解系统，对后面的测试工作也是有利的保证。个人感受

作者: lanqiaolvlang 时间: 2011-8-15 16:19
如果测试有时间，可以去定位bug，但是没有时间的话；竟可能的描述清楚bug发生的前提，步骤等！

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)