测试协议书

凌晨两点十七分，测试我盯着屏幕上那行绿色小字——“测试通过率97.3%”，协议忽然觉得这数字像一句谎言。测试三天前，协议同一套测试用例跑出来的测试结果还是99.1%。没人改过代码，协议没人动过环境，测试可数字自己会呼吸，协议会起伏，测试像某种活物。协议

这份协议书的测试甲方是质量部门，乙方是协议开发团队。条款写得清清楚楚：测试环境必须与生产环境一致，测试测试数据必须脱敏，协议缺陷修复后必须回归验证。测试每一条都像手术刀，精准切割着责任边界。可签字的笔悬在半空时，我总想起上个月那个事故——生产环境出了bug，测试环境跑得完美无缺。最后查出来，是测试库里的日期字段比生产库少了一位毫秒精度。

协议里没有“毫秒”这个词。它只管环境一致，却管不了环境里的时间颗粒度。就像它规定测试人员必须独立于开发团队，却没法规定独立到什么程度才算真独立——隔壁工位的小张，昨天刚帮开发改完测试脚本，今天又要签这份协议，保证测试的客观性。

我见过最荒诞的测试协议执行现场。某银行核心系统上线前，测试组长把全部用例跑完，在报告上签了“通过”二字。可就在同一天，他私下跟我嘀咕：“那个转账并发测试，我其实只跑了单线程，多线程环境起不来。”我问为什么不报缺陷，他反问我：“协议里写了要测多线程吗？写了必须把环境问题报上去吗？”我翻到协议第4.2条，确实只写了“测试应覆盖协议约定的功能点”，没写“测试人员应如实反馈环境限制”。

后来我学会了一件事：看协议不能只看条款，得看条款之间的缝隙。缝隙里藏着人的惰性、组织的惯性，还有那种“反正按协议做了，出事别找我”的免责心态。真正有效的测试协议，往往不是写出来的，是吵出来的——开发说“这bug不算缺陷，是需求理解偏差”，测试说“你需求文档写的就是这个意思”，两边吵到第三轮，才有人提议：“要不把‘需求理解’也写进协议里？”

现在这份协议修订到第七版了。第七版新增了一条：测试结论必须附带原始日志截图。就这么个简单要求，逼得测试组把自动截图功能写进了框架里。你看，协议这东西，写得再细都有漏洞，但每堵上一个漏洞，测试就离真实世界近了一寸。

我最后还是签字了。不是因为协议完美，而是因为它允许修订——第9.3条写着“本协议每季度评审一次，任何一方可提出修改建议”。这大概是整个文档里最有温度的一句话，它承认了测试本身也是被测试的对象。

窗外天快亮了。那行97.3%的绿字还亮着，我右键点开历史记录，发现昨天有人跑过一次冒烟测试，参数没带全。问题找到了，不是代码的错，是人的手滑。可协议管不了手滑，它只能管手滑之后，你愿不愿意在备注栏里写一句“测试参数缺失，结果无效”。

我写了。然后重新跑了一遍，这次是99.1%。数字还是那个数字，可我知道，这一回它背后站着的是诚实。