2.1.4 集成测试

背景

所谓部分系统的集成测试，是指DCC为满足业务的不断变换而开发的部分业务功能。当开发完成后，进入功能测试阶段，在功能测试完成后，进入集成测试阶段。

此阶段测试的版本已经比较稳定，大的需求变更比较少，边界条件、操作方便性测试完毕；测试的工作集中在测试功能模块的正确性。

部分系统验收测试的方式主要通过业务人员进行手工测试。首先编写测试案例和测试数据，并且进行测试。

测试的周期一般为一个月，三轮至四轮测试。

测试过程中往往发生直接的修改。

测试完成之后，子系统合并入整个系统版本。测试案例和测试数据仅作为文档保存，不再复用。

开发人员在测试过程中支持的测试，发现错误立即修改。并且缺乏缺陷跟踪统计。

在测试过程中，无法统计和分析系统的bug。

目标

验收测试的目标在于：

验证系统的主要功能是否和《需求规格说明书》一致；

测试系统的各个交易系统的分支功能是否能够正确执行；

测试系统的各个交易分支是否能够组成正确的业务循环，各个交易之间是否存在冲突；

测试系统的输入、输出（包括打印格式）等。

当前方法

当系统发生比较大的变动或者新增交易得时候，一般是前置组和主机组分别进行单元测试和集成测试，然后由开放中心统一组织业务人员进行大规模的验证测试。一般会执行多轮次的测试，基本覆盖全部的增加/修改交易。

问题

缺乏有效的案例设计（在回归测试部分已经讲过，不再重复）。

缺乏全面的回归测试方法。

由于缺乏测试人员和快速测试方法，因此无法对系统进行全面的回归测试。

目前的回归测试基本上是通过业务人员来评估所影响的相关交易。通常都是从功能的角度上来考虑关联性。实际上，系统的相关性不仅仅是和外在功能相关，也和系统的体系结构、程序设计紧密相关，从这个方面看，系统的关联性是非常难以评估的。

难以评估的结果，是评估的结果无法完全分析到可能会影响到众多交易和交易分支的交易。真正有效的方法是对整个系统进行一次完整的回归测试，覆盖系统的所有分支。

测试案例和测试数据无法重复，供给后面的测试使用。

测试案例往往由测试人员自己设计、同时缺乏统一的格式、统一的存放方式。当测试完成之后，这部分的文档基本上丢失了。

如果需要重复上一次的测试，在更换了测试人员之后，所有的测试案例设计、测试数据准备工作都需要全部的重复。而重复一次测试，实际上只是一个简单的工作重复。