【Hermes系列8】Hermes 生成的测试代码能直接用吗？我 Review 了 10 个脚本（附真实评测数据）

Hermes 生成的代码，我打了 71 分（附 Review 清单）｜ AI 测试代码质量评估：20% 可直接用，40% 需修改，40% 要重写

这是 Hermes 系列的第 8 篇，也是深度分析篇。

前 7 篇我们解决了：是什么、怎么用、实战场景、CI 集成。但还有一个灵魂问题：

Hermes 生成的测试代码，质量到底怎么样？能直接用吗？需要人工 Review 吗？

作为一个测试老兵，我搭建了一个真实的电商演示系统，让 Hermes 生成了 10 个测试脚本，用专业测试的视角逐一评审。

今天这篇，我把评估结果完整分享给你。

包括：
- 评估维度（5 个核心指标）
- 评分结果（平均分 70.9/100）
- 典型问题（4 大类 90 个小项）
- 改进建议（如何让 Hermes 生成更好的代码）
- Review Checklist（可直接用）
-真实评测数据（源码开源）

我承诺一个结果：你照着本文的 Checklist 走，10 分钟内能评估任何 Hermes 生成的测试代码。

02

评估背景

为什么做这个评估？

Hermes 系列发布后，后台收到最多的问题是：

"周周，Hermes 生成的代码我不敢直接用，怎么判断质量？" "AI 写的测试脚本，需要人工 Review 吗？Review 什么？" "有没有一个清单，能帮我快速评估代码质量？"

作为测试我深知：代码质量决定维护成本。

一个写得不好的测试脚本，短期能跑，长期是债。

所以我做了这个评估——给 Hermes 生成的代码一次系统性体检。

10 个脚本的来源：

演示系统：Flask 电商系统（用户登录、商品管理、订单管理）

评估时间：2026-04-15（实测）

评估方法：
1. 静态代码分析（不运行，看代码）
2. 动态执行验证（运行，看结果）
3. 自动化评审脚本（Python + Review Checklist）

03

评估维度

我定义了 5 个核心维度，每个维度 20 分，总分 100 分：

为什么这样权重？

定位器稳定性 (30%) + 断言覆盖率 (25%) = 55% 这是测试脚本的核心价值： - 定位器不稳 → 脚本 flaky（时过不过） - 断言不全 → 测了等于没测 可读性和异常处理可以后期优化，但核心质量必须一开始就过关。

04

评估结果

总体评分：

分级统计：

结论：

- 20% 可直接用 → Hermes 能胜任简单场景 - 40% 需小幅修改 → 主流情况，人工 Review 有价值 - 40% 需大幅重写 → 复杂场景仍需测试专家介入 Hermes 的定位：快速生成初版，减少重复劳动 不是：完全替代人工测试工程师

📊 评测详情：

05

各维度得分详情

维度 1：代码可读性（平均分 76/100）

好例子：

# ✅ 好的命名 def login_with_valid_credentials(): """使用有效凭据登录系统""" username = "admin" password = "123456" login_page.enter_username(username) login_page.enter_password(password) login_page.click_login_button()

坏例子：

# ❌ 坏的命名 def test1(): a = "admin" b = "123456" page.fill("#username", a) page.fill("#password", b) page.click("#login-btn")

维度 2：定位器稳定性（平均分 68/100）⭐ 最弱项

典型问题：

# ❌ 问题 1：XPath 写死（页面一变就挂） page.click("/html/body/div[1]/div[2]/div[3]/button[2]") # ✅ 改进：用 ID 或 role page.click("#submit-btn") page.get_by_role("button", name="提交").click()

# ❌ 问题 2：缺少等待（竞态条件） page.click("#login-btn") assert page.url == "/home" # 可能页面还没跳转 # ✅ 改进：显式等待 page.click("#login-btn") page.wait_for_url("/home", timeout=5000) assert page.url == "/home"

# ❌问题 3：CSS 选择器过于复杂 page.click(".container > div:nth-child(3) > form > input:nth-child(2)") # ✅ 改进：简化选择器 page.click("#username")

维度 3：断言覆盖率（平均分 71/100）

典型问题：

# ❌ 问题 1：只验证成功，不验证失败 def test_login(): page.fill("#username", "admin") page.fill("#password", "123456") page.click("#login-btn") assert page.url == "/home" # 只验证成功场景 # ✅ 改进：覆盖失败场景 def test_login_success(): # 成功场景 ... def test_login_wrong_password(): # 失败场景：密码错误 page.fill("#username", "admin") page.fill("#password", "wrong") page.click("#login-btn") assert "密码错误" in page.text_content(".error-message")

# ❌ 问题 2：断言太弱 assert page.url # 只检查 URL，没检查内容 # ✅ 改进：多重断言 assert page.url == "/home" assert "欢迎" in page.text_content("h1") assert user_info.is_visible()

维度 4：异常处理（平均分 74/100）

典型问题：

# ❌ 问题 1：没有超时设置 page.click("#submit-btn") # 如果按钮加载慢，可能卡死 # ✅ 改进：设置超时 page.click("#submit-btn", timeout=10000)

# ❌ 问题 2：失败时没有截图 try: assert page.url == "/home" except AssertionError: pass # 失败时什么都不做 # ✅ 改进：失败时截图 try: assert page.url == "/home" except AssertionError: page.screenshot(path="screenshots/login_failed.png") raise

维度 5：可维护性（平均分 78/100）

典型问题：

# ❌ 问题 1：测试数据硬编码 def test_login(): page.fill("#username", "admin") page.fill("#password", "123456") # ✅ 改进：配置分离 TEST_ACCOUNTS = { "admin": {"username": "admin", "password": "***"}, "user": {"username": "testuser", "password": "***"} } def test_login(account_type="admin"): account = TEST_ACCOUNTS[account_type] page.fill("#username", account["username"]) page.fill("#password", account["password"])

# ❌ 问题 2：重复代码 def test_login_success(): page.goto("http://localhost:5000/login") page.fill("#username", "admin") page.fill("#password", "123456") page.click("#login-btn") def test_login_wrong_password(): page.goto("http://localhost:5000/login") page.fill("#username", "admin") page.fill("#password", "wrong") page.click("#login-btn") # ✅ 改进：抽取公共方法 def navigate_to_login(): page.goto("http://localhost:5000/login") def login(username, password): page.fill("#username", username) page.fill("#password", password) page.click("#login-btn")

06

问题分类统计

问题分布：

💡 关键发现：

1. 代码结构问题最多（61%）→ 主要是缺少文档和配置分离 2. 异常处理普遍不足（31%）→ AI 倾向于生成"快乐路径"代码 3. 定位器问题较少（1%）→ Hermes 默认使用 ID 选择器，表现良好

07

关键发现与洞察

基于本次评测的 10 个脚本和 90 个问题项，我有 3 个核心洞察：

洞察 1：Hermes 擅长"形"，不擅长"神"

TEXT

"形" → 代码结构、选择器使用、基本流程（得分 80+） "神" → 异常处理、边界思考、质量意识（得分 30-40）

这很合理。AI 学习的是代码的"表象"，但测试的"灵魂"是质疑和防御思维。

洞察 2：AI 生成的代码，像初级测试工程师写的

共同特点： - 能跑通"快乐路径"（Happy Path） - 缺少异常场景思考 - 不会主动加文档和注释 - 需要 Code Review 指导

这不是问题，而是定位。Hermes 的价值是帮你快速生成初版，然后你来当 Reviewer。

洞察 3：Prompt 质量决定代码质量的上限

同样的登录场景，我做了对比实验：

你给 Hermes 的上下文越详细，它生成的代码越接近你的期望。

08

下篇预告

这篇文章只讲了"评测结果"，但更重要的是"如何改进"。

下篇《Hermes 生成代码质量提升指南：从 70 分到 90 分的 5 个技巧》我会讲：

✅ 改进实战 1：如何补充异常处理（50 分 → 85 分） ✅ 改进实战 2：如何优化等待策略（消除固定等待） ✅ 改进实战 3：如何强化断言（从 1 个到 5 个） ✅ Prompt 技巧：4 个让 Hermes 生成更好代码的方法 ✅ 迭代优化：如何让 Hermes 逐步改进代码 ✅ Review 工具：自动化评审脚本使用说明

预计发布时间：明天（关注我，不错过更新）

源码获取：私信

09

结论与建议

Hermes 的定位：

✅ 适合： - 快速生成测试脚本初版 - 减少重复劳动（如 CRUD 测试） - 标准化场景（登录、查询、列表） - 测试数据准备 ❌ 不适合： - 完全替代人工测试工程师 - 复杂业务逻辑测试 - 高可靠性要求的场景（如金融、医疗） - 需要深度领域知识的场景

我的建议：
1.用 Hermes 生成初版（节省 70% 时间）
2.人工 Review 和优化（花 30% 时间保证质量）
3.建立团队规范（Review Checklist）
4.持续迭代（根据反馈优化提示词）

ROI 计算：

传统方式： - 写一个测试脚本：30 分钟 - 10 个脚本：300 分钟（5 小时） Hermes + Review： - 生成初版：5 分钟 - Review + 优化：10 分钟 - 10 个脚本：150 分钟（2.5 小时） 效率提升：50% 质量：可控（有 Review）

11

谢谢你看到这里。

这篇可能是系列里最硬核的一篇——用 10 个脚本换你一个清晰的判断框架。

Hermes 生成的代码，71 分，及格以上，优秀未满。

但这正是 AI 工具的正确打开方式：

AI 生成初版（70 分）+ 人工 Review 优化（+20 分）= 90 分高质量代码 不是让 AI 替代你 而是让 AI 放大你的价值

留言告诉我：
- 你用 Hermes 生成过代码吗？质量如何？
- 你最关心代码的哪个方面？
- 你有自己的 Review 清单吗？

每一条留言，我都会看，都会回。

AI 生成的代码，71 分；人工 Review 的价值，29 分；合起来才是 100 分。

P.S. 如果你不想错过更新，记得点个在看或者分享到朋友圈。

P.P.S. Hermes 系列共 15 篇，这是第 8 篇。建议收藏，方便后续查阅。

（全文约 6500 字，阅读时间约 18 分钟）

动手试试

读完这篇文章，你可以：

1. 用 Review Checklist 评估你生成的测试代码
2. 根据问题项，让 Hermes 迭代优化
3. 下载源码，复现本次评测
4. 在留言区分享：你给 Hermes 代码打几分？

别等完美，先跑起来。迭代，是通往优秀的唯一路径。

作者：测试员周周，14 年测试经验，专注 AI+ 测试实战