在当今快节奏的软件开发周期中，手动测试常常成为显著的瓶颈。我们的团队面临着不断增长的测试用例积压，这些用例需要重复的手动执行——每个冲刺周期都要运行整个测试套件。这消耗了宝贵的时间，而这些时间本可以更好地用于探索性测试和更高价值的任务。

我们通过利用Azure DevOps新的MCP服务器与GitHub Copilot的集成，使用Playwright自动生成和运行端到端测试，来解决这个问题。这一强大组合彻底改变了我们的测试流程：

• 通过AI辅助代码生成，更快地创建测试
• 在关键用户流程中实现更广泛的测试覆盖
• 无缝的CI/CD集成，允许数百个测试自动运行
• 直接从Azure Test Plans体验按需执行测试（即将支持将Playwright JS/TS测试与手动测试用例关联。请关注我们的发布说明以获取公告。）

通过自动化测试流水线，我们显著减少了手动工作，提高了测试可靠性，并加速了发布周期。在本文中，我们将分享我们是如何做到的。

如何将测试用例转化为自动化脚本（逐步指南）

启用这个AI驱动的工作流需要几个部分协同工作。以下是整个过程从开始到结束的工作方式：

通过为每个测试用例遵循上述循环（您可以通过将整个测试套件传递给GitHub Copilot来批量执行），我们逐步将整个手动测试套件转变为自动化套件（仅我们自己的领域就有数百个测试用例，整个项目有超过一千个测试用例）。MCP服务器和Copilot基本上处理了编写代码的重任，而我们的团队监督过程并进行微调。这感觉几乎像魔法——用简单的英语描述一个测试，就能得到一个可运行的自动化脚本！

挑战与经验教训

• 提示是关键！ 不言而喻——您如何提示AI很重要。清晰、具体的提示会产生更好的结果。在我们的案例中，将任务分解为两个提示（“获取测试用例”然后“生成脚本”）比单个组合提示产生更可靠的代码。我们有时还不得不尝试不同的措辞——例如，使用确切的措辞“将上述测试用例步骤转换为Playwright脚本”比模糊的命令效果更好。除此之外，确保将模型指向您有现有测试的相关代码/文件。您提供的参考越多，新生成的脚本就越准确。这有点像一门艺术，但我们使用得越多，就越能感受到GitHub Copilot对哪种措辞反应最好。幸运的是，我们的测试用例描述通常详细且结构化，这使得AI更容易识别操作序列。

• 上下文质量： 您需要在以下两件事之一上花费额外时间：

  • 要么通过在Azure DevOps中编写更清晰、更详细的步骤来改进您的测试用例，
  • 要么花更多时间稍后修复生成的脚本。

如果您选择改进测试用例，请确保它们是具体的。以下是一些模糊和具体步骤的示例：

• 处理非文本步骤： 一些测试场景涉及图形或媒体（例如，“验证图表看起来正确”或检查图像）。当前的Copilot代理无法解释图像或视觉断言——它的领域是文本。我们的概念验证证实，如果测试步骤说“比较截图”，AI不会神奇地进行图像比较。解决方法是调整这些步骤，使其可以通过DOM或数据进行验证（或者暂时手动处理这些情况）。实际上，这是一个较小的限制——我们绝大多数的测试步骤都是诸如“点击这个”或“输入那个”之类的事情，AI处理得很好。但需要意识到：对于纯粹的视觉验证，您需要用传统方法补充，或使用Playwright的截图断言与预定义的基线图像。

附录

提示

以下是可以帮助您入门的两个提示。生成脚本后，您可以调整它们，直到可以在本地成功执行为止。一旦对脚本满意，您可以创建一个Azure Pipeline，定期将其作为一部分执行。

确保根据您的具体需求和上下文调整提示——这将帮助Copilot生成更高质量的脚本。

提示1：

1
2
3
4
5
6
7
8

获取测试用例的详细信息（暂时不要执行任何操作，只需给我每个测试用例的详细信息）。

测试信息：

*   ADO组织：Org_Name
*   项目：Project_Name
*   测试计划ID：Test_Plan_ID
*   测试套件ID：Test_Suite_ID

Copilot通过MCP服务器获取每个测试用例的详细信息后，使用以下提示：

提示2：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70

想象您是一位经验丰富的软件工程师，帮助我根据我提供的测试用例编写高质量的Playwright TypeScript测试脚本。请检查任务两次，确保脚本准确可靠。避免编造，不要产生幻觉。使用下面概述的所有额外信息，编写最适合我项目的最佳脚本。

# 项目上下文

查看“Project_name”文件夹以获取更多见解（如果您的项目相当大，请使用以下部分更具体，并引用特定的文件夹/文件）。

我的项目结构包括：

*   身份验证助手：//*添加/文件夹/路径*
*   现有示例测试：//*添加/文件夹/路径*
*   Playwright配置：//*添加/文件夹/路径*
*   测试结构：//*添加/文件夹/路径/test-1656280.spec.ts*
*   项目的UX组件在以下文件夹中：//*添加/文件夹/路径*。

# 测试结构要求

对于每个测试，请遵循以下结构：

1.  使用 *'test.describe()'* 块的清晰测试描述
2.  在任何页面导航之前进行适当的身份验证设置
3.  具有多个备用方案的稳健选择器策略
4.  用于调试的详细日志记录
5.  在关键点捕获截图以进行验证
6.  具有清晰错误信息的适当错误处理
7.  适当的超时和等待策略
8.  匹配测试用例验收标准的验证/断言步骤

# 稳健性要求

每个测试应包括：

1.  用于不稳定UI元素的重试机制
2.  用于查找元素的多种选择器策略
3.  对网络空闲和页面加载状态的显式等待
4.  每个测试步骤的清晰日志记录
5.  失败时的详细错误报告和截图
6.  处理意外对话框或通知
7.  具有清晰错误信息的超时处理

# 环境考虑

测试将在以下环境中运行：

*   CI/CD流水线环境
*   默认无头模式
*   可能有网络延迟
*   不同的视口大小

# 示例用法

请提供完整的实现，包括：

1.  用于身份验证和常见操作的辅助函数
2.  每个测试用例的完整测试实现
3.  解释复杂逻辑的注释
4.  测试执行指南

# 身份验证方法

为了使测试能够执行，我们需要对应用程序进行身份验证。使用以下身份验证方法：

//{您需要定义身份验证步骤——如果您的项目已经定义了这些，请指导Copilot如何使用。如果您的场景不需要身份验证，可以从提示中删除此部分。}

# 配置参考

对于超时、截图设置和其他配置选项，请参考：

//{添加对特定文件等的引用以获取更好的上下文}

我希望这些测试可维护、可靠，并在失败时提供清晰的反馈。