一年回顾：测试可编程基础设施

关键要点

• 可编程基础设施非常复杂，存在风险，仍然需要测试。
• 仅靠工具无法解决问题，因为云基础设施正在快速地发展演化。
• 不要只测试基本的断言。你的测试策略应该侧重于降低风险和提升质量。
• 云基础设施和探索性测试的组合很罕见。探索性测试是一种强大的方法，用于补充自动化回归套件。测试人员需要培训和经验来以及来自基础设施专家的协作和帮助才能执行有效的测试。

在 2017 年 QCon 伦敦大会上，我做了“使用 Ruby 测试可编程基础设施”的演讲。InfoQ 编辑 Daniel Bryant 为此写了一个摘要。

我在演讲中分享了我在 OpenCredo 的经历，我负责测试我们为客户开发的一个云代理。云代理跨多个云配置和管理云基础设施。客户所在的企业中有两个目标用户组：

• 希望在云基础设施上部署应用程序的内部开发团队。
• 想要跟踪团队资源和支出的管理层。

我们发现，我们可以通过标准技术来测试应用程序的网页和 API，但测试云基础设施却很困难。我们必须采用新的流程、技术和工具来获得相同的覆盖率和保证。我们还遇到了云基础设施固有的技术限制：

• 很多操作都很慢，而且是异步的。
• 部署资源的成本很高。
• 工具还不成熟。

比技术问题更让人头疼的是，我们还要面临文化方面的挑战。系统管理员和测试人员不习惯在一起合作！

我知道，可编程基础设施正在变得越来越普及。有一些特定的领域问题让基础设施的测试变得很棘手，但似乎没有人能够给出有效地解决方案。

基础设施资源对软件的成功来说至关重要。如果你的数据库或负载均衡器出现问题，可能是由于已提交的代码导致的。因为是生产环境的代码，所以我们应该对其进行测试！

上次的演讲已经过去一年多时间了，而启发我去做这个演讲的那个项目是更早之前的了。从那以后，我做了其他一些项目，我的想法也发生了变化。

工具越变越好，但并不代表一切

我演讲的主题之一是我们必须工具改进。我有理由相信这种情况会继续下去。随着越来越多的工程师执行相同的任务，他们需要工具来简化他们的工作。

Terratest 是我很喜欢的一个工具。在 OpenCredo，我们的一个主要项目已经在使用它。Terratest 为 Terraform、Packer、Docker、SSH 和 AWS API 提供了通用的辅助功能。可以用它来测试 Terraform 代码、 Packer 模板和 Docker 镜像。

一个简单的测试可能涉及：

• 调用 Terraform 脚本来创建一些 AWS 资源
• 使用 AWS API 来验证每个资源的创建和配置
• SSH 到 EC2 实例并做一些验证
• 销毁资源

但这些并不是唯一需要测试的技术。根据我的经验，对 Jenkins Groovy 管道做出变更是存在风险的，而且很复杂。通常是因为这些变更难以测试。我还没有看到一个让我感到满意的回归测试工具。

我在准备演讲时，主要关注点是虚拟机。我希望确保云代理那个正确配置和配置服务器。 ServerSpec 非常适合用来完成这项任务。

事后看来，这种想法非常具有局限性。我的上一个主要项目是基于无服务器架构。这个应用程序的作用是维护云资源的清单，其中存在两个问题。首先要确保应用程序能够编目和发现外部云资源。其次要确保我们自己的基础设施能够按预期运行！我们使用了各种 AWS 工具——DynamoDB、Lambda、SQS、Kinesis 等。它们都是按照基础设施代码的形式来提供的。ServerSpec 很棒，但它在这方面却帮不上忙，因为我们对这些服务器没有访问权限！

我无法推荐长期可用的工具，因为工具适用于特定技术，而且行业发展太快。AWS 服务的种类也在逐年增加，无服务器和编配技术的兴起只会让这种情况愈演愈烈。你可以学会使用 Kubernetes 或 AWS Lambda 测试框架，但过几年内可能就会过时。

那么，如果说工具无法帮助我们，那什么可以？

测试基础回顾

在测试新内容时，重新回顾基础知识是非常重要的。在上一次演讲中，我太过关注我们是如何进行测试的，但对为什么要进行测试没有着墨太多。我不知道你们的云基础设施是怎样的，这个话题太过宽泛，而且变化很快。但测试基础是不会改变的，我们需要考虑如何将它们应用到新领域。

在采访中，我最喜欢被问的一个问题是“什么是测试？我们为什么要做测试？”这是一个奇怪的难题。这是我的答案：

软件测试是一种发现软件质量问题的调查手段。

重新验证我们正在构建的东西并不是一项简单的任务——但却是不可或缺的。你可能会误解用户想要或需要的东西，应用程序可能包含你没有想到的用例。

那么，我们关于系统未知方面的想法是如何产生的呢？

测试启发式方法

测试启发式方法是一种基于经验的技术，用于生成测试想法。在编写测试用例时，你需要参考启发式方法。Elizabeth Hendrickson 提供了一个相关的手册。有些启发式方法是通用的，有些则特定于某些领域。安全性和性能也有自己的启发式方法——这就是为什么这些领域需要专家。关于这方面更多的内容，我强烈建议你阅读 Katrina Clokie 的这篇优秀的文章。

在测试可编程基础设施时，我们可以考虑从应用启发式方法开始。我们可能需要考虑与基础设施相关的常见的风险，如数据丢失或可用性。例如：

• 在终止实例时是否会把卷也删除了？
• 我的数据库分片算法是否均匀地将负载分配给每个数据库分片？
• 我的 AWS S3 桶是公开的吗，是否需要公开？
• 我是否检查过 IAM 角色以及谁可以访问哪些内容？
• 我可以在应用程序运行时重新部署资源吗，这样是否会导致数据错误？

启发式方法的一个特点是它们需要领域知识和经验。这些类型的问题涉及到应用程序架构的相关知识。通常需要具备分析和评估风险的能力才能提出正确的问题。最后，我们需要经验和知识来理解和解释这些问题的答案。我们识别问题的机制被称为测试预言（oracle）。想要更多地了解预言，请参阅 Michael Bolton 的文章。

打破常规

现在我们已经拥有了用于测试基础设施不同方面的方法，接下来需要执行这些测试。但你很可能难以自动化你能想到的每一个想法，而且我认为你不需要。

最好的测试通常是精心设计的自动化套件和探索性测试的组合体，我们现在就可以开始使用它来测试我们的基础设施。

探索性测试主要用于识别风险，不受脚本的限制。但不要把探索与临时测试混淆在一起！探索性测试可能需要一个小时左右的时间，主要针对应用程序的特点问题或风险。

唯一的指导原则是用于发现特性信息的测试章程。例如：“我希望通过检查 IAM 角色及其访问权限来发现应用程序中的潜在安全问题”。

章程概述了预期的信息，同时还可以自由发现非预期的问题。在进行探索性测试时，你会思考，执行，观察结果，并用它作为下一个测试的输入。测试可以是以用户或技术为重点，或两者兼而有之。在测试过程中，你记录下你所做和所观察到的东西，这样就可以向别人报告你的发现。我们鼓励你利用创造力和直觉。我们的想法是尽可能多地找出有趣的信息。

探索性测试并不能代替测试自动化，它只是一个补充。它可能会揭示很多问题，可以将这些反馈作为自动化测试断言的参考。

它还澄清了软件中模糊的功能。有时候，软件会出现不寻常的行为，我们也不清楚正确的行为应该是怎样的。在经过探索性测试之后，当你和其他人一起讨论结果时，他们可能会说“呵呵，我没有想到这一点！”这种分析过程是很难进行自动化的，而且没有明确的标准用来判断是通过还是不通过。

有很多关于如何做好探索性测试的资料，不过我建议阅读 Elisabeth Hendrickson 的“ Explore It! ”这本书。它是我想要推荐给测试新手的第一本书。

我在基础设施相关文章中提出了一种无关性的测试技术，这似乎很奇怪。但探索性技术在可编程基础设施中的应用非常少。云技术专家通常拥有运营或开发背景。测试人员通常没有强大的技术背景，或者他们将可编程基础设施相关问题留给其他人去解决。我认为，如果我们能够互相传授想法和技术，可以从中获得很多。

测试人员需要在云基础设施方面做得更好，运维人员需要更好地进行测试

我在上次的演讲中提到，作为测试人员，我对这个新领域不是很熟悉。因此，我很难知道要测试些什么，也不知道我观察到的东西是好还是坏。

最重要的是要提高意识。我们需要重视掌握了基础设施技能的测试人员。目前，测试人员最有价值的方面是他们的自动化能力，于是出现了很多自动化工程师。测试人员已经学习了新技能，开发人员可以帮助进行技术测试。所以，在可编程基础设施这件事情上，我们也可以采用这样的模式。

另一方面要提升测试人员的技能，并让他们参与其中。这与现在教授测试人员技术技能没有太大的不同。以下是一些有用的活动：

• 培训和认证：我目前正在为能够拿到 AWS 解决方案架构师相关认证而努力学习。这个认证涵盖了 AWS 各种服务的基础知识以及它们之间的组合关系。相关的认证培训可以帮助测试人员了解云基础设施。这类培训课程包括 A Cloud Guru 和 Linux Academy 。如果你想学习可编程基础设施，可以使用 Katacoda 。
• 结对：测试人员和开发人员通常会结对工作，他们当然也可以结对开发和测试基础设施代码。即使看起来测试人员更像是来学习的，但仍然可以帮助他们测试系统。
• 分配基础设施工作：实践是最好的学习方法。有很多测试活动可能涉及与基础设施相关的工作。例如，搭建管道和测试基础设施或设计基础设施测试用例。对于专注于技术的测试人员来说，这可能会更容易些，他们甚至已经在做这样的事情。
• 协作活动：有很多适用于基础设施协作的测试活动。风险暴风可用于揭示管道或环境部署的潜在风险。你可以将“ Three Amigos ”应用在基础设施故事上。例如：“作为开发人员，要运行 Java 应用程序，就需要在容器中安装 JDK 1.8 运行时”。你怎么测试这个？为什么是 JDK 1.8？

一切都在变化，没有东西是停滞不前的

我在这里提出的许多问题已经得到了解决，但不是每个人都知道这些问题的存在。它们并非新技术。

事实是，我们都是工程师，我们都有自己的专长。但我们可以互相学习。当有人跟我说他们也面临同样的问题并想对此采取行动时，我就备受鼓舞。

如果我们想要正确地测试基础设施，需要做两件事。

首先，测试人员需要了解更多领域知识。了解云基础设施，了解如何通过可编程基础设施来部署和维护云基础设施，了解可能出现的问题以及哪些地方存在风险。

其次，我们需要重视测试人员的观点，并认识到基础设施不仅仅是 ops（现在是 deva）的专有领域。最好的测试策略是特定于环境的，它们成功地识别并降低风险，防止生产环境出现问题。但要记住，基础设施本身也存在风险。

关于作者

Matt Long 是 OpenCredo 的高级 QA 顾问，OpenCredo 是一家位于伦敦的开源咨询公司。他担任顾问已经有多年时间，并用六种语言构建了测试自动化框架。他的专业领域涉及云基础设施、无服务器架构、API 和 Web 测试。他曾在 QCon、muCon、TestBash 以及伦敦的很多小型聚会上进行过演讲。在业余时间，Matt 对 indiepop 音乐、电子游戏感兴趣，并且是“辛普森语录”方面的“百科全书”。他还开发和维护着一个机器学习桌上足球机器人项目。

查看英文原文： Testing Programmable Infrastructure - a Year On