测试思想-测试设计 史上最详细测试用例设计实践总结 Part1
史上最详细测试用例设计实践
by:授客 QQ:1033553122
步骤1:用例划分
1.按系统模块划分
2.按性质分类划分
3.按关联紧密程度划分
1.按系统模块划分
一般设计比较好的系统软件,都会把功能进行分类,并以模块的方式布局在用户界面上,如图:【目标管理】,【课程管理】,【学员管理】,大模块下再分小模块,比如【课程管理】模块又分【课程列表】,【项目资源管理】。
用例划分:针对每个模块、子模块或子模块的模块设计用例
优点:容易展开,简单明了
缺点:
1.业务逻辑容易被忽视。模块与模块之间往往是关联的。
2.容易忽略非UI功能的测试,比如安装测试
举例:数据库审计系统,【规则模块】,【对象模块】
【规则模块】:存放规则,比如操作表名xx的规则
【对象模块】:存放对象,比如表名对象,操作方式对象
关联:规则引用对象
业务流程:客户操作->产生浏览数据->系统捕获数据->检测操作对象与规则引用的对象->如果对象匹配则触发规则并执行规则中指定的动作
单独测两个模块可能都没问题,但是结合起来,在【对象模块】中把【规则模块】中规则正在引用的对象删除,那结果会咋样?难说吧
2.按性质分类划分
用例划分:兼容性测试,压力测试,安装测试,容量测试,可靠性…
好处:对按模块划分的有效补充。
3.按关联紧密程度划分
用例划分:也是按模块划分,区别是把关联比较紧密的模块归到某个模块
好处:有利于任务分配,减少人力资源的重复投入
举例:手机在线教育APP应用,打开应用有 我的课程,我的笔记,我的问题等模块,其中,我的笔记,笔记记录来自课程模块,观看课件学习时进行提交的。
如果按模块来,测试我的笔记的人需要去观看课件并提交笔记,而测试课件观看的人又要测提交笔记,很明显的,“提交笔记”重复投入了劳力。如果把提交笔记归到我的笔记模块,这样按模块分配用例,分配给同一个人去测,这就减少了交叉,减少重复的劳动
步骤2:用例设计
1、设计思想
2、用例编写
1、设计思想
a) 测试点来源与定位
来源
测试点来源:一、显式需求 二、隐式需求。一个需求点可以对应多个测试点
定位测试点
测试点其实也就是测试目的。用例定义了“怎么测”,而测试点则定义了“为何测”,所以,设计前必须明白测试点是什么,且一个用例仅对应一个测试点。
理由:便于统计,测试用例对整个测试过程的质量控制和评估有很重要的意义:
一、测试需求覆盖率分析。如果一个用例包含几个测试点,那么不利于需求覆盖分析
二、用例成功率分析。一个用例中有多个测试点,肯定会造成用例数量减少,用例失败率大大增多,那么你做的用例成功率还有什么意义?
三、缺陷分析。如果用例失败了,就生成一个缺陷。如果一个用例中写了多个测试点,回归的时候如果有指定回归用例,那用例中那些些与缺陷不相关的测试点也可能也被回归,增加工作量。
以下3点想法帮助你更好的定位测试点
1.站在用户使用角度来考虑,看你定位的“测试点”是否有实际意义
2.考虑你定位的“测试点”的完成能否标志着用户实际业务流程的一个阶段性结束?
3.考虑你定位的“测试点”的完成,是否可以为其他用户或业务提供输入数据,以供完成下面的工作?
综合2-3点:划清界线,点到即止
例子:QQ邮箱注册
如上图,单独把任意一个选框拿出来并为其设计一个用例,站在用户角度来看,都无实际意义。用户关注的是我填写完资料并点击注册,能生成一个可用帐号,为登录功能提供输入数据。所以设计用例时,这里的测试目的应该定位为帐号注册,而不是某个选框的特性测试。那输入框的特性,比如上述咋办?这个就是方法问题了, 类似这样的,可以考虑用场景法来设计。
举例:音乐台音乐短片 扑克牌花式技巧演示"五个窍门”视频播放
操作流程:点击 扑克牌花式技巧演示"五个窍门”视频连接,自动打开视频播放界面,边缓冲,以边播放,播放完成,出现上述界面,给出“重播”按钮提示。
不考虑试测试点粒度和分割(1条用例):
1.点击视频连接--打开视频播放界面
2.查看打开的播放器界面--一边进行视频缓冲,一边自动播放缓冲好的视频部分
3.等待播放结束,查看播放器界面--出现重播按钮和推荐短片
4.点击重播按钮--重新播放已缓冲完成的视频
考虑试测试点粒度和分割(2条用例):
用例1:在线视频播放功能
1.点击视频连接--打开视频播放界面
2.查看打开的播放器界面--视频以边缓冲,一边自动播放
3.等待播放结束,查看播放器界面--出现重播按钮和推荐短片
用例2:视频重播功能
1.打开视频进行播放直到播放结束,查看播放器界面--出现重播按钮和推荐短片
2.点击重播按钮--重新播放打开的视频
这里用例操作过程似乎有点冗余,但是从测试目的考虑是允许的:对用例2来说,步骤1可看成是为测试重播而必须经过的一条路线,不是测试重点,而对用例1而言,用例2中的步骤1则是测试重点。进一步,结束播放时的画面还有推荐视频。对这个设计用例,模仿用例2也显得很容易,思路清晰。
举例:在线教育系统,手机端离线视频学习
操作流程:网络连接下,下载课件视频,网络断开下,查看打开视频学习,提交离线笔记,新增待同步学识记录。网络连接,点击同步学识记录按钮进行服务端与手机端的同步。
从以上3点想法来考虑,可定位以下两个测试点:
1.保存离线笔记
2.同步离线笔记
可能有人会觉得,以上2个测试点也可以合并在一起。对的,但是你再结合一个用例对应一个测试点就好理解为何不合并了。
备注:用例是死的,人是活的,例中所举的例子都存在一定的冗余,执行的时候可以考虑执适当的用例执行顺序来减少操作冗余。
举例:教师端学员信息修改
点击修改,弹出修改界面,继续点击单位,出现如图界面
点击修改界面中的【单位】设置框,弹出的是一个单位搜索和选择对话框,如果不独立出来,对搜索框的准确性验证也加到修改功能的用例里,用例会显得庞大,而且测试点不单一,咋办?
单独出来,目的就是对其搜索或展示数据(单位)准确性,找不到单位联系客服等功能验证,比如,是否错乱,是否少了等进行验证,是有意义的,因为这个测试点的输出数据为这个资料修改模块提供了输入数据,使其可往下执行。而修改中则仅关注单位选择作用。
b) 分离测试数据与测试逻辑(步骤)
方法:将用例中的一些输入、输出等作为参数,数据则单独列出,在执行时选择相应的数据执行。
理由:为什么要参数化?
a 、没有将测试数据和测试逻辑分开的测试用例可能显得非常庞大,不利于测试员理解,导致难以控制和执行;
b 、通过将用例参数化,可以简化用例,使测试用例逻辑清晰,数据不逻辑的关系明了,易于理解;
c 、有利于提高测试用例的重用;
选择参数化内容
测试用例中需要通过使用不同数据来重复执行测试的部分;
包括:
a 、输入(数据或操作等)
b 、输出(结果数据或预期结果等)
举例
例一:系统登陆
测试数据
![测试思想-测试设计 <wbr>史上最详细测试用例设计实践总结 <wbr>Part1 测试思想-测试设计 <wbr>史上最详细测试用例设计实践总结 <wbr>Part1](http://simg.sinajs.cn/blog7style/images/common/sg_trans.gif)
当然,这里的案例也存在不妥的地方,也就说包含了多个测试点,另外,要是再加个验证码,那就更不妥了。。。
c) 依据业务逻辑进行设计
(关于业务逻辑的详细说明可参考另一文档)
举例说明什么是业务逻辑:
网上购物
业务流程:用户登录-选择商品-结算-下订单-付款-确认收货,这是一个流程
业务规则:当用户下单付款后必须通知卖家,有顾客光临
业务实体:订单信息,包含购买物品,买家,金额等
业务实体完整性:如:订单信息中,买家不可少,物品id不能为空
根据上述,可以得出优先级:业务流程>业务规则>实体完整性
当然这顺序不是绝对的。
思想:
根据80/20原则,百分之80的用户只使用了产品20%的核心功能,测试要多站在用户角度进行模拟测试,有些测试站在测试的角度看是有意义的,站在用户的角度看却没多大意义,因为有些类似边界值的数据用户极少或根本不会用。(注意我这里的用词),所以要保证基本的核心功能可用。这样写出来的用例优先级也比较好分,一目了然
作者:授客
微信/QQ:1033553122
全国软件测试QQ交流群:7156436
Git地址:https://gitee.com/ishouke
友情提示:限于时间仓促,文中可能存在错误,欢迎指正、评论!
作者五行缺钱,如果觉得文章对您有帮助,请扫描下边的二维码打赏作者,金额随意,您的支持将是我继续创作的源动力,打赏后如有任何疑问,请联系我!!!
微信打赏
支付宝打赏 全国软件测试交流QQ群