1. 测试用例的概念
测试用例就是测试人员向被测试系统发起的一组集合，该集合包括测试环境，测试数据，测试步骤，预期结果
2. 设计测试用例的好处
在测试前都要先设计测试用例，设计测试用例有如下好处：
测试用例是测试人员执行测试的依据
在做回归测试的时候，测试用例可以复用
测试用例可以衡量需求的覆盖率
测试用例是自动化测试的依据
测试用例具有借鉴意义，后续测试人员可以借鉴前人写的测试用例
测试用例的编写往往是根需求编写的，那么如何根据需求来编写测试用例？
3. 基于需求设计测试用例
在基于需求设计测试用例之前，测试人员要进行如下操作：
测试人员首先要分析需求，验证需求的合理性，正确性，无二义性，并且逻辑自洽
其次再是细化需求，从需求中提取出测试点，根据测试点设计测试用例
在测试人员分析需求时往往分析功能性需求和非功能性需求
3.1 功能性需求
功能性需求是为了满足软件的基本功能，往往从以下几个方面进行分析考虑
从界面考虑，验证界面功能
比如QQ登陆页面，有许多的按钮对应不同的功能
从业务角度考虑，把功能串起来进行测试
比如增加一条用户信息，然后是查询，修改或者删除
验证功能之间的交互性，一致性
比如微信发朋友圈，你发送的内容要和微信好友在朋友圈看到的一致
一个功能的多个输入
比如登陆功能，要使用不同的账号和密码进行登陆测试
功能的异常测试
功能的易用性，体验性的测试
主要是验证用户在使用上是否符合用户使用习惯，使用起来是否舒适等
功能涉及的算法
比如滴滴打车，一个顾客叫了一个车，系统要根据某些算法算出距该顾客最近的车
3.2 非功能性需求
非功能需求是在功能性需求的基础上做一些限制，满足特定场景的需求，让用户有更好的体验，比如软件的兼容性，性能，安全性，可靠性，可移植性，易用性等
不同的软件对于非功能性的需求往往是不同的，如：
客户端的软件：像word，ppt，xmind，播放器对功能和要求很简单，对性能，安全性要求比较低，对软件的可移植性要求比较高，因为这些不需要联网就可以使用
企业软件：比如聊天软件，像飞Q，飞书，钉钉，对功能有一定要求，对兼容性，安全性，性能要求低，因为企业软件用的用户比较少
商业软件：像QQ，微信等，对功能，性能，安全性，可移植性，易用性要求都很高，因为商业软件使用的用户基数大
4. 设计测试用例的具体方法
设计测试用例的常用方法有：等价类，边界值，错误猜测法，场景设计法，因果图，正交法，下面就对这几种常用设计测试用例的常用方法展开具体的介绍
4.1 等价类
根据输入（特殊情况下考虑输出），把输入划分成若干个等价类，从每一个等价类当中取一个测试用例进行测试，如果这个测试用例通过，我们就说这个测试用例代表的等价类测试通过
等价类可以解决测试用例无法穷举的情况
等价类有有效等价类和无效等价类
有效等价类：符合需求规格说明书的数据
无效等价类：不符合需求规格说明书的数据
注意：测试的时候有效等价类和无效等价类都得测试
示例：注册网易邮箱时，针对账号和密码设计测试用例
4.2 边界值
对输入和输出的边界针对性的进行测试用例的设计，叫作边界值法
示例：上面的网易注册账号和密码的测试用例
账号要求6~ 18个字符，密码要求8~16个字符，所以在设计账号的测试用例时，可以采用边界值设计账号长度的测试用例为5，7，17，19个字符，设计密码长度的测试用例为7，9，15，17个字符
注意：边界值往往和等价类结合在一起使用
4.3 错误猜测法
测试人员根据自己的经验，知识，个人直觉判断软件哪一部分会出现问题，针对性的设计测试用例
错误猜测法适用于补充测试用例，或者进行探索性测试的时候
示例：在数据库查询关于张三的信息，使用“张三”查询到相关信息，使用“ 张 三 ”就查询不到任何信息
有经验的测试人员可能能猜到开发人员在做查询的时候，把空格也当作有效字符，而实际要把空格去掉再去匹配
示例：在数据库查询500条信息，每条信息都不重复，500条分5页展示，每页展示100条，但是在翻看的时候发现每页都有与前面页相同的信息
有经验的测试人员可能猜测是开发人员在做查询的时候没有对数据进行排序，排序后，就不会出现类似问题了
4.4 场景设计法
把一个个孤立的功能串起来形成一个场景，每一个功能不同的输入会触发流程走向不同的场景，根据这些不同功能的不同输入触发形成的不同场景进行测试用例的设计
示例：ATM机取款流程
ATM机取款流程：插卡——输入密码——输入取款金额——退卡
ATM机取款流程的测试用例举例：
卡插反：提示无法识别，重新正确插入，操作正常的情况下可以取款成功
卡消磁：提示无效卡，无法取款
卡锁定：提示用户被锁定，请解锁后重新操作
密码输入为空：提示请输入正确密码，输入正确密码取款成功
4.5 因果图法
因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系，因果图法是借助图形来设计测试用例的一种系统方法，
使用场景：当输入有多个，并且不同的输入组合对应着不同的输出，这个时候我们可以用因果图来进行测试用例的分析，根据分析的结果来设计测试用例
因果图的几种关系
恒等：输入为真，输出为真
与：当输入条件有多个，多个条件都为真的时候，输出为真
或：当输入条件有多个，有一个条件为真，输出为真
非：输入为真，输出为假；输入为假，输出为真
如何使用因果图法来设计测试用例？
分析所有的输入和输出
找出输入和输出之间的逻辑关系
根据输入和输出画出因果图
根据因果图画出判定表
根据判定表去设计测试用例
示例：淘宝618活动，订单已提交，并且购物金额大于300或者有红包，则有优惠，否则无优惠
分析所有的输入和输出
输入：订单已提交，购物金额大于300，有红包
输出：有优惠，没优惠
找出输入和输出之间的逻辑关系
订单已提交，购物金额大于300，有红包，有优惠
订单已提交，购物金额小于300，有红包，有优惠
订单已提交，购物金额大于300，没红包，有优惠
订单已提交，购物金额小于300，没红包，没优惠
订单未提交，没优惠
根据输入输出之间的逻辑关系，画出因果图
根据因果图，画出判定表
根据判定表，写测试用例
订单已提交，金额大于300，有红包，有优惠
订单已提交，金额大于300，没红包，有优惠
订单已提交，金额小于300，有红包，有优惠
订单已提交，金额小于300，没红包，没优惠
订单没提交，金额大于300，有红包，没优惠
订单没提交，金额大于300，没红包，没优惠
订单没提交，金额小于300，有红包，没优惠
订单没提交，金额小于300，没红包，没优惠
4.6 正交法
根据正交法从大量的测试数据中，选取出最优的数据组合，根据最优的数据组合的结果来衡量整个测试的输出结果
正交法的目的是为了减少测试用例的数目
5. 测试用例的粒度
测试用例的粒度指测试用例编写的详细程度
测试用例不能写的过于复杂和过于简单
过于复杂：
测试用例写得过于复杂或详细，会带来两个问题，一个是效率问题，另一个是维护成本问题，还有如果测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维
过于简单：
测试用例写的过于简单，则可能失去了测试用例的意义，设计过于简单的测试用例其实并没有真正的进行设计，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已，测试用例设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试
测试用例的粒度应该介于两者之间，具体设计应该根据项目的实际情况，测试资源的情况来决定应该设计出何等粒度的测试用例
