Hermes实战一句话搞定ERP系统自动化测试从72项用例到10份报告的全过程做测试最怕什么不是用例写不出来而是版本上线前那几百条回归用例翻来覆去地在本地点来点去一天下来眼睛酸、精力空最后还要手工把结果整理成报告发给项目组。我做后端测试六年多这事几乎每个月都要来一遍。直到上个月公司一套自研ERP系统要发布2.2版本涉及采购、库存、财务、权限管理多个模块的改动我拿到手的回归用例是72项。按以前的节奏这套用例我一个人闷头点至少需要两天点完还要花一整个下午整理测试报告项目组催得紧产品在等开发在等领导也在问。我一咬牙决定把之前研究过的Hermes Agent拉出来真正用一次。结果比我预想中顺利我只给Agent下了一条总指令它自动完成了用例拆分、逐项执行、结果校验最后生成了10份分模块的测试报告。整个过程大约4小时其中我只在中途介入处理了两次环境问题。这篇就把整个实战过程写透从为什么选Hermes Agent、怎么部署到指令怎么设计、72项用例怎么被拆解执行、10份报告怎么来的以及中间踩过的坑全部摊开来讲。适合正在做ERP系统测试、或者想在项目里尝试用Agent辅助做自动化测试的团队参考。1. 项目背景当72项回归测试撞上版本发版节点1.1 先交代一下测试对象和痛点被测系统是我们内部运行了两年的ERP系统后端是Java Spring Cloud前端管理后台是Vue数据库MySQL另外还接了RabbitMQ做消息队列。这次2.2版本主要改了三个大方向一是采购入库的批次规则变了二是财务的发票校验逻辑重构了三是组织权限模型从单一角色改成了角色数据范围。这三个方向看似不大但影响面波及了采购、仓储、财务、系统管理四个模块。我手上这套72项回归用例是近一年多逐步积累起来的分布大概如下采购模块18项、库存与批次管理15项、财务发票与结算14项、系统权限与用户管理12项、报表查询与导出8项以及公共流程5项。用例里有功能验证有数据流转校验有权限隔离检查还有几项是历史Bug的回归。以前这套用例点下来快的话一天半慢的话两天光是登录、切用户、准备前置数据就要反复折腾。更烦的是结果记录我一边点一边在Excel里标Pass/Fail稍不注意漏标了还得回过去重点一遍。这次不一样的地方在于发版节点卡得很死留给测试的时间只有三天除了回归还要做新功能验证。所以那时候我最需要的不是多一个人手而是一个能理解测试用例、能自己操作界面或调用接口、还能自动汇总结果的执行引擎。说白了我要一个“懂测试的AI执行者”。1.2 为什么最终选了Hermes Agent其实早在半年前我就关注过几类自动化测试工具从Selenium、Appium这类传统UI自动化框架到Pytest、TestNG这类接口层框架再到Playwright这类新锐无头浏览器方案都在项目里试过。它们各有各的好但放在我这个场景下有个共同问题它们解决的是“脚本怎么跑”不解决“用例怎么来”。我还是得手动把72条用例翻译成代码工作量一点没少而且用例一多脚本维护成本直线上升。Hermes Agent给我的第一感觉是反过来的——它允许我用自然语言定义一个代理把“执行一套回归测试”当作一个任务目标由Agent自己拆解步骤、调用工具、返回结果。它本质上是一个AI Agent框架底层支持大模型可以通过工具调用去执行命令、操作浏览器、读写文件、生成报告。对我来说这正好把“翻译用例”的工作省了我不需要把每条用例写成一段代码而是把用例的正常步骤、校验点喂给Agent让它自己理解并执行。我用一张表给当时的选型做个直观对比方案用例表达方式需要维护成本能生成报告吗适合这个场景吗手工测试人肉执行低手工整理不适合太慢Selenium脚本Python/Java代码高要另写勉强Pytest接口自动化代码数据驱动中高有插件部分适用Playwright代码录制中要另写部分适用Hermes Agent自然语言指令中低自动生成非常适合当然Hermes Agent也不是万能的。它本质上依赖大模型的推理能力如果用例描述模棱两可它执行起来也会跑偏。所以在正式跑之前我花了不少精力把用例描述规范成Agent能精确理解的语言。这一步做完之后后面的执行反而非常顺畅。2. Hermes Agent 部署和初始化本地环境到底怎么搭2.1 部署方式我选的本地部署数据留在自己手里Hermes Agent有两种典型的使用方式一种是用它的云端托管服务另一种是在自己的机器或服务器上本地部署。考虑到我们ERP系统在内网测试环境的数据库和接口不能暴露到外网我直接就选了本地部署。本地部署其实不复杂前提是机器上得有Python环境。我用的是一台Windows 11工作站配置是i7-12700、32GB内存、一块RTX 3060显卡。虽然Hermes Agent不强制要求GPU但后面要跑本地推理或者同时并行处理多个Agent任务时显存大了确实从容很多。部署步骤拆开看就三步。第一步安装Python 3.10以上版本并确保pip可用。第二步用git把仓库克隆到本地工作目录。第三步创建虚拟环境安装依赖依赖项。Windows下如果遇到某些编译类依赖报错常见的是缺Microsoft C Build Tools装上就好。这一步我走了点弯路后面在问题章节详细说。装完之后使用CLI入口命令进行初始化配置。它会提示你选择默认的LLM服务商支持OpenAI兼容接口、本地Ollama等方案。我这边因为内网策略统一走的是公司内网部署的OpenAI兼容API网关只需要在初始化时填入Base URL和API Key就可以。这里有一点值得注意密钥和配置默认存在用户主目录下的配置文件夹里建议全团队统一规范管理避免各写各的配置导致后来的协作混乱。2.2 关键配置项和参数选择逻辑初始化完成后配置文件里有一系列Agent行为相关的参数。我重点调整过四个。第一个是任务执行的最大步数上限。默认值跑简单任务够用但我这次72项用例显然属于大型任务如果上限太低Agent会在没跑完时就自我了断。我把它调到了200保证它能把用例尽可能多地执行完不至于中途因步数耗尽而停车。第二个是并发度设置。Hermes Agent支持同时跑多个子任务但这个并发度不能盲目调高。我一开始尝试并行8个Agent结果测试环境的数据库连接池先崩了一堆接口超时。后来根据我们ERP系统的实际承受能力把并发调整到3每3个用例一组执行稳定很多。第三个是日志级别。测试过程中我需要回查每个环节的决策逻辑所以把日志级别设成DEBUG记录Agent每一步的思考、工具调用和返回结果。这样一旦出现Fail的用例我能顺着日志判断是Agent执行错乱还是系统真的有问题。第四个是自定义工具配置。Hermes Agent支持通过工具注册的方式添加自定义可调用工具。这次我用Python给Agent写了一个只读数据库校验工具专门用来做数据层面的断言。因为光靠界面上的文案判断通过还是失败还不够有些用例必须落到数据库看字段值。比如“采购入库后库存数量增加5”这种校验界面显示的是新增后结果但中途是否真的按批次规则取数得查库才知道。安装和配置这些事很多人会忽略一个细节环境的干净度。我建议把Hermes Agent装在一个独立的Python虚拟环境里不要和项目已有的依赖混在一起。原因很简单Hermes Agent的依赖涉及异步框架、pydantic版本等和项目里其他库的版本要求容易打架。我第一次就踩了这个坑——同一个Python环境里既有旧版flask又有pydantic版本冲突导致Agent起不来最后是重建虚拟环境才解决的。3. 一句话指令如何驱动72项测试自动执行3.1 那条“一句话指令”是怎么设计出来的有朋友看到“一句话搞定”可能会觉得夸张难道真的就输入“给我测完所有用例”这么简单当然不是。这里的“一句话”指的是入口指令的简洁但背后一定要有足够清晰的用例集和规则沉淀。打个比方你跟一个实习生说“把这批货盘一下”他如果不知道货在哪、盘点的标准是什么这句话等于没说。给Agent下指令也是一样的道理。我那条总指令写的大意是“根据测试用例目录下的erp_2.2回归用例集逐项执行72条用例用例包含前置条件、操作步骤和预期结果执行完成后标注每条的通过或失败状态并按模块汇总生成测试报告。”想让这句话真正生效前提是我已经把72条用例转换成了Agent可读的结构化文档。这不是让Agent临时理解一堆零散需求而是给它一份遵循统一格式的“操作手册”。对任何想做Agent驱动测试的团队这一步值得多花时间精雕细琢。另外我在总指令里还加了一条约束“遇到登录态失效或环境报错时记录错误详情并跳过该用例不要无限重试。”这是经验的产物。一开始我没加这条约束Agent在遇到某个接口500错误时反复重试了十几次浪费了大量时间。3.2 把历史Excel用例重构成Agent友好的标准格式原先的72项用例散落在Excel里格式不统一有的写“点击保存按钮”有的写“保存成功”有的前置条件缺失有的预期结果含糊。直接原样丢给Agent是不现实的。我统一改成Markdown格式每个用例文件包含以下字段用例编号、所属模块、用例标题、前置条件、测试数据、操作步骤、预期结果。操作步骤我坚持按自然语言写清楚避免太口语化。比如对于“采购订单审核通过后生成入库任务”这条用例我写的是操作步骤 1. 使用采购主管账号登录系统 2. 进入采购订单列表页 3. 选择订单号PO202410001点击审核 4. 审核通过后进入仓储模块的入库任务列表 5. 查询该订单对应的入库任务是否存在 预期结果 1. 审核操作返回成功 2. 入库任务列表中新增一条与PO202410001对应的记录这样的描述Agent不需要猜每个动作都有明确落点。而且我保留了“使用采购主管账号”这种角色信息因为这次权限模型改了用错账号会导致用例失败。72个用例文件放在一个约定的目录下命名方式统一例如“PUR_001_采购订单审核生成入库任务.md”。Agent遍历目录自然就能按顺序处理。这里还有一个小技巧在文件名里加上模块前缀后续生成分模块报告时直接按文件前缀聚合省去了让Agent理解复杂分类的步骤。说实话把Excel转成Markdown这件事本身花了我大半天时间。但做完以后不仅Hermes Agent能用以后任何自然语言驱动的测试框架都能复用这套用例文件边际成本是一次性的。3.3 Agent实际执行过程任务拆解、工具调用与中途介入真正跑起来的时候我盯着屏幕观察了一段时间。Hermes Agent确实不是机械地一条一条执行它会自己规划一个执行方案。我观察到的逻辑大致是先扫描目录统计用例数量和模块分布然后按模块分组设定执行顺序再根据每条用例的操作步骤判断需要调用哪些工具——涉及界面操作的调用浏览器自动化工具涉及数据校验的调用我注册的数据库查询工具。执行过程中它还会做一件很有价值的事步骤之间的上下文关联。举例来说权限模块的用例要求“新建一个带数据范围的子账号然后验证该子账号只能看到指定组织的数据”。Agent会先完成创建账号的用例再自动拿这个账号的会话去执行后面的数据隔离验证。这种在用例之间保持状态的能力是传统自动化脚本很难做到的。当然完全无人值守也不现实。中途我介入过两次。一次是登录验证码问题——测试环境启用了图形验证码Agent在识别验证码这一环消耗了很久。我的处理方式是把测试环境的验证码功能临时关闭并且调整了登录工具的参数。另一次是一个用例的前置数据被之前失败的用例弄脏了Agent执行的“新建客户”步骤因为客户编码重复而报错。我介入清理了测试数据重新触发执行。整轮72项用例最终执行结果通过69项失败3项。失败的3项里有2项被确认是系统真实缺陷——一个权限范围在跨组织查询时没有过滤干净另一个是批次号在并发生成时出现了重复还有1项是用例本身的前置数据描述不完整跟Agent无关属于我准备用例时的疏漏。这个结果其实很理想Agent不只承担了执行工作还帮我精准暴露了产品问题。4. 10份测试报告是怎么自动生成出来的4.1 按模块汇总报告的设计逻辑报告这个环节我一开始就明确不能等测完再手动整理而是让Agent在每完成一个模块的用例后立即生成该模块的报告草稿最后再自动汇总。这样既分摊了生成压力也避免在执行结束后大量结果集中涌出导致报告错乱。10份报告的拆分逻辑如下采购模块1份库存与批次管理1份财务发票与结算1份系统权限与用户管理1份报表查询与导出1份公共流程1份这是6份模块报告再加上Bug汇总报告、执行过程日志报告、测试结果趋势对比报告、遗留问题说明报告一共10份。模块报告里包含的内容该模块覆盖的用例数量、执行通过率、失败用例清单、失败原因初判、相关风险点。Bug汇总报告单独列出已确认的系统缺陷注明复现步骤和影响范围这份报告可以直接导出给开发组定位问题。执行过程日志报告则记录了Agent每步调用的工具和结果便于追溯。4.2 报告生成的技术实现方式与效果Hermes Agent生成报告的方式不是简单地套模板。它在执行完一个模块后会把该模块所有用例的通过/失败状态、失败时的错误信息、操作日志汇总成结构化数据再调用自定义报告工具渲染成Markdown格式最后转成HTML或PDF。因为每个用例文件里有明确的“所属模块”字段聚合过程比想象中稳定。这里分享一个很关键的做法我提前定义了一套报告模板规范规定了报告里必须包含哪些小节、失败用例怎么高亮、Bug等级怎么标注。Agent生成报告时会严格按这个规范来避免每次生成的结构五花八门。如果哪天需要调整报告样式只需要改模板规范不用改Agent本身。生成的10份报告实际效果比我预想中好。以前手工整理报告为了格式统一我要一条条Copy结果、调字号、调颜色半天时间就耗在Excel和Word之间。现在Agent输出的是结构清晰、重点突出的Markdown报告我只需要在末尾补充一小段我的测试结论就可以直接发到项目群。这不光是省时间的问题报告的客观性和一致性也大幅提升了。有一点要提醒大家Agent生成的失败用例描述详细程度取决于它的观察粒度。如果它只是通过界面文案判断成功失败报告里的失败原因就只剩下文案对比。所以我在注册工具时特别加了数据层校验这样报告里能明确写出“接口返回成功但数据库库存字段未变更”这类高价值结论。这也是我这批报告能直接推动开发修改的关键原因。5. 实战过程中踩过的坑和排查避坑经验5.1 环境准备阶段的坑先说说安装环境的坑。第一台测试机上我图省事直接用全局Python安装了Hermes Agent及其依赖结果系统里另一个监控脚本依赖的旧版本pydantic核心库被自动升级直接导致那个监控脚本崩溃。排查了半天才发现是依赖冲突。后来我所有Agent相关环境都强制使用虚拟环境项目脚本和环境完全隔离这个坑才算彻底填上。第二个坑是Windows下的编译报错。Hermes Agent依赖的一部分原生扩展在Windows上需要编译如果没有安装对应版本的Visual C Build Tools会在安装阶段报一堆红字错误。解决办法是提前安装好构建工具或者在条件允许的情况下改用Docker方式部署。如果团队里主要是Windows环境我更推荐Docker省掉很多原生依赖的烦恼。第三LLM服务地址配置。公司内网接的是OpenAI兼容协议接口但有些模型供应商的接口路径需要后缀/v1配置填错会导致连通性测试不通过。建议初始化完成后先跑一个最小任务验证连通性确认能正常返回结果后再开始正式用例不要上来就执行大任务。5.2 用例执行过程中的坑执行阶段最大的坑是登录态管理。ERP系统登录后会生成一个Token有效时间通常是两小时。Agent在跑长任务时如果中途Token过期后续所有涉及界面的用例都会失败。我最初的方案是让Agent每隔一段时间检测登录态过期后自动重新登录但这可能导致正在进行的数据操作丢失。后来干脆把测试环境的Token有效期临时调成了8小时跑完再改回来。对测试环境做这类临时配置调整是合理的但一定要记得恢复原状。第二个坑是前置数据的相互污染。ERP很多用例不是孤立的比如“采购入库”会改变库存数量“新建供应商”会影响后续的检索结果。如果并行执行时不注意隔离不同Agent实例之间会发生数据竞争导致用例间歇性失败。我这次的解决办法是把具有数据依赖关系的用例按顺序放在同一个串行队列里只有完全独立的用例才允许并行。执行前我还做了一个数据快照万一跑乱了能快速恢复初始状态。第三个坑和Agent本身的判断有关。某些用例预期结果描述里包含“系统提示保存成功”类似的话但实际界面上提示文案可能是“操作成功”Agent按字面匹配就会误判失败。我后来在用例文件里把预期结果写得更加严谨用“操作返回成功提示不限定具体文案”这类表述减少Agent的机械匹配。这个细节看似微小却能直接影响通过率数据的真实性。5.3 报告结果可信度的坑最后聊一个特别容易被忽视的坑Agent生成的“通过”结论不一定为真。界面操作成功和业务逻辑正确是两回事。我第一次跑完十几条采购用例界面上全都显示操作成功Agent也标记为Pass但后来抽查数据库发现部分单据的部门字段没按新规则写入。因为Agent只看界面没做数据断言。这个教训直接推动我把数据校验工具做成了标准配置。此后我在每个用例文件里都补充了“数据库校验点”字段Agent执行完界面操作后会自动执行对应SQL查询把返回值和预期值做对比。有了这一层报告里的Pass才真正有说服力。这一条也是我最想分享给团队的经验。6. 对整个方案的复盘和再改进这次实战跑通的当天我就把流程沉淀成了文档并制定了后续优化方向。第一用例文件全面迁移到这种结构化Markdown格式后续新用例直接按规范编写为任何Agent驱动测试打好基础。第二把登录验证码、Token有效期这类环境依赖统一通过环境初始化脚本处理减少人工介入。第三我正在尝试让Agent在发现Bug后自动抓取当时的界面截图和关键日志一并附到报告里进一步降低开发的沟通成本。在整个过程中我个人最深的体会是Agent不会凭空替代“测试设计”这件事但它能把“测试执行”的重复劳动压缩到一个不可思议的程度。我花了大半天整理用例格式换来的是原来两天的执行时间缩短到4小时而且报告质量比手工整理更稳定。对任何测试团队来说提升效率的杠杆点不在工具本身而在你愿不愿意事先把用例规范、数据校验规则、报告模板这些基础架构做扎实。基础夯实之后自然语言驱动执行就是水到渠成的事。假如有团队正准备尝试这条路我给的建议是不要一上来就拿大而全的系统挑战先挑一个模块、几十条用例试跑跑通后再逐步铺开。过程中每一次执行日志都值得保留下来它们会告诉你Agent在哪些环节理解有偏差、哪些环境配置是短板。迭代几轮以后你会拥有一套“自己的”Agent测试体系而不只是套用别人的模板。到那个时候再回头看那些曾经让人头皮发麻的回归测试需求心态会完全不一样。