如何有效分拣测试中遇到的bug？

研发自动驾驶的核心就是开发新的驾驶技能，然后测试该技能。测试中如果发现了问题，再逐一攻克。

而问题是，工程师们往往只擅长写代码，却忽视了通过测试找到代码中的问题。花一个月时间做好了一个新的驾驶技能，就以为万事大吉了。车一旦上路，问题（bug）却层出不穷。

其实，出了bug没关系，最重要的是要充分利用发现的bug，挖掘bug的根源，才能有效修复，避免再犯。

这就涉及到triage的学问。Triage字面意思是指对问题进行分拣，其实也泛指对问题寻根溯源（root-causing），也包括分拣时所需的工具。

传统互联网的triage过程相对比较简单，代码的层级不会太深。比如，一个对外链接断了，八成是因为那个链接已经挪了地方。

而自动驾驶则复杂很多。肉眼可见的只有那辆车以及坐在车里可以体验到的乘坐感受。背后却有成百上千个代码组成部分，每一个组成部分内部又有多层分级。一旦自动驾驶车出现问题，很难马上判断出到底是哪里需要修改。

比如，肉眼所看到的是，自动驾驶车没能及时躲避一位正在过马路的行人。这可能是摄像头的问题，可能是雷达的问题，可能是行为预测的问题，可能是定位的问题，也可能是高精地图的问题，等等。因此，我们需要一个高效、严谨的过程，快速找到bug根源。

我们可以将triage分为三个阶段。

1. Bug识别

2. Bug分拣

3. Bug追根溯源

第一阶段：Bug识别

发现bug的最直接方式就是在路上测试，然后将错误标注出来。准确的标注可以让工程师更快了解bug的类别。比如使用“突然刹车”、“偏离车道”这些关键词。

然而，大部分的bug很难通过驾驶直接体现出来。如果代码里有100个bug，很可能在驾驶中只能体现出两三个。有的bug只能在特定情境下才会被触发，平时不会被发现。而且有的bug可以被重现，有的则不能。今天在某个地方突然刹车，明天这个问题可能又没了。

因此，必须首先尽量将减少测试中的变量，不要等到上路测试才发现bug。比如，如果利用仿真进行测试，就可以对变量进行有效地控制，快速确认bug。

Bug识别的工具也有很多，比如可以通过指标报表，某项指标一旦发生变化，就报错。也可以通过各种前端工具，将车的探测结果进行可视化，错误就能一目了然。

让系统自动报错虽然省时省力，但问题是，报错的数据中往往有很多杂音（noise），报告100个bug，其中也许只有几个是真正有价值的bug。因此，报错系统必须不断提升，才能提高信噪比（signal-to-noise ratio）。

第二阶段：Bug分拣

团队越大，bug分拣就越困难。假设一家公司里同时有二十个团队在过去一个月里碰过代码，那么如果出现了问题，这二十个团队就都有可能承担责任。如果不去对bug进行分拣，每遇到一个bug就让所有团队研究一次bug，会浪费很多工程师的宝贵时间。

因此，负责分拣bug的人必须对各个团队的业务了如指掌，帮助工程师对bug进行分拣。至少做到将bug及时分发到对应的小组手上，从而节省各个团队的的时间。

分拣bug时往往需要一些基本的决策树，比如，如果看到了某种现象，那么bug的原因就一定是A或B。再根据另一种现象，可以推断出一定是B。随着代码不断更新，这个决策树也需要不断更新。

Bug分拣之后，要对bug的重要等级进行排序。并不是所有的bug都需要马上被修正。根据团队在当下阶段的主要目标，比如该季度中自动驾驶车左转的bug最为重要，就要把和左转有关的bug找出来，视为priority 1。

第三阶段：Bug追根溯源

Bug分配到正确的团队的手上之后，就需要被追根溯源，看看根本问题到底出现在哪里。越复杂的bug牵扯出来的问题就会越多，根本原因也埋得越深，修正所需要的时间也越长。

针对相对容易的bug，效率就是一切。如果容易的bug都修复不了，就会拖其他复杂bug的后腿，bug越积越多，最终造成恶性循环。因此，团队必须在控制代码质量的基础上，遵守定时修复bug的流程。

因为一些bug修正起来太困难，所以很多团队会选择进行“热修复”，即hotfix，而不去从根本上解决问题。Hotfix什么时候该用，什么时候不该用，也需要各个团队做到统一。否则代码的核心质量无法保证。

其实，很多bug的根本问题不在于技术本身，而在于公司团队的组织架构设计不合理，或是高层的技术决策出现失误。团队的领导者要认清事实，敢于及时止损。