目录
1.基于需求的设计方法
2.具体的设计方法
2.1等价类
2.2边界值
2.3正交法
2.4判定表法
2.5场景法
2.6 错误猜测法
1.基于需求的设计方法
基于需求的设计方法也是总的设计测试用例的方法，在工作中，我们需要参考需求文档/产品规格说明书来设计测试用例。
测试人员接到需求之后，要对需求进行分析和验证，从合理的需求中进一步分析细化需求，从细化的需求中找出测试点，根据这些测试点再去设计测试用例。
以该注册邮箱账号需求为例，我们来设计测试用例
1.1 注册账号
1.1.1功能概述。 用户可以通过填写邮箱信息在平台注册个人用户。
1.1.2用户角色。 匿名用户。
1.1.3前置条件。 无。
1.1.4输入
序号 栏位名称 栏位说明 长度 类型 备注 1 姓名 必填，录入个人姓名 6~15位 字符型 2 电子邮箱 必填，录入电子邮箱 字符型 3 密码 必填，输入的密码隐藏*号显示 6~15位 字符型 4 确认密码 必填，输入的密码隐藏*号显示 6~15位 字符型 5 验证码 必填，输入验证码 字符型 6 注册 注册操作 操作型 1.1.5处理
1.1.5.1基本事件流：通用流程/大多数用户的操作流程/主流程
- 用户选择注册。
- 系统展现用户协议界面，并请用户确认是否同意用户协议。若用户不同意协议，系统禁止用户注册。若用户同意协议，用户进行信息注册。
- 用户填写注册信息。 注册个人，填写；姓名，电子邮箱，密码，确认密码，验证码。
- 用户提交注册信息。
- 系统提示用户并向用户注册的电子邮件地址发送一封含有激活信息的电子邮件。系统并提示用户，若未收到激活邮件，可以使用注册的邮箱和密码登录系统后再次发送激活邮件。
- 用户可执行激活操作，直接跳转到注册邮箱用户界面。
- 用户通过接收到的电子邮件中的激活信息激活账号，用户注册完成，流程结束。
1.1.5.2扩展事件流 用户注册并激活成功后，第一次登录平台时，提示用户完善信息。
1.1.5.3异常事件流 若用户未收到激活邮件，可在登陆界面录入电子邮件及密码后，再次发送激活邮件。每次发送激活邮件，仅在发送邮件后24小时之内有效，超过24小时后需要重新发送激活邮件。
1.1.6 输出。 用户注册成功。
1.1.7后置条件。 该模块为用户登录等的前置模块。
1.明确需求中的功能点。 账号注册，账号登录。
2.结合万能公式设计测试点。
根据需求文档设计初步的测试用例，而部分的用例还需要细化。
2.具体的设计方法
2.1等价类
依据需求将输入（特殊的情况下才会考虑输出）划分成若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。
穷举法：无法借助该测试方法来进行测试。
等价类主要分为：
有效等价类：对于程序的规格说明说是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能。
无效等价类：根据规格说明书，不满足需求的集合。
根据等价类来设计测试用例的方式：
1.确定有效等价类和无效等价类。
2.编写测试用例，设计具体测试数据。
练习：根据学到的边界值将上述为完成的用例进行完善。
缺点：等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充。
2.2边界值
边界值分析法就是对输入和输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
边界值包含：边界值+次边界值。
边界值即给定返回的左数据和右数据。
选择次边界值的时候需要根据边界值的情况来定：（1）若边界值为有效等价类中的数距，则次边界值为无效等价类中的边界（2）若边界值为无效等价类中的数据，则次边界值为有效等价类中的边界。
继续将上述用例通过边界值来补充完整。
2.3正交法
正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。
正交试验设计是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。正交试验设计是一种正交表的、高效率、快速、经济的试验。
正交表：
如图是最简单的正交表是L（4）（2（3）），含义如下：“L”代表正交表；L下角的数字“4”表示有4横行，简称行，即要做四次试验；括号内的指数“3”表示有3纵列，简称列，即最多允许安排的因素是3个；括号内的数“2”表示表的主要部分只有2中数字，即因素有两种水平1和2。
正交表的构成：因素数，水平数，行数。
因素：对指标的影响条件，通常是正交表中的一列。
水平：因素对应的可选项
正交表的性质：
- 每一列中，不同的数字出现的次数相等。
- 任意两列中数字的排列方式齐全而且均衡。
2.4判定表法
通过具体的方法能够将测试用例设计的更加完整和规范。
需求中会存在各种各样的场景，现在我们把需求改成如下的要求：
用户输入的账号中包含admin字符，或者通过内部连接进入注册页面，提交注册按钮称为管理员身份，反正无管理员身份。
通过这个需求可以看出，不同的组合操作可能对应不同的结果。采用正交法无法解决这样的问题问题。而正交法能够解决需要考虑输入之间的组合关系对应不同场景的结果。
判定法这个需求可以看出，不同的组合操作可能对应不同的结果。采用正交法无法解决这样的问题。而正交法能够解决需要考虑输入之间的组合关系对应不同结果的场景。
判定表是一种表达逻辑判断的工具，形如：
通过该图，可以把所有条件对应的结果清晰的表达出来。我们就需要借助该表来清晰的写出测试用例。
根据判定表法设计测试用例的步骤：
- 确认需求中输入条件和输出条件。
- 找出输入条件和输出条件之间的关系。
- 画判定法。
- 根据判定法编写测试用例。
确认了步骤后，我们使用判定法表进一步对上述需求进行测试用例的设计：
1.确认需求中输入条件和输出条件
输入条件：账号包含admin字符（a）、内部注册链接（b）、点击注册按钮（c）
输出条件：管理员（1）、无管理员（2）
2.找出输入条件和输出条件之间的关系。
1 输入条件：ac ab abc a b c 非abc
2 对应结果：1 2 1 2 2 2 2
画判定表
根据判定表编写测试⽤例
a. 账号包含admin，⾮内部注册链接，点击注册按钮，为管理员⾝份
b. 账号包含admin，内部注册链接，不点击注册按钮，⾮管理员⾝份
c. 账号不包含admin，内部注册链接，点击注册按钮，为管理员⾝份
d. 账号包含admin，内部注册链接，点击注册按钮，为管理员⾝份
e. 账号包含admin，⾮内部注册链接，不点击注册按钮，⾮管理员⾝份
f. 账号不包含admin，⾮内部注册链接，点击注册按钮，⾮管理员⾝份
g. 账号不包含admin，⾮内部注册链接，不点击注册按钮，⾮管理员⾝份2.5场景法
运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指虚拟特定场景发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。
场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。
场景主要包含4种类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。
备选流 基本流 异常流
案例：
根据场景法设计测试用例的步骤：
- 确认基本流。
- 确定备选流。
- 根据备选流补充测试用例。
- 编写测试用例。
编写测试用例：
- 输入正确的账号密码，点击注册后系统发出确认邮件并在24小时之内确认，注册成功。
- 不输入账号密码，点击注册，提示重新输入。
- 只输入账号，不输入密码，点击注册，提示重新输入。
- ……
2.6 错误猜测法
这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人经验和直觉。
这个方法的缺点是难以系统化，并且过度依赖于个人能力。
案例：
以注册为例：
- 校验中特殊字符空格的处理？
- 密码校验中的大小写？
- 姓名中的特殊字符？
- 密码发送是否明文？
