软件测试计划模板.docx

软件测试计划模板.docx

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

软件测试计划模板

文件编号：

LITJSJ-JH-11-09记录编号：

XXXX

测试计划

编制：

年月日

审核：

年月日

批准：

年月日

洛阳理工学院软件学院Z100551

声明

本测试文档中的各项内容仅供厂商或用户参考。

在任何情况下，若需引用本测试文档中的结果、数据及相关内容，都应征得本单位同意。

在使用时务必要保持其完整和真实意义，不得擅自进行增加、修改、伪造。

洛阳理工学院软件学院Z100551

XXXX年XX月

目录

1简介4

1.1目的4

1.2背景4

1.3范围4

1.4引用文档4

2测试需求4

3测试类型5

3.1产品描述测试5

3.2用户文档测试5

3.3功能性测试5

3.4可靠性测试6

3.5易用性测试6

3.6效率测试7

3.7可维护性测试7

3.8可移植性测试8

4资源9

4.1测试人员和职责9

4.2测试环境9

4.3工具10

5项目里程碑10

6可交付工件10

附录职责11

1简介

1.1目的

•[确定现有项目的信息和应测试的软件构件。

•列出推荐的测试需求（高层次）。

•推荐可采用的测试策略，并对这些策略加以说明。

•确定所需的资源，并对测试的工作量进行估计。

•列出测试项目的可交付元素]

1.2背景

[输入测试对象（组件、应用程序、系统等）及其目标的的简要说明。

需要包括的信息有：

主要的功能和特性、测试对象的构架以及项目的简史。

1.3范围

[描述测试的各个阶段，例如：

单元测试、集成测试或系统测试，并说明本计划所针对的测试类型（如功能测试或性能测试）。

简要地列出测试对象中将接受测试或将不接受测试的那些特性和功能。

如果在编写此文档的过程中作出的某些假设可能会影响测试设计、开发或实施，则列出所有这些假设。

列出可能会影响测试设计、开发或实施的所有风险或意外事件。

列出可能会影响测试设计、开发或实施的所有约束。

]

1.4引用文档

此处列出制定测试计划所用的文档，

2测试需求

下面列出了那些已被确定为测试对象的项目（用例、功能性需求和非功能性需求）。

此列表说明了测试的对象。

[在此处输入一个主要测试需求的高层次列表。

]

[测试策略提供了推荐用于测试对象的方法。

上一节“测试需求”中说明了将要测试哪些对象，而本节则要说明如何对测试对象进行测试。

对于每种测试，都应提供测试说明，并解释其实施和执行的原因。

如果不实施和执行某种测试，则应该用一句话加以说明，并陈述这样做的理由。

例如，“将不实施和执行该测试。

。

该测试不合适。

”

制定测试策略时所考虑的主要事项有：

将要使用的方法以及判断测试何时完成的标准。

下面列出了在进行每项测试时需考虑的事项，除此之外，测试还只应在安全的环境中使用已知的、受控的数据库来执行。

]

3测试类型

3.1产品描述测试

测试目标

[测试产品描述是否可以帮助用户或潜在的购买者做出产品是否适用于他们的评价，产品内容是否正确无误等]

方法

[根据GB/T25000:

51-2010的条款的要求列出测试检查表，按测试检查表进行检查，对每一条子条目结论，对检查表的结论一列进行综合，给出对被测试软件的产品描述测试的结论。

]

完成标准

[执行完成测试检查表中所有的子条目的检查]

需考虑的特殊事项

无

3.2用户文档测试

测试目标

[测试用户文档是否可以帮助用户正确使用产品、维护产品]

方法

[根据GB/T25000:

51-2010的条款的要求列出测试检查表，按测试检查表进行检查，对每一条子条目结论，对检查表的结论一列进行综合，给出对被测试软件的用户文档测试的结论。

]

完成标准

[执行完成测试检查表中所有的子条目的检查]

需考虑的特殊事项

无

3.3功能性测试

[测试对象的功能测试应该侧重于可以被直接追踪到用例或业务功能和业务规则的所有测试需求。

这些测试的目标在于核实能否正确地接受、处理和检索数据以及业务规则是否正确实施。

这种类型的测试基于黑盒方法，即通过图形用户界面（GUI）与应用程序交互并分析输出结果来验证应用程序及其内部进程。

以下列出的是每个应用程序推荐的测试方法概要：

]

测试目标

[确保测试对象的功能正常，其中包括导航、数据输入、处理和检索等。

]

方法

[利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：

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

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

各业务规则都得到了正确的应用。

]

完成标准

[所计划的测试已全部执行。

需考虑的特殊事项

[确定或说明那些将对功能测试的实施和执行造成影响的事项或因素（内部的或外部的）]

3.4可靠性测试

[可靠性是指在指定条件下使用软件产品时，软件产品维持规定的性能级别的能力。

可以进一步细分为4个子特性：

成熟性、容错性、易恢复性、可靠性的依从性。

在完成被测试软件的功能测试的基础上，针对可靠性测试的特点，强调实时、准确地作好记录，包括：

每次测试（运行被测试软件）的起止时间（精确到分钟）、被测试软件每次发生故障的时间、如果发生死机，必须记录发生死机的时间、宕机的时间。

对测试中使用的所有测试用例、测试结果按照4个子特性进行统计分析。

根据子特性测试的要求，补充增加相关测试用例。

然后对被测试软件的可靠性进行加权评价。

]

测试目标

[测试在指定条件下使用时，软件产品维持规定的性能级别的能力]

方法

[根据GB/T16260-2006、GB/T25000:

51-2010的条款的要求列出测试检查表，按测试检查表进行检查，对每一条子条目都进行统计数据及给出结论，综合分析统计的数据，给出对被测试软件的可靠性测试的结论。

]

完成标准

[所计划的测试全部完成]

需考虑的特殊事项

3.5易用性测试

[在完成功能测试的基础上，还应该重点考虑软件的易用性测试，设计易用性测试的测试用例，包括：

对产品描述（需求规格说明、用户手册）的测试、对用户文档和/或帮助系统的测试、被测试软件是否提供了在线帮助、用户能否定位找到帮助主题、能否理解对输入数据的要求、对输出信息的说明、对系统消息的说明、用户能否定制界面元素、被测试软件是否提供了演示程序、统计学习使用一项功能的所需的时间、能否容易地修复输入数据、在操作时能否进行参数值的选择。

对测试中使用的所有测试用例、测试结果按照5个子特性进行统计分析。

根据子特性测试的要求，补充增加相关测试用例。

然后对被测试软件的易用性进行加权评价。

]

测试目标

[测试在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。

]

方法

[根据GB/T16260-2006、GB/T25000:

51-2010的条款的要求列出测试检查表，按测试检查表进行检查，对每一条子条目都进行统计数据及给出结论，综合分析统计的数据，给出对被测试软件的易用性测试的结论。

]

完成标准

[所计划的测试全部完成]

需考虑的特殊事项

无

3.6效率测试

[在完成功能测试的基础上，还应该考虑软件的效率测试，设计效率测试的测试用例，包括：

响应时间、平均响应时间、最坏情况下的响应时间比率、吞吐量、平均吞吐量、周转时间、平均周转时间、等待时间的测试；还包括：

对I/O设备、内存、传输设备（不同介质）的使用情况的测试。

对测试中使用的所有测试用例、测试结果按照3个子特性进行统计分析。

根据子特性测试的要求，补充增加相关测试用例。

然后对被测试软件的效率进行加权评价。

]

测试目标

[测试在规定条件下，相对于所用资源的数量，软件产品可提供的适当的性能的能力]

方法

[进行压力测试、负载测试、大数量测试等，监控各项性能指标，分析数据，给出被测试软件的效率。

]

完成标准

[所计划的测试全部完成]

需考虑的特殊事项

3.7可维护性测试

[维护性是指软件产品可被修改的能力。

修改可能包括纠正、改进或软件对环境、需求和功能规格说明变化的适应。

可以进一步细分为5个子特性：

易分析性、易改变性、稳定性、易测试性、维护性的依从性。

在完成功能测试的基础上，还应该重点考虑软件的维护性测试，设计维护性测试的测试用例。

重点关注：

被测试软件是否具有诊断功能？

测试人员能否确定引起失效的是哪个具体功能？

测试人员能否确定引起失效的是哪个具体操作？

被测试软件是否可以通过参数设置来变更软件的状态？

测试人员能否容易地使用检测点运行测试？

被测试软件是否提供了内置测试功能？

详细、准确地做好回归测试的记录，记录软件测试人员向软件开发人员提交软件测试报告（含错误报告）的时间，软件测试人员获得修改后的版本的时间。

记录在回归测试中发现的软件失效情况，统计回归测试之前，测试人员提交给软件开发人员的、测试中发现的失效数。

统计回归测试中又发现的失效数。

这些数据对于维护性评价十分重要。

对测试中使用的所有测试用例、测试结果按照5个子特性进行统计分析。

根据子特性测试的要求，补充增加相关测试用例。

然后对被测试软件的维护性进行加权评价。

]

测试目标

[测试软件产品可被修改的能力]

方法

[根据GB/T16260-2006、GB/T25000:

51-2010的条款的要求列出测试检查表，按测试检查表进行检查，对每一条子条目都进行统计数据及给出结论，综合分析统计的数据，给出对被测试软件的可维护性测试的结论。

]

完成标准

[所计划的测试全部完成]

需考虑的特殊事项

3.8可移植性测试

[可移植性是指软件产品从一种环境迁移到另外一种环境的能力。

可以进一步细分为5个子特性：

适应性、易安装性、共存性、易替换性、可移植性的依从性。

在完成功能测试的基础上，还应该重点考虑软件的可移植性测试，设计可移植性测试的测试用例。

重点关注：

被测试软件可否在不同硬件环境下运行？

对硬件环境的要求如何？

被测试软件可否在不同操作系统软件或并行应用软件环境下运行？

对不同操作系统软件的适应性如何？

是否能够与其他密切相关软件共同运行？

是否具有对环境、数据库等的设置功能？

软件的安装界面是否友好？

安装是否方便？

被测试软件是否易于重新安装？

是否可以方便地卸载？

软件系统是否能够成功地升级到新版本？

新版本对早期版本的兼容性如何？

软件系统是否能够成功地增加新部件？

新部件与原有用户界面一致的程度如何？

对测试中使用的所有测试用例、测试结果按照5个子特性进行统计分析。

根据子特性测试的要求，补充增加相关测试用例。

然后对被测试软件的可移植性进行加权评价。

]

测试目标

[测试软件产品从一种环境迁移到另外一种环境的能力]

方法

[根据GB/T16260-2006、GB/T25000:

51-2010的条款的要求列出测试检查表，按测试检查表进行检查，对每一条子条目都进行统计数据及给出结论，综合分析统计的数据，给出对被测试软件的可移植性测试的结论。

]

完成标准

[所计划的测试全部完成]

需考虑的特殊事项

4资源

[本节列出推荐项目使用的资源，及其主要职责、知识或技能。

]

4.1测试人员和职责

下表列出了参与此项目测试的人员及所担任的职责。

[注：

可视情况删除或添加项目。

]

角色

责任人

职责

计划完成时间

测试经理

制定测试计划

提供技术指导

获取适当的资源

搭建测试环境

提供管理报告

测试工程师

设计测试用例、确定测试用例的优先级、执行测试、记录测试结果、记录问题缺陷

资料管理员

项目资料的管理

维护配置管理系统

测试产品的配置管理

设备管理员

安排测试设备

4.2测试环境

【反映可用的测试环境、平台，评价和选择测试工具以支持测试，写出选择测试工具的理由及其主要功能。

验证是否有足够的资源满足测试人员的需要】

硬件环境

服务器：

配置：

P41.6GCPU，256M内存，40G硬盘；

客户端：

配置：

P41.6GCPU，256M内存，40G硬盘；

网络环境：

局域网10/100自适网卡；

软件环境

操作系统

服务器：

Win98/Win2000Server/Win2003Server

客户端：

Win98/Win2000/WinXP

应用软件

应用服务器：

Tomcat/Weblogic

数据库：

SQLServer/Oracle/MySQL

浏览器：

IE6.0

测试辅助工具

QESuite，LoadRunner7.8；

4.3工具

此项目将使用以下工具：

[注：

可以视情况删除或添加项目。

]

工具

厂商/自行研制

版本

测试管理

QESuite

北航

1.3

缺陷跟踪

QESuite问题追踪库

北航

1.3

性能测试工具

LoadRunner

MI

7.8

项目管理

VSS

微软

6.0

文档编辑工具

offic

微软

2000/2003/XP

5项目里程碑

[对的测试应包括上面各节所述的各项测试的测试活动。

应该为这些测试确定单独的项目里程碑，以通知项目的状态和成果。

]

里程碑任务

工作量

开始日期

结束日期

制定测试计划

设计测试

执行测试

评估测试

6可交付工件

《测试计划》、《测试方案》需客户确认；

《测试报告》、《问题报告》交付给客户参考使用；

以上资料和《测试用例》测试中心存档。

附录职责

阶段

工作产品

任务分解

责任人

计划完成时间

测试计划

《XXX_系统测试计划》

测试设计和开发

《测试用例》、

测试数据

模块1

模块2

……

评审测试用例、测试数据

测试执行

测试记录、问题报告

模块1

模块2

……

测试结束

测试报告