摘要：程序被修改后，要保证程序能正常运行并且修改不能给程序质量带来任何负面影响，回归测试是必要的。大型软件系统结构复杂，构成要素多，如何做到不遗漏功能点同时降低软件回归测试代价，本文结合业务规则模型、修改影响分析和成本风险管理等技术提出了一种自动化回归测试方法。

　　1、引言

　　在软件测试过程中，由于需要对软件进行修改，修改后的程序必须重新测试，以确保程序的修改是否达到了目的和是否引入了新的错误，这种测试是回归测试。软件的变化可能是源于发现了错误并做了修改，也有可能是因为在集成或维护阶段加入了新的模块。当软件中所包含的错误被发现时，如果对错误的跟踪管理系统不够完善，可能会遗漏对这些错误的修改；而开发人员对错误理解的不够透彻，也可能导致所做的修改只修正了错误的外在表现，没有修改错误本身，甚至可能产生副作用，从而导致软件未被修改的部分又产生新的问题，使本来正常的功能产生错误。同样，在有新代码加入软件的时候，除了新加入的代码中有可能含有错误外，新代码还有可能对原有的代码带来影响。因此，每当软件发生变化时，我们必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。因此需要进行回归测试。

　　回归测试是一种代价较高，比较耗时的测试方法，然而又是必不可少的。大型软件通常规模大，系统结构复杂，构成要素多、层次多，在渐进和快速迭代开发中，新版本的连续发布使回归测试的实施更加频繁。因此，通过选择正确的回归测试策略来改进回归测试的效率和效果，减小回归测试代价是非常有意义的。

　　2、大型软件回归测试面临的问题

　　大型软件回归测试面临两个重大难题：一是系统变更引起的回归测试范围无法准确界定；二是参数组合引起的测试用例急剧膨胀，无法在较短时间内以合理成本完成低覆盖率要求的回归测试。而且大型软件回归测试往往受到测试时间和测试环境条件的约束，而测试的工程性质又决定了它不可能达到理论上的完整。

　　在有限的时间和资源条件下，为了更合理的规划和安排测试工作，在测试计划的制定阶段需要一个决策机制能够在资源约束，如时间、人力、成本的前提下基于风险管理和测试成本预算进行决策。

　　随着软件生命周期的推进，软件的开发与回归测试反复迭代，规则的表达逐渐完善，测试用例库越来越丰富，回归测试的实施效率将越来越高。

　　3、大型软件回归测试方法

　　通过构建回归测试决策支持平台可以为大型软件的回归测试提供可行的解决方案。

　　3.1 业务规则

　　业务规则是定义和约束业务结构与业务行为的规定或规范，是业务运作和管理决策所依赖的重要资源。建立大型软件业务规则模型正是要继承测试专家所积累的业务知识，使事实上得到使用的规则有一种显式的表达。在此基础上，结合测试理论和规则的整合以及用例优化算法，建立自动化用例生成系统。

　　业务规则的来源一般包括：

　　1）业务需求导出的规则；

　　2）测试理论原则导出的规则；

　　3）软件业传统导出的规则；

　　4）业内常识导出的规则。

　　业务规则模型的基础是手工测试中积累的一系列用例设计规则、行业规范和源于业务的特殊约束。业务规则模型用于表达这些手工时代的规则，并建立一种可加载规则的引擎结构，在通过该引擎加载规则后，可以通过决策支持系统生成面向某个具体过程的用例模板的基础用例集。

　　所谓规则的加载，是将某条规则加入规则库中，重点是适用条件的表达和优化算法的指定。

　　对于一个目标系统，一次穷尽所有可能的规则是不可能的，只能渐进地逼进，所以应该允许手工追加规则，这一过程是业务规则模型的学习过程。