趁着上篇笔记说的，我们进行功能测试的时候需要书写测试用例，为什么呢？因为我们的产品已逻辑复杂而著称，心特大，什么都想做，功能都是抄抄抄，看一眼就头晕，不写用例测试的时候无从下手~
一、什么是测试用例？
百度百科：测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
通俗的讲：就是把我们测试系统的操作步骤用按照一定的格式用文字描述出来。
二、写测试用例有什么好处(博客园虫师的总结)？
- 理清思路，避免遗漏
这里是我们认为最重要的一点，假如我们测试的项目大而复杂，我们可以把项目功能细分，根据每一个功能通过编写用例的方式来整理我们测试系统的思路，避免遗漏掉要测试的功能点。
- 跟踪测试进展
通过编写测试用例，执行测试用例，我们可以很清楚的知道我们的测试进度。
- 历史参考
在我们所做的项目中，也许会有很多功能是相同或相近的，我们对这类功能设计了测试用例，便于以后我们遇到类似功能的时候可以做参考依据。
- 重复性
我们测试一个系统不是一个人测一遍就算测完的，需要多人反复的进行测试，那么我们就需要测试用例来规范和指导我们的测试行为。
三、写测试用例的方法？
- 等价类划分法
等价类划分法就是把程序的输入域划分为若干个集合，然后从每个集合中选取少数具有代表性的数据当作测试用例的方法；每个集合都可以看作一个等价类；
等价类划分：
-
- 有效等价类： 是指对被测程序合理的，有意义的输入数据的集合
- 无效等价类：是指对被测程序无意义对的、不合理的输入数据的集合
比如：程序规定搜索框仅支持汉字
有效等价类集合：a (所有汉zi)
无效等价类集合：b(y有zi母)、c(有数zi)、d(有特殊符号)
就可以生成测试用例
测试数据 期望结果 覆盖的等价类
你好 有效 a
你好nihao 无效 b
你好123 无效 C
你好@ 无效 d
- 边界值测试
边界值测试，就是对程序输入域的边界值进行测试；通常和等价类划分法结合使用，作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界
比如：程序规定搜索框仅支持汉字
就可以生成测试用例：
一个字也不输入
输入很多字
- 错误推断法
基于经验和直觉推测程序中可能存在的各种错误，从而有针对性的设计测试用例。
- 根据被测业务的行业经验进行错误推断
- 以前产品测试中曾经发现的错误
- 以前有过错误记录的代码更容易出现错误
- 需求说明不详细的代码部分更容易出现错误
- 重构、优化过的代码需要投入更多的测试
- 设计多个开发人员的模块需要投入更多的测试
- 因果图法
是一种利用图解法分析输入的各种情况，从而设计测试用例的方法，既然是图解，所以因果图中使用了简单的逻辑符号 ，以直线连接左右结点，左节点表示输入结点，通常用Ci表示，右结点表示输出结点，通常用Ei表示；因果关系有四种，其标识如下图所示：
上图展示的为原因和结果之间的关系，没有考虑输入条件之间的相互制约关系，条件之间的相互制约关系一般分为5种：
(a)E(互斥、排他)。a、b两个原因不会同时出现，最多只有一个出现。
(b)I(包含、或)。a、b、c三个原因至少有一个出现。
(c)O(唯一)。a、b两个原因必须有一个出现，且仅有一个出现。
(d)R(需求)。a出现时b必定出现。
从结果方面考虑主要有1种约束条件：
(a)M(屏蔽)。a出现时，b必定不出现；a不出现时，b则不确定。
利用因果图设计测试用例应遵循的步骤：
1)分析程序的规格说明书中哪些事原因，哪些是结果。所谓原因，是指输入条件或输入条件的等价类，而结果是指输出条件。
给每一个原因和结果赋一个标识符。
2)分析程序规格说明书中的语义，确定原因与原因，原因与结果之间的关系，画出因果图。
3)由于语法环境的限制，一些原因与原因之间，原因与结果之间的组合不能出现。对于这些特殊情况，在因果图中用一些记号标明约束或限制条件。
4)将因果图转化为判定表。
5)根据判定表的没一列设计测试用例。
当然，若能直接得到判定表，可以直接根据判定表设计测试用例。
因果图法设计测试用例举例：
有一个单价为五角钱的饮料自动售货机软件，对其采用因果图方法设计测试用例。需求如下：
1)若售货机没有零钱找，则一个现实“零钱找完”的红灯亮，以提示顾客在此情况下不要投入1元钱，否则此红灯不亮。
2)顾客投入5角硬币，然后按下“橙汁”或“啤酒”按钮，则相应的饮料被送出。
3)顾客投入1元硬币并按下“橙汁”或“啤酒”按钮后，若售货机没有零钱找，则显示“零钱找完”的红灯亮，1元硬币被退出，且无饮料送出；若有零钱找，则五角硬币被退出且饮料被送出。
列出原因
| 编号 | 原因 |
| 1 | 售货机有零钱找 |
| 2 | 投入1元硬币 |
| 3 | 投入五角硬币 |
| 4 | 按“橙汁”按钮 |
| 5 | 按“啤酒”按钮 |
列出结果：
| 编号 | 结果 |
| 21 | 售货机“零钱找完”灯亮 |
| 22 | 退还1元硬币 |
| 23 | 退还五角硬币 |
| 24 | 送出橙汁饮料 |
| 25 | 送出啤酒饮料 |
根据需求说明设置中间节点：
| 序号 | 中间节点 |
| 11 | 投入1元硬币且按饮料按钮 |
| 12 | 按“橙汁”或“啤酒”按钮 |
| 13 | 退还五角零钱且售货机有零钱找 |
| 14 | 钱已付清 |
根据列出的原因、结果、中间节点花出因果图：
2、3号原因不能同时出现，4、5号原因不能同时出现。
将因果图转换为判断表：
在构成的判定表中，个原因、中间节点、结果的取值为0表示其代表的状态不出现；为1表示状态出现。
中间节点与结果没有值为因违反约束不会出现的情况，16、32列没有做任何操作。8、12、24、28列不符合常理（投币却没有选择饮料）为无效列。
根据剩下的列设计测试用例。
| 用例编号 | 有无零钱 | 投入金额 | 饮料 | 预期结果 |
| C01 | 有 | 1元 | 橙汁 | 退回五角、送出橙汁 |
| C02 | 有 | 1元 | 啤酒 | 退回五角、送出啤酒 |
| C03 | 有 | 5角 | 橙汁 | 送出橙汁 |
| C04 | 有 | 5角 | 啤酒 | 送出啤酒 |
| C05 | 无 | 1元 | 橙汁 | 灯亮、退出1元 |
| C06 | 无 | 1元 | 啤酒 | 灯亮，退出1元 |
| C07 | 无 | 5角 | 橙汁 | 灯亮，送出橙汁 |
| C08 | 无 | 5角 | 啤酒 | 灯亮、送出啤酒 |
- 判定表法
因果图案例中已经表诉
方法已经描述完了，我们再说下测试用例的格式，一般每个公司都有自己的用例管理系统，行业内有禅道，QC等，看你们公司的选择了，我们是用testLink维护测试用例的，编写的时候类似与写word，自动生成的格式像Excel；虽然写测试用例的时候让人想吐血，但是写好后确实步骤清晰，方便执行。写好后如下图：
但是这样的测试用例我们只会在项目时间充分的时候才会写，项目时间紧且项目比较繁杂时，我们会直接用脑图描述测试用例，会大大节省时间，好用的脑图如百度脑图，XMind等。总之，写测试用例在测试过程中是非常重要的环节，一份好的测试用例是一个测试人员水平的最好体现。