一直想找一种方式让系统测试不再像流水线工人一样反复点击、反复抄写结果。ERP项目上线前那阵子我硬是让团队手动跑了三天回归眼睛都快看花了。后来接触到 Hermes Agent发现可以把整个测试过程交给它我只要用一句话描述测试目标它自己拆任务、调工具、跑用例、收集结果最后还能按指定格式生成报告。实测下来我让它自动执行了72项系统测试生成了10份不同维度的报告整个流程基本无人值守。这篇文章就是这次实战的完整复盘包含部署过程、任务拆解思路、参数配置和中间踩过的坑给同样想搭建AI自动化测试环境的朋友一个参考。这次项目的背景并不复杂一个基于B/S架构的ERP系统模块多、接口密、权限逻辑繁琐。传统做法是设计测试用例、人工验证、手动截图和记录费时费力还容易遗漏。我的目标很直接用Hermes Agent接管“计划-执行-汇总”的循环只保留人工审核最终结论。最终落地效果超出了预期不仅72项测试全部跑完报告也自动输出成10份清晰的文档团队评审时可以按模块和风险等级快速定位问题。1. 为什么用 Hermes Agent 做系统测试1.1 传统测试的痛点很多团队对自动化测试的理解还停留在“用脚本替代点击”上。确实Selenium、Playwright、Appium都能解决UI自动化接口层也有JMeter、Postman或自研框架搞一套流水线也能跑。可问题在于测试脚本要维护页面一改就得跟着改数据要准备环境一变就全废最重要的是测试结果分析仍然需要人工逐条查看。跑完几百条用例机器告诉你3条失败你还是要自己去查日志、翻接口、定位是不是环境问题。我这次要测的ERP系统更麻烦。它本身有72个核心业务场景包括采购订单流转、库存盘点、应收应付核销、权限矩阵校验等等。这些场景跨越多个模块接口之间有依赖数据库状态会互相影响。用传统脚本写起来每个场景至少几百行代码还要额外写数据清理逻辑工作量非常大。1.2 Hermes Agent 的能力边界Hermes Agent 跟传统自动化框架最大的区别是它把“执行脚本”上升到了“理解和规划”的层面。它本质上是一个能调用各种工具和API的智能体你可以通过自然语言给它下达测试指令它会结合现有工具链自行规划步骤、生成临时脚本或直接操作接口然后把执行结果汇总反馈。对于测试这件事来说相当于给团队配了一个“AI测试协调员”而不是多了一个“脚本机器人”。应用到系统测试上Hermes Agent 可以做到这几点根据一句测试目标自动拆解测试范围、测试步骤和预期结果。调用已有的接口测试工具、数据库查询工具或浏览器自动化工具代替人来执行动作。实时收集执行日志、接口返回值、数据库快照并自动对比预期。按预定模板生成测试报告内容包含执行明细、失败原因和风险建议。注意Hermes Agent 不是测试工具本身它更像“调度大脑”。具体操作还是要依赖终端、浏览器插件、数据库客户端这些底层工具。理解了这一点后续配置起来就顺了。1.3 这次设定的目标这次项目我给自己定了两个硬指标把ERP系统的72个核心用例全部自动跑完中途不人工干预。自动生成10份报告按不同阅读对象和维度拆分包括完整明细报告、模块汇总报告、接口健康报告、数据校验报告、权限矩阵报告、异常日志分析报告、性能参数趋势报告、用例覆盖度报告、缺陷清单报告和交付评审报告。这10份报告不是简单把一份结果重复复制而是各自用不同的视角抽取数据。Agent需要自己决定从哪些日志和结果文件中提取信息再组织成对应格式。整个过程只允许我提供一句话的总体目标和约束条件。2. 环境准备与 Agent 安装部署2.1 硬件与软件环境先说硬件。Hermes Agent 本地部署版对配置要求不算低因为需要加载模型并做推理。我用的是一台带32GB内存和RTX 40608GB显存的测试工作站操作系统是Ubuntu 22.04。如果是纯Windows环境也能跑但建议显存不低于6GB内存不低于16GB否则并发任务一多容易卡死。软件层面需要准备Python 3.10建议3.11兼容性更好Node.js 18部分内置插件需要Docker可选用于隔离测试环境Git拉取仓库和更新版本各数据库客户端、HTTP客户端会被Agent调用2.2 安装步骤我从官方仓库拉取的是最新的本地部署分支。安装过程大致如下# 拉取代码 git clone https://github.com/HermesAgent/hermes-agent.git cd hermes-agent # 创建虚拟环境 python3 -m venv .venv source .venv/bin/activate # 安装依赖 pip install -r requirements.txt # 复制环境变量模板 cp .env.example .env # 初始化配置 python manage.py init初始化完成后会生成一个本地服务。默认监听在127.0.0.1:8080然后启动服务python manage.py start --port 8080接着在浏览器打开http://127.0.0.1:8080就能看到控制台界面了。首次进入会让你配置模型接口和创建Agent实例。2.3 模型配置与关键参数Hermes Agent 的核心是模型推理所以模型配置直接影响测试规划质量。我最初用默认的通用对话模型结果Agent生成的步骤偏保守很多用例只是“检查页面是否打开”完全没有真正触发业务逻辑。后来改成具备工具调用能力的大模型并且把温度参数调低效果才明显改善。在.env里有几个关键参数值得关注# 模型配置 LLM_PROVIDERopenai_compatible LLM_MODELyour-model-name LLM_API_BASEhttp://127.0.0.1:11434/v1 LLM_API_KEYdummy-key # 推理参数 LLM_TEMPERATURE0.1 LLM_MAX_TOKENS8192 # Agent运行参数 AGENT_MAX_ITERATIONS50 AGENT_CONCURRENCY4温度调到0.1是为了让Agent严格按照指令和已有规范执行减少随机发挥。最大迭代次数设到50避免某个用例陷入死循环导致整个任务卡死。并发设置为4既能提速又不会把系统资源占满。提示如果是在Windows上部署安装依赖前最好先确认Python环境用的是64位并且把Microsoft C Build Tools装好否则部分依赖包编译会报错。3. 测试任务设计与执行流程3.1 将测试需求拆解为 Agent 任务Agent虽然智能但它不知道你的业务规范。所以“一句话搞定”不是真的只需一句话而是把复杂需求浓缩成一句话级别的指令配合必要的上下文和约束。我在给Hermes下指令前会先准备好一份测试范围说明里面包含72个用例编号、名称、前置条件、步骤和预期结果。然后我把这份说明作为附件或上下文提供给Agent再给出总体指令。最终我使用的是类似下面的指令请根据附件《ERP系统核心测试用例v3.xlsx》中的72个测试用例依次执行系统测试。 执行环境为http://192.168.1.100:8088测试账号和密码在环境参数中。 每个用例执行前需要重置对应模块的测试数据执行过程中记录接口状态和响应时间。 执行结束后请汇总所有结果并生成10份报告报告格式要求见模板目录。这仍然算是“一句话”但包含了执行范围、环境、数据策略和输出要求四个关键要素。如果把这些要素分开讲Agent反而容易理解偏差。3.2 设计72项测试用例的思路这里说的72项是最终执行的用例数而不是随便挑出来的。我按照RBT基于风险的测试思想做了筛选优先覆盖核心交易链路、高风险权限点和跨模块数据一致性场景。大致分布如下模块用例数重点覆盖内容采购管理12订单创建、审批流、收货入库、采购退货库存管理10盘点、调拨、批次追溯、库存锁定销售管理14报价、订单、出库、应收生成、销售退回财务模块16凭证生成、核销、期末结账、报表计算系统管理12用户权限、角色矩阵、操作日志、数据权限基础数据8物料档案、供应商档案、BOM维护、汇率同步每个用例都必须有明确的前置条件和预期结果不能出现“验证数据展示正确”这种模糊描述。例如采购订单用例预期结果要精确到“订单状态变为已审核库存台账增加对应数量财务生成待结算单据”。这样才能让Agent对照检查而不是自说自话。3.3 Agent 执行调度与并行策略72个用例不能一股脑全跑因为不同用例之间可能有数据依赖。我把用例按模块分组并设定依赖关系比如采购模块跑完才能跑库存模块库存跑完才能跑财务模块。在Hermes Agent中可以通过规划工具里的“任务依赖图”来配置。实际执行时Hermes Agent会自己动态调度。不用担心并发冲突我配置了全局锁和数据库事务回滚策略。每个用例执行前Agent会先调用数据初始化脚本把相关表恢复到基线状态然后才开始执行步骤。执行过程中的截图、请求日志、响应时间全部落盘。这里有一个重要的经验不要在一开始就让Agent并行执行所有用例。先串行跑通一个模块的10个用例确认没有问题再逐渐提高并发。我第一轮就是盲目开并发结果两个用例同时修改同一批库存数据导致后续断言全失败白白浪费了两个小时。3.4 执行过程的观察与干预虽然目标是无人值守但我在执行过程中还是保持“轻干预”策略。通过控制台能看到每个用例的实时状态分别有等待中、执行中、成功、失败、阻塞5种。我观察到用户权限矩阵相关的用例最容易出现假失败。原因是ERP系统有缓存权限变更后需要刷新会话才生效。Agent第一次没注意连续报了5个失败。我暂停任务在环境配置里增加一条“权限变更后必须重新登录”的全局规则然后重新触发问题就消失了。这种干预是有价值的它不破坏自动化流程反而是把经验沉淀到Agent的配置里。跑完一轮后这些规则都保留在Agent的记忆库中下一轮执行就不会重复踩坑。4. 测试报告生成与解读4.1 10份报告的构成与维度10份报告看起来很多但每一份的读者不同信息颗粒度也就不同。报告名称面向对象主要内容完整执行明细报告测试工程师每个用例的执行步骤、实际结果、截图、日志索引模块汇总报告测试组长各模块通过率、失败用例编号、醒目风险提示接口健康报告开发工程师所有被调用接口的状态码分布、响应时间均值、超时Top10数据校验报告测试工程师数据库前后对比、关键字段一致性、异常数据标记权限矩阵报告安全/管理员各角色可访问功能点、实际访问结果、越权风险异常日志分析报告开发/运维日志中出现频率最高的异常栈、关联用例、时间线性能参数趋势报告性能测试工程师响应时间、吞吐量、资源占用随用例执行的变化曲线用例覆盖度报告质量管理用例与需求追踪矩阵的映射情况、未覆盖需求列表缺陷清单报告项目经理所有失败用例整理成缺陷含严重等级、复现步骤、初步定位交付评审报告项目决策层测试结论、剩余风险、是否可上线的建议Hermes Agent在生成报告时并不是自己编数据而是从执行日志、接口记录文件、数据库快照这些真实数据源中提取内容。为了让它能正确读取我会在测试执行前把相关指标定义好比如“响应时间超时阈值设为3秒”“数据一致性校验精确到小数后两位”。4.2 报告自动化生成管线Agent生成报告的方式很灵活。我在工作目录里放了一个report_templates文件夹里面预置了10份Markdown和HTML模板模板中包含占位符。Agent执行完所有用例后会自动读取执行结果数据库填充对应位置。例如缺陷清单报告模板大致长这样# 缺陷清单报告 生成时间{{generation_time}} 执行批次{{batch_id}} ## 缺陷列表 {{#defects}} ### {{id}} {{title}} - 严重等级{{severity}} - 所属模块{{module}} - 对应用例{{case_id}} - 复现步骤{{steps}} - 实际结果{{actual_result}} - 预期结果{{expected_result}} - 初步定位{{initial_diagnosis}} {{/defects}} ## 风险建议 {{risk_advice}}Agent会根据每个失败用例的日志和上下文生成“初步定位”。比如某个用例失败Agent读取到接口返回500关联到异常日志中的“数据库连接池耗尽”那它会自动把初步定位写成“疑似连接池配置不足”。这种自动化生成的报告最大的好处是格式统一信息完整不会出现某个人写的报告漏掉复现步骤的情况。最大的风险是Agent可能会在定位部分过度推断把不是根本原因的线索当根因。因此我设立了人工复核节点Agent产出的“缺陷清单报告”里所有“初步定位”必须由测试负责人确认后才能转给开发。4.3 测试结论的提取与人工复核报告生成后我并不是直接拿给团队看。第一步是让Agent做一个“自检”把10份报告的关键指标汇总成一个摘要并检查报告之间是否有数据矛盾。比如完整明细说“用例34通过”模块汇总却显示“该模块失败用例包含34”那肯定有问题。这份摘要其实相当于第11份内部报告不会外发只用于校验质量。我看了下整体通过率是92%即66个通过6个失败。失败用例集中在权限变更未刷新、外部接口mock超时、库存基数初始化不准这三个原因。经过人工复核其中2个是测试数据问题重新执行后通过剩下的4个确实是代码缺陷已经记录到缺陷管理系统。报告的数字不是重点重点在于我们能从自动化结果里快速定位真实问题。这比花三天人工整理Excel要高效得多。5. 常见问题与排错清单5.1 安装与调用报错我在部署和运行过程中遇到不少问题挑几个典型的分享。第一个是模型调用超时。第一次跑测试时Agent每一步都要调用模型做决策并发为4的情况下单步决策如果超过60秒任务就卡住。我一开始以为是网络问题后来发现是模型上下文太长。解决方式是精简上下文把执行过长的历史对话定期压缩只保留关键状态和结果。第二个是Agent生成的Python脚本中文字符编码报错。在Windows环境测试时Agent写出的脚本默认保存为UTF-8但控制台是GBK编码导致print中文时崩溃。解决办法是在Agent的初始化指令里加上一句“所有生成的脚本文件头添加# -*- coding: utf-8 -*-并在执行前设置环境变量PYTHONIOENCODINGutf-8”。第三个是数据库连接数耗尽。72个用例密集执行时Agent会频繁建立MySQL连接连接池默认100根本不够。后来在测试数据库中设了max_connections500并让Agent每次操作数据库后主动释放连接。5.2 漏测与误报处理漏测是最可怕的事情。有一次Agent报告“所有用例全部通过”但我知道其中一个用例涉及两个模块之间的事务回滚这个场景如果没有触发异常是不会走回滚分支的。翻看详细日志发现Agent只验证了正常提交路径压根没模拟异常。解决办法是在用例设计阶段明确要求Agent“必须覆盖异常分支”。我在全局指令中增加了规则如果用例中包含“异常”“回滚”“越权”“并发”等关键词必须在执行正常流程后额外执行异常路径验证并在报告中单独标注。经过这条规则补充Agent后续在相关用例中增加了故障注入步骤误报率大幅下降。误报方面则主要靠设置重试机制。对于网络抖动造成的临时失败Agent会重试3次每次间隔10秒。只有3次都失败才判定为用例失败并保留3次尝试的日志供分析。5.3 报告格式错乱的修复另一个常见问题是报告格式化。Agent本身是基于模板填充但如果某个字段内容太长比如异常日志堆栈里有一千行直接渲染到HTML里会让整个报告布局错乱。我让Agent在写入报告前对所有日志类字段做截断超过500字的部分折叠为“详情见日志文件”。还有一次10份报告中有一份是空白的。排查后发现Agent执行汇总任务时读取的文件路径包含中文字符在内部工具链中编码不一致导致找不到结果文件。后来我把所有中间文件的命名统一为英文加数字彻底解决这个问题。经验尽量让Agent在同一个工作目录下读写中间产物不要使用带空格的深层路径。Agent对路径的处理不如人脑灵活容易出幺蛾子。5.4 执行效率调优心得整体72项用例第一次跑耗时约6小时经过调优后稳定在3小时20分钟左右。主要优化手段有三个把不涉及数据依赖的用例并行度从4提升到6但不超过CPU核心数的一半。让Agent对每个用例使用独立的临时数据库schema测试结束直接 drop省去繁琐的数据清理时间。报告生成任务放在所有用例执行完后单独跑不让它占用测试执行资源。说到底Hermes Agent的调度能力本身不错但你需要告诉它哪些步骤可以并行、哪些必须串行。这些约束最有效的表达方式就是在用例表的“依赖模块”列里写清楚Agent会自己读。6. 用 AI Agent 做测试的实际体会这次项目结束之后我对“AI自动化测试”有了更明确的认知。它确实能取代很多重复性验证工作尤其适合回归测试、跨模块数据一致性检查和报告汇总。但指望它完全替代测试工程师也不现实至少在现阶段测试设计能力、业务理解能力和最终风险判断仍然需要人来主导。我个人体会最深的一点是Agent的“聪明”程度取决于你给它输入的测试规范的详细程度。一开始我把测试用例写得比较简略Agent执行时经常自由发挥导致结果不可控。后来我花了两天时间把所有用例的前置条件、步骤、预期结果全部细化执行效率和准确率立刻上来了。所以想让AI替你干好活先要把活路铺平。如果你现在正准备尝试Hermes Agent或者类似的AI Agent做系统测试我的建议是先从一个小模块、20个用例以内的小规模开始跑通之后再扩展到全量。不要上来就挑战上百个用例否则一堆环境问题和工具链问题混在一起你可能分不清是Agent的锅还是自己的锅。另外报告模板提前定义好能省很多事。让Agent按照你习惯的格式输出而不是让它自由发挥这样团队接受度更高。毕竟测试报告是给人看的不是给AI欣赏的。最后再分享一个小技巧每次跑完测试后把Agent的执行日志保留下来并让Agent总结一下本次执行中的规则修正和踩坑点存成一个“经验库”。下一轮测试开始时让Agent先加载这个经验库再执行。实测下来随着轮次增加稳定性和效率会一代比一代好。这就是Agent测试和传统脚本测试最大的不同——它是能“长记性”的。