AI 生成自动化脚本很快，但 “看起来能跑” 和 “长期稳定可维护” 不是一回事。

常见现象：

• 本地能过，CI 不过。
• 单独跑能过，整套跑不稳。
• 今天能过，明天失败。
• 脚本失败后缺少排查信息。
• 失败原因看起来像功能问题，实际是测试数据污染。

下面按测试开发评审视角整理几个高频问题。

1. 选择器不稳定

AI 常见写法：

• 按按钮文本定位。
• 按 class 定位。
• 按页面层级定位。
• 按 nth-child 定位。

这些选择器可能能跑，但稳定性差。

风险：

• 文案调整导致按钮文本失效。
• 样式类名变化导致 class 失效。
• DOM 结构变化导致层级选择器失效。
• 多个相同元素导致误点。

建议优先使用：

• data-testid。
• role。
• label。
• aria 属性。
• 业务唯一字段。

如果页面没有稳定测试标识，应该推动补充，而不是让脚本依赖脆弱选择器。

2. 等待机制依赖固定 sleep

AI 生成脚本时经常写固定等待：

等待 2 秒。
等待 5 秒。

固定等待的问题是：

• 环境慢时不够等。
• 环境快时浪费时间。
• CI 机器负载高时随机失败。
• 接口抖动时不稳定。

更好的等待方式：

• 等元素可见。
• 等按钮可点击。
• 等接口返回。
• 等 loading 消失。
• 等目标数据出现在列表。
• 等业务状态变更完成。

原则：不要等时间，要等状态。

3. 测试数据没有隔离

AI 常默认测试数据已经存在，例如：

• 固定账号。
• 固定商品。
• 固定优惠券。
• 固定订单。
• 固定环境配置。

短期能跑，长期会出现数据污染：

• 账号状态被改。
• 优惠券被使用。
• 订单已支付或已取消。
• 库存被扣减。
• 配置被其他测试修改。

建议脚本明确：

• 数据如何准备。
• 是否动态创建。
• 是否可重复执行。
• 执行后如何清理。
• 并发或多次执行是否互相影响。

没有数据策略的自动化脚本，更像一次性演示。

4. 断言只验证表面成功

AI 常见断言：

• 页面出现 “提交成功”。
• 接口返回 success。
• HTTP 状态码为 200。

这些断言太浅。

自动化脚本应验证业务结果。

示例：创建订单后，应验证：

• 订单是否生成。
• 订单状态是否正确。
• 金额是否正确。
• 库存是否锁定或扣减。
• 优惠券是否占用或核销。
• 列表和详情是否一致。

示例：支付成功后，应验证：

• 支付流水是否生成。
• 订单状态是否变为已支付。
• 权益是否发放。
• 后续查询接口是否一致。

自动化不是只帮你点完流程，而是证明业务结果正确。

5. 失败信息不足

脚本失败后，如果只看到一个断言失败，排查成本会很高。

建议失败时保留：

• 页面截图。
• 当前 URL。
• 请求参数。
• 接口返回。
• 当前用户。
• 关键业务 ID。
• 环境信息。
• 失败前后关键日志。

好的自动化脚本不仅要尽量稳定，还要在失败时容易定位。

6. 硬编码和环境耦合

AI 生成脚本时还容易写入：

• 固定域名。
• 固定账号密码。
• 固定业务 ID。
• 固定时间。
• 固定测试环境数据。

这些都会降低可维护性。

建议检查：

• 环境配置是否外置。
• 账号和密钥是否安全管理。
• 业务 ID 是否动态生成或查询。
• 时间相关断言是否可控。
• 测试数据是否可以在不同环境复用。

推荐审查提示词

请以测试开发评审视角检查以下自动化脚本。

重点看：
1. 选择器是否稳定。
2. 等待机制是否依赖固定 sleep。
3. 测试数据是否独立且可清理。
4. 断言是否验证业务结果，而不是只验证页面提示或接口 success。
5. 失败日志是否足够排查。
6. 是否存在硬编码和环境耦合。

请输出：
- 问题清单。
- 风险等级。
- 可能导致的不稳定表现。
- 修改建议。

脚本内容：
{粘贴脚本}

评审清单

• 是否使用稳定选择器？
• 是否避免固定 sleep？
• 是否有独立测试数据？
• 是否有数据清理机制？
• 是否验证业务结果？
• 失败时是否能快速定位？
• 是否减少硬编码和环境耦合？

AI 可以快速生成脚本初稿，但测试工程师需要继续审查稳定性。

自动化脚本不是能跑一次就算完成，能稳定重复运行、失败后易排查，才算真正进入可维护状态。