原文来源于：功能测试报告
自己编写于2019/02/14 20:11，先转移到“简书”。
本文基于《不会写测试报告，怎么从测试团队中脱颖而出》《功能测试报告的编写》，自我总结编写的。
什么是测试报告
1、说明：
是指把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。
ps.
【测试过程和测试结果的分析报告，以及上线许可】
【其实测试报告的内容基本都是模板的那些，只是在实际测试过程中，如何去整理内容结构，使得报告的通常阅读者：开发人员、测试经理、产品经理、项目负责人能够一目了然地查看想要了解的内容才是测试报告最值得注意的地方】
2、组成部分：
- 概述
- 测试范围
- 测试人员
- 测试进度
- 测试结果
- 缺陷分析
- 测试结论（简言之：是否允许上线）
功能测试报告基本信息如下：
1、引言部分
1.1、项目背景
本测试报告为xx系统测试报告，本报告目的在于总结测试阶段的测试过程及测试结果分析，描述系统是否达到需求的目的。
本报告预期参与人员包括测试人员、测试部门经理、项目管理人员、SQA人员和其他质量控制人员，开发，运维，产品。
ps.
测试部门经理：把控测试报告编写是否正确完整。
运维：根据测试结果来判断是否可以上线。
产品：测试范围是否覆盖整个需求。
pps.
测试计划：测试主管编写。
测试报告：测试人员编写（写的好不好，体现了自己的其中一项价值）。
1.2、参考资料
《需求说明书》
《原型图》
《缺陷记录》
《测试用例》
《测试计划》
等等（基本包含了软件开发生命周期阶段，所有的输出文档）
2、测试基本信息
2.1、测试范围
| 产品 | 模块 | 子模块 | 功能 | 测试点 | 优先级 | 测试工程师 |
|---|---|---|---|---|---|---|
| xx | xx | xx | xx | xx | xx | xx |
ps.
测试点：不等同于测试用例标题；
优先级：一定要熟悉需求，了解什么是核心、基本、次要；
测试范围（来源于 产品说明书、需求、邮件、销售、实施、客服......）
pps.
没有任何一个产品是100%没有bug的。
保证 不脱离需求，比较浅显的bug不出现。
偶然性的bug、深挖的bug不敢保证不会有。
2.2、测试案例设计思路
| 测试类型 | 测试用例设计方法及思路 |
|---|---|
| 功能测试 | 参考需求说明文档，使用等价类、边界值、场景法、错误推算法编写测试用例，并进行测试。 |
| UI测试 | 参考原型图，对页面文案、链接、图片图标等进行界面测试 |
| 兼容性测试 | 使用IE8,9,10，chrome，firefox等主流浏览器进行兼容性测试（根据浏览器的内核不同来区分） |
2.3、测试环境
- 硬件环境
- 软件环境
- 网络拓扑图
3、测试结果及缺陷分析【重点内容】
3.1、测试执行情况及记录
3.1.1、测试组织
| 项目经理 | 软件工程师（开发、运维） | 测试工程师 | 业务负责人（产品经理） |
|---|---|---|---|
| x | x | x | x |
- 软件/测试工程师：所有的开发/测试人员，哪怕只有一行代码的输出都要写上（线上有问题，需要参考这些人员）。
3.1.2、测试时间
| 测试阶段 | 计划开始时间 | 计划结束时间 | 实际开始时间 | 实际结束时间 | 计划工作量(人/天) | 实际工作量(人/天) |
|---|---|---|---|---|---|---|
| x | x | x | x | x | x | x |
- 来源于测试计划。 测试开始时间：提测开始。
- 功能测试、接口测试，测试报告需要分开写，此文只是功能测试报告。
3.1.3、冒烟情况
| 冒烟测试 | 时间 | 是否通过 | 如不通过，请写原因 |
|---|---|---|---|
| x | x | x | x |
- 提测之后，只要出现任何问题，都要提bug。
3.1.4、测试用例统计
| 案例总数 | 可执行个数 | 未执行个数 | 成功个数 | 失败个数 | 案例成功率 |
|---|---|---|---|---|---|
| x | x | x | x | x | x |
- 案例总数：用例的总数，所有人写的总数。
- 可执行的：
- 未执行的：测试环境接口不通。这情况很少。
- 案例成功率=成功个数/可执行个数。
3.2、缺陷的统计与分析
- 缺陷汇总：列出本次实际发现缺陷数、解决的缺陷数、残留的缺陷数（未解决缺陷）。
- 缺陷分析：对测试中发现的缺陷按缺陷类型、严重程度进行分类统计： 对测试中发现的缺陷就其功能分步、测试阶段进行统计，分析软件缺陷倾向及其主要原因。
- 残留缺陷与未解决问题 对残留缺陷对系统功能的影响情况进行分析：对未解决问题对项目的影响。
- 建议使用“bug状态统计”报表 分析bug。
3.2.1、缺陷汇总
｛饼状图，可来源于tapd｝
本次项目发现缺陷总数：X，解决的缺陷数：X，残留的缺陷数：X。
3.2.2、缺陷分析
3.2.2.1、按缺陷类型：
｛饼状图｝
该项目功能问题有x个，其次，页面优化有x个，安全相关、设计缺陷有x个，其他有x个。 大量的bug来源于功能模块，占比达到xx%，优化问题也有x个，达到xx%。
3.2.2.2、按严重程度：
｛饼状图｝
该项目的缺陷，大量的是属于一般缺陷，小部分属于优化缺陷，严重缺陷极少。
3.2.2.3、按功能分布：
｛饼状图｝
bug发生在x、x、x...模块居多，小部分发生在x，x，x模块
3.2.2.4、按测试阶段：
｛饼状图｝
冒烟测试V1.1，第一轮V1.1，第二轮V1.2，第三轮V1.3， bug大量的发生在V1.1，V1.2少部分，V1.3极少
4、测试结论与建议
4.1、风险分析及建议
风险： 测试环境接口不通，无法在测试环境测试 测试时间紧张 需求变更频繁 xx模块bug率较高
4.2、测试结论
本项目根据业务需求及开发人员，产品经理的反馈意见，覆盖了所有测试需求，所有的案例均已在xx测试环境验证完成。
有效案例一共xx个，执行率xx%，成功率xx%，缺陷关闭率为xx%，目前缺陷均已修复并回归关闭。
未解决的bug（延期处理、不予解决、暂不处理等等）已经和产品经理，开发工程师进行沟通，不影响本次上线的基本功能。
综上所述，xx项目，版本Vxx，达到xx项目测试上线标准，可以进行发布。
备注，需求不明确时：一定要去产品经理，把不懂的地方弄懂，把不准确的地方弄准确，不能带着不清不楚的地方执行测试，编写测试用例。
越总结越成长！
