前言：
之前有写过一篇用例建模的心得，这篇会在建模的基础上完善一些思路，算是一个V2.0版本吧；在过往的测试理论基础学习中，我们最先接触到的是等价类划分等这类型的理论基础知识，但是对于初学者而言，只会使用这些基础的用例设计方法，并不能帮助我们达到拥有一个完整的测试思路，不遗漏一些真正重要的功能点的要求。因此本文不赘述一些简单的用例设计规范与标准，更多是基于实战总结一些根据实际功能设计用例的方法。（本文有些思维方法很基础，高级人士可以绕道~）
正文：
一、思维导图方法：
1、方法适用：前端页面的黑盒用例编写；
2、方法优势：所见即所得，且可以帮助你去真实的遍历和回忆每个功能细节。并且不容易遗漏主要功能点。
3、案例背景：之前我让一个同事去整理某个交接过来产品的功能点。过了大概半天后他交给我一份用例，大约涵盖了60%的主要功能点；会发现他想到的主要是常用功能点，而不是全部的主要功能点。这里就犯了一个误区了，很多同学去列功能点的时候会认为自己对功能已经比较熟悉了，会凭空去回忆和罗列。而再好的记性都不如严谨的走查。
4、方法说明：
以layui的这个开源后台模板为例。我们常见的列表功能一般都长下面这个样子。一般收到类似这样的一个功能或者原型。
1）功能切割：
我首先会对整体的画面进行切割和细分。如图，通过归类和切割的方法衍生出几个基础的模块。在针对这些基础的模块进行下一步切割。从而得到下面的思维导图。
这个方法可以适用于大到将整个系统划分为不同的功能模块，小到将一个输入框划分为几种作用。而整个用例的设计过程就是不断使用这个方法丰富用例的过程，针对上图我们划分出搜索模块以后，又可以将搜索功能作为一个对象继续往下划分。丰富图中的叶子部分。
在整个功能切割的过程中，有一个重要的依据是需要严谨的针对现有功能/原型去计较每个功能点。一些粗心大意的人在写这个页面用例的时候，就很容易把 路径展示 这个功能遗漏；
不断的循环使用功能切割方法可以帮助我们得到用例的大体框架，而对于用例设计来说，我们需要尽量得到一颗完整的用例数，下面的方法则是帮助我们去丰富用例树的叶子节点。
2）路径探底：
反思这个当前这个功能，是否还有下游功能路径。例如上图如果仅仅写到搜索按钮这显然是不对的；每个功能我们都要仔细思考是否还可以进行切割。
3）交互排列组合：
上文提到的功能切割，更多针对的是单个功能进行分析，但是实际的功能中还存在很多交互配合的可能。因此针对单个功能节点切割完毕以后，还需要搜索全局的每个功能X,和自己测试中的功能是否存在潜在的联系。
例如前文的菜单功能，我们常见的用例设计是切换菜单是否可以到达指定的页面，而忘记了其实‘路径展示功能’也需要切换为对应的路径。
二、用例框架法：
1、方法适用：前端页面的黑盒用例编写；
2、案例背景：很多同学表示，道理我都懂，但是写用例的时候就是会这里漏那里漏；老话说的好：好记性不如烂笔头。仅仅把自己学习的经验存在脑子里是很不可靠的。实际用例设计过程中，我们经常遇到某次设计用例时能想到这个注意点，但是下次设计时又忘记了这个注意点。所以还不如我们每次都使用合适的用例设计初始框架，并不断根据功能去丰富这个框架的内容。
3、方法优势：随着时间积累，可以沉淀为可视化的经验结果；且可以不断的进行完善，甚至可以让整个团队一起来完善；
4、方法说明：
用例框架方法，其实就是针对过往的经验进行用例沉淀，分为用例框架与用例库两个方向。
1）用例框架：
以常见的移动端测试为例，在测试移动端的时候我们经常会考虑以下几个大方向，那么我们就可以根据这几个大方向形成我们的用例框架：
2）用例库
用例框架指明的是用例设计的大体方向，而用例库则是我们具体沉淀的用例集合。我们可以将高度重复的、常用的用例抽象成一个个集合。
例如上文用例框架中提到的：交叉事件用例库、权限测试用例库。
众所周知，前端UI本质上是由一个个控件组成，所以，除了以上提到的异常用例库以外，我们根据前端的特性还可以针对性封装控件用例库。例如：输入框用例库、view用例库、列表用例库等等。这些用例库可以提醒我们常见的异常场景，并且节省一些用例设计时间。
可能会有人发问：我们使用了用例库以后会发现用例好多，执行时间好长，而且未必时有效的。
这个问题就触及黑盒测试的弊端了，因为如果你仅仅停留在黑盒测试表面，很多行为自然是碰运气的。你无法确定他是否有效。那么我们应该如何提高用例库的使用效率呢？
1）正确使用用例库：了解内部程序机制，明白设计用例的理由以及可能的结果。
例如：上文提到的交叉事件用例库，对于不了的程序内部机制的人员来使用这个用例库，可能就会像无头苍蝇一样，在每个页面都终止App“碰碰运气”那么这样测试下来，效率自然极低。
要知道我们设计终止APP的原因是因为:程序可能没有对移动端机制做好兼容而带来BUG。APP突然被终止可能导致一些正在进行的数据写操作被打断，从而导致一些重要数据丢失。因此我们在使用这个用例的时候，更多是和写数据操作进行结合。其他交叉事件用例亦是如此，这也是交叉事件的名字由来。
2）推进开发进行组件式、模块式代码设计；
如果开发能够进行组件式设计，而不是两个表格功能用两套代码，那么我们的用例库就可以针对开发的这个组件进行测试，如果组件测试没问题，代码版本没有变化，那么理论上我们只需要测试这个组件有被正确的使用即可。而不用去测试两遍不同功能中的表格。
3）引入自动化测试，自动化规划与执行相对应的测试用例库。这点涉及到自动化测试领域就不在本文细说，当然还要评估一下成本，以及你所设计的自动化脚本的稳定性。
三、业务流程梳理法：
1、方法适用：后端复杂业务逻辑测试
2、方法优势：帮助梳理清楚业务流程，以及多个业务之间的配合逻辑；帮助思考业务遗漏点、评审开发设计
3、案例背景：与前端侧重于展示与功能表现不同，后端的测试更加侧重于逻辑与数据。针对复杂的业务功能逻辑我们有时要到功能上线了才发现某种业务逻辑场景我们没有考虑到，这缘于我们在测试或者前期评审的时候没有对业务有过清晰的梳理与质疑。但是复杂业务仅仅凭借脑袋去想象是很难保证思考的比较全面的。
4、方法说明：
针对上面的问题，在后端的业务流程梳理测试方法中，区别于前端的思维导图，会建议使用下面两种逻辑图表进行用例设计。
1）流程图：针对业务流程进行梳理。
2）时序图: 针对各个业务方配合情况进行梳理。
我们都知道在软件测试过程中，如果缺陷越晚被发现，修复的代价就会越大；所以针对以上两个方法的应用场景我更建议使用在需求评审阶段或者开发使用阶段。所以我把相关内容汇总在了以上两篇文章中。
这里只介绍如何根据图表进行用例设计的部分：
1）业务流程图-路径遍历用例设计：
如图就是一个非常简单的流程图，路径遍历的意思是需要将流程图中的路径进行遍历。根据遍历出的功能进行用例设计：
1、点击发布代码-》没有权限-》提示
2、点击发布代码-》有权限-》编译发布-》发布不成功-》通知失败消息
3、点击发布代码-》有权限-》编译发布-》发布成功-》通知成功消息
2）时序图-断点异常测试
业务流程测试过程中更加侧重的是业务逻辑的完整性、业务分支的覆盖，那么时序图更加侧重的是各个服务之间的配合、异常情况下的逻辑与稳定。通常我们会在两个服务的配合之间放置一个假设断点。
这些假设包括：
1、服务异常：某个服务请求失败，整体服务表现。
2、重复的请求：结果返回是异步的情况下，又发起一次发布服务，服务的表现。
五、复盘检漏法：
1、方法适用：用例设计完成以后，复盘使用
2、方法优势：抓住项目重点，判断用户逻辑合理，避免重要功能遗漏；避免细节功能遗漏。
1）用户场景预设：
案例背景：
抓住项目重点，判断用户逻辑合理，避免重要功能遗漏；
2）原型重读：
避免细节功能遗漏。
案例背景：有的原型说明，功能细节比较多。会罗列1-10条小功能说明，每条功能复盘的时候都应该有对应的正、反向用例覆盖
3）邀请他人使用，进行内测。
跳脱固定思维。
案例背景：访问平台响应慢，用户体验意识不敏感。
4）设计聚焦，应该缩略得当。
避免精神疲乏。
这里需要补充说明的是，业务流程梳理法主要专注的是后端测试中的逻辑测试，并不是后端的是的全部，也不局限于测试手段，不论是使用接口测试、白盒测试都需要我们对后端逻辑有一个严谨完整的认知。
