测试用例编写

总体编写思路：

黑盒测试用例（优先）+白盒测试用例（补充）=完整测试用例

总体编写策略：

对于测试用例编写来说，常用的四种方法基本就够用了，等价类、边界值、正交实验法、错误推断法，辅以场景测试法、需求/设计转换法、探索式测试思想，可以应付绝大多数产品的测试。个别的产品还需要在某一点细化和扩充，需要就事论事。

常用的四种方法：

• 等价类
• 边界值
• 正交实验法
• 错误推断法

辅助方法：

• 场景测试法
• 需求/设计转换法
• 探索式测试思想

使用各种编写方法的综合设计策略；（边界值+等价类+错误推测法+场景法+探索式测试（有输入输入的可以辅以因果图法））

1. 在任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强。
2. 必要时用等价类划分方法补充一些测试用例，尤其注意无效等价类情况。
3. 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法（或判定表法、正交试验法）。
4. 用错误推测法再追加一些测试用例，主要是利用测试经验。
5. 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例；参照白盒用例编写。
6. 对程序的应用场景进行研究和思考，增加不同场景下的测试用例；用户场景测试必须重视，很大一部分程序错误就是因为测试场景与用户真实场景的差异性带来的。
7. 对业务和程序有更深的理解之后，可以充分发挥发散思维和探索式想法；大家不要误解探索式测试就是漫无目的的测试，其实探索式测试有非常详细的测试指导思路。

第一部分：黑盒用例编写

常见的方法如下：

• 等价类

• 边界值

• 因果图

• 判定表驱动法

• 正交实验法

• 功能图法

• 场景实验法

• 错误推断法

• 需求转化

• 设计文档

• 探索式测试

等价类

等价类：选取少数有代表性的数据，这一类数据等价于这一类的其它值；找出最小的子集，可以发现最多的错误；

两大特性：必须设计的用例；涵盖了大部分情况；

两类情况：有效等价类；无效等价类；

转化为测试用例

1、按照输入条件、有效等价类、无效等价类建立等价类列表，列出所有的等价类；

2、为每一个等价类固定一个编号；

3、设计一个测试用例，使其覆盖一个或多个有效的等价类；

4、设计一个或更多的测试用例以覆盖剩余的有效等价类；

使用场景：输入条件（取值范围/值个数；必须值集合；布尔值；一组处理值；必须遵守的规则；再细分更小等价类；）

边界值

边界值：所谓边界条件，是指输入和输出等价类中那些恰好处于边界、超过边界、或在边界以下的状态 ；

两个特征：选择一个或多个元素，以便等价类的每一个边界都经过了测试；与仅仅关注输入条件不同，还需要考虑结果空间（输出等价类）设计测试用例；

边界条件可能非常微妙，因此把他们确定下来煞费心思；

使用场景：输入+输出都需要考虑（值的范围；值个数；有序集合；内部数据结构；分析规格说明；）

因果图

因果图：输入条件的组合进行分析。用一个系统的方法选择出高效的测试用例集；

分析思路：

1、分析规格说明描述，确定原因和结果，并赋予标识符；

2、分析规格说明语义，找出原因与原因之间，原因与结果之间关系，画出因果图；

3、有些原因与原因之间，原因与结果之间组合不会出现，用记号表明约束或限制条件；

4、因果图转换为判定表；

5、判定表的每一列作为依据，设计测试用例；

使用场景：必须考虑输入条件的各种组合（一种适合于描述多种条件的组合、相应产生多个动作的形式来进行设计）；

判定表

判定表：分析和表达多逻辑条件下执行不同操作的情况的工具 ；略过因果图的绘制，直接列出所有组合进行筛选；

分析思路：判定表通常有四个部分组成：条件桩、动作桩、条件项、动作项；

判定表的建立步骤：（根据软件规格说明）

确定规则个数；列出所有条件桩和动作桩；填入条件项；填入动作项，得到初始判定表；简化合并相似规则；

使用场景：控制类和游戏。优点是能把复杂的问题按各种可能的情况一一列举出来，简明而易于理解，也可避免遗漏。缺点是不能表达重复执行的动作，例如循环结构。

正交试验法

正交实验法：利用因果图来设计测试用例时, 输入原因与输出结果之间的因果关系,有时很难从软件需求规格说明中得到；往往因果关系非常庞大,以至于测试用例数目巨大，为了有效地、合理地减少测试的工时与费用,可利用正交实验设计方法进行测试用例的设计。

分析思路：

1、提取功能说明,构造因子--状态表 ；

2、加权筛选,生成因素分析表 ；

3、利用正交表构造测试数据集 ；

使用场景：必须考虑输入条件的各种组合（从大量的数据中挑取适量、有代表性的点，合理有效的测试）；

 

场景实验法

场景实验法：软件几乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果形成事件流；生动的描绘出事件触发时的情景，有利于设计用例，同时测试用例也更容易的得到理解和执行。

分析思路：

每条路径都反映了基本流和备选流；基本流是最简单的路径；备选流自基本流开始，会有特定条件下加入并执行，可能有多种情况；

使用场景（0代表基本流）：0；0+1；0+1+2；0+3；0+3+1；0+3+1+2；0+4；0+3+4；…

 

 

错误推断法

错误推断法：基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法；更多的与用户的使用习惯及测试程序中的常见问题为主。

分析思路：

列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据这些情况选择测试用例；

注意积累与分享；

使用场景：任何测试、任何情景下都会用到的方法。

 

需求转换法

需求转换法：根据需求，执行需求分析，并编写测试用例。

分析思路：

将需求转换为思维导图；

仔细推敲每一个字的含义；

与用户的使用场景和目的结合；

严格设计每一个用例；

可以建立一种模型，进行需求转换；

使用场景：任何测试、任何情景下都会用到的方法。

注意：需求的变更带来的影响；需求理解偏差带来的影响；需求含糊不清带来的影响等；

设计文档

设计文档：参照设计文档，可以理解软件系统内部设计流程及处理机制，对比写好的测试用例，可以在对应功能及模块处新增；

分析思路：

仔细阅读设计文档；

与相关人员沟通实现机制；

结合测试用例编写方法，对比之前写好的用例；

使用场景：任何测试、任何情景下都会用到的方法。

注意：设计文档的编写正确性；设计文档的理解偏差；

探索式测试法

探索式测试法：无限创意的测试点，永无止境的探索测试；我们要在测试的最前沿发挥洞察力、技术及应变措施，找出产品的缺陷；

分析思路：

局部探索式测试；全局探索式测试；混合探索式测试；

使用场景：任何测试、任何情景下都会用到的方法。像漫游一样，自由地寻找软件中的缺陷，软件测试的未来必然有探索式测试。

第二部分：白盒用例编写

 

 

基本思路：

第一步需要绘制流程图；

第二步根据路径分析法确定测试用例；

第三步使用等价类/边界值的方法确定测试用例的数据

第四步根据实际情况补充（如默认流程、特殊流程等）

基本策略：

1、语句覆盖准则基本上没啥用，比较强的逻辑覆盖准则是判定覆盖或者条件覆盖；通常判定覆盖可以满足语句覆盖；语句覆盖<判定覆盖<条件覆盖；

2、循环覆盖来说，完全的路径测试并不符合实际；