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

在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