作为一名合格的测试，我们不仅要具备缜密、仔细的测试能力，在定位分析问题的方面，尤其是一些线上问题，也应该能做到得心应手。那一些线上事故我们该如何去定位呢？
确定问题
首先，一般线上事故都会提一个事件单，由公司业务或者运营指定给对应的负责人。我们要看清楚是什么场景下的什么操作导致的，事件的严重等级及影响范围。
另外，遇到事件也不用慌，毕竟还没搞清楚是业务的问题还是代码的问题。
比如，最近运营提出一个问题“产品xxx关联的配置xx没有在前端展示，请排查原因，相关订单号xxxx”。
首先，我们可以根据订单号在订单后台中，查看到当时的下单时，付款的金额是否包含所得资源。
分析问题
最主要的就是分析问题的产生原因。
首先，去日志记录平台查找当时的请求记录。查看当时日志中返回的数据是什么，确定是不是因为用户的配置原因导致的数据被过滤掉了。
其次，我们可以抓取当时的报文，进行二次请求，查看是否能否重现。来判断是偶现还是必现的问题。
最后，我们可以在测试环境配置相同的数据，进行测试请求。通过debug来定位最终问题。
接着上一个例子，我们可以通过订单号，在日志中去查找当时的请求报文，查看日志过滤资源的原因，确定是否存在业务配置错误的问题，一般我们都是通过当时的报文请求，来模拟用户的操作。
总结与成长
一般问题确认之后，如果是用户配置问题，我们要和用户沟通如何去修改配置，如果确实是漏洞问题，我们首先要抓紧时间去修复问题及确定影响返回，是否需要回退版本等。
等问题修复完成之后，总结和分析才是最重要的一步。
一般严重等级比较高的，我们会写事件分析的报告，确定是什么原因造成的，如何才能防止下次的迭代中不出现这个问题。
比如，每次上线前我们都会去观察日志，但由于日志记录的东西太多，没有观察到一个偶现的空指针，那么我就会在每次看日志的时候会拉长日志搜索时间并且仔细观察每个报错信息，确定是不是这个发版造成的。
又比如，由于开发添加字段的时候没有做判断字段为空处理，在新老版本切换的时候，导致新代码请求了旧数据出现空指针异常，那么我会在后面的测试过程中，优先考虑多版本切换的问题。
遇到线上事故确实是挺慌张的，生怕是不是自己漏测了哪个点，其实不用慌，很有可能是开发或者用户的原因。
但是我们要记住：定位分析问题原因，并从中得到总结，在后面的测试工作中得到成长和提高，才是最重要的！
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
