一、测试分析方法
1.质量模型分析法
针对每个功能使用软件质量模型进行分析，分析应测特性，确认各功能的测试点以及测试项；
2.功能交互分析法
针对不同的功能确认各功能之间的交互操作，分析各功能交互时的测试特性，测试注意点，确认测试项；
3.用户场景分析法
针对所有功能，站在用户的角度考虑用户会怎么操作和使用这个功能，分析确认测试点以及测试项；
二、黑盒测试用例设计方法
1.等价类划分
等价类划分是将系统的输入域划分为若干部分，然后从每个部分选取少量代表性数据进行测试。等价类可以划分为有效等价类和无效等价类，设计测试用例的时候要考虑这两种等价类。
2.边界值分析法
边界值分析法是对等价类划分的一种补充，因为大多数错误都在输入输出的边界上。边界值分析就是假定大多数错误出现在输入条件的边界上，如果边界附件取值不会导致程序出错，那么其他取值出错的可能性也就很小。
边界值分析法是通过优先选择不同等价类间的边界值覆盖有效等价类和无效等价类来更有效的进行测试，因此该方法要和等价类划分法结合使用。
3.正交试验法
正交是从大量的试验点中挑选出适量的、有代表性的点。正交试验设计是研究多因素多水平的一种设计方法，他是一种基于正交表的高效率、快速、经济的试验设计方法。
4.状态迁移法
状态迁移法是对一个状态在给定的条件内能够产生需要的状态变化，有没有出现不可达的状态和非法的状态，状态迁移法是设计足够的用例达到对系统状态的覆盖、状态、条件组合、状态迁移路径的覆盖。
5.流程分析法
流程分析法主要针对测试场景类型属于流程测试场景的测试项下的测试子项进行设计，这是从白盒测试中路径覆盖分析法借鉴过来的一种很重要的方法。
6.输入域测试法
输入域测试法是针对输入会有各种各样的输入值的一个测试，他主要考虑 极端测试、中间范围测试，特殊值测试 。
7.输出域分析法
输出域分析法是对输出域进行等价类和边界值分析，确定是要覆盖的输出域样点，反推得到应该输入的输入值，从而构造出测试用例，他的目的是为了达到输出域的等价类和边界值覆盖。
8.判定表分析法
判定表是分析和表达多种输入条件下系统执行不同动作的工具，他可以把复杂的逻辑关系和多种条件组合的情况表达的即具体又明确；
9.因果图法
因果图是用于描述系统输入输出之间的因果关系、约束关系。因果图的绘制过程是对被测系统的外部特征的建模过程，根据输入输出间的因果图可以得到判定表，从而规划出测试用例。
10.错误猜测法
错误猜测法主要是针对系统对于错误操作时对于操作的处理法的猜测法，从而设计测试用例
11.异常分析法
异常分析法是针对系统有可能存在的异常操作，软硬件缺陷引起的故障进行分析，分析发生错误时系统对于错误的处理能力和恢复能力依此设计测试用例。
白盒测试用例设计的一个很重要的评估标准就是对代码的覆盖度。一说到覆盖，大家都感觉非常熟悉，但是常见的覆盖都有哪些？各自有什么优缺点？在白盒测试的用例设计中我们应该如何自如地运用呢？今天小编就为大家总结了一下几种常见的覆盖以及各自的优缺点。
三、白盒测试中常见的覆盖有六种：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合覆盖和路径覆盖。下面我们就分别看看这几种不同的覆盖究竟是什么鬼。
1.语句覆盖（Statement Coverage）
语句覆盖，顾名思义就是针对代码语句的嘛。它的含义是我们设计出来的测试用例要保证程序中的每一个语句至少被执行一次。通常语句覆盖被认为是“最弱的覆盖”，原因是它仅仅考虑对代码中的执行语句进行覆盖而没有考虑各种条件和分支，因此在实际运用中语句覆盖很难发现代码中的问题。举个非常简单的例子：
public int foo(int a,int b)
{
return a/b;
}
这是一个求两数之商的函数。如果我们设计如下的测试用例：
TestCase: a = 2, b = 1
这时候我们会发现，该函数的代码覆盖率达到了100%，并且设计的case可以顺利通过测试。但是显然该函数有一个很明显的bug：当 b=0 时，会抛出异常。
2.判定覆盖（Decision Coverage）
判定覆盖也被成为分支覆盖(Branch Coverage)，也就是说设计的测试用例要保证让被测试程序中的每一个分支都至少执行一次。举个例子,有如下流程图：
针对该图我们想要做到判定覆盖，可以设计如下case：
TestCase1: a=1, b=1 (路径：ab)
TestCase2: a=-1, b=-1 (路径：acd)
TestCase3: a=2, b=-1 (路径：ace)
判定覆盖比语句覆盖强一些，能发现一些语句覆盖无法发现的问题。但是往往一些判定条件都是由多个逻辑条件组合而成的，进行分支判断时相当于对整个组合的最终结果进行判断，这样就会忽略每个条件的取值情况，导致遗漏部分测试路径。
3.条件覆盖（Condition Coverage）
条件覆盖于分支覆盖不同，条件覆盖要求所设计的测试用例能使每个判定中的每一个条件都获得可能的取值，即每个条件至少有一次真值、有一次假值。
仍然以上面流程图作为例子来说明。上图中涉及到的条件一共有4个：
a>0, a<0, b>0, b<0
为了达到条件覆盖的目的，我们设计的用例需要在 a 点有：
a>0, a≤0, b>0, b≤0，
这些情况出现，并且在 c 点有：
a<0, a≥0, b<0, b≥0
这些情况出现。现在可以设计如下用例：
TestCase1: a=1, b=1 (路径：ab)
TestCase1: a=-1, b=-1 (路径：acd)
TestCase1: a=-1, b=0 (路径：ace)
TestCase1: a=1, b=-1 (路径：ace)
通常而言条件覆盖比判定覆盖强，因为条件覆盖使得判定中的每一个条件都取到了不同的结果，这一点判定覆盖则无法保证。但条件覆盖也有缺陷，因为它只能保证每个条件都取到了不同结果，但没有考虑到判定结果，因此有时候条件覆盖并不能保证判定覆盖。
4.判定条件覆盖（Decision/Condition Coverage）
判定条件覆盖，说白了就是我们设计的测试用例可以使得判断中每个条件所有的可能取值至少执行一次（条件覆盖），同时每个判断本身所有的结果也要至少执行一次（判定覆盖）。不难发现判定条件覆盖同时满足判定覆盖和条件覆盖，弥补了两者各自的不足，但是判定条件覆盖并未考虑条件的组合情况。
5.组合覆盖（Branch Condition Combination Coverage）
组合覆盖也叫做条件组合覆盖。意思是说我们设计的测试用例应该使得每个判定中的各个条件的各种可能组合都至少出现一次。显然，满足条件组合覆盖的测试用例一定是满足判定覆盖、条件覆盖和判定条件覆盖的。
针对前文提到的流程图，做条件组合覆盖时我们可以设计如下用例：
TestCase1: a=1, b=1 (路径：ab)
TestCase1: a=-1, b=-1 (路径：acd)
TestCase1: a=-1, b=0 (路径：ace)
TestCase1: a=1, b=-1 (路径：ace)
条件组合覆盖能够同时满足判定、条件和判定条件覆盖，覆盖度较高，但是组合覆盖的测试用例数量相对来说也是比较多的。
6.路径覆盖
路径覆盖，意思是说我们设计的测试用例可以覆盖程序中所有可能的执行路径。这种覆盖方法可以对程序进行彻底的测试用例覆盖，比前面讲的五种方法覆盖度都要高。那么这种方法是不是就一定最好呢？当然不能讲得这么绝对，它的缺点也是显而易见的：由于需要对所有可能的路径全部进行覆盖，那么我们需要设计数量非常巨大的而且较为复杂的测试用例，用例数量将呈现指数级的增长。所以理论上来讲路径覆盖是最彻底的测试用例覆盖，但实际上很多时候路径覆盖的可操作性不强。
