传统端到端测试擅长验证确定性的页面行为，却很难覆盖大量接近真实用户表达的操作路径。Amazon Nova Act 提供了另一种思路：让生成式 AI 从产品文档中提取测试意图，再利用智能导航能力执行用户流程，最后把运行轨迹转化为可定位、可排序的问题。真正重要的变化不只是“用自然语言操作浏览器”，而是让 UX 测试可以并行扩展。
把测试用例从脚本提升为用户意图
一条传统 UI 自动化脚本通常紧贴 DOM：查找按钮、填写输入框、等待特定选择器。页面结构稍有变化，脚本就可能失败。面向用户流程的测试则更关注目标，例如：
- 新用户能否完成注册并进入控制台；
- 用户能否找到某个套餐并理解价格差异；
- 结账失败后，页面是否给出可执行的恢复路径；
- 键盘用户能否完成搜索、筛选和提交。
生成式 AI 可以读取需求文档、帮助中心文章或验收标准，将这些材料整理成结构化场景。为了避免模型输出无法执行，场景应使用固定的数据契约，而不是直接生成任意代码。
可以这样定义一个最小场景文件：
id: checkout-existing-user
start_url: https://staging.example.com/login
persona: 已注册且希望快速完成购买的用户
goal: 登录后购买购物车中的商品
steps:
- 使用测试账号登录
- 打开购物车
- 确认商品数量为 1
- 使用测试支付方式完成结账
assertions:
- 页面显示订单确认信息
- 用户可以看到订单编号
- 流程中没有无法恢复的错误
risk: high
tags:
- checkout
- regression
文档生成器需要校验 start_url、goal 和 assertions 等必填字段，并限制允许访问的域名。模型负责扩展覆盖面，测试平台负责约束输出边界。
云端平台需要拆开生成、执行和分析
要扩展到数百条用户流程，不能把所有工作塞进一个长时间运行的进程。可以将平台拆成四个阶段：
- 场景生成：读取产品文档，生成带版本号的 YAML 或 JSON 场景。
- 任务调度：将每个场景写入队列，并附加环境、浏览器和重试策略。
- 隔离执行：每个 worker 启动独立浏览器会话，通过 Nova Act 完成目标。
- 结果分析：汇总轨迹、截图、耗时和失败原因，输出按影响范围排序的问题。
在 AWS 上可以这样实践：用对象存储保存场景和截图，用消息队列缓冲任务，用容器任务或 Kubernetes Job 承载浏览器 worker，再把结构化结果写入数据库。具体服务不是关键，关键是让一个场景对应一个可重放、可超时、可追踪的执行单元。
下面的 Kubernetes Job 展示了 worker 的基本部署方式。运行前需要替换镜像地址、测试站点和 Secret 名称；Nova Act 的认证变量应以当前 SDK 文档为准。
apiVersion: batch/v1
kind: Job
metadata:
name: ux-flow-worker
spec:
backoffLimit: 1
activeDeadlineSeconds: 900
template:
spec:
restartPolicy: Never
containers:
- name: worker
image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/ux-worker:latest
env:
- name: SCENARIO_FILE
value: /work/scenarios/checkout.yaml
- name: ALLOWED_HOSTS
value: staging.example.com
- name: NOVA_ACT_API_KEY
valueFrom:
secretKeyRef:
name: nova-act-credentials
key: api-key
resources:
requests:
cpu: "1"
memory: 2Gi
limits:
cpu: "2"
memory: 4Gi
并发量不应只由队列长度决定，还要考虑测试环境容量、账号池、第三方 API 限流，以及同一数据被多个流程同时修改的风险。
用 Nova Act 执行结构化场景
下面是一个可改造的最小 Python worker。它采用公开示例中常见的 NovaAct 上下文管理方式，将 YAML 中的步骤逐条交给智能导航代理。不同版本 SDK 的初始化参数和结果对象可能变化，接入时应按所使用版本调整；测试账号也应来自专用测试环境，而不是生产账户。
安装依赖并设置凭证：
python -m venv .venv
source .venv/bin/activate
pip install nova-act PyYAML
export NOVA_ACT_API_KEY='replace-with-your-key'
python worker.py checkout.yaml
worker.py：
import json
import sys
import time
from pathlib import Path
from urllib.parse import urlparse
import yaml
from nova_act import NovaAct
def load_scenario(path: str) -> dict:
scenario = yaml.safe_load(Path(path).read_text(encoding="utf-8"))
required = {"id", "start_url", "goal", "steps", "assertions"}
missing = required - scenario.keys()
if missing:
raise ValueError(f"Missing fields: {sorted(missing)}")
allowed_hosts = {"staging.example.com"}
host = urlparse(scenario["start_url"]).hostname
if host not in allowed_hosts:
raise ValueError(f"Host is not allowed: {host}")
return scenario
def run(path: str) -> None:
scenario = load_scenario(path)
started = time.time()
records = []
try:
with NovaAct(starting_page=scenario["start_url"]) as agent:
for step in scenario["steps"]:
result = agent.act(step)
records.append({"type": "step", "text": step, "result": str(result)})
for assertion in scenario["assertions"]:
prompt = f"Verify this condition without changing application data: {assertion}"
result = agent.act(prompt)
records.append({"type": "assertion", "text": assertion, "result": str(result)})
status = "completed"
error = None
except Exception as exc:
status = "failed"
error = f"{type(exc).__name__}: {exc}"
report = {
"scenario_id": scenario["id"],
"status": status,
"duration_seconds": round(time.time() - started, 2),
"error": error,
"records": records,
}
print(json.dumps(report, ensure_ascii=False, indent=2))
if __name__ == "__main__":
if len(sys.argv) != 2:
raise SystemExit("Usage: python worker.py SCENARIO.yaml")
run(sys.argv[1])
这个示例刻意保留了清晰的输入和输出边界。生产实现还应采集截图、页面 URL、浏览器控制台错误、网络失败和每一步耗时，并将敏感字段从日志中清除。
分析失败，而不是只统计通过率
智能代理执行失败并不必然等于产品缺陷。失败可能来自页面问题，也可能来自测试账号失效、环境不稳定、导航模型误判或场景本身含糊。因此，分析层至少需要区分：
- 产品阻塞：用户无法继续，页面也没有明确恢复方式；
- 体验摩擦：流程能够完成，但出现反复导航、标签歧义或过长等待；
- 测试设施问题：浏览器崩溃、凭证过期、环境返回 5xx；
- 代理不确定性：相同场景多次执行得到不一致结果；
- 场景缺陷：目标依赖未准备的数据，或验收条件无法观察。
对高风险流程可以重复执行三到五次，并保存成功率和路径差异。如果一次失败、四次成功，应先标记为不稳定，而不是立即阻断发布。涉及付款、删除和权限变更的流程，则应在隔离数据集上运行，并设置人工审批或明确的动作禁区。
上线前的采用清单
落地这类平台时，建议从少量高价值旅程开始：注册、登录、搜索、结账和账户恢复通常比穷举页面元素更有价值。上线前应确认以下事项：
- 测试只访问允许域名，并与生产数据隔离；
- 每个场景拥有明确目标、前置条件和可观察断言；
- worker 有超时、重试上限和全链路追踪标识；
- 截图与日志经过密钥、个人信息和支付数据脱敏；
- 确定性回归仍由常规自动化测试承担；
- AI 流程测试用于发现未知路径、文案歧义和交互摩擦；
- 发布门禁只采用经过重复验证且误报率可控的指标。
Nova Act 的价值不在于替代现有测试栈，而在于补充传统脚本难以覆盖的用户意图。把生成、执行和分析做成可审计的流水线之后，团队才能在扩大覆盖面的同时，知道每一个结论来自哪里，也知道何时不应该相信它。