集成测试计划V12.docx

集成测试计划V12.docx

《集成测试计划V12.docx》由会员分享，可在线阅读，更多相关《集成测试计划V12.docx（11页珍藏版）》请在冰豆网上搜索。

集成测试计划V12

编号：

S201001-05

版本：

V1.3

文档修改记录

版本

修订人

修订说明

批准人

发布日期

v1.0

Xxx

新建

Sixers

2010-3-18

v1.1

Xxx

补充部分内容

Sixers

2010-3-29

v1.2

Xxx

修改讨论后的内容

Sixers

2010-3-31

v1.3

Xxx

修改讨论后的内容

Sixers

2010-4-6

说明

第1章

引言

1.1目的

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

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

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.子系统集成：

借书模块：

商品入库是仓储业务的第一阶段，商品入库管理包括商品接运、商品验收和建立商品档案三方面。

还书模块：

商品出库业务，是仓库根据业务部门或存货单位开出的商品出库凭证（提货单、调拨），按其所列商品编号、名称、规格、型号、数量等项目，组织商品出库一系列工作的总称。

盘存模块：

盘点就是定期或不定期地对店内的商品进行全部或部分的清点。

2.功能集成：

有关增加，删除，修改，查询各个数据的操作。

3.数据集成：

数据传递是否正确，对于传入值的控制范围是否一致等等

4.函数集成：

函数是否调用正常。

元素关系如下图：

图1

2.3集成策略

本系统的集成测试采用自底向上的集成（Bottom-UpIntegration）的方式。

自底向上集成方式从程序模块结构中最底层的模块开始组装和测试。

因为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）事前已经完成组装并经过测试，所以不再需要编制桩模块（一种能模拟真实模块，给待测模块提供调用接口或数据的测试用软件模块）。

选择这种集成方式，管理方便、测试人员能较好地锁定软件故障所在位置。

集成测试中的主要步骤：

1制定审核测试计划

2制定和审核测试用例

3进行测试活动

4书写测试报告

如下表:

活动

输入

输出

职责

制定集成测试计划

设计模型

集成构建计划

集成测试计划

制定测试计划

设计集成测试

集成测试计划

设计模型

基础测试用例

测试过程

集成测试用例测试过程

实施集成测试

集成测试用例

测试过程

工作版本

测试脚本

测试过程

编制测试代码更新测试过程

测试驱动（底向上）

编制驱动或桩

执行集成测试

测试脚本

工作版本

测试结果

测试并记录结果

评估集成测试

集成测试计划

测试结果

测试评估摘要

会同开发人员评估测试结果,得出测试报告

表1

2.4集成顺序

2.4.1软件集成顺序

集成顺序：

自底向上，先子系统，再顶系统。

2.4.2软件/硬件集成顺序

无

2.4.3子系统集成顺序

功能集成：

先查找，后增加，删除，修改。

子系统：

先入库出库模块，后盘点和管理员界面等。

第3章

测试步骤描述

3.1软件集成测试

在本项目中：

采取以下几个步骤：

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

自底向上集成测试的步骤

步骤1:

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

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

步骤2:

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

这里，可能需要测试人员开发一些驱动模块来驱动集成活动中形成的被测模块。

对于比较大的模块，可以先将其中的某几个软件单元集成为子模块，然后再集成为一个较大的模块。

步骤3:

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

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

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

步骤4:

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

2.集成测试：

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

①.测试人员按照测试用例逐项进行测试活动,并且将测试结果填写在测试报告上；（测试报告必须覆盖所有测试用例）

②.测试过程中发现Bug，将Bug填写在Bugfree上发给集成部经理；（Bug状态NEW）

③.对应责任人接到Bugfree发过来的Bug

④.对于明显的并且可以立刻解决的Bug，将Bug发给开发人员；（Bug状态ASSIGNED）对于不是Bug的提交，集成部经理通知测试设计人员和测试人员，对相应文档进行修改;（Bug状态RESOLVED，决定设置为INVALID）;对于目前无法修改的,将这个Bug放到下一轮次进行修改；（Bug状态RESOLVED，决定设置为REMIND）

3.问题反馈：

反馈Bug给开发人员。

⑤.开发人员接到发过来的Bug立刻修改;（Bug状态RESOLVED，决定设置为FIXED）

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

4.回归测试：

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

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

⑦.如果复测有问题返回第2步（Bug状态REOPENED），否则关闭这项BUG（Bug状态CLOSED）

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

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

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

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

6.进入系统测试，ALPHA测试，BETA测试

如下图:

图2.流程图

3.2软件/硬件集成测试

软件测试的主要模块：

1．功能点：

根据用户文档列出所有功能点，检验其正确性

2．接口：

根据用户文档列出所有接口，检验其正确性

3．流程处理：

根据用户文档列出所有流程，检验其正确性

4．外部接口：

根据用户文档列出所有外部接口，检验其正确性

硬件集成暂时不测试。

3.3子系统集成测试

完成单元测试后，完成子系统，如入库模块的测试，使之达到对应于需求的要求.

3.4功能测试

按照相关文档，结合需求，代码设计，测试各个功能模块是否能实现相应功能

第4章

集成测试验收标准

4.1模块验收标准

接口：

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

功能点：

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

流程处理：

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

外部接口：

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

4.2集成测试验收标准

首先，《集成测试设计用例》中所设计的功能测试用例必须全部通过，性能及其他类型测试用例通过90%以上。

在未通过的测试用例中，不能含有‘系统崩溃’和‘严重错误’错误，‘一般错误’小于5%。

测试结果与测试用例中期望的结果一致，测试通过，否则标明测试未通过。

测试回归申请结束

测试人员提出申请这轮测试结束，提交集成部测试经理；

集成部测试经理召集本组人员开会讨论；

讨论通过，进行下一轮测试，并且部署下一轮测试的注意事项，流程等内容；

如果发现这轮测试目前还存在问题没有解决，延期下一轮测试时间，讨论下一步工作应该如何进行。

测试结果申请结束

测试人员提出申请测试结束，提交集成部经理；

集成部经理召集本组人员开会讨论；

1.讨论通过，结束测试任务；

2.如果发现目前测试还存在问题没有解决，延期测试结束时间，并且讨论下一步工作应该如何进行。

第5章

测试工具

5.1测试工具

测试中心平台：

BugFree；

性能测试工具：

360WebTest；

集成测试工具：

Selenium；

其他：

Excel、MicrosoftVisio 

第6章

挂起、恢复和退出条件

6.1挂起

进入第一轮测试，测试人员大体了解一下产品情况，如果在一小时之内发现5个以上（含5个）操作性错误，或者3个以上（含3个）功能性错误，则冒烟测试未通过，退回单元测试组测试；

遇到有项目优先级更高的集成测试任务；

遇到有项目优先级更高的集成任务；

在测试复测过程中发现产品无法运行下去；

人员，设备不足；

重大突发紧急情况；

6.2恢复

符合进入集成测试条件（一小时之内发现5个以下（不含5个）操作性错误，或者3个以下（不含3个）功能性错误）通过冒烟测试；

项目优先级更高的集成测试任务暂告完成；

项目优先级更高的集成任务暂告完成；

复测过程中产品可以运行下去；

人员，设备到位；

突发事件处理完成；

6.3退出

项目因故终止；

不可抗力：

合同专用条款中约定等级以上的自然灾害也属不可抗力；

其他原因的测试工作频频被挂起或者挂起后迟迟恢复不了，并过了客户要求的时期

第7章

责任人和时间表

7.1责任

测试负责人：

Xxx。

控制并完成测试任务和测试过程，决定测试人员提交上来的Bug是否需要修改；

测试设计人员：

Xxx，Xxx。

书写集成测试用例；

测试人员：

Xxx，Xxx，Xxx。

按照测试用例进行测试活动；

开发人员：

Xxx。

程序Bug修改，程序员间协调；

用户代表：

无。

7.2时间表 

开始/结束时间表：

测试工作

进度（人*工作日）

开始日期

结束日期

测试计划

1*2

20100326

20100328

测试设计

2*5

20100401

20100406

测试执行总共进度

3*4

20100406

20100410

每次回归进度

3*1

20100412

20100413

测试报告

1*3

20100420

20100424

表2

第8章

记录和解决问题

8.1记录和解决问题 

记录和解决问题：

利用BugFree平台记录Bug，并指定相关责任人。

更进一步，把BugFree和需求设计文档、开发文档、测试文档、测试用例等联系起来，做成一个软件研发工具套件，即可通过一个Bug方便找到对应的文档、代码、测试用例等等。

解决问题。

小组会议以及开发人员协调负责人，协调测试开发之间的工作。

第9章重新测试程序

9.1重新测试程序

当发生测试完成后，提交物发生重大Bug，或者明显的功能性错误。

导致系统无法使用或者重大影响的，立即返回重新测试。

另外，当发布重要补丁，重要版本更新时（大规模改动）资料片等时，连带原来的系统一起重新审核重新测试。