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

　　语音内容：

　　在我们的日常工作中，出现线上事故是难免的，而作为项目最后一环的测试，往往首当其冲："测试怎么没测出来？"是人们首先想到的。于是出于这种先入为主的想法，测试往往会承担过量的责任。而作为测试人员，却往往下意识的保护自己，精力大部分放到开脱自己的责任上，事故的善后做的不够好、不专业。其实在遇到事故的时候，要及时做总结和通告，把事故最真实客观的情况、每个角色在这个事故中的责任、事故的解决方案以及后续工作的改进方案呈现给所有人，这样才是正确的做法。那么如何进行事故通告呢？回复关键词"通告"，即可看到一篇相关文章！

　　文字内容：

　　如何进行事故通告？

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

　　2、通告公示的时机

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

　　3、通告公示的形式

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

　　4、通告公示的内容

　　a.事故描述

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

　　b.漏测原因分析

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

　　注意事项：

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

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

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

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

　　c.问题原因分析

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

　　d.测试改进措施

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

　　注意事项：

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

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

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

　　e.问题修复方案

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

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