平时写测试用例用的是脑图，大部分都是 H5 页面，目前主要就是 UI 用例和业务场景无法分开，写的时候就感觉这也得写，那也得写，然后越写越多，越写越细，也越写越乱，最后就发现 UI 用例和业务场景已经无法分开了，给别人看的话就不是一目了然
和楼主一样的感觉，我们测试用例也用脑图，感觉就是把业务逻辑梳理一遍，强依赖 UI 交互，至今没想到好的办法
允许重复就行，很容易分开。
高质量用例还是得看你业务理解和思维方式。
有些逻辑不知道或者不清楚，用例质量就高不了
如果必须要依赖 ui 才叫业务,这叫点点点根本不是业务.
最多只是把很多点点点拼在一起就变成了业务.
真正的业务关注点从来不是界面怎么做
而是在业务层每一步要实现什么
最终会产生什么结果，是否如业务所预期的.
建议写案例的时候思路就要明确，业务和 UI 分开，先把业务逻辑理顺，一部分主要做业务验证，一部分主要做 UI 检查，平时注意积累 UI 验证的一些方法，也可以在做需求分析时，把重要的 UI 检查找出来，做 UI 测试的时候重点测试，其他的就按照常用的 UI 测试方法执行，这样的案例思路清晰，也能做到 UI 和业务有一定的分离，个人愚见，请勿见笑
我自己的方法，希望能帮到你
1.用 xmind 将业务逻辑梳理一遍，如果时间充裕的情况下会画核心业务的数据流图；
2.从系统出发，了解系统已有功能；
3.基于第二点，从不同用户的角度出发，什么角色使用这个系统会干什么样的事情，操作流程是什么（一般需求都会明确）；
4.将 ui 界面功能（基于 UI 原型验证功能点对不对）和业务流程（基于数据流图）的用例解耦（考验思维能力和抓重点能力）
好处就是便于后续的维护，当出现 bug 的时候，从 bug 源于前端后端，就能快速补充 UI 用例和业务流程（接口）用例
给你看下我的一篇测试思路的文章，希望对你有所帮助：https://testerhome.com/topics/20419
UI 用例是什么意思，通过单功能模块，单功能模块组合，业务场景这样来区别
case 设计必须以业务为主，必须围绕业务需求，以及系统设计，来进行 case 设计；
UI 测试这块，不需要设计 case，记录测试点就行。
在执行业务 case 的时候，可以顺带将 UI 测试点来验证
吉吉里
回复
比如我正在测的优惠券，优惠券上的信息 (金额，有效期，适用范围等) 都取自接口的反参，不同的字典值显示不同的信息；我把反参的字典值描述完，我的优惠券用例也写完了；这种算是什么用例呢？UI 用例，业务用例？如果非要划分一类别，感觉都不合适啊
高质量就是渗透深度，能从用户行为分析出发，驾驭得了开发设计，能分析出项目的业务深度、设计缺陷、性能瓶颈；高质量就是艺术结晶，能从产品交互出发，体验得了灵巧，感受得到精致；
当你理解一个功能的业务流 数据流 实现方法和细节你就能做的更好。
