最近小编负责测试的某个项目，出现了一个线上事故，令小编一度愤懑不已。
事情经过是这样的：
一个风和日丽的下午，小编正在愉快的溜娃。突然间在项目群里收到了一条boss发来的聊天记录，有个用户说他创建了多个不同的数据，结果使用数据时发现这些数据都一样。
小编赶紧抄起手机，一通操作，结果重现了用户的问题，当时一脸黑线，怎么会这样啊！！！
回归现实，将验证结果反馈到群里之后，开发同学开始各种排查，定位原因，最终发现是前端服务写的有问题，然后修改紧急上线。
事后复盘这次的事故原因：
首先，从bug本身上定位：前端服务收到用户创建的数据后，需要转给后端服务，传递过程中，需要传一组参数：参数1+参数2+参数3。对于同一个用户，在同一台设备上，参数1和参数2是相同的，参数3应该是创建数据的id，而前端开发写成了用户id。结果就是用户在同一台设备上不管创建多少数据，所传的参数都是完全一样的。然后就命中了后端服务的缓存，始终返回首次创建的数据。所以用户后来创建的数据，始终都无法生效。
其次，分析这个问题产生的原因：当时后端服务开发增加了上面的缓存逻辑，需要前端开发配合在传数据时带上一组数据（即参数1+参数2+参数3），两人随口一说，就把这事敲定了，参数1和参数2双方理解的没问题，而参数3则出现了上面的差异。然后……然后……然后……没提测就上线了！
复盘过程走到这一步，小编终于松了一口气，这锅不用背了~但一瞬间之后，作为一个测试的正（ze）义（ren）感突然爆棚。项目组是一个整体，一损俱损，一荣俱荣，产品挂了，项目垮了，所有人都会是受害者，测试也不例外，谁不希望做一个完美的产品呢？所以我们怎么能就这样置身事外呢？
想到这里，我随即给自己提了两个问题：
第一、如果这事儿提测，我们能不能覆盖到？
第二、从这次复盘的结果看，作为测试，我们真的就不能做点什么？
第一个问题很好回答，简单思考了一下，就用了答案：能够覆盖。
原因：提测必有需求（没需求测试怎么能接受呢），需求必说用户数据和缓存，验证走不走缓存一定会创建多个不同的数据，那么这个bug肯定跑不了。
那么第二个问题呢？我想，我们可以从以下几点来做些事情：
第一，提前了解产品的未来需求，掌握后续的工作安排。
作为测试，我们有必要了解产品的发展规划，也需要让产品和开发提供短期内的明确计划和工作安排，比如按月提供将要上线的需求和大致提测时间。这样一方面可以提前布局调整团队结构，另一方面也有助于协调人力排期（涉及多项目并行的测试团队，这点尤为重要），同时也可以侧面监督产品的需变和开发的提测。（注：本次的事故，如果有这个流程，那么开发没提测这件事，我们就能提前知晓）
第二，协助建立项目组的需求流程。
项目组的需求流程，测试同学应该是全程参与的，因此这部分流程是否完善直接影响到测试的工作，这中间也需要我们提出我们的需求，例如不同侧的需求该如何阐述？需求文档的要求都有什么？开发、测试介入的时机等等，当然最重要的就是：形成结论后一定要，公示！公示！！公示！！！
第三，建立项目组的提测流程。
建立提测流程测试一定是主要发起者，因为对我们的影响是非常直接的，如果提测这块做不好，介入测试后，处处是坎儿。
这块我们要提出明确的要求，明确哪些任务必须提测？提测必须通过邮件公示，以及公示时需要提供的信息，例如需求文档、协议说明、测试版本、测试工具等等。
尤其有必要加入开发自测流程，或者产品体验流程，自测或产品体验过之后，才能正式提测，即避免出现阻塞性bug，又避免开发实现与产品预期不一致，这些都可能导致测试进展受阻或重复的工作量，从而影响项目的进度。
当然自测case可以由测试提供，第三方的监督效果才最好。
再次回想这次的事故，其实如果我们把2的流程建立好，就足以将这个bug暴露并解决掉了。所以真正建立好一套流程，是能够把相当一部分的bug，杀死在无形当中，这样才是一种对项目负责的态度，对吧。