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

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

测试计划

测试范围

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

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

测试准则

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

测试资源

人力资源

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

测试环境

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

培训需求

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

培训内容	培训方式	参与人	计划时间
业务培训	讲解需求和参观原系统操作	韩**	2015.7.28
流程建模技术培训	培训Cordys建模操作和自学	韩**	2015.7.28
测试技术培训	讲解测试方案和技术	韩**	2015.7.29

测试策略

测试策略	内容
测试目标	找出并修改整个系统测试中的bug，使系统更加完善，并能体现出系统能力
测试范围
使用的技术	自底向上（流程审批）、自顶向下（阳光大厅）、核心集成测试、分层集成测试、基于使用测试
测试重点与优先级	流程审批、岗位管理、阳光大厅
需考虑的特殊事项	租户管理及人员跨部门
局限性	组织机构、业务不完整

测试进度计划

测试活动过程

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

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

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

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

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

3.搭建测试环境

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

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

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

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

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

（2）.修复缺陷

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

（3）.回归测试

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

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

5.编写集成测试报告

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

测试用例及执行

测试用例

用例编号	模块名称	用例概述	设计者	创建时间	用例状态	操作步骤	测试数据	预期结果
001	新建申请	新建业务申请单并启动流程送下一步	肖永威	2015.7.26	审核通过	见时序图1	资费申请单	产生流程待办
002	审批	填写意见送下一步	肖永威	2015.7.26	审核通过	见时序图2	资费申请单	产生流程待办

新建申请时序图

集成测试用例执行记录

第一轮测试

接口编号	用例编号	是否选用	执行人	执行时间	测试结果	缺陷编号
API001	001	是		2015.7.26	未通过	Bug001
API002	001	是		2015.7.26	未通过	Bug001

第二轮测试
表格同上。

关于集成测试缺陷记录

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

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

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

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

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

6.其他描述内容：

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

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