08-05-23问：
随着系统的逐步成熟，每个版本包含的新特性越来越少，但是新功能对原系统的影响有多大是我们在测试时需要重点考虑的问题。此时，就势必要进行回归测试。而且系统越成熟，回归测试的比重也会越大。这将会对测试工作带来不小的挑战。
在实际工作中，经常是一方面求全，希望覆盖面尽量广，避免漏测。另一方面求产出，大量的回归测试用例，可能只发现很少的问题，投入与产出不太匹配，会影响测试人员的士气，甚至测试管理者也会对这种投入产出有所质疑。并且，设计大量的自动化测试脚本，会占用大量的时间。
引子就说这么多，看看大家对这一普遍问题有什么看法和建议
答：
回归测试是个重复繁琐的工作，如果直接选择大量用处不大的用例，直接影响测试人员的心情，效率低下，严重时还遗漏bug，即浪费了时间、浪费人力，又得不到好的效果;
如果回归的用例不足，人、时间当然节约了，但是质量就得不到保障了.
实际工作中进行回归测试前，
首先需要知道哪些地方改过，哪些地方没有改过，改过的地方会对其他地方有什么影响（相关联的地方）
如果能知道可能会引起什么问题那是最好的（必需对软件非常的了解）
针对这些地方再去选择用例，进行回归测试，这样即保证了效率有保证了质量。
对于质量要求高的软件，那就必须进行完全的回归了，这时可以选用自动化工具（公司有条件可以自己开发工具），可以选用QTP,WR等
在软件没有完全稳定的时候可以选用描述性编程。
时间紧迫也可以采用80/20原则，把用户经常操作、还有bug经常发生的地方进行完全的回归或选择有效的用例回归，然后只要保证剩余的模块不出现高等级的bug，其他的地方可以等时间空下来的时候测试人员再进行测试
如果软件几经发布，发现bug以补丁形式发布。
