46 lines
12 KiB
Markdown
46 lines
12 KiB
Markdown
---
|
||
name: artemis-case-prep
|
||
description: 从多工作表原始 Android 测试用例中筛选适用于目标设备且可由 ARTEMIS 自动执行的用例，核实测试环境和用例信息后标记原表副本，并填写七列批量任务模板。用于准备任务文档，不用于直接运行批次或改造导入器。
|
||
---
|
||
|
||
# ARTEMIS 用例准备
|
||
|
||
把原始测试用例工作簿转成两份可追溯的文件：保留原有内容并新增“是否选中作为自动化执行”（`是`/`否`）列的原表副本，以及只包含选中用例的七列任务表。优先使用用户提供且符合下述七列表头的模板；未提供时使用 [七列模板](assets/artemis-tasks.xlsx)。不要覆盖输入文件。
|
||
|
||
## 先确认适用性，再判断自动化
|
||
|
||
1. 逐页识别真正的用例表、表头、续行、合并单元格及行级适用性；不要以固定列号、`max_row` 或单独的用例编号推断用例。行政清单、报告页和空白格式行不算用例。遇到本项目附件的异构页时，读 [字段与边界](references/workbook-contract.md)。其他原始文档仍须按其实际结构重新识别。
|
||
2. 适用性由用户在**原始用例**中完成：核对目标设备及每条用例的“是否适用”标记、标题限定或明确的适用说明；不强制另建设备能力清单。若有空白、缺少行级判定而无法由原文明确判定，或目标设备信息与原文范围无法对应，列出缺失的工作表与行号（可压缩连续行段），提醒用户补齐并**暂停正式转换**。不得把空白当作“不适用”，也不得从型号臆测设备能力。适用性明确为“否”的用例在自动化列标“否”。
|
||
3. 对适用用例逐条判断能否由 ARTEMIS 的 Android UI 操作及其可用 ADB/日志观察建立前置条件、完成动作并取得可核验结果。依赖人工观察、实物遮挡/断电、外部设备或 PC 操作、主观音画质量评价，或者前置条件无法建立的用例标“否”，不交给 ARTEMIS 试跑。不能因为有步骤文字就判“是”。“是”表示适合自动化执行，不表示测试已经通过。
|
||
原始步骤若有不清晰之处，尤其操作对象、顺序、入口、触发条件或结果判定不明确时，列出来源工作表、行号、原文及具体疑问，向使用者确认后再判定该条用例并定稿 Artemis 提示词。确认前不猜测步骤或界面路径，也不把“否”作为替代澄清的标记；可继续整理其他明确用例，但受影响条目保持待确认，正式任务表待澄清后再交付。
|
||
4. **编写任何 Artemis 提示词之前**，先取得用户提供或明确确认的四项信息：① Android 模拟器名称（不用模拟器时，由用户明确说明“使用真机、不使用模拟器”）；②测试 App 名称；③测试 App 版本；④被测设备名称。模拟器是运行 App 的 Android 环境，被测设备是用例操作的设备，两者不可混用；设备型号、固件版本和用例文档日期不能替代 App 版本。已有对话或用户提供的原始资料中有明确值时直接沿用，不重复索取；仍缺任何一项时集中列出缺项并暂停提示词编写，不生成带占位符的草稿提示词。可先分析原表并整理待确认用例。
|
||
5. 逐条检查用例是否足以确定前置条件、操作对象与顺序、触发条件、可观察的预期结果。原文或用户资料不全时，列出来源工作表、行号、原文和具体缺项，请用户补齐后才编写该条提示词；不猜测步骤、界面路径或预期，也不以“否”代替澄清。涉及“一致/匹配/同步”时，还须取得比较字段、独立的预期值或可信参照及适用范围；不能从被测页面自身反推预期。若用户明确无法取得独立参照，才判为无法自动核验。其他信息完整的用例可继续整理，但正式任务表应待全部待确认项处理后交付。
|
||
6. **测试开始之前**，在目标 Android 环境中统一核验一次实际安装的 App 版本并记录结果；同一轮测试的各条用例沿用该结果，不逐条重新核验。若测试过程中安装版本变化，重新核验。另须确认需要使用的设备 SN、秘钥、设备型号等执行信息。用户已明确这些设备信息可在该工作流中正常流转；相关用例可直接使用已提供的值，不凭空编造。若某项信息本身是用例前置条件或断言所必需，应按第 5 条在编写该条提示词前取得。不要把 ARTEMIS 的模型 API Key 与设备秘钥混同。
|
||
|
||
## 生成与核验
|
||
|
||
- 在原表**副本**的用例表增加且只增加所要求的自动化标记列（若已有此列则更新，不重复新增）；每条用例填 `是` 或 `否`。先核对目标位置不会覆盖既有数据，保留原工作表、原文、图片、合并、格式及非用例页。若所选表格工具不能保真，停止交付并说明损失，不输出貌似完整的副本。遵循可用的 spreadsheet 工作流进行编辑、渲染与导出检查。
|
||
- 任务表严格沿用 `任务` 页的七列顺序：`用例编号 / 检测项目 / 测试子项 / 测试用例 / 前置约束提取 / Artemis提示词 / 任务配置(JSON)`。只写入适用且自动化列为“是”、提示词所需信息已补齐的用例；其他工作表保持模板原样。`用例编号` 只填写原表显示的编号，不附 `（Sheet1!2）`、`〔来源页!行号〕` 等工作表/行号后缀；原表编号不改。重复编号保持原样，处理时另以来源工作表和行号定位用例。`Artemis提示词` 是唯一提交给 AI 的任务正文，其他文本列只作元数据，不自动拼入提示词。
|
||
- `任务配置(JSON)` 可留空，表示继承批次或全局配置；确需逐项覆盖时，只写当前 ARTEMIS 导入器支持的字段和值，使用合法 JSON 对象，不写密钥、占位值或未经确认的设备序列号。模拟器名称和被测设备名称不能当作 `device_serial`；填写前核对实际序列号。字段及导入边界见 [七列契约](references/workbook-contract.md#模板)。
|
||
- “前置约束提取”写目标测试 App 版本及原文实际要求的设备、账号、网络和状态；一致性用例还写明比较字段与独立预期值/来源，草稿中可明确标出待补项，但不把未确认条件写成已满足。“Artemis提示词”**必须以 `【原表显示的用例编号】` 紧接原“测试用例”文本开头**，随后接完整执行说明；例如 `【1.1】【声波配网】手动长按重置恢复出厂后首次绑定完成配网流程` 后另起执行说明。这里的连接是文本拼接，不写字面 `+`；提示词前缀不附来源页/行号。执行说明写明沿用测试开始前统一核验的 App 版本，不要求每条用例再次检查；还须写明起点、操作意图、必要等待/状态转移、可观察的预期及判定方式；一致性断言须明确实际值与哪个预期值比较。直播页的分辨率切换、全屏、声音开启/关闭等目标控件初次未显示时，可先观察画面、轻点直播画面一次并重新观察可能浮现的控件或二级菜单；声音开关仅以可观察的 UI 状态核验，不把需要人工听音的结果判为自动化可核验。卡回看和云回看可将有颜色区域作为有数据的选时线索、空白区域作为无数据线索；选有数据片段时先选择过去且有颜色的区域，再用回放结果核验，不仅凭颜色判通过，也不设计拖动到未来。**仅移动爱家 App** 的卡回放用例可在点击“云回看”后观察是否出现切换入口。以上均是适用场景的条件性提示，不发明 UI 定位器、页面路径、精确坐标或功能。无可用原编号或测试用例文本时列出来源行请用户补齐，不造编号或标题。给 Codex 的通用截图、录屏、证据归档及结论要求不写入“Artemis提示词”；更多写法见 [字段与边界](references/workbook-contract.md)。
|
||
- “前置约束提取”及每条正式“Artemis提示词”都要写明已确认的模拟器名称或真机环境、测试 App 名称与版本、被测设备名称。执行说明沿用测试开始前统一核验的安装版本，不要求逐条再查。用例缺失的操作、前置或预期信息只列在单独的待补清单中；补齐前不写该条提示词，也不将占位内容放进任务表。
|
||
- 每条“Artemis提示词”在完成本用例的操作和结果观察后，要求返回目标 App 内的设备首页并确认首页可见；用例失败或未验证时也应尝试返回。不要把 Android 系统桌面当成设备首页，也不要编造返回路径。若因解绑、页面异常等原因无法返回，说明最终页面和原因。Codex 在开始下一条前核对设备首页已恢复；未恢复时先处理状态问题，避免用例相互干扰。
|
||
- **移动爱家 App** 点击“设置”进入设置页后，先等待页面刷新出实际设置内容并重新观察，确认目标控件属于刷新后的页面，再进行点击或滑动；不能把刚进入时的空白、占位或旧页面当作最终内容。设置页功能项较多；相关用例在已加载的首屏未找到目标时，提示词应允许向上滑动更长距离以查看下方内容，并在每次滑动后重新观察和定位。不要把首屏未见当作功能缺失，也不要规定未经核实的固定等待时间、坐标、距离或盲滑次数；见 [设置页查找边界](references/workbook-contract.md#提示词与决策)。
|
||
- 核对原表每条真实用例的标记均为 `是`/`否`，待确认条目全部处理后，任务表数据行数恰等于“是”的数量；逐行检查编号列只含原表显示的编号、提示词的编号和用例文本前缀，且每条提示词都要求结束时返回 App 内设备首页；核对模拟器或真机环境、App 名称与版本、被测设备名称与用户确认值一致，且提示词没有逐条核验版本、通用截图录屏、证据归档或结论指令。第七列应为空或为可解析、仅含受支持字段的 JSON 对象。抽查一致性用例有独立参照且比较字段明确，再抽查不同表头布局、重复编号、合并/续行和排除项。确认输入文件未改、两份输出的非目标内容未意外变化，且七列表头、提示词与来源可回溯。
|
||
|
||
本七列模板与当前查看的 ARTEMIS `task_import.py` 表头一致，但不能仅凭表头声称文件已通过导入。用户将来要求执行时，先用当时服务的预览校验，再按执行授权启动；本 skill 不改导入器、不调用 `mobile_batch`、不启动设备。编写外部可执行测试代码则先用 ARTEMIS 探索实际应用。
|
||
|
||
## Codex 执行与证据归档（不写入 Artemis 提示词）
|
||
|
||
后续执行测试时，Codex 在关键操作前后截图并保留本任务录屏；记录证据路径，以便归档到工作区“测试佐证”目录。若工具只能保存到 ARTEMIS trace，报告 trace 和证据路径。前置条件不成立、控件未找到或证据不能证明预期时，如实报告阻塞或未验证，不写通过。这些要求由 Codex 处理，不拼入任务表每条“Artemis提示词”。
|
||
|
||
## 执行状态显示取消但之后完成
|
||
|
||
ARTEMIS 执行期间，网页或列表可能显示“取消”/“正在取消”，而之后的持久批次或任务记录又显示已完成。不要依据单次界面快照判最终状态，也不要把“已完成”直接等同于测试通过。执行方应按稳定的批次 ID、session/trace ID 重新读取 ARTEMIS 持久状态，确认取消是否只是请求/过渡状态、任务最终状态，以及报告是否已就绪；检查应遵从工具建议并保持低频，避免连续轮询。
|
||
|
||
- 最终持久记录为 `completed` 且报告已就绪时，核对 trace/报告中的实际步骤、证据和业务判定，再分别记录通过、失败或未验证。
|
||
- 最终持久记录为 `cancelled` 时，它是终态；保留取消记录及已产生的部分证据，不得改写成完成，也不要因界面状态不一致而自动重提同一用例。重跑须有明确授权，并作为新的执行记录。
|
||
- 若批次、session 与网页显示互相矛盾，或报告尚未就绪，记录各自 ID、状态和检查时间，做必要的低频只读核验；矛盾未消除前标记“状态待核实”，不得统计为通过或已完成。
|
||
|
||
此规则只用于解释执行记录，不改变本 skill 的职责范围：本 skill 负责准备与核验用例文档，不负责启动、取消、恢复或重跑 ARTEMIS 任务。
|