产品发布测试可能是一个复杂的需求矩阵，尤其是在当今复杂的软件和硬件系统中。发布需要花费无数小时进行测试，以确保这些产品在到达客户手中之前的质量。本文阐述了基于 Web 的产品 (SaaS) 的发布，以及在整个 QA 过程中确保环境保真度的重要性。
在测试复杂的应用程序时，重要的是在测试过程的所有阶段，测试环境都尽可能类似于实际的生产系统，但随着发布过程的推进，这一点变得更加重要。产品发布可能会经过多个阶段的测试，包括：开发测试、QA 测试、性能测试、Soak 测试和 Staging（预生产）环境，然后才能发布到实际的生产环境。
正如 Puppet Labs 的 Aliza Earnshaw 所说：
“但是，要实现 [持续交付]，您必须将代码从开发人员的桌面环境移至测试环境——或多个环境——然后再移至生产环境。所有这些环境都必须以相同的方式配置，否则您将冒着找到在 QA 中工作的代码的风险，例如，在生产中中断。” [1]
让我们考虑一下同类测试环境背后的原因：
开发测试
在测试的开发阶段，工程团队将每天对其更改进行多次迭代测试。虽然在这个测试阶段让环境与生产系统中的环境相似很重要，但仍有许多方面难以复制。例如，可能只有一台服务器可以服务于多种用途，例如应用程序服务器、Web 服务器、数据库服务器等。可能没有负载平衡器、没有冗余服务器，也没有故障转移过程。在测试的这一点上，这是预期的。
但是服务器本身应该与生产环境中的类似。在最终将在 Linux 服务器上运行的 Windows 服务器上测试应用程序不如在安装了相同操作系统和其他软件包的 Linux 服务器上进行测试有效。重要的是相同的操作系统（包括补丁级别）和其他软件包与生产环境中的版本相同。在发布过程的所有阶段测试应用程序的可能性，只有在它进入生产环境时才发现错误，因为生产使用的是不同版本的软件，这是任何团队都不应该遇到的问题。通过使开发测试环境类似于最终将安装应用程序的实际生产环境，团队可以消除与软件版本相关的潜在问题。
如果存在与开发测试环境中不可用的其他软件包的交互，重要的是要有模拟器或仿真器来模拟该交互。如果不这样做，那么与该功能相关的潜在问题将在发布过程的后期才能被发现，而此时发现问题的成本要高得多。开发团队测试此功能的能力，尤其是当他们进行可能影响此功能的更改时，对于应用程序的质量控制至关重要。
质量保证测试
一旦新功能的开发取得进展，该应用程序将移交给质量保证小组。在流程的这一点上，应该有一组更全面的环境可供该团队使用，与生产系统比开发测试系统更相似。这是多个应用程序服务器、负载平衡器和生产中发现的其他系统应该就位的地方。仿真器和模拟器在此测试阶段也将更加重要，因为在此过程中此时将进行更全面的测试。
此处将使用的环境应该与生产中使用的环境几乎相同。安装的所有软件应与生产中的版本相同，硬件本身也应尽可能相似。这将有助于减少与环境本身相关的任何问题的可能性。
性能和浸泡测试
性能测试和浸泡测试都需要在特定环境中进行，这些环境应该再次尽可能地模拟生产环境。虽然性能环境通常是特定的并且有详细记录，但为了确保性能指标有用，它们应该与生产环境中存在的相似，从而使性能指标能够更准确地表示客户可能遇到的情况。
浸泡测试是为了测试典型的生产负载，因此也应该在类似于生产环境的环境中进行测试。环境越接近生产环境，测试结果就越准确。
暂存环境测试
用于在生产系统中安装之前测试发布的暂存环境最好由运营团队管理——该团队将管理生产环境中的安装。通过让运营团队在舞台环境中进行安装，他们可以初步了解安装过程，并在生产环境中安装应用程序之前进行练习。阶段环境可能是 QA 团队必须实际测试某些第三方集成（例如不允许在开发和 QA 环境中进行测试的银行或信贷应用程序）的第一次机会。通过让舞台环境尽可能类似于生产环境（在软件和硬件方面），它允许 QA 团队在实际安装应用程序之前最准确地了解应用程序将如何在生产环境中运行。通过允许操作人员在 dtaging 环境中进行安装，他们有机会在将其用于生产系统之前使用自动化安装，从而允许另一双眼睛在用于关键环境之前检查安装的准确性和质量生产环境。
通过在此环境中进行测试，QA 有最后的机会在将应用程序安装到生产环境之前发现任何问题。这是他们在向客户发布应用程序之前发现错误的最佳机会。因此，至关重要的是该环境尽可能接近生产，以消除在生产中发现与这些环境差异相关的问题的可能性。
生产测试
将应用程序安装到生产环境后，应在此环境中进行测试以确保软件正确运行。如果之前的环境已配置为尽可能类似于生产环境，那么在测试过程中此时应该发现的问题很少。任何问题都更可能与负载或生产中严格可用的其他因素有关（例如与先前环境中不可用的第 3 方系统的链接）。这将有助于 QA 测试缩小任何问题的可能原因，并有望让他们更快地解决任何问题。
通过减少测试环境各个阶段之间的变量，可以更快地发现问题，修复成本更低，然后在应用程序发布到生产版本时找到问题。
安装过程
这个过程的一个重要因素（在前面的部分中没有提到）是确保在各个测试阶段安装的相似性。对所有环境采用单一安装过程可确保安装过程本身在整个过程中得到测试，并进一步确保安装在所有环境中以类似方式完成。
虽然在整个发布过程中每个测试环境都会有某些不同之处，但这些差异应该保持在最低限度。配置信息的差异可以存储在文本文件中，并在安装过程中读取。这确保可以跟踪各种环境的任何差异（通过将它们存储在一个文件中，可以将它们签入您的代码控制系统，从而实现可追溯性）。将这些值存储在文件中还允许可重复性，如果在安装过程中手动修改这些值，则不会出现数据输入问题，只需从配置文件中读取这些值即可。
通过使用自动化安装过程，它提高了安装的可重复性，并确保在整个过程中所有环境都使用相同的过程。它进一步降低了安装过程中出错的可能性。自动化安装可用于发布过程的所有阶段，对其进行多次测试，确保在生产中完成安装时，自动化已经过全面测试。
关键是可重复性——与包含许多需要人工交互的步骤的安装过程相比，自动化过程更容易重复。拥有一个允许您轻松安装和配置您的版本的自动化平台将使团队能够专注于出现的任何问题，而不是安装过程中出现的任何错误。
结论
总之，在与客户将看到的环境相似的环境中测试任何产品时，这一点很重要。当您测试一个复杂的、集成的、基于 Web 的系统时，这可能是一个挑战。例如，如果您的应用程序具有某种类型的银行链接或信用授权，您通常无法在内部 QA 环境中针对实时银行系统测试这些。在到达暂存环境之前，您可能没有机会测试这些链接，并且该测试甚至可能针对基于银行的测试系统，或者它可能使用模拟器。然而，在测试的所有阶段，整个系统尽可能相似仍然很重要。这允许质量保证团队确保将任何与环境相关的问题保持在最低限度，并且正在测试的系统准确地反映了应用程序将在生产环境中运行的内容。
参考：
1) Aliza Earnshaw，“构建持续交付工具箱”； https://puppetlabs.com/blog/build-a-toolbox-for-continuous-delivery