软件项目管理（CMMI成熟度）实践——之集成测试

测试计划

测试范围

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

测试活动过程

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

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

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

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

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

3.搭建测试环境

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

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

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

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

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

（2）.修复缺陷

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

（3）.回归测试

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

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

5.编写集成测试 告

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

测试用例及执行

测试用例

新建申请时序图

Created with Rapha?l 2.1.0 申请人 申请人 业务申请列表界面 业务申请列表界面 申请单框架界面 申请单框架界面 流程选择界面（多流程时出现） 流程选择界面（多流程时出现） 流程选择界面 流程选择界面 1.选择表单，点击“新建”按钮（） 打开申请单（） 2.填写表单，并保存（） 3.选择/自动选择流程（） 显示送下一步按钮（） 4.点击送下一步按钮（） 5.点击关闭按钮（）

集成测试用例执行记录

第一轮测试

第二轮测试
表格同上。

关于集成测试缺陷记录

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

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

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

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

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

6.其他描述内容：

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

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