关注 霍格沃兹软件测试开发 公众号回复「资料」, 领取人工智能测试开发技术合集这两年程序员第一次碰到了一个有点反常的问题代码写得太快了。以前一个需求可能是产品评审半天。开发3天。测试2天。修Bug一天。上线。现在有了Cursor、Claude Code、Codex之后有些中小需求真的可能变成产品需求刚下来。开发把Prompt扔进去。Agent读代码。Agent改代码。Agent补接口。Agent写SQL。Agent提交PR。半小时以后开发转头问测试“好了可以测了。”测试工程师昨天三个需求还没测完今天又来了五个。这就是AI Coding越来越普及以后一个很容易被忽视的问题开发速度提高不等于整个软件交付速度同比提高。如果代码生成速度提高5倍而验证速度只提高20%最后新的瓶颈反而会出现在QA。也正是在这个背景下一个叫 Argus 的开源项目最近登上了Hacker News。它打出的定位非常直接Agentic QA for teams whose coding agents move faster than QA.翻译成人话就是既然写代码的已经是Agent了那为什么测试代码还必须靠人一条一条写这件事情可能比“AI帮我生成测试用例”要重要得多。一、Argus到底干了什么先别把它想得太复杂。传统UI自动化通常是测试工程师↓设计测试场景↓写Playwright/Selenium脚本↓维护Selector↓运行脚本↓看报告Argus想做的事情变成了测试目标↓AI理解我要测什么↓自己探索页面↓自己规划测试步骤↓调用Playwright操作浏览器↓动态判断页面结果↓输出报告、截图、执行时间线Argus官方把一次测试拆成了五个Agent。Validator先检查你的URL和测试目标是不是可执行的。Comprehender把一句自然语言需求拆成测试场景。Explorer先去页面里探索有什么页面有什么按钮可以做什么操作Strategist根据页面地图和测试目标规划执行步骤。最后是Executor真正打开Playwright浏览器点击、输入、滚动、检查结果。所以它真正值得测试工程师研究的并不是“又来了一个AI自动化工具。”而是测试自动化正在出现另外一种组织方式。过去Script Driven Testing。现在开始出现Agent Driven Testing。二、但这里有一个非常容易被吹过头的地方很多文章会直接得出结论XPath没用了。Playwright不用学了。自动化脚本要消失了。我觉得都说早了。因为Agentic QA不是把确定性测试扔掉。真正合理的架构其实是AI负责理解AI负责规划自动化工具负责执行确定性程序负责验证这句话特别重要。因为LLM适合推理。但测试Oracle最好尽可能确定。什么叫Oracle简单说就是你凭什么判断这个测试到底通过了这恰恰是很多初级测试工程师天天在做但面试的时候又很容易讲浅的地方。我们从一个最简单的真实案例讲起。三、案例一为什么你的UI自动化总是“昨天能跑今天挂了”假设你负责一个商城。最普通的登录自动化from playwright.sync_api import sync_playwrightwith sync_playwright() as p:browser p.chromium.launch()page browser.new_page() page.goto(https://test.example.com/login) page.locator(#username).fill(tester) page.locator(#password).fill(123456) page.locator(#login-btn).click() page.wait_for_url(**/home) assert page.locator( .welcome ).inner_text() 欢迎回来 browser.close()跑了两个月。突然有一天CI红了。TimeoutError:locator(“#login-btn”)not found你打开网站。登录功能根本没坏。只是前端重构以后登录 变成 登录 于是业务没有变。自动化挂了。四、面试官问为什么UI自动化维护成本高很多初级工程师回答因为元素容易变化。对。但如果只回答到这里最多算60分。真正更深的问题是我们把“业务意图”和“页面实现”绑定得太紧了。测试真正想表达的是输入用户名输入密码点击登录验证登录成功但是脚本表达的是page.locator(“#app div:nth-child(2) form button”).click()前者是什么业务语义。后者是什么实现细节。于是页面实现只要调整测试资产跟着坏。这才是传统UI自动化一直被Flaky Test困扰的重要原因之一。五、Playwright其实已经往前走了一步所以为什么现在越来越多自动化工程师喜欢page.get_by_role(“button”,name“登录”).click()而不是page.locator(“//*[id‘root’]/div/div[2]/button”).click()因为前者更接近用户看到的东西。而不是DOM具体怎么实现。这就是一个非常值得记住的变化结构定位↓语义定位↓意图驱动而Argus这类Agentic QA实际上是在继续往下一层走测试人员甚至不告诉它get_by_role(“button”, name“登录”)只告诉它验证正常用户是否可以成功登录商城。剩下的页面理解和操作规划让Agent完成。六、一个最小的Agentic QA到底长什么样我们甚至不需要上来就搭一个复杂Agent框架。先把测试目标变成结构化描述test_task {“goal”: “验证正常用户是否能够成功登录商城”,“user”: {“username”: “tester”,“password”: “123456”},“expected”: [“登录成功”,“进入用户首页”,“页面展示当前用户名”]}然后让LLM负责理解测试目标↓观察页面↓产生Action例如{“action”: “click”,“target”: {“role”: “button”,“name”: “登录”}}最终仍然可以交给Playwright执行def execute_action(page, action):if action[action] click: target action[target] page.get_by_role( target[role], nametarget[name] ).click()注意这个结构。LLM没有直接控制Chrome。而是LLM↓Structured Action↓Browser Tool↓Playwright↓Browser这实际上就是Agent工程里非常重要的一条原则不要让模型直接干所有事情。尽量让模型决策。让Tool执行。七、但是问题来了Agent说“登录成功”你信吗这是我特别建议拿去做面试题的一句话。假设Agent完成操作以后告诉你测试通过。用户成功登录商城。你敢直接把CI标绿吗当然不能。因为Agent自己的结论不能直接等于测试结果。这也是Agentic QA最容易被初学者忽略的问题。八、我们需要一个Evaluator比如登录成功不要问LLM“你觉得是不是成功了”可以直接验证三个事实。第一URL。assert “/home” in page.url第二登录态。cookies page.context.cookies()token_exists any(cookie[“name”] “access_token”for cookie in cookies)assert token_exists第三页面状态。expect(page.get_by_text(“tester”)).to_be_visible()于是整个系统变成Planner Agent↓Executor↓Browser↓Evaluator这里真正发生了一件非常重要的事情Agent可以是概率性的。但是核心业务结果尽量使用确定性验证。九、“测试从确定性脚本走向概率性推理”到底是什么意思这句话最近很火。但是特别容易被误解。传统自动化click(“#login”)fill(“#username”)assert url “/home”只要环境不变执行路径就是固定的。这种东西叫Deterministic。Agentic QA不一样。同样一句测试一下登录功能。第一次Agent可能先看登录按钮。第二次可能先分析表单。第三次可能尝试注册入口以后再返回登录。它的执行路径并不一定完全一致。这就是概率性推理。所以Agentic QA真正难的不是能不能点页面。真正难的是每次走的路都可能不同怎么证明最终质量是稳定的这就把测试行业带到了一个新的问题我们开始需要测试“测试Agent”。十、怎么测试一个Agent假设我们让Argus类Agent执行验证用户可以正常登录不要只跑一次。跑100次。记录results {“total”: 100,“success”: 87,“failed”: 13}success_rate (results[“success”]/ results[“total”])print(success_rate)结果87%现在问题来了。传统自动化通过失败Agent测试开始出现成功率继续。为什么13次失败可能是5次页面定位错误3次错误判断验证码状态2次模型超时2次错误规划1次环境故障测试工程师开始需要统计metrics {“task_success_rate”: 0.87,“avg_steps”: 8.6,“avg_latency”: 14.2,“avg_tokens”: 3260,“retry_rate”: 0.18}这其实已经不是传统UI自动化的思维了。这是Agent Evaluation。十一、再看一个真正企业级的案例前面登录的例子大家每天都能遇到。接下来我们上一个难度。假设现在测试的是电商退款。需求用户购买商品后在订单发货前申请退款退款成功后订单关闭、支付原路退回、库存恢复、优惠券返还。页面看起来只有一个按钮申请退款但是背后的业务链路可能是退款申请↓订单服务↓支付服务↓库存服务↓优惠券服务↓MQ↓数据最终一致这时候如果Argus只看到页面显示“退款成功”它真的测完了吗没有。甚至只完成了20%。十二、这也是为什么“像用户一样测试”还不够真正的企业QA必须同时回答页面状态对不对接口状态对不对数据库对不对支付流水对不对库存有没有回滚优惠券有没有恢复消息有没有重复消费这就是单纯Browser Agent和真正企业级Agentic QA之间的差距。Argus当前公开项目主要聚焦视觉UI测试和真实Playwright浏览器环境但其“理解目标—探索环境—规划—执行”的思路可以继续向API、数据库、日志、消息队列等企业测试工具扩展。十三、退款场景怎么设计Agentic QA可以拆成Test Planner↓UI Agent↓API Agent↓DB Tool↓MQ Tool↓Evaluator例如UI Agent负责page.get_by_role(“button”,name“申请退款”).click()page.get_by_text(“退款原因”).click()page.get_by_role(“button”,name“提交”).click()然后API层验证import requestsdef get_order(order_id):response requests.get( fhttps://test-api.example.com/orders/{order_id} ) return response.json()order get_order(“ORDER_10086”)assert order[“status”] “REFUNDED”十四、然后查支付def get_payment(order_id):response requests.get( https://payment-test.example.com/query, params{orderId: order_id} ) return response.json()payment get_payment(“ORDER_10086”)assert payment[“refundStatus”] “SUCCESS”再查库存stock_before 100stock_after query_stock(sku_id“SKU_001”)assert stock_after stock_before优惠券coupon query_coupon(user_id“USER_001”)assert coupon[“status”] “AVAILABLE”这时候你会发现真正可靠的Agentic QA不是所有东西都让AI判断。反而是AI负责协调越来越多确定性的验证工具。十五、这里藏着一道特别经典的面试题什么叫最终一致性假设退款成功后。订单立即变成 REFUNDED但是库存服务因为MQ异步消费3秒后才恢复。你的测试代码assert query_stock(“SKU_001”) 100立即执行。结果99测试失败。这是Bug吗不一定。可能只是Eventually Consistent。很多初级测试工程师遇到这种问题第一反应就是time.sleep(10)这也是面试特别容易说不清楚的地方。十六、为什么sleep(10)不是好方案因为如果1秒恢复浪费9秒。如果11秒恢复还是失败。正确思路应该是Poll Timeout。例如import timedef wait_until(condition,timeout10,interval0.5):start time.time() while time.time() - start timeout: if condition(): return True time.sleep(interval) return False使用success wait_until(lambda:query_stock(“SKU_001”) 100,timeout10)assert success这背后真正考的是同步等待和异步最终一致性的区别。如果面试官问为什么不能直接sleep只回答“浪费时间。”明显不够。更完整的答案应该是sleep属于固定等待既无法根据实际状态提前结束也无法适应超出固定等待时间的异步延迟对于最终一致性场景更适合使用带超时的条件轮询。这就是面试官真正想听的东西。十七、Agent反而能让这件事情更聪明假设Evaluator发现订单 REFUNDED支付 SUCCESS优惠券 AVAILABLE库存 99它不应该立即FAILEDAgent可以根据系统知识判断库存由异步MQ更新需要等待最终一致。于是调用wait_inventory_consistency再检查。10秒以后仍然99才真正失败。然后自动继续查询MQ Trace。trace query_mq(key“ORDER_10086”)发现RefundSuccessEventsent 1InventoryRollbackconsumed 0再查日志logs search_log(keyword“ORDER_10086”)发现inventory-serviceERROR:consumer timeout最后Agent给出的已经不是退款测试失败。而可能是测试失败影响退款成功后库存未恢复。已确认订单状态正常支付退款成功优惠券已返还异常模块inventory-service证据InventoryRollback消息未被成功消费建议检查库存消费服务及MQ积压。这才开始接近企业真正想要的Autonomous QA。十八、Argus最让我感兴趣的其实不是“无脚本”因为“自然语言测试”以前也有人做。真正重要的是它把理解、探索、规划、执行拆开。这意味着未来测试Agent很可能不会是一个超级大模型什么都干而是Comprehender↓Explorer↓Planner↓Executor↓Evaluator甚至继续扩展Diagnosis Agent↓Bug Agent↓Regression Agent这种Multi-Agent测试架构。这跟AI Coding正在发生的变化非常像。十九、未来研发链路可能真的会变成“双Agent”过去产品↓开发↓测试AI Coding之后产品↓Coding Agent↓测试工程师但如果Coding Agent一天能够提交几十个Change人类测试不可能永远线性跟着增加。下一步很可能是Coding Agent ↓ 生成代码/修改 ↓ 提交Change ↓ QA Agent ↙ ↓ ↘ UI API DB ↓ Evaluator ↓ 发现问题 ↙ ↘ Yes No ↓ ↓Coding Agent修复 Merge↓Re-Test这就是AI写码Agent AI测试Agent形成闭环。但有一个特别重要的前提绝不能让写代码的Agent自己给自己打满分。二十、为什么“自己写、自己测”有风险假设Coding Agent生成def discount(price, level):if level VIP: return price * 0.8 return price然后它自己生成测试def test_discount():assert discount( 100, VIP ) 80通过。于是它认为功能正确。但是需求真正写的是VIP 8折但单笔最高优惠50元。对于1000元商品正确价格应该950而代码返回800Coding Agent只测了自己理解到的需求。于是产生一个非常危险的问题同源偏差。这就是为什么开发Agent和测试Agent最好拥有独立上下文、独立测试策略甚至不同模型。否则就变成自己出题。自己答题。自己判卷。最后100分。二十一、这也是未来测试工程师真正值钱的地方如果你看到Argus以后只得出以后测试不用写代码了。我认为理解浅了。恰恰相反。未来测试开发可能更需要理解业务。架构。测试Oracle。异步系统。接口。数据库。Agent。上下文。工具调用。评测指标。因为AI可以帮你点击。输入。生成脚本。探索页面。但是有一个问题AI永远很难凭空知道到底什么叫“对”退款成功以后库存是不是必须立刻恢复订单金额和支付金额如何对账优惠券能不能重复返还一个请求执行两次应该生成两个订单还是一个管理员和普通用户到底有什么权限边界这些东西叫Business Oracle。谁最懂这些还是长期理解业务系统的人。二十二、顺便再送一道面试高频题什么叫幂等假设Agent测试点击支付网络卡了一下。它没看到结果。于是再点一次。支付支付结果后端生成PAY_001PAY_002用户被扣了两次钱。测试发现重大Bug。这里面真正的知识点叫Idempotency。一个幂等接口重复执行一次和执行多次最终业务效果应该一致。例如headers {“Idempotency-Key”:“ORDER_10086_PAY”}requests.post(“/pay”,jsondata,headersheaders)重复调用requests.post(“/pay”,jsondata,headersheaders)服务端应该识别同一个业务请求。而不是再创建一次支付。你会发现Argus、Agentic QA这些新技术最后真正落到测试里绕不开的依然是幂等。并发。事务。最终一致性。缓存。MQ。权限。这些经典问题。所以AI时代最危险的学习方式是什么每天背AgentMCPSkillHarnessRAG结果面试官问为什么支付接口必须做幂等回答不上来。那还是很难成为真正的AI测试开发工程师。二十三、所以确定性脚本真的要消失吗不会。我甚至认为恰恰相反。未来测试体系很可能分成三层。第一层Deterministic Test稳定、关键、强规则。例如assert order_total 1000assert pay_amount 1000assert stock 98这种测试不要让AI自由发挥。第二层Agentic Test适合探索。异常路径。UI变化。未知场景。自然语言需求。复杂流程组合。第三层AI Evaluator负责理解复杂输出。异常归类。失败分析。测试覆盖评估。最终形成确定性自动化概率性AgentEvaluator这才可能是更现实的下一代测试体系。不是Agent替代Playwright。而是Agent站到Playwright上面。二十四、对于初级测试工程师应该学什么看完Argus不需要马上去造一个五Agent系统。真正建议的顺序还是Python↓HTTP/API↓SQL↓Playwright↓Pytest↓CI/CD↓LLM基础↓Tool Calling↓MCP↓Agent↓Agent Evaluation尤其不要跳过前半段。因为Agent失败以后。最终你还是要回答为什么接口404为什么Cookie没写进去为什么元素不可点击为什么数据库数据不一致为什么MQ延迟为什么接口重复提交为什么事务回滚AI能给你一个猜测。但是测试开发工程师必须能判断这个猜测对不对。写在最后Argus现在当然还是一个很年轻的开源项目。它目前重点解决的也是UI测试而不是企业所有QA问题。所以现在就喊测试脚本彻底消失。显然言之过早。但我认为它出现的时间点非常有意思。因为过去两年软件行业几乎所有的AI效率提升都优先发生在写代码。Cursor。Claude Code。Codex。Copilot。越来越多Coding Agent出现以后我们终于开始面对一个过去不存在的问题如果代码生成能力已经不再稀缺谁来验证这些代码到底能不能上线于是测试突然重新变得重要。只不过未来负责测试的不一定只有人。很可能还有另外一群Agent。Coding Agent负责疯狂生产Change。QA Agent负责疯狂寻找问题。人类测试工程师逐渐从亲自点每一个按钮往设计测试规则构建Tool定义Oracle治理测试Agent分析真正高风险问题移动。这也是为什么我觉得Argus真正值得测试工程师关注的不是“AI会不会把测试脚本干掉”而是AI已经把写代码这件事提速了下一个必须被重新设计的环节会不会恰恰就是测试如果答案是Yes。那么未来最有价值的测试工程师可能不再是最会写Case的人。也不一定是最会写XPath的人。而是那个真正知道什么必须测、什么才算通过、出了问题应该去哪找证据以及怎么让一群Agent可靠地替团队完成这些工作的工程师。这可能才是 Agentic QA 真正值得关注的地方。本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。