集成测试计划模板文档格式.docx

集成测试计划模板文档格式.docx

《集成测试计划模板文档格式.docx》由会员分享，可在线阅读，更多相关《集成测试计划模板文档格式.docx（10页珍藏版）》请在冰点文库上搜索。

制作人

部门

日期

文件发行管制章

批准

签名

审查

核准

1.前言

1.1.目的

本文是描述XXX管理系统的集成测试的大纲文章，主要描述如何进行集成测试活动，如何控制集成测试活动，,集成测试活动的流程以及集成测试活动的工作安排等。

保证程序连接起来也能正常的工作，保证程序的完整运行。

1.2.范围

本次测试计划主要是针对软件的集成测试：

不含硬件，系统测试，以及单元测试（需要已经完成单元测试）

主要的任务是：

1.测试在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；

2.测试各个子功能组合起来，能否达到预期要求的父功能；

3.一个模块的功能是否会对另一个模块的功能产生不利的影响；

4、全局数据结构是否有问题；

5、单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。

主要测试方法是：

使用黑盒测试方法测试集成的功能。

并且对以前的集成进行回归测试

本文主要的读者对象是：

项目负责人，集成部门经理，测试工程师。

1.3.术语

软件测试：

软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例，并利用这些测试用例运行软件，以发现软件错误的过程。

测试计划：

测试计划是指对软件测试的对象、目标、要求、活动、资源及日程进行整体规划，以保证软件系统的测试能够顺利进行的计划性文档。

测试用例：

测试用例指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略的文档；

内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。

测试对象：

测试对象是指特定环境下运行的软件系统和相关的文档。

作为测试对象的软件系统可以是整个业务系统，也可以是业务系统的一个子系统或一个完整的部件。

测试环境：

测试环境指对软件系统进行各类测试所基于的软、硬件设备和配置。

一般包括硬件环境、网络环境、操作系统环境、应用服务器平台环境、数据库环境以及各种支撑环境等。

1.4.测试环境

序号

描述

配置

1#

浏览器

IE&

Firefox

2#

输入习惯

中文

4#

操作系统环境

WindowsXP

1.5.参考文件

开始测试需要以下文档：

●《需求计划书》-RequirementAnalysis

●《项目计划表》-ProjectPlan

●《软件设计书》-SoftwareDesign

●《单元测试报告》-ModuleTestReport

●《用户手册》-UserManual

开始测试前必须完成的任务：

●软件编码；

●单元测试；

结束时提交的文档：

●《测试计划书》；

●《测试用例》；

●《测试报告》；

●《测试总结》；

●；

2.产品描述

2.1.功能描述

参照《×

×

需求说明书》、《×

功能说明书》。

2.2.当前版本

系统版本：

1.0。

3.测试概述

3.1.测试目标

●接口：

接口提供的功能或者数据正确。

●功能点：

验证程序与产品描述、用户文档中的全部说明相对应，一致性。

●流程处理：

验证程序与产品描述、用户文档中的全部说明相对应，一致性

●外部接口：

●界面：

美观、易用、合理

3.2.测试步骤

在本项目中：

采取以下几个步骤：

1.设计《集成测试设计用例》

自底向上集成测试的步骤

步骤1:

按照概要设计规格说明，明确有哪些被测模块。

在熟悉被测模块性质的基础上对被测模块进行分层，在同一层次上的测试可以并行进行，然后排出测试活动的先后关系，制定测试进度计划

步骤2:

在步骤1的基础上，按时间线序关系，将软件单元集成为模块，并测试在集成过程中出现的问题。

步骤3:

将各软件模块集成为子系统（或分系统）。

检测各自子系统是否能正常工作。

可能需要测试人员开发少量的驱动模块来驱动被测子系统。

步骤4:

将各子系统集成为最终用户系统，测试是否存在各分系统能否在最终用户系统中正常工作。

2.集成测试：

组织人员按照1中的《集成测试设计用例》测试系统集成度。

①.测试人员按照测试用例逐项进行测试活动,并且将测试结果填写在测试报告上；

（测试报告必须覆盖所有测试用例）

②.测试过程中发现Bug，将Bug填写在缺陷记录上发给项目经理；

③.对应责任人接到项目经理发过来的Bug

④.对于明显的并且可以立刻解决的Bug，将Bug发给开发人员；

对于不是Bug的提交，项目经理通知测试设计人员和测试人员，对相应文档进行修改;

;

对于目前无法修改的,将这个Bug放到下一轮次进行修改；

3.问题反馈：

反馈Bug给开发人员。

⑤.开发人员接到发过来的Bug立刻修改，并填写单元测试报告;

⑥.测试人员接到项目经理发过来的错误更改信息，应该逐项复测，填写新的测试报告（测试报告必须覆盖上一次的测试用例）；

4.回归测试：

重新测试修复Bug后的系统。

重复3，直到4回归测试结果到达系统验收标准。

⑦.如果复测有问题返回第2步，否则关闭这项BUG

本轮测试中测试用例中有90一次性通过测试,结束测试任务；

本轮测试中发现的错误有95经过修改并且通过再次测试，返回进行新的一轮测试；

5.集成测试测试总结报告：

完成以上4步后，综合相关资料生成报告。

6.进入系统测试

3.3.测试方法

3.3.1黑盒测试

黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。

在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。

3.3.2黑盒测试的方法有：

具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。

等价类划分的办法是把程序的输入域划分成若干部分（子集），然后从每个部分中选取少数代表性数据作为测试用例。

每一类的代表性数据在测试中的作用等价于这一类中的其他值。

该方法是一种重要的，常用的黑盒测试用例设计方法。

3.4.进入准则

●编码阶段已经审核完成

●单元测试已经完成

●项目经理已经批准了集成测试计划

●测试组已经设计好测试案例，经过测试组组长的检查，并通过项目经理批准

●测试数据已经准备好并经过检查

●测试资源已经到位（软件、硬件、人力）

3.5.结束准则

●测试遇到的所有问题已经记录下来

●所有测试案例都已运行

●90％的测试案例已经成功通过

●所有测试案例至少运行了三次，所有错误已经修改

●测试结果已经记录，测试分析报告已经提交项目经理检查

3.6.考虑事项

●单元划分

●模块关联接口

●重要的实行路径

●错误处理

●极端条件

●数据准确性

●基于程序说明的测试案例

4.控制和协调

4.1.测试用例检查和质量控制

所有测试用例应该经过项目经理及测试主管的检查。

严格按照测试计划时间表执行，如有推迟则适当调整计划时间，并记录原因。

如需求有变动，项目经理负责协调开发与需求人之间进行沟通，对计划及时调整。

4.2.测试流程

4.3.开发组和测试组之间程序版本控制

为测试人员提供可执行的软件环境，开发人员负责对其内容的修改。

所有开发人员必须在自己的工作站保存最新版本的代码，不得变更测试程序目录下的内容。

在修改之前，由开发人员通知测试人员将做哪些修改和修改将影响的功能。

5.资源需求和依赖条件

5.1.软/硬件依赖条件

软/硬件名称

数量

开始日期

截至日期

说明

5.2.测试数据需求

在测试案例运行前，应准备所有需要的测试数据。

5.3.测试人员需求

●测试组组长：

研发经理

●测试人员：

测试组人员

●测试用例设计人员：

●测试数据准备人员：

●测试运行人员：

6.进度表

测试用例

工作量

负责人

计划开始日期

计划结束日期

排课功能与课时消耗功能关联

4天

XXX

2012.09.13

2012.09.16

测试用例-排课功能与课时消耗功能关联

测试执行步骤

编写用例

1天

执行用例

修复bug

回归测试、测试报告