企业官网建设流程全解析

AI 自动测试是最近一年多热度持续走高的方向。很多人以为“AI 测试”就是让 AI 写测试用例，或者用 ChatGPT 生成一段脚本，但实际上，从测试用例设计、自动化脚本生成、测试数据构造，到页面元素定位、断言分析、失败重试，再到测试报告生成，AI 都能深度参与。这套教程我整理了很长时间，筛选了大量资料，把 B 站上关于 AI 自动测试最实用、最系统的内容做了一个整合，涵盖了从入门到进阶再到项目落地的完整链路，希望能帮你少走弯路。

在实际落地 AI 自动测试时，大家最大的困惑往往是这几个：AI 生成的脚本到底能不能直接用？如何让 AI 理解复杂的业务场景？测试数据怎么构造才够真实？已有的自动化测试框架如何与 AI 能力结合？

这篇文章不会只停留在“AI 能写脚本”这个层面，而是从测试理论、AI 辅助用例设计、自动脚本生成、持续集成、失败定位、数据构造等方面，成体系地告诉你 AI 自动测试到底怎么落地。全文会搭配大量可运行的代码示例、配置片段和排查思路，建议先收藏再阅读。

1. 背景与核心概念：AI 自动测试到底是什么

1.1 从传统自动化测试到 AI 自动测试

传统的自动化测试，核心流程是“手工编写脚本 + 维护测试数据 + 定时执行”。它的痛点非常明显：

• 脚本编写成本高，一个中等规模的 Web 项目，UI 自动化用例动辄几千条，每条都需要人工维护定位器和业务逻辑。
• 页面结构一变，定位器就失效，维护成本占比往往超过开发成本。
• 测试数据构造困难，尤其是复杂业务场景下的数据组合。
• 断言设计靠经验，容易漏测或者过测。
• 失败分析需要人工介入，半夜跑完的用例第二天早上一看红了一大片，还得一条条查日志。

AI 自动测试并不是要完全替代这些流程，而是把 AI 能力嵌入到测试生命周期中，重点解决以下问题：

1. 根据需求描述自动生成测试用例。
2. 根据页面结构和业务逻辑自动生成自动化脚本。
3. 自动识别页面元素变化并修复定位器。
4. 智能生成贴近真实场景的测试数据。
5. 自动分析失败原因并给出修复建议。
6. 自动生成测试报告和风险评估。

一句话总结：AI 不会让测试人员失业，但会用 AI 的测试人员会逐步拉开差距。

1.2 常见的 AI 测试技术路线

1.3 需要掌握的基础能力

在真正接触 AI 自动测试工具前，建议先打好这些基础：

• 至少掌握一种编程语言，推荐 Python 或 Java。
• 熟悉一种自动化测试框架，比如 Selenium、Playwright、Pytest、JUnit。
• 了解基本的 Prompt 编写思路，比如如何描述测试场景、如何约束输出格式。
• 了解测试数据管理的基本方法，包括数据脱敏、数据隔离和数据构造。

接下来我们从环境准备开始，逐步搭建一套可落地的 AI 自动测试体系。

2. 环境准备与版本说明

2.1 运行环境与版本选择

由于 AI 测试涉及的内容较多，下面以本文示例的通用环境为例。实际版本请根据项目情况调整，重点是理解配置思路。

2.2 安装 Playwright

Playwright 是目前比较适合与 AI 结合的自动化框架，原因是它内置了page.screenshot()、page.locator()、page.expect()等能力，而且可以通过page.locator配合 AI 修复定位器。

# 创建虚拟环境（推荐） python -m venv ai-test-env source ai-test-env/bin/activate # Windows 下使用 ai-test-env\Scripts\activate # 安装 Playwright pip install playwright pytest pytest-playwright allure-pytest # 安装浏览器内核 playwright install chromium

2.3 配置大模型 API

AI 自动测试的核心能力来自于大模型的文本理解和代码生成。本文以 OpenAI 格式兼容的接口作为示例，你也可以使用国内大模型或本地部署模型，只需要调整base_url和api_key即可。

# config.py import os LLM_API_KEY = os.getenv("LLM_API_KEY", "sk-xxxxx") LLM_BASE_URL = os.getenv("LLM_BASE_URL", "https://api.openai.com/v1") LLM_MODEL = os.getenv("LLM_MODEL", "gpt-4o-mini")

这里需要注意：不要把 API Key 硬编码到代码仓库中。正式项目中建议使用环境变量或密钥管理服务。如果你使用的是本地部署模型，比如基于 Ollama 部署的模型，base_url通常指向本地服务端口，本文的示例代码仍然适用，因为你使用的是兼容接口。

2.4 示例项目结构

为了便于后续实战，我们创建一个可扩展的项目结构：

ai-auto-test/ ├── config.py # 全局配置 ├── requirements.txt # 依赖列表 ├── ai_utils/ │ ├── __init__.py │ ├── llm_client.py # LLM 调用封装 │ ├── testcase_agent.py # 测试用例生成 Agent │ ├── testdata_agent.py # 测试数据生成 Agent │ └── repair_agent.py # 定位器修复 Agent ├── pages/ │ ├── __init__.py │ └── login_page.py # 登录页面对象 ├── tests/ │ ├── conftest.py # Pytest 夹具 │ ├── test_login.py # 登录测试 │ └── test_order.py # 下单流程测试 ├── data/ │ └── test_cases.json # 生成的测试用例 └── reports/ # 测试报告

这个结构把 AI 能力封装成独立的模块，方便后续复用和扩展。接下来我们逐层拆解。

3. 核心原理拆解：怎么让 AI 正确生成测试内容

3.1 Prompt 的本质是约束

在 AI 自动测试中，Prompt 决定了输出质量。很多人让 AI 写测试脚本，结果生成的代码要么不能直接运行，要么测试覆盖不到重点，根本原因就是 Prompt 不够具体。

一个合格的测试生成 Prompt 至少需要包含以下元素：

1. 角色设定：你是资深测试开发工程师。
2. 被测对象描述：被测系统的类型、技术栈、核心业务流程。
3. 输入信息：需求文本、接口文档、页面结构、测试数据约束。
4. 输出格式：测试用例表格、代码文件、JSON 结构、Markdown 报告。
5. 约束条件：边界值、异常场景、安全约束、数据隔离要求。

下面是一个简单的测试用例生成示例：

# ai_utils/testcase_agent.py from ai_utils.llm_client import chat_completion SYSTEM_PROMPT = """ 你是一名资深的测试开发工程师，擅长编写高质量的测试用例。 你需要严格遵循以下规则： 1. 测试用例必须覆盖功能测试、边界测试、异常测试。 2. 每条测试用例必须包含：用例编号、用例名称、前置条件、测试步骤、预期结果、优先级。 3. 输出格式为 JSON 数组，不要输出其他多余信息。 4. 考虑测试数据的唯一性和隔离性。 """ def generate_test_cases(requirement_text: str) -> list: user_prompt = f""" 请根据以下需求描述生成测试用例： {requirement_text} """ response = chat_completion( system_prompt=SYSTEM_PROMPT, user_prompt=user_prompt, response_format="json" ) return response

3.2 LLM 调用的工程化封装

在实际项目中，我们不会直接在主测试代码里调用 OpenAI SDK，因为这样会让代码耦合度高、难以维护。推荐做一个轻量的llm_client.py，统一处理超时、重试、token 限制和错误日志。

# ai_utils/llm_client.py import json import time from typing import Optional import requests from config import LLM_API_KEY, LLM_BASE_URL, LLM_MODEL class LLMClient: def __init__(self, api_key: str = LLM_API_KEY, base_url: str = LLM_BASE_URL, model: str = LLM_MODEL): self.api_key = api_key self.base_url = base_url.rstrip("/") + "/chat/completions" self.model = model self.max_retries = 3 self.timeout = 60 def chat(self, system_prompt: str, user_prompt: str, response_format: Optional[str] = None) -> str: headers = { "Authorization": f"Bearer {self.api_key}", "Content-Type": "application/json" } payload = { "model": self.model, "messages": [ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_prompt} ], "temperature": 0.2 } if response_format == "json": payload["response_format"] = {"type": "json_object"} for attempt in range(self.max_retries): try: response = requests.post(self.base_url, headers=headers, json=payload, timeout=self.timeout) response.raise_for_status() data = response.json() return data["choices"][0]["message"]["content"] except Exception as e: print(f"[LLM] 第 {attempt + 1} 次请求失败: {e}") if attempt < self.max_retries - 1: time.sleep(2 ** attempt) raise RuntimeError("LLM 调用失败，请检查网络或 API 配置") def chat_json(self, system_prompt: str, user_prompt: str) -> dict: content = self.chat(system_prompt, user_prompt, response_format="json") # 兼容部分模型未严格返回 JSON 时的情况 content = content.strip() if content.startswith("```json"): content = content[7:] if content.endswith("```"): content = content[:-3] return json.loads(content) llm_client = LLMClient() def chat_completion(system_prompt: str, user_prompt: str, response_format: Optional[str] = None): return llm_client.chat(system_prompt, user_prompt, response_format)

3.3 如何让 AI 生成可运行的自动化测试脚本

让 AI 生成可运行的自动化脚本，比生成测试用例难度更高。原因很直接：自动化脚本依赖被测系统的 DOM 结构、接口协议、测试环境地址等具体信息，这些信息在 Prompt 中缺失时，AI 只能生成泛化代码。

一个更稳妥的做法是：先根据页面对象模型（Page Object Model）提供页面结构摘要，再让 AI 生成符合框架要求的脚本片段。

下面是一个获取页面结构摘要的例子：

# ai_utils/page_pilot.py import json from playwright.sync_api import Page def extract_page_structure(page: Page, selectors: list) -> dict: """ 从页面中提取关键元素的信息，供 AI 生成脚本时参考。 selectors: 需要提取的元素定位器列表，例如 ['#username', '#password', '.login-btn'] """ structure = {} for selector in selectors: try: locator = page.locator(selector).first structure[selector] = { "tag": locator.evaluate("el => el.tagName"), "visible": locator.is_visible(), "text": locator.inner_text(timeout=2000) if locator.count() > 0 else "", } except Exception: structure[selector] = {"tag": "unknown", "visible": False} return structure

把这个结构作为上下文传给 AI，AI 生成的脚本通常会更准确。接下来我们看一个完整的实战案例。

4. 完整实战案例：从用例生成到自动化执行的闭环

4.1 需求描述

假设我们要测试一个电商系统的登录功能，需求如下：

• 用户使用手机号和密码登录。
• 登录成功后跳转到首页，右上角显示用户名。
• 密码错误时提示“用户名或密码错误”。
• 手机号格式非法时提示“请输入正确的手机号”。
• 登录失败 5 次后，账号被锁定 30 分钟。

我们将从 AI 生成测试用例开始，到生成 Playwright 脚本，最后执行并输出报告。

4.2 生成测试用例

# scripts/generate_testcases.py from ai_utils.testcase_agent import generate_test_cases requirement = """ 用户登录功能： 1. 用户输入手机号和密码登录。 2. 登录成功后跳转首页，显示用户名。 3. 密码错误提示“用户名或密码错误”。 4. 手机号格式非法提示“请输入正确的手机号”。 5. 连续失败 5 次后锁定账号 30 分钟。 """ cases = generate_test_cases(requirement) print(json.dumps(cases, ensure_ascii=False, indent=2)) # 保存到 data/test_cases.json with open("data/test_cases.json", "w", encoding="utf-8") as f: json.dump(cases, f, ensure_ascii=False, indent=2)

生成结果示例（格式可能因模型输出略有差异）：

[ { "case_id": "TC001", "case_name": "正常登录成功", "precondition": "已注册用户：13800138000 / Test@123", "steps": [ "打开登录页", "输入手机号 13800138000", "输入密码 Test@123", "点击登录按钮" ], "expected": "跳转首页，右上角显示用户名 testuser", "priority": "P0" }, { "case_id": "TC002", "case_name": "密码错误提示", "precondition": "已注册用户：13800138000", "steps": [ "打开登录页", "输入手机号 13800138000", "输入密码 Wrong@123", "点击登录按钮" ], "expected": "页面提示“用户名或密码错误”", "priority": "P1" } ]

这里需要提醒的是，AI 生成的用例只能作为初稿，正式使用前必须评审。你可以让 AI 输出优先级、依赖关系、数据准备方式，也可以让 AI 反过来检查遗漏场景。

4.3 编写测试代码

我们利用 Playwright 和 Pytest 来实现自动化脚本。先创建conftest.py：

# tests/conftest.py import pytest from playwright.sync_api import sync_playwright @pytest.fixture(scope="function") def page(): with sync_playwright() as p: browser = p.chromium.launch(headless=False) context = browser.new_context() page = context.new_page() yield page context.close() browser.close() @pytest.fixture(scope="function") def login_page(page): from pages.login_page import LoginPage return LoginPage(page)

页面对象：

# pages/login_page.py class LoginPage: def __init__(self, page): self.page = page self.username_input = page.locator("#username") self.password_input = page.locator("#password") self.login_button = page.locator("#login-btn") self.error_msg = page.locator(".error-message") self.user_info = page.locator(".user-name") def goto(self): self.page.goto("https://your-test-env.example.com/login") self.page.wait_for_load_state("networkidle") def login(self, username: str, password: str): self.username_input.fill(username) self.password_input.fill(password) self.login_button.click()

测试用例：

# tests/test_login.py import pytest def test_login_success(login_page): login_page.goto() login_page.login("13800138000", "Test@123") login_page.page.wait_for_url("**/home") assert login_page.user_info.inner_text() == "testuser" def test_login_wrong_password(login_page): login_page.goto() login_page.login("13800138000", "Wrong@123") assert login_page.error_msg.inner_text() == "用户名或密码错误" def test_login_invalid_phone(login_page): login_page.goto() login_page.login("12345", "Test@123") assert login_page.error_msg.inner_text() == "请输入正确的手机号"

4.4 用 AI 生成数据驱动用例

在实际业务中，测试数据往往不是写死的。我们可以让 AI 生成一批符合格式规则的测试数据，并用 Pytest 参数化来执行。

# tests/test_login_data_driven.py import pytest import json from ai_utils.testdata_agent import generate_login_test_data # 这里可以根据 test_cases.json 的结构生成数据组合 test_data = [ ("13800138000", "Test@123", "success"), ("13800138000", "Wrong@123", "wrong_password"), ("12345", "Test@123", "invalid_phone"), ("", "Test@123", "invalid_phone"), ] @pytest.mark.parametrize("username,password,expected_type", test_data) def test_login_data_driven(login_page, username, password, expected_type): login_page.goto() login_page.login(username, password) if expected_type == "success": assert login_page.user_info.inner_text() == "testuser" elif expected_type == "wrong_password": assert login_page.error_msg.inner_text() == "用户名或密码错误" else: assert login_page.error_msg.inner_text() == "请输入正确的手机号"

4.5 运行与报告

# 运行所有测试 pytest -v --alluredir=reports/allure-results # 打开报告（如果是本地展示） allure serve reports/allure-results

预期结果：所有测试用例执行完毕，报告中可以查看每个用例的关键步骤和截图。如果出现失败，可以配合后续的 AI 失败分析模块快速定位。

5. 常见问题与排查思路

5.1 AI 生成的脚本经常报错，如何减少？

5.2 LLM 调用超时或返回格式错误

# 针对返回格式不稳定，可以加上格式修正和重试 def safe_json_parse(content: str): content = content.strip() start = content.find("[") end = content.rfind("]") if start != -1 and end != -1: content = content[start:end + 1] try: return json.loads(content) except json.JSONDecodeError as e: print(f"[WARN] JSON 解析失败: {e}") return []

这样可以避免因为模型输出少量描述性文字导致整个流程中断。

5.3 定位器自愈的思路

对于 UI 自动化回归测试，页面结构变化是最大的维护成本。一个轻量级的自愈方案是：

1. 运行前收集所有定位器的历史匹配率。
2. 如果某个定位器失败，将页面截图和 DOM 摘要发送给 AI。
3. AI 返回新的候选定位置。
4. 在测试环境中验证新定位器，并更新页面对象。

这部分的代码实现可以参考下面的思路：

def repair_locator(page, old_selector, description): dom_dump = page.locator("body").inner_text(timeout=5000) prompt = f""" 页面变更导致定位器失效，请根据页面内容提供新的定位器建议。 原定位器: {old_selector} 页面描述: {description} 页面文本: {dom_dump[:3000]} 请只返回CSS选择器。 """ new_selector = llm_client.chat("", prompt).strip() return new_selector

5.4 数据隔离与安全问题

AI 自动测试会读取页面内容发给大模型，所以要特别小心数据安全。在生产环境或包含敏感数据的测试环境，不要直接发送完整页面 DOM。建议：

• 对页面文本进行脱敏。
• 只发送标签名、id、class 等结构信息。
• 使用本地部署模型处理敏感环境数据。
• 不要将真实用户手机号、身份证号发送给外部 API。

6. 最佳实践与工程建议

6.1 Prompt 与用例资产管理

AI 自动测试并不代表“无脑生成”。使用一段时间后，你应该把高质量 Prompt、评审过的测试用例、人工修正过的脚本沉淀下来，形成团队资产。具体做法：

• 将确认可复用的 Prompt 保存成模板文件。
• 将 AI 生成的测试用例与人工用例分开管理。
• 每轮测试结束后记录 AI 命中率和误报率，持续优化 Prompt。
• 对 AI 生成的代码做 Code Review 后再进入测试库。

6.2 必须保留人工审核环节

AI 生成测试用例和测试脚本的安全边界是：AI 负责“从 0 到 80 分”的工作，人负责“从 80 到 100 分”的校验。

即使是大模型，也会出现以下问题：

• 遗漏关键业务校验场景。
• 对业务规则理解偏差。
• 对历史缺陷场景不了解。
• 难以理解复杂状态机的流转。

所以，正式项目的流程建议是：

1. AI 生成初稿。
2. 测试负责人评审。
3. 自动化工程师补充边界场景。
4. 上线前执行回归并记录覆盖情况。
5. 持续将项目特殊规则反馈到 Prompt 上下文。

6.3 将 AI 嵌入 CI/CD 流水线

在实际项目中，AI 自动测试最有价值的场景之一是持续集成。下面是一个 GitHub Actions 的简化示例：

name: AI Test Pipeline on: push: branches: [ main ] pull_request: branches: [ main ] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Set up Python uses: actions/setup-python@v5 with: python-version: '3.11' - name: Install dependencies run: | pip install -r requirements.txt playwright install chromium - name: Run tests env: LLM_API_KEY: ${{ secrets.LLM_API_KEY }} LLM_BASE_URL: ${{ secrets.LLM_BASE_URL }} run: | pytest -v --maxfail=5 --alluredir=reports/allure-results - name: Upload report uses: actions/upload-artifact@v4 with: name: allure-report path: reports/

在流水线中，如果 AI 调用失败，可以使用--maxfail控制整体测试时长，避免因 LLM 服务抖动导致测试全部搁浅。同时，建议对 AI 接口调用增加熔断机制：当连续失败超过阈值时，跳过 AI 相关步骤并保留已有历史测试数据，保证 CI 整体稳定性。

6.4 日志与可观测性

AI 自动测试项目对日志的要求比普通自动化更高，因为你需要知道：

• 哪个 Prompt 产生了什么输出。
• 模型返回结果是否被人工修正。
• 定位器修复时使用了哪些上下文。
• 测试数据生成时消耗了多少 token。
• 每个 AI 步骤的耗时和成功率。

建议在llm_client中加入结构化日志，输出到独立文件：

import logging ai_logger = logging.getLogger("ai_test") ai_logger.setLevel(logging.INFO) file_handler = logging.FileHandler("logs/ai_test.log", encoding="utf-8") file_handler.setFormatter(logging.Formatter("%(asctime)s %(levelname)s %(message)s")) ai_logger.addHandler(file_handler) def log_ai_call(system_prompt, user_prompt, response, duration_ms): ai_logger.info( "LLM_CALL system_len=%d user_len=%d resp_len=%d duration_ms=%d", len(system_prompt), len(user_prompt), len(response), duration_ms )

日志中的数据脱敏同样重要。如果 Prompt 中包含测试账号、用户手机号等敏感信息，建议在落盘前替换为占位符。

6.5 性能与成本控制

大模型 API 调用不是免费的，所以在 AI 自动测试设计中，必须考虑成本和性能：

• 同一份页面结构摘要可以缓存，不要每个用例重复发送。
• 测试数据生成可以批量执行，减少调用次数。
• 失败的失败分析可以只对失败用例调用 AI，不需要全量调用。
• 优先使用更小的模型处理简单任务（比如定位器修复），复杂任务才使用大模型。

下面是一个简单的缓存示例：

import hashlib import json _cache = {} def get_cache_key(messages: list) -> str: raw = json.dumps(messages, ensure_ascii=False) return hashlib.md5(raw.encode("utf-8")).hexdigest() def chat_with_cache(system_prompt, user_prompt, cache: dict): key = get_cache_key([system_prompt, user_prompt]) if key in cache: return cache[key] response = llm_client.chat(system_prompt, user_prompt) cache[key] = response return response

6.6 选择适合的模型部署方式

根据团队资源，模型部署可以分为三种模式：

在工程落地中，可以同时配置多个模型，按任务难度路由。比如“测试数据生成”使用本地小模型就可以，而“复杂业务场景用例生成”使用云端大模型。

7. 拓展：AI 自动化测试的进阶方向

7.1 AI 辅助接口测试

除了 UI 测试，接口测试同样可以从 AI 中受益。将接口文档（OpenAPI/Swagger）直接喂给 AI，可以快速生成接口用例覆盖矩阵、参数组合、异常参数用例。

示例思路：

def generate_api_testcases(openapi_spec: dict): prompt = f""" 请分析以下 OpenAPI 文档，生成接口测试用例。 注意覆盖： - 必填参数缺失 - 参数类型错误 - 枚举值越界 - 认证失败 输出 JSON 格式。 接口文档： {json.dumps(openapi_spec, ensure_ascii=False)[:8000]} """ return llm_client.chat_json("", prompt)

7.2 AI 辅助移动端测试

移动端测试中，AI 可以用于：

• 根据需求描述生成 Appium 脚本。
• 通过截图识别控件位置。
• 自动生成手势轨迹。
• 分析崩溃日志和页面跳转异常。

工具选择上，可以关注 Appium、Maestro、ai2test 等。与 Web 端一致，核心思路仍是“尽可能为模型提供结构化的上下文，而不是丢一段需求文字让它自由发挥”。

7.3 AI 辅助测试报告解读

测试执行完成后，AI 还可以根据失败用例的日志、截图、网络报文生成一份“失败原因分析报告”。下面是一个简化实现：

def analyze_failure(case_name: str, log_text: str, screenshot_base64: str = None): prompt = f""" 你是一名资深测试开发工程师，请分析以下自动化测试失败原因。 测试用例：{case_name} 日志： {log_text[:3000]} 请从以下方面分析： 1. 可能的原因 2. 定位问题的下一步排查步骤 3. 修复建议 """ return llm_client.chat(SYSTEM_PROMPT, prompt)

8. 学习路线与资源推荐

8.1 第一阶段：打牢测试自动化和 AI 基础

• 学习 Python 基础，重点掌握数据结构、类的使用、异常处理和文件读写。
• 熟悉 Pytest 的 fixture、参数化、断言和报告生成。
• 学习 Playwright 的 locator、auto-waiting 和截图能力。
• 了解大模型的 API 调用方式和 JSON 输出解析。

8.2 第二阶段：掌握 Prompt 工程与测试结合

• 练习写测试用例生成 Prompt，从简单登录模块开始。
• 练习让 AI 生成 Pytest 测试脚本，并手动修复语法问题。
• 学习如何把页面结构、接口文档、测试数据约束写入 Prompt。
• 搭建一个小型项目，完整跑通“需求→AI 生成用例→脚本→执行→报告”。

8.3 第三阶段：项目落地与工程化

• 研究定位器自愈机制、失败分析和报告解读。
• 将 AI 测试接入 CI/CD，结合 GitLab CI 或 GitHub Actions。
• 关注 token 成本，建立缓存、失败重试和模型路由。
• 探索私有化模型部署，积累本地部署经验。

8.4 第四阶段：持续关注领域进展

AI 自动测试工具更新很快，建议关注：

• 大模型测试生成论文和开源框架。
• Playwright、Selenium 等框架对 AI 能力的整合。
• 团队内的 AI 测试实践复盘。
• 多模态模型在 UI 测试中的应用。

9. 结语与动手建议

AI 自动测试不是一条捷径，它更像是把测试工程师从繁琐重复劳动中解放出来的杠杆。真正的核心竞争力，仍然是你对业务的理解、对测试理论的理解，以及把 AI 输出转化为高质量测试资产的能力。

如果你现在还没有系统接触过 AI 自动测试，可以从今天开始做一个小实验：

1. 把一个页面的登录流程写成需求描述。
2. 用文中的testcase_agent.py生成测试用例。
3. 用 Playwright 手动跑通一条用例。
4. 再把整个流程嵌入到 CI 里跑一遍。

这个实验做完，你对 AI 自动测试的认知会远超只看视频教程的效果。后续遇到问题时，优先回到“数据、提示词、验证、反馈”这四件事上，大部分问题都能找到方向。