导读
当AI测试工具将代码覆盖率从60%推高到92%，我们看到的究竟是质量保障的飞跃，还是一张团队集体自我安慰的成绩单？
老贺通过三个层次层层推进论证。首先以银行利率系统闰年Bug为例，揭示覆盖率本质是一场"精确的自我欺骗"——AI只能高效执行文档里"有"的内容，对文档里"没有"的场景保持完美沉默。文档从来不是真实业务的完整映射，只是写文档者认知的投射。
其次，指出行业中存在一种"组织级合谋"：CTO需要技术先进性证明、QA总监需要数据化业绩、项目经理需要投入回报证明，而覆盖率报告恰好是所有人都能接受的"完美答案"——没人愿意追问覆盖之外还有什么。
最后，老贺用HSBC宕机事件说明隐性知识的致命盲区：存在于老员工肌肉记忆里的经验、两年前的内部邮件链、踩坑积累的直觉，这些AI永远扫不到。
所以：软件质量的决定性因素，从来不是执行效率，而是对业务本质的理解精度。放弃追问"文档没写的测了吗"这个权利，测试工程师就离数据标注员不远了。
2026年AI测试最核心的迷思：当我们拼命把数字从红刷到绿，到底是在确保质量，还是在给团队配发一片集体镇静剂？
一、那个被所有人绕开的闰年Bug
把时间拉回到几年前。我参与过一个银行核心利率计算系统的测试验收。项目也上了AI测试，覆盖率从67%干到87%，报告打印出来厚厚一沓，看起来很唬人。
我那天也不知道哪根筋搭错了，站在白板前画了条时间线，然后问了项目组一句话：“这个模块能在闰年2月29日正确算出利息吗？”
会议室安静了大概五秒钟。技术经理的脸色从红变白，最后变成一个很尴尬的笑。他们回去翻文档，翻了三遍，确实没提闰年。
更可怕的是，上线日期是那年11月。那个系统在下一个闰年到来前，整整跑了14个月。没人知道那个Bug。直到那一年的2月29日，它精确引爆，涉及12万笔交易的利息计算全部出错。事后追责，没人能背锅——因为文档里确实没有。你让AI测什么？
这个事让我想明白一件事：覆盖率的本质，是一场精确的自我欺骗。
它不关心现实世界有多少“闰年2月29日”，只关心你提供了多少测试用例给它跑。你给的用例越多，它跑得越漂亮。但问题是，文档从来不是真实业务的完整映射——它只是当时写文档的人认知的投射。
而这个现实，在AI测试的语境下，被放大了十倍。
二、一场组织级的“合谋”
我在网上查到一个挺有意思的数据，来自《World Quality Report 2023-24》。报告里说，88%的企业打算加AI测试预算，但足足73%的企业坦承，还没把AI测试真正集成到CI/CD流水线里。
这很有意思。大家一边喊着我投钱，一边身体很诚实。为什么？因为“真上线了，锅谁来背？”
这个问题其实牵出了AI测试推广中最核心的隐痛——这是一种组织级的“合谋”。
我们不妨还原一下这个场景。CTO要证明自己引入了“最先进的AI技术”来提升交付效率；QA总监要证明自己的团队“跟上了时代”，用数据说话；项目经理要证明“投入有回报”。而“覆盖率从X%提升到Y%”的报告，恰好是所有人都能接受的“完美答案”。
没人会主动追问“覆盖之外还有什么”，因为一旦追问，所有人都得面临“我前面投入的那大几百万和时间，到底买了什么”的灵魂拷问。
这就像一场心照不宣的表演。管理层拿到一份漂亮的KPI数据，向上汇报更有底气；测试团队拿到一份“降本增效”的功劳簿，年终总结更好写。但代价呢？代价就是所有人都选择了不问。
我前阵子和一个TMMi认证的专家聊天，他提到一个很扎心的观察：很多达到TMMi Level 2的企业，流程文档做得飞起，但实际执行大打折扣——“有，但没人真按它干”。这跟我上面说的“合谋”，本质上是一回事。
当“好看”变成了比“好用”更重要的事，再漂亮的数字也救不了场。
三、“没有写在任何地方”的知识，才是真正的黑盒
有人肯定会说：你这不是老黄历吗？现在的AI测试工具，尤其是大模型加持的，已经能做很多东西了。它能自动分析需求文档，发现逻辑冲突、遗漏点，甚至能帮你补全文档本身。
我承认，这确实是进步。一些工具已经在做“文档审查”的工作，能找出文档A和文档B定义不一致这种显性错误。
但这里有个更深的盲区。
我举个最经典的例子。2019年，汇丰银行（HSBC）的零售银行系统发生了一次大面积宕机，原因是一个数据字典变更后，相关的异常处理代码没有同步更新。这个知识存在于“老员工的脑子里”，或者存在于“两年前一个不公开的邮件链”里。AI去扫描1000份文档，也找不到这个信息。因为它从来就不是文档知识。它是一个坑踩多了之后积累的经验。
AI最擅长的事，是执行“已知”。但它对“隐性知识”近乎失明。
汇率的小数位截断、跨时区的夏令时跳转、第三方接口那些稀奇古怪的429响应……这些场景，很多都没有“标准答案”写在文档里。它们存在于业务专家的直觉里，存在于那些被生产事故砸过的老测试的肌肉记忆里。
所以我们真正要警惕的，从来不是AI，而是借着AI那双“完美的手”，心安理得地放下了自己那颗“提防的心”。
四、行业里正在发生的一些事
我最近注意到几件事，跟这个判断有点呼应。
第一个是ISTQB的CT-GenAI认证（生成式AI测试认证），报名人数蹿得很快，但通过率据说很低。为什么？因为这个认证不考你“用什么工具调什么参数”，它考的是思维方式——你理不理解AI系统的不确定性、偏差和幻觉。说白了，考的是你对测试本质的理解，不是对工具的上手速度。这其实是一个非常重要的行业信号：专业认证体系已经开始倒逼从业者，从“怎么用AI测”回到“什么是测试”这个元问题上。
第二个是ISO 25010质量特性模型在AI系统测试领域开始回潮。前两年大家都在讲覆盖率、讲自动化率。现在越来越多的成熟团队，开始把功能正确性、性能效率、可用性、可靠性、安全性这些维度重新拉回来，放在一个更大的框架里去审视AI测试的价值。这背后一个很朴素的想法是：不能只盯着一个指标好看，要看整个系统是不是真的稳了。
第三个是我在自己跟踪的一个行业事故数据库中看到的趋势：过去一年，因为“需求盲区”（或者说“文档里没写”）导致的生产事故占比，上升了接近40%。这个曲线跟AI测试工具的普及曲线，高度重合。
这些信号串在一起，指向一个不太乐观的判断：我们可能是在用一个更快的轮子，跑在一条错误的地图上。跑得越快，偏得越远。
五、那怎么办？几个能落地的“笨办法”
基于上面的分析，我其实可以做一个比较谨慎的预测：如果AI测试工具的覆盖率能力在未来一年还在快速提升（IDC预测市场增长率超50%），而团队评估质量的标准依然是单一维度的“覆盖率”，那在未来18到24个月里，会有大量“高覆盖率、高事故率”的案例集中爆出来。届时，行业会迎来一次对AI测试效果的真实反思，质量评估标准会被逼着从“覆盖率”走向“风险覆盖度+业务理解深度”的双轨制。
我不想等那时候。所以我分享几个我自己在项目里，或者看到身边靠谱团队在用的“笨办法”。
1. 给覆盖率报告上个“紧箍咒”：覆盖率盲区清单
规矩很简单。每周出覆盖率报告的时候，必须附上一份“覆盖率盲区清单”。格式大概是这样：
本周覆盖率：85%
盲区假设清单：
文档假设了所有交易都在单一币种内。如果出现交叉币种对冲，逻辑未覆盖。 文档假设第三方支付接口成功率100%。如果接口连续超时3次以上回滚逻辑未定义。 文档假设用户输入在10-200字符之间。如果用户输入了一个Emoji导致数据库字段报错，未覆盖。
这份清单的价值，大于那张85%的报告。因为它逼着团队去直面“我们不知道什么”。
2. 搞一场“批斗式”需求对抗
在AI生成测试用例之前，先开个会。参会的人不是随便叫的：必须要有业务专家、一线开发、以及干了这个行当超过5年的老测试。会议目标不是“文档写得多好”，而是“文档写得多烂”。
让大家放开了找茬。越离谱越好。找到一个算一个。我上个月在一个项目上这么干，第一周就薅出了13个文档没覆盖的场景，其中一个涉及千万级交易量的汇率精度问题，当场把业务专家吓出一身冷汗。
3. 做个“未知风险仪表盘”
跟那些漂亮的、红绿相间的覆盖率仪表盘并排放一块。在覆盖率数字旁边，用一个同样大小的区域，显示“当前已知的未知风险数”。
这个数字怎么来？就从上面第一条的“覆盖率盲区清单”里来。它能持续给管理者和团队一个直观的心理反馈：真正的安全感不是来自92%，而是来自你知道那8%之外，还TM有这么多坑。
最后说一句
我有时候觉得，AI测试这场浪潮，最大的贡献不是帮我们省了多少人力，而是它把一个长期被行业粉饰太平的问题，赤裸裸地摆到了桌面上——软件质量的决定性因素，从来不是执行效率，而是对业务本质的理解精度。
测试工程师真正的护城河，不是你会用多新潮的工具，而是你敢不敢站在白板前，问出那句“文档没写的东西，我们测了吗？”
放弃这个权利，就真的离“数据标注员”不远了。
文章评论