测试用例

是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。
内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
每个具体测试用例都将包括下列详细信息：编制人、审定人、编制日期、版本、用例类型、设计说明书编号、用例编号、用例名称、输入说明、期望结果（含判断标准）、环境要求、备注等。

测试用例设计

• 将软件测试的行为活动，作为一个科学化的组织归纳。
• 挑选具有代表性或者特殊性的测试数据来进行测试。
• 软件程序在测试用例限定的条件下，必须能够正常运行并且达到程序所设计的执行结果。
  

测试用例的好处

• 在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。
• 测试用例的使用令软件测试的实施重点突出、目的明确。
• 在软件版本更新后只修正少部分的测试用例便可展开测试工作，降低工作强度，缩短项目周期。
• 测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。
  

常见黑盒测试用例设计方法

等价类划分法
等价类是指输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效，并合理地假设：测试某等价类的代表值就等于对这类其他值的测试。
等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。

等价类划分有两种不同的情况：有效等价类和无效等价类。

• 有效等价类：指对于程序的规格说明书来说是合理的、有意义的输入数据构成的集合。利用有效等价类可以检验程序是否实现了规格说明书中所规定的功能和性能。
• 无效等价类：与有效等价类的定义恰巧相反。
  设计测试用例时，要同时考虑这两种等价类。因为，软件不仅要能接收合理的数据， 也能经受意外的考验。这样的测试才能确保软件具有更高的可靠性。
  

确定等价类的原则

• 在输入条件规定了取值范围或者值个数的情况下，可以确定一个有效等价类和两个无效等价类。
• 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确定一个有效等价类和一个无效等价类。
• 在输入条件是一个布尔量的情况下，可以确定一个有效的等价类和一个无效的等价类
• 在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可以确定n个有效的等价类和一个无效的等价类。
• 在规定了输入数据必须遵守的规则的情况下，可以确定一个有效等价类类（符合规则）和若干个无效等价类（从不同角度违反规则）。
• 在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类。
  

确定测试用例步骤
为每个等价类规定一个惟一的编号。
设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类，重复这一步，最后使得所有的有效等价类均被测试用例所覆盖。
设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖。

边界值分析法
边界值分析：是考虑边界条件而选取测试用例的一种黑盒测试方法，是对等价类划分方法的补充。
实践证明，软件在输入、输出域的边界附近容易出现差错， 而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。

使用边界值分析方法设计测试方案首先应该确定边界情况，通常输入等价类和输出等价类的边界，就是应该注重测试的程序边界情况。
选取的测试数据应该正好等于、刚刚小于和刚刚大于边界值。
也就是说，按照边界值分析法，应该选取刚好等于、稍小于和稍大于等价类边界值作为测试数据，而不是选取每个等价类内的典型值或任意值作为测试数据。

基于边界值分析方法选择测试用例的原则

• 如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。
• 如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数作为测试数据。
• 根据规格说明的每个输出条件 ，考虑值的范围情况。
• 根据规格说明的每个输出条件 ，考虑值的个数情况。
• 如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
• 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例
• 分析规格说明，找出其它可能的边界条件。
  

错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误， 从而有针对性的设计测试用例的方法。

错误推测方法的基本思想：

• 列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。
• 设计一些非法、错误、不正确和垃圾数据进行输入测试是很有意义，如果软件要求输入数字、就输入字母，如果软件只接受正数，就输入负数，等等。
  

错误推测方法常见依据:

• 在单元测试时曾列出的许多在模块中常见的错误。
• 以前产品测试中曾经发现的错误等。
• 已发现缺陷的测试方法的推广。
• 容易发生错误的情况。
• 补充等价类和边界值法遗漏的一些等价类组合。
• 一些位置使用了共享变量，设计测试用例，修改一个共享变量，看其他位置有没有同时做修改。
  

因果图法
因果图方法是对等价类的扩展，可以理解为 “ 等价类组合判定表 ” 。是输入等价类与输出等价类的关系图。

等价类划分方法和边界值分析法都是着重考虑输入条件，并没有考虑到输入情况的各组合，也没有考虑各个输入情况之间的相互制约关系。
利用因果关系描述多种条件的组合，相应地产生多个动作的形式来考虑设计用例。

生成测试用例的基本步骤

• 分析软件规格说明描述中， 那些是原因 ( 即输入条件或输入条件的等价类 ) ，那些是结果 ( 即输出条件 ) ， 并给每个原因和结果赋予一个标识符。
• 分析软件规格说明描述中的语义。找出原因与结果之间， 原因与原因之间对应的关系 。根据这些关系，画出因果图。
• 表明约束条件。由于语法或环境限制， 有些原因与原因之间，原因与结果之间的组合情况不不可能出现。 为表明这些特殊情况， 在因果图上用一些记号表明约束或限制条件。
• 把因果图转换成判定表。
• 为判定表中每一列表示的情况设计测试用例。
  

判定表驱动法
判定表是把作为条件的所有输入的各种组合值以及对应输出值都罗列出来而形成的表格。是分析和表达多逻辑条件下执行不同操作的情况的工具。

• 可配合因果图后期使用
• 适合于多逻辑条件下的组合分析
  能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。
  

判定表组成

• 条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。
• 动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
• 条件项（Condition Entry）：列出针对它左列条件的取值。针对条件桩给出的条件列出所有可能的取值
• 动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。
  将任何一个条件组合的特定取值及相应要执行的动作称为一条规则。在决策表中贯穿条件项和动作项的一列就是一条规则。
  

判定表的优点和缺点

• 优点：它能把复杂的问题按各种可能的情况一一列举出来，简明而易于理解，也可避免遗漏。
• 缺点：不能表达重复执行的动作，例如循环结构。
  

判定表的建立步骤

• 确定规则的个数。假如有n个条件，每个条件有两个取值（0,1），故有2n种规则
• 列出所有的条件桩和动作桩
• 填入条件项
• 填入动作项。制定初始判定表
• 简化。合并相似规则或者相同动作
  

正交试验设计法
是从大量的试验数据中挑选适量的、有代表性的点，从而合理的安排测试的一种科学的试验设计方法。
设计出最少的测试组合，达到有效测试目的。

• 节省测试工时。
• 可控制测试用例的数量。
• 测试用例具有一定的覆盖率。
  

生成测试用例的基本步骤

• 提取功能说明，构造因子 状态表。
• 加权筛，生成因素分析表。
• 利用正交表构造测试数据集。
  

功能图法
用功能图形象地表示程序功能说明，并生成功能图的测试用例。又可以称作流程测试或状态迁移测试。类似于白盒测试中的逻辑覆盖和路径法。
需要懂得控制语句（循环，顺序，选择，重复）

生成测试用例的基本步骤

• 在每个状态生成局部测试用例。
• 测试路径生成：从初始状态到最后状态的测试路径。
• 测试用例合成：合成测试路径和功能图中每个状态的局部测试用例。
• 测试用例合成算法：条件构造树。
  

场景法
事件触发控制流程，事件触发时的情景便形成场景。
同一事件不同的触发顺序和处理结果就形成事件流。
用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径的有基本流和备选流。

测试用例选择的综合策略

• 首先进行等价类划分，包括输入条件和输出条件的等价类划分，将无限测试变成有限测试，这是减少工作量和提高测试效率的有效方法。
• 在任何情况下都必须使用边界值分析方法。经验表明，用这种方法设计出的测试用例发现程序错误的能力最强。
• 可以用错误推测法追加一些测试用例，这些需要依靠测试工程师的智慧和经验。
• 对照程序逻辑，检查已设计的测试用例的逻辑覆盖程序，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。
• 如果程序的功能说明中含有输入条件的组合，则一开始就可以选因果图法和判定表驱动法。
• 对参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳的测试效果。
• 功能图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的测试数据。
• 对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。
  

【转载】仅作分享，侵删
链接：http://www.cnblogs.com/anliven/p/6070370.html