系统测试计划.docx
《系统测试计划.docx》由会员分享,可在线阅读,更多相关《系统测试计划.docx(10页珍藏版)》请在冰豆网上搜索。
系统测试计划
×××版本产品或×××项目
系统测试计划
文件标识
版本号
编制人
编制日期
审核人
审核日期
批准人
批准日期
XXX公司
版本历史
版本/状态
作者
参与者
起止日期
修订说明
批准人
A/发布
1简介
1.1文档目的
编写本文档的目的是什么
1.2读者对象
例如:
开发人员、测试人员、项目负责人、
1.3参考文献
《需求规格说明书V1.1》或
《用户需求说明书V1.1》
《产品计划V1.1》或《项目开发计划》
1.4职责权限
角色
人员
测试经理
测试工程师
1.5测试内容
序号
模块名称
预计(执行测试)工作量
单位:
人日
1.
2.
3.
4.
5.
6.
1.6测试范围
执行测试工作的具体范围。
2测试方法和目标
2.1测试方法
主要进行哪几类测试。
2.1.1功能测试
对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。
这种测试的目标是核实数据的接收、处理和检索是否正确,以及业务规则的实施是否恰当。
此类测试基于黑盒技术,该技术通过图形用户界面(GUI)与应用程序进行交互,并对交互的输出或结果进行分析,以此来核实应用程序及其内部进程。
以下为各种应用程序列出了推荐使用的测试概要:
测试目标:
确保测试的功能正常,流程正常流转。
测试范围:
×××
技术:
利用有效的和无效的数据来执行各个用例、功能或流程,以核实以下内容:
1)在使用有效数据时得到预期的结果;
2)在使用无效数据时显示相应的错误消息或警告消息;
3)各业务规则都得到了正确的应用;
4)各个流程能够正常流转。
开始标准:
1)具有软件测试所需的各种文档并通过评审(需求说明文档等)。
完成标准:
1)按要求完成所有功能测试;
2)测试用例覆盖率达到要求的比例。
测试重点和优先级:
需求文档及开发文档明确规定的功能点。
2.1.2用户界面测试
用户界面(UI)测试用于核实用户与软件之间的交互。
UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。
另外,UI测试还可确保UI中的对象按照预期的方式运行,并符合公司或行业的标准。
测试目标:
核实以下内容:
1)确保通过对用户界面对象的操作可为用户提供相应的访问或浏览功能;
2)确保UI中的对象按照预期的方式运行,并符合行业的标准;
3)验证用户界面的友好度;
4)验证用户界面的易用性;
5)验证用户界面设计的合理性;
6)验证用户界面显示内容的完整性;
7)验证用户界面显示内容的准确性;
8)验证用户界面显示内容的一致性;
9)验证用户界面提示信息的指导性。
测试范围:
××××现有模块界面。
技术:
为每个窗口创建或修改测试,以核实各个应用程序窗口和对象都可正确地进行浏览,并处于正常的对象状态;
着重验证界面的友好度、易用性、规范性、合理性、完整性、准确性、帮助、美观与协调、菜单位置、独特性及快捷方式的组合等。
开始标准:
界面功能模块设计部分或全部完成。
完成标准:
成功地核实出各个窗口都与基准版本保持一致,或符合可接受标准。
测试重点和优先级:
本系统使用频繁的业务模块和功能点。
2.1.3回归测试
当程序修改后,为了确保功能的正确性,需要重新测试应用程序中没有改变的部分。
在时间和条件允许的情况下,要测试修改相关的整个模块甚至整个程序。
测试目标:
测试软件变更之后,变更部分的正确性和对变更需求的符合性;
测试软件变更之后,对软件原有的、正确的功能没有损坏。
测试范围:
1)所有在系统测试过程中发现的问题;
2)和发现的缺陷相关联的模块;
3)需求变更或新增需求。
技术:
1)复测修复的问题;
2)按照最新版的测试用例通测整个系统;
重复步骤1)~2),直至严重问题均已解决。
开始标准:
发现的缺陷修改完成;
提交相应的复测文档;
完成标准:
按照软件配置项回归测试的要求,完成了对变更和受变更影响的软件配置项的测试,并无新问题出现;
对变更的系统的回归测试应符合原系统测试的准出条件,并且无新问题出现。
测试重点和优先级:
测试重点是开发人员提交的已经修复的问题,在保证修复问题复测通过后进行相关功能及整个软件系统的回归测试。
2.2测试目标
Ø确保功能满足《×××用户需求说明书》中的功能约定;
Ø通过对系统的详细测试,包括功能测试、用户界面测试及多次回归测试等,全面验证系统各项功能的正确性和适用性,同时保证整体的测试水平和测试质量。
3测试环境与测试辅助工具
3.1测试配置和环境说明
3.1.1硬件环境
服务器:
描述
服务器
硬件环境
CPU、内存、硬盘
CPU:
六核2.30GHZ
内存:
8G
硬盘:
500G
测试机:
描述
测试机
硬件环境
CPU、内存、硬盘
CPU:
双核2.30GHZ
内存:
2G
硬盘:
500G
3.1.2软件环境
服务器:
描述
服务器
软件环境
操作系统、中间件、数据库等
操作系统:
WindowsServer2008
中间件:
Tomcat6.0
数据库:
Oracle11g
测试机:
描述
测试机
软件环境
操作系统、浏览器
操作系统:
Windows7
浏览器:
IE9
4测试转换准则
Ø进入标准:
◆测试计划经评审通过后;
◆测试用例经评审通过后;
◆申请测试提交单审核通过;
◆测试环境通过环境检查表验证;
Ø退出标准:
◆测试用例执行率达到100%
◆4~5级缺陷修复率100%,1~3级缺陷修复率不低于95%;
Ø停止标准:
◆近半数以上测试用例无法执行;
◆5级缺陷开发人员不能解决;
5人员与任务进度安排
任务
开始时间
工作量(人/日)
负责人
撰写系统测试计划
2012.11.21
1
撰写系统测试用例
2012.11.21
4
系统测试
2012.11.27
8.5
撰写系统测试报告
2012.12.7
1.5
6缺陷管理与改错计划
6.1缺陷管理
测试管理工具:
缺陷应用数据库名:
管理员:
参照《系统测试问题记录》
6.2缺陷分类
缺陷分类
缺陷说明
修正措施
一级缺陷
Low
建议性问题
根据情况由项目经理确定需不需要改什么时间改。
二级缺陷
Medium
细小的错误
由开发人员修改;根据项目的进度要求可以延期修改,由项目经理根据项目的实际情况确定是在项目结束前修改完还是在下个版本升级时再修改。
三级缺陷
High
一般性的错误或功能实现有不完美处
由开发人员修改;根据项目的进度要求可以延期修改,由项目经理根据项目的实际情况确定是在项目结束前修改完还是在下个版本升级时再修改。
四级缺陷
Veryhigh
被测试功能不能正常实现;
软件错误导致数据丢失;
被测数据处理错误;
用户需求未实现。
由开发人员分析原因并写出问题说明和解决办法;必须立即修改。
五级缺陷
Urgent
导致系统崩溃;
导致程序模块丢失;
业务流程出现断点;
内存泄漏;
导致死机
由开发人员分析原因并写出问题说明和解决办法;必须立即修改。
7风险分析及措施
7.1风险分析
预见到的测试风险,及有可能会造成的影响和后果
7.2措施
应对风险可采取什么样的措施,削弱或者减轻可能造成的影响和后果。
8测试的输入与输出
8.1测试的输入与输出
序号
阶段
输入
输出
人员
1
需求
项目计划
《系统测试计划》
2
系统测试
需求说明书和界面原型
《系统测试用例》
3
测试结束
《系统测试报告》
8.2文档的管理
序号
文档
管理工具
负责人
1
《系统测试计划》
VSS
2
《系统测试用例》
VSS
3
《系统测试报告》
VSS
……