请问大伙是怎样选取回归用例的？
因为我是系统阶段测试，对软件内部实现不太懂，当对BUG回归测试的时候，多数情况是用以前的用例全部测试一遍，很费时，如果时间紧就只能凭经验来测试，这时候新产生的BUG难免漏掉，我想请教一下大伙是怎么做的，谢谢了。我们是第一轮或第二轮全部执行用例，在后几轮的回归中，挑选错误覆盖率高的模块的用例进行执行，而在最后一轮测试中需要再全部执行一遍用例，这样可以既不会浪费太多时间，也能基本保障没有漏掉的测试。 呵，谢谢你的分享 我们在回归测试的时候往往是先验证已改bug，然后将基本功能走一遍，最后是测试容易出错的地方，当然，这是在回归测试的时间很短的情况下进行的。时间充裕的时候回归测试是要将所有的用例都测试一遍的，这样会避免漏测。 study 时间够就全部做，不够就只能先验证fixed的地方，然后依靠以前的积累和经验来选择做回归的功能点。 一般都全跑一遍。不够时间的话就按经验来跑。或者挑重要的，就是出了问题会被人骂的那种来回归。 上面几位都说得差不多了
主干流程是一定要的，毕竟连流程都跑不通铁定被k死....
其实回归测试这东西很取决于项目的当初立项的范围，如果功能划分得好，后期的回归测试做起来会很轻松。
如果可能的话，与开发人员沟通紧密些，可以使你对估算可能出现的问题有更大的把握
楼上的朋友那种说法好像就太过于靠经验了，如果做了比较久对系统熟悉还好，不然回归测试可靠性会差一些。
不过有时间的话肯定是推荐全部用例都跑一遍的，哈 例子:
一般的系统控制在一星期一个版本
第一轮执行用例==>发现BUG1,2,3==>由开发人员修改==>测试人员只查看BUG123只否已修复==>再进行第二轮测试 事实上根本没有那么多时间让你从头到尾的跑所有的用例的！！但是一定要验证之前FIXED的功能点！！！ 4楼说得不错，学习了！ 1.在时间充裕的情况下,是可以将所有的测试用例全部执行一遍的,不过,在人力,成本上就会有所牺牲.
2.让项目中的技术负责人对于修改的问题进行影响范围的分析,测试人员根据影响范围进行测试,这种方式的成功率,效率还是挺高的.
页:
[1]
