本文描述集成测试的测试计划、测试活动过程、测试用例及执行等三部分内容实践，每部分仅举例部分实际内容供参考，以及相关测试规范。

测试计划

测试范围

根据项目整体情况，确定测试对象、测试重点。本项目范围包括：基础服务平台、流程能力平台、系统接口、业务展示（阳光大厅）、业务实施等五部分，如下图所述为基础服务平台部分。

说明：
源功能：可以理解为待集成模块的入口，即从哪个模块获取数据；
目标功能：可理解为待集成模块的出口，即向哪个模块输出数据，也就通过具体功能来涵盖并测试基础服务。

测试准则

入口准则：
待集成测试的产品组件已通过了代码审查或单元测试。
出口准则：
集成测试用例已经通过评审；
测试用例执行覆盖率达到80%以上；
集成测试中发现的缺陷已修复，修复率达到90%以上。

测试资源

人力资源

列出本计划涉及的人员及对应职责。

测试环境

列出测试环境的软硬件资源。

培训需求

对测试人员的技能进行评估，确定培训需求。

测试策略

测试进度计划

测试活动过程

1.制定及维护集成测试计划

• 在项目策划阶段，测试负责人或项目经理将集成测试时间、人员等内容初步填写到《项目实施计划中》，提交项目经理审批，作为集成测试的初始计划。
• 在《系统集成方案》确定之后，测试负责人根据项目实际情况，指定测试人员、测试范围、测试日期、测试环境、测试策略、测试方法、测试步骤及测试通过标准等内容，并形成《集成测试计划》，提交给项目经理，项目经理组织项目成员、测试人员、项目级QA进行评审，评审过程按照《技术评审过程》中的规定执行。

说明：集成测试过程在项目中可能被执行多次，在制定《集成测试计划》时需要参考《产品集成方案》，来确定集成测试策略。

2.制定及维护集成测试用例

测试人员根据《软件需求说明书》、《概要设计说明书》等文档，并结合合适的测试策略及测试方法，制定《集成测试用例》并提交给项目经理，项目经理组织测试负责人、测试人员、项目成员、项目级QA对《集成测试用例》进行评审，评审过程按照《技术评审过程》中的规定执行。

3.搭建测试环境

按项目实施计划，集成测试开始之前，测试负责人或项目经理指定人员依据《集成测试计划》搭建集成测试环境，在搭建测试环境过程中，需要项目经理协调软硬件资源，项目成员提供技术支持，并协助验证集成测试环境的正确性。

说明：待测试的程序或代码必须从配置管理库（SVN）处获取。

4.执行集成测试
（1）.执行集成测试

• 测试人员按照《集成测试计划》和《集成测试用例》进行集成测试，并将测试执行过程及结果记录到《集成测试用例执行记录》中，便于后期测试用例的跟踪与分析。
• 若测试过程中发现缺陷，测试人员将缺陷记录到《集成测试缺陷记录》中，填写缺陷的基本描述信息，指定“解决人”（项目成员），并将缺陷状态置为“已提交”。

说明：在测试过程中，测试人员也应该检查被测试的产品组件及关系是否符合《接口列表》（来自：产品集成方案）。
说明：在测试执行过程中，如果发现测试的缺陷较多或重大功能尚未实现，测试负责人认为可以中止本次集成测试，需要填写《集成测试中止报告》，提交项目经理、部门经理处。

（2）.修复缺陷

• 项目开发人员在《集成测试缺陷记录》中，过滤出分配给自己的缺陷，并且状态为“已打开”或者“重新打开”。
• 项目开发人员对缺陷进行分析，若认为缺陷却是存在，则变更缺陷状态为“打开”；若认为不是缺陷则变更缺陷状态为“拒绝”。
• 项目开发人员从配置库中获取相应的代码，修改完毕后提交代码，并更新《集成测试缺陷记录》中的缺陷状态为“修复”。

（3）.回归测试

• 在新一轮集成测试开始前，测试负责人（或指定的其他技术人员）重新部署或安装待测试程序或代码，经过项目成员确认后方可进行回归性测试。
• 测试人员在《集成测试缺陷记录》中，过滤已经修复的缺陷，进行测试并验证，验证通过后将缺陷状态置为“关闭”；否则置为“重新打开”。

说明：待测试的程序或代码必须从配置管理库（SVN）获取。

5.编写集成测试报告

• 《集成测试计划》评审通过后，按《配置管理过程》将其纳入配置库进行管理。
• 《集成测试用例》评审通过后，按《配置管理过程》将其纳入配置库进行管理。
• 集成测试活动达到了退出标准，按《配置管理过程》对集成测试过程中的工作产品进行配置管理。

测试用例及执行

测试用例

新建申请时序图

集成测试用例执行记录

第一轮测试

第二轮测试
表格同上。

关于集成测试缺陷记录

集成测试缺陷记录定义如下：

1.缺陷编号：缺陷的唯一标示，命名规范：模块名称+编号（从001开始）。
2.缺陷类型：

• F-功能：如逻辑，指针，循环，递归，功能等缺陷。
• G-语法：如拼写、标点符号等缺陷。
• A-赋值：如声明、重复命名、作用域。
• I-接口：与其它组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。
• B-联编打包：由于配置库、变更管理或版本控制引起的错误。
• D-文档：需求、概要设计、详细设计等文档。
• U-用户接口：人机交互特性：屏幕格式、确认用户输入、功能有效性。
• P-性能：不满足系统可测量的属性值，如执行时间、事务处理速率等。
• N-标准：不符合各种标准的要求，如编码标准、设计规定等。
• E-环境：设计、编译、其它支持系统的问题。

3.严重程度：致命、严重、一般、轻微。
4.优先级：“高”级别缺陷需立即被解决；“中”级缺陷需正常排队等待修复；“低”级缺陷可在方便时被修复。
5.缺陷状态：

• 已提交：已提交的缺陷。
• 打开：确认已提交的缺陷，等待处理。
• 拒绝：拒绝已提交的缺陷，不需要修复或不是缺陷。
• 修复：缺陷被修复。
• 关闭：确认被修复的缺陷，将其关闭。
• 重新打开：验证修复的缺陷，验证结果未修复。

6.其他描述内容：

• 缺陷描述
• 缺陷来源
• 报告人员、报告日期
• 解决人、解决措施、解决日期
• 验证人、验证日期

上述缺陷记录内容，可以使用表格工具管理（例如：WPS表格、Excel）。