记一次迭代中历史路径bug定位过程；

项目背景：现项目主要是做关于机器人的调度系统，涉及到web端、移动端、小程序及服务端和实体机器人端；

迭代背景：采用的敏捷开发，迭代周期为两周，本次迭代的US为机器人在地图上位置显示及路径显示，主要涉及到地图、设备状态、设备位置、电梯等状态信息展示；

记录方向：历史路径bug定位

记录时间：20210109

 

===================================================

关于历史路径描点存在两个问题：

1、历史数据描点存在问题（画出来的历史路径会飘-从肉眼观看就知道历史路径存在问题）；

bug定位过程：

a、刷新重新发起请求，复现该情况，是否是一直出现，该步骤是测试过程中提bug的必要步骤，必须是能够重现的，不然你提bug的时候现象描述得有相关的证据来佐证你的bug的真实性；

b、浏览器开发者工具检查请求接口，主要检查该接口的请求状态、响应报文，检查报文中返回的历史数据是否正确；当然这一步得结合数据的来进行检查了，通过写相关的查询语句来检查；

历史路径存储使用的mongodb+redis的方式，mongodb做数据持久化，redis做5分钟内数据的缓存，持久化的策略是5分钟持久化一次；在这过程中学习了一下mongodb的如何进行查询，后面可以把mongodb的相关学习文章贴出来；

c、检查历史路径查询的方式，在现项目中历史路径的查询方式：在查询过程中对数据进行了压缩采用的是道格拉斯算法；

d、检查数据本身的正确性，该数据是机器人通过mqtt方式与服务端进行交互的，在存储的过程中服务端没有对数据内容进行任何加工，只对数据进行了分组分包的的方式，5分钟持久化一次，一分钟一个包，一个包中包含了多个分组标签，一个标签代表了一段路径；

最后发现机器人上送位置数据有问题，当机器人开机或者重启后会出现定位丢失的情况，上送的位置信息数据是错误的，所以在地图上描述出的路径是有问题的；

 

针对上送的位置数据有问题做了如下方案：

•  第一种方案：对机器人上送的位置信息数据做异常数据筛选，剔除异常数据；

• 第二种方案：联合机器人做一个机器人开机自检的init接口，在上送的位置信息里面加一个标志位，来表示机器人是否定位成功，这个方案比较靠谱，但是需要机器人端实现，只是提出来这种方案；

2、右侧的测试列表状态信息存在闪烁的情况，一会儿状态有，一会儿状态没有；

该机器人列表的实现逻辑：请求或者刷新的时候通过接口返回机器人的状态：在线、离线（服务端10s是否订阅到机器人端发布的topic）；停留在该界面机器人离线变在线，在线变离线的判断逻辑为10s内前段是否订阅到该设备的位置信息或者状态信息；

后面检查得知服务端订阅到的机器人的topic中时间戳与服务端的时间不一致，导致解析topic中的payload的时候判断出错；

3、获取历史数据接口请求响应慢，部分接口请求响应时间多达14s，有时候回出现超时情况（前段设置了超时时间）

 a、打开浏览器开发者工具，检查接口请求情况有，检查接口详情中的timing时间统计信息，发现reques/response时间消耗达到14s；

b、检查response中的响应body，发现数据量提别大；

优化：服务端对历史数据查询进行优化压缩，效果不明显；

c、检查mongodb中的查询时间；

优化：mongodb数据库添加查询索引，效果不明显；

d、数据检查，其他设备的历史数据查询消耗的时间远远小于该设备查询时间，检查该设备的具体数据，发现该设备的存在多楼层的历史数据；

后续的优化方案待定，需要等后续方案确定后在进行补充；