测试中遇到的几种异常

2.2 ucc配置被误修改，导致调用的服务或者当前配置的参数未能生效；

3、同步数据异常：
3.1 服务问题导致的同步数据异常：POP店铺系统对matter、online、search等外部服务有较强的依赖，测试过程中常常会遇到外部服务异常导致店铺后台直接挂掉，此时可以先初步检查下店铺拿到的同步数据，如果同步数据为空，即可判断是后端异常，然后再进一步定位问题原因；

  

3.2 同步数据可正常获取，但数据中存在前端不支持的非法字符导致页面无法正常显示；

eg: POP商家后台系统中存在较多的文本输入框（商品信息文本），在前后端校验不充分的情况下（历史遗留），容易出现非法字符写入数据库，比如mac的回车、换行等可能会导致文本后面带有\u2029 等字符，用户直接复制文本信息到partner系统的某个文本框，保存审核生效后，再次进入该页面时同步数据会出现异常；

4、数据库异常：
eg: 后端未对写入数据库的数据进行限制，或者预发布工单未执行，此类异常一般后端会有明显的日志抛出，容易定位； 

5、依赖方功能异常：
eg：通过dubbo接口测试平台，或者直接登录机器，手动调用一次依赖的服务，检查返回值是否正常；

6、业务逻辑错误或功能性异常：
   在QA日常的测试过程中，遇到更多的可能是业务逻辑或者功能上的问题，这种bug容易发现也容易遗漏，还有部分问题难复现，难定位，我认为排查这种问题需要我们对自己负责的业务模块有足够的了解，而且这种了解不仅限于业务逻辑上，还包括开发的功能实现上。不了解开发实现，会使得我们在问题排查和功能回归时做很多无用功。
eg：店铺searchbanner图审核通过后，搜索结果页展示的searchbanner图未更新

业务逻辑：店铺后台修改更新searchbanner图，bss审核通过后，会触发搜索刷新自己的店铺缓存，最终更新搜索结果页展示的searchbanner图   
排查方向： 1、店铺searchbanner图审核通过后，数据是否从edit表同步到online表；

       2、审核通过后是否有向搜索发送消息更新店铺缓存（消息在问题排查中往往比较麻烦，且测试环境存在消息被其他环境消费的情况，加大了排查难度）；
       3、消息内容是否正确（店铺审核通过后会发送两种消息，online或update）；
       4、搜索拿到消息后是否进行了缓存更新； 
       5、搜索如何更新自己的缓存（遗漏）；
排查过程：首次排查时，由于对搜索更新店铺缓存的逻辑不是足够了解，所以在定位问题原因时没有排查方向，饶了很多弯路。排查无果后与开发共同梳理了店铺触发搜索更新缓存的逻辑，按照上述排查方向逐步排查，最终确认2（searchbanner图审核通过后未向搜索发送update消息）、5（搜索更新缓存时是读店铺缓存，而不是取店铺的online表，店铺漏更新自己的缓存，导致搜索更新缓存后，缓存依然是错的）是问题原因。

  
   以上是我在这段时间内经常遇到的几种异常场景和排查手段，进行自我总结，也希望对大家有所帮助。