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