集成测试计划模板.doc

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