经过一个阶段，这个时候我可能有机会去负责一个全新模块的用例设计工作了。整个用例设计的过程大概是：
1、学习研发的需求文档，设计文档，demo等等相关资料
2、根据文档去编写测试用例
3、评审并完善测试用例
那么，我们该如何去设计高质量的用例呢？首先，我们明确下用例设计的目标，应该是叫终极目标吧！
l 用例覆盖率达到100%（即能够通过用例发现所有的bug）
l 没有冗余的用例（能够达到每个用例都有存在的目的）
l 用例的执行效率很高（每个用例都能够通过更快的方式测试完成）
l 能够在测试用例里面（或者用例的框架）直接将测试策略和风险分析一起体现出来
l ......
现在是不是发现用例的设计要达到上面的目标很难，或者简直是不可能完成的任务了？应该说确实如此，但是却是我们不断追求的目标。
下面分别从逻辑、用户场景、需求、UI、关联、可靠性、性能等多个方面来说明如何设计对应的用例。这些也应该是一个模块的用例基本框架
逻辑用例的设计方法：
一个模块就是由一连串的逻辑来组成的，如果我们覆盖到了所有的逻辑并且保证没有问题的话，该模块的质量至少心里已经有个底了，再加上一些其他维度的用例补充，那么整个模块的用例质量应该就比较高了。下面根据笔者的经验来说明编写逻辑用例的一些过程和注意地方吧。
l 用例编写过程：
1、优先完成业务逻辑图，需要在测试的角度上面去画逻辑图，包括数据流完整的输入和输出过程，并且自己能够理解为什么这样处理
2、根据自己的理解分析每个逻辑的处理是否完善，是否有没有覆盖到的地方，并提交缺陷预防bug
3、根据逻辑编写测试用例，保证每个逻辑都能够有对应的用例覆盖
4、编写逻辑用例的过程中思考如何去改进该用例的测试过程，比如：接口测试，自动化测试，脚本。并且，能够及时让研发提供对应的接口和调试方法
5、用例要按照10分钟原则，即保证10分钟内能够执行完成
l 用例评审过程：
1、先讲解整个业务逻辑图，需要保证评审人员对于整个业务逻辑图都非常清楚，并且能够理解为什么这样做
2、分析整个业务逻辑图是否有没有覆盖到的场景或者分支情况（采用头脑风暴的方式）
3、分析业务逻辑的异常处理情况（是否每个业务逻辑都有对异常情况进行处理，也采用头脑风暴的方式）
4、是否将逻辑的用例分类比较合理，让大家通过逻辑很容易就找到对应的用例
5、分析是否所有的逻辑都能够找到对应的用例（通过逻辑找到对应的用例）,包括前面没有考虑到的逻辑
6、分析用例是否有冗余，是否多个用例都是覆盖的同一个逻辑（包括测试步骤和检查点）
7、分析用例的测试方法是否有改进，是否能够直接通过代码静态走读、接口测试、自动化测试（包括编写脚本）、引入工具等等来进一步提高我们的测试效率
l 注意事项：
1、仅仅只能保证已有的逻辑没有问题，但是可能出现部分情况没有处理导致失效的情况，可以通过后面的场景用例和需求用例来补充覆盖。
2、逻辑里面异常情况考虑不充分，导致测试用例也相对比较欠缺，可以通过对每个逻辑进行头脑风暴，分析是否有其他异常情况，并且评审时重点评审这块
3、研发的逻辑有可能本身就是错误的，但是如果顺着研发的逻辑去编写用例时会导致用例也有问题，达不到测试目的，所以需要从需求和设计的角度去提前分析逻辑是否有问题
4、过程中研发的逻辑可能变化比较快，这样会导致逻辑测试用例也要经常变化，所以需要保证研发的编码是与设计一致的，并且逻辑是尽量根据设计来进行的
5、逻辑用例的设计可以在编码中后期进行，这样的改动会少点
场景用例的设计方法：
基于逻辑的用例设计一个很重要的前提就是假设开发的需求和设计没有问题。
但是理想的丰满的，现实的骨干的。往往会出现开发的部分设计是站在自己的角度上面考虑的，而没有去关注客户是如何去使用的，甚至对客户的需求本身就理解的有问题。这样就可能做出来的东西跟客户想要的存在差距，这大概就是我们需要场景用例一个很重要的地方吧。
另外一点就是场景用例能够通过一系列复杂的操作发现一些逻辑也没有考虑到的地方，这个也是基于逻辑的用例里面可能无法考虑完全的（基于逻辑的用例目标是覆盖到已有的逻辑，但是如果开发本身没有考虑到的逻辑也可能会遗漏）。下面分享下笔者编写场景用例的一些经验。
l 用例编写过程：
1、搞清楚客户的原始需求，为什么需要这个功能，能够给客户带来的价值是什么
2、查看需求说明书里面的客户使用的典型用户场景，并且整合到场景用例里面
3、在需求说明书的基础上进一步分析客户还可能有哪些实际的使用场景（主要是整个客户的拓扑结构）
4、客户会怎样去配置该模块以满足什么样的需求（头脑风暴）
5、过程中客户会有哪些操作（头脑风暴）
l 用例评审过程：
1、安排相关模块专家、规划经理和主管来进行评审，主要是分析还可能有哪些场景没有考虑到，最好是能够有具体的客户
2、安排讲解该模块的场景，保证用例责任人对模块场景是非常熟悉的，并且过程中分析是否可能会有其他情况，来进一步完善场景用例
l 注意事项：
1、模块用户场景尽量是有真实的客户，而不是自己yy出来的
2、模块用户场景最好是完整的客户使用过程，而不是某一个测试点
3、并不是所有的模块都有场景用例
需求用例的设计方法：
基于需求的用例设计主要的避免一些不起眼的需求被开发遗漏掉了，而测试在逻辑和用户场景也很难考虑到，这样就可能直接就遗漏了。所以，基于需求的用例设计相当于是对前面两种用例设计方法的补充。基于需求的用例设计方法过程如下：
l 用例编写过程：
1、参照需求表，并且对照前面的逻辑用例和场景用例，检视是否覆盖到所有需求，没有的分析下原因，是否逻辑用例or场景用例考虑的还不充分，是的话补充到上面，不是的话则补充到需求用例里面
2、充分利用相关的用例编写技术，包括：边界值分析法、等价类分析法、
错误类推测法、路径覆盖法、因果分析法、正交分析法等
3、分析用例是否能够通过自动化or其他测试手段来覆盖到
l 用例评审过程：
1、对照需求表来进行检视，是否全部覆盖到，不仅仅是测试用例，还包括测试步骤和期望结果，避免因为依赖研发的逻辑来设计用例导致问题
2、评审该部分用例是否跟前面的逻辑用例和场景用例冗余
3、分析用例是否能够通过自动化or其他测试手段来覆盖到
l 友情提醒：
1、基于需求的用例仅仅是针对前面没有覆盖到的用例的补充，所以这部分用例应该相对比较少，如果发现比较多的话可以分析下是否研发的一些逻辑没有覆盖到相关地方
关联用例的设计方法：
一般情况下，我们只负责一个产品的某一个模块的测试工作。但是，因为对其他的模块不了解，这样就很容易导致模块之间的关联会容易遗漏掉。而这些在前面的几种测试用例里面也是很难考虑到的。那么我们需要一种什么样的方法能够让我们能够分析到与所有模块的关联呢？
我们可以有一份整个产品的模块一览表。然后逐个模块去检视。更好的情况是我们有一份整个产品的模块关联表，当然这个表应该是对整个产品都比较熟悉的人来编写，并且跟开发确认ok的，并且后面每增加一个新的模块就列入到该表里面。表格可以按照下面的方式。
| 模块1 | 模块2 | 模块3 | 模块4 |
模块1 | | 关联点分析 | …… | |
模块2 | 关联点分析 | | | |
模块3 | …… | | | |
模块4 | | | | |
这样，我们做关联分析的时候参考这张表来检视的时候，就能够每个模块都去找对应的测试或者开发的责任人，然后一起分析出可能关联的地方，并且完善这块的关联用例。
可靠用例的设计方法：
可靠性主要是指该模块出现各种异常的时候是否会有恢复和修复的功能。那么，怎样去保证一个模块的可靠性测试用例质量呢？这里同样也可以通过表格的检视方式（不得不说，表格是一种很形象的方法，并且在用例设计里面很有用处）。
我们可以根据产品的特点从多个维度将可能存在的问题列出来，然后再根据该模块进行逐个的检视是否考虑到了，参考下面的表格（脚本自己可以分析下）。
维度 | 具体功能 | 可能存在的问题 | 对应的恢复机制 | 测试方法 |
进程 | Xxx进程 | 内存泄露 | 超过额定值重启 | 模拟内存占用 |
配置文件 | Xxx配置文件 | 配置文件损坏 | 有对应备份配置恢复 | 模拟配置损坏 |
驱动 | XxX驱动 | 驱动异常宕机 | 宕机后自动重启 | 模拟宕机 |
数据库 | XXX数据库 | 数据库损坏 | 损坏后自动修复 | 模拟数据库损坏 |
脚本 | XXX脚本 | | | |
性能用例的设计方法：
性能用例的设计方法也可以参考逻辑用例的设计方法，将业务逻辑图分析出来后根据业务逻辑来分析出可能的性能点，然后设计对应的性能测试用例，具体会在性能的章节里面详细介绍。
自己在用例设计经历了下面的几个阶段:
最开始的时候，一个模块用例设计主要就是根据需求文档来写对应的用例，然后就是评审，通过后就ok了，这里是纯黑盒的用例设计方法，用例质量可想而知。当然，因为单纯的依靠用例无法保证质量，也更加利于大家的发散测试。
后来，随着测试开始介入到开发的需求、设计、编码等相关阶段，开始尝试了根据开发的业务逻辑去写用例，这样做的一个很明显的好处就是对产品的内部实现更加的熟悉，也是测试从纯黑盒转到灰盒的一个标记吧！当然，不好的地方就是开发的业务逻辑改动比较大的话可能用例也需要变化比较大，花费维护的时间比较多，这个阶段也一直摸索了好长一段时间，因为毕竟涉及到跟开发的沟通。
再后来，根据产品在客户那里使用经常出现一些没有考虑到的地方，开始去分析一些典型的用户场景，并且根据模块的特性来转化成用户场景的用例，让内部的测试方法更加符合客户的环境和操作习惯。
到现在整个用例的设计思路基本比较清晰了（当然，后面还会进一步的完善），自己也在整个过程中对用例的理解更加的深刻了，并且对于推动逻辑的用例设计方法也做了一定的贡献：
1、根据开发的设计文档来完成模块的整个业务逻辑图，然后根据业务逻辑图来设计整个逻辑的用例，保证能够将所有的业务逻辑全部都能够覆盖到，然后再将这些业务逻辑的用例通过接口或者自动化的方式（不一定是黑盒的测试方法，更多是构造数据的方法）来覆盖到这些逻辑；
2、在需求阶段开始搜集客户的原始需求，以及一些隐藏的需求使用环境和操作习惯等等，分析并整理成典型的用户场景。
3、再次检视整个需求，分析上面的2种方式设计出来的用例是否覆盖到了所有的需求，并且对没有覆盖的需求进行补充和完善。
4、根据该模块的逻辑进行分析是否存在性能压力点并且提取出来，形成该模块的性能测试用例。
5、分析整个系统可能跟该模块相关联的地方以及对应的关联点，形成该模块的关联测试用例。
6、分析该模块可能出现的一些异常情况，形成该模块的异常测试用例。
