附：集成测试计划书 模版

原创作者：jerry 系统分析之窗

1 引言

1.1编写目的

本文是描述****集成测试的大纲文章，主要描述如何进行集成测试活动？如何控制集成测试活动？集成测试活动的流程以及集成测试活动的工作安排。本文主要的读者对象是项目负责人，集成部门经理，集成测试设计师。

1.2背景

项目名称：***集成测试

项目相关对象：******************

1.3定义< /p>

**********：********************

1.4参考资料

《*********》

2 测试项目

本测试主要为***系统的集成测试，目前***的版本为2.0,测试是***的最终集成测试，是建立在开发组程序员开发完毕自己的测试以及开发组测试的基础之上

3 被测特性

3.1操作性测试

主要测试操作是否正确，有无误差？分为两部分：

3.1.1返回测试

由主界面逐级进入最终界面，按EXIT键逐级返回，检查返回时候屏幕聚焦是否正确

比如：

1. 进入“系统设置”

2. 进入“频道搜索”

3. 进入“自动频道搜索”

4. 按EXIT键返回，检查当前聚焦是否为“频道搜索”

5. 按EXIT键返回，检查当前聚焦是否为“系统设置”

3.1.2进入测试

由主界面逐级进入最终界面，按MENU键返回主界面，再次进入，检查是否聚焦正确

比如：< /p>

1. 进入“系统设置”

2. 进入“频道搜索”

3. 进入“自动频道搜索”

4. 按MENU键返回主界面

5. 当前聚焦是否为“系统设置”

6. 进入“系统设置”，当前聚焦是否为“频道搜索”

3.2功能测试

测试机顶盒中每个应用的功能是否正确

3.3性能测试

3.3.1疲劳性测试< /p>

测试连续开机1个月不关机器，每3天去运行一次应用。看系统的稳定性

3.3.2大容量数据测试

前段***数据库表中含有大量数据，测试***功能

4 不被测特性

5 测试方法

1. 书写测试计划

2. 审核测试计划，未通过返回第一步

3. 书写测试用例；

4. 审核测试用例，未通过返回第三步

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

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

7. 集成部经理接到bugzilla发过来的bug

7.1 对于明显的并且可以立刻解决的bug，将bug发给开发人员；（bug状态ASSIGNED）;

7.2 对于不是bug的提交，集成部经理通知测试设计人员和测试人员，对相应文档进行修改; （bug状态RES●LVED，决定设置为INVALID）;

7.3 对于目前无法修改的,将这个bug放到下一轮次进行修改；（bug状态RES●LVED，决定设置为 REMIND）

8. 开发人员接到发过来的bug立刻修改;（bug状态RES●LVED，决定设置为FIXED）

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

10. 如果复测有问题返回第六步（bug状态RE●PENED）

11. 否则关闭这项BUG（bug状态CL●SED）

12. 本轮测试中测试用例中有95%一次性通过测试,结束测试任务；

13. 本轮测试中发现的错误有98%经过修改并且通过再次测试（即bug状态CL●SED），返回第五步进行新的一轮测试；

14. 测试任务结束后书写测试总结报告；

15. 正规测试结束进入非正规测试，首先是ALPHA测试，请公司里其他非技术人员以用户角色使用系统。发现bug通知测试人员，测试人员以正规流程处理bug 事件；

16. 然后是BETA测试，请用户代表进行测试。发现bug通知测试人员，测试人员以正规流程处理bug事件。

几点说明：

● 测试回归计划为三次；

● 测试用例应该写得比较详尽，步骤一定要标明清楚（应该包括：编号，测试描述，前置条件，测试步骤以及测试希望结果）；

● 对于测试人员觉得应该进行的测试项目，测试人员应该报告测试设计人员，完善和健全测试用例；

● 测试报告与测试用例分开，测试报告标明测试用例序号以及是否通过Y/N；

● 对于集成部经理无法决定的上交项目负责人决定；

● 性能测试中的疲劳性测试可以结合在功能测试部分，即测试期间不关闭机器；

● 性能测试中的大容量数据测试放在测试后部分轮次（第二步，只需要进行一次）

6 测试通过标准

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

6.1测试结果审批过程

6.1.1测试回归申请结束< /p>

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

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

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

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

6.1.2测试结果申请结束

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

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

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

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

7 测试挂起和恢复条件

7.1挂起条件

● 进入第一轮测试，测试人员大体了解一下产品情况，如果在一小时之内发现５个以上（含５个）操作性错误，或者３个以上（含３个）功能性错误，退回测试组测试；

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

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

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

● 人员，设备不足。

7.2恢复条件

● 符合进入集成测试条件（一小时之内发现５个以下（不含５个）操作性错误，或者３个以下（不含３个）功能性错误）；

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

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

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

● 人员，设备到位。

8 应提供的测试文件

● 测试计划书

● 测试用例

● 测试报告

● 测试总结

9 测试任务

● 制定审核测试计划

● 制定和审核测试用例

● 进行测试活动

● 书写测试报告

10 测试环境需求

10.1硬件需求< /p>

***********

10.2软件需求< /p>

************

10.3测试工具< /p>

*************

10.4测试需要的条件< /p>

**************

10.4.1 需要的文档

● 用户手册

● 应用手册

● 安装说明

10.4.2需要完成的任务

● 程序员本人测试

● 测试组完成测试

11 角色和职责

● 集成（测试）经理：控制并完成测试任务和测试过程，决定测试人员提交上来的bug是否需要修改；

● 测试设计人员：书写集成测试用例；

● 测试人员：按照测试用例进行测试活动；

● 开发人员：MHP程序bug修改；

● 用户代表：进行BETA测试。

12 人员和培训

● 集成测试经理有责任对测试相关人员进行测试流程，规章制度培训；

● 测试设计人员有责任对测试人员进行测试操作培训

13 测试进度

测试工作进度(人＊工作日)

测试计划 8

测试设计 60

测试执行总共进度 30

每次回归进度 10

测试报告 2

14 风险及应急计划

设备不到位:加紧设备购买;< /p>

人员不到位

人员请假：请假人员回来加班或赶紧测试进度／申请调配新的人员；

人员离职：调配新的人员；

人员调配到其他部门或项目：调配新的人员；

开发人员开发频频出错：通知开发部门，商量策略；

其他原因的测试工作频频被挂起或者挂起后迟迟恢复不了：加班或延期

15 审批

集成部经理技术部经理

姓名：         姓名：

日期：         日期：