错误推测法
    基于经验和直觉推测程序中所有可能存在的各种错误， 从而有针对性的设计测试用例的方法。
    错误推测方法的基本思想： 列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。 例如， 在单元测试时曾列出的许多在模块中常见的错误。 以前产品测试中曾经发现的错误等， 这些是经验的总结。 还有， 输入数据和输出数据为0的情况。 输入表格为空格或输入表格只有一行。 这些都是容易发生错误的情况。 可选择这些情况下的例子作为测试用例。
    因果图方法
    前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系， 相互组合等。 考虑输入条件之间的相互组合，可能会产生一些新的情况。 但要检查输入条件的组合不是一件容易的事情， 即使把所有输入条件划分成等价类，他们之间的组合情况也相当多。 因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。 这需要利用因果图（逻辑模型）。
    因果图方法终生成的是判定表。 它适合于检查程序输入条件的各种组合情况。
    利用因果图生成测试用例的基本步骤：
    （1） 分析软件规格说明描述中， 那些是原因（即输入条件或输入条件的等价类），那些是结果（即输出条件）， 并给每个原因和结果赋予一个标识符。
    （2） 分析软件规格说明描述中的语义。找出原因与结果之间， 原因与原因之间对应的关系。 根据这些关系，画出因果图。
    （3） 由于语法或环境限制， 有些原因与原因之间，原因与结果之间的组合情况不不可能出现。 为表明这些特殊情况， 在因果图上用一些记号表明约束或限制条件。
    （4） 把因果图转换为判定表。
    （5） 把判定表的每一列拿出来作为依据，设计测试用例。
    从因果图生成的测试用例（局部，组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况，构成的测试用例数目达到少，且测试用例数目随输入数据数目的增加而线性地增加。
    前面因果图方法中已经用到了判定表。判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的情况下的工具。在程序设计发展的初期，判定表已被当作编写程序的辅助工具了。由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。
    判定表通常由四个部分组成。
    条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出得条件的次序无关紧要。
    动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
    条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。
    动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。
    规则：任何一个条件组合的特定取值及其相应要执行的操作。在判定表中贯穿条件项和动作项的一列是一条规则。显然，判定表中列出多少组条件取值，也有多少条规则，既条件项和动作项有多少列。
    判定表的建立步骤：（根据软件规格说明）
    ①确定规则的个数。假如有n个条件。每个条件有两个取值（0，1），故有种规则。
    ②列出所有的条件桩和动作桩。
    ③填入条件项。
    ④填入动作项。等到初始判定表。
    ⑤简化。合并相似规则（相同动作）。
    B. Beizer 指出了适合使用判定表设计测试用例的条件：
    ①规格说明以判定表形式给出，或很容易转换成判定表。
    ②条件的排列顺序不会也不影响执行哪些操作。
    ③规则的排列顺序不会也不影响执行哪些操作。
    ④每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。
    ⑤如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要。
    与黑盒测试用例设计方法并重的还有白盒测试用例设计方法，我们简单介绍：
    白盒测试用例设计技术可分为逻辑覆盖和路径覆盖，逻辑覆盖又可分为以下几种，从弱到强：
    语句覆盖（SC）：设计足够多的测试用例，确保每条语句都被执行过。
    判定覆盖（DC）：设计足够多的测试用例，确保每个判定都分别取真值与假值。
    条件覆盖（CC）：设计足够多的测试用例，确保每个条件都分别取真值与假值。（一个判定里可能包含多个条件）
    判定/条件覆盖（DCC）：设计足够多的测试用例，确保每个判定和条件分别取真值和假值。
    条件组合覆盖（CMC）：设计足够多的测试用例，确保覆盖每个判定中的各个条件的所有组合情况。（只考虑同一个判定内的各条件组合情况）
    路径覆盖：设计足够多的测试用例，确保每条路径都被执行。如果程序复杂，比如包含循环的情况，路径覆盖的测试用例数将会是个天文数字，无法实现。可以采用简化了的路径覆盖，即将循环看成是一个判定，只考虑循环被执行和未执行两种情况。