#技术巡猎##岚图# 你有没有遇到过这种情况，导航在空旷道路上定位很准，一进高楼之间、隧道口或者复杂路口，车标就开始漂移了，语音和页面提示也跟不上？这种问题拿回实验室以后，是经常复现不出来的。测试人员给车机输入一条理想定位轨迹，导航一路都可以很流畅，可真实道路上的卫星信号会出现多径反射，车速和转向角是变化的，乘客还可能同时说话点屏幕，几类信号之间的时间关系才是问题的一部分。

岚图这套方法，不是用那种“给导航编一段更复杂的假路线”，它做的是把一趟真实行程录下来。采集车在道路上行驶时，系统同步保存车辆位置、车身状态、语音输入和页面操作，每条数据都带着采集时刻。回来以后再做清洗和时间对齐，把连续行程按照场景或事件切成数据片段，比如进入隧道、驶过高楼区、连续转弯或者发生一次语音操作，并给片段加上场景标签和预期响应，最后装进用例数据库。

关键是，时间不能拆散。

这里最重要的不是数据量，而是不同信号之间的先后没有被拆散。
定位信号在某一秒开始漂移，同一秒车辆正在转向，驾驶员又刚好说了一个目的地，页面随后发生切换，这些动作在真实车里本来就是一条链。如果只留下几个坐标点，车机收到的只是路线，不是当时那段经历。带时间戳的数据包保留了谁先发生、谁后发生，以及不同信号之间隔了多久。

测试开始后，任务管理平台先指定目标用例和数据包，系统把实车数据转换成车机能接收的仿真信号，再按照原来的时间顺序注入导航。你可以把它理解成让车机重新走一次那段路，只是车没有真的开出去。测试还可以从数据包中间某个位置开始，也能调整回放速度和时序，一个难复现的问题因此可以反复播放，不用每次都等到相同天气、相同路况，再让测试车跑一遍。

但导航不是只有定位引擎。定位仿真信号交给导航引擎，车速、转向等车身信号交给通信引擎，语音输入进入语音引擎，点击和页面切换则交给页面引擎。几条信号沿着同一条时间线同时推进，测试系统再收集它们的响应，导航算出了什么位置，车身信息有没有正确传进来，语音播报说了什么，页面留下了哪些操作日志。这样测到的不是地图上的一个点，而是定位、车辆状态和交互一起运转的完整过程。

接下来不需要测试人员一直盯着屏幕。数据包里已经保存预期语音和预期操作日志，系统可以把实际播报内容与预期内容对比，把定位、车身状态和页面日志逐项核对，再生成测试结果回传任务平台。结果还能反过来更新用例库，一个新发现的问题经过确认后，就能变成以后每次软件升级都要重放的固定场景。今天修了隧道口漂移，下一版代码上线前再把同一段数据跑一遍，看旧问题有没有回来。

当然，回放真实数据不等于导航准确率自动提高了，它先解决的是测试是否足够接近真实，以及问题能不能稳定复现。数据包没有采到的道路场景，系统不会凭空知道，预期响应如果写错，自动对比也会跟着错。但这类边界不妨碍它改变测试工作的重心，过去大家努力在实验室里模拟一条道路，现在则可以把真实道路的时间关系带回实验室。

这意味着车载软件测试开始拥有一种新的记忆。它记住的不只是车辆去过哪里，还记住当时车怎么转、信号怎么漂、乘客说了什么、页面又做了什么。下一次导航版本更新，车机可以一次次重走同一段数字道路，直到那次偶然出现的问题，不再只能靠运气而已了。