测试数据库
测试数据库这事，测试我干过最蠢的数据一次，是测试把生产库当测试库连了。那天下午三点，数据我点下那个“执行”按钮的测试时候，咖啡还冒着热气。数据三秒后，测试整个订单表没了。数据不是测试删了，是数据没了——就像你兜里揣着五百块钱，走路回家发现口袋破了个洞，测试你甚至不知道它什么时候掉的数据。
所以后来我给自己立了个规矩：测试数据库必须是测试假的，假得越离谱越好。数据不是测试让你把数据改成“test1”“test2”那种假，是结构上就得跟生产库划清界限。我见过太多团队，测试库是从生产库导出的快照，然后大家在上面跑测试，跑着跑着，测试数据跟真数据混在一起，谁也分不清哪个是哪个了。
有个朋友跟我讲他们公司的做法，挺有意思。他们每次测试前，会往数据库里灌一批“标记数据”——每条记录的ID都带一个特定前缀，比如“ZZZ_”。这样不管谁在测试环境里查到什么，一眼就能看出来这数据是假的。要是哪天查出来一条没有前缀的记录，那说明有人把测试环境连到生产库了，这比任何监控报警都直观。
但光有标记还不够。测试数据库最怕的不是数据假不假，而是没人管。我见过一个测试库，里面躺着三年前的旧数据，字段早就改过好几轮了，可那库还按老结构跑着。每次跑测试，代码报错，排查半天，最后发现是测试库的表结构没同步。你说气不气？时间全耗在这种破事上了。
后来我学乖了，测试库的创建脚本得写进代码仓库里，跟应用代码一起管。每次有人改表结构，必须同步改那个建库脚本，跑一次完整的测试库重建流程。这事儿一开始麻烦，但真做下来，省心太多了。就像你每天出门前检查钥匙手机钱包，养成习惯了，就不会在电梯里突然慌神。
还有个细节，可能很多人没注意——测试库的权限得收着点。别给所有人写权限，不然谁手一抖改了个数据，你排查半天以为是代码bug，结果是有人手动改了测试数据。我吃过这个亏。那次跑回归测试，有个用例死活过不去，查了俩小时，最后发现是前一天晚上有人为了调试，手动改了测试库里的一条状态字段。你说冤不冤？
测试数据库这事儿，说白了就一句话：它是你的实验台，不是你的仓库。你得让它干净、可控、随时能重建。别心疼那点数据，真的，测试数据没了就没了，重建一遍花不了多少时间。要是因为舍不得删测试数据，导致生产库出问题，那才叫得不偿失。
我现在的习惯是，每周一早上第一件事，把测试库整个重建一遍。跑个脚本，等个几分钟，一杯水的功夫，就得到一个全新的、干净的测试环境。这比什么文档都管用——你不需要记住上周谁改了啥，因为一切从零开始。