现在主要是自己写完，需要执行者也能看懂，分情况吧，如果只是出策略还是有必要写的很清楚的，当然功能迭代比较频繁的确实很麻烦

确实，用例评审也是过下测试点就 OK 的

借帖问一下，存量的测试用例怎么治理，有 3000 多条，每次回归，都是用打了标签的几百条用例。

补充：场景、整个需求对应的全流程（有些需求本身是垃圾产品搞的，一开始写的需求和原始需求都对不上）

我还以为我在大乱斗

一方面是离职后你的知识能不能沉淀到公司内部的问题，还有就是 AI 可以借鉴历史的测试用例生成符合新需求的测试用例，老的用例是有参考意义的。而且现在都是 AI 生成测试用例，也没多少手工部分了吧。如你所言，把测试点整理详细后，AI 可以生成的又快又全

用例的颗粒度, 取决于执行用例的人是否理解需求和熟悉系统
自己写自己执行 (深入理解需求和系统), 写测试点就好, 除非是重要 + 复杂逻辑 要深入评审则要写细点 (场景细, 但还是废话别太多)
给不清楚这块业务/没看过需求的人执行: 还是细点吧, 不知道他们能理解成啥样

自己就是执行者

能不能借助 ai 搞自动化呢

确实 现在评审都是过测试点

如何从需求生成测试用例呢？贵公司已经落地了吗？我司只有原型图没有 prd，还在探索 axure 转 html 然后让 ai 提取测试点

遇到过有些产品的逻辑都不闭环

还没执行过或者给别人执行过自己的用例

主流程、有关键步骤的详细用例
零碎简单的测试点 group 在一起的检查清单
还有特殊情况的探索测试
我们目前一般 1：3：1 的比例分了这三种用例

如果用例只是给自己看，并且就会用到一次，我觉得都不需要写用例，整理下测试点就好，但是往往用例不是只给自己看，还需要评审、还需要他人执行，还需要留存，后续迭代还有可能他人来执行回归，你写的不够详细，那就啥也不是了。还有可能让你回头补这部分用例，更头大

我是搞了个 figma 读取需求文档并生成测试用例的 skill，axure 应该也有类似的接口。不管是 figma 还是 axure，底层都是数据流，不管是 json 还是结构化的内容，都是可以读取出来的。只要你拿出来，剩下的就是慢慢调脚本，写成符合你们流程的 skill 就好了

完全不存在这种情况 需要回归的用例 早就提取出来了，评审测试点也就行了，也不会有其他人执行，可能公司比较小吧

确实是，自己写自己测，还真没必要写的这么细，浪费时间

感谢指导已经初步实现，结合 gemini 打磨提示词，trae solo 模式生成，看着效果可以就让 trae 生成 skill

需求端到用例端这种端到端的 skill 很早就有了，但是每家公司的需求形式和用例形式差异很大，所以很难有现成的 skill。需要自己去根据公司的模式去慢慢调这个流程，最终形成一套可用的工作流。自用下来，我们内部的测试用例生成效率还是提高了非常多的，但这个质量完全基于你的描述，你对需求来源、拆解和用例的覆盖度等等维度了解的越深刻，这个 skill 的效果会大大提升。毕竟 Ai 通识能力很强，但是定制能力很弱

像原来要实现此功能，要付出很多心血写平台才能完成原型转换到用例，现在直接一个 skill 就搞定了，时代碾压进步，不留一丝情面

如果只是自己看的话无所谓，就拿来自己看的时候拿思维导图列一下测试点就完事，要考虑三方评审，回归，上线验证会由他人来执行的情况的话，就得把用例的具体场景步骤和结果写清楚些了

请问原型图之间如果有箭头，ai 是怎么理解的，还有如何能让需求文档和原型图对照起来

我们公司的原型图，点击图 1 的按钮，箭头指向图 3 的页面

一个测试用例只写测试点跟耍流氓没区别吧。

没有优点，全是缺点，这本质上就跟程序不写注释，不去分层，产品设计只说概念不含细节有啥区别啊。

真就只顾自己爽了。哈哈。

原型图的箭头本质上是节点的一个交互属性，Skill 通过递归遍历 API 返回的节点树，提取每个节点上挂载的交互行为，从而找到所有箭头及其跳转关系

列测试点用来评审
测试点再拆解成用例用来测试

所以说，我就很讨厌这种测试基础能力不扎实的
什么叫【传统测试用例确认太复杂了】，测试用例写得太随意太自我，后期的麻烦是无穷的

写步骤确实很麻烦，现在迭代又快，比如前后端开发给了开发了一个月，你只有三天时间写用例，搞不赢的，写测试点也好，写用例步骤也好，目的就是让大家之道你测了什么，能不能保证功能没问题，不用拘泥于 步骤 1 是什么 步骤 2 是什么，你看一眼这个模块就知道在哪里，比如测试登录 就写 正常登录、不存在的账号登录，锁定的账号登录、错误的密码登录，不输入账号或密码登录等等