测试计划模板Word下载.docx

测试计划模板Word下载.docx

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

确定测试范围,包括测试对象中将接受测试或将不接受测试的那些性能和功能。

推荐可采用的测试策略，并对这些策略加以说明。

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

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

1.2测试范围

测试的各个阶段：

测试设计：

根据T0305样品软件需求规格说明书，制定测试计划、测试方案，包括收集测试方法，设计测试用例，可能用到的测试工具等。

系统测试：

前期依据需求规格说明书进行基本的功能测试、界面测试、兼容性测试。

1.3读者对象

项目经理、测试经理、测试人员

1.4术语与缩略语

1.5功能模块划分

T0350样品软件有4个基本模块：

软件安装、班级学生成绩管理、年级学生成绩查询、参数设置与数据库操作。

如下图所示：

模块对应的功能细化如下：

模块

功能

安装模块

1.自动向导安装

2.可自由选择安装路径

班级学生成绩管理模块

1.增加学生信息；

2.删除学生信息；

3.清空班级学生信息；

4.修改学生成绩信息；

5.显示学生成绩；

6.成绩查询；

7.学生信息排序；

年级学生成绩查询

1.成绩显示；

2.成绩查询；

3.学生信息更新；

参数设置与数据库操作模块

1.参数设置；

2.导入样品数据；

2测试资源

参考需求：

为真实模拟测试环境，需要测试各种软硬件能否正常工作

2.1人力资源

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

角色

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

具体职责或注释

测试经理

进行管理监督。

职责：

提供技术指导

获取适当的资源

生成测试计划，测试方案

管理测试数据

收集测试用例

参与测试

测试员

张耀、孙林霞、孙巧玲

执行测试。

执行测试

记录结果

从错误中恢复（返测报告）

测试系统管理员

确保测试环境和资产得到有效的管理和维护。

管理测试系统

授予和管理角色对测试系统的访问权限

2.2测试环境

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

操作系统：

Win7

相关软件：

T0305能力验证品V1.2

硬件环境（设备等）

显示器分辨率为800×

600以上

硬盘：

500G

CPU：

Itel（R）Core（TM）2QuadRAM:

2.0G

2.3测试工具

3测试参考文档和测试提交文档

3.1测试参考文档

T0305样品软件需求规格说明书

3.2测试提交文档

（1）测试计划；

（2）测试需求；

（3）测试用例；

（4）测试日志；

（5）缺陷报告；

（6）测试报告；

4测试进度

4.1各测试阶段资源要求及时间安排

注：

在制定完测试方案以后，公司将有一个为期19天的年假。

人员

设备

时间安排

测试计划

普通用机1台

2013-01-26至2013-01-26

测试需求

普通用机3台

2013-01-27至2012-01-28

测试用例

2013-01-29至2013-01-30

功能测试

测试用机3台

2013-02-19至2013-02-26

4.2项目里程碑

里程碑任务

工作量

开始日期

结束日期

制订测试计划

1人天

制订测试需求

3*2人天

2013-01-27

2012-01-28

制订测试用例

2013-01-29

2013-01-30

3*7人天

2013-02-19

2013-02-26

4.3人员模块划分

具体负责模块

安装模块，班级学生成绩管理模块

测试工程师

孙林霞

班级学生成绩管理模块，年级学生成绩模块

孙巧玲

年级学生成绩模块，参数设置与数据库导入

5系统风险、优先级

1.人员风险

测试人员需要时间适应需要测试的软件，测试工具和测试环境。

2.计划编制风险

不能做到计划的全面设计。

3.无开发人员参与

无法与开发人员进行项目的讨论，对理解项目不利。

遇到缺陷也无法及时修复。

4.时间风险

一人身兼多职，时间上也许不够。

6测试策略

学生成绩管理系统软件测试将进行功能测试、界面测试、兼容性测试。

6.1功能确认测试

●概述：

包括学生信息的增、删、改、查和数据库测试。

●目标：

确保输入的条件是否符合数据字典的规定

方法：

·

集成测试阶段主要针对大的功能实现进行测试，系统测试阶段依据需求规格说明书逐项测试，验收测试阶段依据说明书逐项测试。

重要的功能应该投入更多的精力进行测试，并及时小结。

完成标准：

功能实现，且可以正确执行。

所发现的缺陷尽量解决，留下的问题已经进行相应的处理或提供其他的解决方法。

需考虑的特殊事项：

注意开发组可能的功能变化和需求变更。

注意其中一些重要功能是与实际效果相关，并不是简单的功能实现。

注意值域测试的提示信息。

6.2用户界面测试

用于核实用户与软件之间的交互是否正常

核实下列内容

确保窗口对象及其特征（菜单、大小、位置、状态和中心）都符合标准等

参考表格如下：

检查项

测试人员的类别及其评价

窗口切换、移动、改变大小时正常吗？

各种界面元素的文字正确吗？

（如标题、提示等）

各种界面元素的状态正确吗？

（如有效、无效、选中等状态）

各种界面元素支持键盘操作吗？

各种界面元素支持鼠标操作吗？

对话框中的缺省焦点正确吗？

数据项能正确回显吗？

对于常用的功能，用户能否不必阅读手册就能使用？

执行有风险的操作时，有“确认”、“放弃”等提示吗？

操作顺序合理吗？

按钮排列合理吗？

导航帮助明确吗？

提示信息规范吗？

6.3易用性测试

测试目标：

支撑常用的快捷方式，易掌握使用

跟功能确认同步进行，验证其快捷方式

支撑常用快捷方式，易掌握使用

1.导航栏中对应的显示

2.不常用快捷方式的支撑

6.4业务测试

系统提供的业务流程与需求或用户手册相符。

逐一对系统中的业务流程按照需求规定的业务流程走一遍。

完成业务流程后的结果要与需求上的业务相对应，并且没有错误

注意每个业务是否完成了一遍

注意每个业务的流程走法

6.5兼容性测试

在不同的软硬件环境下软件能正常运行

把软件放在不同的软硬件环境下运行，看是否能正常运行，环境尽量复杂一点

证实软件在不同的软硬件环境下能兼容运行不出错误

注意软硬件环境的不同

注意环境的复杂度

7问题严重度描述

Bug严重程度编号

严重状态

严重程度说明

1

紧急缺陷（Urgent）：

⏹系统崩溃：

如服务吊死、死机、资源耗尽、程序不可预期地退出等；

⏹数据丢失：

如用户输入的数据不能保存，系统原有的数据丢失；

⏹数据不一致：

如操作后造成系统存储的相关数据之间的逻辑关系或约束关系遭到破坏；

⏹测试员认为可能严重影响后续工作的其他缺陷；

2

严重缺陷（High）

⏹可回避的紧急缺陷：

有确定方法可以避开的系统崩溃、数据不能保存或数据丢失与不一致；

⏹主要功能有缺陷：

优先级高的功能或需要频繁使用的功能严重不满足需求；

⏹主要性能指标严重不达标：

如系统主要功能的响应时间超过需求规格中规定的100％以上或常用功能的响应时间大大超过常人能人忍受的范围；

⏹严重的安全漏洞：

系统存在严重的安全漏洞，可能导致系统在非授权的情况下被非法访问；

⏹测试员认为可能影响后续工作的其他缺陷；

3

中等缺陷（Medium）

⏹非主要功能有缺陷：

系统中非主要功能不满足需求；

⏹非主要性能指标不达标：

主要的性能指标轻微超标，或次要的性能指标超标；

⏹数据显示错误：

系统显示的数据与真实数据不一致，或相关数据之间的逻辑关系不正确；

⏹其它非功能需求不达标：

包括软件的易用性、健壮性、可靠性、兼容性、可移植性、安全性、可扩展形、可维护性等方面的特性不满足需求；

⏹测试员认为值得修复的其它缺陷；

4

轻微缺陷（Low）

⏹用户界面不美观或风格不一致；

⏹大多数用户不会在意的缺陷：

如错别字等；

⏹建议性意见

8附录：

8.1项目任务

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

✧　　制定测试计划

⏹确定测试需求

⏹评估风险

⏹制定测试策略

⏹确定测试资源

⏹创建时间表

⏹生成测试计划

✧设计测试

⏹准备工作量分析文档

⏹确定并说明测试用例

⏹确定测试过程，并建立测试过程的结构

✧复审和评估测试覆盖

✧实施测试

⏹记录或通过编程创建测试脚本

⏹确定设计与实施模型中的测试专用功能

⏹建立外部数据集

✧执行测试

✧执行测试过程

✧评估测试的执行情况

✧恢复暂停的测试

✧核实结果

✧调查意外结果

✧记录缺陷

✧对测试进行评估

✧评估测试用例覆盖

✧评估代码覆盖

✧分析缺陷

✧确定是否达到了测试完成标准与成功标准

8.2本计划审批意见

项目经理审批意见：

签字：

日期：