回归测试-建行自动测试及管理方案（3）
2.1.2 回归测试 背景之一??版本复杂 建设银行的各个分行主要的系统是前端系统和前置系统（主机系统只有一个版本），这两个系统都具有不同的情况，导致版本众多。 对中心而言，还存在协议转换网关系统等。 另外还需要考虑文件传输系统的版本。 背景之二??系统庞大，功能点众多 建设银行的系统子系统众多，功能点众多，有2000多个功能点和交易。因此，实施一次回归测试来测试需要大量的测试人员投入和时间。 一般而言，进行一次测试需要三个星期的时间：测试三轮，每轮一个星期。实际情况是，DCC并没有大量的测试人员，也没有大量的测试时间来进行一次回归测试。因此，目前所采取的回归测试是大量的人工测试。测试方案是有人工进行评估一次修改可能会造成的交易影响都具有那些，然后设计测试方案进行测试。 工作目标 测试工作的目标是： 第一，在完成一次功能修改或者增加子功能之后，对系统进行对应的回归测试，发现由于修改原有系统出现的功能错误； 第二，在完成子版本的回归测试之后，对多个版本和版本组合进行回归测试，发现各个版本可能会出现的问题。 目前方法 第一，业务人员评估功能修改所可能影响的交易，然后设计测试案例和测试数据； 第二，测试案例设计和测试数据准备由负责测试的业务人员自己完成； 第三，该业务人员同时负责完成测试，并且评估是否通过了测试； 第四，测试通过手工完成。 第五，一般测试三至四轮，每轮次一个星期。 存在问题 第一，缺乏有效的测试案例设计。 目前的测试基本上是由业务人员自己来评估需要进行回归测试的范围、设计测试案例和测试数据，确定测试通过的标准。 缺乏有效的测试案例设计和测试通过标准，使得测试的质量不高，并且测试案例无法重复使用。 缺乏有效的测试案例设计，交易的分支路径覆盖根本无法真正达到覆盖，测试效果由于很多分支被忽略而效果不好。 第二，测试效率低下，测试成本高。 由于采用手工测试的方法，手工测试的效率十分低下：完成一个测试交易需要几分钟时间，因此众多的测试案例需要大量的测试人员来完成。 大量的测试使得测试成本据高不下。对大量的重复测试，无法自动完成。 第三，回归测试难以保证测试效果，存在比较大的风险。 由于测试人员不足，测试效率低下，各个交易的分支覆盖测试往往只测试很少的几个分支，导致测试质量无法保证，存在很大的风险。 例如，一个一般的交易，如果它所有需要覆盖的分支有20个，那么往往人工能够测试的分支不足一半。 第四，多版本测试基本上不存在。 在发布一个版本的时候，需要发布多个不同应用、不同软件环境、不同操作系统环境的版本。 那么，各个不同版本的测试非常重要。实际上，DCC无法、也无力对各个版本进行测试，这样导致了版本发布的风险。
