3 存在问题

尽管目前的这种工作模式能够保证DCC系统的稳定运行，但是仍然存在较大隐患。随着分行推广工作的深入，有些隐患可能会直接影响到DCC系统的安全运行。另外从开发中心的规划和CMMI3级的要求来看，现有的测试工作模式已经不能满足开发中心未来的发展目标。

在开发过程中，开发人员开发出来的程序经过了多轮测试，从单元测试、连接测试、功能测试、集成测试到系统测试、压力测试，得到了非常充分的验证。而在维护阶段，目前的方法存在以下问题：

1.回归测试的业务覆盖率严重不足：目前的测试都是“见招拆招”的方法，那里修改了，针对修改部分进行测试，但是这个修改会影响哪些部分？修改后，受影响部分还是否功能正常？这种回归测试不充分的情况，是一种可能致命的隐患，如对一些参数表的修改和对公共模块的修改，都可能影响很多模块的功能和性能。

2.缺乏统一的版本验证规范：目前对于新发布版本的测试没有统一的标准，各种不同类型的修改分别需要测试到什么程度？需要多少测试案例？这些问题往往都是由开发人员和业务人员临时决定的。这样做无法保证版本验证测试的质量，给DCC系统的安全运行造成隐患。

3.缺陷管理严重不足：目前的缺陷管理都是通过填写纸制的PTM书来实现的。对于质量部门来说，很难跟踪缺陷的整个生命周期，同时也无法全面了解缺陷在系统中的分布情况、数量的变化趋势等。因此也不能获得比较准确的统计数据，影响了决策的科学性。

4.没有完整、规范的测试案例库：目前测试的案例都是测试人员自己选择、编写的，测试案例质量的好坏和测试人员的素质有很大关系。对于同样一个交易的测试，如果由不同的测试人员来测试，测试质量会有很大的不同。只有进行科学论证和挑选，开发出一套标准测试案例集，才能保证测试的质量，既能充分测试正常的功能和异常情况，还能使测试过程尽量经济，尽可能少进行重复测试。

5.测试人员严重不足：随着推广工作的大规模开展，参与系统开发和测试的业务人员和技术人员大部分投入到分行支持工作中，开发中心的缺陷修复和功能增强在发布前的测试得不到需要的资源。

6.用例不可重用，缺乏标准：每次的测试案例和测试数据都需要重新设计，测试的基础数据也需要重新准备。测试是否成功的标准也存在众多的人为判断因素，缺乏科学评估标准。

7.测试周期过长，成本很高：

由于目前性能测试使用的是开发组自行开发的测试工具，测试质量不能保证。很有可能当一些核心模块改变时，会导致系统整体性能下降，使业务运作不顺畅，甚至会丢失业务数据。

组成一次回归测试的周期很长，人员很多，造成了大量的成本，也影响了工作效率。