模板化的集成测试计划

集成测试计划 版本：V1.3 文 档 编 号 保 密 等 级 作 者 最后修改日期 审 核 人 最后审批日期 批 准 人 最后批准日期 修订记录 日期 版本 修订说明 修订人 目 录 1 简介 3 1.1 目的 3 1.2 背景 3 1.3 范围 3 1.4 参考文档 3 2 测试约束 3 2.1 测试进出条件 3 2.1.1 进入条件 3 2.1.2 退出条件 3 2.2 测试通过和失败准则 3 2.2.1 通过准则： 3 2.2.2 失败准则： 4 2.3 测试启动/结束/暂停/再启动准则 4 2.3.1 测试启动准则 4 2.3.2 测试结束准则 4 2.3.3 测试暂停/再启动准则 4 3 测试需求 4 4 测试风险 5 5 集成策略 5 6 测试策略 5 6.1 策略描述 5 6.2 测试类型 5 6.2.1 功能测试 5 6.2.2 接口测试 6 6.2.3 容错测试 6 6.2.4 回归测试 6 6.3 测试轮数 7 7 测试资源 7 7.1 人力需求 7 7.2 测试环境 8 7.3 测试工具 8 8 测试进度 8 9 本阶段量化计划 9 10 交付物 9 简介 目的 【描述集成测试计划的编写目的及本次集成测试的主要目的。】 如，编写目的：本文档用于描述XXX开发项目集成测试所要遵循的规范以及确定测试方法、测试环境、测试用例的编写和测试整体进度的计划安排、人力资源安排等。 测试目的：集成测试的目的是测试组成XXX系统的各子模块间的接口及功能实现等。 背景 【描述项目或产品的背景。】 范围 【描述集成测试在项目的整体范围。如，需要集成的各功能模块的描述。】 参考文档 【描述本次集成测试所需要参考的文档。】 测试约束 【描述本次集成测试所要遵循的准则及条件约束等。】 测试进出条件 进入条件 【描述集成测试的测试依据和满足该阶段测试进入的条件和约束。】 退出条件 【描述满足该阶段测试退出的条件,要根据 《项目量化管理计划》中第3节的内容来制定退出条件，例如 致命和严重级别的缺陷清除率达到 100％,致命和严重的缺陷修复率达到100％，一般缺陷的修复率达到99％并且遗留缺陷数小于5个；同时参考《测试过程》中的相关描述，并要求系统测试每轮发现的缺陷数量呈收敛趋势。】 测试通过和失败准则 通过准则： 【描述集成测试每一轮测试通过的条件。】 如，每轮测试所有用例全部执行完毕，且没有出现致命性错误，回归测试或执行新增测试用例时不再出现问题，则测试工作通过； 失败准则： 【描述集成测试某轮次测试失败的条件。】 如，每轮测试所有用例全部执行完毕，没有出现致命性错误，回归测试或执行新增测试用例时不再出现问题，且回归测试的周期不少于X天，回归测试执行的测试用例数比例不低于XX％，则测试工作通过。 测试启动/结束/暂停/再启动准则 测试启动准则 【描述集成测试执行启动的约束准则。】 如， 配置管理员提交给测试组每次build的正确版本及集成的模块清单。 测试环境通过检验之后。 测试结束准则 【描述集成测试执行结束的约束准则。】 如，测试案例全部执行完毕，测试结果证明系统符合需求，遗留的问题满足测试退出条件且在质量标准允许范围内，即可结束测试。 测试暂停/再启动准则 【描述集成测试执行过程中出现的特殊情况的约束准则。】 如，被测模块出现某个致命性错误。测试案例无法继续执行，测试工作需暂停，如果非关联模块可以进行测试则执行非关联模块的测试；当这些问题得到解决后重新启动该模块的测试工作。 测试需求 【根据系统集成构建计划，列举每次集成的新版本产生新的测试需求功能点，包括接口的测试需求。】 需求ID 模块 子模块 待测试功能需求点 优先级 模块一 子模块1 功能点1 功能点2 … 功能点N 子模块2 … 子模块N 测试风险 【此处描述测试任务可能遇到的风险，以及规避的方法】 风险 编号 风险描述 风险发生可能性 （高、中、低） 风险的影响程度 （高、中、低） 责任人 规避方法 集成策略 【描述集成的方法、集成的顺序和集成的环境。详细的集成环境见《环境配置清单-集成环境》 集成顺序一般有：深度优先、自下而上、自上而下等； 深度优先：即关键（主控路径上的）业务流程涉及到的模块先集成到一起，然后再集成辅助业务模块； 自下而上：即已实现的较底层的功能优先集成，然后逐层上升，形成整个系统； 自上而下：即事先存在一个稳定的架构，不断地向下细化，最后实现所有具体的功能细节； 集成顺序的选择可以是不同集成顺序的综合。 】 集成计划 【说明项目周期内计划执行的集成活动的时间安排】 集成次号 集成目标 被集成对象 计划集成时间 包含的接口 测试策略 【测试策略提供了对以上测试对象实施测试的方法。上一节“测试需求”中说明了将要测试哪些对象，而本节则要说明如何对这些测试对象进行测试。】 【对每一个工作版本将进行以下三种类型的测试：A、接口测试，测试接口调用。B、功能测试，测试工作版本应该实现的功能。C、回归测试，在新版本中执行以前集成版本的测试用例脚本。】 策略描述 【此处描述根据项目的具体特征所确定的集成测试的策略（如：测试可行性分析，测试技术方法确定，测试类型选择以及集成的方案环境描述等】 测试类型 【此处描述集成测试选择的测试类型，一般建议有如下四种：】 功能测试 测试目标： 确保已经集成的工作版本的正确性，能够实现该集成版本应该具有的功能的正确性以及完整性。 技术： 重用为系统功能测试设计的部分测试用例，部分测试过程。生成测试脚本，实现测试自动化。 完成标准： 所计划的测试全部执行、 对以前版本的接口完成了回归测试、 所发现的高优先级缺陷和高等级的缺陷已完全解决。 需考虑的特殊事项： 开发人员应该保证每个后续的集成版本的基本界面元素都未改变。 考虑测试脚本的重用性以及自动化测试。 测试方法描述 【此处描述一个特定的测试类型在项目测试活动中如何具体的执行。】 接口测试 测试目标： 确保“测试需求”中对应的所有工作版本的内部单元组合到一起后能够按照设计的意图协作运行，接口的调用正确。 技术： 重用为系统测试准备的测试用例、 分析测试用例对接口的覆盖情况，对没有覆盖的接口设计足够的测试用例，以覆盖所有的调用接口。 为每个测试用例制定测试过程，生成测试脚本。以实现测试的自动化。 完成标准： 所计划的测试全部执行、 对以前版本的接口完成了回归测试、 所发现的高优先级缺陷和高等级的缺陷已完全解决。 需考虑的特殊事项： 开发人员应该保证每个后续的集成版本的基本界面元素都未改变。 考虑测试脚本的重用性以及自动化测试。 测试方法描述 【此处描述一个特定的测试类型在项目测试活动中如何具体的执行。】 容错测试 测试目标： 验证异常错误流程能顺利执行，并有易懂的提示信息 技术： 包含在上述功能和接口的测试用例设计中 完成标准： 对每一个非法的操作显示相应的错误信息或警告信息。 需考虑的特殊事项： 测试方法描述 【此处描述一个特定的测试类型在项目测试活动中如何具体的执行。】 回归测试 测试目标： 确保前一个集成的版本并未因为新版本的增量集成而带来缺陷。 技术： 在新的集成版本中使用前一个集成版本的自动化测试脚本执行自动化测试。 完成标准： 前一个集成版本的所用测试用例已全部执行。 所发现的缺陷已全部解决。 需考虑的特殊事项： 开发人员应该保证每个后续的集成版本的基本界面元素都未改变。 考虑测试脚本的重用性以及自动化测试。 测试方法描述 【此处描述一个特定的测试类型在项目测试活动中如何具体的执行。】 测试轮数 【根据集成计划确定的集成次数，计划整个产品开发周期内集成测试的次数】 测试资源 人力需求 【列出此项目的测试人员配备方面的需求。】  角色 人员 具体职责 测试经理 进行管理监督。 职责：          提供技术指导          获取适当的资源          提供管理报告 测试设计员   确定测试用例、确定测试用例的优先级并实施测试用例。 职责： 生成测试计划 生成测试模型 评估测试工作的有效性 测试员 执行测试。 职责： 执行测试 记录结果 从错误中恢复 记录变更请求 测试系统管理员 确保测试环境和资产得到管理和维护。 职责：管理测试系统    分配和管理角色对测试系统的访问权 数据库管理员 确保测试数据（数据库）环境和资产得到管理和维护。 职责：  管理测试数据（数据库）   测试环境 【列出了测试项目所需的系统资源。 】 资源 名称/类型 硬件和网路环境 数据库服务器 - 网络或子网 - 服务器名称 - 数据库名称 用户端测试 PC 包括特殊的配置需求 测试数据存储库 \\JJJ\Test\Data - 网络或子网 内部局域网 - 服务器名称 \\JJJ 测试开发 PC \\03824-1，\\02194-2，\\02336。 软件环境 DBMS 中间件 AppServer 浏览器 其它 测试工具 【本次测试将使用的工具】 用途 工具 厂商/自产 版本 测试管理 测试执行 缺陷报告 测试进度  【根据集成测试的轮次，分解测试工作，计算工作量（N:人数，M：工作日）。每一轮次任务均包括上轮次的回归验证工作】 编号 任务 工作量（人日） 开始日期 结束日期 制定测试计划 N*M 设计测试用例 执行测试（第一轮） 执行测试（第二轮） … 执行测试（第N轮） 最后一轮回归测试 对测试进行评估 合计工作量 交付物 【描述集成测试需要交付的工作产品】 交付物名称 责任人 参与者 交付日期 测试计划 测试用例 测试脚本 测试报告 。。。