如何编写测试计划？

 

编写测试计划目录

1 概述

1.1 文档目的

1.2 文档读者

1.3 文档范围

2 用户需求概述

3 系统功能需求

4 参考资料

5 条件与限制

6 测试方案

6.1 测试环境

6.1.1 PC测试

6.2 测试类型

6.2.1 测试需求列表

6.2.2 功能测试

6.2.3 性能测试

6.2.4 易用性测试

6.2.5 安全性测试

6.2.6 兼容性测试

6.2.7 可移植性测试

6.3 测试策略

6.3.1 基本功能测试

6.3.2 用户界面及易用性测试

7 测试计划

7.1 测试资源

7.2 测试进度安排

7.3 测试准备工作

7.4 风险评估

7.5 系统测试进入准则

7.6 系统测试退出准则

 具体情况如下： 

1 概述

在整个系统测试阶段,相关的系统测试工作的开展需要进行各方面的明确,在系统测试计划中主要是针对系统测试阶段各个不同岗位所担负的相关职责,防范由于职责不清所造成的系统测试工作的混乱现象.明确定义相关的系统测试范围,防止由于测试分工而造成的遗测.在该计划中一定要对系统测试过程中可能出现的各种风险进行预防和规避.

1.1 文档目的

本文档主要阐述xxx统测试计划。

xxxxx对今后软件开发人员概要设计、详细设计和编码有着重要的指导作用。

1.2 文档读者

测试人员、研发人员、项目管理人员。

1.3 文档范围

所属产品	所属模块	需求名称
Xxxxx

2 用户需求概述

xxxxxxxxxxx

3 系统功能需求

xxxxxxxxxx

4 参考资料

参照文档《xxxxx-需求规格说明书》

5 条件与限制

测试限制条件主要存在于大屏测试和三方工具调用：

1. 测试工具：需要使用Jmeter在PC上模拟在线用户数量峰值和正常值。（视项目情况是否需要性能测试）
2. 测试人员时间：由于测试人员时间有限，无法全覆盖所有的条件组合，只对测试用例全覆盖进行测试。
3. 三方工具调用：多部门、多公司联合开发，联调、配合时间存在一定的风险性。

6 测试方案

6.1 测试环境

6.1.1 PC测试

浏览器

 

浏览器	备注
Google	全功能测试
FireFox	兼容性测试
360	兼容性测试
IE 11及以上	兼容性测试
Opera	兼容性测试

6.2 测试类型

6.2.1 测试需求列表

                                测试需求列表（2019/xx/xxxx)

所属产品	所属模块	需求名称	测试类型
xxx

6.2.2 功能测试

测试对象：测试需求列表（见禅道需求点）里所有标注“功能测试”的需求，需进行全面功能测试。

测试标准及要点：按照测试用例执行。

测试用例：在执行前需进行内部评审，并用禅道工具进行执行状况跟踪。

6.2.3 性能测试

PS:视情况是否需要性能测试

测试对象：测试需求列表（见禅道需求点）里所有标注“性能测试”的需求

测试工具：Jmeter，在PC上对系统进行施压

测试时间：所有功能的性能测试需在相应功能模块完成并通过功能测试后再执行

测试场景

分类	用户量	指标	优先级	备注
事务处理类	300 （非高峰期）	前端系统访问响应时间≤5秒	中	前端系统指标测试需结合Jmeter的报告   后端CPU利用率可使用Jmeter插件在服务器安装，Jmeter自动监控；若不允许装插件，则使用人工监控记录
查询类	300  （非高峰期）	前端系统访问响应时间≤2秒 后端CPU利用率<=50% 后端内存利用率<=50%	高
	1000 （高峰期）	系统访问响应时间≤10秒 后端CPU利用率<=70% 后端内存利用率<=70%	高
	3000 （极限）	系统未崩溃 请求未返回大量错误	低
统计类	简单统计类	系统响应时间≤10秒	中	手动启动业务全过程跟踪
	复杂统计类	系统响应时间≤30秒	中	手动启动运行月报

6.2.4 易用性测试

测试对象：测试需求列表（见禅道需求点）里所有标注“易用性”测试的需求。

测试内容：

1. 应用系统提供一致性的中文图形用户界面、颜色统一、协调、美观。字体应统一大小。
2. 应用系统对普通用户的操作界面应该以B/S方式实现。
3. 应用系统必须支持同时打开多个管理窗口以对不同任务进行并行的操作。
4. 应用系统应该支持通过Tab键或回车键可以访问到同一个窗口的所有空间对象。
5. 查询时，若为日期条件、数值条件支持范围查询。
6. 查询时，若为字符型条件支持模糊查询。
7. 系统必须采用分页机制显示查询结果，并显示返回的记录数目、当前页和总页数。
8. 应用系统的查询统计结果可以转存为EXECL等常见格式文件。
9. 应用系统发现用户提交有误信息，必须以弹出窗口的形式明确提示用户错误的原因，并把界面控制焦点置于发生错误的控件对象上。
10. 应用系统的操作界面必须明确标识出必填的输入信息。
11. 在导致系统数据发生变化的操作执行之前，系统应该弹出提示窗口供用户确认。
12. 对于复杂的信息结构，系统应该采用分栏的机制在同一个窗口中显示不同的信息内容，并自动刷新不同部分的信息内容。
13. 当应用系统正在执行用户提交的请求而无法返回时，必须明确标识系统处于繁忙阶段。
14. 应用系统功能菜单必须按照功能域、功能项的分类方法进行组织。
15. 对于操作员无权限使用的菜单功能，应用系统不显示该菜单或将其设置为不可用状态。
16. 系统必须提供在线帮助功能，对于每一个操作功能都能查找到相应的详细使用说明。
17. 操作员登录系统后，系统必须能够主动地提醒等待该操作员处理的任务。
18. 应用系统提供FAQ功能，支持常见问题的管理、发布等。
19. 应用系统提供问题管理功能，支持常见问题的收集、反馈等。
20. 经常性的面向基层的具体岗位的业务处理界面必须简洁、实用、直观，数据信息分层显示，常用的排前，不常用的靠后或消隐。
21. 操作键序符合工作处理步骤，能自动跳转，以提高日常业务处理效率。

6.2.5 安全性测试

测试对象：测试需求列表（见禅道需求点）里所有标注“安全性”测试的需求。

测试内容：

1. 登录/注销：对用户进行身份识别和鉴别；登录失败后，采取结束会话、限制非法登录次数和当网络登录连接超时自动退出等措施；登录时采用加密技术
2. 执行“删除”、“退出”等有风险操作时，应有“确认”、“放弃”提示对话框。
3. 身份鉴别信息具有不易被冒用的特点，口令有复杂度要求，如口令长度至少八位以上，同时包含字母、数字、特殊字符等，并定期更换口令。
4. 系统应该对用户在客户端输入或导入的数据进行长度、范围、数据类型等属性的合法性进行检验，对不合法的数据应该禁止输入系统，并且提示明确的错误信息。
5. 系统应该在服务器端对将要存储到后台数据库中的数据进行合法性检验，对不合法的数据应该舍弃，并报警。
6. 系统应该能够允许多用户同时对同一个系统资源进行不相冲突的访问操作，并且设定保护措施，防止相互可能造成的冲突。
7. 系统应该禁止客户端用户执行相互矛盾的操作，例如两个用户同时修改一个资源。

6.2.6 兼容性测试

测试对象：测试需求列表（见禅道需求点）里所有标注“兼容性”测试的需求，参考如下。

测试内容：

1. 浏览器兼容测试：测试程序在不同浏览器上是否可以正常运行，功能能否正常使用；
2. 屏幕尺寸和分辨率兼容测试：测试程序在不同分辨率下能否正常显示；
3. 操作系统兼容测试：测试程序在不同的操作系统下面能否正常运行，功能能否正常使用，显示是否正确等；
4. 不同设备型号兼容测试：针对于APP，现在移动设备型号五花八门，主要测试APP在主流设备上能否正常运行，会不会出现崩溃的现象。

6.2.7 可移植性测试

测试对象：测试需求列表（见禅道需求点）里所有标注“可移植性”测试的需求，参考如下。

测试内容：

1. 可安装性测试：使用安装向导或遵照安装手册的步骤（包括执行必需的安装脚本），功能是否可以成功地进行软件安装。
2. 共存性/兼容性测试：不存在相互依赖关系的计算机系统可以在同一环境（例如：同一个硬件平台）中运行，而不影响彼此的行为（如资源冲突）
3. 适应性测试：测试一个应用程序是否能够在所有特定的目标环境（硬件、软件、中间件、操作系统等）中正确地运行。
4. 可替换性测试：在集成过程中会有一些可替换的组件集成构成一个完整的系统。

6.3 测试策略

6.3.1 基本功能测试

对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术。

表6-1 功能测试策略

测试目标	确保测试的功能正常，其中包括导航，数据输入，处理和检索等功能。
测试范围	需求中明确的功能项。
技术	利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容： 1.在使用有效数据时得到预期的结果。 2.在使用无效数据时显示相应的错误消息或警告消息。 3.各业务规则都得到了正确的应用。
开始标准	所有功能均已完成，并已提交测试。
完成标准	所计划的测试已全部执行。所发现的缺陷已全部解决。
需考虑的特殊事项	无

6.3.2 用户界面及易用性测试

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

表6-2 用户界面测试策略

测试目标	1.通过测试进行的浏览可正确反映业务的功能和需求，包括窗口与窗口之间、字段与字段之间的浏览，以及各种访问方法（Tab键、鼠标移动、和快捷键）的使用； 2.窗口的对象和特征（例如，菜单、大小、位置、状态和中心）都符合标准。
测试范围	系统业务应用模块的所有子系统。
技术	为每个窗口创建或修改测试，以核实各个应用程序窗口和对象都可正确地进行浏览，并处于正常的对象状态。
开始标准	所有项目功能均可正常进行。
完成标准	成功地核实出各个窗口都与基准版本保持一致，或符合可接受标准。
需考虑的特殊事项

 

7 测试计划

7.1 测试资源

                                     测试人员表

姓名	角色	角色描述	具体职责
xxxx	测试主任	研发测试质量管理	协调沟通任务、评审测试用例、制定测试计划、辅助测试
xxxx	测试人员	研发测试	制定测试计划、编写测试报告、编写测试用例、执行测试、编写用户操作手册

7.2 测试进度安排

                        测试任务安排（第一期 – 预发布时间2019/9/10）

任务标号	任务名称	工期（天）	开始时间	结束时间	人员
1	测试准备	4	2019/8/27	2019/8/30	xxxx
2	执行数据测试	5	2019/9/2	2019/9/6	xxxx
3	执行功能测试	2	2019/9/5	2019/9/6	xxxx
4	执行验收测试	2	2019/9/9	2019/9/10	xxxx
5	编写系统测试报告	3	2019/9/11	2019/9/13	xxxx
6	编写操作手册	3	2019/9/12	2019/9/14	xxxx

具体任务安排请参考禅道需求点

***禅道需求点***

7.3 测试准备工作

                             测试准备工作

测试类型	测试准备内容	负责人	截止日期
所有	修订测试计划	xxxx	xxxx
功能测试 易用性测试	编写测试用例	xxxx	xxxx
	测试环境搭建	xxxx	xxxx
	评审测试用例	xxxx	xxxx
兼容性测试 可移植性测试	软件资源（浏览器）	xxxx	xxxx
性能测试	选定性能测试场景、测试工具 制定性能测试步骤	xxxx	xxxx
验收测试	验收测试场景、用例	xxxx	xxxx

7.4 风险评估                              

风险评估

风险分析	预防措施	责任人
测试开始时间受制于开发进度，若开始时间较晚，可能无法在预定的交付时间完成所有测试	随时跟踪开发进度调整测试时间计划，若发现测试开始时间较已设定时间延迟时间太长，与项目经理沟通，在进度、范围、质量之间进行平衡。	xxxxx
测试周期时间可能会受开发质量影响，如bug太多则会延长测试时长	与相应团队成员分析质量原因 与项目管理团队沟通是否在进度、范围、质量之间进行平衡	xxxxx
硬件性能的风险	本系统涉及到后端大量数据的比对及清洗，对系统硬件本身的运算能力、存储等有较高要求。如果硬件性能无法得到保障，将导致数据清洗时间过长、系统运行缓慢，影响较大。
网络环境的风险	本系统是部署在电子政务外网及互联网两个网络之中，并且大部分功能都需要进行数据查询及网络通信，因此网络环境决定了查询及应用速度的快慢，如果不能保证良好的网络环境，将对系统造成一定影响
第三方软件部署的风险	本系统所采购第三方软件均是严格对应标书的技术标准，并且系统部署时，所有的软件提供商均会现场进行部署和支撑，因此该风险较小。
开发技术的风险	系统前端使用技术：ES6/React，Webpack,Node.js，Canvas。前端风险可能主要在使用了大量HTML5技术，对老旧浏览器的兼容性支持不好。推荐使用IE10+或Chrome、Firefox浏览器，并且会在系统提供相应浏览器下载。后端使用技术：Java8, Spring Boot 1.4。后端使用了成熟的Java EE技术，采用了Spring技术栈。

7.5 系统测试进入准则

                                    系统测试进入准则

标准名称	标准说明	风险
测试用例	测试用例通过测试内部评审、以及其他项目团队成员同意（如项目经理）	说明：每个功能测试的测试用例编写测试要点、测试步骤、预期结果、实际结果。因此测试时，不同测试人员的操作具有一定的局限性，对用例可能会有不同的理解。 控制：测试人员在测试前都参与用例的评审，熟悉每个测试用例的测试要点，及设计目的，以保证用例规定的所有要点都被覆盖。
需求	需求需要测试人员、开发人员评审通过，并上传至禅道	说明：需求理解的不同，测试人员、开发人员在编写用例、编写代码存在一定的误差。 控制：在每次编写用例、代码前，与需求人员对需求进行评审，达成一致在进行执行操作。
概要/详细设计	概要/详细设计需要项目人员、测试人员评审通过，并上传至禅道
功能	功能开发完成	说明：开发人员提交功能至测试环境。 控制：在禅道上创建测试版本，开发人员提交版本说明，包括该版本中新增加的功能特性、修改的缺陷、可能存在的问题以及测试重点的建议等
冒烟测试	开发单元测试完成 系统冒烟测试通过
性能测试	性能测试场景方案制定完成，并且通过测试内部评审、项目经理同意	说明：对系统非高峰期和高峰期的用户数量并未明确说明 控制：与项目经理进行确认、可以多测几组数据，如1000、2000、3000

7.6 系统测试退出准则

                                   系统测试退出准则

标准名称	标准说明	风险控制说明
最低标准	测试用例：覆盖率100%，通过率90% 遗留bug： 不存在严重程度为“1”和“2”的bug 严重程度为“3”的bug数量≤15	将未通过的测试用例导出与项目经理分析并确认是否可接受 在阶段结束之前，与项目经理和其他项目团队成员确认需在交付前解决的bug 清单
合理标准	测试用例：覆盖率100%，通过率95% 遗留bug： 不存在严重程度为“1”和“2”的bug 严重程度为“3”的bug数量≤10
较高标准	测试用例：覆盖率100%，通过率98% 遗留bug：无

Bug等级说明：

严重程度为1（致命）：系统崩溃、中断、死机、数据丢失、安全问题、主要功能未实现、严重错误且没有应急解决方案、系统性能严重低于最低要求

严重程度为2（严重）：数据错误、程序逻辑错误

严重程度为3（一般）：功能小错误且有应急解决方案

严重程度为4（轻微）：人机交互或界面优化建议、提示语等拼写小错误，不影响用户正常使用。