Questions tagged «testing»

如果您具有复杂程度适中的Terraform配置，您将如何围绕可作为持续集成/持续交付管道的一部分执行的配置编写测试？ 例如，您可能具有指定以下所需状态的多云配置： Azure容器服务在Azure中托管Docker Azure Blob存储 SQL Azure EC2容器服务以在AWS中托管Docker Amazon S3存储服务 Amazon RDS SQL Server数据库 可能terraform apply会从头开始创建上述内容，或从部分部署状态过渡到上述所需状态。 我知道Terraform将其工作分为执行计划阶段和应用程序阶段，后者实际上是对目标体系结构进行更改。是否可以使用它来针对执行计划编写测试，如果有的话，是否有框架可以帮助编写这些测试？

37 testing  terraform 

正在尝试尝试在我们的Ansible设置中建立一些弹性，以处理配置和配置。 我了解在事物的配置方面进行测试的几种方法，但是我想知道如何最好地在事物的配置方面进行测试，以及是否有任何工具可以帮助实现这种类型的实现。 目前，我们的许多测试是在剧本期间连续进行的，这对于诸如“有服务出现； vip可用；异步任务已完成”之类的事情很有用，但真正令我感到担忧的是我们管理漂移的能力。在应用程序层和供应层进行配置（例如VM配置）。我知道Ansible并不是解决配置漂移的最佳工具，但我很想知道您的意见。 如果您有什么可以使流程完全自动化的更好。（我们有一些丑陋的脚本，它们每天都会以松弛状态返回报告）。 注意：现在，在一些情况下，可能会发生重新配置（例如，从备份进行重建，严重的系统问题），但是通常情况下，它只是循环执行一些烦人的配置任务，因此不再考虑其他事情。

33 testing  ansible  configuration  provisioning 

假设您使用的是持续集成过程，该过程会经常更新某些目标环境，以便每次发生某些更改时，“您”都可以立即测试您的更改。那是CI的目标之一，不是吗？ 但是，还要假设您在测试周期中涉及其他人员，例如经理或客户。让其他人参与尝试（中断）您即将进行的更改很有意义，不是吗？ 但是，如果您继续在其他人正认真尝试测试的环境中不断交付更改，那么可能会出现多个问题，例如： they 可能会浪费他们的时间来报告问题，而当他们保存（深入）报告时，他们甚至无法自己重现该问题（例如，由于您偶然遇到了同一问题，并且已经将其修复在他们的环境中）。 you 可能无法重现他们报告的问题，因为遇到问题的环境不再相同（您（!!!）可能覆盖了他们的环境）。 那么，您该怎么做（如何配置事物？）来避免此类（令人沮丧的）情况？

19 continuous-integration  testing 

我是Ansible的新手。这是我的任务... 我有400多台主机，我需要验证从它们的一端到我们的Web服务器是否打开了5个不同的端口。 我可以单独登录并运行： telnet mywebserver.com 443 telnet mywebserver.com 80 telnet mywebserver.com 8443 ..等等.. 可以在Ansible中使用什么模块或插件，以便使它自动化，并让其将结果（无论是打开还是关闭的端口）报告回我的Ansible服务器？

15 ansible  testing  ports 

我已经注意到，在集成测试过程中，我实际上使用的是Restful API（或一般的HTTP接口）的重复使用案例，我在这里和那里使用bash + cURL进行检查。 它开始看起来非常凌乱，并且变得难以维护。为什么要乱成一团？ 典型的用例是： 检查URL是否返回http响应代码，例如200 在这种情况下，检查内容类型是否与您需要的某些MIME相匹配 检查返回的内容是否匹配某种模式，或通过抽象验证过程 到目前为止，我发现并在不重新发明轮子的情况下认为是可行的选择是： 可以使用PyCurl-希望它可以完全实现所有cURL选项esp。代理以及其他我可能需要的开关 使用Python的内置单元testng 然后，例如，我可以检查每个服务一项单元测试： import unittest, pycurl class TestService (unittest.TestCase): def test_1(self): self.assertEqual(pycurl.returncode("some_url"), 200) def test_2(self): self.assertTrue(pycurl.response("some_url").matches ("xxx") ) def test_3(self): self.assertTrue (pycurl.ContentType("some_url").equal("xxx")) if __name__ == '__main__': unittest.main() 这是否有意义？或者是否有更高级的工具（但不太复杂，无法使用和集成）？

14 testing  continuous-deployment  python  curl 

作为代码的基础架构告诉我们使用自动化构建的工具。大。像工具ansible，厨师，木偶，盐栈以及其他推动我们写作基础设施长相怎么样，而解决分歧。 在Salt Stack中，这些位称为状态。如果状态与现实不符，该工具将为我们解决。换句话说-我们正在为基础架构编写测试，如果测试失败，该工具将自行修复。至少那是主意。 XP教我们如何使用TDD，问题是它是否适用于基础架构？工具表明确实如此。 我可以想象几种非常有用的测试类型。 我们编写与部署的服务捆绑在一起的冒烟测试，以确保端到端的部署服务正常运行。这将是一个API调用或/和systemctl检查，以确保我们刚刚部署的内容能够正常工作。由于诸如ansible之类的工具具有确保服务正在运行的状态，因此许多功能都可以在相同的状态下涵盖。 有一个项目Molecule允许针对docker或另一个临时虚拟化引擎运行单独的角色（如Ansible所说的那样）。这迫使角色分离，并允许在处理角色时将其与剧本隔离地执行。测试通常允许模拟该角色应该使用的变量。但是，其他示例似乎是ansible引擎的副本（声明文件属于用户...）。 ThoughtWorks的高科技雷达，现在推崇一样的工具INSPEC，serverspec或戈斯用于验证服务器是否满足规范。但是我们正在编写规范，不是吗？ 如果我们以状态/角色描述基础架构，那么进一步测试基础架构是否有意义？我想这可能会在较大的组织（由一个团队提供规范并遵循其他规范）中变得更加必要，或者如果有大量角色，也许您想运行其中一部分并从测试中获得快速收益？我很努力地想知道，如果您对相同的问题有一个角色/状态，为什么还要编写测试。

11 deployment  testing  infrastructure-as-code  serverspec  tdd 

目前，我处于一种状态，即测试要花我很多时间和金钱... 背景：我正在软层上部署VM，并使用部署后脚本（bash），该脚本将在VM准备好后安装所需的每个软件。问题是，我只能通过部署一个VM来测试此脚本，并且目前大约需要4小时才能完成脚本...因此，我进行的每一次更改都需要创建一个新的VM（需要花钱）并等待大约4小时后看脚本是否损坏...这变得混乱了，如果我保持这种方式，我将无法前进。 我需要一种新的方式来处理这种情况，并且能够更快地测试配置脚本，而不必每次都部署新的VM。 你们知道在这种情况下有什么工具可以帮助我吗？

10 testing  provisioning  virtualization