测试计划模板

文件类别： [过程文件/使用指南/相关模板/参考案例]	文件版本：	文件编号：

测试计划 [瀑布式PG-IT]
受控状态：受控

文档密级：普通

文档状态：[ ] 草案 [ ]正式发布 [ ]正在修订

变更履历

序号	版本	变更描述	修订人/日期	审核/日期	批准/日期
1
2
3
4
5
6
7
8
9
10

1.引言

1.1 编写目的

软件测试计划是指导测试过程的纲领性文件，借助软件测试计划，参与测试的项目成员，可以明确测试任务和测试方法，保持测试是过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。同时其他相关人员可以通过测试计划了解测试部门如何开展本项目的测试工作。

网上办事大厅系统的这一“测试计划”文档有助于实现以下目标：

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

● 列出推荐的测试需求。

● 对各种测试策略加以说明，并推荐可采用的测试策略。

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

● 列出测试项目的可交付元素。

1.2 背景

项目委托方：

项目开发单位：

项目名称：

系统开发的软件平台为B/S形式，应用平台为Windows平台，应用于内网局域网。

1.3 定义

本次测试对象为，测试范围个模块里面所有功能，和后台个模块里面的所有功能

前台：

● 模块；

后台：

●

主要为集成测试、系统测试。主要包括功能测试、性能测试、用户界面测试。

测试功能包括：数据查询、数据新增、数据修改、数据删除、数据录入、报表统计、业务流程等。

测试性能包括：

测试风险包括：时间和人力资源方面不足、需求设计方面的变动、缺陷修复不及时等。

测试过程中对发现的各种软件的错误和缺陷，主要依据其严重程度划分五个级别：

⑤ 致命性错误

数据丢失，数据计算错误、数据传递错误、对数据库造成破坏，造成应用系统、操作系统或其它支撑系统崩溃、非正常关闭和非正常死机；

④ 严重性错误

系统的主要功能性错误导致相关联的多个模块受到影响，或者同样的功能性错误在多个模块重复出现；

③ 功能性错误

系统的主要功能存在问题导致部分功能没有实现甚至功能全部没有实现；

② 告警性错误

文字、图片、易用性存在的各种问题，不影响主要功能实现、主要业务运行的；

① 建议

软件设计和功能实现等不完全合理之处提出建议，可改可不改，但修改后会对系统整体品质有所提高。

1.4 参考资料

《项目计划书》

《需求规格说明书》

《项目立项报告》

《用户需求说明书》

2.测试参考文档和测试提交文档

2.1测试参考文档

文档	已创建或可用	已经过评审	作者或来源	计划时间	实际时间
数据库设计说明书	是■　否□	是□　否■	李中山
进度计划	是■　否□	是■　否□	欧百茂
项目立项报告	是■　否□	是■　否□	李中山
项目计划书	是■　否□	是■　否□	李中山
用户需求说明书	是■　否□	是■　否□	黄振宏
需求规格说明书	是■　否□	是■　否□	黄振宏

2.2测试提交文档

文档	已创建或可用	说明
测试计划	是⊙　否□
集成测试用例	是⊙　否□
系统测试用例	是⊙　否□
性能测试方案	是⊙　否□
项目测试报告	是⊙　否□

3.测试进度

测试活动	计划开始日期	实际开始日期	结束日期
制定测试计划
集成测试
系统测试
验收测试

4.测试资源

4.1人力资源

角色	角色姓名	角色数量	具体职责或注释
测试负责人			制定测试计划及测试相关的文档等
测试人员			编写测试用例、执行测试用例、追踪缺陷过程等

4.2 测试环境

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

服务器配置

操作系统：

应用软件：

数据库：

测试机配置

操作系统：

应用软件：

测试工具：

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

服务器配置

CPU：

内存：

硬盘：

必要的网络设备

测试机配置

CPU：

内存：

硬盘：

必要的网络设备

网络环境

M内网

4.3测试工具

用途	工具	生产厂商/自产	版本
缺陷跟踪管理
维护测试用例
记录测试过程
性能测试
功能测试
浏览器数据分析

5.测试风险、优先级

风险：

风险描述	风险等级	出现概率	应对措施
需求、设计等文档存在描述不全面、二义性等问题，导致测试过程中无法依据相关文档对开发出来的功能进行测试；	高	一般	测试人员要在开发阶段对相关需求、设计等文档进行分析，对大体模块功能进行分类，分析业务逻辑，在不清楚的地方及时与开发人员沟通，保证将来开发出来的所有功能都在能对应的需求、设计文档里面找到对应的要求、标准。
需求、设计阶段考虑不周全，导致后期开发返工、测试中断；	高	较少	在需求、设计等文档完成之后尽量组织各相关人员开会进行文档评审。当问题出现之后测试人员应该主动积极与开发人员进行沟通，识别造成的影响范围，对范围内的功能重新设计测试用例进行对应的测试。
没有统一的界面设计规范；	中	较少	尽可能在开发之前确定界面设计规范，当问题出现之后，与项目负责人沟通确定测试标准，。
所有模块的开发没有统一设计，开发人员有自己的设计方式；	中	较少	尽可能在开始编码之前通过会议或者文档等方式沟通、统一设计方式，当问题出现之后，与项目负责人沟通确定标准方式，与标准方式不一致的地方全部以BUG形式提交对应模块开发人员。
需求变更开发；	中	一般	当出现需求变更的时候，形成对应的文档，通过会议或邮件等方式通知各部门负责人及对应开发、测试人员。当测试过程中发现没有对应文档的需求变更，及时与需求、开发方面负责人沟通确认，并补充对应的需求变更文档。
缺陷修复过程中又产生其他的缺陷；	低	较多	尽量在确定解决方案之前全面考虑各种影响，当问题出现之后，测试人员积极与开发人员沟通，识别可能存在问题的地方重新进行测试。
测试过程中发现部分模块发现较多的缺陷；	中	一般	考虑缺陷存在的集中性，当测试过程中出现部分模块发现缺陷较多的时候，组织相关人员对相应模块针对已经发现的问题设计补充测试用例对该模块开展更深入测试。
测试用例设计不到位，忽略了一些边界条件、深层次的逻辑等；	高	较少	对系统进行充分了解、分析之后，组织测试人员讨论、编写公共部分测试用例，各部分单独的测试用例编写完成之后组织全部测试人员对用例进行评审。
对被测系统的特性理解不准确，造成测试范围分析的误差，导致某些地方始终测试不到或严重的标准不对；	高	较少	相关测试人员在对所测部分有充分了解的基础上要对系统全局有相应了解，运用各种用例设计的方法为所测功能设计尽可能全面的用例。当测试过程中出现该类问题，相关测试人员及时跟相关的需求、开发等人员沟通清楚，补充相应测试用例然后执行测试。在条件允许的情况下组织其他测试人员开会分析该类问题，寻找解决策略和方法，并同时预防同类问题在其他地方再次出现。
测试人员现有知识无法全面测试系统的特性；	中	较少	组织有相关技术的人员对测试人员进行简单的培训或指导，协助解决对应的测试问题；当问题并非本部门人员可以解决的时候寻找其他部门甚至其他资源协助解决问题。
测试环境与最终的生产环境不一致，导致部分环境引起的问题到遗留给了用户；	高	较少	尽可能按照最终的生产环境部署同样的测试环境用于开展测试。当软硬件因为各种原因导致无法部署跟生产环境一样的测试环境的时候，尽可能采用有可比性的软硬件部署测试环境。当出现类似的问题的时候，条件允许的直接在生产环境开展对应测试重现问题，或者分析测试环境和生产环境的差异性试图找到问题根源。
测试需要的各种软硬件资源不到位影响测试开展；	中	较少	及时跟项目负责人沟通，确保需要的各种软硬件资源及时提供到位。当测试中出现类似的问题的时候，在申请资源的同时调整测试顺序，在等待资源过程过程中同时开始其他模块或阶段的测试。
测试工具的各种要求、特性不能被满足导致对应测试无法进行下去；	中	较少	在选择测试工具的时候要充分考虑工具的各种要求、特性是否能被满足，在对多种同类测试工具进行选型的时候编制对应的工具对比说明，详细列表不同工具的优势、劣势，根据实际情况选择能满足测试需求的最简单的工具。当测试中出现此类问题的时候，组织相关测试人员依据实际情况决定解决现有工具难点或更换其他同类工具。
测试时间短；	高	较少	根据项目的实际情况，按照公司的裁剪标准，跟项目负责人沟通之后对测试流程进行适当的裁剪，最终裁剪结果不会影响测试的完整性。在需要时候组织相关人员加班赶进度。
人力资源有限；	高	较少	制定出测试计划之后及早向公司申请协调人力资源，保证在不同的测试阶段有充足的人员参与完成计划任务。动员测试人员完成测试任务，必要时，给予相应物质奖励，提高人员工作积极性。
测试人员变动；	中	较少	用不同的工具做好测试过程和结果的记录，当出现人员变动的时候，只要有相应的交接文档，新加入的人员就能快速上手跟进计划。

优先级：

1、功能正确性测试；

2、主要业务流程测试；

3、用户界面测试；

4、性能测试。

6.软件说明

下表列出各模块的相关功能说明：

序号	测试功能点	输入输出质量标准	备注
一
1.1
1.1.1
1.1.2
1.1.3
1.2
1.2.1
1.3
1.3.1
1.3.2
1.4
1.4.1
1.4.2
1.4.3
1.4.4
1.4.5
1.4.6
1.4.7
1.4.8
1.4.9
1.4.10
1.4.11
1.4.12
二
2.1
2.1.1
2.1.2
2.2
2.2.1
2.2.2
2.2.3
2.3
2.3.1
2.3.2
2.3.3
2.4
2.4.1
2.4.2
2.4.3
2.5
2.5.1
三
3.1
3.1.1
3.1.2
3.1.3
3.1.4
3.2
3.2.1
3.3
3.3.1
3.3.2
3.3.3
3.4
3.4.1
3.4.2
3.4.3
3.5
3.5.1
3.5.2
3.6
3.6.1
3.6.2
3.6.3
3.7
3.7.1
3.8
3.8.1
四
4.1
4.1.1
4.1.2
4.1.3
4.1.4
4.1.5
4.1.6
4.2
4.2.1
4.3
4.3.1
4.4
4.4.1
4.4.2
4.5
4.5.1
4.6
4.6.1
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
六	性能测试点
	登陆
	日常交互性操作
	统计查询
	多业务场景性能

7.测试策略

注意：不实施某种测试，则应该用一句话加以说明，并陈述这样的理由。例如，“将不实施该测试。该测试本项目不适用”。

7.1功能测试

对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的录入、处理和查询是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。

功能测试主要保障代码实现是否符合设计、需求，所以在本次测试过程中将实施该测试.

测试目标	确保测试的功能符合设计、需求，其中包括业务流程，数据录入，处理和查询等功能。
测试范围	该系统的所有功能
技术	针对不同的功能点，采用等价类、边界值等测试方法来编写对应的测试用例，以核实以下内容：在使用有效数据的时候得到预期的正常结果；在使用无效数据的时候得到相应的提示性信息或警告、错误消息；各业务规则都得到了正确的实现、应用。
开始标准	功能模块完成开发之后
完成标准	覆盖系统所有功能点且全部达到设计、需求时停止测试
测试重点和优先级	1、涉及各种特定规则的业务实现； 2、数据在新增、修改、删除、查询功能； 3、各种数据统计、报表功能。
需考虑的特殊事项	测试人力资源不足、需求功能的变更、缺陷修复进度不及时等情况都可能影响测试进度。

7.2集成测试

对实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。它最简单的形式是：把两个已经测试过的单元组合成一个组件，测试它们之间的接口。

集成测试主要就是验证多个单独的模块组合起来之后是否能达到整体的功能要求，所以在本次测试过程中将实施该测试。

测试目标	确保各个正常的功能模块组合起来之后能达到需求、设计里面要求的整体效果。
测试范围	该系统的所有功能
技术	针对不同的功能点，采用等价类、边界值等测试方法来编写对应的测试用例，以核实以下内容：在使用有效数据的时候得到预期的正常结果；在使用无效数据的时候得到相应的提示性信息或警告、错误消息；各业务规则都得到了正确的实现、应用。
开始标准	系统各模块开发完成并按计划、顺序组装好
完成标准	系统各模块组装完成后整体效果达到需求、设计所规定的
测试重点和优先级	l 各种常用、重点功能、流程模块； l 关键功能、流程的各种主要支撑数据。
需考虑的特殊事项	各模块集成顺序

7.3系统测试

系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的方案。

系统测试是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。所以在本次测试过程中将实施该测试。

测试目标	在确认的软硬件等基础上，验证系统是否满足了需求规格定义的全部
测试范围	该系统的所有功能
技术	在使用有效数据的时候得到预期的正常结果；在使用无效数据的时候得到相应的提示性信息或警告、错误消息；各业务规则都得到了正确的实现、应用。
开始标准	系统完成集成测试，修复的缺陷达到要求
完成标准	系统整体实现满足需求规格定义的全部
测试重点和优先级	需求里面优先、重点定义的部分
需考虑的特殊事项

7.4验收测试

验收测试，系统开发生命周期方法论的一个阶段，它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。

验收测试旨在说明软件与需求是否一致，所以在本次测试过程中将实施该测试。

测试目标	验证产品能够满足用户所规定的全部需求
测试范围	该系统的所有功能
技术	定义一些特殊测试用例，主要参考系统测试用例
开始标准	产品完成系统测试，修复的缺陷达到要求
完成标准	产品满足合同规定的所有功能和性能
测试重点和优先级	需求里面优先、重点定义的部分
需考虑的特殊事项

7.5用户界面测试

用户界面测试用于核实用户与软件之间的交互。测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，测试还可确保界面测试中的对象按照预期的方式运行，并符合公司或行业的标准。

在本次测试中将实施该项测试。

测试目标	核实以下内容：通过测试进行的浏览可正确反映业务的功能和需求，这种浏览包括窗口与窗口之间、字段与字段之间的浏览，以及各种访问方法（Tab键、鼠标移动、和快捷键）的使用窗口的对象和特征（例如，菜单、大小、位置、状态和中心）都符合标准。
测试范围	所有用户操作界面
技术	通过浏览、执行所有开放给用户的功能操作界面达到以下标准： 11 系统所有页面符合统一的风格要求，系统各级页面具体风格以美工及前端开发人员设计为准； 12 各级页面展示的文字、图片信息符合统一的字体、大小、位置状态等特征； 13 系统提供的各种常规输入、展示控件属性、状态满足公司或行业常用标准； 14 各级界面主要功能键Tab顺序及其他所属不同业务的操作顺序满足易用性的需求；
开始标准	集成测试完成之后
完成标准	所有提供给用户的操作界面全部测试达到预期标准，或符合用户实际可接受标准。
测试重点和优先级	1、系统整体风格； 2、文字、图片展示； 3、常用/特定业务控件的展示方式； 4、功能操作顺序。
需考虑的特殊事项	并不是所有定制或第三方对象的特征都可访问。

7.6用户使用手册测试

用户使用手册测试目的：指导用户使用本公司开发的软件系统；测试应包括：软件概述、运行环境、使用说明、用户操作举例

运行说明：

1．运行表：【列出每种可能的运行情况，说明其运行目的。】

2．运行步骤：【按运行表说明，运行每种操作详细步骤】

程序文件（或命令文件）和数据文件一览表：【按文件名字母顺序或按功能与模块分类顺序逐个列出文件名称、标识符及说明。】

非常规过程：【提供应急或非常规操作的必要信息及操作步骤，如出错处理操作、向后备系统切换操作以及维护人员须知的操作和注意事项。】

操作命令一览表：【按字母顺序逐个列出全部操作命令的格式、功能及参数说明。】

在本次测试过程中将实施该测试。

测试目标	核实操作手册包含足够的内容帮助用户对系统每一个方面都有充分的认识
测试范围	软件概述、运行环境、使用说明、运行说明、程序文件（或命令文件）和数据文件一览表、用户操作举例等
技术
开始标准	用户手册对应部分编写完成
完成标准	用户能正确使用本系统
测试重点和优先级	使用说明、用户操作举例
需考虑的特殊事项

move on