虽然回归测试很重要，但是实际执行情况却不尽如人意，其主要原因是目前的回归测试通常都是手工测试。其基本流程如下：

   在手工回归测试过程中，存在以下问题：
   ·测试过程中，大量精力花在输入数据、执行程序和数据比较上，无法把精力集中到关键问题上，如提高测试的有效性，编写更多更好的测试用例等。
   ·手工测试工作是一件工作量非常大的、重复的、枯燥的工作，容易使测试人员热情下降，易出错，而且手工操作效率低下。
   ·现在的应用系统使用环境比较复杂，通常会运行在不同的操作系统、数据库、中间件等系统软件上，很难组织这么多业务人员对所有环境进行测试。
   ·随着技术进步，迭代开发越来越盛行，这造成测试工作的周期被缩短了，测试的频率被增加了。在这种情况下，传统的手工测试已经严重的满足不了软件开发的需求。
   ·参与测试的业务人员不足，无法保证充分的测试，而且采用的是临时准备的、随机的测试用例和数据，效果不好，很难发现逻辑错误，也无法重复。
   ·系统投入生产后，紧急版本修复需要发放补丁时，往往没有时间做回归测试。

   2.自动回归测试系统技术实现
   总结各种自动回归测试技术，其实核心问题就是要解决自动回归测试过程中自动化、维护、复用三个主要问题。而我们的自动回归测试系统支持测试用例设计、自动脚本生成、业务流定义和管理、业务流数据配置和管理、测试执行、缺陷报告、缺陷管理和测试报告等功能的实现，很好的解决了上述三个问题。

   2.1 自动回归测试系统功能结构
   我们的自动回归测试系统在通用测试工具上构建了一个自动回归测试框架，框架里包含一个公用函数库和5个主要功能模块。通过自动回归测试框架，自动测试工程师可以完成测试用例设计和自动脚本生成功能，业务人员可以完成业务流定义和数据配置功能，测试执行人员可以完成测试调度和测试管理功能。

  2.2 自动回归测试框架

   2.2.1测试用例设计

   测试用例是最小的业务分支，它规定了需要操作的对象、步骤、动作和需要使用的数据。测试用例是可复用的，因此在测试用例中的数据应是参数化的，由此测试用例产生的测试脚本也是可复用的。

   测试用例应由业务人员和技术人员设计。业务人员使用Excel或其它工具来设计，技术人员使用自动回归测试框架来设计。

   2.2.2脚本生成器
   脚本的维护往往是自动测试系统中维护工作量最大的部分。在我们的自动回归测试框架中，我们提供了自动脚本生成器，由此可以自动产生健壮的、结构化的、易于维护的脚本，自动脚本生成器的基础是测试用例设计。

   2.2.3业务流管理器
   自动测试执行的实际上是一个一个的业务流，业务流是由测试用例串联起来的，为了配置和维护方便，自动回归测试框架提供以下特性：
   ·业务流管理器可以选择测试用例来组成业务流
   ·在业务流中可支持条件分支，形成树状的业务流
   ·提供业务流管理功能，可以新增、删除、修改业务流
   ·支持在一个业务流中对同一个测试用例的多次引用

   2.2.4数据管理器

   数据管理器提供为测试用例指定数据的功能。满足以下要求：
   ·可以在数据管理器上选择需要配置的业务流
   ·选择业务流后，可以选择指定的测试用例
   ·可以显示测试用例所有参数的列表，并提供赋值功能
   ·提供业务流中测试用例间数据映射功能
   ·支持同一个业务流中多次使用同一个测试用例的数据配置

   2.2.5测试调度器
   测试调度器实现以下功能：
   ·配置业务流的执行时间，支持预约测试
   ·可选择业务流执行
   ·执行测试
   ·指定出错时的处理方法