测试大纲
一、测试计划
1 概述
1.1 目的
简述本计划的目的,旨在说明各种测试阶段任务、人员分配和时间安排、工作规范等。测试计划包含足够的信息使测试人员明白项目需要做什么,是如何运作的。另外,清晰的文档结构能使任何一个读者在浏览计划的前面几页后,就能对项目有一个大概的认识。测试计划只是测试的一个框架,很多细节需要跟开发人员或其他人员沟通,因此计划不包括测试用例的细节和系统功能的详细信息。
注:在正式编写文档前,请把蓝色字体全部删除。
1.2 范围
在计划目的中需要指明读者对象,如下:
本文档包括资源需求计划、测试对象计划、进度里程碑计划,并指明工作交付件。
本文阅读对象:产品经理、测试经理、测试人员及相关人员。
1.3 测试对象
详细描述被测对象,包括硬软件特性等;要附上被测试对象的平面图。
1.4 名字解释
列出本计划中使用的专用术语及其定义;
列出本计划中使用的全部缩略语全称及其定义。
缩写词或术语 | 英文解释 | 中文解释 |
2 测试计划
2.1 资源需求
2.1.1 软件需求
资源 | 描述 | 数量 |
Jmeter | 用于测试接口功能 | 1 |
公司的问题单管理库 | 问题单管理 | 1 |
操作系统 | CentOS7 LIUNX | 各1套 |
2.1.2 硬件需求
描述建立测试环境所需要的设备、用途及软件部署计划。
资源 | 描述 | 数量 |
Pc机器 | 普通办公环境 | 1套 |
测试服务器 | 服务器配置清单及重要部件版本信息 | 4套 |
网线 | 用于服务器之间的连接 | 15根 |
2.1.3 人员需求
列出项目参与人员的技能和数量,到位时间等
资源 | 技能要求 | 数量 | 到位时间 |
测试工程师 | 1) 掌握基本的编程知识; 2) 熟悉测试流程和测试方法; 3) 对测试对象的业务知识较为了解。 |
2.1.4 测试输入件
列出测试过程中可能用到的参考文档、相关的设计文档以及保存位置
输入件 | 相关人员 | 需求日期 | 备注 |
2.2 过程条件
2.2.1 启动条件
描述版本能启动测试的基本条件;如:版本基本稳定、测试用例、测试设备准备完成。
2.2.2 结束条件
简要说明测试发布的质量目标;
测试方案中所有测试方法和模块已经执行通过;
所有的测试用例已经执行过;
所有的重要等级Bug已经解决并由测试验证。
2.3 进度计划
2.3.1 人力投入
25天/人(工作日)
2.3.2 阶段里程碑
对各阶段的测试给出里程碑计划,包括阶段、里程碑、资源等。
里程碑 | 完成时间 | 完成标准 |
测试正式开始 | 完成可接受性测试和烟雾测试 | |
进行CVS LOCK | 完成所有里程碑测试和标准测试,测试种类包括确认测试和系统测试,且所有发现的Bug等级为1/2/3的Bug已修复,近期内无发现新的Bug等级为1/2/3的Bug | |
产品Release | 重复进行主路径测试和进行Bug检查测试,产品处于可交付状态并由测试经理和产品经理确认 |
2.4 任务分配及进度
简要说明测试开始时间与发布时间,测试人员,阶段完成标志。
测试阶段 | 开始时间 | 完成时间 | 测试人员 | 阶段完成标志 |
制定测试计划 | ||||
需求Review | ||||
设计Review | ||||
设计测试用例 | ||||
测试开发 | ||||
测试环境准备 | ||||
测试实施 | ||||
功能测试 | ||||
集成测试 | ||||
性能测试 | ||||
系统测试 | ||||
验收测试 | ||||
文档编写 |
备注:由于时间安排的紧迫性和测试人力资源的缺乏,各种测试阶段可能会同时进行。
2.5 导向/培训计划
为了能让测试人员尽快熟悉业务,需要收集一些培训需求。
培训需求 | 培训内容 | 培训人员 | 开始时间 | 完成时间 |
业务流程 | ||||
安装配置 | ||||
工具使用 |
3 工作交付件
测试工作完成后,测试将得到怎样的提交产物或输出,下面主要明确描述测试的输出文件
交互件名称 | 责任人 | 应交付日期 |
XXX性能测试报告 | ||
XX测试报告 |
4 参考资料
列出本计划各处参考的经过基线化的全部文档和主要文献。
二、测试方案
1 概述
1.1 目的
描述需要测试的特性、测试方法、测试用例编写方法、测试环境规划、测试工具的设计和选择、本次测试可能存在的风险及规避办法。
如:编写本方案的目的是用于指导XXXX系统测试,主要从测试环境、测试工具、测试策略、测试具体执行方法等计划和设计。
1.2 名词解释
此报告中涉及的业务和技术方面的专业名词。
缩写词或术语 | 英文解释 | 中文解释 |
1.3 被测对象概述
主要描述被测对象的特性,重点模块,应用场景。如果是在原有产品上修改,请将修改重点描述。
1.4 测试方案概述
如:本测试方案是针对XXX版本的全面特性测试方案。
主要包括测试对象的分析, 测试需求的划分,测试用例的设计,测试环境等内容. 为XX测试提供总体测试方案、全面特性测试方案。用于指导测试需求的分解,系统测试用例的设计。
1.5 参考资料
此报告参考和依据的所有文档
2 XXX特性测试设计
2.1 测试对象分析
对待测对象进行全面的分析;分析包括软件和硬件。
2.2 测试类型分析
详细描述本次测试中将会用到的测试类型。
2.3 测试设计策略分析
如:根据原始需求设计本次测试,覆盖XXX平台业务逻辑。原则上根据每个功能点进行详细的测试需求分析设计和测试。测试设计的思路包括但不限于:输入参数的合法性测试、输出结果的正确性测试、日志功能的记录信息测试、XX创建/修改/删除等测试、观察数据变化测试、异常情况测试。设计时使用等价类划分、边界值和错误推测的方法构造输入数据,覆盖所有处理分支。
2.4 详细测试方法
描述出产品的主要功能列表,如:支持订单创建、修改、删除、查看等。
如:
编号 | 功能 | 功能描述 |
1 | 支持订单创建 | |
2.4.1 支持RAID5
主要从测试对象分析、测试设计策略分析、详细的测试方法这三方面进行重点分析.
如:
测试对象分析:
测试设计策略分析:
Ⅰ.从测试类型来看,系统要做以下测试类型分析
1、功能测试
2、性能测试
3、压力测试
4、配置测试
5、长时间测试
6、故障植入测试
7、易用性测试
8、大容量测试
9、兼容性测试
10、数据一致性测试
11、稳定性测试
Ⅱ.从功能交互对系统进行分析
产品功能不是独立的,功能之间存在交互;防止有交互作用的功能遗漏,提高功能测试的完备性
Ⅲ.从关联图对系统功能进行分析
Ⅳ.从继承性对系统功能进行分析
详细测试分析:
序号 | 测试类型 | 测试分析 |
1 | 功能测试 | 要做功能测试,主要考虑能否正常创建/删除/修改订单。 |
2 | 性能测试 | 要做性能测试,在做性能测试又要分析很多方面,如:对单个商品同时创建多个订单;对多个商品同时创建多个订单;对低库存商品同时创建超出库存数量订单。 |
3 | 压力测试 | 要做压力测试,单控达到最大压力、双控达到最大压力;这个往往和长时间测试一起进行。这个压力测试主要是为了检查在一定的压力下,系统的响应能力。设计用例时照这方面考虑;例如:在压力很大时,创建订单。 |
4 | 长时间测试 | 要做长时间测试,主要分有业务的情况下,没有业务的情况下;存储长时间(30天)运行是否会出问题 |
5 | 易用性测试 | 要做易用性测试,主要考虑创建订单是否方便,界面是否友好,出错是否有错误信息提示等等 |
6 | 备份测试 | 不用 |
7 | 兼容性测试 | 要做兼容性测试,不同设备终端、系统、分辨率 |
8 | 数据一致性测试 | 要做数据一致性测试,主要考虑输入的数据和输出数据是否一致 |
9 | 稳定性测试 | 要做稳定性测试,其实前面的长时间测试和这个稳定性测试有点类似,不过在进行稳定测试时,要考虑改变不同的压力。 |
2.4.2 支持Snapshot功能
2.4.3 支持SNMP管理
2.4.4 XXX性能子特性测试设计
2.4.5 XXX稳定性子特性测试设计
2.4.6 XXX兼容性子特性测试设计
2.5 自动化测试设计
主要描述一些自动化设计的方案
2.6 测试用例设计
2.6.1 用例编号规则
2.6.2 用例编写方法
设计用例时使用等价类划分、边界值、错误推测、因果图等方法构造输入数据,覆盖所有功能点。
2.7 测试组网/系统架构分析
附上测试时用到的详细组网/系统架构图。
2.8 测试环境分析
2.8.1 硬件需求
资源 | 描述 | 数量 |
Pc机器 | 普通办公环境 | 1套 |
测试服务器 | 服务器配置清单及重要部件版本信息 | 4套 |
网线 | 用于服务器之间的连接 | 15根 |
2.8.2 软件需求
资源 | 描述 | 数量 |
IOmeter | 用于测试服务器的性能 | 1 |
公司的问题单管理库 | 问题单管理,如:bugzilla | 1 |
公司测试用例管理库 | 测试用例管理库,如:testlink | 1 |
操作系统 | centos7 LIUNX | 各1套 |
2.8.3 其它需求
3 风险及规避
3.1 本次测试过程中,可能出现的风险
如:
1、系统整体功能的实现情况
2、人员经验以及对软件的熟悉度
3、代码的编写质量
4、来料的质量
3.2 风险规避
如:
1、与设计人员多沟通
2、控制来料质量
3、加强内总外部培训
4 附件
4.1 测试用例列表
三、测试用例
四、测试报告
1 概述
1.1 目的
说明为什么要进行此测试;项目背景,对版本做个简单介绍等。
注:在正式编写文档前,请把蓝色字体全部删除。
1.2 名词解释
此报告中涉及的业务和技术方面的专业名词。
缩写词或术语 | 英文解释 | 中文解释 |
1.3 参考资料
此报告参考和依据的所有文档
2 测试环境
详细描述测试中所用到的硬件环境、软件环境、组网方式等等。
2.1 硬件环境
资源 | 描述 | 数量 |
Pc机器 | 普通办公环境 | 1套 |
测试服务器 | 服务器配置清单及重要部件版本信息 | 4套 |
NL-SAS | NL-SAS硬盘信息 | 30块 |
SATA硬盘 | SATA 硬盘信息 | 30块 |
KVM切换器 | 用于连接测试服务器 | 不限 |
网线 | 用于服务器之间的连接 | 15根 |
2.2 软件环境
资源 | 描述 | 数量 |
IOmeter | 用于测试服务器的性能 | 1 |
公司的问题单管理库 | 问题单管理,如:bugzilla | 1 |
公司测试用例管理库 | 测试用例管理库,如:testlink | 1 |
操作系统 | centos7 LIUNX | 各1套 |
2.3 组网方式/系统架构
在报告中列出详细的组网方式/系统架构.。
2.4 测试时间人员
版本名称
| 测试时间 | 测试人员 | 测式地点 | |
开始时间 | 结束时间 | |||
动态对比服务器 | 2024-3-15 | 2024-4-15 | XXX | 实验室 |
主要描述产品名称、测试的超始时间、测试人员及测试地点
3 测试过程评估
3.1 需求测试覆盖表
列出《产品系统需求规格说明书》中的功能测试通过情况,并在此嵌入该表
3.2 测试执行评估
重点描述是否执行了全部测试用例,或有那些测试没有执行。
3.3 测试用例执行统计数据
Priority | Total | Passed | Failed | Not Run | Blocked | ||||
Count | Percent | Count | Percent | Count | Percent | Count | Percent | ||
All | |||||||||
ATP | |||||||||
High | |||||||||
Medium | |||||||||
Low |
注明:测试优先级分为:ATP、High、Medium、Low; 其中ATP=接受测试
在表格后面可以引入图表,同时必须从测试用例管理平台(Test Link)报表中(Test result matrix)部分导出测试用例执行结果,模板如下面附件。
3.4 缺陷统计分析
状态 | 致命 | 严重 | 次要 | 一般 | 建议 | Total | |
Count | Percent | ||||||
New | |||||||
Assigned | |||||||
Fixed | |||||||
Postponed | |||||||
Closed | |||||||
Total |
注明:在表格后面可以引入图表
3.5 版本发布历史
序号 | 版本号 | 版本提交测试时间 | 版本测试结束时间 | 版本引入原因分析 | 版本类型 | 备注 |
1 | ||||||
2 | ||||||
3 |
注明:版本类型分成:测试版本和发布版本,最终测试通过的版本为“发布版本”
4 产品质量评估
此模板中总共列出了下面6项试评估,其它测试类型可以根据实际需要进行增加
4.1 安装或升级测试评估
4.2 产品功能测试评估
4.3 产品稳定性测试评估
加入拷机的结果等
4.4 产品可靠性测试评估
4.5 产品性能测试评估
4.6 版本测试结论
测试结论说明:
结论分类 | 结论选择 | 结论说明 |
通过 | 产品可归档及发布对外使用 | |
有条件通过 | 产品可对外发布,但在发布说明需注明问题影响及处理说明 | |
不通过 | 产品不能对外发布使用 |
表格说明: 1) 满足测试结束准则,通过测试。
2) 基本满足测试结果,有些小问题但不影响系统主功能的使用,可在日后维护中修改,则为有条件通过。
3)不满足测试结束准则,测试不通过。
4)如有进行性能测试,请附上性能测试报告,并在此简要列出性能测试结果。
5)内部验证测试通过后,此处需要说明是否实施外部验证测试。
6)外部验证测试通过后,需要说明是否可以发布使用。
4.7 发布版本
版本号 | 文件名 | 文件大小 | 备注 |
配套版本 | |||
配套版本 | |||
配套版本 |
备注:文件大小为win10操作系统上显示大小。
5 遗留问题
缺陷表述部分必须叙述清楚,让人能一目了然知道这个bug的基本信息
序号 | BUG ID | 严重级别 | 简要描述 | 备注 |
1 | ||||
2 | ||||
3 |
6 附件
更多测试资源(百度网盘):
https://pan.baidu.com/s/1Ypm8-VKuPurLtu0bCJovnA?pwd=5eji 提取码: 5eji