用例编写——三级命题法

    之前看过很多文章,帖子讲解如何编写用例,有些是分析方法,有些是项目思路,整体来看很少有幸成一个体系的。这里结合我个人经验,总结出一种编写方法——三级命题法。

    首先先说下为什么我们要形成体系。第一,可以提高工作效率,有一定之规的工作往往比没头苍蝇一样乱撞要轻松;第二,实际工作中同事,队友经常是来自不同行业之中,跨行业的测试人员进入新的公司会有较长的一段适应期,具体取决于行业差别以及个人的基本功,形成体系后更有助于新人上手;第三就是降低漏检率,坦率地说,软件测试漏检情况还是比较常见的,只是漏检的bug是大是小的区别了。这里推荐的方法也只是一个雏形,欢迎过客留言,一起完善。

    三级命题简单的说就是用例命名的一种方法,将用例命名分为三级,即【模块】元素_场景;

    就像编写用例一样,我们也有一个前置条件,就是功能点,逻辑点拆分的彻底,这个取决于测试人员的逻辑思维能力,如果这个搞不定,我建议可以考虑转行了。

    对于一个模块或者一个逻辑功能来说,一般用例结构分为以下四类:

    1.冒烟测试:【模块】冒烟测试;

    2.UI测试:【模块】UI测试;

    3.权限校验:【模块】权限校验;

    4.功能校验:

        a.【模块】元素_场景(条件/状态);

        b.【模块】判定_场景;

    这么说有点朦胧,我们直接举个栗子吧,很多面试中都会出现的一个经典题目:登陆界面!

    界面中包括"用户名","密码","验证码","登陆按钮","注册跳转"元素。业务逻辑,已注册,密码匹配的可以登陆,未注册或者密码不匹配的无法登陆。

    1.冒烟测试:不用说了,主流程,根据业务需求编写:

        【登陆界面】冒烟测试

    2.UI测试:用户界面测试,这里一般是校验看得见,摸得着的东西,一般情况下包括以下几点:

        a.页面布局(与UI原型一致);

        b.文案展示(文案需求一致);

        c.页面元素(页面的输入框,按钮,链接等页面元素齐备);

        d.默认值展示(还用多解释么);

        e.默认顺序(同上);

        f.效果展示(悬停,动态效果等);

        g.跳转,链接(个人习惯放在这里,也可以放在后面功能里进行校验)

            【登陆界面】UI测试

    3.权限校验:什么是权限?游客和注册用户拥有不同权限,普通用户和vip有不同权限,黑名单和白名单有不同权限,业务员与超级管理员有不同权限。这里所谓的权限是依照业务逻辑,对于业务上权限的校验,针对我们的栗子,未注册,已注册就是两种权限;

        【登陆界面】权限校验

    4.功能测试:重头戏来了,到这里,我们的命题才正式拆分成三级。

    a:界面功能

        第一级:模块:具体根据前期需求进行拆分,如【登陆界面】;

        第二级:元素:界面测试时,根据有功能的界面元素,如"用户名";

        第三级:场景/条件/状态:这里是根据功能点,分别对不同的场景,条件以及状态进行校验,比如这个栗子:用户名编码规则,长度,特殊字符等等,比如天朝常用的移动支付,输入密码后,点击支付前是一种状态,支付后是一种状态,那么点击支付后手机处于"loading"的情况呢,实际上这种情况并不全因为网络,支付平台在这个时候会进行疯狂的运算,详情这里不多说,只要知道这也是一种状态;

        如此我们得到了第一条功能测试用例:

        【登陆界面】用户名_纯数字;

        【登陆界面】用户名_16位;(超长)

        ... ...

    b:业务逻辑

        第一级:模块,见a;

        第二级:判定,根据业务逻辑,很多场景中会有比较缜密的业务逻辑,我们看下一个简单的逻辑图吧:


        首先,别吐槽为什么这么简单,因为敝人很懒,其次,对于业务逻辑图,我们第二级命题就是业务逻辑的判定,原来的栗子,如"验证码";

        第三级:场景:无非是"是","否";

        我们便可以得到业务逻辑的用例:

        【登陆】验证码_正确;

        【登陆】验证码_错误;

        ... ...

    至此我们可以得到批量的用例,之后汇总去重,就能得到这次迭代的用例的步骤了;

预制,步骤我们都有了,最后就是我们的预期了。

    一般来说,每条用例或者每个功能点都是从四个方面校验的:

    a.客户端展示,如未注册用户点击"登陆",预期展示为"未注册"诸如此类;

    b.前后端交互,请求,响应是否正确;

    c.数据库校验,是否落地,是否变动;

    d.日志校验(前提是开发打日志);

以上结合起来,就能得到这个迭代的用例集了。这种方法实际推广在项目上,确实降低了漏检率,提高了不少效率,欢迎过客指教。上述只是一种分析思路,分析方法,工作中还需要与项目实际结合起来。

    困死了。。。。。。。

阅读更多

没有更多推荐了,返回首页