测试计划Word格式.doc
《测试计划Word格式.doc》由会员分享，可在线阅读，更多相关《测试计划Word格式.doc（11页珍藏版）》请在冰豆网上搜索。
使用工具
提交日期
责任人
《测试计划》
Word
测试经理
《测试用例》
QC
《缺陷报告》
《测试报告》
Excel
项目的测试人员、职位、工作职责
角色
姓名
工作内容
编写测试计划缺陷管理测试结果分析
黑盒测试工程师
编写测试用例执行测试报告缺陷
自动化测试工程师
编写脚本自动化测试执行
性能测试工程师
分析软件功能开发脚本性能测试执行
需要配合的部门与人员
开发人员
协助搭建测试环境
业务人员
协助测试人员理解需求，提供业务帮助
5.测试工具
测试管理工具为QualityCenter、性能测试工具有LoadRunner、功能自动化测试工具为QuickTestProfessional
用途
工具
生产厂商
版本
测试管理
HP
9.0
性能测试
LR
8.1
功能自动化
QTP
9.2
6.测试规模以及工作量分析
XXXX项目为大型项目，测试工作包括为测试计划、测试用例的编写、集成测试的执行、性能测试的执行，涉及功能模块较多，业务逻辑较为复杂，预估测试工作量如下所示。
测试工作量预估
任务阶段
人数
工作日
人日小计
备注
测试案例编写
15
7
105
测试执行
23
345
功能点分析
模块
子节点
测试人员
启动时间
XXXX
登录及整体架构
2009-10-24
XXXXX
XXX
7.测试进程
1）测试流程表
2）测试过程描述
a.测试计划阶段
编写测试计划
测试经理根据项目计划与项目业务需求说明书创建测试计划，如果此需求发生变化，则将根据变化更新此项目测试计划。
评审测试计划
ü
项目经理浏览并评审《系统项目测试计划》。
测试经理负责更新此文档。
项目经理负责评审和批准经过更新的文档。
《项目测试计划》的版本为1.0,如果该计划被更新，则版本的序号也随之变更。
测试工程师根据测试计划执行测试任务。
b.测试用例阶段
编写测试用例
分析《软件需求说明书》。
测试工程师根据《软件需求说明书》编写测试用例。
冒烟测试用例需要被同时创建。
评审测试用例
测试组负责评审《测试用例》。
在发现错误或问题的情况下，该测试用例将会被更新。
测试经理负责填写《测试用例评审报告》。
我们将《测试用例》的最初版本定义为1.0，如果该文件得到更新，其版本也会被同时更新。
c.测试阶段
冒烟测试
测试工程师负责根据《项目测试用例》进行冒烟测试，执行测试用例的实际输出结果是否符合预期结果，我们将此用例标注为通过或者失败，将结果返回给开发部门。
系统测试
根据《项目测试计划》和《项目测试用例》，测试工程师负责执行测试用例：
当执行测试用例时：
1.如果实际输出结果和预期输出结果相同，该用例需要被标注为通过。
2.如果实际输出结果和预期输出结果不同，该用例需要被标注为失败。
3.如果测试时遇到功能性缺陷导致用例不能执行，该测试用例需要被标注为锁定，直到该缺陷被修复，才可以继续执行该测试用例。
4.所有在测试过程发现的缺陷，需要被提交到QualityCenter。
测试用例在测试过程中将根据需要得到更新。
测试经理负责分析测试结果，对测试人员执行的测试用例进行一定比率的内部QC（质量控制）。
测试完成时，需得到测试经理的批准。
备注：
所有的缺陷必须被提交到缺陷处理系统QualityCenter。
d.测试总结阶段
分析和总结测试结果
测试经理总结各自的测试工作并在《项目测试总结》中填写相应的部分内容。
包括测试工具，测试技术，测试体会以及工作质量等。
测试经理负责在《项目测试总结》中分析与总结测试数据，填写包括测试人员工作效率，人力资源消耗，测试过程中经验与教训，评价整个项目过程中的测试质量。
测试完成
测试经理负责批准测试完成。
所有测试人员在《项目测试总结》中签名，证明所有任务都已完成。
8.测试进度及时间资源
XX网银项目测试人员数量为15人，测试时间为450个工作日。
测试活动
计划开始日期
计划结束日期
实际开始日期
实际结束日期
测试计划
2009-10-27
设计测试用例
2009-10-26
2009-11-4
测试用例评审
2008-10-27
2009-11-5
环境搭建
2009-10-28
系统测试
2009-11-20
2009-11-22
2009-12-2
测试总结报告
2009-11-29
9.测试轮次安排
XXXX测试项目测试轮次视项目情况而定，通常分为2轮，每轮的工作根据轮次的推进而改变。
第一轮
2009-11-12
第二轮
2009-11-13
测试内容
人员
冒烟测试、功能测试
缺陷验证、冒烟测试、功能测试、用户界面测试、、兼容性测试
10.测试方法
1）功能类测试
功能类测试是银行项目测试工作中的重点，在各个环节都需要有比较全面的考虑。
先考虑测试案例的组织结构，首先按照功能模块（通常对应系统中的一级菜单）归类，然后针对各功能模块下的每一个具体功能（即有独立页面的功能，简称子功能）再分类，分别设计不同方面的测试案例，案例的组织结构如下：
——“XX模块”
——“XX叶子功能1”
——冒烟测试
——页面要素验证
——必输项验证
——输入项检查
——联动项检查
——本功能流程测试
——通过性测试
——失效性测试
——“XX叶子功能2”
……
——总体规则验证
——数据流转测试
——后台线程测试
数据流转测试和后台线程测试，这两类案例可考虑根据情况，放在某一模块下，或者单独自成一部份。
对这几类测试，做一个简要的说明：
名称
描述
冒烟测试
对本功能正常的主线流程进行验证而设计的案例
此案例专门用来做冒烟测试，通常每个子功能只需提供一条该案例，设计时只需保证该功能的正常操作流程（即仅输入必要的有效数据）通过即可
总体规则
根据需求文档中提供的总体规则来设计的用例。
主要包括各个功能页面风格的一致性、操作习惯的一致、显示格式的统一等。
通常一个项目的总体规则是固定的，既要保证案例的执行覆盖度，又要避免案例的冗余，所以总体规则可由一个人完成设计，在各个模块下直接复用；
测试执行时，可根据需要来进行执行情况的统计。
页面\必输项验证
执行该功能操作，页面中所必须录入/选择的项目，是否在为空的情况下仍然可以通过提交的检查。
各个页面的必输项不同，要考虑必输项的显示方式，以及非必输项是否也被做了必输限制等。
页面\输入项检查
主要指在客户端所进行的各类输入数据项的合法性的检查。
这部分案例主要指在客户端能够验证或限制的内容，如数据输入长度限制、是否含有非法字符等。
页面\联动项检查
主要指页面中多个输入或选择项目之间，根据前一项的结果而对其它项是否产生了约束的检查。
例如，城市的选择，选择了省之后，其下可选择的市，是否进行了列表更新等。
本功能流程测试
当前功能本身的操作及数据流程正确性的测试，包括正常流程和异常流程。
例如，执行转账操作，输入正确和错误密码是否得到了正确的正常和异常返回结果；
以及显示的返回结果是否与实际结果一致等。
数据流转测试
主要指银行端与客户端之间的数据通讯是否准确，以及企业网银授权、审核流程的数据流转是否正确等。
例如，企业网银在银行端设定某种授权模式，在客户端是否正确体现等；
或银行端修改了客户信息、发布了客户通知等在客户端是否正确体现等。
后台线程测试
验证系统设定的在固定时间自动线程是否正确执行。
例如，系统设定每天凌晨1点，某系统自动从主机同步网点数据进行更新等。
注：
“数据流转测试”从名称和范围上难与功能流程测试有明显划分的界限，可根据实际项目情况变更案例类别的名称，或明确规定试用范围；
实际项目中可能仍会有部分案例无法划分在上述的类别中，可根据实际情况进行调整，或单独形成一个补充案例。
例如，主机错误码在网银系统未知的情况，是由于网银数据库基础数据不完整，也应属于缺陷。
“冒烟测试”的案例，仅执行冒烟测试时使用，案例可能会与“本功能流程测试”的案例重复，但此处单独提出，便于测试的执行和统计，不算案例冗余。
2）兼容性测试
兼容性测试主要应针对客户端，并且根据客户的要求并结合实际，来提供不同的测试方案，并非要盲目的兼容一切；
B/S架构项目兼容性测试的重点，在于
升级会员 