事件背景：交付给沈阳自动化研究所的一台直径200的AUV进入售后阶段。


1月13日，甲方联系我们，说深度数据不太正常，记录的下潜深度数据和实际下潜深度不一致。深度数据产生的链路是这样的。导航段的节点控制板通过485串口接收深度计的数据，和其他数据组包后，再发给我主控段的控制板，主控段内根据协议进行数据解析。这台AUV的硬件及底层代码是我们提供的，主控段内的数据解析程序也是我们提供的，甲方将自己的控制代码部署上去。


起初，我们怀疑甲方未使用正确的数据，是不是把惯导输出的Z轴数据作为深度来使用了，甲方声称绝对没有错，使用的就是数据解析程序结构体的depth数据。这样子的话，我们只能说把原始数据也记录下来看看情况。


今天，1月14号，甲方把记录了原始数据的日志发给我们后，发现解析值和原始值一致，且甲方再次进行了深度航行试验，深度数据依旧不正确。


由于导航段节点控制板未对深度传感器的数据做任何处理，不存在传递错误，说明代码端没有问题。


也许是深度计的硬件问题？说实话这不大可能，因为我们使用的深度计，是keller的Paa-10LX，之前的项目也一直在用，用了挺久，没出现过问题，这款设备也很难坏。


之后再次一顿分析，同事提出，深度计输出的原始数据单位是什么，查看了一下是bar，这时惊觉，没有把压力单位转换成m，所以数据才会不对。其实我们都清楚深度计输出的原始数据是压力单位，大概是负责节点控制板内的同事和主控段内数据解析的同事都错以为对方已经做了转换，不再需要处理了，才会出现这个问题。没有转换前压力数据是1.几，看着还挺正常，就没发现。

从这个问题可以看出测试岗位的重要性。本来团队内是有测试人员的，做事也挺认真，可惜上层领导为了降本增效，把人给开了，这个项目中开发兼测试，有些问题自测很难发现。正如对同事所说的，我们需要一个脱离开发角色的人来专门做测试。只有这样，才能从使用者的角度发现潜藏的问题。