正确的测试心态（测试理论第一部分）

获取新的 Intel® 物联网开发者套件，这是一套完整的硬件和软件解决方案，使开发人员能够使用 Intel® Galileo 和 Intel® Edison 主板创建令人兴奋的新解决方案。访问 Intel® 物联网开发者专区。

我最近写的一篇关于 ESA Schiaparelli 坠毁事件的博文 引发了一场关于测试、测试执行工具和正确测试心态的讨论。如果您回顾一下我过去在 这个博客 和 Wind River 博客 上写的内容，会发现一个反复出现的主题，那就是将测试扩展到显而易见的范围之外，并测试那些在现实世界中难以测试的内容（通过使用模拟）。在这个关于测试理论的两部分系列博文中，我将尝试总结我对测试的看法，并分享一些轶事。

这是第一部分，您可以在 这里 找到第二部分。

测试领域

一般来说，计算机系统中的软件（包括汽车、飞机、机器人、服务器、笔记本电脑、火箭、烤面包机、手机和核电站）被设计为在某些情况、输入、状态和环境条件下工作。软件测试倾向于关注证明软件按预期工作，并且在系统的设计空间内，它能为预期和格式正确的输入给出正确的结果。

预期和格式正确的输入可以意味着命令行界面中的有效命令、计算函数的合理值、控制系统中在预期范围内的传感器值、遵循协议格式的网络数据包、图形界面中正确顺序的点击等等。大多数时候，这是程序员集中精力的地方，以确保软件做正确的事情并按预期执行。毕竟，如果软件不能完成它被构建的任务，对任何人来说价值都微乎其微。

在预期输入空间之外，我们进入了无效或异常状态和输入的领域。软件确实也必须以一种优雅的方式处理这些状态。这就是为什么我们会从编译器那里得到语法错误消息，而不仅仅是随机的垃圾二进制文件。如果您被要求在网络表单中输入年龄，然后输入字母，您理应期望系统给您一个错误消息，而不是接受您的年龄是“与你无关”或“ABC”。错误处理是软件开发的关键部分，或者至少应该是。

在我看来，异常状态可以分为两部分：在系统正常运行过程中发生的异常值，以及系统明显损坏的故障。例如，如果您为飞机设计一个控制系统，该系统本应不超过 500 公里/小时的速度，但飞机在一次俯冲中设法超过了该速度，那么就出现了一种异常情况——但系统本身仍然完好无损。如果相反，速度传感系统出现故障并开始报告与系统实际状态无关的随机值，那么就存在故障。

虽然这两种情况都是反常或异常的，但它们需要以不同的方式处理。异常状态反映了系统的实际状态，算法必须得到扩展，以便以一种优雅的方式处理这些情况。世界是一个艰难的地方，系统必须与之应对。另一方面，故障需要偏执的逻辑来检测系统中是否存在故障。当检测到故障时，必须使用不依赖于故障组件的回退策略。在许多情况下，处理故障归结为物理冗余和使用多个不同的传感器来检测是否有任何一个传感器出现故障。

总而言之，以下是我对软件系统可能遇到的状态空间的一些思考方式，以及工程师在看到系统在给定状态下运行时典型的说法。

最里面的绿色框代表系统被设计来处理的状态集。预期的输入、格式正确的程序、控制系统的正常运行状态、飞机的设计速度等。

黄色框代表预期的异常状态和预期的故障。对于这些情况，应该有相应的逻辑来以合理安全的方式处理。对于预期的异常状态，情况是可预见的，并且我们知道软件仍然会工作——即使工作意味着打印错误消息。这是软件中典型的错误处理所处理的范围。对于预期的故障，我仿佛能听到一位程序员自信地告诉用户：“是的，我们已经意识到这些东西可能会出问题，并且软件设计成即使在存在故障的情况下也能正常工作”。

在黄色框之外，是红色框。这涵盖了意外的异常状态和意外的故障，我们进入了未知的领域。我们驶出了地图的边缘，无法预测接下来会发生什么。由于按照定义没有人考虑到这些情况，所以会发生什么将是碰运气的。在最好的软件（或者纯粹是幸运的软件）中，这些情况会被良好的限制器、逻辑和一致的设计优雅地处理，即使远远超出了设计状态，也能以线性方式运行。良好的“全方位捕获”系统非常有帮助——前提是您执行了能使系统进入安全状态的操作。然而，正如多年来无数的例子所说明的那样，很可能会发生糟糕的事情。

创意测试

鉴于这种测试领域，我们可以将我们为系统定义的测试分为以下几类：

• 测试正常运行的测试
• 系统设计者设想的预期异常情况和预期故障的测试
• 对超出设计者想象的意外情况的测试

然而，对意外情况的测试真的存在吗？毕竟，如果我们有一个测试，那它就属于设想和预期的范畴。我将在本系列的 第二部分 中回到关于测试意外情况的问题。

回到预期领域，一个优秀的测试员的关键技能在于在系统可能承受的方面具有极强的想象力和创造力。随着测试的创建、运行，很可能出现失败，开发人员将修复软件。这个过程应该会使软件更好，通过破坏它来有效地提高系统的健壮性。

因此，一个优秀的测试员可以扩展“预期异常”和“预期故障”状态的集合，提高系统的可靠性以及我们可以对其行为感到自信的状态和故障的集合。这也意味着意外状态的集合会减少，如下所示：

理想情况下，红色框会被消除——但我怀疑对于在现实世界中运行的真实系统来说，这是否现实。经验告诉我们，世界在想出新情况方面极其有创造力。正如有人常说的，如果你认为你的软件是万无一失的，那只是因为你还没找到合适的“傻瓜”。

让我讲一个关于创意测试的计算机历史上的故事。

黑队

我认为一个优秀的测试员应该像黑客一样思考——寻找系统可能出错的方式，找到可以被利用来导致故障的裂缝。我们可以期望程序员在测试系统的正常运行及其工作方式方面做得不错——这是常规的快速开发测试的一部分。如上所述，测试员的工作是超越明显有效的情况，进入程序员可能没有过多考虑的状态——并将这些纳入测试体系。

20 世纪 60 年代，IBM 有一个传奇的测试团队，称为黑队，我认为他们是创意测试的典范。IBM 非常关心其软件的质量，并将他们最优秀的测试员组成一个团队，他们认为有才华的人一起工作可以对效率产生巨大的影响。他们的成功超出了他们的想象！

来自 http://t3.org/tangledwebs/07/tw0706.html

“……他们开始将自己的工作视为不是测试软件，而是破坏软件。团队成员为自己的能力赢得了当之无愧的自豪感，并开始培养一种恶毒破坏者的形象。作为一个团体，他们开始穿着黑色服装上班，并称自己为‘黑队’。”

黑队在测试代码方面做得如此出色，以至于程序员都害怕他们——这反过来又大大提高了代码质量。由于程序员知道粗制滥造会被发现，他们对自己和自己的代码要求更严格。

像这些人一样折磨软件，是一门我们仍然需要的艺术。特别是在考虑到软件在我们生活中的普遍性，以及安全漏洞、系统被黑客攻击和安全关键控制软件所带来的非常实际的威胁时。

总之。

第一部分到此结束。在 第二部分 中，我将探讨更多关于测试的实际方面，以及工具和系统的性质和可用性如何影响测试工作。