线上事故的善后——事故通告

在我们的日常工作中，出现线上事故是难免的，而作为项目最后一环的测试，往往首当其冲：“测试怎么没测出来？”是人们首先想到的。于是出于这种先入为主的想法，测试往往会承担过量的责任。而作为测试人员，却往往下意识的保护自己 精力大部分放到开脱自己的责任上，事故的善后做的不够好、不专业。

其实在遇到事故的时候，要及时做总结和通告，把事故最真实客观的情况、每个角色在这个事故中的责任、事故的解决方案以及后续工作的改进方案呈现给所有人，这样才是正确的做法。

那么如何进行事故通告呢？

1、通告公示的使用范围

只要认为是线上事故，建议都要进行通告公示

2、通告公示的时机

出现线上事故后，当然解决事故是最优先的，在不影响解决进度的情况下，测试要进行事故原因的了解与分析，包括开发代码原因和测试漏测原因，并在第一时间进行公示。

3、通告公示的形式

建议以邮件形式给出，发给所有相关人员，包括产品、开发、测试，如有需要可抄送上级领导。

4、通告公示的内容

a.事故描述

主要就是描述问题现象，和对用户的影响

b.漏测原因分析

主要是从测试角度，为什么没测试出来，需要把所有的已知情况列出来

注意事项：

1) 语言简练精准，没有歧义异议

2) 一定要站在整个项目的立场高度上，进行客观、公正的描述，切忌总是描述产品和开发的问题、而弱化测试自身原因。

3) 建议把测试自身的责任放到最前面，后面再写其他方的问题

4) 要注意措辞，不要给人推卸责任的感觉，如有必要可以把话说圆滑一些；有可能引起反感或歧义的内容一定不要出现，不要让它成为相关责任人的“口水战场”，否则就失去了通告的意义。

c.问题原因分析

从功能逻辑或从代码角度，阐述问题出在哪里，一般是和开发沟通得到的。

d.测试改进措施

很多人尤其是上层领导，关注点不在于到底是谁的责任，而是以后如何避免类似问题再次出现，所以改进措施才是整个事故通告的重点。该处就是从测试角度说明，我们需要对以后的工作做哪些优化处理，并于什么时间前完成。

注意事项：

1) 要和上面的测试遗漏原因挂钩，尽量做到所有问题都有解决办法。

2) 所有的改进措施，都需要是切切实实的有可执行性的内容，像“增强随机测试力度”“以后测试时会更加细心”，这些都是没有可操作性的、类似表决心的描述，意义不大。拿“增强随机测试力度”举例，正确的描述应该是通过哪些工作来进行增强随机测试能力和力度、达到什么样的水平，什么时候实施和完成等等。

3) 改进措施给人的感觉应该是，我们在通盘思考整个事故之后、对于未来工作的改进；哪怕考虑了很多改进方案，结果都因为各种原因无法实施，那么也要写进去，并且写明为什么无法实施，给人积极解决问题的感觉。

e.问题修复方案

就是当前该问题如何解决，具体方案是什么，什么时候完成。

相信以上这些内容如实展现给相关人员后，就能够把事故的影响降到最低，并且让后续测试工作有了更多的工作方向和思路，避免事故的再次发生。

原文链接

如需转载该篇文章，请注明来自“搜狗测试”