企业官网建设流程全解析

1. 项目概述：当AI撞上Web自动化测试

最近在团队里搞技术分享，聊到测试效率的瓶颈，大家不约而同地提到了Web自动化测试的“老毛病”：脚本维护成本高、元素定位一有风吹草动就失效、测试数据准备繁琐。正好，这两年AI工具遍地开花，从写代码的Cursor到能理解需求的Claude，再到各种大模型API，我就琢磨着，能不能让AI来当我们的“测试开发实习生”，把我们从重复的脚本编写和维护中解放出来？

这个想法催生了这次实践。所谓“AI测试”，并不是指用AI去直接“思考”和“执行”测试用例，那离我们还比较远。我理解的“AI辅助Web自动化测试”，核心是利用大语言模型的代码生成、自然语言理解和逻辑推理能力，来辅助我们完成自动化测试脚本的编写、维护、数据生成乃至部分异常场景的推断。简单说，就是让AI帮我们写Selenium、Playwright或者Cypress的代码，我们负责提供清晰的指令和做最后的把关。

这适合谁呢？如果你是刚接触自动化测试，觉得写代码门槛高；或者你是业务测试人员，想提升效率但苦于编码能力；又或者你已经是资深自动化测试工程师，但厌倦了日复一日的脚本调试和维护——那么，这套“AI喂饭”流程很可能让你眼前一亮。它不要求你成为编程专家，但需要你具备清晰的测试思维和对被测系统的理解。接下来，我就把手头这个用AI辅助搭建Web自动化测试框架的完整过程，包括思路、工具、实操和踩过的坑，毫无保留地分享出来。

2. 核心思路与工具选型：为什么是它们？

在决定让AI介入之前，得先想清楚让它干什么，以及用什么工具指挥它。Web自动化测试的流程大致可以拆解为：需求分析 -> 用例设计 -> 脚本生成 -> 脚本执行与维护 -> 结果分析。AI目前最能发挥作用的环节，集中在脚本生成和部分维护上。

2.1 核心思路：AI作为“高级代码生成器”

我的核心思路是：将测试用例的自然语言描述，通过AI转化为可执行的、健壮的自动化测试代码。这里的关键在于“可执行”和“健壮”。AI生成的代码不能是玩具，必须能直接融入现有的测试框架，处理登录态、等待、断言等实际问题。因此，我们需要给AI提供足够的“上下文”，包括：

1. 技术栈上下文：告诉AI我们使用什么测试框架（如Pytest）、什么浏览器驱动工具（如Playwright）、什么断言库。
2. 项目结构上下文：让AI了解我们的Page Object设计模式、配置文件位置、基础测试类等。
3. 具体操作上下文：清晰描述操作步骤、预期结果，最好能提供目标网页的HTML片段或元素选择器。

基于这个思路，工具选型就围绕“谁能更好地理解并生成代码”以及“如何便捷地提供上下文”来展开。

2.2 工具选型解析：Cursor + 大模型API的组合拳

市面上AI工具很多，我最终选择了Cursor + 大模型API（如DeepSeek、GPT-4）的组合。为什么是它们？

1. Cursor：面向代码的“瑞士军刀”Cursor不是一个聊天机器人，它是一个深度集成AI的代码编辑器。它的杀手级功能是“Chat”和“Composer”。

• Chat模式：你可以像和同事讨论一样，选中一段代码或一个错误信息，直接问Cursor“怎么修复这个定位不到元素的问题？”它会结合当前文件甚至整个项目的代码上下文给出建议，比在网页聊天框里粘贴代码片段要高效得多。
• Composer模式（指令式生成）：这是我用来生成测试脚本的主力。你可以用自然语言描述一个完整的操作流程，比如“用Playwright给电商网站写一个测试：用户登录，搜索‘手机’，将第一个商品加入购物车，然后去购物车页面验证商品存在且价格正确”。Cursor能生成结构相当完整的代码块，包括必要的导入、异步处理、断言等。
• 项目级感知：Cursor能索引你的整个项目，这意味着它生成的代码会考虑你已有的conftest.py、page_objects目录结构，生成的代码风格也更统一。

2. 大模型API（如DeepSeek）虽然Cursor内置了模型，但有时我们需要更强大的逻辑推理能力，或者处理非常复杂的场景描述。这时，我会调用如DeepSeek-V3这类高性能API。

• 优势：对于需要多步推理、条件判断的复杂测试场景（例如：“如果商品库存为0，则检查‘缺货’标签是否显示，并且加入购物车按钮应为禁用状态”），大模型能更好地理解意图并生成准确的逻辑代码。
• 用法：我会在API调用中构造一个包含系统指令（“你是一个专业的测试开发工程师”）、技术栈（“使用Python+Pytest+Playwright，采用Page Object模式”）、以及具体需求的Prompt。这样生成的代码针对性强，可以直接复制到Cursor中使用。

为什么不选其他？

• 纯网页聊天工具（如ChatGPT网页版）：需要频繁复制粘贴代码和上下文，效率低，且容易丢失项目结构信息。
• 低代码/无代码测试平台：虽然上手快，但灵活性和可编程性差，难以处理复杂业务逻辑和定制化需求，生成的脚本也往往难以集成到CI/CD。
• 单一的AI测试工具：很多宣称AI测试的工具，其模型能力封闭，且往往绑定自己的生态，不如Cursor+API组合自由、强大。

这个组合的核心思想是：用Cursor处理日常、高频、基于项目上下文的代码生成与问答；用大模型API攻坚复杂、需要深度推理的脚本逻辑。两者互补，覆盖了自动化测试脚本开发的大部分需求。

3. 环境搭建与基础框架配置

工欲善其事，必先利其器。在让AI开始干活之前，我们需要先搭建一个标准、清晰的测试项目骨架。这不仅是好习惯，更是为了给AI提供一个高质量的“上下文环境”，让它生成的代码能无缝嵌入。

3.1 初始化项目与依赖安装

我习惯用Poetry管理Python项目的依赖，它比pip更清晰。当然，用venv加requirements.txt也一样。

# 1. 创建项目目录 mkdir ai-web-autotest-demo && cd ai-web-autotest-demo # 2. 使用Poetry初始化项目（如果没有，用 pip install poetry 安装） poetry init -n # 交互式创建pyproject.toml，这里用-n跳过交互 # 3. 添加核心依赖 poetry add pytest playwright pytest-playwright poetry add python-dotenv # 用于管理环境变量，如账号密码 poetry add allure-pytest # 可选，用于生成漂亮报告 # 4. 安装Playwright浏览器 poetry run playwright install chromium

关键点说明：

• Pytest：是测试框架的事实标准，结构清晰，插件生态丰富。
• Playwright：我选择它而非Selenium，是因为Playwright的API更现代，自动等待机制更智能，对现代Web应用（单页应用）支持更好，能大大减少“元素未加载”导致的失败。AI为Playwright生成的代码也通常更简洁。
• pytest-playwright：提供了Pytest和Playwright的无缝集成，比如方便的Fixture（如page）来管理浏览器页面。

3.2 构建清晰的项目结构

一个清晰的结构能让AI和你自己都更容易理解代码。我的目录结构如下：

ai-web-autotest-demo/ ├── pyproject.toml ├── .env # 存储敏感信息，如BASE_URL, USERNAME, PASSWORD ├── conftest.py # Pytest全局配置，定义Fixture ├── pytest.ini # Pytest配置文件 ├── pages/ # Page Object 目录 │ ├── __init__.py │ ├── base_page.py # 基础页面类，封装公共方法 │ ├── login_page.py # 登录页面 │ └── cart_page.py # 购物车页面 ├── tests/ # 测试用例目录 │ ├── __init__.py │ ├── test_login.py # 登录测试 │ └── test_cart.py # 购物车测试 ├── utils/ # 工具函数目录 │ ├── __init__.py │ └── data_helper.py # 测试数据生成/读取 └── reports/ # 测试报告输出目录（自动生成）

为什么这么设计？

1. Page Object模式 (pages/)：这是Web自动化的最佳实践。将每个页面的元素定位和操作封装成类。AI在生成针对某个页面的操作代码时，可以精准地引用对应Page类的方法，避免生成一堆散落的page.locator(“selector”)。
2. conftest.py：这里定义全局的Pytest Fixture。例如，一个初始化Playwright浏览器并登录的Fixture，可以被所有测试用例复用。AI在生成新测试时，会识别到这些Fixture并尝试使用它们。
3. .env文件：将URL、账号密码等配置外置。AI生成的代码中不应出现硬编码的敏感信息，而是读取环境变量。我们在给AI的指令中也要强调这一点。

3.3 编写核心基础类与配置

这是给AI的“教科书”，让它知道我们的代码规范。

1.pages/base_page.py- 基础页面类

from playwright.sync_api import Page class BasePage: """所有Page类的基类，封装公共操作""" def __init__(self, page: Page): self.page = page self.timeout = 10000 # 默认超时时间 def navigate(self, url): """导航到指定URL""" self.page.goto(url) self.page.wait_for_load_state("networkidle") # 等待网络空闲 def get_element(self, selector): """获取元素，加入显式等待""" return self.page.locator(selector).first def click_element(self, selector): """点击元素""" self.get_element(selector).click() def fill_text(self, selector, text): """输入文本""" self.get_element(selector).fill(text) def get_text(self, selector): """获取元素文本""" return self.get_element(selector).text_content() def wait_for_element_visible(self, selector): """等待元素可见""" self.page.wait_for_selector(selector, state="visible", timeout=self.timeout)

2.conftest.py- 全局Fixture

import pytest from playwright.sync_api import Browser, Page from dotenv import load_dotenv import os load_dotenv() # 加载.env文件中的环境变量 BASE_URL = os.getenv("BASE_URL", "https://demo.testfire.net") # 示例测试网站 @pytest.fixture(scope="session") def browser(): """启动浏览器实例（会话级，所有测试共用）""" from playwright.sync_api import sync_playwright with sync_playwright() as p: browser = p.chromium.launch(headless=False) # 调试时可设为False看浏览器 yield browser browser.close() @pytest.fixture def page(browser: Browser): """为每个测试用例创建一个新页面""" context = browser.new_context(viewport={'width': 1920, 'height': 1080}) page = context.new_page() yield page context.close() @pytest.fixture def login_page(page: Page): """提供一个已导航到登录页面的Page对象""" from pages.login_page import LoginPage login_page = LoginPage(page) login_page.navigate(f"{BASE_URL}/login.jsp") return login_page

3..env文件

BASE_URL=https://demo.testfire.net TEST_USERNAME=admin TEST_PASSWORD=admin

注意：在真实的项目中，.env文件应该被加入.gitignore，并且使用git update-index --assume-unchanged .env命令让其不被追踪。在CI/CD环境中，这些变量通过流水线平台（如Jenkins, GitLab CI）注入。

做好这些准备工作，我们就拥有了一个专业、标准的自动化测试项目骨架。接下来，AI将在这个骨架上“生长”出血肉——具体的测试用例。

4. 实操：手把手用AI生成第一个测试用例

现在，让我们进入最核心的环节：如何与AI协作，生成可用的测试代码。我将以“用户登录”这个最经典的场景为例，演示完整流程。

4.1 第一步：用自然语言描述测试用例

首先，你需要像一个测试分析师一样，清晰地在脑中或纸上描述测试场景。不要一上来就想着代码。例如，对于登录测试，我们可以拆解出几个关键用例：

1. 正向用例：使用正确的用户名和密码，登录成功，页面跳转到首页。
2. 反向用例-密码错误：使用正确的用户名和错误的密码，登录失败，页面提示“无效的登录信息”。
3. 反向用例-用户名为空：不输入用户名，点击登录，页面提示“请输入用户名”。

我们选择正向用例作为第一个例子。给AI的指令需要包含：

• 角色设定：你是什么角色？
• 技术栈：使用什么工具和模式？
• 具体操作：步骤是什么？
• 预期结果：验证什么？
• 上下文：参考哪些现有代码？

4.2 第二步：在Cursor中生成Page Object代码

打开Cursor，进入你的项目。首先，我们需要创建登录页面的Page Object。在pages/目录下新建login_page.py，然后打开它。

在Cursor的Chat面板或直接使用Cmd+K打开Composer，输入以下指令：

作为测试开发专家，请基于现有的BasePage类，为登录页面创建一个Page Object类。 页面URL路径是 /login.jsp。 页面包含以下关键元素： - 用户名输入框: id为 ‘uid’ - 密码输入框: id为 ‘passw’ - 登录按钮: 一个type为submit的input元素，name为 ‘btnSubmit’ 请创建LoginPage类，包含以下方法： 1. `login(username, password)`: 执行登录操作。 2. `get_error_message()`: 获取登录失败后的错误提示文本，错误信息的CSS选择器是 ‘span#_ctl0__ctl0_Content_Main_message’。 请使用Playwright的同步API，并遵循项目已有的代码风格。

Cursor分析项目后，生成了如下代码：

from .base_page import BasePage class LoginPage(BasePage): """登录页面Page Object""" # 元素定位器 USERNAME_INPUT = "#uid" PASSWORD_INPUT = "#passw" LOGIN_BUTTON = "input[name='btnSubmit']" ERROR_MESSAGE = "span#_ctl0__ctl0_Content_Main_message" def login(self, username: str, password: str): """执行登录操作""" self.fill_text(self.USERNAME_INPUT, username) self.fill_text(self.PASSWORD_INPUT, password) self.click_element(self.LOGIN_BUTTON) # 登录后等待页面跳转或加载完成 self.page.wait_for_load_state("networkidle") def get_error_message(self) -> str: """获取登录错误信息，如果不存在则返回空字符串""" if self.page.locator(self.ERROR_MESSAGE).count() > 0: return self.page.locator(self.ERROR_MESSAGE).text_content() return ""

生成代码分析：

• AI正确地继承了BasePage。
• 将元素选择器定义为类变量，这是好习惯，便于维护。
• login方法调用了基类的fill_text和click_element，代码简洁。
• 加入了wait_for_load_state，这是一个很好的实践，确保了登录操作后的页面稳定性。
• get_error_message方法考虑了元素可能不存在的情况（登录成功时），返回空字符串，避免了测试因找不到元素而意外失败。

如果生成的不完美怎么办？比如，你可能希望login方法返回下一个页面的对象（如首页）。你可以直接选中相关代码，在Chat里问：“如何修改login方法，使其在登录成功后返回HomePage的实例？” Cursor会根据你的项目结构给出修改建议。

4.3 第三步：用AI编写Pytest测试用例

有了LoginPage，现在来生成测试用例。在tests/目录下创建test_login.py。

打开这个新文件，使用Cursor Composer输入更复杂的指令：

请编写一个Pytest测试类 `TestLogin`，测试登录功能。 使用项目已有的 `login_page` fixture。 包含以下测试用例： 1. `test_login_success`: 使用环境变量中的TEST_USERNAME和TEST_PASSWORD登录，验证登录成功后页面标题包含“Altoro Mutual”字样，并且当前URL包含“main.jsp”。 2. `test_login_failure_wrong_password`: 使用正确的用户名和错误的密码“wrong”登录，验证错误信息包含“Invalid Login”文本。 3. `test_login_failure_empty_username`: 用户名为空，密码随意，点击登录，验证错误信息包含“Please enter a username”。 请从 .env 文件或os.environ中读取用户名和密码。使用清晰的断言语句。

Cursor生成的代码如下：

import os import pytest from dotenv import load_dotenv load_dotenv() class TestLogin: """登录功能测试集""" def test_login_success(self, login_page): """测试使用正确凭据登录成功""" username = os.getenv("TEST_USERNAME") password = os.getenv("TEST_PASSWORD") login_page.login(username, password) # 断言1：页面标题包含特定文本 assert "Altoro Mutual" in login_page.page.title() # 断言2：URL跳转到了主页面 assert "main.jsp" in login_page.page.url # 可以添加更多断言，如检查登录后用户菜单是否出现 def test_login_failure_wrong_password(self, login_page): """测试密码错误登录失败""" username = os.getenv("TEST_USERNAME") wrong_password = "wrong" login_page.login(username, wrong_password) error_msg = login_page.get_error_message() # 断言错误信息符合预期 assert "Invalid Login" in error_msg # 额外断言：登录后URL没有跳转（可选） assert "login.jsp" in login_page.page.url def test_login_failure_empty_username(self, login_page): """测试用户名为空登录失败""" empty_username = "" any_password = "123" # 对于空用户名，我们直接操作元素，因为login方法会填充空字符串 login_page.fill_text(login_page.USERNAME_INPUT, empty_username) login_page.fill_text(login_page.PASSWORD_INPUT, any_password) login_page.click_element(login_page.LOGIN_BUTTON) error_msg = login_page.get_error_message() assert "Please enter a username" in error_msg

代码审查与优化： AI生成的代码已经非常可用，但仍有优化空间。我们作为把关人，需要审查：

1. 断言粒度：test_login_success中的两个断言是基本的。在实际项目中，我们可能还需要验证登录后用户的登录状态（如检查“欢迎，[用户名]”的文本是否出现）。我们可以让AI补充：“如何在登录成功后，验证页面顶部出现了欢迎用户的文本？该文本的选择器是#welcome_user”。
2. 测试数据：密码“wrong”是硬编码的。更好的做法是从一个测试数据文件中读取，或者使用@pytest.mark.parametrize进行参数化。我们可以指示AI：“请使用pytest.mark.parametrize重构test_login_failure_wrong_password，使其能测试多组错误的密码数据。”
3. 等待与稳定性：在test_login_failure_empty_username中，点击按钮后最好加一个短暂的等待，确保错误信息加载出来。可以添加login_page.page.wait_for_timeout(500)或更好的login_page.wait_for_element_visible(login_page.ERROR_MESSAGE)。

通过这样一轮“指令生成 -> 审查优化”的循环，我们就能快速得到一个健壮的测试用例。整个过程，你更像是一个“测试架构师”和“代码评审员”，而AI承担了“初级开发”的编码工作。

5. 进阶技巧：让AI处理复杂场景与数据

基本的登录测试只是开始。Web自动化中真正的挑战在于复杂业务流程和动态测试数据。AI在这些方面同样能提供巨大帮助。

5.1 生成端到端（E2E）业务流程测试

假设我们要测试一个电商的“搜索->加购->下单”流程。这个流程涉及多个页面（首页、搜索列表页、商品详情页、购物车页、结算页）。手动编写这样的测试脚本非常耗时。

我们可以给AI一个高阶指令：

请为一个电商网站编写一个端到端的测试用例 `test_complete_purchase_flow`。 流程如下： 1. 用户已登录（使用已有的 `login_page` fixture 和正确凭据）。 2. 在首页的搜索框（选择器：`#search_input`）中输入关键词“无线耳机”，并点击搜索按钮（选择器：`#search_button`）。 3. 在搜索结果列表页，点击第一个商品的标题链接（标题链接的选择器规律是：`.product-list a.product-title:first-child`）。 4. 在商品详情页，点击“加入购物车”按钮（选择器：`#add_to_cart`）。 5. 页面会弹出一个小浮层提示“已加入购物车”，并有一个“查看购物车”的按钮（选择器：`.cart-popup a.view-cart`），点击它。 6. 进入购物车页面，验证商品名称包含“无线耳机”，数量为1，然后点击“去结算”按钮（选择器：`#checkout_button`）。 7. 在结算页面（假设URL包含‘checkout’），选择默认地址，选择“在线支付”方式，点击“提交订单”按钮（选择器：`#submit_order`）。 8. 最终验证订单提交成功，页面显示“订单创建成功！”的提示（选择器：`.success-message`）。 要求： - 使用Page Object模式，为每个新页面（搜索页、详情页、购物车页、结算页）创建对应的Page类方法。如果类不存在，请先创建它们。 - 在测试用例中，合理使用 `page.wait_for_load_state` 和 `page.wait_for_selector` 来确保页面稳定。 - 处理可能出现的弹窗或加载状态。 - 每一步操作后，都添加相应的断言来验证操作是否成功（例如，点击加入购物车后，验证浮层出现）。

这个指令非常详细，AI（特别是强大的大模型）能够理解整个业务流程，并生成跨越多个Page类的、包含等待和断言的完整测试代码。它可能会先生成SearchPage、ProductDetailPage、CartPage、CheckoutPage的骨架和方法，然后再生成整合它们的测试函数。

关键点：对于如此复杂的指令，分步生成可能更稳妥。可以先让AI生成各个Page类，然后再生成整合的测试用例。这样可以更好地控制代码质量。

5.2 利用AI生成和清理测试数据

测试数据是另一大痛点。AI可以帮我们生成符合要求的假数据，或者清理测试后产生的垃圾数据。

1. 生成测试数据在utils/data_helper.py中，我们可以让AI编写一个函数：

请编写一个函数 `generate_user_data()`，用于生成注册新用户所需的测试数据。 要求： - 返回一个字典，包含字段：username, password, email, first_name, last_name, phone。 - username: 8-12位，字母数字组合。 - password: 至少8位，包含大小写字母和数字。 - email: 格式正确的随机邮箱。 - first_name/last_name: 常见英文名。 - phone: 符合中国或美国格式的随机手机号。 请使用Python的`random`和`string`库实现。

AI生成的函数可以让我们在测试注册、下单等需要新用户的场景中，轻松获得合规的测试数据。

2. 清理测试数据测试可能会在数据库中创建临时数据。我们可以让AI生成一个清理Fixture：

请编写一个Pytest fixture `cleanup_test_user`，作用域为function。 这个fixture在测试函数运行后（yield之后）执行清理操作。 假设我们有一个简单的数据库客户端类 `DBClient`，它有一个方法 `delete_user_by_username(username)`。 这个fixture需要读取测试函数中可能创建的测试用户的用户名（例如，通过一个在测试中设置的 `request.node` 属性 `created_username`），然后调用DBClient删除该用户。 如果 `created_username` 不存在，则跳过清理。

通过这样的指令，AI能帮我们构建起数据生成和清理的闭环，让自动化测试更加独立和可靠。

6. 调试、维护与提示工程实战

AI生成的代码不会总是完美的。元素定位失败、异步加载问题、脆弱的断言是常见问题。这时，我们的角色要从“指令官”转变为“调试伙伴”。

6.1 调试AI生成的代码：定位与等待问题

假设AI生成了一个点击按钮的代码：page.click(“button.submit”)，但运行时报错TimeoutError: Timeout 30000ms exceeded。

错误排查步骤：

1. 检查选择器：首先手动在浏览器开发者工具中检查button.submit这个选择器是否唯一、正确。也许页面有多个.submit类，或者元素是<input type=”submit”>。
2. 检查元素状态：元素是否被遮挡？是否在iframe里？是否被禁用了？Playwright提供了state选项，可以检查元素是否可操作。
3. 优化等待策略：这是AI生成代码最需要人工干预的地方。AI可能使用了默认等待，但页面是动态加载的。

如何让AI修复？在Cursor中，选中报错的行，在Chat里提问：

“这段代码点击按钮超时了。这个按钮在一个动态加载的表格之后才出现。请修改代码，使用Playwright的page.wait_for_selector先等待按钮处于visible和enabled状态，然后再点击。另外，请考虑使用更精确的选择器，比如通过文本内容‘提交订单’来定位。”

AI可能会给出修改后的代码：

# 先等待表格加载完成（假设表格有特定选择器） page.wait_for_selector(“.data-table”, state=“visible”) # 再等待按钮可点击 submit_button = page.locator(“button”, has_text=“提交订单”) submit_button.wait_for(state=“visible”) submit_button.wait_for(state=“enabled”) submit_button.click()

6.2 维护：当页面元素变更时

页面UI改了，id=”old_button”变成了class=”new-btn”。传统维护需要人工搜索替换所有用到这个选择器的地方。用AI可以怎么做？

1. 全局搜索与识别：在Cursor或你的IDE中，全局搜索“old_button”，找到所有引用它的文件。
2. 批量重构：在Cursor中，你可以打开pages/base_page.py或具体的Page类，然后使用Chat指令：“这个项目中，所有#old_button的选择器需要更新为.new-btn。请帮我找出所有需要修改的Python文件，并给出修改建议。” Cursor可以分析项目，列出所有相关文件。
3. 智能更新：对于某个具体的Page类，你可以说：“请更新LoginPage类，将LOGIN_BUTTON的选择器从#old_button改为.new-btn，并检查所有使用到它的方法是否需要调整。”

AI不仅能改一个文件，还能理解项目结构，提供更系统的修改建议，大大减少了漏改的风险。

6.3 提示工程：如何给AI下“好指令”

要让AI输出高质量的测试代码，指令（Prompt）的质量至关重要。以下是一些实战心得：

• 明确角色与上下文：开头一定要设定角色。“你是一个经验丰富的测试开发工程师，精通Pytest和Playwright。”
• 指定技术栈与模式：“使用Python，Pytest测试框架，Playwright同步API，并严格遵守Page Object设计模式。”
• 提供示例代码：“参考项目中已有的LoginPage类的写法。”
• 描述要具体，避免歧义：
  • 差：“测试登录功能。”
  • 好：“编写一个测试函数，使用login_pagefixture，输入正确的用户名（从环境变量TEST_USER获取）和密码，点击登录按钮，然后断言页面标题包含‘Dashboard’字样，并且导航栏出现了用户头像（选择器是img.avatar）。”
• 要求包含等待与断言：“在关键操作后（如点击按钮、跳转页面），请添加合适的等待（如wait_for_load_state(‘networkidle’)），并对操作结果进行明确断言。”
• 要求处理异常情况：“请考虑网络延迟或元素加载失败的情况，在定位元素时使用wait_for_selector并设置合理的超时时间。”
• 分步指令：对于复杂任务，拆分成多个指令。先让AI生成Page类，再生成测试用例，最后生成数据清理Fixture。

7. 常见问题、局限性与最佳实践

经过一段时间的实践，我总结了一些常见问题、AI目前的局限性，以及如何扬长避短的最佳实践。

7.1 常见问题速查表

7.2 AI的局限性：它不能做什么？

我们必须清醒认识到，AI不是银弹：

1. 无法替代测试设计：AI不知道你的业务优先级和风险点。哪些功能需要重点测试，哪些场景需要覆盖，这依然需要测试分析师的经验。
2. 无法理解未经验证的需求：如果需求文档本身有歧义，AI生成的测试代码很可能也是错的。Garbage in, garbage out.
3. 难以处理极度动态的UI：对于选择器每秒都在变的页面（如某些Canvas游戏），AI也无能为力，需要更高级的视觉或图像识别方案。
4. 缺乏“常识”和“经验”：AI不知道上一次部署导致数据库字段变更，也不知道某个第三方服务在周五晚上容易超时。这些“部落知识”需要人来补充。
5. 安全与合规检查：AI生成的代码可能无意中包含硬编码的密钥或不安全的操作，必须经过人工安全审查。

7.3 最佳实践：人机协作工作流

基于以上，我推荐以下人机协作的工作流：

1. 人工主导设计：测试人员设计测试场景、用例和数据。
2. AI辅助实现：将设计好的用例，通过清晰的指令交给AI生成脚本初稿。
3. 人工审查与调试：仔细审查AI生成的代码，特别是元素定位、等待逻辑和断言。运行测试，修复不稳定的地方。
4. 人工补充“智慧”：添加AI难以生成的部分，如复杂的业务逻辑验证、性能检查点、安全测试点、以及与CI/CD集成的钩子。
5. AI辅助维护：当页面变更时，利用AI快速定位和重构受影响的脚本。

最终，AI是一个强大的“倍乘器”，它能把测试人员从繁琐的编码中解放出来，让你更专注于高价值的测试设计、缺陷分析和质量 advocacy。拥抱它，驾驭它，但永远别忘了，你才是质量守门人。