对于回归测试，请问你们用什么方式测试？

似梦非梦 · 发表于 2005-3-29 16:17:34

当开发人员修改了提交的BUG后重新发布程序，这时的测试重点是验证提交的BUG。但是很有可能这次发布的程序会带出其他的新问题。这时如果全部再进行一次测试，可能要花上很长的时间，但是又不能不测试。对于这种情况，请问一下你们是怎么处理的？

woaixiehong · 发表于 2005-3-29 16:53:46

archonwang · 发表于 2005-3-29 18:20:29

同上，尽量使用自动化，对于较大的系统肯定需要这么做。不过对于一些在业务逻辑上比较复杂的流程需要用手工进行。

black_tulip · 发表于 2005-3-30 09:39:45

经验

似梦非梦 · 发表于 2005-3-30 18:05:30

多谢谢楼上几位的回复。可是，全部重测一遍花的时间可不少啊~这样下来可真烦人~~

jennie98 · 发表于 2005-3-31 08:55:56

自动化请问用什么工具啊？？
要编写脚本吗？

johnliuzy · 发表于 2005-4-1 11:14:01

你可以设定先好各个开发时间段中的测试基线
每次回归后看满足哪个基线的要求
在提出进一步的测试计划或开发修改计划
具体的工具很多
大量使用的是功能性测试工具和负载压力测试工具
典型有MI 的WR LR
IMB的 ROBAT。
网上这方面的资料很多，你可以查查看

云层 · 发表于 2005-4-7 11:06:08

简单的功能用自动化，复杂的功能还得手工，没办法

似梦非梦 · 发表于 2005-4-12 16:30:08

多谢两位的指导~~

后来 · 发表于 2005-4-12 16:38:18

开发修改完bug，我们测试人员应该要替他们提供修改方法和修改影响范围，这样，我们返测bug的时候，不光要返侧bug本体,还要针对开发提供的影响范围，进行关联性的测试。
还有就是在bug修改结束后，进行回归测试：影响bug的回归测试和，影响模块、流程的回归测试

似梦非梦 · 发表于 2005-4-12 16:58:51

to:后来
谢谢你的意见~
我在现实中经常遇到这样的情况:提交的BUG只是单元A中一个级别较低的问题,但是当开发人员修改好提交的问题后,再交付测试时与单元A没有关联的单元B中却出现有影响流程的问题~
开发人员本身也没预想到可能会出现这样的情况,所以我会头痛```除了关联的之外,还可能会有其他的问题~
另外,你提到的"我们测试人员应该要替他们提供修改方法和修改影响范围",测试人员替开发人员提供修改问题的方法??这,,会不会误导开发人员??

后来 · 发表于 2005-4-12 17:34:39

赫赫，写错了，我们测试人员应该要求开发人员给我们提供他们的修改方法和影响范围，对不起啊；
你说的问题都是存在的，这些也是看开发人员本身的能力，我们公司都是要求开发人员进行影响范围的提示，慢慢开发人员都养成了这样的习惯，所以我们返侧bug，重点都是进行关联的测试，关联测试不光只测模块a,模块b，模块c，都要测到。关联不光侧开发人员提供的影响范围，还有我们经验总结的相关功能，当然对于一个新系统，只能尽自己努力了，发现新问题，只能提交新的bug了。
一个项目的成败，需要开发人员和测试人员共同努力，我们测试完全可以提醒、指导开发人员他们应该做什么，怎么做

似梦非梦 · 发表于 2005-4-12 18:13:15

你的意见不错,谢谢`~之前我和开发人员沟通时也经常要求他们这样做,不过后来开发人员说麻烦就不再写了~

huipingzhai · 发表于 2005-4-13 09:14:13

谢谢

似梦非梦 · 发表于 2005-4-13 09:40:10

to:huipingzhai
??

aidaliu · 发表于 2005-4-18 23:09:59

影响范围＋经验

		自动登录	找回密码
密码			(注-册)加入51Testing

[讨论] 对于回归测试，请问你们用什么方式测试？

相关帖子

简单的功能用自动化，复杂的功能还得手工，没办法

站长推荐 /1