测试计划VdocWord文档格式.docx
- 文档编号:21808573
- 上传时间:2023-02-01
- 格式:DOCX
- 页数:8
- 大小:25.81KB
测试计划VdocWord文档格式.docx
《测试计划VdocWord文档格式.docx》由会员分享,可在线阅读,更多相关《测试计划VdocWord文档格式.docx(8页珍藏版)》请在冰豆网上搜索。
项目管理人员根据此计划,可以对项目进行宏观调控。
测试人员根据此计划,能够明确自己的权利、职责,并对项目的总体情况有个大致的认识,能够准确地定位自己在项目的作用,并能使自己从事的工作从整体的意义上发挥最大的作用。
相关部门,可以根据此计划,对相关资源进行准备。
1.2背景
a.本测试计划从属于XXX,为XXX实现XXX。
b.项目任务的提出者为:
XXX公司项目管理部;
系统的开发者为:
XXX公司;
系统的使用者为:
XXX;
c.此测试项目的进行,将在需求确认后开始执行,基准是准确、全面的需求文档。
测试重点是对开发实现的功能进行测试。
1.3定义
1.4参考资料
a.《XXX功能界定书》10版本
b.《XXX测试计划编写规范》
1.5控制信息
本项目测试经理:
电话号码:
1.6测试目标
该测试项目将通过设计和执行接受测试、界面测试和功能测试,对软件实现的功能,以及软件的兼容性、安全性、实用性、可靠性、扩展性各个方面进行全面系统的测试。
基于本系统的业务复杂性和开发周期短的特性,系统测试的重点将放在功能测试上。
通过测试提高软件的质量,为用户提供最好的服务,并合理地避免软件的风险和减少软件的成本。
测试报告确认该项目符合客户需求,第一、二级问题报告单的状态为close和cancel状态,经项目经理确认后,第三级问题报告单允许为其它状态,对没有解决的问题,已经进行了详细记载,该测试项目结束。
2计划
2.1进度安排及里程碑
给出进行各项测试的日期和工作内容(如熟悉环境、培训、准备输入数据、实施测试等)。
里程碑任务
工作
开始日期
结束日期
制定测试计划
设计测试
实施测试
对测试进行评估
2.2角色
测
试
人
员
安
排
负责人:
其他负责人
职责
联系信息
职责:
负责制定测试计划;
负责编写和验收用例;
完成项目实测;
负责与外部合作部门交互;
负责协调内部人员的工作;
负责编写测试报告。
测试组成员
姓名
职责
负责部分测试案例的编写和测试
2.3系统
下表列出了测试项目所需的系统资源。
系统资源
资源
名称/类型
数据库服务器
网络或子网
服务器名称
数据库名称
客户端测试PC
包括特殊的配置需求
测试存储库
测试开发PC
2.4可交付工件
项目测试计划:
项目测试案例:
问题报告清单:
2.4.1测试模型
2.4.2测试记录
采用测试案例
2.4.3缺陷报告
采用问题报告单清单
2.5测试资料
测试文档:
测试相关模板。
需求文档:
项目需求文档
2.6项目风险分析
编号
可能风险
风险的原因
造成的问题
采取的措施
1.
2.
3测试设计说明(大纲)
3.1概述
3.1.1测试方法和测试案例选取的原则
系统:
(要求从宏观的角度,对软件的各个方面进行测试)
全面:
(要求测试案例能够覆盖每一个测试点的要点)
合理:
(测试的用例的选择避免重复测试、选择最好的测试方法将测试点合理覆盖)
3.1.2测试的控制方式
测试案例的实现必须遵守测试计划的安排。
实际测试必须以测试案例为基准。
实际测试中测试案例的状态记载:
(1)failed:
如果某一步测试案例失败,但不影响以后测试案例处理
(2)block:
如果某一步测试案例失败,并影响以后测试案例处理
(3)good:
成功测试
实际测试与外部交互使用问题报告单清单进行交流。
测试人员必须详细、准确填写报告单内容。
开发修改人员要详细、准确地填写修改情况
通过问题报告单清单的状态进行测试和修改交互
(1)open:
当开始一个问题报告单时,为open
开发返回后,错误仍存在为open
(2)fixed/return
开发人员对错误进行了修改,为fixed
开发人员对错误没有进行修改,返回测试部为return
(3)close/cancel
测试人员确认错误已经修改,为close
测试人员确认错误的无效或可以接受(标记)为cancel
对外部交互使用一个接口。
测试版本的控制
由项目开发组随版本发布时提交版本提交单,测试组完成测试后提交版本测试报告,版本更新时由开发组填写更新记录。
测试案例的命名原则:
测试面_[测试功能]_[测试点]编号
例如:
FVT_Manage_PersonAdd001(功能测试_管理员部分_人员增加001)
问题报告单清单命名原则为:
问题报告单清单+_测试人员名称+_日期
例如:
问题报告单清单_刘飞_20020101
3.1.3数据选择策略:
数据的选择全面覆盖所有数据、并要求避免冗余数据的使用(采用边界值、特殊值、以及普通值)。
3.1.4测试过程描述和操作步骤:
Ø
书写测试计划
参考测试计划、需求、概要设计以及部分详细设计文档进行案例设计
参考测试计划和测试案例进行实际测试操作
测试总结
测试设计详细说明:
1、基本界面连接测试
2、测试基本流程(简易的IVT)
3、测试功能块(重点为容错测试)
4、统计信息的测试(IVT)
3.2软件说明
XXX。
3.3测试内容及测试重点
本测试将通过接受测试、用户界面测试、功能测试、集成测试,对系统进行测试。
3.3.1接受测试(AVT)
目的:
对待测试软件产品的完整性和可用性进行评定
内容:
根据系统功能界定检查软件产品功能结构的完整,以及系统安装、配置、运行的可用性。
3.3.2用户界面测试(UIT)
对系统中出现的所有页面进行全面测试
对系统的功能页面进行各种可操作性测试
重点:
容错检测
3.3.3功能测试(FVT)
对XXX进行全面测试
对系统的业务操作进行各种可能性流程测试
权限测试
数据正确性测试
3.3.4集成测试(SVT)
对整个系统进行全面测试,主要包括系统兼容性、安全性、实用性、可靠性、扩展性。
把整个系统所涉及的操作,按照系统流程进行测试。
系统操作权限的安全性
系统业务配置的扩展性
3.4测试重点及用例的设计
测试的重点将主要放在功能测试上,包括如下模块:
3.5评价
3.5.1范围
功能测试涵盖测试全过程。
界面测试涵盖测试全过程。
3.5.2准则
系统功能符合客户需求。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 测试 计划 Vdoc