xiaoxiao
/
AI_UIAutomation
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
AI_UIAutomation/prompts/p0_coverage_report.md

5.6 KiB
Raw Permalink Blame History

P0 覆盖度生成提示词

用途:让 Claude Code 自动盘点 SwitchBot App UI 自动化的 P0 必测项覆盖度(含覆盖率),输出"已覆盖 / 缺口 + 覆盖率"报告。 用法:在仓库根目录(/Users/woan/Desktop/AI_UIAutomation)把下面【提示词】整段发给 Claude。

【提示词】

盘点 P0 必测项(ONES 计划 CQz9YCNX / lib EPfZfC9Y)的自动化覆盖度,必须算出覆盖率(含添加+控制+平台+功能四类,不能只算添加)。按以下规则执行:

数据源

  1. P0 必测项全集 = test-plan/must-test.manifest.ts(199 条 item / 96 个唯一 ONES 号;字段:kind(add/feature/ctrl/platform)、ones、name、cat、device、file、status)。
    • 构成:add ≈73、feature 9、platform 12、ctrl=105(2 条协议超级用例逐 step:15975 BLE + 15974 WiFi)。
  2. 真实在跑的脚本 = scripts/run-p0-all.sh(Android:ADD_CMDS/CONTROL/TAIL)+ scripts/run-ios-adds.sh(iOS 添加,含 hub_connect 等 Android 没单跑的)+ scripts/run-ios-controls.sh。在这些列表里的 *_connect.test.ts = 真实已实现的添加;*_card/*_control = 控制。
  3. 实际用例文件 = tests/<品类>/*.test.ts。

判定规则(踩过的坑,务必遵守)

  • ⚠️ 号对不上:manifest 的必测 ONES 号 ≠ 脚本运行时注入的锚点号(例:"添加Hub Mini"必测=15972、脚本锚=21787;锚点由 ones-anchor helper 运行时注入、不在 .test.ts 源码里)。→ 绝不能按 ONES 号自动匹配,也不能 grep 源码找锚点。必须按设备/型号名人工核对。
  • ⚠️ 别信 manifest.file 字段:用旧泛名(lock_control/plug_connect/robot_connect/ceiling_light_connect/camera_connect/sensor_connect),与真实脚本名不符。真实换名示例:lock_control→lock_card、bot_control→bot_card、robot_control→robot_card、air_condition_control→air_purifier_card、sensor_connect→motion_/contact_/presence_sensor_connect、camera_connect→doorbell_/outdoor_ptc_connect、plug_connect→plug_mini_connect、robot_connect→robot_s1p_/s10_connect、humidifier_connect→humidifier2_connect、ceiling_light_connect→ceiling_light_pro_/floor_lamp_/color_floor_lamp_connect、strip_light→strip_light_/strip_light_3_/neon_light_connect。
  • ⚠️ 文件存在 ≠ 已覆盖:有些 connect 是 skip 占位/骨架(典型 lock_connect.test.ts:锁添加需物理校准,只有"已存在跳过"逻辑、不在任何 P0 ADD 清单)→ 算未覆盖。判"已覆盖添加"的硬标准:该设备的 connect 脚本真实出现在 run-p0-all.sh 或 run-ios-adds.sh 的添加列表里。
  • ✅ 控制覆盖率通常远高于添加:很多设备添加加不上(需校准/扫码)、但控制有脚本(Lock 添加✗ 但 lock_card✓;风扇/扫地机控制同理)。所以只看添加会严重低估——必须四类都算。
  • N/A(不计入覆盖率分母):无法自动化的项。已知:摄像头扫码添加(Indoor Cam/Pan-Tilt/Pan-Tilt 2K/PTC Plus 3MP·5MP)、safety alarm 之外暂无;强绑定设备自动解绑(需真实态+人工)。⚠️ safety alarm 添加是有覆盖的(safety_alarm_connect.test.ts 在 P0),别误归 N/A。

已知边界(2026-06 实测,直接采用)

  • 已覆盖添加:Bot/Meter系/传感器(motion/contact/presence)/Curtain系/Water/Weather/safety alarm/Hub3·Plus·Matter/Relay Switch(脚本在跑,当前配对失败待修)/Plug Mini(JP/US/EU)/各类灯(Color Bulb/吸顶灯Pro/Strip/Floor/Neon/Strip3/屋檐,新灯除融蜡灯外都覆盖)/Robot S1 Plus·S10/Keypad Vision·Touch/AI Hub·Art Frame/Air Purifier/Humidifier2/URC/Find Card/Doorbell·Outdoor PTC。
  • 添加缺口:锁全系(校准)、Blind Tilt(百叶帘)、Roller Shade(卷帘)、风扇全系、K系列扫地机(K10+/K10+Pro/K11+/S20/Combo)、OSC添加、Hub 新款(Hub Mini/Hub2/各 S3)、融蜡灯(110V)、Garage Door、Climate Panel、暖气阀、原版 Plug/Humidifier/Robot S1。
  • 控制缺口:风扇控制、Garage Door 控制、K10+/K10+Pro/Combo 扫地机控制。OSC 拉流控制已覆盖(走摄像头拉流 camera_stream)。
  • 平台缺口:第三方操作验证、覆盖安装测试(其余 10 项有脚本:注册/忘记密码/第三方登录/登出/创建房间/feedback/场景/插件热更/欧区登录/消息中心)。

执行(纯静态,不需真机)

  1. 读 manifest 全集(199 项)。2. 读 run-p0-all.sh + run-ios-adds.sh + run-ios-controls.sh 的列表。3. 按设备名逐项核对(用上面"换名示例"+"已知边界")。4. 产出报告。

输出格式

  1. 总覆盖率表(四类分行 + 合计):类型 | 总数 | ✅覆盖 | ❌缺口 | N/A | 覆盖率;合计行给 总覆盖率 = 覆盖/(总-N/A)。
  2. 已覆盖(列品类/型号,简列)。
  3. 缺口明细表(按类别分组:锁/窗帘/风扇/扫地机/Hub新款/新灯/其他/遥控学习/平台;列 类别 | 项 | 说明(无脚本/skip占位/需校准/扫码))。
  4. 结尾:优先补建议(设备在手+高频优先:百叶帘/卷帘/原版Plug/风扇;难自动化后置:锁校准/摄像头扫码)。

中文、表格化、可扫读;不要逐条罗列 105 个 ctrl step,按动作/品类归类。

备注(维护者)

  • 根治"号对不上":把脚本运行时锚点号统一成 manifest 必测计划号,之后可纯按号自动统计覆盖率,免去设备级手核。
  • 新调通设备后:① 用例打 [P0][ONES:<号>];② 加进 run-p0-all.sh/run-ios-adds.sh 列表 → 本提示词即可自动算"已覆盖"。
  • 最近一次(2026-06-29)盘点结果:总覆盖率 ≈77%(150/194);控制 90.5%、添加 57%、平台 83%、功能 67%。