测试计划模板V0.docx

测试计划模板V0.docx

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

测试计划模板V0

记录文件

XX测试计划

版本

编写

审核

审定

批准

生效时间

A/0

注：

如无受控文件标识（蓝色印章）则为非有效版本，以受控文件规定为准。

本文件产权属中XXX所有，未经许可，不得以任何方式外传。

内部使用如无蓝色受控文件标识章，则为非有效版本，请以受控文件规定为准。

修改记录页

NO

修改日期

修改摘要（涉及页码/条款/内容）

版本

修改原因

目录

1概述3

1.1项目背景3

1.2限制条件3

1.3参考文档3

2约定4

2.1测试说明4

2.2测试目标4

2.3测试资源4

2.3.1人力资源4

2.3.2测试环境4

2.3.3工具5

2.4送测要求5

3测试策略5

3.1整体策略5

3.2测试范围6

3.3风险分析6

4测试类型及测试标准7

4.1测试类型7

4.2测试方法及标准8

4.2.1功能测试8

4.2.2业务测试9

4.2.3性能测试9

4.2.4安装测试9

4.2.5验收测试10

5测试重点及优先级10

5.2测试重点10

5.2.1功能测试10

5.2.2业务测试11

5.3优先级11

5.3.1测试类型优先级11

5.3.2测试模块优先级11

6测试进度安排12

7测试过程管理12

7.1测试文档12

7.1.1测试文档管理12

7.1.2编号规则13

7.2缺陷处理过程13

8测试执行标准13

8.1测试开始标准13

8.2测试暂停标准14

8.3测试停止标准14

1概述

1.1项目背景

简单介绍下项目的情况（如是一期开发还是二期开发），说明该项目已经实现了什么功能，最终要实现什么功能，可以参考功能说明书

1.2限制条件

说明开展本次测试的限制条件如本测试计划可能受限于产品开发人员提交测试的内容和时间的事实及测试人员人数、测试时间的限制；需要根据开发人员提交模块的实际情况，及测试时间的安排，本计划会做出相应修改。

1.3参考文档

列出测试计划需要参考的项目文档的资料，可能根据项目实际情况的不同，而参考的文档会有所不同，系统详细设计说明书可能会根据项目的实际情况划分为各个模块的详细设计说明书，则参考的文档就要具体划分为模块详细设计说明书。

序号

名称

作者

备注

1.

系统需求说明书

2.

系统概要设计说明书

3.

系统详细设计说明书

2约定

2.1测试说明

说明制定该计划适用的范围，如测试计划包括测试主计划和阶段计划，目前文档中做出的是整体测试计划，阶段性的测试计划用project进行设计；根据开发的迭代过程和测试主计划对测试计划进行细化，制订各个阶段的测试计划。

2.2测试目标

说明开展本次测试所要达到的目标，可以根据项目的具体情况需要达到的测试目标不同，如通过测试，达到以下目标：

Ø测试已实现的产品是否达到设计的要求，包括：

各个功能点是否以实现，业务流程是否正确。

Ø产品规定的操作和运行稳定。

ØBug数和缺陷率控制在可接收的范围之内。

2.3测试资源

2.3.1人力资源

列出在此项目的人员配备方面所作的各种假定。

[注：

可适当地删除或添加角色项。

]

角色

所推荐的最少资源（所分配的专职角色数量）

具体职责或注释

项目经理

测试经理

测试人员

2.3.2测试环境

列出测试的系统环境，其中包括软件环境与硬件环境，及简单说明下与实际用户环境的差异，及对测试结果的影响

软件环境（相关软件、操作系统等）

硬件环境（网络、设备等）

2.3.3工具

列出本次测试所用到的工具，不单单是测试工具，也包括文档管理工具、项目管理工具、缺陷管理工具，下表列出了一些参考的工具

用途

工具

生产厂商/自产

版本

缺陷、项目管理工具

禅道

开源

2.3

性能测试工具

LoadRunner

mercury

10.0

2.4送测要求

说明要进行本次测试需要达到的要求，根据项目管理的实际情况设置送测要求，如开发人员提交的测试按以下要求进行：

步骤

动作

负责人

相关文档或记录

要求

1

打包、编译

开发人员

无

确认可测试

2

审核并提交测试

Xx

经审核的上一级测试报告

测试报告xx审核并签字（如进行集成测试就需要单元测试报告审核并签字）

3

接收测试

测试人员

经xx审核并签字的上一级测试报告

4

开始测试

测试人员

Bug单、小结

测试小结个人编写个人的内容

3测试策略

3.1整体策略

本文档把测试种类及标准从测试策略中分离出来单独作为一个小节

说明本次项目的特点：

（例如）

Ø参与的测试人员对系统的了解情况；

Ø系统是已经做过一些测试，正在运行，还是第一次进行测试；

Ø相对于项目要做的事情来说，时间进度非常紧（要建立一个基本完善的测试规范、要设计整套测试用例和执行一轮完整的测试）；

Ø本次项目测试的是只对系统进行一轮测试还是多次测试；

根据以上项目列出的特点，制定本项目的测试过程策略：

（例如）

Ø以80/20原理为指导

尽量做到在有限的时间里发现尽可能多的缺陷（尤其是严重缺陷）；

Ø测试计划与需求制定、用例设计同步进行

Ø必须制定测试需求

通过确定要测试的内容和各自的优先级、重要性，使测试设计工作更有目的性，在需求的指导下设计出更多更有效的用例；

Ø逐步完善测试用例库

测试用例库的建设是一个不断完善的过程，我们要在有限的时间里，先设计出一整套的测试用例，重要的部分用例需要设计得完善一些，一般部分的则指出测试的要点，在以后的测试工作中再不断去完善测试用例库，如测试用例可以先用项目管理工具如禅道设计测试用例，再逐步完善形成测试用例文档保存起来，作为后续测试的依据；

Ø测试过程要受到控制

根据事先定义的测试执行顺序进行测试，并填写测试记录表，保证测试过程是受控的，可以根据项目开发模块的优先顺序进行测试，测试记录可以用缺陷管理工具如禅道来进行管理；

Ø确定重点

测试重点放在各子系统的功能及业务流程之上，客户常用的功能与业务流程是重中之重；

测试技术（说明开展本次测试的技术或方法例如）

◆本项目采用黑盒测试技术。

◆本项目测试过程中将不会采用测试工具。

依据标准（说明本次测试涉及到的文档的依据例如）

说明本次测试中测试文档的编写、测试用例的编写、具体的执行测试以及测试中各项资源的分配和估算的依据，如是以XX公司提供的各子系统的使用手册盒练习指导手册为标准，软件的执行以系统概要设计构架为依据。

3.2测试范围

说明制定本次项目测试范围的依据：

（例如是针对《迪娜林二期概要设计说明书》中规定内容的测试计划，根据以下列出点列出要测试的范围与不做测试的地方）

Ø各子系统所包含的功能或系统模块要实现的功能；

Ø同该项目负责人特别确定的测试范围；

Ø不需要测试的子系统或模块；

3.3风险分析

[简要描述测试阶段的风险和处理的优先级]

例如本次测试过程中，可能出现的风险如下：

Ø缺陷的修复情况；

Ø模块功能的实现情况；

Ø系统整体功能的实现情况；

Ø代码的编写质量；

Ø人员经验以及对软件的熟悉度；

Ø开发人员、测试人员关于项目约定的执行情况；

Ø人员调整导致研发周期延迟；

Ø开发时间的缩短导致某些测试计划无法执行；

[风险发生的可能性说明：

高：

>60%，中：

30%—60%，低：

<30%]

风险类型

风险要素/描述

风险发生可能

风险带来的影响

减少风险的策略

责任人/部门

资源风险

测试环境不能及时到位

60%

30%

请项目组在开发服务器上搭建独立的测试环境。

人员风险

开发、测试人员资源分不足及开发、测试人员调整

60%

60%

拟订备份测试人员，必要时加入团队，执行测试工作。

时间风险

需求变更比较大，但发布时间不变更。

项目测试时间严重不足。

50%

60%

拟订备份测试人员，必要时加入团队，执行测试工作。

开发进度风险

需求变更、代码编写的质量、功能的实现情况

60%

60%

处理的优先级可以根据项目的进度及问题的严重程度进行处理，如致命的、严重的问题必须在一个交付点全部修复，对于一般的、微小与建议的问题可以延后处理，问题的严重程度可以参考本文档的问题严重程度描述该小节的内容。

4测试类型及测试标准

4.1测试类型

说明本次需要进行的测试类型（禅道上划分的类型为单元测试、功能测试、集成测试、系统测试、冒烟测试、版本验证测试，可以根据项目性质的不同设置不同的测试类型）

Ø单元测试

Ø功能测试（在集成测试阶段侧重于功能测试）

Ø业务测试（系统测试阶段侧重于业务测试）

Ø性能测试

Ø安装测试

Ø验收测试

4.2测试方法及标准

4.2.1功能测试

系统能按照设计要求实现模块的各个功能，数据应完整、界面美观、操作方便，具体可参照本文档测试重点及部分。

4.2.1.1界面测试

通过测试进行的浏览可正确反映业务的功能和需求，这种浏览包括窗口与窗口之间、字段与字段之间的浏览、界面色调的搭配、界面布局、字段的命名以及各种访问方法（Tab键、鼠标移动、和快捷键）的使用、窗口的对象和特征（例如，菜单、大小、位置、状态和中心）等是否都符合标准，详细的界面测试可以参考界面测试CheckList.xls。

4.2.1.2数据项测试

Ø字母数字数据项是否能够正确回显，并输入到系统中？

Ø图形模式的数据项（如滑动条）是否正常工作？

Ø是否能够识别非法数据？

Ø数据输入消息是否可理解？

4.2.1.3帮助文档测试

Ø文档是否精确描述了如何使用各种使用模式？

Ø交互顺序的描述是否精确？

Ø例子是否精确？

Ø术语、菜单描述和系统响应是否与实际程序一致？

Ø是否能够很方便地在文档中定位指南？

Ø是否能够很方便地使用文档排除错误？

Ø文档的内容和索引是否精确完整？

Ø文档的设计（布局、缩进和图形）是否便于信息的理解？

Ø显示给用户的错误信息是否有更详细的文档解释？

Ø如果使用超级链接，超级链接是否精确完整？

4.2.2业务测试

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

4.2.3性能测试

4.2.3.1测试说明

本次压力测试根据实际情况包含性能测试，重点模拟客户进行多用户测试。

压力测试有一条8：

2原则。

及百分之八十的业务量在百分之二十的时间内输入。

例如:

正常每天有100条新数据，测试时在两小时内输入80条数据。

我们无法知道用户的业务量，所以只有利用公司现有资源进行大量的数据量的测试。

4.2.3.3压力测试方法及标准

压力测试的方法及标准参考压力测试计划.doc

4.2.4安装测试

4.2.4.1安装测试说明

除了嵌入式软件之外，安装是软件产品实现其功能的第一步，没有正确的安装根本就谈不上正确的执行，因此对于安装的测试就显得尤为重要。

4.2.4.2安装测试方法与标准

Ø自动安装还是手工配置安装，测试各种不同的安装组合，并验证各种不同组合的正确性，最终目标是所有组合都能安装成功；

Ø安装退出之后，确认应用程序可以正确启动、运行；

Ø卸载测试和安装测试同样重要，如果系统提供自动卸载工具，那么卸载之后需检验系统是否把所有的文件全部删除，注册表中有关的注册信息是否也被删除；

Ø至少要在一台笔记本上进行安装测试，因为有很多产品在笔记本中会出现问题，尤其是系统级的产品。

（有条件的情况下）；

Ø安装完成之后，可以在简单地使用之后再执行卸载操作，有的系统在使用之后会发生变化，变得不可卸载；

Ø安装时间是否合理；

Ø对于客户服务器模式的应用系统，可以先安装客户端，然后安装服务器端，测试是否会出现问题；

Ø考察安装该系统是否对其他的应用程序造成影响，特别是Windows操作系统，经常会出现此类的问题；

4.2.5验收测试

4.2.5.1验收测试说明

软件产品测试部对经过内部单元测试、集成测试和系统测试后的软件所进行的测试，测试用例采用业务流程测试用例。

4.2.5.2验收测试方法及标准

具体测试方法可以参照软件验收标准

5测试重点及优先级

5.2测试重点

这里仅为测试重点的描述，具体测试方法以及内容请参见测试用例。

5.2.1功能测试

列出需要进行测试各个模块的功能点，若某个模块功能还没有确定下来可以说明为待定（举例如下）

5.2.1.1商品组装方案

Ø是否使用右键和菜单实现了增、删、改功能；

Ø增加零配件使用产品和价格配制器，查看零配件使用商品编辑窗口；

Ø拖动功能是否正确；

5.2.2业务测试

这里只是描述了业务测试的大概情况，具体测试方法以及内容请参见业务测试用例，这里的业务测试包含模块之间的关系（举例如下）

5.2.2.1销售机会修改

Ø增加费用时关联到费用单；

Ø联系人关联到联系活动、客户计划决策人、组织分析；

Ø与知识库关联；

5.3优先级

5.3.1测试类型优先级

列出进行各类测试的优先级

测试类型

优先级

测试目标

技术

完成标准

备注

单元测试

功能测试

业务测试

性能测试

安装测试

验收测试

5.3.2测试模块优先级

列出系统各个模块的测试优先级，这个可以根据项目开发进度来设置模块测试的优先级，而且只列举大模块，对于细分的模块可以根据测试用例来测试（举例如下）

模块

优先级

备注

资源平台

高

采购中心

中

销售中心

中

行业参数

中

系统平台

高

存货物流

高

客户中心

低

商品管理

中

6测试进度安排

根据测试各个阶段大致估算测试任务所需要的工作量，对于每个阶段的具体工作所需要的时间可以参见具体参见XXXX-工作任务安排.mpp（时间段可以交叉进行）

测试阶段

计划开始日期

计划结束日期

责任人

制定测试计划

设计测试用例

评审测试用例

单元测试

集成测试（侧重功能测试）

系统测试（侧重业务测试）

性能测试

验收测试

产品发布

7测试过程管理

7.1测试文档

7.1.1测试文档管理

说明测试产生文档的管理规则，及测试过程中产生的文档，例如

Ø本项目对测试文档进行集中管理，文档集中存放项目管理软件禅道的文档视图中，每天备份一次。

Ø测试文档由不同角色分别创建，各角色创建的文档如下：

文档名称

编制者

其它说明

《测试计划》

项目经理

《测试需求表》

测试需求制定人员

《测试用例说明书》

测试设计人员

《测试执行记录表》

测试执行人员

《缺陷记录》

缺陷报告人员

《缺陷跟踪汇总表》

缺陷报告人员

《测试总结分析报告》

项目经理

7.1.2编号规则

说明本次测试计划涉及到的文档的相关规则，例如与本测试计划相关的编号规则如下：

Ø测试用例中的编号，功能名+界面名（每个字第一个汉语拼音大写）+编号

例如：

新增报价书第一个用例

XZBJS0001

Ø测试用例文件命命名规则，模块名+测试用例

例如：

客服合同模块

客服合同测试用例

7.2缺陷处理过程

说明进行测试过程中发现缺陷的处理过程，例如本次项目要进行多次测试，要对发现的缺陷进行跟踪，制定的缺陷处理过程如下：

Ø测试人员利用缺陷管理工具禅道记录发现的缺陷指派对应的开发负责人；

Ø开发人员在管理工具上找到指派给自己的缺陷，按缺陷的严重程度、优先级处理缺陷指派给对应的测试人员；

Ø测试人员对已经处理的缺陷进行回归测试，缺陷若已经处理则关闭，若没有处理则重新指派给开发人员，直到缺陷得到处理结果；

Ø测试结束之后形成缺陷记录表，测试报告等其它测试报告提交给客户；

8测试执行标准

8.1测试开始标准

制定出开始进行测试的标准，例如

同时满足以下条件允许开始测试：

Ø测试计划已经制定并且通过了审批；

Ø测试组明确客户需求和设计要求；

Ø测试用例已经设计并且通过了审核；

Ø被测试对象已经开发完毕并等待测试，其版本应已通过实现阶段评审或经项目经理确认；

Ø项目需求变更或产生的新的需求，在原测试计划下做相应的调整后；

8.2测试暂停标准

满足以下条件允许暂停测试：

Ø测试进行中当发现重大缺陷，无法运行系统，应暂停测试返回开发；

Ø软件项目需暂停以进行调整时，测试应随之暂停，并备份暂停点数据；

Ø软件项目在其开发生命周期内出现重大估算错误或需求偏差过大，进度偏差，需暂停时，测试应随之暂停，并备份暂停点数据；

Ø若开发暂停，则相应测试也暂停，并备份暂停点数据；

8.3测试停止标准

同时满足以下条件允许结束测试：

Ø按照测试计划完成了测试；

Ø达到了测试计划中的覆盖率要求；

Ø测试结果验证了客户需求和系统设计要求；

Ø在测试中发现的错误已经得到修改，各级缺陷修复率达到标准；

Ø被测试对象正确运行，对残留错误有合理解释或被认可暂留；

Ø软件项目在其开发生命周期内出现重大估算错误或需求变更很大，进度偏差，需停止时，测试应随之停止，并备份终止点数据；

Ø若项目中止，则对已完成的测试工作做测试活动总结，停止测试；

评审负责人（签名）：

评审日期：

年月日