51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 15486|回复: 26
打印 上一主题 下一主题

关于回归测试

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2005-5-27 08:51:09 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
当测试时发现了bug,在测试用例的‘实际结果’中要记录bug的详细描述,并提交到bug库(如果有bug管理工具),开发人员从bug库里去找新bug,修订并将bug的状态改为checked in  
    请问一下大家测试人员在做回归测试时,也是根据bug库里的bug状态,将bug状态为check in  重新回放,如果一修订ok了,就该为closed;
    还是应该按照将测试用例中将所以实际结果和期望结果不一致测试用例重新执行一遍,再记录测试结果。但是在测试用例很多的情况下,自己可能也不记得那些测试用例中有实际结果与期望结果不一致的用例,没有管理工具并且测试完了还要到bug库里去找其相应的bug,更改他的状态感觉这样好麻烦。
    请问大家在测试中是怎么做的,有什么好的建议
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏

该用户从未签到

2#
发表于 2005-5-27 12:20:47 | 只看该作者
1、关于Bug的状态前面有帖子楼主可以看看,开发人员如果认为Bug已修复,应把Bug的状态改成Resolved,测试人员发现有Resolved的Bug就要进行回归测试以验证Bug是否真的解决,如验证通过则将Bug的状态改成Verified Pass,然后再由相关人员(如测试负责人)把Bug的装体改成Closed;如验证失败则将Bug的状态改成Verified Fail,让开发人员再去解决。
2、关于楼主提到的“但是在测试用例很多的情况下,自己可能也不记得那些测试用例中有实际结果与期望结果不一致的用例”说明Bug的提交和记录存在问题,Bug所对应的测试用例编号是肯定要包含在Bug报告中的,这样回归测试的时候就不会搞不清楚了。
3、现在开源的Bug管理工具也是有的,如bugzilla,最好还是去装一个吧。
回复 支持 反对

使用道具 举报

该用户从未签到

3#
 楼主| 发表于 2005-5-27 12:52:26 | 只看该作者
谢谢回复
  我门的bug库是bugtracker.net  我门的工具没有你说的那些状态呀。我门只有new,check in,re-open,closed,in progress   呀
  你说的bugzilla应该也是类似的工具吧
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2005-5-27 13:27:17 | 只看该作者
Bug的状态各个公司会不同,多少也不一样,我原来在德公司就有30来种状态。呵呵!
一般只要能够区分下面几种情况,并且不让人误解就好了
1,新提交的Bug
2,开发正在修改的Bug
3,已经修改好并且等待测试人员验证的Bug
4,验证通过的Bug
5,验证没有通过的Bug(这个要和新提交的Bug同样处理,不过有的公司需要记住没有改好的次数,用来考评开发的绩效)
6,设计问题
7,测试人员报错
8,暂时不修改的Bug
回归测试的方法具体问题具体分析,可能有人说我这样等于什么都没说,可是每个项目不同,不同时期也不同,甚至可能测试的人员都换了,如果以一种固定的方法来做,未免显得有点死板。个人认为,在测试的时候,最好能够边测试,边在测试用例上加上备注,说明实际结果。并且最好用颜色标记,如果你够仔细,能够把有问题的测试用例再标注上Bug的编号就更好了,这样在复查bug时,就知道修改好的bug是由哪个用例引起的,可以执行一下相关的用例,看是否真的改好并且没有影响到其他部分,这样就可以放心的Close了。如果有人觉得这样太过麻烦或者中途有人员的变动,也可以只看Bug的描述,按照bug的说明进行验证就够了,但是要记住最好能够对相关的模块进行一下测试,看看流程是否还能走通。不过这就要求Bug的描述要写得比较清晰,明了。
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2005-5-27 16:32:23 | 只看该作者
似乎讲的是缺陷管理问题而并非回归测试问题
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2006-6-15 11:06:31 | 只看该作者
我用我目前最现实的、最真诚的表达方式,说一声:谢谢,您辛苦了。
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2006-6-19 10:02:30 | 只看该作者
我们用的工具是mantis觉得还不错
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2006-6-19 13:11:08 | 只看该作者
回归测试和验证修复的bug不是等同的.回归测试要求在新的版本中,重新遍历测试用例,因为开发人员在解决问题时可能会影响到相关的模块,只验证修复的问题是否已经解决不能叫做回归测试.
建议看看回归测试的相关资料网上应该可以搜得到的.
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2006-6-28 22:38:09 | 只看该作者
我们最新采用的回归测试的方法是:把所有的测试说明中的用例全部执行一遍!(很麻烦的说)
然后对于初次测试出问题的地方及其边缘重点测试!

感觉实在是不爽,但是就是本着认真负责的态度,害怕程序修改引进新的问题!
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2006-7-4 09:27:59 | 只看该作者

我是新手,想和大家交个朋友!

[font=宋体][color=Pink]希望大家能够交我这个朋友!我的QQ:215143066,MSN:jickllyloveshe@hotmail.com
欢迎加入我的群!26526836

[/color][/font]
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2006-7-5 16:44:34 | 只看该作者
恩,是啊,每次新的版本就先验证一下上版本的BUG又没有Fixed, 然后再进行重新的测试。
还是会进行Full test。
回复 支持 反对

使用道具 举报

该用户从未签到

12#
发表于 2006-8-15 19:10:29 | 只看该作者
真的好感谢你们的精华帖子,,让我学习到了很多的东西。真的好感谢!!!
回复 支持 反对

使用道具 举报

该用户从未签到

13#
发表于 2006-8-30 14:41:00 | 只看该作者

回复 #3 zhuhao 的帖子

学习学学
回复 支持 反对

使用道具 举报

该用户从未签到

14#
发表于 2006-10-10 16:32:26 | 只看该作者
我也感觉在测试的时候,回归测试很重要。个人感觉回归测试要有一定的编程基础,要能够清楚修改的bug可能牵扯到的新的问题。
回复 支持 反对

使用道具 举报

该用户从未签到

15#
发表于 2006-10-10 16:44:29 | 只看该作者
为什么我没有看到发表新帖的功能~!我怎么发表自己的主题啊~
郁闷啊~~~
回复 支持 反对

使用道具 举报

该用户从未签到

16#
发表于 2007-1-30 21:18:07 | 只看该作者
一个bug的所经历的状态:
new、open、fixed、closed、reopen、postpone、rejected、duplicated、abandon、released
回复 支持 反对

使用道具 举报

该用户从未签到

17#
发表于 2007-3-20 21:57:30 | 只看该作者

感想

增长了见识,毕竟没这方面的经验,下次遇到这样的问题就不怕了!
回复 支持 反对

使用道具 举报

该用户从未签到

18#
发表于 2007-3-23 19:56:55 | 只看该作者
说的好
回复 支持 反对

使用道具 举报

该用户从未签到

19#
发表于 2007-3-29 17:26:44 | 只看该作者
看你们讨论的好热闹,我是新手,只有学习的份!
回复 支持 反对

使用道具 举报

该用户从未签到

20#
发表于 2007-3-31 13:55:53 | 只看该作者
学习了
回复 支持 反对

使用道具 举报

本版积分规则

关闭

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

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

GMT+8, 2024-11-15 04:25 , Processed in 0.083924 second(s), 27 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

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