一个测试工程师的项目总结笔记（附总结模板）

题记：职场的复盘会议上，有些人可以借助会议平步青云 ，被上司默定为晋升候选人；而有些人任劳任怨，加班加点，即使附上自己一年的考勤记录表，仍无人问津。测试人员也迎来了前所未有的大批裁员时期，无论是缩减成本，还是组织架构调整，都取决于我们的核心竞争力以及自身价值。

那么测试人员的复盘会议上，如何展现自身能力又让大家认可且有助于人呢，奉上一份资深测试工程师的改善型总结~~

《XXX项目改善型总结》

工作汇报评价表

列出制定测试计划时，所有要达成的目标； 并附上目标达成情况。除非必要情况下，目标未达成先找自身原因（如因外部调整原因除外）。尤其是正式的复盘会议上，参会人员可能是项目组全员。更需要聚焦于如何改善或达成措施，而非寻找原因，更忌相互推诿。

评价项可以依项目特征与团队要求来灵活调整，下图是某个项目初期的评价项（当时测试团队还未完全组建起来），可供参考：

评价内容可以根据项目中的每个阶段中的情况来编写 ，不要局限于测试阶段，建议从需求评审开始直到上线后的测试跟踪。展示出整个项目中我们超出预期目标的部分，不足项，获取的成就，深层次分析（如，造成测试时间不足的根本原因，在测试阶段中退回的原因，版本控制等等），下一目标要怎样达成。其中，这里的深层次分析与改善措施作为附表形式展开，就不在工作汇报评价表中说明了。备注中的内容也会分开阐述，不同项目可以灵活调整方式。

下图为前期工作汇报评价表的示例：

深层次原因

这里的深层次原因分析主要集中在缺陷状态分析上，故其他方面暂不作展示。

首先，缺陷报告与用例设计均为一个专业测试人员应该具备的基本职业技能，所以缺陷报告的好坏优劣也直接反映测试人员的专业水准。是否熟悉这样的情形：汇报工作时直接报告缺陷数量，领导问及缺陷具体情况时却无法回答，当前急需解决的问题自己也不清晰，或者直接是只提Bug，不及时交流，问题等到开发人员修复后回归，这是测试人员的被动工作状态。所以主动出击，找到深层次的原因，助己助人，也是与初级测试人员拉开距离的一个首要条件。

《缺陷分析》中不局限于任何形式，可以按照前端、后端，也可以按照项目流程来划分，每个阶段遇到多少个问题，要如何改善，之后如何避免，如需求分析阶段静态测试遇到的问题，评审时遇到的问题，作为测试人员解决了哪些问题，还可以从另一个维度 ，如共性问题，非典型问题，用户体验，阻塞问题等等。

其中共性问题还可以细分：

【SessionID失效问题汇总】

【加载出渲染页面问题】

【账户权限数据问题汇总】

【浏览器返回按钮问题汇总】

【重复操作问题】

【基础平台】

【字段超长问题】

【约束条件&校验】

【表单提交判断问题】

【需求】

【特殊字符问题】

后端问题也可以细分为接口、数据库、版本构建、算法等。

PS：缺陷分析如果在报告阶段已经形成明确的流程，可以利用缺陷管理工具中的统计或报表功能来导出相关数据，无需人工一一校对。

改善措施

因测试团队初建，这里直接用于维护测试流程了，也是针对此次项目中的不足与成就来综合评估。

这样整个复盘会议上，一用来做工作汇报评价表，查看目标达成与简要分析，一目了然。二分析项目缺陷，按整个项目流程划分，既展示自己的完全参与度，在一定程度上也帮助各个阶段的项目成员作出了缺陷分析的一个简易型报表，让大家看到哪个地方产出的问题最多，如何规避，又在哪些地方浪费了时间与精力，哪些地方造成重复工作，这样做的目的除了可以清楚的用数据来说话外，也切实帮助了开发人员从整体质量上看待整个产品，而不是过于零散地头痛医头，一直局限于自己的模块内。前两个部分做完了整体比较与原因分析，接下来就是改善措施了，直接用来优化测试流程或是项目工作流程，形成一个闭环思维。那么下个项目中既可以采用优化后的流程，还可以避免这次中踩过的坑。

与单纯地汇报本次项目中产生了XXX个缺陷，测试了XXX轮，来得更实在，也更有价值。毕竟我们是站在整体项目的角度来考虑问题，至少方向一定是正确的。（#软件测试#更多详情请关注“木蚂蚁”公众号了解）

欢迎各位同行分享讨论更多自己复盘会议上的亮点与建议~~~学无止境~~

***相关文章推荐***

测试人员必知的软件测试文档有哪些

事务跟踪工具JIRA的基本使用

关于编写缺陷报告的几点建议

测试人员基本功之一：报告Bug技巧 

测试过程文档模板整理(一)-提测流程

初升测试管理岗，我是这样制订测试计划的