测试计划模板.docx
- 文档编号:546155
- 上传时间:2022-10-11
- 格式:DOCX
- 页数:19
- 大小:25.97KB
测试计划模板.docx
《测试计划模板.docx》由会员分享,可在线阅读,更多相关《测试计划模板.docx(19页珍藏版)》请在冰豆网上搜索。
测试计划模板
文件编号:
CMMI-Q-PI-M-1
版本号:
V1.0
受控状态:
测试计划模板
编制:
完成日期:
2007年12月12日
审核:
完成日期:
2007年12月13日
批准:
完成日期:
2007年12月13日
XXX技术有限责任公司
文档修订记录
版本编号或者更改记录编号
*变更
状态
简要说明(变更内容和变更范围)
日期
变更人
批准日期
批准人
1.0
A
编写测试计划模板
2007.12.12
XX
2007.12.13
XX
M
增加测试质量目标和基线
2013.5.20
XX
2013.5.31
XX
*变更状态:
A——增加,M——修改,D——删除
文档审批信息
序号
审批人
角色
审批日期
签字
备注
1
XX
部门经理
2007.12.13
XX
1
引言
1.1编写目的
【阐明编写测试计划的目的,指明读者对象。
】
1.2项目背景
【说明项目的来源、委托单位及主管部门。
】
1.3定义
【列出测试计划中所用到的专门术语的定义和缩写词的原意。
】
1.4范围
【列要本文档所关注产品的组成部分的一份清单。
要测试的发行版本
以往版本待修正缺陷
安装方式或发行媒质
最终用户文档列表】
1.5参考资料
【列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源,可包括:
a.项目的计划任务书、合同或批文;
b.项目开发计划;
c.需求规格说明书;
d.概要设计说明书;
e.详细设计说明书;
f.用户操作手册;
g.本测试计划中引用的其他资料、采用的软件开发标准或规范。
】
2任务概述
2.1测试的目标
2.2进行测试的软件、硬件环境以及测试工具
2.3测试的阶段
单元测试、集成测试、系统测试或验收测试及其它
3计划
3.1测试方案
【说明主要测试方法、选取的测试用例,对测试进行总体描述】
3.2测试安排
【说明本次测试的阶段名称、目的、人员、开始及结束准则和时间等。
】
3.3测试准备
【列出本次测试需进行的准备工作。
】
3.4测试机构及人员
【测试机构名称、负责人和职责。
】
4测试项目说明
4.1测试项目名称、测试内容以及测试方法
4.2测试用例(可选)
用例编号
用例描述//简要描述测试用例
预期结果
1
2
3
备注
表4.1
5评价
5.1范围
【说明所完成的各项测试说明问题的范围及其局限性。
】
5.2准则
5.2.1测试完成准则
对于非严格系统可以采用“基于测试用例”的准则:
1、功能性测试用例通过率达到100%;
2、非功能性测试用例通过率达到95%时。
对于严格系统,应当补充“基于缺陷密度”的规则:
相邻n个CPU小时内“测试期缺陷密度”全部低于某个值m。
例如n大于10,m小于等于1。
3、千行代码率
千行代码率:
bug总数/代码千行数*100%
如下图仅供参考
千行代码缺陷率(BUG率)
CMMI1级
11.95‰
CMMI2级
5.52‰
CMMI3级
2.39‰
CMMI4级
0.92‰
CMMI5级
0.32‰
5.2.2测试评审与通过标准
执行测试过程
●评估测试的执行情况
●恢复暂停的测试
●核实结果
●调查意外结果
●记录缺陷
评估测试
●评估测试用例覆盖
●评估代码覆盖
●分析缺陷
●确定是否达到了测试完成标准与成功标准
5.2.3测试质量标准
5.2.3.1测试效率
指标(单位)
定义
基线
上限
下限
测试用例效率
测试用例个数/测试用例编写的工时
测试效率
有效代码千行代码数/工作量
5.2.3.2测试效果
指标(单位)
定义
基线
上限
下限
测试用例执行密度
用例个数/有效代码千行代码数
测试缺陷效果
测试缺陷个数/每轮测试工时(注:
在同一版本或者同一个阶段中,每轮测试工作量)
6系统风险、优先级
在此记录任何与本测试项目相关的风险和问题。
例如:
风险和问题包括以下几条:
Ø开发单位是否按时完成既定工作;
Ø测试计划、测试流程、测试进度的制订不够合理、规范。
在项目进行过程中,发现其可操作性不强;
Ø测试所需的资源是否到位。
如:
是否有足够的测试组人员,测试人员的培训是否按时进行,并且测试人员的技能是否达到了要求。
测试所需的软、硬件和操作系统等测试环境是否准备完毕;
Ø测试人员之间,以及测试组人员与用户之间是否进行了有效的沟通;
Ø项目参加人员对于所使用的测试工具及其系统不熟悉,在使用过程中出现偏差,影响测试效率。
7测试策略(根据不同项目选择不同策略)
对于每种测试,都应提供测试说明,并解释其实施和执行的原因。
如果不实施和执行某种测试,则应该用一句话加以说明,并陈述这样做的理由。
例如,“将不实施和执行该测试。
该测试不合适。
”
制定测试策略时所考虑的主要事项有:
将要使用的方法以及判断测试何时完成的标准。
下面列出了在进行每项测试时需考虑的事项,除此之外,测试还只应在安全的环境中使用已知的、受控的数据库来执行,可按实际需要进行删减。
7.1数据和数据库完整性测试
【数据库和数据库进程应作为<项目名称>中的子系统来进行测试。
在测试这些子系统时,不应将测试对象的用户界面用作数据的接口。
对于数据库管理系统(DBMS),还需要进行深入的研究,以确定可以支持以下测试的工具和方法。
】
测试目标:
[确保数据库访问方法和进程正常运行,数据不会遭到损坏。
]
方法:
∙[调用各个数据库访问方法和进程,并在其中填充有效的和无效的数据或对数据的请求。
∙检查数据库,确保数据已按预期的方式填充,并且所有数据库事件都按正常方式出现;或者检查所返回的数据,确保为正当的理由检索到了正确的数据]
完成标准:
[所有的数据库访问方法和进程都按照设计的方式运行,数据没有遭到损坏。
]
需考虑的特殊事项:
∙[测试可能需要DBMS开发环境或驱动程序以便在数据库中直接输入或修改数据。
∙进程应该以手工方式调用。
∙应使用小型或最小的数据库(其中的记录数很有限)来使所有无法接受的事件具有更大的可见性。
]
表7.1
7.2功能测试
【测试对象的功能测试应该侧重于可以被直接追踪到用例或业务功能和业务规则的所有测试需求。
这些测试的目标在于核实能否正确地接受、处理和检索数据以及业务规则是否正确实施。
这种类型的测试基于黑盒方法,即通过图形用户界面(GUI)与应用程序交互并分析输出结果来验证应用程序及其内部进程。
以下列出的是每个应用程序推荐的测试方法概要:
】
测试目标:
[确保测试对象的功能正常,其中包括导航、数据输入、处理和检索等。
]
方法:
[利用有效的和无效的数据来执行各个用例、用例流或功能,以核实以下内容:
∙在使用有效数据时得到预期的结果。
∙在使用无效数据时显示相应的错误消息或警告消息。
∙各业务规则都得到了正确的应用。
]
完成标准:
∙[所计划的测试已全部执行。
∙所发现的缺陷已全部解决。
]
需考虑的特殊事项:
[确定或说明那些将对功能测试的实施和执行造成影响的事项或因素(内部的或外部的)]
表7.2
7.3用户界面测试
【通过用户界面(UI)测试来核实用户与软件的交互。
UI测试的目标在于确保用户界面向用户提供了适当的访问和浏览测试对象功能的操作。
除此之外,UI测试还要确保UI功能内部的对象符合预期要求,并遵循公司或行业的标准。
】
测试目标:
[核实以下内容:
∙通过浏览测试对象可正确反映业务的功能和需求,这种浏览包括窗口与窗口之间、字段与字段之间的浏览,以及各种访问方法(Tab健、鼠标移动和快捷键)的使用
∙窗口的对象和特征(例如:
菜单、大小、位置、状态和中心)都符合标准。
]
方法:
[为每个窗口创建或修改测试,以核实各个应用程序窗口和对象都可正确地进行浏览,并处于正常的对象状态。
]
完成标准:
[证实各个窗口都与基准版本保持一致,或符合可接受标准]
需考虑的特殊事项:
[并不是所有定制或第三方对象的特征都可访问。
]
表7.3
7.4性能评测
【性能评价是一种性能测试,它对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。
性能评价的目标是核实性能需求是否都已满足。
实施和执行性能评价的目的是将测试对象的性能行为当作条件(例如工作量或硬件配置)的一种函数来进行评价和微调。
注:
以下事务均指“逻辑业务事务”。
这种事务被定义为将由系统的某个主角通过使用测试对象来执行的特定用例,例如,添加或修改某个合同。
】
测试目标:
[核实所指定的事务或业务功能在以下情况下的性能行为:
∙正常的预期工作量
∙预期的最繁重工作量]
方法:
∙[使用为功能或业务周期测试制定的测试过程。
∙通过修改数据文件来增加事务数量,或通过修改脚本来增加每项事务的迭代次数。
∙脚本应该在一台计算机上运行(最好是以单个用户、单个事务为基准),并在多台客户机(虚拟的或实际的客户机,请参见下面的“需考虑的特殊事项”)上重复。
]
完成标准:
∙[单个事务或单个用户:
在每个事务所预期或要求的时间范围内成功地完成测试脚本,没有发生任何故障。
]
∙[多个事务或多个用户:
在可接受的时间范围内成功地完成测试脚本,没有发生任何故障。
]
考虑的特殊事项:
综合的性能测试还包括在服务器上添加后台工作量。
可采用多种方法来执行此操作,其中包括:
∙直接将“事务强行分配到”服务器上,这通常以“结构化查询语言”(SQL)调用的形式来实现。
∙通过创建“虚拟的”用户负载来模拟许多个(通常为数百个)客户机。
此负载可通过“远程终端仿真”(RemoteTerminalEmulation)工具来实现。
此技术还可用于在网络中加载“流量”。
∙使用多台实际客户机(每台客户机都运行测试脚本)在系统上添加负载。
性能测试应该在专用的计算机上或在专用的机时内执行,以便实现完全的控制和精确的评测。
性能测试所用的数据库应该是与实际大小相同或等比例缩放的数据库。
表7.4
7.5负载测试
【负载测试是一种性能测试。
在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。
负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。
此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。
】
[注:
以下事务均指“逻辑业务事务”。
这些事务被定义为将由系统的最终用户通过使用应用程序来执行的具体功能,例如,添加或修改某个合同。
]
测试目标:
[核实所指定的事务或商业理由在不同的工作量条件下的性能行为时间。
]
方法:
∙[使用为功能或业务周期测试制定的测试。
∙通过修改数据文件来增加事务数量,或通过修改测试来增加每项事务发生的次
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 测试 计划 模板
![提示](https://static.bdocx.com/images/bang_tan.gif)