测试用例是一个小场景，在这个小场景中去测试某个软件，比较预期结果和实际结果之间的差异的过程
测试用例就是为特定的目的设计的一组由测试输入、执行条件、预期结果组成的场景，以便于验证该场景的执行实际结果是否满足需求
用例编号、用例标题（简单描述）、测试项目、用例级别、测试输入、执行步骤、测试前置条件、测试数据、预期结果
7种
测试常用的方法：code review +代码静态分析、CI/CD
CI–持续集成–开发成员经常集成它们的工作，尽快发现集成错误
CD–持续部署–将集成后的代码部署到更贴近真实运行的环境
用例编号 用例标题 功能模块名称 前置条件 输入数据 操作步骤 预期结果
优先级 执行结果 编写人 执行人 其他补充项
难点：读出需求之外的测试点（需求非常的了解）
需求学习方法：、
适用于：存在单个输入的功能
思想： 解决无穷输入
目的： 减少测试用例条目
概念： 输入具有代表性的数据子集
有效等价类： 满足需求的，根据需求说明书，和需求一致，有意义的输入数据构成的集合
无效等价类： 和需求不一致，不满足需求的集合
设计步骤：
（1）明确需求
（2）确定有效和无效等价类
（3）编写测试用例，对于无效等价类尽量设计全面，有效等价类用少量的case覆盖所有有效等价类
示例1：测试一个加法计算器，计算2个1-100之间的整数的和
有效等价类：1+100 2+33
无效等价类：-1+100 -1±100 12±1
示例2：测试QQ账号6-10位自然数
测试用例来自等价类的边界，是等价类的一种补充方法，与它基本成对出现
场景：输入和输出
强调：输入和输出的“边界值”
取值：开区间和闭区间
开区间–向外取值，闭区间–向内取值
设计步骤：
（1）明确需求
（2）确定有效和无效等价类
（3）选取等价类的边界范围，选取正好等于，刚好大于或刚好小于的边界值
（4）编写测试用例
边界值分析法中的三个点
上点：边界上的点 1 100
离点：距离边界值最近的点 0 99
内点：范围内的点 50
示例1：测试一个加法计算器，计算2个1-100之间的整数的和
有效等价类：1+100
无效等价类：2+101 0+99
【1，50】—0，1，50，51
（1，50】–1，2，50，51
适用于有多个输入、多个输出，且输入之间可以组合，不同的组合最终导致输出的结果有差异
| 条件桩 | 条件项 |
|---|---|
| 动作桩 | 动作项 |
| 条件桩：列出系统所有输入 | |
| 动作桩：列出系统可能采取的操作，所有输出 | |
| 条件项：列出针对它左列输入的取值，输入取值 | |
| 动作项：列出在输入项的各种取值情况下应该采取的动作，输出值 | |
| 动作项+条件项：指出了条件项的各种取值情况下应该采取的动作，在判定表中贯穿条件项和动作项的一列就是一条规则，可以针对每个合法输入组合的规则设计用例进行测试 |
（1）明确条件桩
（2）明确动作桩
（3）对条件桩进行全组合
（4）明确每个组合和对应的动作桩
（5）设计测试用例，每列数据对应一条测试用例
利用图解法分析输入的各种组合，与判定表的适用场景一样。是通向判定表的中间步骤
场景：输入（原因）和输出（结果）之间的关系
概念：输入（原因）和输出（结果）之间的关系，输出依赖输入（多个）
因果图需要掌握的基本知识
因：输入条件
果：输出结果
因为用户欠费，所以不允许主被叫
恒等、与、或、非
原因出现则结果出现：因为取了100，则ATM出来100
原因不出现，则结果不出现
只有全部原因都为真，那么结果为真
多个原因有一个为真时，结果为真
原因为假，结果才为真
可以借助工具生成：
（1）正交助手（只适用于控件的水平数都相等的）
（2）allpairs
使用最小的测试过程集合获得最大的测试覆盖率
（1）一种特质的表，一般的正交表标记为：Ln(m^k)
N：行数,实验次数
K:表的列数，控件个数（因素或因子的个数）
m:每个控件包含的取值个数（各因素的水平数）
L9(3^4)：读作4因素3水平有9条测试用例 ,有4个 控件，每个控件有3个取值
n=k*(m-1)+1
原理：正交表，正交实验（抽样）
目的：减少测试用例的条数
两条性质：
任何一列中出现的数字个数一样\
任何两列中有序对出现的次数一样
L=N(TC)–L:正交表
N：行数实验次数
T:水平数（变量的可取值个数）
C:因素数（变量的个数），列
N=C*（T-1）+1
（1）根据需求形成因子状态表（因子-控件名称 状态：每个控件对应的取值）
（2）确定所需的正交表，当控件数在正交表中找不到时，找大于控件数的表
（3）将正交表中的字母用文字代替
（4）一行就是一条测试用例
如果每个控件下的取值不同，选水平个数出现最多的，不是最大的哦
模拟用户操作软件时的场景，主要用于测试多个功能之间组合使用情况
从用户角度：用户评审使用的不是单个功能，而是多个功能之间组合使用
从测试角度：平时测试是单个功能，为保证测试全面性，考虑多个功能之间组合测试的场景
适用于多个功能之间组合的测试场景，冒烟测试经常使用
业务流程：把孤立的功能点串起来
（1）基本流
按照正确的业务流程来实现的一条操作路径
注册–登录–写邮件–发邮件
（2）备选流
导致程序出现错误的操作流程（模拟错误的操作流程）
注册–登录–写邮件–断网–发邮件
（1）确定项目角色 前台用户、后台用户
（2）明确角色的常用功能
（3）根据需求构建测试场景
（4）一个场景就是一条case
适用于多个功能间的组合测试，往往在冒烟测试中使用
步骤：
根据产品经历的需求说明、流程图，写用例覆盖所有的路径分支，一个路径就是一条case
适用于项目紧任务急，时间不够的情况，不能按部就班的设计测试用例，按照之前的项目经验
利用直觉和经验猜测可能出错的类型，非凭空想象，是有来源的，三大来源：
- 分为项目组评审
- 用户评审：可以是最终用户也可以是程序员
- 同行评审
- 白盒：要查看代码
需求分析、等价类划分、边界值分析、因果图、场景法、正交实验设计法、判定表、错误推测法、流程图分析法，依据是用户需求规格说明书、详细涉及说明书
语句覆盖、判断覆盖、条件覆盖、路径覆盖、条件组合覆盖，依据是代码结构和逻辑
六种覆盖标准发现错误的能力由弱到强的变化：
-语句覆盖，每条语句至少执行一次。
-判断覆盖，每个判断的每个分支至少执行一次。
-条件覆盖，每个判断的每个条件应取到的各种可能的值。
-判断/条件覆盖，同时满足判断覆盖条件覆盖。
-条件组合覆盖，每个判定中各条件的每一种组合至少出现一次。
-路径覆盖，使程序中每一条可能的路径至少执行一次。
设计若干测试用例，运行被测程序，使程序中每个可执行语句至少执行一次。只需设计一个测试用例:a=2，b=1，c=6；即达到了语句覆盖。
【优点】 ：可以很直观地从源代码得到测试用例，无须细分每条判定表达式。
【缺点】 ：由于这种测试方法仅仅针对程序逻辑中显式存在的语句，但对于隐藏的条件是无法测试的。如在多分支的逻辑运算中无法全面的考虑。语句覆盖是最弱的逻辑覆盖。
设计若干测试用例，运行被测程序，使得程序中每个分支的取真值和取假值至少一次，即判断真假值均曾被满足。a=2，b=1 ，c=6（M,Q分支全为真）和a=-2，b=-1 ，c=-3（M,Q分支全为假）这两组测试用例可覆盖所有判定的真假分支。
【优点】：判定覆盖具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例。
【缺点】：往往大部分的判定语句是由多个逻辑条件组合而成，若仅仅判断其整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径。判定覆盖仍是弱的逻辑覆盖。
设计若干测试用例，执行被测程序以后要使每个判断中每个条件的可能取值至少满足一次。
判断M表达式:设条件 a>0 取真 记为 T1 ；假F1
条件 b>0 取真 记为 T2 ；假F2
判断Q表达式:设条件 a>1 取真 记为 T3 ；假F3
条件 c>1 取真 记为 T4 ；假F4
我们用条件覆盖设计的思想就是让测试用例能覆盖T1、T2、T3、T4、F1、F2、F3、F4
【优点】：增加了对条件判定情况的测试，增加了测试路径。
【缺点】：条件覆盖不一定包含判定覆盖。例如，我们刚才设计的用例就没有覆盖判断M的Y分支和判断Q的N分支。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。
设计足够的测试用例，使得判断条件中的所有条件可能至少执行一次取值，同时，所有判断的可能结果至少执行一次。
测试用例要满足如下条件：1.所有条件可能至少执行一次取值；2.所有判断的可能结果至少执行一次。
【优点】 ：能同时满足判定、条件两种覆盖标准。
【缺点】 ：判定/条件覆盖准则的缺点是未考虑条件的组合情况。
设计足够的测试用例，使得所有可能的条件取值组合至少执行一次。
【优点】 ：条件组合覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则。
【缺点】 ：线性地增加了测试用例的数量。
设计所有的测试用例，来覆盖程序中的所有可能的执行路径 。
【优点】 ：这种测试方法可以对程序进行彻底的测试，比前面五种的覆盖面都广。
【缺点】 ：需要设计大量、复杂的测试用例，使得工作量呈指数级增长，不见得把所有的条件组合都覆盖。
从前面的例子我们可以看到，采用任何一种覆盖方法都不能满足我们的要求，所以，在实际的测试用例设计过程中，可以根据需要将不同的覆盖方法组合起来使用，以实现最佳的测试用例设计 。