防止脚本错误：尽早测试

随着您的 Shell 脚本复杂性增加，潜在的陷阱也随之增多。在开发过程的早期发现错误可以节省时间和避免后续的挫败感。通过从一开始就加入测试，您可以识别和修复问题，防止它们像滚雪球一样变大，从而获得更健壮和可靠的脚本。

这是关于使用 Shell 脚本进行自动化的教程系列的第六篇文章，了解如何确保您的程序正确运行。前一篇文章教您如何使用模板构建高效脚本。

让我们来谈谈测试。根据我作为 Linux 管理员多年的测试经验，我发现 Shell 脚本的适当测试要么完全被忽视，要么匆忙完成。

我也遇到过为了赶上尖头老板的进度，而故意最小化或跳过测试的情况。

作为系统管理员，我的目标是编写在各种条件下都能完美运行的 Shell 脚本。本文探讨了不同的测试方法，并指导您完成实施过程。

关于测试

“总会有一个以上的错误。”

— Lubarsky 的控制论昆虫学定律

Lubarsky 是正确的。您永远无法找到代码中的所有错误。对于我找到的每个错误，似乎总会有另一个错误冒出来，通常是在最糟糕的时候。

测试不仅仅是关于程序。测试不仅仅是寻找代码中的错误。它还关于验证脚本是否真正解决了它旨在解决的问题，而不管来源（硬件、软件，甚至是意外的用户操作）。测试还确保脚本用户友好并具有清晰的界面。

在编写和测试 Shell 脚本时，遵循一个明确定义的过程可以帮助获得一致且高质量的结果。

我的流程很简单

1. 创建一个简单的测试计划。
2. 在开发初期就开始测试。
3. 在代码完成时执行最终测试。
4. 移至生产环境并进行更多测试。

测试计划

测试计划有很多不同的格式。我使用过各种各样的格式——从所有内容都记在脑子里；到在一张纸上匆匆记下一些笔记，再到一套复杂的表格，需要详细描述每个测试、它将测试的功能代码、测试将完成什么，以及输入和结果应该是什么。

经过多年的经验，我现在尝试采取中间路线。至少有一个简短的书面测试计划将确保每次测试运行的一致性。您需要的详细程度取决于您的开发和测试职能的正式程度。

我在网上搜索中找到的示例测试计划文档很复杂，旨在用于具有非常正式的开发和测试流程的大型组织。虽然这些测试计划对于那些职位名称中带有“测试”的人来说很好，但它们并不适用于系统管理员更混乱和时间紧迫的工作条件。与工作的大多数其他方面一样，系统管理员需要有创造力。因此，这里有一个简短的列表，列出了您在测试计划中应考虑包含的内容。根据您的需要进行修改

• 被测软件的名称和简短描述
• 要测试的软件功能描述
• 每个测试的起始条件
• 每个测试要遵循的步骤
• 每个测试的预期结果描述
• 旨在测试负面结果的特定测试
• 程序如何处理意外输入的测试
• 每个测试通过或失败的明确描述
• 模糊测试，如下所述

此列表应该为您创建测试计划提供一些想法。大多数系统管理员应该保持简单和相当非正式。

尽早测试——经常测试

我总是在完成第一个可执行部分后立即开始测试我的 Shell 脚本。无论我是在编写一个简短的命令行程序还是一个可执行文件的脚本，都是如此。

我通常从使用我们在上一篇文章中创建的 Shell 脚本模板开始创建新程序。我编写 Help 函数的代码并对其进行测试。这通常是过程中的一个微不足道的部分，但它可以帮助我入门，并确保模板中的内容在开始时正常工作。此时，很容易修复脚本模板部分的问题，或者对其进行修改以满足标准模板无法满足的需求。

一旦模板和 Help 函数正常工作，我就继续创建程序的主体，方法是添加注释来记录满足程序规范所需的编程步骤。现在我开始添加代码来满足每个注释中陈述的要求。此代码可能需要添加在该模板部分中初始化的变量——现在模板正在变成一个 Shell 脚本。

这就是测试不仅仅是输入数据和验证结果的地方。这需要额外的工作。有时我会添加一个命令，简单地打印我刚编写的代码的中间结果并进行验证。对于更复杂的脚本，我添加了一个 -t 选项用于“测试模式”。在这种情况下，内部测试代码仅在命令行上输入 -t 选项时执行。

最终测试

代码完成后，我返回使用已知输入来生成特定输出，对所有特性和功能进行完整测试。我还测试一些随机输入，看看程序是否可以处理意外输入。

最终测试旨在验证程序是否按预期运行。最终测试的很大一部分是确保在开发周期早期工作的功能没有被在周期后期添加或更改的代码破坏。

如果您在向脚本添加新代码时一直在测试它，您可能会认为在最终测试期间不应该有任何意外。错了！最终测试期间总是会有意外。总是。期待这些意外，并准备好花时间修复它们。如果在最终测试期间从未发现任何错误，那么进行最终测试就没有意义了，不是吗？

生产环境中的测试

哈——什么？

“直到一个程序在生产环境中运行至少六个月后，最有害的错误才会被发现。”

— Troutman 的编程假设

是的，在生产环境中进行测试现在被认为是正常且可取的。作为一名曾经的测试人员，我认为这很合理。“但是等等！这很危险，”您说。我的经验是，这并不比在专用测试环境中进行广泛而严格的测试更危险。在某些情况下，别无选择，因为没有测试环境——只有生产环境。

系统管理员对在生产环境中测试新的或修订的脚本的需求并不陌生。任何时候将脚本移至生产环境，这都变成了最终测试。生产环境构成了该测试最关键的部分。测试人员在测试环境中可以想到的任何东西都无法完全复制真实的生产环境。

据称新的生产环境测试实践只是对系统管理员一直以来都知道的事情的认可。最好的测试是生产环境——只要它不是唯一的测试。

模糊测试

“模糊测试”这个词可能听起来像是随机敲击键盘直到出现问题。但它不仅仅如此：它是关于故意向程序输入意外或无效的数据，以查看它的反应。

模糊测试有点像我儿子在不到一分钟的时间内用随机输入破坏了一个游戏代码。这几乎结束了我为他编写游戏的尝试。

大多数测试计划都使用非常特定的输入来生成特定的结果或输出。无论测试将正面或负面结果定义为成功，它仍然是受控的，并且输入和结果是指定的和预期的，例如特定故障模式的特定错误消息。

模糊测试是关于处理测试所有方面的随机性，例如起始条件、非常随机和意外的输入、随机选择的选项组合、低内存、与其他程序竞争的高 CPU 级别、正在测试的程序的多个实例以及您可以想到的任何其他随机条件来应用于测试。

我尝试从一开始就进行一些模糊测试。如果 Bash 脚本无法处理早期阶段的显著随机性，那么随着您添加更多代码，它不太可能变得更好。这是在代码相对简单时捕获这些问题并修复它们的好时机。在每个阶段进行少量模糊测试也有助于在问题被更多代码掩盖之前找到它们。

代码完成后，我喜欢进行更多更广泛的模糊测试。始终进行一些模糊测试。我当然对一些结果感到惊讶。测试预期的事情很容易，但用户通常不会使用脚本做预期的事情。

总结

在本文中，我们深入探讨了测试我们编写的 Shell 脚本的重要性和方法。作为一名系统管理员，我的目标是创建在各种条件下都能完美运行的代码。这就是为什么彻底的测试是编写优秀脚本的重要组成部分。

现在您已经了解了好处，是时候创建您自己的测试计划并开始以结构化的方式测试 Bash 脚本模板了。

接下来我们将研究初始化变量，以确保您的程序在正确的条件集下运行。