测试方案和测试计划书.docx

测试方案和测试计划书.docx

《测试方案和测试计划书.docx》由会员分享，可在线阅读，更多相关《测试方案和测试计划书.docx（14页珍藏版）》请在冰点文库上搜索。

测试方案和测试计划书

XX二期测试方案与计划

修订历史记录

版本　　　　　　　

日期　　　　　　

AMD　　　　　　

修订者　　　　　

说明　　　　　

1.0

2020-03-17

A

创建文档

（A-添加，M-修改，D-删除）

1.简介

1.1目的

测试工程师需要基于产品功能需求和测试方案来设计和执行测试用例。

测试方案是从测试的角度去分析或者说分解需求，在方向上明确要怎么测，分析结果就是测试点和测试方法。

1.2层次

从技术的角度对一次测试活动进行规划工具的设计、测试用例的设计、测试数据的设计。

它是描述需要测试的特性、测试的方法、测试环境的规划、测试工具的设计和选择、测试用例的设计方法、测试代码的设计方案。

1.3主要内容

1、测试策略选取，明确策略；测试策略就是如何用最少的资源满足测试质量的要求，既高效、低成本、较高质量的完成测试。

2、测试子项细分，细化测试特性形成测试子项；将测试计划中描述的方法进行细化，包括要采用的具体测试技术。

3、测试用例的规划；

4、测试环境的规划；

5、自动化测试框架的设计；

6、测试工具的设计和选择；

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

2.1测试参考文档

下表列出了制定测试计划时所使用的文档，并标明了各文档的可用性：

文档

（版本/日期）

已创建或可用

已被接收或已经过复审

作者或来源

备注

XXX软件功能清单-第二期

是

XXX二期工作计划

是

2.2测试提交文档

下表列出了在测试阶段结束后所有可提交的文档：

文档

文档提交时间

备注

测试计划书

2020.3.20

测试用例文档

随需求变动随时更新

缺陷列表

管理

Bug分布图

测试报告

正式版发布之前

发布时同时提供

3.测试进度

测试活动

计划开始日期

实际开始日期

结束日期

制定测试计划

2020.3.17

2020.3.17

2020.3.20

编写测试用例

2020.3.19

2020.3.19

实时根据需求更新

测试环境/数据准备

2020.3.23

2020.3.20

功能模块测试

2020.3.20

2020.3.20

集成测试

2020.3.23

回归测试

2020.3.30

4.测试资源

4.1人力资源

下表列出了在此项目的人员配备方面所作的各种假定：

测试人员

角色

具体职责或注释

XXX

测试工程师

智轨通APP安卓IOS测试设计及用例的编写，执行测试，报告软件缺陷，测试报告

XXX

测试工程师

卡管系统、票务系统、运营管理系统、APP管理系统、业务前置系统测试设计及用例的编写，执行测试，报告软件缺陷，测试报告

XXX

测试工程师

闸机、应急终端、手持pos终端的测试设计及用例的编写，执行测试，报告软件缺陷，测试报告

XXX

性能测试工程师

测试计划，测试设计，执行测试，报告软件缺陷，测试报告

4.2测试环境

下表列出了测试的系统环境：

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

安卓

Ios

谷歌浏览器

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

车载终端

手持pos终端

闸机

TVM

人脸设备

4.3测试工具

下表列出了测试的工具：

用途

名称

测试用例管理

禅道

数据库

NavicatforMySQL

抓包工具

Charles

压力测试

Jmeter

5.系统风险、优先级

下表列出项目可能的风险：

风险类型

优先级

解决办法

阶段开发任务延期使得集成测试和回归测试时间缩短

高

必须为项目测试保留足够的时间。

需求分析不明确

中

及时发现问题，第一时间与客户沟通。

现场环境与测试环境不一致

高

现场配合测试

6.测试策略

本次测试整体策略为黑盒功能测试，具体测试策略包括功能模块测试、用户界面测试、安全性和访问控制测试、真实负载测试、安装测试、集成测试、兼容性测试和回归测试。

6.1功能模块测试

测试目标：

测试各功能模块功能满足需求。

测试范围：

方法：

针对各个功能点使用有效数据时得到预期的结果。

针对各个功能点在使用无效数据时显示相应的错误或警告消息。

各业务规则和计算逻辑都得到了正确的执行。

完成标准：

所计划的测试点和测试用例已全部执行。

所发现的缺陷和bug已全部记录下来

需考虑的特殊事项：

各计算逻辑需重点测试。

6.2用户界面测试

测试目标：

核实以下内容：

界面风格是否符合要求，且风格一致。

界面实现是否符合项目约定，是否满足易用性要求。

·界面控件功能正确，外观应感觉舒服。

方法：

点击与使用每个功能，观察其是否处理正常工作状态；检查界面风格和易操作性

完成标准：

证实各个页面都符合要求。

需考虑的特殊事项：

界面风格按照客户的要求进行测试。

6.3安全性和访问控制测试

测试目标：

核实以下内容

∙系统安全性

∙不同用户的操作权限

方法：

∙用正常用户和非法用户登录系统是否正常

∙给用户设置不同的权限，结果是否正确

∙使用不同权限用户登录系统可访问相应的功能

∙禁用（disabled）的用户不能登录

完成标准：

∙各种已知的角色类型都可访问相应的功能而且都按照预期的方式运行。

需考虑的特殊事项：

在同一台测试机器上测试不同用户登录，留意cache以及session对切换用户登录的影响。

测试session过期后系统的处理。

6.4真实负载测试

测试目标：

测试系统部分功能在真实负载情况下的响应情况

方法：

∙通过导入功能将客户提供的数据导入到系统。

∙在需要的数据量达到真实负载情况下，运行相关功能。

完成标准：

在真实负载情况下，相应功能应不受影响，相应速度应满足要求。

需考虑的特殊事项：

6.5安装测试

测试目标：

测试根据系统部署说明书能将软件系统部署成功

方法：

根据系统部署说明书部署系统

完成标准：

软件部署成功，部署后系统能够正常使用。

需考虑的特殊事项：

考虑软件系统规定的硬件配置

6.6集成测试

测试目标：

检测需求中业务流程，数据流的正确性；需求中明确的业务流程，或组合不同功能模块而形成一个大的功能。

方法：

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

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

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

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

各种可能的业务流程符合预期的结果。

完成标准：

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

所发现的缺陷已全部解决。

需考虑的特殊事项：

各功能模块间的衔接以及数据传递

6.7兼容性测试

测试目标：

核实在以下软件环境下，软件能工作正常：

谷歌浏览器、安卓主流手机、苹果手机

方法：

谷歌浏览器、安卓主流手机、苹果手机

完成标准：

软件正常工作，没有Medium级别及以上的缺陷，或者发现的错误被修改。

需考虑的特殊事项：

6.8回归测试

测试目标：

在程序有修改情况下保证原有整个软件系统功能正常。

方法：

重点测试Bug修改，bug修改关联模块，新增功能，重点模块，时间允许的情况下测试全部用例。

完成标准：

软件系统功能正常，没有Medium级别及以上的缺陷。

需考虑的特殊事项：

如果系统在回归测试期间发现Medium级别及以上的缺陷，需要重新构建候选版本，并在新的候选版本上重新回归，直到系统稳定运行。

7关注点

7.1文本输入框

（1）检查空数据；

（2）检查过长数据（超出空间本身的长度和数据库中改字段所允许的长度）；

（3）检查特殊字符，尤其是数据库中不允许的字符，甚至回车字符、空格字符等；

（4）检查字符类型，比如应该输入数字的文本框输入英文字符；

（5）中文字符的处理；

（6）对于日期时间型数据，检查格式正确性以及时间日期的合理性。

比如开始时间不能晚于结束时间等；

7.2下拉列表

（1）列表数据是否正确、完整；

（2）下拉列表与其他空间的联动关系；

（3）是否允许多选；

7.3增加数据

（1）数据个数的上限；

（2）重复数据处理，尤其是键值的重复；

（3）相关表格的更新；

（4）检查多次使用back键的情况，在有back的地方，back回到原页面，再back重复多次，看是否会出错；

7.4修改数据

（1）不能破坏数据库数据的关联和完整；

（2）重复数据处理，尤其是键值的重复；

（3）修改登录用户本身信息时对系统的影响；

（4）修改正在使用的数据；

（5）检查多次使用back键的情况，在有back的地方，back，回到原页面，再back，重复多次，看是否会出错。

7.5删除数据

（1）不能破坏数据库数据的关联和完整；

（2）删除正在使用的数据；

（3）删除登录用户本身；

7.6查询数据

（1）多条件组合查询的正确性；

（2）多次连续查询正确性；

7.7数据导入导出

（1）导入数据格式要求不应太严格，提示明确；

（2）导出数据不应乱码；

7.8数据接入与处理

（1）数据接入方式是否全部可用，数据是否能正确接入；

（2）数据处理方式是否全部可行；

（3）数据的动态监测是否正确无误；

7.9其他

（1）对网络故障的提示；

（2）同一用户多次登录；

（3）内存使用情况；

（4）压力测试，系统承受能力，多用户同时登录使用。

8.缺陷管理流程

9.问题严重度描述

问题严重度

描述

响应时间

严重

即系统无法执行、崩溃或资源严重不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。

例如：

系统崩溃，系统很多功能不能正常工作

1天

重要

即影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。

例如：

某一功能不能正常工作

2天

一般

即界面、性能缺陷、兼容性。

例如：

数据输入验证错误，一般的功能性缺陷

3天

轻微

即易用性及建议性问题。

例如：

页面字体不一致，标签文字错误

3天以上

10.通过测试的标准

一般有“基于测试用例”和“基于缺陷密度”两种评比准则，在这里我们采用前者。

 准则如下：

Ø功能性测试用例通过率达到100％； Ø

Ø非功能性测试用例通过率达到95％； Ø 

Ø沒有高于优先级3以上的问题。

备选通过办法：

   根据实际情况由软件开发部门的经理、项目经理和测试负责人等共同讨论确定本阶段是否结束。

11.附录：

测试任务

以下是一些与测试有关的任务：

✧　　制定测试计划

⏹确定测试需求

⏹评估风险

⏹制定测试策略

⏹确定测试资源

⏹创建时间表

⏹生成测试计划

✧编写测试用例

⏹定义测试数据

⏹编写测试用例

⏹确定测试过程

✧实施测试

⏹模块功能测试

⏹集成测试

⏹回归测试（根据测试发现的问题安排多次回归测试）

✧记录缺陷

✧验证已修改的缺陷

✧测试报告，提交Bug分布图和缺陷列表