带你全流程，全方位的了解属于测试的软件事故

    事故？车祸？是的，没错从国家事故的定义是：一般是指当事人违反法律法规或由疏忽失误造成的意外死亡、疾病、伤害、损坏或者其他严重损失的情况，车祸就是里面的一种。但今年我说的不是这种，我说的是软件事故，那软件事故是什么？有的人，可能不大了解，那我说下软件事故是一个计算机专业名词，定义是这么讲的：软件出错造成不可恢复的系统故障。不可恢复？这个好像有点矛盾啊，特别是我们对发出去的功能，比如优惠券，出现Bug，可以被薅羊毛，那通过代码修复，那还叫不可恢复吗？好像不是，我就简单的进行了自我进行微观的定义了下，有两个：1.因个人操作失误或者个人原因造成的软件功能异常，造成公司财产损失或者用户流失等问题；2.因客观原因，如服务器突然损坏，停电等原因，造成软件无法使用或者异常，造成公司财产损失或者用户流失等问题;那我本次讨论的是1，由主观造成的。

目前大家熟悉的事故有哪些呢，比如有王者荣耀test邮件事件，携程瘫痪门事件，拼多多优惠券BUG事件等等，具体你们百度下，就都了解。

可能大家会一看或想，这难道测试的锅？别激动，不是也不一定是，项目是一个团队，你是团队的一份子，不是你的锅，我们也要提前做个预防是不？墨菲定律，该发生的总会发生，也许哪一天就轮到测试的身上了呢？我只是大概提前带大家了解下，管理一个测试团队的时候，对于事故我们可能可以怎么做？毕竟这个大家还是比较陌生的。

我大概整理了下，大概涉及到软件测试事故的框架如下：

对于测试事故的类型一般就两种，一个是测试环境的配置错误，造成的影响；第二个就是关于功能没有测试到造成的影响；其中对于测试过程中环境中的配置错误，如推送功能等，一旦出现问题就会造成很大影响，我个人认为环境的操作错误的严重程度大部分是远远大于功能问题，所以大家这个一定要非常注意；

对于时间轴，我们主要分为事故预防，事故发生时以及事故发生后，这个三个过程，我们按照发生时，发生后，发生预防，也就是我们首次遇到的流程来说。对于发生时，当事人一个了解过程的情况，以及即时汇报到直接主管报备，如果有经验的直接就按照事故发生的时的流程走就行，这个过程，要求的是汇报信息需要尽量详细，主管要主动跟踪以及汇报；发生后，对事故的进行复盘，然后做下总结以及预防，记得这个过程最怕的是，结束以后，大家都把要做的事列了，最后其实没有执行到位，这个很重要的是要执行到位，跟踪到位，至于事故责任担责就看公司是如何处理了；对于预防，有三个方面吧，第一个要做好员工入职的一些操作事项和测试注意事项以及承担的责任，这些写好了，入职以后，要对员工进行考察下，避免成为一个形式；第二个，要每个季度组织去重新温习，避免忘了；第三要制定事故的处理流程，汇报流程；


事故的奖惩制度，这个啊，可以说啊，最好不要发生事故，为啥，因为发生事故了说明不是好事了，肯定公司的boss也知道了，这不仅个人要担责，其实整体的领导都得有连带责任了，对于事故的等级，大事故基本可以直接判定了，对于模糊的地方，就可能需要有规则来原则来判定，我建议，除了环境操作配置问题，对于功能性可以从问题出现的主观性（如疏忽，有规则不看等），严重程度，影响用户程度，公司带来的损失来通过管理会议大多数统一的方式进行定义，分别标准1,2,3等级，然后相应的惩罚也跟这些级别挂钩，惩罚其实最重的就是走人，接下来可能就是绩效没有了，加薪没了，年终没了，晋升没希望了，年底绩效最低等等，具体的规则根据你们领导还有公司进行制定。


以上，是我简单的对于测试事故的看法以及做法，希望对大家这方面的知识有所帮助，喜欢的就帮忙点赞，分享。如果对本订阅号相关测试资料的视频感兴趣，可以在Dou音上搜索“测试一般不一般”，查看相关视频,也可以关注V订阅号：测试一般不一般。