51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 15274|回复: 31
打印 上一主题 下一主题

Bug定位技术杂谈

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2004-11-24 08:42:15 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
好的测试人员,应该为开发人员提供关于Bug的更多信息,包括错误原因,更改建议等。欢迎大家就如何精确定位Bug话题展开讨论。

前提说明 : 测试人员有必要的编码知识。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏

该用户从未签到

2#
发表于 2004-11-24 08:57:52 | 只看该作者
我很赞成你的说法!!我就是这样测试的!但要谈到精确的定位BUG,我对这个概念很模糊。
回复 支持 反对

使用道具 举报

该用户从未签到

3#
 楼主| 发表于 2004-11-24 17:57:48 | 只看该作者

多谢楼上的支持,使我对这个贴子有了些信心:)

:)你们都怎么做的?快说说,我只是初学,想想的方法如下:

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

使用道具 举报

该用户从未签到

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

使用道具 举报

该用户从未签到

5#
发表于 2004-12-10 14:17:16 | 只看该作者
对于大型系统的质量保证,测试是唯一的方法


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

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

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

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

个人杂谈,仅供参考
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2004-12-10 18:08:29 | 只看该作者

赞成帮程序定位BUG

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

使用道具 举报

该用户从未签到

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

使用道具 举报

该用户从未签到

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



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

使用道具 举报

该用户从未签到

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

使用道具 举报

  • TA的每日心情
    郁闷
    2015-6-16 14:29
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    10#
    发表于 2004-12-20 15:02:54 | 只看该作者

    测试帮助开发人员定位bug,但不能帮助他们解决bug!

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

    使用道具 举报

    该用户从未签到

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

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

    使用道具 举报

    该用户从未签到

    12#
    发表于 2005-3-21 18:45:19 | 只看该作者
    这个问题还不好回答吗?

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

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

    :)
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2015-6-16 14:29
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    13#
    发表于 2005-3-22 10:10:20 | 只看该作者

    TO叶子0929

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

    使用道具 举报

    该用户从未签到

    14#
    发表于 2005-3-24 16:28:44 | 只看该作者
    DO THINGS SIMPLE BUT NOT TOO SIMPLE
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2005-3-28 14:54:57 | 只看该作者

    你需要比程序员更为了解程序的模块信息和系统信息

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

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

    使用道具 举报

    该用户从未签到

    16#
    发表于 2005-3-29 15:25:20 | 只看该作者
    测试只要描述清楚就行了,开发人员看了,自然清楚问题出在什么地方。除非不是他做的。

    [ Last edited by luckhj on 2005-3-29 at 15:42 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2005-5-26 22:54:04 | 只看该作者

    测试员和其他开发组成员应密切配合

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

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    该用户从未签到

    20#
    发表于 2006-10-24 01:38:53 | 只看该作者
    如果测试人员有兴趣,有时间,又精力,当然可以做bug定位。

    但是,需要记住的是debugging <> testing!!!测试人员的任务是find failures,measure quality,不是bug定位!
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-6 23:22 , Processed in 0.080825 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表