背景介绍
我们现在做的是一个维护旧系统的工作，但每次因为修一些bug上线后都会导致production issue频繁发生，看到这你可能会鄙视认为就维护一个旧系统，修修补补bug都能引入线上问题，这样的测试水平也太值得怀疑了吧，是的，作为一名专业的软件测试人员，遇到这种情况实在尴尬无比。
虽然每次production issue发生后我都会反思这个bug在测试阶段为什么没有被发现，要怎样完善测试策略去避免以后类似事件的发生，但往往每次问题发生的原因都不尽相同，而且后知后觉。
几个案例
UX的一句话引发的血案：
页面上有个table， table中某一column的值显示为0，新换的UX说0对用户不友好，我们需要把这个字段改成N/A，想着这也没什么复杂的，于是dev就改了，作为QA这么简单的也没什么其它它过多的test scenario要考虑的，于是就这样上线了。上线后user报table中页面上其它column的值更改后保存会报错说数据格式不符合，console里提示只支持number类型的。经调查发现，虽然只修改了一个看似无关的字段，但在保存table中别的值时请求里对这个地方的数据也进行了校验。因为这个字段由之前的0改成了非number类型N/A，所以导致验证不过。-
未能使用真实的测试数据引入的锅
我们系统里有两部分的数据，一部分从其它系统migrate过来的，一部分是在自己系统create的，但从其它系统migrate过来的数据最终会和在自己系统创建的数据一起维护在同一张表中，结构大概如下：
image.png
从其它系统migrate过来的数据先会进到migrated-data中，再通过进一步解析存到data store json，而从当前系统直接created的数据会以同样的格式直接进入data store json中。
那么问题来了，这些数据中有两个别的字段需要被下游服务用到，dev直接给下游取字段的服务加了这两个字段名，但改的是从 data store json中取值的那条路径。测试时因为被告知就把data store json中这两个字段新加到下游服务中，想想又是一极其简单的改动，只用确认这两个字段格式在各种正常和异常情况下都能被正确处理并且成功进入下游系统不就完了。果不其然，没那么简单，上线后发现生产环境这两个字段并没有被读进去，调查后发现，这个下游服务在代码更高层级对migrate和当前系统创建的数据做了区分，如果是当前系统创建的才从 data store json中取，从其它系统migrate过来的因为migrated-data是原始数据，当前下游服务会从这个地方直接取migrate过来的数据，因为不清楚有这样的逻辑，所以就随机找了几条数据手动的在data store json中添加了这两个字段，测试就这样过了，但因为忽略了这条migrate这条路径，导致想要的字段并没有出现在下游服务中，测试也没有测出来。
类似这样的情况太多啦，每次都事出有因，每次情况也都不同，但怎样才能更好的杜绝这样的事情了，这是一个值得思考的问题。
精准测试
虽然一直在尝试践行精准测试，但精准测试中有一条理论，知道代码的改动影响的点或范围，奈何，因为我们的系统太复杂，代码水平有限，不能从全貌上理解或看懂项目代码，那这样靠自己精准的定位影响范围就显得力不从心。
基于此，在大多数情况下，会去直接问开发影响范围，但现在更多时候，是开发每接到一个story卡或bug卡后也只是基于卡里的描述进行简单的改动，甚至改动前自己都没有搞清楚影响范围，因为他们没有测试的测试思维，这样如果自己依赖的根基都错了，那在此基础上的建筑也必然不稳固。
此时此刻，如何避免线上bug仍是让我比较头疼的一个问题，需要继续思考，同时于此也清醒的认识到一个测试人员能读懂复杂代码的重要性，这样很多问题就可以掌控在自己手中。
有幸读到此文的你，如果有什么好的思路或灵丹妙药也非常欢迎给我留言，感谢！
