作为软件测试工程师，最主要的工作就是：编写测试用例，那么为什么要编写测试用例？它有什么好处？如何编写测试用例？测试用例写简单好还是复杂好？如何评价测试用例的质量？
天呐撸！能说不会吗？！
作为倾向软件测试工程师的老铁们，还是一起来学习吧！
一、编写测试用例的好处
- 测试用例是测试者的依据
- 测试用例使得工作可重复，是自动化测试的基础
补充：自动化测试的前提条件是：功能比较稳定，页面元素的变化较小
- 可以使用测试用例来评估需求的覆盖率
- 测试用例的复用
- 编写测试用例的过程中我们可以累积测试的方法思路以供后续借鉴
通过编写测试用例，可以解决如下问题：
不知道是否较全面的测试了所有功能
测试的覆盖率无法衡量
对新版本的重复测试很难实施
存在大量冗余测试影响测试效率
虽然测试用例有那么多好处，但是它也给测试人员带来了一些困扰：测试用例的设计特别的费时费力，一般设计测试用例花费的时间比执行测试用例花费的时间多。尽管如此，我们还是要以积极的态度去编写测试用例，毕竟它带给我们的好处更多一些，这就和金无足赤，人无完人一个道理嘛！
二、测试用例的设计方法
1.测试用例的总体设计方法–基于需求的设计
- RBT( Requirements-Based Testing)是基于需求的测试方法，会使测试更加有效，因为它使测试专注于质量问题产生的根源，即需求。
- 基于需求的测试是一种最根本的软件测试，重点关注以下两大关键问题。
（1）验证需求是否正确、完整、无二义性，并且逻辑一致。
（2）要从“黑盒”的角度，设计出充分并且必要的测试集，以保证设计和代码都能完全符合需求。
2.具体的设计方法
（1）等价类
- 概念：依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过。
- 作用：等价类可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。
- 分类：有效等价类、无效等价类
有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能。
无效等价类：根据需求说明书，不满足需求的集合。
- 我们来举两个例子：
1> 用户需求：吃火锅
有效等价类：吃海底捞、吃粗粮王、吃千禧
无效等价类：吃烤鱼、吃川菜、吃凉皮
2> 软件需求：登录某注册页面，填写用户名（6-15位，字符类型A-Z不区分大小写）
用户名由长度为6-15位的字符串组成，针对字符类型：
有效等价类：A-Z，a-z
无效等价类：数字（1，2.2，-3等）、特殊字符（@，#，$，空格等）
（2）边界值
- 概念：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
- 下面的问题如何编写测试用例：
1> 可变矩形的长度为1-10，边界值取：0、1、10、11
2> 科技竞赛的参加项目为1-3项，边界值取：0、1、3、4
3> 查询页面有999行，每50行为一页，边界值取：0、1、50、51、999、1000
4> 用上述等价类中的例子，当输入的字符类型为A-Z，a-z时，边界值取：5、6、15、16，但是这样的测试用例不全，因为没有测试区间内的值，正确的测试用例还用包含一个在5-16之间的值，例如：5、6、10、15、16
注：可能会有童鞋问这里的测试用例，取值的之后，可不可以用小于5的一个数比如4或3来代替5？
答案是不可以的，因为5可以代表4或3所包含的测试用例，但4或3不可以代表5所包含的测试用例，5是边界值，4或3小于该类却没有等于。
- 这里对边界值做以总结：
（3）因果图
- 概念：因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。因果图法是借助图形来设计测试用例的一种系统方法。
- 适用场景：特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。
- 因果图需要知道的基本知识
1> 恒等：如果原因为真，那么结果必定为真。
2> 与：当两个原因都为真，那么结果为真。
3> 或：当两个原因中有一个为真时，结果就为真。
4> 非：只有原因为假是，结果才为真。
因果图法设计测试用例的步骤如下：
1> 分析所有可能的输入和可能的输出；
2> 找出输入和输出之间的对应关系；
3> 画出因果图；
4> 把因果图转换成判定表；
5> 把判定表对应到每一个测试用例。下面来看一个例子：
假设业务单据的处理规则为：“淘宝618活动，提单已提交，订单合计金额大于300元或有红包，则进优惠”
具体做法按照因果图的设计步骤来做：
1> 首先通过分析所有可能的输入和可能的输出，可以得到如下结果：
输入：订单已提交、金额大于300、有红包
输出：优惠、不优惠
2> 找出输入与输出之间的对应关系。通过分析，可以看出有以下的对应关系:
（1）订单已提交，订单金额大于300元，则优惠；
（2）订单已提交，有红包，则优惠；
（3）订单已提交，订单金额大于300元，有红包，则优惠；
（4）订单金额小于等于300元，不优惠；
（5）订单未提交，不优惠。
3> 画因果图：
4> 将因果图转换成判定表（这里需要计算判定表的列数：因为有三个输入条件，每个条件都有两个取值，因此表的列数=2^3=8）
5> 最终的测试用例为：1、2、3、4、5
为什么没有6、7、8呢？因为5、6、7、8四条都属于“无效的等价类”，即：当订单未提交时，不管其他输入，结果都是不优惠。（因为条件判断是有先后顺序的，在这里明显“订单已提交”的优先级高于其他两个。）
（4）正交排列（当因果设计法的用例过多时，就引入了“正交排序”）
概念：正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。正交试验设计是一种基于正交表的、高效率、快速、经济的试验。
正交表的表达式如下图：
- 正交表的两条性质：
- 举个例子：
以上述的注册为例
1> 因素：姓名、邮箱、密码、确认密码、验证码
2> 水平：填写、不填写
3> 表中的因素数>=5，表中至每个因素数的水平数>=2，行数取最少的一个，即试验次数最少的一个。则：L=N(TC)=6(25)=5*(2-1)+1=6。注意：正交表不是随便写的，它是设计好的，在一定范围内，正交表可大可小，一般都选取最优组合
4> 生成测试用例（注意：测试用例不唯一，只要满足正交表的两条性质即可）
5> 增补测试用例：五个因素都不填写
（5）场景设计法
概念：现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行。
举个例子：（仍然以注册为例）
（6）错误猜测发
概念：错误猜测法是经验丰富的测试人员喜欢使用的一种测试方法。基于经验和直觉，找出程序中你认为可能出现的错误，有针对性地设计测试用例。经验可能来自于在对某项业务的测试较多，也可以来自于售后用户的反馈意见，或者从故障管理库中整理bug。梳理出产品以往哪些地方容易出现问题，问题越多的地方，潜在的bug也就越多。
举个例子（仍以注册为例）：
1、校验中特殊字符空格的处理?
2、密码校验中的大小写？
3、姓名中的特殊字符？
4、密码发送是否明文
三、测试用例的粒度–好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试
- 粒度：指编写测试用例的详细程度。
- 主要参考内容如下：
产品的质量要求
项目对用例的要求
测试时间和资源是否充分
四、测试用例的评价
- 测试用例的评价标准：
（1）测试用例表达清楚、无二义性；
（2）测试用例可操作性强吧 ；
（3）测试用例的输入输出明确；
（4）一条好的测试用例只有一个预期结果；
（5）测试用例的可维护性好，即可读性好；
（6）测试用例的需求覆盖率高；
（7）测试用例让程序暴露bug的能力强。
- 遵循以上标准，在评价测试用例时，可以让同行评价、用户检查评价、项目中审评评价。
本篇博客的内容有点多，但都是很重要的知识点，欢迎大家批评指正！