1.因为是游戏测试，主要是想看一些动画效果的展示和操作，目前操作可以用 adb 命令 + 视觉检测来完成，但是存在的问题是每一步都需要截图-LLM 检测 - 输出坐标 - 执行，循环时间较长，不是很快捷
2.midscene 当前困扰是图标更新后脚本需要重构，当前维护成本还是较大

需求生成用例我也在做，但是存在几个问题
1.需求多次人工修改才能满足当前 midscene 识别并执行
2.有些用例无法用自动化执行，无法快速筛选出来完全无法用的用例
想问下有没有遇到过类似 2 个问题

个人感觉测试用例拆解重要的不是工作流程，而是当前 LLM 是否了解你的项目
1.知识库内容齐全，那一个大模型就完全可以做拆解内容了
2.拆分多个大模型，个人做法线路分两条，（1）需求拆解提示词（人工审核）- 抽取知识库内容 - 整理测试用例（2）需求拆解用例 + 结合知识库用例 - 查重、整合 - 生成用例

1.触发节点:5 种触发条件：用户明确反馈（正确/错误）、高频重复（3 次/7 天）、周期复盘（每日/每周）、复杂任务验收
2.信息采集:排除问候语和闲聊，只保留含"点击/滑动/验证/文案/入口"等关键词的有效内容
3.自我反思:评估输出是否匹配需求、错误是偶发还是底层逻辑缺失、成功经验能否抽象为通用规则（人工 +AI）
4.规则抽象:生成规则 ID、模式、解决方案、适用场景、执行标准，并通过通用性/可执行性/无冲突/可追溯性四维验证
5.规则更新：写入分层记忆，短期 → 中期 → 长期：验证 ≥5 次升中期，≥10 次升长期，30 天未使用自动清理
5.持续迭代:下次任务应用更新后的规则

目前也是自己摸索在用，根据这些限定收成的 case 放到 midscene 中运行，跑通/跑不通需反馈 skill，再次更新后维护

如果是需求文档转 UI 自动化用例，目前我们是 3 步策略
1.需求文档拆解生成测试用例，规定好测试目标 - 步骤路径（父子结构的知识库文档）- 测试步骤 + 预期结果（预期结果一定要准确）
2.禅道 bug 转用例，需要禅道提交 skill，提交过程中结合需求文档和知识库，自动转换为 UI 自动化所需格式，提交 bug 的时候就规定好模版
3.人工测试过程中遍历测试用例，修改不合规、不完整和错误不明确的预期结果
4.整合所有结果，尝试转换 UI 自动化用例

目前我们也刚开始使用 midscene 做 UI 自动化，识别不准已现在运行的历史结果来看，还是通用限制 + 专项用例的提示词描述不清导致的
1.需要非常明确的路径、测试步骤、预期结果，这块目前是 2 方面优化（1）需求文档让产品提供更细致（2）根据需求拆解测试用例，人工执行完毕后根据需求维护用例后再执行
2.每次 midscene 执行完毕后使用 skill 总结，当前这条用例为什么可以跑通，积累成功经验，随后将跑不通的描述和用例自动总结到错题本，使用 2 个总结方式进行日常积累
3.adb 坐标点击到目标页面这个步骤感觉比较好用，等到目标界面后再进行 AI 识别，成功率会更高一些
当前我们也是在初步尝试，大家有更好的方法，辛苦指点

wiki 搭建个人知识库，全量索引不会有幻觉问题，大模型清洗需求文档，跟产品研发补全需求，搭配 LLM+ 提示词限制拆解需求文档生成测试用例，基本用例能达到九成可复用，其次 wiki+work buddy 或者 tare 可以做到自动迭代知识库和差异化记录，应该会更好一些

明白了，我的结构和差异化处理残缺，我再调整一下，太感谢了