用例编写——三级命题法
之前看过很多文章，帖子讲解如何编写用例，有些是分析方法，有些是项目思路，整体来看很少有幸成一个体系的。这里结合我个人经验，总结出一种编写方法——三级命题法。
首先先说下为什么我们要形成体系。第一，可以提高工作效率，有一定之规的工作往往比没头苍蝇一样乱撞要轻松；第二，实际工作中同事，队友经常是来自不同行业之中，跨行业的测试人员进入新的公司会有较长的一段适应期，具体取决于行业差别以及个人的基本功，形成体系后更有助于新人上手；第三就是降低漏检率，坦率地说，软件测试漏检情况还是比较常见的，只是漏检的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.日志校验（前提是开发打日志）；
以上结合起来，就能得到这个迭代的用例集了。这种方法实际推广在项目上，确实降低了漏检率，提高了不少效率，欢迎过客指教。上述只是一种分析思路，分析方法，工作中还需要与项目实际结合起来。
困死了。。。。。。。