当AI开始写代码，测试的战场从“测代码”变成了“测AI”
大家好，我是某互联网公司质量基础设施团队的负责人。
最近半年，我身边越来越多的同行在问同一个问题：“AI Agent都能自己写代码了，测试是不是快被淘汰了？”
我每次的回答都一样——恰恰相反。AI Agent越能写代码，测试就越重要，而且测试的难度和复杂度正在指数级上升。
今天想聊一个在圈子里越来越热的概念——Harness，以及为什么AI Agent时代，测试比任何时候都更需要它。
一、一个正在发生的现实：AI在写越来越多的代码
先看一组数字。
根据行业数据，42%的代码已经由AI生成或辅助完成，但96%的开发者仍然无法完全信任AI生成的代码。与此同时，67%的开发人员花费更多时间调试AI生成的代码，68%花费更多时间解决安全漏洞。
更让人担忧的是，Tricentis发布的《2026 Quality Transformation Report》指出：全球高达60%的组织正在将未经测试的代码部署到生产环境中。
这不是危言耸听。我所在的公司，过去半年AI辅助生成的代码占比从不到10%飙升到了35%以上。代码产出的速度翻了几倍，但测试团队的人手没怎么变。
结果就是：测试成了整个交付链路里最粗的那根瓶颈。
二、AI写的代码，到底有什么不一样？
有人可能会说：“AI写的代码也是代码，用同样的方法测不就行了？”
但实际情况远比这复杂。AI生成的代码有三个非常特殊的“坑”：
坑一：代码“能跑”≠代码“正确”
AI生成的代码往往能编译通过、能跑通主流程，但一旦遇到异常场景、并发竞争、数据一致性问题、安全漏洞，就会暴露出深层缺陷。
我见过一个真实案例：AI生成了一段支付回调处理逻辑，主流程跑得特别顺畅，但在“回调超时+重试”的边界场景下，直接导致了重复扣款。常规的功能测试根本测不出来。
坑二：代码量暴增，人类审查跟不上
Harness CEO Jyoti Bansal在2025年的Unscripted活动上说过一句大实话：使用AI生成的代码意味着代码量可能是以前的四倍，这使得人类很难检查每一行代码。
四倍是什么概念？以前一个PR 200行代码，Reviewer还能一行行看。现在一个PR 800行，其中大部分是AI写的——你根本来不及看完，更别说看懂。
坑三：测试用例本身也可能是AI写的
最讽刺的是——很多AI编码助手不仅生成业务代码，还会顺便生成单元测试。
但问题来了：让同一个AI既写代码又写测试，等于让一个人既做账又做审计。测试和代码来自同一个“大脑”，它只会验证自己认为对的东西，天然漏掉自己没想到的场景。
研究表明，在AI生成的有缺陷代码之后生成测试，缺陷检测效果会显著降低，因为生成产物之间缺乏独立性。
三、传统测试框架为什么不够用了？
面对上面这些问题，传统的测试框架——JUnit、TestNG、Pytest、Appium——全都显得力不从心。
传统测试框架的本质是“执行预设脚本” 。你写好了测试用例，框架帮你跑。但AI生成的代码每时每刻都在变，你根本来不及为每一行新代码写测试。
更关键的是，AI Agent的行为模式本身就需要测试——同一个输入，AI可能给出不同的输出，因为它底层的语言模型每次都在“自主决定”如何完成任务。
传统软件是确定性的——同样的代码、同样的输入，永远产生同样的输出。AI Agent是非确定性的——同样的输入跑10次，可能得到10个不同的结果。
用测试确定性系统的方法去测试非确定性系统，注定失效。
四、Harness到底是什么？（用一句话说清楚）
Harness这个单词的本意是“马具”——套在马身上的缰绳和鞍具。
马力再大，没有马具，就是在旷野上乱跑。AI模型是马力，Harness就是方向盘加刹车。
具体到技术层面，Harness是一家专注于自动化软件开发“代码后”阶段的公司——测试、安全、部署。它在2025年完成了2.4亿美元E轮融资，估值55亿美元，服务超过1000家企业客户。
但Harness更重要的身份是——一个给AI Agent设计的“工作环境”和“操作系统” 。
想象你招了一个新员工：
他很聪明，但记性差（无状态）
他会自作主张（容易幻觉）
他做错了也不承认（缺乏自省）
你怎么办？不是反复叮嘱“你要仔细点”——那是Prompt Engineering。你需要给他一套完整的工作系统：操作手册、文件柜、自动检查流程、错误记录本、交接制度。
这套系统，就是Harness。
五、Harness到底能做什么？
我挑几个对测试团队最有价值的点来说。
- 意图驱动的测试创建（Intent-Based Testing）
这是Harness AI Test Automation最核心的能力。
你不再需要写脚本、维护XPath、调试断言。你只需要用自然语言描述测试意图。
比如，你直接输入：“把最贵的商品添加到购物车”。
AI会自动理解你的意图、分析UI结构、生成对应的测试步骤、执行验证。
效果数据：测试创建速度提升10倍，测试维护工作量降低70% ，发布周期加快5倍。
- 自愈能力（Self-Healing）
这是传统自动化测试最大的痛点——UI一改，XPath全挂。
Harness的AI会在每次运行时动态调整UI定位器，基于最新的页面布局和元素变化自动修正。
有客户从Playwright迁移到Harness AI Test Automation后，测试维护时间减少50%，Bug数量大幅下降。另一家客户测试维护工作量降低40%，每个测试人员每天省出2-3小时。
- 知识图谱（Knowledge Graph）
Harness区别于其他AI平台的核心，是它的软件交付知识图谱——映射了代码变更、服务、部署、测试、环境、事件、策略和成本之间的关系。
简单说：AI不是“盲测”，它知道你整个系统的上下文。
当AI要生成一个测试时，它知道这个服务依赖谁、上次改了什么、历史上在哪里出过问题。这种上下文感知能力，是“泛泛的AI”做不到的。
- Agent全生命周期管理
2026年6月，Harness推出了Autonomous Worker Agents——流水线里的每一个步骤（测试、安全、部署、修复）都可以作为一个“推理Agent”运行，而不是一段固定脚本。
更关键的是，这些Agent走的是和人类部署一样的审批流程、审计追踪和策略控制。
2026年7月，Harness又推出了Agent DLC（Agent Development Lifecycle） ——把管理应用代码的那套流程，完整地扩展到了AI Agent上。
这意味着：你的AI Agent可以像普通代码一样被构建、测试、部署、回滚、审计。
- AI评测与质量门禁（AI Evals）
Agent和普通代码不一样——你不能简单地跑个单元测试就说“通过了”。
Harness AI Evals会对Agent的输出进行正确性、性能、安全性的评分，并可以作为CD流水线的质量门禁。
不达标就不让上线。 这恰恰是现在大多数团队在用AI Agent时最缺失的一环。
六、一个真实对比：有Harness和没有Harness
我在内部做过一次对比实验，用同一个AI Coding Agent完成一个中等复杂度的功能开发，然后对比两种测试方式：
没有Harness的方式：
开发写完代码 → 手工点几个页面 → “好像没问题”
提交PR → 跑现有自动化测试（覆盖率不到40%）
测试同学手工补充验证 → 发现3-5个Bug → 打回重改
来回2-3轮 → 交付周期3天
有Harness的方式：
开发写完代码 → Harness AI自动生成对应的端到端测试
测试自动执行 → AI自愈定位器自动适配UI变化
AI Evals自动评分 → 质量门禁自动判断是否达标
不达标自动打回 → 开发收到详细的失败报告
一轮通过 → 交付周期4小时
差距不是一点点。
七、给测试同行的几点建议
如果你所在的团队正在引入AI Coding工具，我建议你认真考虑以下几个问题：
- 测试的定位正在从“执行者”变成“设计者”
以前测试的核心工作是“写用例、跑用例”。以后的核心工作是设计质量门禁、定义评估标准、训练和调优测试Agent。
你的价值不再是你写了多少条测试，而是你设计了一套什么样的质量保障体系。
- 不要只用AI来“辅助测试”，要用AI来“治理AI”
很多团队用AI做测试用例生成、做自动化脚本——这当然有用，但只是第一步。
真正需要的是用一套工程化的体系来治理AI生成的一切——代码、测试、部署——让AI的所有产出都经过系统性的验证。
这正是Harness在做的事情：让AI Agent通过和人类代码一样的流水线、策略和审计流程。
- 质量门禁要从“代码层面”上升到“行为层面”
传统质量门禁检查的是：代码有没有编译通过、测试覆盖率够不够、有没有安全漏洞。
对于AI Agent，你需要检查的远不止这些：它的输出是否正确、是否安全、是否合规、是否可复现。
你需要的是一套专门为AI Agent设计的测试和评估体系。
最后
AI Agent会写代码，不是测试的末日，而是测试的升级时刻。
当AI承担了越来越多的“写代码”工作，人类工程师的价值就从“写”变成了“判断”——判断AI写的东西对不对、好不好、能不能上线。
而Harness这类工具，本质上就是给这个“判断”过程提供了一套工程化的基础设施。
它不是取代测试工程师，而是让测试工程师从“手工执行测试”升级为“设计和管理质量保障体系”。
代码越容易生产，质量就越珍贵。
而守护质量的人，永远不会失业。
本文系作者基于行业观察和项目经验的总结。文中涉及的产品和数据均来自公开信息，欢迎同行交流讨论。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
