1. 项目概述当AI大模型遇上现代浏览器自动化最近在搞自动化测试的团队估计没少为写测试脚本头疼。尤其是UI自动化一个页面改个按钮位置可能就得花半天时间去调定位器更别提那些复杂的交互流程和异常场景覆盖了。我自己带团队做项目交付深有体会测试脚本的编写和维护成本常常是阻碍自动化测试深度落地的最大绊脚石。就在这个当口我注意到了两个工具的“梦幻联动”一个是微软开源的现代浏览器自动化工具Playwright另一个是国产AI大模型里的“当红炸子鸡”DeepSeek。前者提供了稳定、快速、功能强大的浏览器操控能力支持Chromium、Firefox、WebKit三大内核后者则在代码生成、逻辑理解和上下文推理上表现出色。把它们俩结合一下会怎样简单说就是让AI来帮我们写Playwright测试脚本甚至帮我们思考“测什么”和“怎么测更全”。这可不是简单的“让AI写几行代码”。其核心价值在于利用DeepSeek对自然语言需求的理解能力和代码生成能力将测试人员用口语或简单步骤描述出来的测试意图直接转化为可执行的、健壮的Playwright脚本。更进一步我们还可以引导AI去分析现有代码或页面结构自动识别出测试覆盖的盲区生成补充的测试用例从而实现测试脚本的自动生成与测试覆盖率的智能优化。对于追求研发效能和测试质量的团队来说这无疑打开了一扇新的大门。2. 核心思路与技术选型背后的考量2.1 为什么是Playwright而不是Selenium在决定用AI生成自动化脚本之前选择一个稳定、易用、表达能力强的底层框架是前提。这几年Playwright的崛起势头非常猛在很多新项目中已经逐渐取代了Selenium。我选择它作为自动化底座主要基于以下几点实战考量第一稳定性与速度是硬指标。Playwright直接通过DevTools Protocol与浏览器通信避免了Selenium WebDriver的额外中转层。这意味着更少的网络延迟和更直接的命令执行。在实际对比中同样的操作Playwright的执行速度通常比Selenium快20%-30%这对于动辄成百上千的测试用例集来说节省的时间是巨大的。更重要的是Playwright内置了智能等待机制它会自动等待元素可操作、网络请求完成大大减少了测试脚本中需要手动添加的“sleep”或“显式等待”这让AI生成的代码更不容易因为时序问题而失败。第二强大的内置能力减少胶水代码。Playwright“开箱即用”的特性非常突出。比如它原生支持文件上传下载、拦截和修改网络请求、模拟地理位置和设备权限、生成执行追踪视频等。如果让AI基于Selenium生成一个文件下载后验证的脚本可能还需要引入额外的库来处理文件系统操作和等待。而Playwright一句page.waitForEvent(download)就搞定了。这降低了AI生成代码的复杂度也使得生成的脚本更简洁、更专注于业务验证逻辑本身。第三跨浏览器与多环境支持的一致性。Playwright为三大浏览器引擎提供了高度一致的API。这意味着AI只需要学习一套API就能生成适用于Chrome、Firefox、Safari的测试脚本。对于需要做跨浏览器兼容性测试的项目这简直是福音。我们不再需要为不同浏览器编写或调整不同的定位策略或交互代码。注意虽然Playwright优势明显但如果你的项目强依赖于某些仅支持Selenium的云测试平台如老版本的Sauce Labs或者有大量遗留的Selenium框架代码需要复用那么全面转向Playwright的成本需要评估。不过对于新项目或决心进行技术栈升级的团队Playwright是目前更优的选择。2.2 为什么是DeepSeek而不是其他AI编码助手AI编码助手现在选择很多GitHub Copilot、Claude Code、Cursor等都非常流行。我重点考察DeepSeek是因为它在自动化测试脚本生成这个细分场景下有几个独特的优势上下文长度与成本优势。DeepSeek-V3模型支持128K的上下文长度这对于分析整个页面的HTML结构、或者理解一个复杂的多步骤测试场景描述来说是至关重要的。我们可以把待测页面的DOM快照、现有的测试代码、项目文档一起喂给它让它有更全面的信息来生成准确的脚本。同时DeepSeek API的调用成本相对较低这对于需要频繁、批量生成测试脚本的场景非常友好不用担心账单爆炸。对中文需求的理解更精准。我们的测试人员、产品文档很多都是中文的。DeepSeek作为国产模型在理解中文语境、中文技术术语方面天然有优势。当测试人员用中文描述“点击那个红色的提交按钮然后等弹窗出来在弹窗里输入‘测试数据’并确认”时DeepSeek能更准确地捕捉意图并转化为page.click(button:has-text(提交))page.waitForSelector(.modal)page.fill(.modal input, 测试数据)这样的代码。代码生成风格贴近实际工程。在我大量的测试中DeepSeek生成的Playwright代码不仅语法正确而且会倾向于使用Playwright推荐的最佳实践比如优先使用getByRole、getByText这类面向可访问性的定位器而不是脆弱的XPath或CSS选择器。它还会自动添加必要的断言assertions这是构成有效测试用例的关键而不仅仅是操作步骤的罗列。本地化部署的可行性。对于一些对数据安全要求极高的项目如金融、政务DeepSeek提供了模型权重支持私有化部署。这意味着我们可以在内网环境中搭建一套从需求到脚本的完全自主可控的自动化测试生成流水线彻底杜绝敏感业务数据外泄的风险。3. 环境搭建与核心工具链集成3.1 Playwright测试环境快速初始化要让AI生成的脚本能跑起来一个标准、干净的Playwright环境是基础。这里我分享一套经过多个项目验证的初始化流程能帮你避开不少坑。首先我强烈建议使用Node.js环境而不是Python。虽然Playwright两者都支持但Node.js版本通常更新更快社区生态特别是与前端工具链集成更活跃而且AI模型对JavaScript/TypeScript的代码生成训练数据通常也更丰富。使用npm或yarn初始化项目mkdir ai-playwright-tests cd ai-playwright-tests npm init -y接下来安装Playwright。这里有个关键点不要只安装playwright库而是安装playwright/test这个测试运行器。它是一个集成了运行器、断言库和报告工具的完整框架能让生成的测试脚本结构更规范。npm install --save-dev playwright/test安装完成后运行以下命令来安装所需的浏览器二进制文件Chromium, Firefox, WebKit。我建议使用项目内安装而不是全局安装这样可以保证团队每个成员和CI/CD环境使用的浏览器版本完全一致。npx playwright install实操心得在CI/CD服务器如Jenkins、GitHub Actions上安装时如果网络环境受限可以使用npx playwright install --with-deps chromium只安装必需的Chromium及其系统依赖以加快安装速度并减少磁盘占用。对于UI自动化测试Chromium在绝大多数情况下已经足够。3.2 深度集成DeepSeek API要让我们的脚本“AI化”核心是打通与DeepSeek API的通信。我们不依赖任何可能有版本兼容性问题的第三方中间件直接使用最通用的HTTP请求方式。首先你需要在DeepSeek官网申请API Key。拿到Key之后不要在代码里硬编码。创建一个.env文件来管理敏感信息DEEPSEEK_API_KEYyour_api_key_here DEEPSEEK_API_BASEhttps://api.deepseek.com然后在项目中安装dotenv和axios一个简单好用的HTTP客户端npm install --save-dev dotenv axios接下来我们创建一个核心工具模块ai-test-generator.js。这个模块负责构造请求、与DeepSeek对话并解析返回的代码。// ai-test-generator.js require(dotenv).config(); const axios require(axios); class AITestGenerator { constructor() { this.apiKey process.env.DEEPSEEK_API_KEY; this.apiBase process.env.DEEPSEEK_API_BASE || https://api.deepseek.com; this.client axios.create({ baseURL: this.apiBase, headers: { Authorization: Bearer ${this.apiKey}, Content-Type: application/json, }, }); } /** * 核心方法根据自然语言描述生成Playwright测试脚本 * param {string} requirement - 用自然语言描述的测试需求 * param {string} [pageHtml] - 可选目标页面的HTML片段提供上下文 * returns {Promisestring} - 生成的Playwright测试代码 */ async generateTestScript(requirement, pageHtml ) { const prompt this._constructPrompt(requirement, pageHtml); try { const response await this.client.post(/chat/completions, { model: deepseek-chat, // 根据可用模型调整 messages: [ { role: system, content: 你是一个专业的自动化测试工程师精通Playwright测试框架。请根据用户需求生成完整、可运行、健壮的Playwright测试脚本。使用playwright/test的语法包含必要的导入、测试函数和断言。代码要简洁高效使用最佳的定位器实践如优先使用getByRole, getByText。 }, { role: user, content: prompt } ], temperature: 0.2, // 温度设低保证生成代码的确定性和一致性 max_tokens: 4000, }); // 从AI回复中提取代码块 const content response.data.choices[0].message.content; const codeBlockRegex /(?:javascript|js|typescript|ts)?\n([\s\S]*?)/; const match content.match(codeBlockRegex); if (match match[1]) { return match[1].trim(); } else { // 如果没有代码块尝试直接返回内容有时AI可能不包裹 console.warn(未找到标准的代码块尝试直接返回内容。); return content.trim(); } } catch (error) { console.error(调用DeepSeek API失败:, error.response?.data || error.message); throw new Error(AI脚本生成失败: ${error.message}); } } _constructPrompt(requirement, pageHtml) { let prompt 请为以下测试需求生成Playwright测试脚本\n“${requirement}”\n\n; if (pageHtml) { prompt 这是目标页面的部分HTML结构供你参考元素定位\n\\\html\n${pageHtml}\n\\\\n; } prompt 请遵循以下要求 1. 使用 playwright/test 框架编写一个完整的测试函数。 2. 文件名假设为 example.spec.js。 3. 包含必要的导入import { test, expect } from playwright/test; 4. 测试描述清晰使用 test(描述, async ({ page }) { ... }) 结构。 5. 使用健壮的定位策略优先使用 page.getByRole(), page.getByText(), page.getByLabel()其次使用CSS选择器避免使用脆弱的XPath。 6. 包含明确的断言expect来验证测试结果。 7. 添加适当的等待优先使用 await page.waitForLoadState(networkidle) 或 waitForSelector避免使用固定时间的sleep。 8. 生成的代码应该可以直接复制到文件中运行。 9. 用中文注释解释关键步骤可选。 ; return prompt; } } module.exports AITestGenerator;这个类的设计有几个关键点职责单一只负责与AI通信和生成代码。提示词工程_constructPrompt方法精心构造了给AI的指令明确了框架、语法、最佳实践等要求这是获得高质量代码的关键。错误处理对API调用失败和返回结果中无代码块的情况做了处理。可配置性通过.env文件管理API密钥和地址便于在不同环境开发、测试、生产中切换。有了这个生成器我们就可以在需要的时候传入一句中文描述得到一段可运行的测试代码了。4. 从需求到脚本AI生成测试用例实战4.1 基础功能点测试脚本生成让我们从一个最简单的例子开始。假设我们有一个登录页面需求是“测试用户使用正确的用户名和密码可以成功登录”。我们首先手动或通过Playwright的Codegen工具打开登录页面获取关键元素的HTML片段。比如我们可能得到input typetext idusername placeholder请输入用户名 input typepassword idpassword placeholder请输入密码 button typesubmit classlogin-btn登录/button div classwelcome-message styledisplay: none;欢迎回来用户1/div然后我们调用AI生成器// generate-login-test.js const AITestGenerator require(./ai-test-generator); const fs require(fs).promises; const path require(path); async function main() { const generator new AITestGenerator(); const requirement 测试用户使用正确的用户名和密码可以成功登录。登录后页面应显示欢迎语。已知用户名输入框id是username密码框id是password登录按钮的类名是.login-btn成功登录后显示的欢迎信息元素类名是.welcome-message。; const pageHtml input typetext idusername placeholder请输入用户名 input typepassword idpassword placeholder请输入密码 button typesubmit classlogin-btn登录/button div classwelcome-message styledisplay: none;欢迎回来用户1/div; try { const testCode await generator.generateTestScript(requirement, pageHtml); // 将生成的代码保存到测试文件 const testDir path.join(__dirname, tests); await fs.mkdir(testDir, { recursive: true }); // 确保目录存在 const filePath path.join(testDir, login.spec.js); await fs.writeFile(filePath, testCode, utf8); console.log(✅ 测试脚本已生成并保存至: ${filePath}); console.log(生成的内容预览\n, testCode.substring(0, 500) ...); } catch (error) { console.error(生成失败:, error); } } main();运行这个脚本后我们可能会得到如下内容的login.spec.js文件import { test, expect } from playwright/test; test(用户使用正确凭据成功登录, async ({ page }) { // 1. 导航到登录页面假设登录页面URL为 /login await page.goto(/login); // 2. 等待页面关键元素加载完成 await page.waitForSelector(#username); // 3. 输入正确的用户名和密码 // 使用 getByRole 或 ID 进行定位是更佳实践这里根据提供的ID定位 await page.locator(#username).fill(testuser); await page.locator(#password).fill(securepassword123); // 4. 点击登录按钮 await page.click(.login-btn); // 5. 等待登录后的页面状态或导航完成 // 假设登录成功后会跳转到首页或者显示欢迎信息 await page.waitForURL(**/dashboard); // 或等待欢迎信息元素可见 // 6. 验证登录成功检查欢迎信息是否可见且包含预期文本 const welcomeMessage page.locator(.welcome-message); await expect(welcomeMessage).toBeVisible(); await expect(welcomeMessage).toContainText(欢迎回来); // 额外的断言可以检查URL是否正确或者页面是否存在登录后才有的元素 await expect(page).toHaveURL(/dashboard/); });分析AI生成的代码结构完整遵循了playwright/test的标准结构有导入、测试函数。使用了最佳实践在输入操作前使用了waitForSelector确保元素就绪避免了“元素未找到”的错误。包含了明确的等待使用waitForURL等待导航完成这是一个比固定sleep好得多的模式。断言充分不仅检查了元素可见性还检查了文本内容并且额外验证了URL构成了一个健壮的测试断言集。有改进空间AI使用了page.locator(#username)这没问题。但根据我们提示词的要求优先使用getByRole如果HTML有完善的ARIA属性它可能会生成page.getByRole(textbox, { name: 请输入用户名 })这通常更稳定。我们可以通过提供更详细的HTML上下文包含label标签来引导AI生成更优的定位器。4.2 复杂交互与数据驱动测试生成实际业务中测试场景远不止简单的表单提交。比如我们需要测试一个电商网站的“加入购物车-结算”流程其中涉及多个页面跳转、状态管理和API交互。对于这种复杂场景我们可以采用“分步描述迭代生成”的策略。不要试图让AI一次性生成一个包含10个步骤的超长测试。而是将流程分解并为AI提供更丰富的上下文。第一步生成核心流程骨架。我们可以给AI这样的需求“生成一个Playwright测试脚本模拟用户在电商网站将一件商品加入购物车然后进入购物车页面。已知商品列表页URL是‘/products’商品卡片有一个‘加入购物车’按钮类名为’.add-to-cart’点击后有一个迷你弹窗提示‘已加入’。购物车图标在页面右上角点击可进入‘/cart’页面。”AI可能会生成一个包含页面跳转、点击操作和简单断言如检查URL、检查提示文本的脚本。第二步增强断言与等待。生成的初始脚本可能对异步操作如加入购物车后的API调用处理不足。我们可以手动审查并在需要的地方添加更精确的等待例如等待网络请求完成// 在点击“加入购物车”后等待对应的API请求完成 const [response] await Promise.all([ page.waitForResponse(resp resp.url().includes(/api/cart) resp.status() 200), page.click(.add-to-cart) ]); // 可选断言响应体中的数据 const responseData await response.json(); expect(responseData.success).toBe(true);第三步引入数据驱动。一个测试用例往往需要覆盖多组数据如不同商品、不同用户。我们可以再次借助AI让它帮我们生成一个数据驱动的测试模板。需求描述“将上面的测试脚本改造成数据驱动的形式。使用一个数组testData来存储不同的商品信息例如商品ID或名称。使用test.describe和testData.forEach来为每组数据运行测试。”AI可能会生成类似下面的代码import { test, expect } from playwright/test; const products [ { id: prod_1, name: 测试商品A, cartSelector: [data-product-idprod_1] .add-to-cart }, { id: prod_2, name: 测试商品B, cartSelector: [data-product-idprod_2] .add-to-cart }, ]; test.describe(电商购物车流程 - 数据驱动, () { products.forEach(product { test(将商品 ${product.name} 加入购物车, async ({ page }) { await page.goto(/products); // 使用动态选择器 await page.click(product.cartSelector); await expect(page.locator(.mini-cart-toast)).toContainText(已加入); // ... 后续步骤 }); }); });通过这种“人类规划流程AI填充细节人类审查优化”的协作模式我们可以高效地构建出覆盖核心业务流程的、健壮的自动化测试套件。5. 超越脚本生成利用AI进行覆盖率分析与优化生成脚本只是第一步。一个更高级的应用是利用AI来分析现有测试套件和被测应用智能地识别测试覆盖的盲点并提出优化建议甚至直接生成补充测试用例。这才是“覆盖率优化”的真正含义。5.1 静态分析识别未被覆盖的代码分支我们可以结合前端代码覆盖率工具如 Istanbul被Playwright Test内置支持和DeepSeek的分析能力。操作流程如下运行测试并收集覆盖率数据在Playwright配置中启用覆盖率收集。// playwright.config.js module.exports { use: { // ... 其他配置 trace: on-first-retry, // 启用V8覆盖率收集 coverage: v8, }, // 配置报告器输出覆盖率文件 reporter: [[html], [json, { outputFile: coverage/coverage.json }]], };运行测试后会生成一个coverage/coverage.json文件其中包含了哪些行、哪些函数、哪些分支被测试执行到的信息。提取并格式化覆盖率数据编写一个脚本读取JSON文件提取出覆盖率低例如行覆盖率80%或完全未覆盖的文件和函数。请求AI进行分析与建议将低覆盖率的函数代码、其所在的文件上下文以及相关的业务描述可从代码注释或单独文档中提取发送给DeepSeek。提示词示例“以下是一个前端React组件CheckoutButton.js的代码以及当前测试套件对其的覆盖率报告显示handleClick函数中的折扣逻辑分支未被测试。请分析代码并生成一个Playwright测试用例专门用于测试这个未被覆盖的折扣逻辑分支。代码上下文[粘贴代码]。覆盖率缺口第25-30行的if语句块判断用户是否有优惠券。”执行AI生成的补充测试将AI生成的测试用例整合到测试套件中重新运行测试并收集覆盖率验证缺口是否被填补。这个过程可以部分自动化形成一个“测试-分析-生成-再测试”的闭环。虽然完全自动化还有挑战比如需要理解业务语义但AI可以极大地辅助测试工程师进行分析和用例设计。5.2 动态探索基于用户行为的测试用例挖掘另一个思路是“探索式测试”的自动化。我们可以利用Playwright录制一段真实用户或测试人员的操作流程然后将录制的脚本包含点击序列、输入数据、页面快照交给AI进行分析。操作步骤使用Playwright的playwright codegen命令启动一个浏览器并手动执行一些测试场景。Playwright会生成对应的脚本。将生成的脚本、操作过程中关键页面的截图或HTML快照一起提交给DeepSeek。向AI提问“分析以下录制脚本和页面快照。这是一个用户注册流程的测试。请思考1. 这个测试覆盖了哪些主要的用户操作路径正向流程2. 根据页面表单字段和交互元素你能推断出哪些潜在的异常场景或边界情况没有被测试到例如邮箱格式错误、密码强度不足、重复注册等3. 请为每一个你识别出的潜在异常场景生成一个对应的Playwright测试用例。”AI凭借其对代码和自然语言的理解能力可以“阅读”录制脚本理解其意图并基于对Web应用的通用知识如表单验证、常见交互模式提出一些测试人员可能忽略的异常情况并直接生成测试这些情况的脚本。这相当于请了一位不知疲倦的、知识渊博的测试顾问在不停地为你做测试用例的脑力激荡。6. 工程化集成与持续测试流水线将AI生成测试的能力工程化、流水线化才能最大化其价值。这里我分享一个与GitHub Actions集成的简单方案实现“提交代码自动生成并运行补充测试”。6.1 设计自动化生成流水线核心思路是当开发人员提交新的功能代码或修改现有代码时CI系统自动分析代码变更diff识别出可能受影响的功能模块然后调用AI服务为这些模块生成或更新测试脚本最后自动运行这些脚本进行验证。我们可以创建一个GitHub Actions工作流文件.github/workflows/ai-test-generation.ymlname: AI-Powered Test Generation Validation on: pull_request: branches: [ main, develop ] paths: - src/** # 监听源代码目录的变更 - pages/** jobs: analyze-and-generate: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkoutv3 - name: Setup Node.js uses: actions/setup-nodev3 with: node-version: 18 - name: Install dependencies run: npm ci - name: Install Playwright Browsers run: npx playwright install --with-deps chromium - name: Extract Changed Files Identify Test Scope id: changes run: | # 使用git diff获取本次PR修改的文件列表 echo CHANGED_FILES$(git diff --name-only ${{ github.event.pull_request.base.sha }} ${{ github.sha }} | grep -E \.(js|jsx|ts|tsx|vue)$ | tr \n , | sed s/,$//) $GITHUB_OUTPUT # 这里可以添加更复杂的逻辑比如根据文件路径映射到对应的功能模块描述 echo TEST_SCOPE_DESC\本次修改涉及用户登录组件和商品详情页API调用。\ $GITHUB_OUTPUT - name: Generate Tests via DeepSeek AI env: DEEPSEEK_API_KEY: ${{ secrets.DEEPSEEK_API_KEY }} run: | node scripts/ai-generate-tests.js \ --scope ${{ steps.changes.outputs.TEST_SCOPE_DESC }} \ --output-dir ./generated-tests # 此脚本会调用我们之前写的AITestGenerator根据scope描述生成测试文件 - name: Run Generated Tests run: | # 将生成的测试移动到Playwright的测试目录或直接运行 npx playwright test ./generated-tests --reporterhtml,github continue-on-error: true # 首次生成的测试可能失败允许继续 - name: Upload Test Report if: always() uses: actions/upload-artifactv3 with: name: playwright-report path: playwright-report/ retention-days: 7 - name: Comment PR with Test Results if: always() uses: actions/github-scriptv6 with: script: | const fs require(fs); let summary ## AI 测试生成与执行报告\n\n; summary **变更范围分析:** ${{ steps.changes.outputs.TEST_SCOPE_DESC }}\n\n; // 读取测试结果摘要假设我们有一个简单的结果文件 try { const result fs.readFileSync(./test-results-summary.md, utf8); summary result; } catch (e) { summary ⚠️ 未能读取详细测试结果。\n; } summary \n---\n*此报告由 AI 测试生成流水线自动创建。生成的测试用例位于 \./generated-tests/\ 目录请审查后决定是否合并到主测试套件中。*; github.rest.issues.createComment({ issue_number: context.issue.number, owner: context.repo.owner, repo: context.repo.repo, body: summary });这个工作流做了以下几件事监听代码变更在PR创建或更新时触发。分析变更范围通过git diff找出修改的源码文件并尝试将其映射到业务功能描述这一步可以做得更智能比如通过文件路径规则或简单的配置文件映射。调用AI生成测试执行一个Node.js脚本将功能描述发送给DeepSeek API请求生成针对性的测试脚本并保存到generated-tests目录。运行生成的测试用Playwright运行这些新生成的测试。continue-on-error: true很重要因为首次生成的测试不一定能完全通过但这不影响我们查看结果。报告结果将测试报告HTML格式保存为制品并在PR下方自动评论告知生成和测试的情况。6.2 生成脚本的审查与合并策略AI生成的代码不能盲目信任必须经过人工审查。上述流水线将生成的测试放在一个独立的generated-tests目录而不是直接混入主测试套件tests/就是为了隔离和审查。建议的团队协作流程如下AI作为“初级测试开发”AI负责根据变更描述快速产出测试脚本的“初稿”。开发或测试人员作为“审查者”在PR的评论中看到AI生成的测试报告后需要去查看具体的测试代码。审查逻辑正确性测试步骤是否符合业务逻辑断言是否验证了正确的功能点审查代码质量定位器是否健壮等待逻辑是否合理是否有冗余操作审查数据使用的测试数据如用户名、商品ID是否有效是否需要参数化优化与合并审查者将generated-tests/中可用的测试用例经过必要的优化和调整后手动复制或合并到正式的tests/目录中并提交到同一个PR或新的提交。反馈循环对于AI生成的不合理或错误的代码可以总结模式反过来优化我们给AI的提示词Prompt形成良性循环。7. 避坑指南与效能提升技巧在实际项目中融合AI与Playwright我踩过不少坑也总结出一些能大幅提升效率和成功率的心得。7.1 提示词Prompt工程是成败关键AI生成代码的质量90%取决于你给它的指令是否清晰、具体。以下是一些编写高效Prompt的模板和技巧1. 角色与上下文设定System Prompt每次调用都明确AI的角色和任务边界。“你是一个资深的Web自动化测试工程师精通Playwright和现代JavaScript测试实践。你的任务是根据用户需求生成可直接运行、稳定可靠的端到端E2E测试脚本。”2. 提供结构化、具体的需求User Prompt避免模糊描述。使用“给定-当-那么”Given-When-Then格式或步骤列表来描述场景。差的Prompt“测试登录功能。”好的Prompt“为一个登录页面编写测试。步骤1. 导航到‘/login’。2. 在ID为‘email’的输入框中输入‘testexample.com’。3. 在ID为‘password’的输入框中输入‘password123’。4. 点击文本为‘登录’的按钮。5. 验证页面会跳转到‘/dashboard’并且页面顶部会显示一个包含用户名的欢迎横幅元素选择器为‘.user-welcome’。”3. 明确约束与技术栈在Prompt中重申框架、语法和最佳实践。“请使用 playwright/test 框架用JavaScript编写。使用async/await。优先使用page.getByRole(),page.getByText(),page.getByLabel()进行定位。对于任何点击或输入操作后可能发生的页面导航或元素显隐变化必须使用page.waitForURL()或page.waitForSelector()进行等待禁止使用page.waitForTimeout()。每个测试用例必须包含至少一个明确的expect断言。”4. 提供页面上下文Context如果可能将目标页面的关键HTML片段特别是表单、按钮等交互元素作为上下文提供给AI。这能极大提高定位器的准确性。5. 要求输出格式明确要求AI将代码包裹在Markdown代码块中。“请将完整的测试脚本输出在一个 javascript 代码块中。”7.2 处理AI生成的“脆弱”定位器AI生成的定位器有时会过于依赖具体的文本或脆弱的CSS路径如div:nth-child(3) button。我们需要一个后处理或审查策略建立定位器策略规范在团队内约定优先使用面向角色的定位器(getByRole) 和面向文本的定位器(getByText)其次是面向标签的定位器(getByLabel)最后才是CSS选择器。尽量避免XPath。在给AI的Prompt中强调这一点。使用测试属性Test ID这是最稳定的方法。与前端开发团队约定为重要的可测试元素添加>
尧图网络