AI测试 AI 自动化测试的方案
目前使用的是 Midscene.js 为核心搭建起来的 UI 自动化测试项目，依靠视觉驱动测试，主要服务于公司的 Android 客户端的测试。
测试脚本：因为是依托于视觉驱动的测试，所以就需要在测试脚本写明如何从首页到达被测模块所在的位置，然后在脚本中添加返回首页的公共函数，用于测试用例间的隔离
测试执行：Android 这边使用的是云手机，然后写了一个调度模块，可以并行执行用例。并且加了一个固化模块，提取 Midscene 在首次执行的定位信息，然后下次执行到相同的脚本就可以直接拼接 adb 命令，不用 AI 定位，加快脚本的执行。
测试报告：Midscene 的原生报告适合看 AI 是如何执行的，所以写了一个静态网页专门展示用例执行的信息。测试执行完成后推送报告到相关的钉钉群里面
测试脚本这边太依赖人工，执行过程中发现视觉并不是非常准确，以及需要从固定的初始页面状态开始，去到对应的页面测试。
所以就把这个工作转移到开发团队那边：读取被测应用的代码 + 需求文档 + 测试脚本生成规范 直接生成测试脚本，效率提升了非常多。
但是仍有不足：
我们的需求文档大部分都只有一个标题，真的的需求到了后期都是靠测试人员去追问的。现在已经反馈了这个问题，不然没有足够的前置知识，整个 AI 流程很难跑起来
AI 定位元素，有时然后发出的操作指令不准确，人工手动执行用例是可以通过的，但换到 AI 就不行了
现在发到论坛想问问大家关于这个写脚本的方式，有没有更能提升效率和质量的方法？再不行就要换自动化核心了，放弃 AI 驱动，转到时下的 selelinum,appium 之类的了
可以考虑使用 accessibilityservice android 系统服务和 OCR，通过定位文本后拿到信息再点击。这样有 3 级定位 a11y->cor->ai，不侵入现有脚本也能省 token 并保准准确率。
不稳定，不可靠，有更好的更可行的方法，我们公司已经落地了，ai 一天写上百条用例，版本迭代通过率 90 以上，已经没人执行手工测试了
lusujin123
回复
这兄弟在有关 ai 的帖子下都在猛猛一顿输出，结果大家问都不回复，大家懂得都懂，找太多存在感了。
这种东西直接看行业头部公司就行
目前我们也刚开始使用 midscene 做 UI 自动化，识别不准已现在运行的历史结果来看，还是通用限制 + 专项用例的提示词描述不清导致的
1.需要非常明确的路径、测试步骤、预期结果，这块目前是 2 方面优化（1）需求文档让产品提供更细致（2）根据需求拆解测试用例，人工执行完毕后根据需求维护用例后再执行
2.每次 midscene 执行完毕后使用 skill 总结，当前这条用例为什么可以跑通，积累成功经验，随后将跑不通的描述和用例自动总结到错题本，使用 2 个总结方式进行日常积累
3.adb 坐标点击到目标页面这个步骤感觉比较好用，等到目标界面后再进行 AI 识别，成功率会更高一些
当前我们也是在初步尝试，大家有更好的方法，辛苦指点
南修
回复
1.触发节点:5 种触发条件：用户明确反馈（正确/错误）、高频重复（3 次/7 天）、周期复盘（每日/每周）、复杂任务验收
2.信息采集:排除问候语和闲聊，只保留含"点击/滑动/验证/文案/入口"等关键词的有效内容
3.自我反思:评估输出是否匹配需求、错误是偶发还是底层逻辑缺失、成功经验能否抽象为通用规则（人工 +AI）
4.规则抽象:生成规则 ID、模式、解决方案、适用场景、执行标准，并通过通用性/可执行性/无冲突/可追溯性四维验证
5.规则更新：写入分层记忆，短期 → 中期 → 长期：验证 ≥5 次升中期，≥10 次升长期，30 天未使用自动清理
5.持续迭代:下次任务应用更新后的规则
目前也是自己摸索在用，根据这些限定收成的 case 放到 midscene 中运行，跑通/跑不通需反馈 skill，再次更新后维护
我也尝试过使用 midscene 操作安卓 ui 自动化，结果不是很好，可以完成我的描述，但是稍微繁琐的功能上使用这个自动化测试不仅费时间且大概率不满足需求