今天转测出了问题。
我做的内容池跳转功能，测试一跑就发现跳不了，直接阻塞了用例，提了一个致命单。
坐在那里的时候，心里其实很慌。第一次出这么严重的问题，脑子里各种念头都来了。
但慌完了之后，我还是坐下来把整件事拆开看了一遍。
到底发生了什么
时间线：
- 3月30日 19:30 — 我提交了内容池跳转需求的代码
- 3月30日 — 我主动问了路由整改的同事，他说让我正常开发，他会来改我这部分
- 3月31日 — 等待，对方没有改
- 4月1日 转测 — 测试发现内容池跳转失败，阻塞用例
项目最近在做路由整改，新的跳转方式替代了旧的。我做内容池跳转用的是老方法。
我30号就提交了代码，也在当天主动确认过，对方承诺会来改。我等了两天，对方没有跟进。
昨晚合代码时，时间很晚，我担心赶不上转测发包，而且以为路由那边会处理，就没再主动追一次——这是我的失误。
但其实就算拉了，也不会有代码冲突。路由整改是新增了一套新方法，不是修改旧代码，所以 git pull 成功不代表功能没问题。这是我没有意识到的盲区。
因为昨晚后台接口也有问题，一个资源位数据不下发，一个 linkurl 为空，所以我一直以为跳不了是后台的原因，没想到还叠加了路由的问题。两个原因叠在一起，让我判断失误了很久。
最后，自验证表上用了英文名搜索，而用例上写的是中文名字，对不上，我以为没有我的验证项，就跳过去了。结果那个用例里确实有我的名字，我的功能没有被验证。
四个原因，每一个单独拎出来都不算大事，但叠在一起，就是今天这个局面。
我真正学到的
合代码后，一定要用转测包跑一遍核心流程。
不是本地的包，是合并了所有人代码之后的转测包。这两个包是不一样的东西。本地测过很多遍没问题，不代表转测包没问题。
这件事之前我知道，但今天才真正明白。
还有一件事——昨晚心里有个小声音说”要拉一下新代码”，但我没有听。
以后每次那个小声音出现，就是该停下来的时刻。哪怕就五分钟，拉一下代码，跑一遍核心流程，比之后花几个小时救火值钱得多。
处理过程
整改的同事挺好的，主动说让我把问题单转给他，他来改。致命单也降级成严重单了。
我没有甩锅，也没有等。主动复盘、主动跟进，快速弄清楚根因。
这种时候的处理方式，比功能本身跑没跑通更重要。
最后说一句
人生的路很长，一次失误不会定义什么。树挪死，人挪活。
这次经历让我对”转测包验证”和”那个小声音”有了完全不同的感知，这个认知值钱。
继续学，继续进步。
下午吃了大碗鸡肉和莲藕排骨汤。本来叫”断头饭”，后来想想应该叫”庆功宴”——扛住了，就赢了。🍗