回归测试时，只测回归点 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:45
不过这样的情况再怎么分析也是避免不了了；问题出现后分析一下是否真的跟新功能一点儿关系都没有，还是自己 ...
是啊。有的可以从功能上分析出关联性。有的从功能上看是看不出来的，得从代码结构设计和数据库设计上看。 每个版本发布前，我们都会最后安排一次全面测试 除非实在没有时间，分析一下最关键的内容进行测试，否则需要全部测试的。 提供给客户，肯定是要全面测试的 全测... 全测除非时间充裕，否则不可能。
回归测试除了验证bug修复，还要从bug影响这方面考虑，因此尽量知道bug产生的原因才能做好回归 qiguojie 发表于 2015-3-24 11:05
全测除非时间充裕，否则不可能。
回归测试除了验证bug修复，还要从bug影响这方面考虑，因此尽量知道bug ...
基本上时间是不充裕的，订单时间都比较紧张 1、让开发人员评估下是否新功能是否会引起老功能的变动，他们最清楚风险了。
2、开测前，把版本包取下来与前一个版本做比对，查看大概改动了些什么地方，可能哪些地方会受影响。
3、要补充被客户发现bug的测试用例。
4、稳定的老功能尽可能做成自动化，版本每次开测时跑一炮。 做自动化，一般都全测 很明显，随便测测的后果，只是看了下基本功能就完事了，没有测全。 威特米c 发表于 2016-5-23 10:29
很明显，随便测测的后果，只是看了下基本功能就完事了，没有测全。
你说的太轻松了，你看没楼主说的吗？出现问题的模块从业务角度来看是无关联的，只是代码模块影响了。这样测试是很难分析的，只能让开发评估的时候认真点，规范点。而且一般的项目交付时间都不可能充足的，全测根本不可能的！ 我们现在也是第一轮全测，第二轮回归+主要流程测试，因为周期被压的太紧，根本测不完，解决方案只能是一，前期评估工作计划的时候就要说清楚测试范围和可能出现的风险，二、写测试报告的时候说清楚测了哪些功能，这只能是最大程度保护自己，如果产品稳定，周期长，真的应该弄一个自动化测试 bug回归+相关连的模块验证后，最后再跑一个完整的主流程，不是按照全部测试用例来跑，是跑功能的测试点 测试很多时候是在根据实际条件（测试周期、改动量、影响性、开发质量）做权衡。
上面amo666说的解决办法确实不错。
1、开发的评估一定要有，我们拿来参考作为重点，不错不能全信，开发评估漏的情况不在少数。
2、版本比对，起码是配置文件和参数的比对，最好做到代码级的比对，这样测试对修改点影响性有了自己的判断，是对开发评估的一个补充。（前提是测试拿得到代码，并且有一定的知识积累）
3、前面两条都做了，已经很不错了，剩下的就交给自动化回归案例来帮忙弥补评估的遗漏吧。
页:
[1]
2
