2.3.1.1. 测试用例和测试套件¶

好的，如果目标是以发现错误为目的执行程序（或其一部分），那就让我们运行它！但是我们应该使用什么输入值或用户交互序列呢？

举个例子，假设你正在测试一些非常简单的东西，比如一个名为 isEven() 的单个函数，它接受一个整数值，如果整数是偶数则返回 true，如果是奇数则返回 false。

记住，仅仅运行程序并不算 测试；相反，我们必须试图以某种方式证明失败。这意味着要仔细计划我们将如何运行程序——使用什么输入值或场景，以及我们将寻找什么具体行为或结果。

测试用例 是软件将在其下运行以尝试证明失败的单个场景，通常包含三个基本部分。

1. 首先，测试用例必须定义测试中使用的所有 输入值、条件或变量。例如，我们可以想象一个场景，我们希望在输入值 2 上测试 isEven()。

2. 其次，测试用例必须定义一个 过程 来执行被测软件。在 isEven() 的情况下，过程可以非常简单：用给定的输入值调用该方法，并存储布尔结果。然而，如果我们正在测试一个更大的软件部件或整个应用程序，我们可能需要执行一个更长、更复杂的操作序列来执行它，这个过程是测试用例的一部分。

3. 第三，测试用例必须定义当软件以这种方式执行时应产生的 预期行为。例如，如果我们用值 2 调用 isEven()，我们期望它产生结果 true。

此外，测试用例是在 测试执行之前 制定（并写下来）的。也就是说，我们在运行测试之前就要弄清楚我们将做什么以及期望它产生什么结果。这将测试与简单地"运行代码看看会发生什么"区分开来。

当然，可能需要不止一个测试用例来确定某个所需行为是否被完全满足。例如，一个总是返回 true 而不管输入值如何的 isEven() 实现将通过上述示例测试用例。因此，程序员通常设计一组协同工作的测试用例。为执行同一段软件而设计的测试用例集合称为 测试套件。

例如，可以为 isEven() 设计五个测试用例：一个测试正偶整数，一个测试正奇整数，一个测试负偶整数，一个测试负奇整数，以及一个测试零。另一个人可能想出一个不同的测试套件，但这个组合将有很大机会成功演示该方法中可能出现的大多数简单缺陷/瑕疵。

2.3.1.2. 好的测试用例¶

即使测试像 isEven() 这样的单个方法，也有大量的测试用例可供选择。对于 32 位整数，有 2³² 个可能的输入值我们可以尝试。那么为什么我们要在测试用例中选择这些值中的一个而不是另一个呢？是什么让一个测试用例成为"好的"测试用例？

根据 Glenford Myers 的说法，一个 好的测试用例 应该满足以下条件：

• 有很高的发现错误概率。由于我们的目标是证明缺陷/瑕疵，我们应该选择我们认为最有可能成功的测试用例。

• 不冗余。如果我们已经有一个值为 2 的测试用例，我们就不需要另一个。此外，为什么不使用其他整数，比如 147652 呢？是否有理由认为这个测试用例有很高的发现错误概率？如果我们已经有其他测试用例覆盖偶数，为什么还要测试这个数字呢？如果它只是重新测试已经被充分演示的行为，那么它就是 冗余的——它执行的行为已经被我们测试套件中的其他测试用例测试过了。

• 是"最佳选择"。换句话说，如果有几个冗余的测试用例你可能考虑，都覆盖相同的行为，选择最有可能发现错误的那个测试用例。例如，如果我们想在负偶整数上测试 isEven()，我们应该选择哪个值？任何随机值都可以吗？在这种情况下，选择最大的负整数（-2³¹）可能更好，因为它还将检查该方法在整数范围的极端边界上是否有效。

• 既不太简单也不太复杂。假设你正在测试一个类上的一组方法，而不仅仅是专注于 isEven()。你可能有一个测试用例，它以某种顺序调用类中的每个方法（并且可能多次调用某些方法！）。这样的测试用例可能覆盖很多方面——所有方法都必须在至少一些测试值上正确工作，这个测试用例才能通过。但是，如果测试揭示了一个缺陷/瑕疵，它在哪里呢？它可能在任何方法中，几乎在任何地方。这是一个测试用例过于复杂的例子，因为它涉及太多的行为都在同一系列操作中。最好是使用许多更小的测试用例，每个都专注于检查单个行为，这样测试结果会更有意义。同样，一个只是创建对象而什么都不做的测试用例可能太简单而无法揭示任何缺陷/瑕疵。努力追求范围狭窄但仍然可能揭示它们所执行行为中的缺陷/瑕疵的测试用例。

2.3.1.3. 软件测试方法¶

显然，穷举测试（测试每个可能的执行序列）是不切实际的，即使对于像 isEven() 这样非常简单的代码也是如此。有太多的可能性要尝试，而且需要太长时间。因此，我们需要一种方法来选择一组适当的测试用例（测试套件），该套件有很高的可能性揭示最可能的缺陷/瑕疵。已经开发了许多不同的测试方法来设计测试用例，所有方法的目标都是帮助你选择有效的测试套件。

两类最大的测试方法是 黑盒测试 方法和 白盒测试 方法，尽管还有其他方法。

测试活动还根据被测单元的性质以及你要验证的内容的重点来分类。一些最常见的测试活动是 单元测试 、 集成测试 和 系统测试 。

黑盒测试 或 功能测试 是用于一类测试方法的术语，其中测试用例源自规范、接口定义或行为描述。在使用此策略时，测试人员将被测软件视为"黑盒"，其行为只能通过研究其输入和相关输出来确定。对于学生来说，这就是你在根据作业描述思考编写测试时使用的方法。

相反，另一类测试方法称为 白盒测试 、 结构测试 或 逻辑驱动测试 。白盒测试方法要求测试人员检查被测软件的 内部 结构。在使用此策略时，测试人员在审查程序的内部逻辑和结构后推导测试用例。

单元测试 用于描述在隔离状态下测试单个软件"单元"的活动，独立于任何其他正在编写的代码。这通常是你刚开始时使用的技巧，一次为一个类编写测试。

集成测试：一旦单个程序组件或类（单元）经过测试，它们必须被集成以创建部分或完整的系统。集成过程涉及 测试组合在一起工作的单元，以发现组件交互时出现的问题。被测试的组合可以从小到两个单元交互开始，增长到完整的应用程序。通常，这是由不同开发人员编写的完整系统的各部分一起测试的时候。

系统测试 是在典型工作环境下对整个完全集成的程序进行测试。这涉及将所有开发人员的代码组合成完整的软件产品。

2.3.1.4. 单元测试的更多细节¶

单元测试 用于描述在隔离状态下测试单个软件"单元"的活动，独立于任何其他正在编写的代码。

单元 的确切含义可以从一种编程语言到另一种，从一种编程范式到另一种，从一个组织到另一个组织而有所不同，但旨在表示一个可以独立执行的、清晰分隔的、可识别的软件部分。在 Pascal 中，"单元"通常是过程或函数。在面向对象的语言中，"单元"通常是一个类，尽管有时它也可以是单个方法。除非另有说明，从现在开始我们将把"单元"解释为面向对象语言中的单个类， 被测单元 （ UUT ）表示我们当前正在测试或为其编写测试的类。

单元测试通常由编写被测单元（UUT）的程序员或程序员们在该单元与其他软件部件组合形成更大的应用程序之前执行。目标是尽可能在将该单元与其他软件组合 之前 确认它自身没有错误。这是因为你正在测试的软件部分越小，就越容易定位和消除被揭示的缺陷/瑕疵。

对于学生来说，事实证明你在自己的作业上做的大部分测试都是单元测试：在隔离状态下测试各个类，以确保它们满足各自的设计需求。

2.3.1.5. 软件测试的好处¶

让我们考虑软件测试的一些好处。这将给我们一个视角，为什么我们要在作业中采用软件测试：

• 它增加你对代码的信心

• 它增加你对需求的理解

• 它预防"大爆炸"集成问题

• 它提高你的成绩

2.3.1.6. 测试驱动开发¶

测试驱动开发 （ TDD ）是一种编程技术，涉及不断交替编写一个或多个小的测试用例，然后编写一小段增量代码，以便你可以逐步建立一个可工作的代码库。TDD 背后有三个主要思想：

• 测试优先。 也就是说，每次你即将编写解决方案的某一部分时，首先 写下确认你的解决方案按你期望工作所需的测试用例，然后才 编写代码。因此，TDD 也被称为 测试优先编码。

• 以极小的增量编写。 不要一次编写大块代码，你应该以"婴儿学步"的方式添加新代码：一次一个小方法，或一次一小段方法，为每一小段编写一两个新的测试用例。

  例如，前面讨论的 isEven() 足够小，你可以为它编写测试用例，然后在一步中编写方法体（只需要一行代码），最后运行你的测试用例并根据需要调试。

  然而，如果你正在编写一个行为更复杂的方法，它可能太复杂而无法在一步中编写。考虑一个方法，它接受三个数字表示三角形三条边的长度，该方法应该返回相应的三角形是等边的、等腰的还是不等边的，同时如果这些边长不能构成三角形则报告该信息。

  如果你正在为这个方法编写测试，你将需要检查许多不同类型的情况。它能处理零长度的边吗？它能处理负数吗？它能处理不能构成任何三角形的长度吗？等腰三角形呢？等边三角形呢？不等边三角形呢？你可以将解决方案逻辑中的每个"情况"或分支分离成一个单独的小增量。为你想要的零长度边编写测试用例。然后只实现该部分方法并运行你的测试。接下来，为负数添加测试用例，只为此情况添加额外的代码，并重新运行 所有 测试。一步一步地处理剩余的情况，编写一些测试然后编写实现相应行为的代码。

  使用 案例分析 ——即将问题分解为两个或多个子问题，并定义一个或另一个子问题适用的条件——是一个强大的问题解决工具。它在计算机科学中一直出现，并提供了一种将复杂方法分解为更小步骤的方法，这些步骤可以增量测试。

• "当条是绿色的，代码就是干净的。" 这条 TDD 格言描述了第三个关键思想：每次你添加一小段代码时，你重新运行 所有 为开发中的单元编写的测试，并且在 所有 测试 100% 通过之前不要进入下一步。

  简而言之，先添加少量测试，然后添加相应的（小段）代码，运行所有测试，并立即调试任何问题。除非所有测试都通过，否则你永远没有准备好进入下一个编码步骤（或完成你的解决方案，或准备将你的代码贡献给开源项目等）。你的测试用例是你对代码"正确行为"的表述。因此，这些测试用例是你衡量成功的 标准，随着你增量增长测试套件，你可以看到你离完成所有所需行为有多近。

  大多数自动运行测试用例的测试工具会在测试运行时显示一个进度条，只要测试成功就将其涂成绿色，任何测试失败时涂成红色。

传统测试中成功的测试会发现一个或多个缺陷/瑕疵。但在 TDD 中， 当测试失败时你已经取得了进展 ，因为你现在知道你需要解决这个问题。TDD 增加了你对系统确实满足为它定义的需求并且系统确实可以工作的信心。据说你应该"有目的地测试"，并知道你为什么测试某个东西以及需要测试到什么程度。此外，使用 TDD 时，当你实现了一个经过良好测试的程序时，每一行代码都被测试了。通常，这是传统测试所推荐的，但并不保证的。

2.3.1.7. 了解更多关于 TDD¶

TDD 是关于编写 "可工作的干净代码"。以下是 Kent Beck 的一些直观描述 TDD 的引言：

这里的风格是：先编写几行代码，然后编写一个应该能通过的测试；或者更好的是，先编写一个通不过的测试，然后再编写代码让它通过。 ... [在弄清楚如何写一小段代码之后...] 现在，我们不想继续编码，而是想获得即时反馈，实践"写一点代码，测试一点，写一点代码，测试一点。" [... 所以我们立即为它编写一个测试。]

TDD 源自 极限编程 并从简单的 XP 思想"建一点，测一点"在编码过程中演化而来。基本上，你的代码总是有一组完整的测试来执行其功能，并且你在添加代码时编写新的测试。

TDD 提供的一个显著优势是它使你在编写软件时能够（鼓励你！）采取小步骤。例如，假设你添加一小段新代码，编译并测试它。迟早当你这样做时，由于代码中的一个或多个缺陷/瑕疵，你的一个或多个测试将失败。然而，通过以小步骤进行，找到并修复这些缺陷/瑕疵要容易得多。问题最可能在你刚才编写的极小段代码中，因为你之前编写的其他代码通过了所有其他测试。如果某些之前正常工作的行为再次中断，它很可能是新添加代码造成的干扰的结果。而且如果你只编写了五行新代码而不是五百行或五千行，缺陷/瑕疵会容易得多地被找到。

2.3.5.1. 使用参数传递信息¶

我们使用过的一些方法需要参数（arguments），即你在调用方法时提供的值。例如，一只 Jeroo 有两个名为 'hop' 的方法。调用 hop() 会让 Jeroo 向前跳一格。但是，如果你在括号里指定一个数字，比如 hop(4) ，Jeroo 就会向前跳四格。

使用方法时，你提供参数。当 编写 方法时，你要为参数命名。参数列表说明需要哪些参数。

例如：

public void turnAndDisable(RelativeDirection direction)
{
    this.turn(direction);
    this.toss();
}

要调用这个方法，我们必须提供一个相对方向作为参数：

turnAndDisable(RIGHT);

这将使 Jeroo 向右转并禁用一个网。

2.3.5.2. 使用多个参数¶

下面是接收两个参数的方法示例：

public void turnThenHop(RelativeDirection direction, int hops)
{
    this.turn(direction);
    this.hop(numHops);
}

要调用这个方法，我们必须提供一个整数和一个相对方向作为参数：

turnThenHop(RIGHT, 7);

这将使 Jeroo 向右转然后跳跃七次。

2.3.7.1. 逻辑非与 if-else 结构¶

有一点需要考虑：在编写 if/else 语句时，以 ! 开头通常会让代码更难阅读。

if (!this.isClear(AHEAD))
{
    this.toss();
}
else
{
    this.hop();
}

上面的 ! 很容易被忽略，从而导致对这个条件语句的误读。相反，更好的做法是像这样改写同一个条件：

if (this.isClear(AHEAD))
{
    this.hop();
}
else
{
    this.toss();
}

可以看到，从逻辑上讲，这两个 if-then-else 结构达到了同样的效果，但其中一个更容易阅读。

2.3.7.2. 过多的条件语句¶

另一件要记住的事情是不要编写过多的条件。在解决复杂问题时，很容易忍不住为遇到的每一种新情况不断添加新条件。然而，这既更难阅读，也可能在你的代码中引入以后很难发现的 bug。

例如：

if (this.isClear(AHEAD))
{
    this.hop();
}
else if (!this.isClear(AHEAD))
{
    this.toss();
}
else
{
    this.turn(RIGHT);
}

从逻辑上讲，这个条件语句的 if 分支和 else-if 分支与我们上面看到的一样。然而，这里存在第三个永远不会执行的分支。这是因为 Jeroo 前方的区域要么总是畅通的，要么总是不畅通。代码总能在前两个选择之间找到一个要执行的分支，而且永远不存在 else 分支适用的情形。

在计算机术语中，你编写的在任何可能的情况下都无法执行的代码称为 不可达代码。这种代码通常是一个编程问题，因为它无法执行的原因通常是由于不正确的编程逻辑，就像这里的示例一样。前两个分支涵盖了所有可能的情况，所以第三个选项是无用的。

如果你不完全确定两个布尔语句是否等价，写出一个真值表可能会有所帮助。例如，我们可以看到下面 b 和 !!b 是等价的。

无论 b 有什么值，我们都可以看到 !!b 与之匹配！

2.3.7.3. 空条件分支¶

不在代码中留下空条件也是一个好习惯。

if (this.isClear(AHEAD))
{
    // do nothing
}
else
{
    this.turn(RIGHT);
}

人们总是更喜欢只用一个 if 语句，而不是一个空的 if-else。

if (this.isClear(AHEAD))
{
    // do nothing
}
else
{
    this.turn(RIGHT);
}

这里，比起空条件，更偏好使用 ! 运算符：

if (!this.isClear(AHEAD))
{
    this.turn(RIGHT);
}

2.3.7.4. 多个条件与复合条件¶

看一下下面这段代码片段：

if (this.isClear(AHEAD))
{
    if (this.seesNet(RIGHT))
    {
        this.turn(RIGHT);
    }
}

这里我们看到一个条件嵌套在另一个条件中。通常，更好的做法是把同样的条件改写成这样：

if (this.isClear(AHEAD) && this.seesNet(RIGHT))
{
    this.turn(RIGHT);
}

2.3.11.1. 使用基本数据类型的比较运算符¶

比较运算符用于检查条件，如两个值是否相等，或者一个是否大于另一个。这类运算符完全不适用于对象，因此你不能将它们用于 Jeroo。不过，它们适用于数值，比如 int。下面的表达式展示了它们的使用方式。

关系运算符的结果是两个布尔值之一：true 或 false。这些值属于数据类型 boolean；事实上，它们是唯一的 boolean 值。

一个常见的错误是当你想比较两个值时使用单个 = 而不是双等号 ==。请记住 = 是赋值运算符，== 是比较运算符。此外，意外编写 =< 或 => 将产生编译器错误。等号总是在 < 或 > 之后，就像你在英语中说出那些比较的名称一样："less than or equal"先有小于符号，然后是等号。

一个常见的错误是，当你想比较两个值时，误用单个 = 而不是双 ==。请记住，= 是赋值运算符，而 == 是比较运算符。另外，不小心写出 =< 或 => 会产生编译错误。等号总是位于 < 或 > 之后，就像你用英文说出这些比较的名称一样：“小于或等于”是先写小于号，再写等号。