51Testing软件测试论坛

标题: 回归测试时，只测回归点 OR 全测？ [打印本页]

作者: carafe1567 时间: 2015-3-12 09:37
标题: 回归测试时，只测回归点 OR 全测？
本帖最后由 carafe1567 于 2015-3-12 10:10 编辑

碰到过一个案例：
一个版本稳定的软件（已历时1年多，经过N次测试），新加了一个小功能。测试时间2天，1个测试人员，测试了2轮。
测试策略是这样的：第一轮测试新功能，以及新功能可能影响的关联点。第二轮回归验证+跑一遍软件主要功能，提交测试。
结果，提交给客户后，出了问题：发现了2个BUG，都是不常用的小功能和与新功能无关的功能。
原因分析了一下，是改BUG的时候影响到了其他功能，引入了新的BUG。

那么问题来了，开发人员不清楚自己是否可能在某个模块引入了新BUG，测试人员在回归测试的时候，也基本不会进行全测（全测耗时太久也认为没有必要，所以之前没有问题的次要功能就不进行测试了），那么如何控制回归测试的质量？难道每次回归测试都要进行全测吗？
请问大家是怎么做的呢？一起来讨论下。

作者: frankowl 时间: 2015-3-12 10:18
我们是要全测得

作者: hujing_123 时间: 2015-3-12 10:43
这就是测试分析时的关联性影响重要性了；开发一个新功能，却让原来的功能异常，这是肯定不合理的。测试的时候要多分析一下可能关联到的其他问题：一个简单例子，将某个字段长度控制放宽。就可能造成功能直接保存异常。

作者: hujing_123 时间: 2015-3-12 10:45
不过这样的情况再怎么分析也是避免不了了；问题出现后分析一下是否真的跟新功能一点儿关系都没有，还是自己分析关联性的遗漏

作者: carafe1567 时间: 2015-3-12 14:55

frankowl 发表于 2015-3-12 10:18
我们是要全测得

每一轮都全测？这一轮下来得花多少时间啊？

作者: carafe1567 时间: 2015-3-12 14:58

hujing_123 发表于 2015-3-12 10:45
不过这样的情况再怎么分析也是避免不了了；问题出现后分析一下是否真的跟新功能一点儿关系都没有，还是自己 ...

是啊。有的可以从功能上分析出关联性。有的从功能上看是看不出来的，得从代码结构设计和数据库设计上看。

作者: 晓冼youyou 时间: 2015-3-12 16:25
每个版本发布前，我们都会最后安排一次全面测试

作者: luming 时间: 2015-3-13 14:55
除非实在没有时间，分析一下最关键的内容进行测试，否则需要全部测试的。

作者: Miss_love 时间: 2015-3-21 09:06
提供给客户，肯定是要全面测试的

作者: sandy-guo 时间: 2015-3-23 12:36
全测...

作者: qiguojie 时间: 2015-3-24 11:05
全测除非时间充裕，否则不可能。

回归测试除了验证bug修复，还要从bug影响这方面考虑，因此尽量知道bug产生的原因才能做好回归

作者: carafe1567 时间: 2015-3-26 08:52

qiguojie 发表于 2015-3-24 11:05
全测除非时间充裕，否则不可能。

回归测试除了验证bug修复，还要从bug影响这方面考虑，因此尽量知道bug ...

基本上时间是不充裕的，订单时间都比较紧张

作者: amo666 时间: 2015-3-31 21:55
1、让开发人员评估下是否新功能是否会引起老功能的变动，他们最清楚风险了。
2、开测前，把版本包取下来与前一个版本做比对，查看大概改动了些什么地方，可能哪些地方会受影响。
3、要补充被客户发现bug的测试用例。
4、稳定的老功能尽可能做成自动化，版本每次开测时跑一炮。

作者: bug在哪里 时间: 2015-5-13 18:49
做自动化，一般都全测

作者: sally100 时间: 2015-8-4 13:24
回归测试分两步走。第一步是针对你提交的问题进行测试，查看是否已修复，并测试关联功能。如：特殊字符的限制，关联功能为对应的保存和提交按钮。第二步是在软件发布之前，要做最后的全面回归测试，即全部再测一遍，保证所有功能没有问题。

作者: 威特米c 时间: 2016-5-23 10:29
很明显，随便测测的后果，只是看了下基本功能就完事了，没有测全。

作者: 天机 时间: 2016-5-26 10:15

威特米c 发表于 2016-5-23 10:29
很明显，随便测测的后果，只是看了下基本功能就完事了，没有测全。

你说的太轻松了，你看没楼主说的吗？出现问题的模块从业务角度来看是无关联的，只是代码模块影响了。这样测试是很难分析的，只能让开发评估的时候认真点，规范点。而且一般的项目交付时间都不可能充足的，全测根本不可能的！

作者: lovewang0306 时间: 2016-7-6 14:40
我们现在也是第一轮全测，第二轮回归+主要流程测试，因为周期被压的太紧，根本测不完，解决方案只能是一，前期评估工作计划的时候就要说清楚测试范围和可能出现的风险，二、写测试报告的时候说清楚测了哪些功能，这只能是最大程度保护自己，如果产品稳定，周期长，真的应该弄一个自动化测试

作者: JH虚心请教 时间: 2016-12-2 16:26
bug回归+相关连的模块验证后，最后再跑一个完整的主流程，不是按照全部测试用例来跑，是跑功能的测试点

作者: 老鸟 时间: 2016-12-23 08:52
测试很多时候是在根据实际条件（测试周期、改动量、影响性、开发质量）做权衡。
上面amo666说的解决办法确实不错。

1、开发的评估一定要有，我们拿来参考作为重点，不错不能全信，开发评估漏的情况不在少数。
2、版本比对，起码是配置文件和参数的比对，最好做到代码级的比对，这样测试对修改点影响性有了自己的判断，是对开发评估的一个补充。（前提是测试拿得到代码，并且有一定的知识积累）
3、前面两条都做了，已经很不错了，剩下的就交给自动化回归案例来帮忙弥补评估的遗漏吧。

作者: huigor 时间: 2017-7-10 16:20
1、回归BUG本身；
2、根据BUG修改的地方，评估影响范围；尤其是有代码耦合的地方，需要测试验证，看是否为了修改BUG，而引入新的BUG；
3、重点内容，可以也回归测试一下，防止评估不到位；

作者: oucfanglei 时间: 2017-12-31 17:40
需要自动化，如果手动全测基本上不可能，就国内这情况，基本上研发发完版本就要给客户使用，建议修改或者修改涉及范围进行手册，其他尽量自动化执行

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