测试计划的设计和编写

最近入职了新公司，项目组只有我一个测试，自成一家，哈哈，领导让编写测试计划，因而在网上看了不少，最终本身拟了一份，但愿能和你们共勉！

目录

1     引言... 4

1.1      产品简介... 4

1.2      编写目的... 4

1.3      参考文档... 4

1.4      限制条件... 5

2     测试概要... 5

2.1      测试目标... 5

2.2      测试范围... 5

2.3      测试资源... 6

2.3.1       测试人力资源... 6

2.3.2       测试环境... 6

2.3.3       BUG管理工具... 6

3     测试规范... 7

3.1      测试接收标准... 7

3.2      BUG规范... 7

4     测试策略... 9

4.1      测试流程及工做量估算... 9

4.2      测试种类... 10

4.2.1       功能测试... 11

4.2.2       容错性测试... 12

4.2.3       易用性测试... 13

4.2.4       UI（界面）测试... 13

4.2.5       接口测试... 14

4.2.6       系统测试... 14

4.2.7       兼容性测试... 15

4.2.8       性能测试... 15

4.2.9       安装卸载测试... 17

5     发布标准... 17

5.1      测试输出文档... 17

5.2      测试完成标准... 18

5.3      产品发布标准... 18

6     测试风险... 18

 

1     引言

1.1    产品简介

1.2    编写目的

此文档根据项目需求文档，制定测试策略、评估测试风险，肯定所需的资源，并对测试的工做量进行估计，进行人员和进度安排，而且列出测试项目的可交付元素。

本文档预期读者对象主要为项目经理、产品、开发、测试等。

1.3    参考文档

序号	名称	做者	备注
	详细设计文档
	设计原型

 

1.4    限制条件

本测试计划受限于开发人员提交测试的内容和时间。根据开发人员提交模块的实际状况，本计划会作出相应修改。

2     测试概要

2.1    测试目标

经过测试，达到如下目标：

1. 测试已实现的产品是否达到设计的要求，包括：各个功能点是否以实现，业务流程是否正确。
2. 产品规定的操做和系统运行稳定。
3. Bug数和缺陷率控制在可接收的范围以内，遗留BUG通常不超过全部BUG的10%。

2.2    测试范围

列出测试最终须要交付的功能模块列表

2.3    测试资源

2.3.1   测试人力资源

角色	人员	职责
测试负责人	XXX	测试环境搭建 制定测试计划 制定测试规范 测试用例审核 控制测试进度 与相关部门、人员沟通
测试设计人员	XXX	设计测试用例 准备测试数据
测试执行人员	XXX	按计划执行测试用例 记录执行过程 提出纠正建议措施
缺陷管理人员	全部测试执行人员	记录、报告所发现的缺陷 跟踪缺陷修改过程 回归测试已修复缺陷
测试报告人员	XXX	分析测试结果 编写测试报告

 

2.3.2   测试环境

1. 服务器环境

操做系统：windows          IP:

操做系统：linux              IP:

1. 终端环境

PC：windows10（ie十、chrome、Firefox）、windows7（ie十、chrome、Firefox）

1. 网络环境

公司办公内网、外网

2.3.3   BUG管理工具

在测试过程当中发现的缺陷及可用性问题，使用禅道来进行 bug 管理。

3     测试规范

3.1    测试接收标准

开始/中断测试标准	标准说明
开始测试标准	一、代码编译经过 二、软件能够正确安装运行 三、实现功能与产品设计出入不大 四、冒烟测试经过
中断测试标准	一、安装没法正确完成 二、程序代码编译不经过 三、系统服务异常 四、发现阻塞功能的BUG

 

3.2    BUG规范

测试人员提交缺陷记录时，应清晰、准确地描述缺陷发生的条件和步骤，并

设置缺陷的严重等级以下：

缺陷级别	描述
一级 （致命问题）	1. 程序运行过程当中不断申请，但没有彻底释放资源，形成系统性能愈来愈低，并出现无规律的死机现象。 2. 程序运行致使系统崩溃。 3. 由程序引发的资源严重不足、非法退出等。 4. 严重的关键计算错误（如计费等）。 5. 数据库发生死锁，且没法自动恢复。 6. 与需求要求差距较大。 7. 系统无响应。
二级 （严重问题）	1. 因错误操做致使的程序中断。 2. 功能没有实现。 3. 正确操做致使的错误结果。 4. 与数据库链接错误,没法自动恢复。 5. 数据通信错误，没法自动恢复。 6. 数据库的表、业务规则、缺省值未加完整性等约束条件。 7. 界面中的信息不能及时刷新，不能正确反映当前数据状态，可能误导用户。（数据库中剩余记录个数和参数设置对话框中的预设值经常显示为历史值而不是当前值） 8. 对输入数据没有进行充分而且有效的有效性检查，形成不合要求的数据进入数据库。
三级 （普通问题）	1. 操做界面错误。（包括数据窗口内列名定义、含义是否一致，界面中英文混杂，界面元素良莠不齐，文字显示不全） 2. 打印内容、格式错误。 3. 删除操做未给出提示。 4. 数据库表中有过多的空字段。 5. 提示信息意文不明或为原始的英文提示。 6. 要求用户输入多余的、原本系统能够自动获取的数据。（服务是否启动，安装后用户须要手动修改某些配置文件）。 7. 辅助说明描述不清楚，有歧义。 8. 长操做未给用户提示。
四级 （改进问题）	1. 辅助说明描述不清楚。 2. 输入输出不规范。 3. 可输入区域和只读区域没有明显的区分标志。 4. 某一项功能的冗余操做太多。如：对话框嵌套层次太多，影响用户操做。 5. 不能记忆用户的设置或操做习惯，用户每次进入系统都须要从新操做初始环境。 6. 不符合用户操做习惯。（快捷键定义不科学、不实用，键位分布不合理、按键太多，甚至没有快捷键）。 7. 界面不规范。 8. 提示窗口文字未采用行业术语。

 

4     测试策略

4.1    测试流程及工做量估算

任务	时间	执行人员	预期工做量	备注
编写测试计划		XXX	2
测试计划review及修改		XXX	1
测试环境搭建		XXX	4
测试用例编写		XXX	4
冒烟测试		XXX	2	依据开发提测时间变更
第一轮功能测试		XXX	4	执行测试用例，包括边界值测试、兼容性测试、易用性测试、用户界面测试、安全性测试等
第二轮功能测试		XXX	3	BUG复测及功能验证
回归测试		XXX	1	全面回归测试
性能测试	-			待定，需确认具体性能测试方案和工具
发布测试	-			产品发布方案确认后再规划
测试报告总结		XXX	2	时间待定
备注：因为测试时可能会出现多个测试计划并行测试执行的状况，测试预估时间只做参考。

 

4.2    测试种类

本次测试计划对系统进行如下类型的测试，针对不一样的测试类型分别进行规划和设计，包括测试方法和标准等。测试类型罗列以下：

测试类型	是否采用	说明
功能测试	采用	根据系统需求文档和设计文档，检查系统是否正确实现了功能
边界值测试	采用	选择边界数据进行测试，确保系统功能正常，程序无异常
容错性测试	采用	检查系统的容错能力，错误的数据输入不会对功能和系统产生非正常的影响，程序对错误的输入有正确的提示信息
异常测试	采用	检查系统可否处理异常
易用性测试	采用	检查系统是否易用友好
UI（界面）测试	采用	检查界面是否美观合理，便于操做，符合操做习惯
流程测试	采用	按操做流程进行的测试，主要有业务流程、数据流程、逻辑流程，检查软件在按流程操做时是否可以正确处理
接口测试	采用	检查系统接口可否正常工做
系统测试	采用	系统根据集成方案部署安装到软硬件环境后的运行状况
兼容性测试	采用	对于 C/S 架构的系统来讲，须要考虑客户端支持的系统平台；对于 B/S 架构的系统来讲须要考虑用户端浏览器的版本
稳定性测试	采用	利用工具长时间不断的对系统进行操做
安全性测试	采用	系统应用级别的安全性：检查角色只能访问其所属用户类型已被受权访问的那些功能或数据。
性能测试	采用	提取系统性能数据，检查系统是否知足在需求中所规定达到的性能。
安装卸载测试	采用	检查系统可否正确安装、配置

 

4.2.1    功能测试

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

测试目标	覆盖本次测试范围的全部功能测试
测试范围	测试内容
技术	1.设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略等 2.利用有效的和无效的数据来执行各个用例、用例流或功能，以核实如下内容： （1）在使用有效数据时获得预期的结果。 （2）在使用无效数据时显示相应的错误消息或警告消息。 （3）各业务规则都获得了正确的应用。
开始标准	经过冒烟测试
完成标准	不能遗留一，二级缺陷,三级普通缺陷90%获得修改而且经过复测，四级改进缺陷80%获得修改而且经过复测
测试重点和优先级	重点测试的功能和优先级安排
需考虑的特殊事项	考虑数据库数据存储的正确性； 考虑业务边界值的测试（边界值测试）； 考虑业务异常状况的测试（异常测试）； 考虑业务流程、数据流程、逻辑流程的测试（流程测试）

 

4.2.2   容错性测试

容错性测试主要检查系统的容错能力，检查软件在异常条件下自身是否具备防御性的措施或者某种灾难性恢复手段。

 

测试目标	检查软件容错能力
测试范围
技术	1.输入异常数据或进行异常操做，以检验系统的保护性。若是系统的容错性好，系统只给出提示或内部消化掉，而不会致使系统出错甚至崩溃。 2.灾难恢复性测试。经过各类手段，让软件强制性地发生故障，而后验证系统已保存的用户数据是否丢失，系统和数据是否能尽快恢复。
开始标准	功能测试阶段
完成标准	不能遗留一，二级缺陷,三级普通缺陷90%获得修改而且经过复测，四级改进缺陷80%获得修改而且经过复测
测试重点和优先级	重点考虑各类异常状况，灾难恢复性测试需创建在系统有较好的容灾机制。
需考虑的特殊事项	考虑不按正常流程操做系统； 考虑使用非正常手段访问（例如直接使用内部连接地址访问，直接使用访问协议访问） 考虑数据不符合实际规则（例如数据填写不完整、输入不存在的日期、数字或文本超出设定值、输入空格、上传不符合类型的文件等） 考虑多系统登陆、超时登陆等 如下几点为环境容错测试，即容灾机制需考虑的问题： 在网络出现故障时，是否有其余网络进行自动的切换和链接 在系统断电时，是否有其余的供电系统能进行自动切换 在系统服务器出现问题时，是否有其余的备用服务器能进行自动切换 考虑当多个客户端同时请求系统资源（例如硬盘、内存、CPU等），是否对资源会产生死锁问题，及死锁解决方案

 

4.2.3   易用性测试

易用性测试是指用户使用软件时是否感受方便，好比是否最多点击鼠标三次就能够达到用户的目的。易用性测试应当集中体如今界面美观、功能实用、处理有效几个方面。

测试目标	检查系统是否易用友好
测试范围
技术	通常从导航，图形，内容，总体界面等几个方面入手，主要考虑以下几个方面: (1)易理解性;(2)易学习性;(3)易操做性(4)吸引性;(5)依从性。 具体测试点以下： 1.查询、添加、删除、修改操做相关提示信息的一致性，可理解性 2.输入限制的正确性 3.系统各类提示信息的正确性，可理解性，一致性
开始标准	功能测试阶段
完成标准	不能遗留一，二级缺陷,三级普通缺陷90%获得修改而且经过复测，四级改进缺陷80%获得修改而且经过复测
测试重点和优先级
需考虑的特殊事项	考虑系统被频繁使用的功能支持快捷方式或默认值方式； 考虑2秒钟法则——用户在使用某类系统时的等待反应不该该超过2秒； 考虑3次点击法则——用户在3次点击以内若是尚未找到他们想要的信息或了解产品/网站的特点，他们就会离开； 考虑全部提示信息应该能够帮助用户完成功能使用，而且尽量通俗易懂，言简意赅

 

4.2.4   UI（界面）测试

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

测试目标	测试UI界面的浏览是否能够正确反映业务的功能和需求，是否能与原型图保持一致
测试范围
技术	UI界面测试包括窗口与窗口之间、字段与字段之间的浏览，以及各类访问方法（Tab键、鼠标移动、和快捷键）的使用，窗口的对象和特征（例如，菜单、图标、文字、大小、位置、状态和中心）等
开始标准	功能测试阶段
完成标准	成功地核实出各个窗口都与原型图保持一致，或符合可接受标准
测试重点和优先级
需考虑的特殊事项	考虑直观性、一致性、灵活性、温馨性等

 

4.2.5   接口测试

接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

接口测试也属于功能测试，测试流程是首先根据接口文档编写测试用例（用例编写能够按照功能测试的规则来编写，例如等价类划分，边界值等设计方法），而后执行测试，查看不一样的参数请求，判断接口的返回数据是否达到预期，可能须要转换接口数据格式，常见为json格式，而且需根据需求支持一种或多种接口请求方式（例如GET请求、POST请求等），请求协议为http或https等。

测试目标	保证接口调用的正确性
测试范围
技术	1.使用接口测试工具postman进行接口调用测试， 2.使用jmeter维护自动化接口测试， 3.使用fiddler进行接口请求抓取
开始标准	功能测试阶段
完成标准	不能遗留一，二级缺陷,三级普通缺陷90%获得修改而且经过复测，四级改进缺陷80%获得修改而且经过复测
测试重点和优先级
需考虑的特殊事项	考虑接口参数必填、非必填 考虑业务异常状况 考虑接口参数异常（如参数为null，参数为特殊字符） 考虑接口参数边界值测试 考虑接口返回数据的正确性 考虑接口请求超时的状况 考虑接口请求失败的状况，业务是否可逆，数据是否存储或取消

 

4.2.6   系统测试

系统测试主要目的为检测系统是否达到需求对业务流程及数据流的处理是否符合标准，检测系统对业务流处理是否存在逻辑不严谨及错误，检测需求是否存在不合理的标准及要求。此阶段测试是基于功能测试完成的状况下。

测试目标	检测整个系统业务流程，数据流的正确性
测试范围
技术	利用有效的和无效的数据来执行各个用例、用例流或功能，以核实如下内容： 1.在使用有效数据时获得预期的结果。 2.在使用无效数据时显示相应的错误消息或警告消息。 3.各业务规则都获得了正确的应用。
开始标准	功能测试完成后
完成标准	所计划的测试已所有执行。 所发现的等级高的缺陷已所有解决。
测试重点和优先级	重点测试系统之间交互，数据传送等
需考虑的特殊事项	考虑不一样系统的交互流程是否存在冗余步骤，及可优化点

 

4.2.7   兼容性测试

兼容性测试主要检验被测试软件在特定的硬件平台上、不一样的应用软件之间、不一样的操做系统平台上、不一样的网络等环境中是否可以很友好的运行测试。

 

测试目标	检测程序兼容性
测试范围
技术	1.测试软件是否能在不一样的操做系统平台上兼容，或测试软件是否能在同一操做平台的不一样版本上兼容； 2.软件自己可否向前或向后兼容（考虑版本迭代的状况）； 3.测试软件可否与其余相关的软件兼容； 4.测试软件可否支持不一样浏览器的兼容； 5.测试软件可否支持不一样分辨率的兼容； 6.数据兼容性测试，主要是指数据可否共享等。
开始标准	功能测试阶段
完成标准	不能遗留一，二级缺陷,三级普通缺陷90%获得修改而且经过复测，四级改进缺陷80%获得修改而且经过复测
测试重点和优先级
需考虑的特殊事项	需考虑后期版本迭代，不一样系统不一样版本之间的兼容性

 

4.2.8   性能测试

性能测试是经过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。性能测试是为了验证软件系统是否可以达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，优化软件，最后起到优化系统的目的。性能测试通常包括如下几种类型：

1.基准测试：在给系统施加较低压力时，查看系统的运行情况并记录相关数据作为基础参考。

2.负载测试：是指对系统不断地增长压力或持续一段时间增长必定压力，直到系统的某项或多项性能指标达到安全临界值，例如某种资源已经达到饱和状态等。

3.压力测试：压力测试是评估系统处于或超过预期负载时系统的运行状况，关注系统在峰值负载时或超出最大负载状况下的处理能力。

4.稳定性测试：在给系统加载必定业务压力的状况下，使系统运行一段时间，以此检测系统是否稳定。

5.并发测试：测试多个用户同时访问同一个应用、同一个模块或者数据记录时，是否存在死锁或者其余性能问题。

 

测试目标	检测系统性能，发现性能瓶颈，进行性能调优
测试范围
技术	待肯定详细的性能测试方案
开始标准	测试工做完成后，系统稳定后
完成标准	达到需求要求的性能标准
测试重点和优先级
需考虑的特殊事项	性能测试通常参考指标有响应时间、吞吐量、并发数、资源利用率、事务处理能力（TPS）等。 性能测试通常关注点以下： 1.响应时间快慢，服务器端的处理速度 2.服务器端的使用状况 3.数据库端的资源使用状况 4.最大用户访问数量 5.同时处理最大业务数量 6.考察系统可否支撑7x24小时运转 7.内存资源、线程资源可否正常回收 8.代码，算法，sql语句设计是否合理 9.整个系统的稳定性，可恢复性

 

4.2.9   安装卸载测试

安装卸载测试是为了确保该软件在正常状况和异常状况的不一样条件下（例如，进行首次安装、升级、完整的或自定义的安装，卸载重安装等）都能成功进行安装，异常状况包括磁盘空间不足、缺乏目录建立权限等，核实软件在安装后可当即正常运行，核实软件能够正常进行卸载。

 

测试目标	检查程序包是否能够正常进行安装部署和卸载
测试范围	-
技术	1.软件在不一样操做系统下安装的过程。 2.软件安装后的是否可以正常运行，安装后的文件夹及文件是否写到了指定的目录里。 3. 软件安装过程是否能够取消 4.测试使用系统自带的添加删除（以WIDOWSXP为例）程序卸载的状况 5.测试软件自带的卸载程序 6.测试卸载之后从新安装 7.测试安装和卸载时的提示信息是否合理
开始标准	测试阶段完成，有安装包打包方案后
完成标准	安装成功可以运行系统，卸载成功无残留
测试重点和优先级
需考虑的特殊事项	考虑安装和卸载过程当中出现的意外状况的测试（如死机、断电、重启） 考虑旧版本升级操做

 

5    发布标准

5.1    测试输出文档

本次测试完成后的提交物：

• 测试计划
• 测试用例
• 测试Bug单
• 使用手册
• 测试报告

5.2    测试完成标准

本次测试过程当中，计划测试完成的标准以下：

1. 需求规格说明书中的需求必须所有实现并测试经过。
2. 主流程畅通，系统没有一类和二类Bug（参考3.2 BUG规范），没有影响用户正常使用的BUG。
3. 全部功能和性能测试用例100％执行完成。
4. 剩余三类四类有争议的bug，若是没法达成一致，测试人员需与产品、开发、项目经理开会讨论决定是否遗留有争议的Bug，若最终决定项目上线时有遗留BUG，需将BUG说明附在测试结果报告里，给出缘由或最终解决方案。
5. 测试报告编写完成，测试收尾工做结束。
6. 项目处于试运行或上线阶段。

5.3    产品发布标准

本次测试过程当中，计划产品发布上线的标准以下：

1. 按照交互文档、需求文档彻底的实现需求。
2. 符合交互稿的交互设计规范、符合视觉要求，并已经经过设计评审。
3. 核心代码100％通过代码Review。
4. 容许遗留可能会对用户正常使用形成必定影响的三类、四类缺陷，但应在发布前告知项目组，并经风险评估一致赞成发布后方可发布。

6     测试风险

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

1. 开发提交测试版本比该计划延迟，发生此种状况时，执行测试的时间应该合理顺延；
2. 若是测试计划执行过程当中出现需求变动超出预计的状况，可能致使编写测试用例和执行测试相关工做量增长，测试进度延迟；
3. 若是开发提测版本质量较低，bug较多，可能致使比该计划更多轮次的回归测试；
4. 人员调整、人员经验以及对软件的熟悉度可能会影响测试计划；
5. 测试需依赖于服务器环境，若是环境不稳定，如代码编译不经过，tomcat异常、jar包异常、数据库异常等状况，可能会影响测试进度。