AI-移动端自动化整体框架 — 各阶段提示词-初稿-ai生成
移动端自动化整体框架 — 各阶段提示词
📌 阶段一：AI 分析需求
1.1 需求文档解析
markdown
1# Role: 移动端测试需求分析师
2
3你是一位资深移动端测试专家，擅长从产品需求文档(PRD)中提取可测试点。
4
5# Input
6- 产品需求文档内容（附在下方）
7- 目标平台：Android / iOS / 两者
8- App类型：原生/Hybrid/Flutter/React Native
9
10# Task
11请按以下结构输出分析结果：
12
13## 1. 功能模块拆解
14- 列出所有一级模块、二级功能点
15- 标注每个功能点的优先级（P0/P1/P2）
16
17## 2. 可自动化识别
18| 功能点 | 是否可自动化 | 自动化难度 | 推荐技术 | 备注 |
19|--------|-------------|-----------|---------|------|
20
21## 3. 核心业务流程
22- 用流程图文字描述 Top5 核心用户路径
23- 标注每个路径的关键断言点
24
25## 4. 风险点分析
26- 哪些场景不适合自动化（如手势、动画、弱网、兼容性）
27- 哪些场景需要专项测试（如支付、权限、推送）
28
29## 5. 数据依赖分析
30- 需要哪些测试数据准备
31- 是否需要Mock接口
32- 是否需要注入特殊环境（定位、语言、时区）
33
34# Constraints
35- 假设使用 Appium + Python/Java 技术栈
36- 考虑主流机型兼容性（Top 20机型）
37- 输出要直接可用于下一阶段用例编写
381.2 需求转测试点
markdown
1# Role: 测试用例设计专家
2
3基于以下需求描述，生成测试点思维导图。
4
5# Input
6需求描述：{{用户登录模块支持手机号+验证码登录，验证码60s倒计时，
7支持本机号码一键登录，登录失败5次锁定账户30分钟}}
8
9# Task
10请输出：
11
12## 正向测试点
13- 手机号+验证码正常登录
14- 本机号码一键登录
15- 验证码倒计时显示正确（60s）
16- 倒计时结束后按钮状态变化
17
18## 逆向测试点
19- 手机号为空/格式错误
20- 验证码错误/过期/为空
21- 登录失败1次/5次/6次的边界
22- 锁定后再尝试登录
23- 锁定30分钟后自动解锁
24
25## 异常测试点
26- 无网络/弱网/网络切换
27- 验证码接口超时/返回异常
28- 前后台切换（收到验证码时）
29- 多设备同时登录
30
31## 兼容性测试点
32- 不同屏幕尺寸
33- 不同系统版本（Android 10-14 / iOS 15-17）
34- 不同输入法
35
36## 性能测试点
37- 登录接口响应时间
38- 验证码倒计时精度
39- 失败5次锁定的时间准确性
40
41# Output Format
42JSON格式，包含字段：case_id, module, title, priority, type(正向/逆向/异常/兼容/性能), preconditions, steps, expected
43📌 阶段二：用例编写
2.1 单用例生成（Page Object 模式）
markdown
1# Role: 移动端自动化测试工程师
2
3技术栈：Appium 2.x + Python + pytest + Page Object Model
4
5请为以下测试场景生成完整可执行代码：
6
7# Scenario
8{{场景：用户在首页点击"我的"tab，进入个人中心，验证用户昵称和头像显示正确}}
9
10# App信息
11- 包名：com.example.app
12- 主Activity：.MainActivity
13- 页面元素定位信息：
14 - 首页"我的"tab：id="com.example.app:id/tab_mine"
15 - 个人中心昵称：xpath="//android.widget.TextView[@text='用户昵称']"
16 - 个人中心头像：id="com.example.app:id/iv_avatar"
17
18# 要求输出以下文件结构：
19📁 pages/
20 📄 home_page.py # 首页Page Object
21 📄 mine_page.py # 个人中心Page Object
22📁 tests/
23 📄 test_mine_nav.py # 测试用例
24📁 conftest.py # pytest fixtures
25📁 locators/
26 📄 mine_locators.py # 元素定位（独立文件）
27
28# 代码规范
291. 每个Page类继承BasePage，封装通用方法：swipe, wait_element, scroll_to
302. 使用显式等待（WebDriverWait），超时10s
313. 断言使用assert，失败截图自动保存
324. 元素定位优先用id > accessibility_id > xpath
335. 添加中文docstring
346. 关键操作添加日志（logging模块）
357. 处理常见异常：NoSuchElement, StaleElement, Timeout
362.2 批量用例生成（数据驱动）
markdown
1# Role: 自动化测试架构师
2
3请基于以下登录场景，生成数据驱动的测试用例：
4
5# 场景
6登录模块，支持4种登录方式，需要覆盖正向+逆向
7
8# 数据表
9| case_id | phone | verify_code | expect_result | scenario_desc |
10|---------|-------------|-------------|---------------|------------------------|
11| L001 | 13800138001 | 123456 | 登录成功 | 正常手机号+正确验证码 |
12| L002 | 13800138001 | 000000 | 验证码错误 | 正确手机+错误验证码 |
13| L003 | 13800138001 | 空 | 提示输入验证码 | 验证码为空 |
14| L004 | 空 | 123456 | 提示输入手机号 | 手机号为空 |
15| L005 | 123 | 123456 | 格式错误 | 手机号格式错误 |
16| L006 | 13800138001 | expired | 验证码已过期 | 验证码过期 |
17| L007 | locked_user | 123456 | 账户已锁定 | 锁定账户尝试登录 |
18| L008 | 本地号码 | - | 一键登录成功 | 本机号码一键登录 |
19
20# 生成要求
211. 使用 @pytest.mark.parametrize 装饰器
222. 测试数据从YAML/Excel读取（给出读取代码）
233. 每个case自动生成Allure报告标题
244. 失败用例自动重试1次（@pytest.mark.flaky）
255. 生成测试数据工厂类 DataFactory，支持随机生成手机号
266. 给出完整的 pytest.ini 配置（Allure、重试、并行）
27
28# 输出
29- test_login.py（完整代码）
30- test_data.yaml（测试数据）
31- conftest.py（fixtures + hooks）
322.3 复杂场景用例（业务流）
markdown
1# Role: 移动端E2E自动化专家
2
3请为以下电商下单流程生成自动化用例：
4
5# 业务流程
6首页 → 搜索"手机" → 商品列表 → 点击第一个商品 → 商品详情
7→ 加入购物车 → 购物车 → 结算 → 确认订单 → 支付成功 → 订单列表验证
8
9# 技术要求
101. 使用 Screenplay Pattern（Actor-Task-Question）或 BDD风格（given/when/then）
112. 每个页面独立Page Object
123. 购物车数量变化需要等待动画完成
134. 支付环节需要Mock（不走真实支付）
145. 订单生成后需要轮询接口查询状态（最多等30s）
156. 考虑页面加载骨架屏的等待策略
167. 流程中任意步骤失败，自动截图+录屏+日志
17
18# 额外要求
19- 生成流程编排类 OrderFlow，支持一键执行全流程
20- 生成失败恢复机制（如支付失败后回到购物车）
21- 给出Appium Desired Capabilities配置（含自动化名称、系统版本等）
22- 生成CI/CD集成代码（Jenkinsfile / GitHub Actions）
23
24# 输出结构
25📁 framework/
26 📄 base_page.py
27 📄 actor.py # Screenplay Actor
28 📄 order_flow.py # 流程编排
29 📄 api_helper.py # 接口Mock辅助
30📁 pages/
31 📄 home_page.py
32 📄 search_page.py
33 📄 product_page.py
34 📄 cart_page.py
35 📄 checkout_page.py
36 📄 order_page.py
37📁 tests/
38 📄 test_order_flow.py
39📁 config/
40 📄 capabilities.yaml
41 📄 test_data.yaml
42📌 阶段三：用例执行
3.1 执行引擎提示词
markdown
1# Role: 自动化测试执行引擎
2
3你是一个智能测试执行调度器，负责管理和执行移动端自动化用例。
4
5# Input
6- 测试用例集合：{{从pytest collect获取的用例列表}}
7- 设备池信息：
8 [
9 {"udid": "emulator-5554", "platform": "Android", "version": "13", "device": "Pixel 6"},
10 {"udid": "emulator-5556", "platform": "Android", "version": "14", "device": "Pixel 8"},
11 {"udid": "iPhone 15", "platform": "iOS", "version": "17.2", "device": "iPhone 15"}
12 ]
13- 执行策略：{{冒烟优先 / 回归全量 / 随机探索}}
14
15# Task
16请生成执行方案：
17
18## 1. 执行计划
19- 用例分桶（按模块/优先级/设备兼容性）
20- 并行执行方案（最大并发数、设备分配）
21- 执行顺序（依赖关系、前置条件）
22
23## 2. 设备分配矩阵
24| 设备 | 分配用例 | 预估时间 | 优先级 |
25|------|---------|---------|--------|
26
27## 3. 失败重试策略
28- flaky用例识别规则（基于历史执行数据）
29- 重试次数和间隔
30- 失败后是否阻断后续用例
31
32## 4. 实时监控指标
33- 需要收集的指标：执行时长、CPU/内存、FPS、流量
34- 告警阈值设置
35- 异常检测规则（如ANR、Crash、超时）
36
37## 5. 报告模板
38- Allure报告结构
39- 失败用例自动归类（环境问题/Bug/用例问题）
40- 生成执行摘要（通过率、耗时、阻塞问题）
41
42# 生成可执行的Python调度脚本
43- 使用 subprocess/multiprocessing 实现并行
44- 集成 ADB/WDA 设备管理
45- 生成执行日志（JSON格式，便于分析）
463.2 失败分析与自愈
markdown
1# Role: 自动化测试失败诊断专家
2
3以下是一条失败的自动化执行日志，请分析原因并给出修复方案：
4
5# Log
6[2024-01-15 10:23:45] INFO Starting test: test_login_verify_code
7[2024-01-15 10:23:46] INFO Navigating to login page...
8[2024-01-15 10:23:48] INFO Entering phone: 13800138001
9[2024-01-15 10:23:49] INFO Clicking send code button
10[2024-01-15 10:23:55] ERROR TimeoutException: Message:
11 An element could not be located on the page using the given search parameters.
12 Locator: id="com.example.app:id/et_verify_code"
13 Wait time: 10s
14[2024-01-15 10:23:55] INFO Screenshot saved: ./reports/screenshots/fail_001.png
15[2024-01-15 10:23:55] INFO Page source length: 85432
16
17# 页面快照（简化）
18<FrameLayout>
19 <LinearLayout>
20 <EditText id="et_phone" text="13800138001"/>
21 <Button id="btn_send" text="获取验证码"/>
22 <View id="countdown_view" visibility="visible" text="59s"/>
23 <!-- 注意：验证码输入框还未出现 -->
24 </LinearLayout>
25</FrameLayout>
26
27# 请分析：
281. 🔴 根本原因是什么？（不是超时，是元素还没渲染）
292. 🔧 修复方案（给出3种，按推荐度排序）
303. 🛡️ 预防方案（如何避免同类问题）
314. 📝 修复后的代码（Page Object + 等待策略）
325. 🧪 是否需要新增用例覆盖此场景
33
34# 关键提示
35- 发送验证码后，输入框是延迟渲染的（先显示倒计时）
36- 考虑加载动画、网络请求完成的等待
37- 对比前后页面结构变化
383.3 执行报告生成
markdown
1# Role: 测试报告分析师
2
3基于以下执行结果，生成多维度分析报告：
4
5# Execution Result (JSON)
6{
7 "total": 156,
8 "passed": 132,
9 "failed": 18,
10 "skipped": 4,
11 "flaky": 2,
12 "duration": "45m32s",
13 "devices": [
14 {"name": "Pixel 6", "passed": 45, "failed": 3},
15 {"name": "Pixel 8", "passed": 44, "failed": 5},
16 {"name": "iPhone 15", "passed": 43, "failed": 10}
17 ],
18 "failures": [
19 {"case": "test_payment_wechat", "error": "ElementNotVisible", "device": "iPhone 15"},
20 {"case": "test_cart_add", "error": "Timeout", "device": "Pixel 8"},
21 ...
22 ]
23}
24
25# 生成报告包含：
26
27## 📊 执行总览
28- 通过率趋势（对比上次执行）
29- 设备维度通过率对比
30- 模块维度通过率热力图
31
32## 🔴 失败根因分类
33| 类别 | 数量 | 占比 | Top问题 |
34|------|-----|------|---------|
35| 元素定位失效 | 8 | 44% | 页面结构变化 |
36| 超时/等待不足 | 5 | 28% | 接口响应慢 |
37| 测试数据问题 | 3 | 17% | 账号被封禁 |
38| 环境问题 | 2 | 11% | iOS WDA崩溃 |
39
40## 📈 质量趋势
41- 近7次执行通过率趋势图（ASCII）
42- Flaky用例Top5（建议删除或修复）
43- 平均执行时长变化
44
45## 💡 改进建议
461. 短期（本周）：修复Top3失败用例
472. 中期（本月）：引入元素定位自愈机制
483. 长期（本季）：接入AI视觉定位替代XPath
49
50## 📋 待办清单
51- [ ] 修复 test_payment_wechat（iOS 17适配）
52- [ ] 优化 test_cart_add 等待策略
53- [ ] 更新登录模块元素定位（v2.3页面改版）
54- [ ] 新增iOS 17.2兼容性用例
55
56# 输出格式：Markdown，可直接粘贴到Confluence/飞书
57📌 阶段四：整体框架构建
4.1 框架架构设计
markdown
1# Role: 移动端自动化测试架构师
2
3请设计一套企业级移动端自动化测试框架，要求如下：
4
5# 项目背景
6- App类型：电商App（原生Android + iOS，含H5页面）
7- 团队规模：5人测试团队
8- 迭代周期：双周迭代
9- 现有痛点：用例维护成本高、执行不稳定、报告不直观、CI集成差
10
11# 技术选型约束
12- 语言：Python 3.10+
13- 核心：Appium 2.x + pytest
14- 可选集成：Allure / Airtest / ATX / UIAutomator2
15
16# 请输出完整架构设计：
17
18## 1. 目录结构（树状图）
19要求分层清晰，遵循关注点分离原则
20
21## 2. 核心模块设计
22每个模块说明：职责、关键类、依赖关系
23
24### 必含模块
25- 🔧 基础层（BasePage, DriverManager, ConfigLoader）
26- 📱 页面层（Page Object，按业务模块分包）
27- 🧪 用例层（测试用例 + 数据驱动 + BDD场景）
28- 🛠️ 工具层（日志、截图、录屏、Mock、ADB封装）
29- 📊 报告层（Allure定制、数据分析、通知）
30- 🚀 执行层（并发执行、设备管理、CI集成）
31
32### 可选模块
33- 🤖 AI增强（视觉定位、用例自愈、智能等待）
34- 📈 监控层（性能采集、Crash监控、ANR检测）
35- 🗄️ 数据层（测试数据工厂、数据清理、Mock服务）
36
37## 3. 核心类设计
38给出关键类的代码骨架：
39- AppDriver（单例驱动管理，支持多设备）
40- PageObject（基类，封装通用操作）
41- TestDataFactory（测试数据生成）
42- RetryDecorator（失败重试）
43- DevicePool（设备池管理）
44
45## 4. 设计模式应用
46说明在框架中如何应用：
47- 单例模式、工厂模式、装饰器模式、策略模式
48- 给出具体应用场景和代码示例
49
50## 5. 扩展性设计
51- 如何新增一个App的自动化（多App支持）
52- 如何新增一种测试类型（性能/安全/兼容性）
53- 插件化机制设计
54
55## 6. CI/CD 流水线
56给出 GitHub Actions / Jenkins 完整配置
57- 触发条件（PR/定时/手动）
58- 执行策略（分层执行：冒烟→回归→全量）
59- 报告推送（钉钉/飞书/Slack）
60
61## 7. 运维考虑
62- 日志轮转
63- 测试数据隔离
64- 设备农场对接（Testin/WeTest/Kobiton）
65- 版本兼容性矩阵
66
67# 输出要求
68- 每个模块给出代码骨架（关键方法签名+docstring）
69- 画出架构图（Mermaid格式）
70- 标注哪些部分可以先MVP，哪些后续迭代
714.2 框架代码生成（MVP版本）
markdown
1# Role: Python开发工程师
2
3基于上述架构设计，先实现MVP版本，要求：
4
5# MVP范围（2天可交付）
6✅ 项目骨架 + 目录结构
7✅ 基础PageObject基类（含等待、滑动、截图）
8✅ 单设备Appium驱动管理
9✅ 1个完整业务流程用例（登录→首页→个人中心）
10✅ pytest配置 + Allure报告
11✅ README文档（5分钟上手）
12✅ GitHub Actions CI（触发执行+推送报告）
13
14❌ 暂不做：多设备并行、AI视觉、数据工厂、Mock服务
15
16# 请按以下顺序输出代码：
17
18## Step 1: 项目初始化
19- requirements.txt
20- pyproject.toml (含pytest/allure/appium依赖)
21- pytest.ini
22- .github/workflows/mobile_test.yml
23
24## Step 2: 核心框架代码
25- framework/__init__.py
26- framework/base_page.py（重点：显式等待封装、日志、截图失败处理）
27- framework/driver_manager.py（单例、生命周期管理）
28- framework/config_loader.py（YAML配置读取）
29
30## Step 3: 页面对象（以登录+首页为例）
31- pages/login_page.py
32- pages/home_page.py
33- pages/mine_page.py
34- locators/locators.py（集中管理，支持YAML覆盖）
35
36## Step 4: 测试用例
37- tests/test_login_flow.py（含 parametrize + Allure + 失败截图）
38- conftest.py（fixture: driver, page objects注入）
39
40## Step 5: 辅助工具
41- utils/logger.py（彩色日志）
42- utils/screenshot.py（失败自动截图+录屏开关）
43- utils/adb_helper.py（常用ADB命令封装）
44
45## Step 6: 文档
46- README.md（安装、运行、截图、CI、目录说明）
47- FRAMEWORK_DESIGN.md（架构说明）
48
49# 代码规范
50- PEP8 + 中文docstring
51- Type Hints
52- 关键异常必须捕获并记录
53- 不使用硬编码，所有可配置项走config.yaml
54- 日志级别：DEBUG(开发) / INFO(执行) / ERROR(失败)
55
56# 验证标准
57- clone后 pip install -r requirements.txt 即可运行
58- pytest -v 能发现并执行所有用例
59- Allure serve 能看到带截图的报告
604.3 框架演进提示词
markdown
1# Role: 自动化测试技术负责人
2
3当前MVP框架已运行2个月，收集到以下反馈，请设计V2.0演进方案：
4
5# 现状痛点
61. 页面元素定位维护成本高（每周约5个用例因元素变化失败）
72. iOS执行稳定性差（通过率仅78%，Android 92%）
83. 测试数据管理混乱（硬编码多，数据污染）
94. 缺少性能指标（不知道App性能是否退化）
105. 团队新人上手慢（框架文档不够）
11
12# 演进目标
13| 指标 | 当前 | 目标(V2.0) |
14|------|------|-----------|
15| 用例维护成本 | 5个/周 | <1个/周 |
16| iOS通过率 | 78% | >90% |
17| 新人上手时间 | 3天 | 0.5天 |
18| 性能监控覆盖 | 0% | 核心流程100% |
19
20# 请输出V2.0方案：
21
22## 1. 技术改进
23### 1.1 元素定位自愈（最高优先级）
24- 方案对比：AI视觉定位 vs 智能XPath vs 双重定位策略
25- 推荐方案 + 实现思路 + 工作量评估
26
27### 1.2 iOS稳定性提升
28- WDA常见问题排查清单
29- 等待策略优化方案
30- 推荐是否引入Airtest/ATX辅助
31
32### 1.3 测试数据管理
33- 数据工厂设计（工厂模式 + Faker）
34- 数据隔离方案（每个用例独立数据）
35- 数据清理策略（AfterEach钩子）
36
37### 1.4 性能采集
38- Appium Performance Data 采集
39- 关键指标：FPS、内存、CPU、流量、启动时间
40- 性能基线对比机制
41
42## 2. 架构升级
43- 插件化设计（pytest hook + entry_points）
44- 多App支持配置化
45- 页面对象自动生成工具（从Appium Inspector导出）
46
47## 3. 开发者体验
48- 录制回放工具集成（Appium Inspector → 代码生成）
49- 交互式调试工具（IPython嵌入）
50- 视频教程大纲（5个视频，每个10分钟）
51
52## 4. 演进路线图
53Month 1: 元素定位自愈 + iOS稳定性
Month 2: 数据工厂 + 性能采集
Month 3: 插件化 + 文档完善
1
2## 5. 工作量估算
3| 任务 | 人天 | 负责人 | 依赖 |
4|------|-----|--------|------|
5
6# 输出：技术方案文档 + 每个改进点的POC代码
7🗂️ 提示词速查表
| 阶段 | 核心提示词关键词 | 输出物 |
|---|---|---|
| 需求分析 | 模块拆解、可自动化识别、风险点、数据依赖 | 测试点矩阵、自动化可行性报告 |
| 用例编写 | Page Object、数据驱动、parametrize、BDD、Screenplay | .py文件、YAML数据、Page类 |
| 用例执行 | 并行执行、设备分配、失败分析、自愈、Allure | 执行脚本、分析报告、修复方案 |
| 框架构建 | 架构设计、设计模式、MVP、CI/CD、演进 | 完整项目骨架、文档、路线图 |
💡 使用建议：将以上提示词存入内部知识库（如Notion/飞书），按阶段串联使用。先用阶段一输出作为阶段二的Input，形成 需求→用例→执行→框架 的完整闭环。
浙公网安备 33010602011771号