3.错误推测
在测试程序时，人们可能根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例，这就是错误推测法。
4.因果图
等价类划分和边界值方法分析方法都只是孤立地考虑各个输入数据的测试功能，而没有考虑多个输入数据的组合引起的错误。
5.综合策略
每种方法都能设计出一组有用例子，用这组例子容易发现某种类型的错误，但可能不易发现另一类型的错误。因此在实际测试中，联合使用各种测试方法，形成综合策略，通常先用黑盒法设计基本的测试用例，再用白盒法补充一些必要的测试用例。
六、测试用例设计的误区
（来源：关河测试网）
·能发现到目前为止没有发现的缺陷的用例是好的用例；
首先要申明，其实这句话是十分有道理的，但我发现很多人都曲解了这句话的原意，一心要设计出发现“难于发现的缺陷”而陷入盲目的片面中去，忘记了测试的目的所在，这是十分可怕的。我倾向于将测试用例当作一个集合来认识，对它的评价也只能对测试用例的集合来进行，测试本身是一种“V&V”的活动，测试 需要保证以下两点：
程序做了它应该做的事情
程序没有做它不该做的事情
因此，作为测试实施依据的测试用例，必须要能完整覆盖测试需求，而不应该针对单个的测试用例去评判好坏。
·测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试；
不知道国内有没有公司真正做到这点，或者说，不知道有国内没有公司能够将每个测试用例都写得如此详细。在我的测试经历中，对测试用例描述的详细和复杂程度 也曾有过很多的彷徨。写得太简单吧，除了自己没人能够执行，写得太详细吧，消耗在测试用例维护（别忘了，测试用例是动态的，一旦测试环境、需求、设计、实 现发生了变化，测试用例都需要相应发生变化）上的时间实在是太惊人，在目前国内大部分软件公司的测试资源都不足的情况下，恐怕很难实现。但我偏偏就能遇到 一些这样的老总或者是项目负责人，甚至是测试工程师本身，全然不顾实际的资源情况，一定要写出“没有接触过系统的人员也能进行测试”的用例。
在讨论这个问题之前，我们可以先考虑一下测试的目的。测试的目的是尽可能发现程序中存在的缺陷，测试活动本身也可以被看作是一个Project，也需要在 给定的资源条件下尽可能达成目标，根据我个人的经验，大部分的国内软件公司在测试方面配备的资源都是不足够的，因此我们必须在测试计划阶段明确测试的目 标，一切围绕测试的目标进行。
除了资源上的约束外，测试用例的详细程度也需要根据需要确定。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻，那测试用例就没有必要太详细了，文档的作用本来就在于沟通，只要能达到沟通的目的就OK。在我担任测试经理的项目中，在测试计划阶段，一般给予测试设计30% - 40%左右的时间，测试设计工程师能够根据项目的需要自行确定用例的详细程度，在测试用例的评审阶段由参与评审的相关人对其把关。
·测试用例设计是一劳永逸的事情；
这句话摆在这里，我想没有一个人会认可，但在实际情况中，却经常能发现这种想法的影子。我曾经参与过一个项目，软件需求和设计已经变更了多次，但测试用例 却没有任何修改。导致的直接结果是新加入的测试工程师在执行测试用例时不知所措，间接的后果是测试用例成了废纸一堆，开发人员在多次被无效的缺陷报告打扰 后，对测试人员不屑一顾。
这个例子可能有些极端，但测试用例与需求和设计不同步的情况在实际开发过程中确是屡见不鲜的，测试用例文档是“活的”文档，这一点应该被测试工程师牢记。
·测试用例不应该包含实际的数据；
测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行 性。当然，测试用例中包含输入数据会带来维护、与测试环境同步之类的问题，关于这一点，《Effective Software Test》一书中提供了详细的测试用例、测试数据的维护方法，可以参考。
·测试用例中不需要明显的验证手段；
我见过很多测试工程师编写的测试用例中，“预期输出”仅描述为程序的可见行为，其实，“预期结果”的含义并不只是程序的可见行为。例如，对一个订货系统， 输入订货数据，点击“确定”按钮后，系统提示“订货成功”，这样是不是一个完整的用例呢？是不是系统输出的“订货成功”就应该作为我们唯一的验证手段呢？ 显然不是。订货是否成功还需要查看相应的数据记录是否更新，因此，在这样的一个用例中，还应该包含对测试结果的显式的验证手段：在数据库中执行查询语句进行查询，看查询结果是否与预期的一致。
七、从用例中生成测试用例
用于功能性测试的测试用例来源于测试目标的用例。应该为每个用例场景编制测试用例。用例场景要通过描述流经用例的路径来确定，这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。
例如，下图中经过用例的每条不同路径都反映了基本流和备选流，都用箭头来表示。基本流用直黑线来表示，是经过用例的最简单的路径。每个备选流自基本流开始，之后，备选流会在某个特定条件下执行。备选流可能会重新加入基本流中（备选流 1 和 3），还可能起源于另一个备选流（备选流 2），或者终止用例而不再重新加入某个流（备选流 2 和 4）。
用例的事件流示例
遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：
场景 1 基本流 场景 2 基本流备选流 1 场景 3 基本流备选流 1 备选流 2 场景 4 基本流备选流 3 场景 5 基本流备选流 3 备选流 1 场景 6 基本流备选流 3 备选流 1 备选流 2 场景 7 基本流备选流 4 场景 8 基本流备选流 3 备选流 4注：为方便起见，场景 5、6 和 8 只描述了备选流 3 指示的循环执行一次的情况。
生成每个场景的测试用例是通过确定某个特定条件来完成的，这个特定条件将导致特定用例场景的执行。
例如，假定上图描述的用例对备选流 3 规定如下：
“如果在上述步骤 2'输入提款金额’中输入的美元量超出当前帐户余额，则出现此事件流。系统将显示一则警告消息，之后重新加入基本流，再次执行上述步骤 2'输入提款金额’，此时银行客户可以输入新的提款金额。”
据此，可以开始确定需要用来执行备选流 3 的测试用例：
测试用例 ID 场景条件预期结果 TC x 场景 4 步骤 2 - 提款金额 > 帐户余额在步骤 2 处重新加入基本流 TC y 场景 4 步骤 2 - 提款金额 < 帐户余额不执行备选流 3，执行基本流 TC z 场景 4 步骤 2 - 提款金额 = 帐户余额不执行备选流 3，执行基本流注：由于没有提供其他信息，以上显示的测试用例都非常简单。测试用例很少如此简单。
下面是一个由用例生成测试用例的更符合实际情况的示例。
示例：
一台 ATM 机器的主角和用例。
下表包含了上图中提款用例的基本流和某些备用流：
本用例的开端是 ATM 处于准备就绪状态。 准备提款 - 客户将银行卡插入 ATM 机的读卡机。
验证银行卡 - ATM 机从银行卡的磁条中读取帐户代码，并检查它是否属于可以接收的银行卡。
输入 PIN - ATM 要求客户输入 PIN 码（4 位）
验证帐户代码和 PIN - 验证帐户代码和 PIN 以确定该帐户是否有效以及所输入的 PIN 对该帐户来说是否正确。对于此事件流，帐户是有效的而且 PIN 对此帐户来说正确无误。
ATM 选项 - ATM 显示在本机上可用的各种选项。在此事件流中，银行客户通常选择“提款”。
输入金额 - 要从 ATM 中提取的金额。对于此事件流，客户需选择预设的金额（10 美元、20 美元、50 美元或 100 美元）。
授权 - ATM 通过将卡 ID、PIN、金额以及帐户信息作为一笔交易发送给银行系统来启动验证过程。对于此事件流，银行系统处于联机状态，而且对授权请求给予答复，批准完成提款过程，并且据此更新帐户余额。
出钞 - 提供现金。
返回银行卡 - 银行卡被返还。
收据 - 打印收据并提供给客户。ATM 还相应地更新内部记录。
用例结束时 ATM 又回到准备就绪状态。
如果 PIN 输入有误，ATM 将显示适当的消息；如果还存在输入机会，则此事件流在步骤 3 - 输入 PIN 处重新加入基本流。
如果最后一次尝试输入的 PIN 码仍然错误，则该卡将被 ATM 机保留，同时 ATM 返回到准备就绪状态，本用例终止。 备选流 5 - 帐户不存在在基本流步骤 4 中 - 验证帐户和 PIN，如果银行系统返回的代码表明找不到该帐户或禁止从该帐户中提款，则 ATM 显示适当的消息并且在步骤 9 - 返回银行卡处重新加入基本流。 备选流 6 - 帐面金额不足在基本流步骤 7 - 授权中，银行系统返回代码表明帐户余额少于在基本流步骤 6 - 输入金额内输入的金额，则 ATM 显示适当的消息并且在步骤 6 - 输入金额处重新加入基本流。 备选流 7 - 达到每日最大的提款金额在基本流步骤 7 - 授权中，银行系统返回的代码表明包括本提款请求在内，客户已经或将超过在 24 小时内允许提取的最多金额，则 ATM 显示适当的消息并在步骤 6 - 输入金额上重新加入基本流。 备选流 x - 记录错误如果在基本流步骤 10 - 收据中，记录无法更新，则 ATM 进入“安全模式”，在此模式下所有功能都将暂停使用。同时向银行系统发送一条适当的警报信息表明 ATM 已经暂停工作。 备选流 y - 退出客户可随时决定终止交易（退出）。交易终止，银行卡随之退出。 备选流 z - “翘起” ATM 包含大量的传感器，用以监控各种功能，如电源检测器、不同的门和出入口处的测压器以及动作检测器等。在任一时刻，如果某个传感器被激活，则警报信号将发送给警方而且 ATM 进入“安全模式”，在此模式下所有功能都暂停使用，直到采取适当的重启/重新初始化的措施。
在第一次迭代中，根据迭代计划，我们需要核实提款用例已经正确地实施。此时尚未实施整个用例，只实施了下面的事件流：
可以从这个用例生成下列场景
场景 1 - 成功的提款基本流 场景 2 - ATM 内没有现金基本流备选流 2 场景 3 - ATM 内现金不足基本流备选流 3 场景 4 - PIN 有误（还有输入机会）基本流备选流 4 场景 5 - PIN 有误（不再有输入机会）基本流备选流 4 场景 6 - 帐户不存在/帐户类型有误基本流备选流 5 场景 7 - 帐户余额不足基本流备选流 6 注：为方便起见，备选流 3 和 6（场景 3 和 7）内的循环以及循环组合未纳入上表。对于这 7 个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例 ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。
通过从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景，至少要确定包含执行场景所需的适当条件的测试用例。例如，在下面的矩阵中，V（有效）用于表明这个条件必须是 VALID（有效的）才可执行基本流，而 I（无效）用于表明这种条件下将激活所需备选流。下表中使用的“n/a”（不适用）表明这个条件不适用于测试用例。
TC（测试用例）ID 号场景/条件 PIN帐号
输入的金额
（或选择的金额）
帐面金额
ATM 内的金额
预期结果 CW1. 场景 1 - 成功的提款 V V V V V 成功的提款。 CW2. 场景 2 - ATM 内没有现金 V V V V I 提款选项不可用，用例结束 CW3. 场景 3 - ATM 内现金不足 V V V V I 警告消息，返回基本流步骤 6 - 输入金额 CW4. 场景 4 - PIN 有误（还有不止一次输入机会） I
V n/a V V 警告消息，返回基本流步骤 4，输入 PIN CW5. 场景 4 - PIN 有误（还有一次输入机会） I
V n/a V V 警告消息，返回基本流步骤 4，输入 PIN CW6. 场景 4 - PIN 有误（不再有输入机会） I
V n/a V V 警告消息，卡予保留，用例结束
在上面的矩阵中，六个测试用例执行了四个场景。对于基本流，上述测试用例 CW1 称为正面测试用例。它一直沿着用例的基本流路径执行，未发生任何偏差。基本流的全面测试必须包括负面测试用例，以确保只有在符合条件的情况下才执行基本流。这些负面测试用例由 CW2 至 6 表示（阴影单元格表明这种条件下需要执行备选流）。虽然 CW2 至 6 对于基本流而言都是负面测试用例，但它们相对于备选流 2 至 4 而言是正面测试用例。而且对于这些备选流中的每一个而言，至少存在一个负面测试用例（CW1 - 基本流）。
每个场景只具有一个正面测试用例和负面测试用例是不充分的，场景 4 正是这样的一个示例。要全面地测试场景 4 - PIN 有误，至少需要三个正面测试用例（以激活场景 4）：
输入了错误的 PIN，但仍存在输入机会，此备选流重新加入基本流中的步骤 3 - 输入 PIN。 输入了错误的 PIN，而且不再有输入机会，则此备选流将保留银行卡并终止用例。 最后一次输入时输入了“正确”的 PIN。备选流在步骤 5 - 输入金额处重新加入基本流。注：在上面的矩阵中，无需为条件（数据）输入任何实际的值。以这种方式创建测试用例矩阵的一个优点在于容易看到测试的是什么条件。由于只需要查看 V 和 I（或此处采用的阴影单元格），这种方式还易于判断是否已经确定了充足的测试用例。从上表中可发现存在几个条件不具备阴影单元格，这表明测试用例还不完全，如场景 6 - 不存在的帐户/帐户类型有误和场景 7 - 帐户余额不足就缺少测试用例。
一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。
测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据
TC（测试用例）ID 号场景/条件 PIN帐号
输入的金额
（或选择的金额）
帐面金额
ATM 内的金额
预期结果 CW1. 场景 1 - 成功的提款 4987 809 - 498 50.00 500.00 2,000 成功的提款。帐户余额被更新为 450.00 CW2. 场景 2 - ATM 内没有现金 4987 809 - 498 100.00 500.00 0.00 提款选项不可用，用例结束 CW3. 场景 3 - ATM 内现金不足 4987 809 - 498 100.00 500.00 70.00 警告消息，返回基本流步骤 6 - 输入金额 CW4. 场景 4 - PIN 有误（还有不止一次输入机会） 4978
809 - 498 n/a 500.00 2,000 警告消息，返回基本流步骤 4，输入 PIN CW5. 场景 4 - PIN 有误（还有一次输入机会） 4978
809 - 498 n/a 500.00 2,000 警告消息，返回基本流步骤 4，输入 PIN CW6. 场景 4 - PIN 有误（不再有输入机会） 4978
809 - 498 n/a 500.00 2,000 警告消息，卡予保留，用例结束
以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。需要的其他测试用例包括：
场景 6 - 帐户不存在/帐户类型有误：未找到帐户或帐户不可用 场景 6 - 帐户不存在/帐户类型有误：禁止从该帐户中提款 场景 7 - 帐户余额不足：请求的金额超出帐面金额在将来的迭代中，当实施其他事件流时，在下列情况下将需要测试用例：
无效卡（所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等） 无法读卡（读卡机堵塞、脱机或出现故障） 帐户已消户、冻结或由于其他方面原因而无法使用 ATM 内的现金不足或不能提供所请求的金额（与 CW3 不同，在 CW3 中只是一种币值不足，而不是所有币值都不足） 无法联系银行系统以获得认可 银行网络离线或交易过程中断电在确定功能性测试用例时，确保满足下列条件：
已经为每个用例场景确定了充足的正面和负面测试用例。 测试用例可以处理用例所实施的所有业务规则，确保对于业务规则，无论是在内部、外部还是在边界条件/值上都存在测试用例。 测试用例可以处理所有事件或动作排序（如在设计模型的序列图中确定的内容），还应能处理用户界面对象状态或条件。 测试用例可以处理为用例所指定的任何特殊需求，如最佳/最差性能，有时这些特殊需求会与用例执行过程中的最小/最大负载或数据容量组合在一起。 八、从补充规约中生成测试用例并不是所有的测试目标需求都将在用例中有所反映。非功能性需求（如性能、安全性和访问控制）以及配置要求等将会说明测试目标的其他行为或特征。补充规约是为其他行为生成测试用例的主要来源。
关于如何生成这些其他测试用例的指南说明如下：
为性能测试生成测试用例 为安全性/访问控制测试生成测试用例 为配置测试生成测试用例 为安装测试生成测试用例 为其他非功能性测试生成测试用例 为性能测试生成测试用例性能测试用例的主要输入是补充规约，补充规约中包含了非功能性需求（请参见工件：补充规约）。为性能测试生成测试用例时，请使用下列指南：
对于补充规约内阐明性能标准的各条说明都应确保至少要确定一个测试用例。性能标准通常表示为时间/事务、事务量/用户或百分数的形式。 对每个关键用例，都应确保至少要确定一个测试用例。关键用例是在上述说明中和/或在工作量分析文档中确定的、必须采用性能评测方法来评估的用例（请参见工件：工作量分析文档）。与功能性测试的测试用例类似，通常对于每个用例/需求都会存在不止一个测试用例。常见的情况是：存在一个低于性能阈值的测试用例、一个处于阈值上的测试用例，还有一个测试用例高于阈值。
除了以上性能标准以外，确保已确定影响响应时间的特定条件，包括：
数据库的大小 - 存在多少个记录？ 工作量 - 同时执行操作的最终用户的数量和类型，以及要同时执行的事务的数量和类型 环境特征（硬件、网件以及软件配置）将用于性能测试的测试用例记录在类似于功能测试所使用的矩阵中。
以下是各种性能测试的一些示例：
对于负载测试：
TC（测试用例）ID 号工作量条件预期结果 PCW1. 1 （单个 ATM） 完成提款交易 全部交易（不依赖于主角的时间）在 20 秒之内完成 PCW2. 2 （1,000 个同时运行的 ATM） 完成提款交易 全部交易（不依赖于主角的时间）在 30 秒之内完成 PCW3. 3 （10.000 个同时运行的 ATM） 完成提款交易 全部交易（不依赖于主角的时间）在 50 秒之内完成
对于强度测试：
TC（测试用例）ID 号工作量条件预期结果 SCW1. 2 （1,000 个同时运行的 ATM） 数据库锁定 - 2 个 ATM 请求同一帐户 ATM 请求排成队列 SCW2. 2 （1,000 个同时运行的 ATM） 无法实现银行系统的通信 交易排成队列或超时 SCW3. 2 （1,000 个同时运行的 ATM） 在交易过程中，银行系统通信被终止 显示警告消息为安全性/访问控制测试生成测试用例
主角和用例一同说明系统外部用户与系统所执行的动作之间的交互，以便为特定主角生成测试结果。复杂系统包含许多主角，所以我们编制测试用例时必须确保只有指定执行用例的主角可以进行此操作，这一点非常关键。在基于主角类型的用例事件流存在差别时，尤其如此。
例如，在 ATM 用例中，如果主角“银行客户”的卡和帐户有的属于拥有这个 ATM 机的银行，有的是竞争银行的银行卡（和帐户），或是企图使用该 ATM 不支持的银行卡，则将对该主角“银行客户”执行不同的用例事件流。
对于功能性测试用例，请同样遵循上面列举的指南。
关于安全性和访问控制测试用例的示例：
TC（测试用例）ID 号条件卡（V 表明卡有效）
读卡机（V 表明读卡机工作正常）
银行的网络预期结果 ACW1. 在银行网络之内 V V V 所有用例都可用 ACW2. 银行网络之外 V V I 只有提款用例可用 ACW3. 无法读卡 I V V 警告消息，卡被退出 ACW4. 因被盗，卡已挂失 I V V 警告消息，卡予保留 ACW5. 卡已过期 I V V 警告消息，卡予保留为配置测试生成测试用例
文章来源于领测软件测试网 https://www.ltesting.net/
