测试人员在完成一项测试项目以后，最应该做的就是去编写测试总结报告，这样有利于寻找自己的不足，同时在下一次测试的过程中能更快的找到自己对测试的认识，在测试完成-测试总结-测试继续-测试完成-测试总结，这样一个循环的过程中，才能不断的成长和完善自己的不足。也就是我们简单的说 执行-总结-反思-执行-总结-反思......无限循环的过程中，才能让自己不停的往前推进，不然只是流水线似的的工作，每到年底总结感觉自己又过去了一年，撒变化都没有，也不知道自己有哪些进步，但是却在一步一步的忧虑中，又长了一岁...离35岁又进了一步。
一、测试报告与测试总结的区别？
一直纠结到底什么是测试报告和测试总结，一度把他们混为一谈了，总想去总结点撒，但是每次一去总结的时候，发现哪里不对。
测试报告：把测试的过程和结果写成文档，并对发现的问题和缺陷进行分析，为纠正软件存在的质量问题提供依据，同时为软件验收和交付打下基础。一份详细的测试报告包含足够的信息，包括产品质量和测试过程的评价，测试报告基于测试中的数据采集及对最终测试结果的分析。测试报告仅仅是测试总结的一部分，是对测试过程的描述和测试结果信息的汇总，并根据过程数据做分析给出测试结论评估。
测试总结：测试总结的是问题，是风险，是经验，是如何改进，是分析测试过程中的问题，并针对项目进行分析从而找出解决方案。也可以说用于分析并总结这些缺陷，将总结出来的经验用于指导下一次的测试用例设计。在每个版本测试完毕后，要进行测试总结，做一些比例的总结、缺陷严重级别及比例的总结，人员工作效率的总结，还有最重要的是风险的平复，对下一测试版本的建议等。
我所理解的测试报告是对外的，需要正式提交的一份文档，它是一份有规则、有结构的正式文档，需要涵盖我们的目的、背景、测试概要（测试环境和配置、测试方法和工作、测试概要分析表）、各模块的完整测试情况（功能测试、性能测试、可靠性测试、兼容性测试、安全性测试、易用性测试、兼容性测试）。
请参考博文：https://www.cnblogs.com/wendyw/p/13375975.html
而所谓的测试总结是对内的，对我们内部在自己测试过程中的问题、难点进行整理以吸取教训和经验，在下一次测试开始前能更好的进行改进的一个反思的过程。它所涵盖的应该是一些分析数据，比如测试用例分析、缺陷分析、质量优势、质量问题总结。
二、测试总结思路
大纲：引言+测试概要+测试结果及缺陷分析+测试结论及建议
- 1.引言
- 2.测试概要
- 3.测试结果及缺陷分析（核心）
- 4.测试结论及建议
做任何测试总结，我们处于互联网行业，一定首先要想到的是如何使用工具来帮助我们达到目的，而不是通过人工去实现。我们目前通过使用工具EXCEL工具的宏功能和结合禅道测试-BUG、用例，进行定制编写相应的代码，进行定制化缺陷分析。
1.测试结果及缺陷分析结果工具：分析工具+数据来源【Excdel宏功能+禅道-测试-对应项目导出来的数据】。
2.测试用例结果分析展示数据：测试用例的开始测试时间、计划完成时间、计划进度、实际进度、通过率、测试状态、测试用例总数、测试用例的通过、失败、阻塞、未执行、延期、无效。
在测试用例分析的时候，涉及到的几个公式：
- 通过率=通过/(通过+失败)；
- 测试状态：实际进度VS计划进度；
- 实际进度=(通过+失败)/(通过+失败+阻塞+未执行)
3.BUG结果分析展示数据：总的用例BUG-统计与分析、BUG趋势、BUG-遗留-严重程度和优先级、BUG-遗留-开发-严重程度和优先级、BUG-遗留-类型分布、开发分布、激活天数、BUG-本周创建-严重程度、BUG-本周关闭、BUG-累计情况-严重程度-状态。
具体实例，根据某个项目进行详细分析。
三、测试总结
测试总结
1引言
1.1编写目的
本测试总结了具体编写目的，指出预期的读者范围。
本测试总结为XXX项目的测试总结，目的在于总结测试阶段的测试及分析测试结果，描述系统是否符合需求（或达到XX功能目标）。预期参考人员包括用户、测试人员、开发人员、项目管理者、其他质量管理人员和需要阅读本总结的高层经理。
1.2项目背景
对项目目标和目的进行简要说明。
1.3系统简介
设计说明书中必要的框架图和网络拓扑图。
1.4术语和缩写词
1.5参考资料
2测试概要
包括测试的一些声明、测试范围、测试目的等，主要是测试情况简介。
2.1测试用例设计
2.2测试环境和配置
2.3测试方法和工具
3测试结果及缺陷分析
汇总各种数据并进行度量，度量包括对测试过程的度量和能力评估、对软件产品的质量度量和产品评估。
3.1测试用例分析
需求覆盖：
需求覆盖是指经过测试的需求/功能和需求规格说明书中所有需求/功能的比值，通过情况下要达到100%的目标。
- 需求/功能（或编号）：需求覆盖率=(Y项数量/需求总数)*100%
- 已覆盖需求数量
- 未覆盖需求数量
- 测试类型
- 是否通过：[Y][N][P][N/A],P表示部分通过，Y表示通过，N表示不通过，N/A表示不可测试或者用例不适用。
测试覆盖：
- 需求/功能（或编号）：测试覆盖率=(执行数/用例总数)*100%
- 用例个数
- 执行总数
- 未执行
- 未/漏测分析和原因
3.2缺陷分析与统计
- 缺陷发现效率=缺陷总数(bug)/执行测试用时
- 用例质量=(缺陷总数bug/测试用例总数)*100%
- 缺陷密度=缺陷总数/功能点总数
缺陷密度：系统各功能或各需求的缺陷分析情况，开发人员可以在此分析基础上得出哪部分功能/需求缺陷最多，从而在今后开发中注意避免并在实施时予以关注，测试经验表明，测试缺陷越多的部分隐藏的缺陷也越多。
3.2.1BUG趋势
BUG趋势图预期结果展示：
- 各严重程度累计趋势图：
- 各曲线应呈缓慢增长趋势。
- 严重程度1的曲线应处于其他严重程度之下（少于其他严重程度）。
- 累计总数趋势图：应呈缓慢增长趋势。
- 累计遗留趋势图：前期应呈平缓趋势，后期应呈下降趋势且最后归于0
- 当期新增趋势图：前期应呈平缓趋势，后期应呈下降趋势且最后归于0
- 当期关闭趋势图：前期应呈平缓趋势，后期应呈下降趋势
BUG趋势图实际结果展示，若与预期不一致，解释原因，比如：
- 大多数功能提测时间集中，未细分阶段进行提测
- 某模块开发质量差
- 开发未及时修复BUG
- 需求变更未评审导致开发未按变更后需求实现
3.2.2BUG遗留
缺陷趋势分析是缺陷的纵向分析，在时间上对缺陷进行分析，有助于进度控制和测试过程的管理。
缺陷趋势分析是考察缺陷随时间变化的趋势，如将各种状态（活动的、修正的、关闭的）的缺陷计数作为时间的函数来显示，缺陷趋势分析报告可以是实时的(如每日缺陷数、每周缺陷数随时间的变化曲线)，也可以是累计的（如新报告的缺陷累计数和关闭的缺陷累计数比较曲线）
缺陷趋势预期：
生命周期的初期，缺陷增长率高。在达到顶峰后，缺陷会随时间以较低的速率下降。可以根据这一趋势付复审项目时间表来检查进展情况。
激活状态BUG - 严重程度与优先级：
- 严重程度与优先级为1的遗留数量：应为0
- 严重程度与优先级为2的遗留数量：应为0
- 严重程度与优先级为3和4遗留数量：应为0
遗留数量 > 0原因：
延期修复BUG - 严重程度与优先级：
- 延期的严重程度与优先级为1的遗留数量：应为0
- 延期的严重程度与优先级为2的遗留数量：应为0
- 延期的严重程度与优先级为3和4遗留数量：应该控制在阈值范围以内
1和2延期数量 > 0 原因：
3和4延期数量 > threshold原因：
3.2.3BUG累计情况 – 严重程度
模块VS严重程度（分析BUG数量TOP2的模块）
各程度占比（分析严重程度为1和2过多的原因）
3.2.4BUG累计情况 – 类型分布
BUG产生原因分析：分析数量TOP2的类型
3.2.5BUG累计情况 – 解决方案
BUG解决方案分析：分析无效BUG数量过多的原因（已解决、延期处理为有效BUG）
3.2.6BUG累计情况 – 激活次数
BUG激活次数：分析各位开发人员解决BUG的效率及质量
3.2.7BUG累计情况 – 由谁产生
BUG由谁产生：BUG制造者分布
3.2.8BUG累计情况 – 发现阶段
BUG发现阶段：应 组件测试 > 集成测试 > 系统测试 > 验收测试 > 试运行
分析验收测试、试运行BUG过多原因
3.2.9BUG累计情况 – 由谁发现
BUG由谁发现：分析测试效率、质量
3.2.10BUG累计情况 – 由谁发现
BUG由谁发现：分析测试效率、质量
4测试结论与建议
对过程、缺陷分析之后下结论。
4.1测试结论
- 测试执行是否充分
- 对测试风险的控制措施和成效
- 测试目标是否完成
- 测试是否通过
- 是否可以进入下一阶段项目目标
4.2测试建议
- 对系统存在问题的说明，描述测试所揭露的软件缺陷和不足，以及可能给软件实施和运行带来的影响
- 可能存在的潜在缺陷和后续工作
- 对缺陷修改和产品设计的建议
- 对过程改进方面的建议
4.3测试优化
优化：根据项目实施过程中的问题做总结分析，针对问题找到解决方法，进而改进项目实施中的缺陷，提升项目实施质量。按照软件生命周期分为3类：最终产品质量度量、过程中质量度量、维护质量度量。
（1）产品质量度量：缺陷密度、用户报告的问题和用户满意度等。
（2）过程中质量度量：测试进度偏差、案例执行率、测试案例有效性、测试案例覆盖率、基于轮次的缺陷发现率等。
（3）维护质量度量：逃逸缺陷密度、修复响应时间、逾期修复百分数和有效缺陷修复率等。
如果有更好的想法，欢迎大家留言讨论，本文只代表个人的不成熟想法，请指教！