测试基础08:测试文档的编写(测试计划方案用例报告)
测试计划、测试方案、测试用例、测试报告模板
测试大纲

一、测试计划
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
魔乐社区(Modelers.cn) 是一个中立、公益的人工智能社区,提供人工智能工具、模型、数据的托管、展示与应用协同服务,为人工智能开发及爱好者搭建开放的学习交流平台。社区通过理事会方式运作,由全产业链共同建设、共同运营、共同享有,推动国产AI生态繁荣发展。
更多推荐

所有评论(0)