【史上最全】一文学会测试用例，手把手教会
在测试工作中，测试用例设计是整个测试工作中最重要的环节，那么，我们如何编写一份高质量的测试用例呢？掌握测试用例的设计方法以及选择合适的方法非常关键。
如上一篇文章测试基本理论-看这篇就够了所说，常见的用例设计方法有：等价类划分法、边界值分析法、错误猜测法、场景法、测试大纲法、因果图&判定表法、正交排列法、状态转换法。接下来就带你轻松掌握这些方法。
一、用例设计方法如何使用？
1、等价类划分法
选取少数有代表性的数据，这一类数据等价于这一类的其它值；找出最小的子集，可以发现最多的错误。重点在于找出有效等价类和无效等价类。
① 有效等价类：指完全满足程序输入的要求，是由有效且有意义的输入数据所构成的集合。利用有效等价类可以检验程序是否满足需求所规定的要求。
② 无效等价类：和有效等价类相反，即不满足程序输入要求。
【举个栗子】：
<考生证书查询系统>登录界面的考生号输入框限定只能输入（0~50]之的正整数，那么单纯从该输入框考虑，经分析：
【有效等价类】：（0~50]之间任意整数；
【无效等价类】：
① 小于0的负数；
② 大于50的整数；
③ 0；
④ （0~50]之间任意浮点数；
⑤ 中文；英文；
⑥ 特殊字符、表情；
⑦ 空、空格、True、False等；
2、边界值分析法
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法，通常情况下，边界值分析是对等价类划分的补充，需要先找到等价类的边界值，对分界点及其两边的点进行测试，通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。
【举个栗子】：
<考生证书查询系统>登录界面的考生号输入框限定只能输入（0~50]之的正整数，那么，经分析：
选取的边界值数据应该包括：-1，0，1，49，50，51。
实际工作中，边界值是无处不在的，不仅存在于一些数据存储和运算中，还存在字符、位置、尺寸、操作、逻辑条件等中。
3、错误猜测法
错误推测法是指基于对被测试软件系统设计的理解、过往经验以及个人直觉，推测出软件可能存在的缺陷，从而有针对性地设计测试用例的方法。这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，主要靠的是经验、知识、直觉。
【举个栗子】：
<手机日历>中新建日程，使用错误猜测法可以分析出可能存在的错误：
① 设置完成期限早于当前日期；
② 设置完成日期为2月30日；
③ 重复新建日程；
④ 日程名称为空、空格、特殊字符串、很长字符串；
....
综上所述，在错误推荐法中，可依据下列因素来设计用例：
① 客观因素：之前版本存在问题，回归测试中发现的问题；
② 已知因素：语言、操作系统、浏览器等的限制可能带来的问题；
③ 个人经验：可由模块之间的关联所联想到测试点，也可由修复软件的错误推测会带来的问题。
实际的工作中：通常会建立常见缺陷知识库，在测试设计时，会使用缺陷知识库作为checklist，去帮助优化补充测试用例的设计。
4、场景法
通过模拟业务场景来对系统的功能点或者业务流程描述，主要用于测试多个功能之间的组合使用情况。主要的目的是测试软件的主要业务流程、主要功能的正确性和主要的错误处理能力。
① 基本流(正确流)：模拟用户正确操作——验证软件业务流程和主要功能。
② 备选流(错误流)：模拟用户错误操作——验证软件的错误处理能力。
【举个栗子】：
正常流程：插入银行卡->输入正确密码->输入取款金额->完成取款。其中，密码错误3次即会被锁住，当卡内余额不足、ATM机余额不足、超出当日可取额度时将取款失败。【正确流】：正确取款【备选流】:银行卡错误；密码错误；密码错误3次；卡内余额不足；超出当日可取；ATM余额不足；以上可以组合场景用例，一个场景即为一个case。
5、测试大纲法
在一个程序中涉及到多个窗口，每个窗口有多个操作，窗口和窗口之间有一定的联系(或者操作之间的联系)，为了弄清楚它们之间的联系，使用测试大纲法。步骤：
【步骤1】：分析需求，列大纲；
【步骤2】：分析大纲，画关联图，理清窗口间关系；
【步骤3】：编写用例。
备注：对于“列表框”和“下拉列表框”、“组合列表框”(文本框+下拉列表)进行测试，一般至少测试三项，首尾项和中间项。
6、因果图&判定表法
适合有多个控件组合的情况，测试的时候要考虑控件的组合关系，不同的控件组合会产生不同的输出结果的组合，根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况。控件如：输入框、按钮、选择框等。
【步骤】：
① 找出所有的输入条件；
② 找出所有的输出结果；
③ 找出输入条件中的所有组合和互斥条件；
④ 明确每种输入组合对应的输出结果，画因果图，填判定表，每一列就是一条用例（画因果图只是一种辅助工具，可省略）。
【举个栗子】：
<饮料自助售卖机>可投币全部5角或者是投币全部1元，有2个按钮，1个是购买橙汁，1个是购买啤酒的按钮，经分析：
1、【因果图】：
-->找出所有原因(输出)：
① 投币5角；
② 投币1元；
③ 按下橙汁；
④ 按下啤酒；
-->找出所有结果(输出)：
① 送出橙汁；
② 送出啤酒；
③ 找零；
④ 错误提示；
【互斥分析】： 5角和1元之间是互斥的、橙汁和啤酒之间是互斥的；2、【判定表】：
7、正交排列法
在一个界面中有多个控件，每个控件有多个取值，要考虑不同控件不同取值之间的组合，且组合数量较大的话，不可能为每一种编写用例，此时，可以使用正交排列法。（使用最少的抽样数据达到最广的，覆盖率最高的统计结果。）
【与判定表&因果图区别】：
判定表&因果图也是考虑控件组合，但是组合数量较少（一般不会超过20种），而且要求测试全面。
【举个栗子】：
字体的相关情况如下：
【分析】：如果需要将所有场景100%覆盖，测试时考虑输入框的组合情况有81种，这样设计测试用例麻烦，因此采用正交排列法的形式，采用最少的测试用例集合获得最大的测试覆盖率更为合理。
由此，利用正交排列法可以设计最优用例如下（共9种场景）：
8、状态转换法
状态转换法主要关注在测试状态转移的正确性上面。对于一个有限状态机，通过测试验证其在给定的条件内是否能够产生需要的状态变化，有没有不可达的状态和非法的状态，是否可能产生非法的状态转移等。通过构造能导致状态迁移的事件，来测试状态之间的转换。
【举个栗子】：
<视频播放流程>举个简单视频播放例子，例如播放器具备播放、关闭、快进的功能，相关功能流转如下：
则可以得出相关状态树如下：
那么，初步可以得出用例：
① 打开视频-->播放-->快进-->关闭视频；
② 打开视频-->播放-->快进-->播放；
③ 打开视频-->播放-->快进-->快进；
④ 打开视频-->播放-->关闭视频-->打开视频；
⑤ 打开视频-->播放-->关闭视频；
......
以此类推，如果流程还可以往下拆解，则可以再往下拆解流程，得出更全的用例。
二、用例设计方法如何选择？
学习了这么多用例设计方法，在实际测试工作中都是综合使用的，可以结合实际的应用场景去选择合适的方法，例如：
①【文本框输入】：使用等价类划分，必须使用边界值分析法；
②【输入条件的组合情况(组合小于等于20种)】：因果图法&判定表；
③【输入条件的组合情况(组合大于20种)】：正交排列法；
④【业务流程清晰】：场景法；
⑤【操作流程有状态变化】：状态转换法；
⑥【多个窗口，每个窗口中有多个动作】：测试大纲方法；
⑦【补充用例】：错误推测法。
在实际工作中，对大多数的测试而言，使用最多的方法是等价类划分、边界值分析和错误推测这三大类方法。测试也需要深入理解系统的架构，比如数据库、Redis、MQ、第三方系统的集成等，并对用例进行补充。
三、避雷！用例设计常见的问题
1、用例设计不完整，没有100%覆盖所有的软件需求；
2、用例设计内容不完整，没有给出测试步骤、预期结果等内容；
3、用例设计描述不准确，用例名称未清晰描述测试的场景；
4、用例中描述的预期结果不具体，比如把预期结果描述为“见原型”。
四、用例设计的规范
测试用例需具备可被他人理解、可被他人执行。用例除了一些基本的信息（用例编号、功能模块、优先级、测试类型、测试点、用例设计人、执行环境、实际结果等）之外，通常包括四个主要的内容，具体规范如下：
1、用例名称
① 常用的结构“主、谓、宾”；
② 名称简洁易懂，不要包括具体操作步骤。
2、前置条件
① 不可将其他用例作为前置条件，前置条件需要语言描述；
② 完整清晰。包括入口、账号类型、账号权限、数据准备等。
3、测试步骤
① 操作步骤需要描述清晰、简洁；
② 操作和结果是一一对应的，操作中不要包含结果的检查；
③ 用例描述中不允许存在连词、介词，比如：而且，和等等；
④ 用例描述中不允许出现假设性词汇，如：假如，可能等。
4、预期结果
① 每个用例必须要有预期结果，结果不能为空；
② 结果中只能包含结果，不能有步骤；
③ 一个结果有多个检查点时，确保检查点完整；
④ 应当有具体的期望输出的动作或数据，而不能简单一句“功能正常”。