软件产品测试计划书

修订历史记录

AMD：（A-添加，M-修改，D-删除）

目录

软件产品测试计划书... 1

目录... 3

1           引言... 3

1.1       目的... 3

1.2       项目背景... 3

1.3       名词定义... 4

1.4       参考资料... 4

2           测试任务及要求... 4

2.1       文档测试内容与要求... 4

2.2       应用系统测试内容与要求... 5

3           测试方案... 6

3.1       测试环境... 6

3.2       测试组织... 6

3.3       测试时间安排... 7

3.4       测试流程要求... 7

3.5       测试方案及用例... 7

4           测试进度... 10

5           系统风险、优先级... 10

6           问题严重度描述... 11

7           与测试相关的任务... 11

7.1       制定测试计划... 11

7.2       设计测试... 12

7.3       实施测试... 12

7.4       记录缺陷，分析缺陷... 12

1     引言

1.1  目的

本文是为了测试智能交通秩序管理系统而编制， 编制目的在于为此系统的管理工作和技术工作提供指南；确定测试的内容和范围，为以后评价智能交通秩序管理系统提供依据。

本文主要依据《智能交通秩序管理应用手册》和《智能交通秩序管理系统需求规格说明书》编制。同时，本文也是编制《测试用例》、《测试问题报告》的依据。

1.2  项目背景

1.3  名词定义

 文档中的缩略语和术语有：

1.4  参考资料

1、 下表列出了制定测试计划时所使用的文档：

2、 测试提交文档：

2     测试任务及要求

2.1  文档测试内容与要求

2.1.1              文档测试内容

1.   《智能交通秩序管理应用手册》

2.   《智能交通秩序管理系统需求规格说明书》

2.1.2              文档测试要求

1     文档的完整性：主要是测试文档内容的全面性与完整性，从总体上把握文档的质量。例如用户手册应该包括软件的所有功能模块。

2     描述与软件实际情况的一致性：主要测试软件文档与软件实际的一致程度。例如用户手册基本完整后，我们还要注意用户手册与实际功能描述是否一致。因为文档往往跟不上软件版本的更新速度。

3     易理解性：主要是检查文档对关键、重要的操作有无图文说明，文字、图表是否易于理解。对于关键、重要的操作仅仅只有文字说明肯定是不够的，应该附有图表使说明更为直观和明了。

4     文档中提供操作的实例：这项检查内容主要针对用户手册。对主要功能和关键操作提供的应用实例是否丰富，提供的实例描述是否详细。只有简单的图文说明，而无实例的用户手册看起来就像是软件界面的简单拷贝，对于用户来说，实际上没有什么帮助。

5     印刷与包装质量：主要是检查软件文档的商品化程度。有些用户手册是简单打印、装订而成，过于粗糙，不易于用户保存。优秀的文档例如用户手册和技术白皮书，应提供商品化包装，并且印刷精美。

2.2  应用系统测试内容与要求

2.2.1           系统测试内容

下面主要针对智能交通秩序管理系统的功能测试建立了一个相对完善的评测体系，各测试项分布情况如下：

2.2.2              系统测试要求

能测试完成后进行业务测试，业务测试关注的要点是业务流程，及数据流从软件中的一个模块流到另一个模块的过程中的正确性

3     测试方案

3.1       测试环境

a)   测试地点

北京易华录信息技术有限公司 研究院

b)    测试环境

c)   测试工具

3.2       测试组织

3.3       测试时间安排

3.4       测试流程要求

便于在测试阶段中对文档的归档和对bug 的追踪以及管理，要求如下：

测试人员：列出进行测试的具体步骤（进行过何种测试），测试结果，反馈给开发人员

开发人员：提供功能清单，列出测试失败的详细描述、原理分析、修改方法和修改结果并形成文档回馈给测试人员

3.5       测试方案及用例

    测试方案提供了对测试对象的推荐方法。

3.5.1           阶段性测试方案

3.5.1.1                                  系统测试

系统测试流程图

3.5.1.2           安装部署测试

安装测试流程图

3.5.2            测试方法及用例

3.5.2.1        功能测试

l  概述：确保测试项目的功能正常，如导航，数据输入，处理、检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面（GUI）与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程,这是目前的测试重点。

l  目标：利用有效的和无效的数据来执行各个用例流，以核实以下内容：

²  在使用有效数据时得到预期的结果

²  在使用无效数据时显示相应的错误消息或警告消息。

注：除测试所提供的功能外，还需添加Cookies测试

3.5.2.2        用户界面测试

l  概述：用于核实用户与软件之间的交互是否正常

l  目标：核实下列内容

²  确保各种浏览以及各种访问方法（鼠标移动、快捷键等）都使用正常

²  确保窗口对象及其特征（菜单、大小、位置、状态和中心）都符合标准等

3.5.2.3        安装部署测试

l  概述：测试软件在正常情况和异常情况下的安装状况

l  目标：核实下列行为

²  首次安装、升级、完整的或自定义的安装都能进行安装

²  磁盘空间不足、缺少目录创建权限等异常情况的安装

3.5.2.4        文档测试

测试用户手册与需求说明书的准确型，一致性。

4     测试进度

5     系统风险、优先级

L=Low(风险与处理的优先级为低) M=Middle(风险与处理的优先级为中) H=High(风险与处理的优先级为高)

6     问题严重度描述

7     与测试相关的任务

7.1    制定测试计划

l   确定测试需求，制定测试策略

l   确定测试资源，创建时间表、生成测试计划

7.2    设计测试

l   确定并说明测试用例

l   确定测试过程

7.3    实施测试

l   记录或通过编程创建测试脚本

l   执行测试过程

l   确定设计与实施模型中的测试专用功能

l   建立外部数据集

7.4    记录缺陷，分析缺陷

l   实施测试后，记录缺陷

l   提交至开发人员

 

第二篇：软件集成测试计划书

1引言 1.1编写目的本文是描述****集成测试的大纲文章，主要描述如何进行集成测试活动？如何控制集成测试活动？集成测试活动的流程以及集成测试活动的工作安排。本文主要的读者对象是项目负责人，集成部门经理，集成测试设计师。1.2背景项目名称：***集成测试项目相关对象：******************1.3定义**********：********************1.4参考资料《*********》2测试项目本测试主要为***系统的集成测试，目前***的版本为2.0,测试是***的最终集成测试，是建立在开发组程序员开发完毕自己的测试以及开发组测试的基础之上3 被测特性3.1操作性测试主要测试操作是否正确，有无误差？分为两部分：3.1.1返回测试由主界面逐级进入最终界面，按EXIT键逐级返回，检查返回时候屏幕聚焦是否正确比如：1. 进入“系统设置”2. 进入“频道搜索”3. 进入“自动频道搜索”4. 按EXIT键返回，检查当前聚焦是否为“频道搜索”5. 按EXIT键返回，检查当前聚焦是否为“系统设置”3.1.2进入测试由主界面逐级进入最终界面，按MENU键返回主界面，再次进入，检查是否聚焦正确比如：1. 进入“系统设置”2. 进入“频道搜索”3. 进入“自动频道搜索”4. 按MENU键返回主界面5. 当前聚焦是否为“系统设置”6. 进入“系统设置”，当前聚焦是否为“频道搜索”3.2功能测试测试机顶盒中每个应用的功能是否正确3.3性能测试3.3.1疲劳性测试测试连续开机1个月不关机器，每3天去运行一次应用。看系统的稳定性3.3.2大容量数据测试前段***数据库表中含有大量数据，测试***功能4 不被测特性5 测试方法1. 书写测试计划2. 审核测试计划，未通过返回第一步3. 书写测试用例；4. 审核测试用例，未通过返回第三步5. 测试人员按照测试用例逐项进行测试活动,并且将测试结果填写在测试报告上；（测试报告必须覆盖所有测试用例）6. 测试过程中发现bug，将bug填写在bugzilla上发给集成部经理；（bug状态NEW）7. 集成部经理接到bugzilla发过来的bug7.1 对于明显的并且可以立刻解决的bug，将bug发给开发人员；（bug状态ASSIGNED）;7.2 对于不是bug的提交，集成部经理通知测试设计人员和测试人员，对相应文档进行修改; （bug状态RESOLVED，决定设置为INVALID）;7.3 对于目前无法修改的,将这个bug放到下一轮次进行修改；（bug状态RESOLVED，决定设置为REMIND）8. 开发人员接到发过来的bug立刻修改;（bug状态RESOLVED，决定设置为FIXED）9. 测试人员接到bugzilla发过来的错误更改信息，应该逐项复测，填写新的测试报告（测试报告必须覆盖上一次中所有REOPENED的

测试用例）；10. 如果复测有问题返回第六步（bug状态REOPENED）11. 否则关闭这项BUG（bug状态CLOSED）12. 本轮测试中测试用例中有95%一次性通过测试,结束测试任务；13. 本轮测试中发现的错误有98%经过修改并且通过再次测试（即bug状态CLOSED），返回第五步进行新的一轮测试；14. 测试任务结束后书写测试总结报告；15. 正规测试结束进入非正规测试，首先是ALPHA测试，请公司里其他非技术人员以用户角色使用系统。发现bug通知测试人员，测试人员以正规流程处理bug事件；16. 然后是BETA测试，请用户代表进行测试。发现bug通知测试人员，测试人员以正规流程处理bug事件。几点说明：测试回归计划为三次； 测试用例应该写得比较详尽，步骤一定要标明清楚（应该包括：编号，测试描述，前置条件，测试步骤以及测试希望结果）； 对于测试人员觉得应该进行的测试项目，测试人员应该报告测试设计人员，完善和健全测试用例； 测试报告与测试用例分开，测试报告标明测试用例序号以及是否通过Y/N； 对于集成部经理无法决定的上交项目负责人决定； 性能测试中的疲劳性测试可以结合在功能测试部分，即测试期间不关闭机器； 性能测试中的大容量数据测试放在测试后部分轮次（第二步，只需要进行一次） 6 测试通过标准测试结果与测试用例中期望的结果一致，测试通过，否则标明测试未通过。6.1测试结果审批过程6.1.1测试回归申请结束测试人员提出申请这轮测试结束，提交集成部经理；集成部经理召集本组人员开会讨论；讨论通过，进行下一轮测试，并且部署下一轮测试的注意事项，流程等内容；如果发现这轮测试目前还存在问题没有解决，延期下一轮测试时间，讨论下一步工作应该如何进行。6.1.2测试结果申请结束测试人员提出申请测试结束，提交集成部经理；集成部经理召集本组人员开会讨论；1. 讨论通过，结束测试任务；2. 如果发现目前测试还存在问题没有解决，延期测试结束时间，并且讨论下一步工作应该如何进行。7 测试挂起和恢复条件7.1挂起条件进入第一轮测试，测试人员大体了解一下产品情况，如果在一小时之内发现５个以上（含５个）操作性错误，或者３个以上（含３个）功能性错误，退回测试组测试； 遇到有项目优先级更高的集成测试任务； 遇到有项目优先级更高的集成任务； 在测试复测过程中发现产品无法运行下去； 人员，设备不足。 7.2恢复条件符合进入集成测试条件（一小时之内发现５个以下（不含５个）操作性错误，或者３个以下（不含３个）功能性错误）； 项目优先级更高的

集成测试任务暂告完成； 项目优先级更高的集成任务暂告完成； 复测过程中产品可以运行下去； 人员，设备到位。 8应提供的测试文件测试计划书 测试用例 测试报告 测试总结 9测试任务制定审核测试计划 制定和审核测试用例 进行测试活动 书写测试报告 10测试环境需求10.1硬件需求***********10.2软件需求************10.3测试工具*************10.4测试需要的条件**************10.4.1需要的文档用户手册 应用手册 安装说明 10.4.2需要完成的任务程序员本人测试 测试组完成测试 11角色和职责集成（测试）经理：控制并完成测试任务和测试过程，决定测试人员提交上来的bug是否需要修改； 测试设计人员：书写集成测试用例； 测试人员：按照测试用例进行测试活动； 开发人员：MHP程序bug修改； 用户代表：进行BETA测试。 12 人员和培训集成测试经理有责任对测试相关人员进行测试流程，规章制度培训； 测试设计人员有责任对测试人员进行测试操作培训 13 测试进度测试工作 进度(人＊工作日) 测试计划 8 测试设计 60 测试执行总共进度 30 每次回归进度 10 测试报告 ２ 14风险及应急计划设备不到位:加紧设备购买;人员不到位人员请假：请假人员回来加班或赶紧测试进度／申请调配新的人员；人员离职：调配新的人员；人员调配到其他部门或项目：调配新的人员；开发人员开发频频出错：通知开发部门，商量策略；其他原因的测试工作频频被挂起或者挂起后迟迟恢复不了：加班或延期15审批集成部经理 技术部经理姓名： 姓名：日期： 日期：