如何写好年终总结？

前面有读者留言问年终总结要怎么写，我一听你要聊这个我可不困了，这活我熟啊，谁不知道我厂是 PPT 之王。先来一套打法闭环方法论，再来一套赋能抓手组合拳，如此这般，便可笑傲于江湖。

玩笑归玩笑，年终总结不单只是一份文档，也是展现自己的一次机会，写好年终总结的确是很重要的事情，我们还是需要认真对待。一般的总结框架会包含这三个部分：今年的工作回顾、个人成长和收获以及明年的规划。为方便理解，我以一个反面实例的方式来具体讲解。

工作回顾

1. 完成了 100 个需求的测试，所有需求高质量发布。

2. 编写了 500 个测试用例，全部录入到用例库。

3. 维护 50 个自动化测试用例。

4. 优化了现有自动化测试脚本，提升了效率。

5. 调研“IronMan”接口测试系统。

6. 写了一份关于 Appium 使用的文档。

7. 处理线上缺陷，帮助客户解决问题。

8. 积极与开发沟通，帮助开发定位缺陷。

9. 积极与产品沟通，帮助产品找出文档中的不足。

个人成长

1. 自学了 Python。

2. 看了五十本书。

明年规划

保证某某业务的高质量。
学习 React 框架。

大伙可以先想想这份总结写得好不好，存在哪些问题。这其实是一份很典型的总结，这些内容我全部见过，每一条出现的频率都很高，当然其中的糟点也很多，我们不妨挨个来看它的问题在哪里。

1）缺乏重心，目标不明确。这个问题极其常见。很多人在写总结的时候，希望能够尽可能地展现自己的工作，于是事无巨细地把所有内容都往里写。殊不知这么做只会起到反效果，看似洋洋洒洒，实则不明所以，看起来什么都做了，却又找不到亮点。

我们在组织内容的过程中，一定要先做个换位思考。对于上级主管而言，他更关心的是今年定的目标完成得如何，有没有不及预期或超出预期的地方。因此我们要围绕目标去展开自己的工作描写，而非“自说自话”、“你打你的，我打我的”。

2）没有体现自己的过程思考。虽然绩效最终看的还是结果，但最好也要简要描述自己分析和解决问题的过程，这其中体现的是自己的思考能力。拿到结果的因素有很多，可能是个人努力的结果，也可能只是偶然，所以需要对过程也有一定的解释。

3）用词虚化，不够直观。比如“所有需求高质量发布”，那么什么算是“高质量”？类似的还有“提升了效率”，又是怎么个提升法？我们要尽量避免这种宽泛的表述，而采用更具象的说法。比如“所有需求高质量发布”改成“所有需求发布之后均未产生 P0/P1 级的线上问题，整体质量较高”。

4）把基本工作作为成果。日常的、惯例的、基础的工作不应该出现在总结里。例如“与开发沟通”和“与产品沟通”，这是一个测试最基本的工作内容，写到总结里反而会让主管觉得我们是在勉强凑数。这点与为什么不要把“掌握 Office 办公软件”写在简历里是一个道理。

5）个人成长与岗位无关。企业不是学校，我们的价值是为企业创造效益，对于个人成长也是一样，重要的是我们的成长能够为团队带来什么增值利益。因此诸如“学习了某某知识”并没有什么意义，可以改成“通过学习 Python，我已能够在工作中编写自动化脚本，减少数据准备时间”。

6）未来规划没有突破点。我们在写未来规划的时候，喜欢使用“继续保证某某业务质量”这样的描述（一定程度上也是因为缺少想法），这也是一个不好的习惯。为什么要写未来规划？因为团队对个人的期望是能够超越自我，不断成长。所以未来规划的重点是描述我们将来在哪方面希望取得更大的突破。

通过这些反例，我们大体可以知道要写好一份总结，需要具备这些条件：目标清晰、重点明确；既有过程，又有结果；成果确切，可量化、可衡量；个人成长明显，能够学以致用，可塑性强；未来规划清晰，不满足于现状，潜力较高。

按这个思路，我们把之前的总结重写一遍（注意并没有新增成果，只是重整）：

工作回顾

关键目标一：进一步提升某某业务的质量

过程：通过对线上缺陷数据的分析，得知某某业务的质量问题主要由以下问题导致（解释做这些事情的原因）。

1）现有测试用例库覆盖率严重不足，回归测试遗漏风险大。

2）集成测试阶段由于缺陷修复引入新的缺陷问题较多，人力无法保障频繁回归。

因此我在今年针对这两个问题主要做了以下工作。首先对用例库的常见用例做了补充和完善，其次对核心用例添加自动化测试用以在集成阶段进行回归（解决方案是什么）。

结果：总共新增了 500 个有效的测试用例，完整覆盖用例库 P0/P1/P2 级别的全部用例。其中的 P0/P1 级别用例自动化覆盖率达到 95%，共有 50 个自动化用例在有效执行。今年全年某某业务线上缺陷数由 100 个/月下降到 30 个/月（成果量化体现），效果显著。

关键目标二：提高测试团队的发布效率

过程：经过前期的调研，发现了旧有的自动化脚本中，存在大量无效的等待时间，导致发布前的自动化执行时间过长。此外，由于我们的自动化用例数过多，依次排队等待也会造成运行瓶颈。

结果：今年下半年，我完整扫描了现有的自动化用例脚本，去掉不必要的 sleep 等待，或改成显性等待方式，优化之后单次执行时间由 2 小时下降为 1.5 小时，效率提升 25%。之后又改造了现有的自动化框架，使其支持并发模式，当前的执行时间进一步下降到 30 分钟。

关键目标三：调研接口测试工具并落地

过程：今年 6 月份，我总共调研了多个接口测试工具，包括 PostMan、Jmeter、IronMan 等（调研类工作需要有对比分析）。我们团队规模有 50 个人，对接口测试工具的诉求包括实时使用、在线协同、稳定易维护、支持自动化等。因此我最终选取了 IronMan（瞎编的名字，不打广告别搜了）做为我们团队的接口测试工具，并在 7 月份做了团队内部推行和试运行。

结果：当前我们团队已 100% 采用新系统进行我们的接口测试工作，系统上已有 300 个接口用例在稳定维护和运行，自动化测试次数超过 1000 次，发现超过 100 个问题（调研也要有结果变现）。

个人成长

今年我通过自学掌握了 Python 的使用，并成功运行到我的日常工作中。例如通过 Python 来生成某某业务的测试数据（讲明学习与工作的关系），使之前需要 2 小时的数据准备工作缩减到 5 分钟，希望将来能够发掘更多的使用场景。

并且今年我还完成了五十本书籍的阅读，包括大数据分析、性能测试基础、稳定性体系建设等，让我对测试体系有了更多的理解。在团队内部我也进行了 3 次相关的技术分享（对团队有输出），帮助团队一起成长。

明年规划

明年我希望能够掌握 React 的使用，对自己在这方面技术掌握的空白实现零的突破（未来规范的核心是对自己提更高的要求）。一方面是更多地了解我们公司使用的前端技术，帮助自己在定位前端问题时能够更加准确和深入；另一方面是可以帮助我们团队研发自己的测试系统平台，对现有分散的各个工具进行集成，进一步提升我们的工作自动化程度。

下面是你需要的资料吗！

↓↓