频繁改动下的回归测试

飞儿乐队

是否可以先解决一个问题：为什么项目会频繁改动？需求的原因？开发送测质量的原因？测试是否彻底？

－－希望能把回归测试的有效和高效放在一起来谈－－
1. 有效性，频繁的改动须保证每次回归测试的有效性，如果只是为了完成了回归而做回归，对回归测试
版本的控制，BUG的修改控制没有做到位的话，任何所谓高效的回归测试也只能是在做些无用功。控制
好测试版本，严控测试的出口和入口是进行回归测试首先要解决的问题；

2. 若是提到高效回归，肯定会谈到自动化，希望能通过自动化来解决回归测试的效率问题（关于自动化
测试对人员、时间、资源的要求不在重复）。是否选择自动化、如何实现自动化就看所做产品／项目的
情况了（较成形的大型产品都会涉及自动化测试，前期设计好的、需求变化不大的项目会用部分的自动
化进行回归）。

3. 进行回归测试需要关心的另一个问题是：主要流程和修改涉汲的主要问题。
1）主要流程是用户实际操作运用最多的，当然要首先保证。
2）修改涉汲的主要问题可以帮我们分析问题，确定测试范围和测试重点。全面的测试当然最好，考虑到
时间关系，最好是能有所侧重。

4.关于问题修改的方式问题
高内聚，低耦合。从这个关点来看，除非是操作流程引起的实现方式的改变，每个问题所涉汲的修改内容
应当是有效和可控的。如果修改一个问题所关联的是全流程，一方面要全面测试，另一方面建议开发对功
能进行剥离，减少耦合度。毕竟高质量的修改代码所能产生的问题的可能性也会大大降低，测试人员可以
将关注点集中在主要问题影响，而不只是些问题的表像。

5.沟通合作问题
与需求和开发的沟通是有效和高效进行回归的关键问题，只有明确了对上一版本的修改状况，修改内容，
以及修改的方式、方法，才能更有效的展开测试问题分析、测试进度安排、测试有例覆盖，才能更有效
和高效的展开回归测试。

洗水果的男孩

很受启发
总的来说就是：1.回归测试用例的有效性决定了回归测试的有效性；2.引入自动化；3.全量回顾测试和选择性优化回归测试根据修改的问题，要有侧重点的进行测试；4.高质量修复问题的方式可以让测试同学更关注问题影响；5.对修改的问题的历史、现状以及修改方式的理解有助于更好的回归测试