问题是关于测试/验证产品配置的最佳实践。
假设我们正在开发酒店预订系统，有 1 个用于预订书籍的网站、用于处理预订的后台守护程序工作以及用于与酒店通信的 API。网站向 Message Queue 发布消息，守护进程使用这些消息，将这些消息保存在数据库中并通过 API 向酒店发送通知。
在这种情况下，测试/验证以下内容是否有意义：
是的，冒烟测试和集成测试将测试这一切，但他们更有可能进行应用程序逻辑测试。我想要一些可以在冒烟测试之前运行的东西，对于 pre-prod 和 prod 环境，它会很好地检查所有配置是否指向 prod。
任何建议将不胜感激。
【问题讨论】：
标签： unit-testing testing configuration verification configuration-management
你想要的不是真正的测试，这是监控。
您想检查系统的运行状况。
您将从 monit (https://mmonit.com/monit/) 开始，因为它是运行守护程序的一个很好的基础。它还内置了可编写脚本的检查，因此如果您的守护进程占用过多的 cpu 或 ram，它可以重新启动它。
您还可以监控您的 mq 服务器和队列长度，以便在问题出现时及时发现。
对于配置文件和正确的数据库连接：如果这些不正确，即使您的索引页面也可能会失败，因此类似监控的检查会在几秒钟内诊断出这些问题。
我还会在应用层实现健康检查，并定期从您的监控服务中调用它（例如 yoursite.com/healthreport.php，它只能从地址列表访问）。然后你可以投票。确保提供带有当前版本信息的有用错误消息（例如您的应用程序版本、php 版本或 mysql 版本），并跟踪这些信息，因为在没有信息的情况下寻找问题是很困难的。 （哪个服务器！？哪个用户？它是哪个版本？它在哪里？哦，你们刚刚apt-get更新了吗？！？）
这样，如果您的健康报告没有及时回复，并且答案不是“一切正常”，那么它可能会向您发送警报。
对于配置，我将实施三层解决方案： - 第 1 层是所有内容的默认设置，这是您的源代码的一部分，当然它是受版本控制的。 - 第 2 层是版本控制的覆盖配置，仅与默认设置不同。您应该在配置中包含您的安装实体名称（或例如主机名），因此您可以在一个版本控制目录中存储测试、生产、开发配置。没有人接触过生产中的配置，您应该始终提交更改来做到这一点。 - 第 3 层是 NEVER 的例外 :) 用于安全凭证，并且它不是版本控制的，因此它只是安装附近服务器上的一个文件，并且可能也包含安装名称（“生产”或“开发”等）。
这种分层配置意味着您将始终知道谁更改了哪些内容，您将知道当前已发布哪个版本，并且如果您遇到问题，您可以回滚任何更改（甚至自动）。
（凭证存储除外，但几乎不会更改，而且您确实有备份，不是吗？）
此外，日志记录和日志分析是您操作的一部分，您的应用程序永远不应隐藏问题（尝试捕获所有内容），但它应该有一个内置的异常处理程序，记录有关问题的所有必要细节，并帮助您追查问题。
例如，如果您的软件以脚本语言在自托管环境中运行，您可以直接从版本控制软件进行部署。并且当引发异常时，您可以分析堆栈跟踪（如果需要，可以实时分析），检查发生在哪个文件中的哪一行，并使用 vcs 工具注释功能跟踪对开发人员的最后更改，修订（提交） ，甚至根据提交的消息在您的问题跟踪系统中发送一张票。
这样，智能系统可以： - 实时通知负责最后一次更改的开发人员（这并不总是他/她的错，但他或她有最新的信息，因此如果必须，他们将最快地将问题追溯到其他开发人员） - 如果你有一个例外，你可能会得到 200 个相同的原因，所以你可以一起收集它们。 （不同的 DATE-sourcefile-line :)）。
您还想在上线之前测试这些吗？您将需要一个暂存环境，其设置与真实环境几乎相同，然后您将需要一个滚动更新系统来逐步发布新版本。您也可以自动执行此操作，滚动更新仅在没有已知问题时才会继续。
我确信像 gmail 这样的服务也会跟踪响应时间，所以如果 2.1 版本的响应时间比 2.0 版本的响应时间长 20%，他们也将其视为失败，即使用户升级也将停止甚至没有注意到问题。
基本思想是，您应该在尝试处理它们之前存储所有数据（即使您的系统崩溃也能够恢复），然后您应该存储一些用于分析的指标，编写防御性代码来处理所有可能的情况失败场景（测试所有内容），然后自动收集这些报告。
您还应该为您的 api 构建一个客户端（很高兴将它提供给您的付费客户，以使用您的 api），并且通过该客户端，您可以全天监控您的服务。
【讨论】：