项目结束之后，我们经常需要组织召开复盘会议，很多同学一听到复盘会议就会紧张，好像按照他们的理解，复盘会议就是为了追责，就会十分恐惧。
实际上，复盘会议并不是狭义的如此，复盘其实是为了大家一起交流，互相学习，对于做的不好的地方及时改进。简单拿我们的一个复盘过程举例。
过程回顾
本轮测试7天时间，共计XX个Bug，其中XX个Bug为功能Bug已修复，XX个Bug为UI Bug已修复，XX个Bug遗留（XX个Bug产品经理给出具体方案后续优化，XX个为浏览器机制产生的一直存在，前端也一直未给出相应的解决）。
XX个界面优化用户体验性问题。
测试过程出现中的问题
Bug回归不及时，导致问题修改周期长。
版本中合入其他版本修复的部分问题，代码合并部分引入部分风险，主要有：
版本的稳定性有一定影响性；
合入部分的代码会存在没有相应的需求和影响范围分析性数据，这样会给测试带来部分漏测的风险。
组内讨论，交流经验
本次版本测试过程中印象深刻Bug（Bug修改反复打开，Bug比较典型可能换个版本还是会出现，Bug暴露背后的开发思维）。
分享找到这个Bug的方法（是如何找到这个Bug的，核对原型发现、执行用例发现、交叉验证发现）。
如何跟进解决（问题提出、问题分析、问题修复之后的验证，有没有结合自己的看法）。
开会讨论，打开系统具体Bug查看交流记录。
解决方案
每一轮测试之前，需要先验证上一轮测试中是否有未回归的Bug，对于未修复的Bug尤其是严重级别的Bug（或者造成阻塞的Bug），需要及时通知开发leader。
对于合入代码部分，尽量在迭代测试中建议开发人员减少合入与本次迭代无关的代码的活动，如果有合入的必要，建议最好有一份所涉及的影响范围的文档说明，这样也一定程度上避免掉漏测的风险。
以上就是一个简单的例子，有分析、有建议、有结果，这样才能共同进步。
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
