生产环境测试策略

Question

在一个理想的世界里，开发人员/操作人员作为一个团队一起工作，把一些东西发布到生产上。

但是，有一些组织是有局限性的，因此发布工程师/团队完全远离开发/项目团队。

这不仅增加了发布的沟通痛苦，而且使生产环境对项目团队几乎“不可见”。在某种程度上，项目和部署团队之间存在“信任危机”。

即使在UAT环境中，我们也有良好和可靠的接受/功能测试，但我们只是不确定部署过程是否已经正确完成，以及在生产上是否一切都与UAT完全一样。因此，我们能够验证这一点的唯一方法是通过一些生产环境的测试。

一些简单的烟雾测试可能有助于识别连接问题。

因此，我的问题是:您对将UAT上的所有测试应用于生产(配置为禁用生产中不希望发生的位元，例如删除数据等)有何看法。

如果您做了类似的事情，那么如何在不受审计跟踪污染的情况下处理生产环境中的数据(显然是基于帐户的，但假设没有按帐户进行隔离)。

编辑:我并不是一直都在测试prod环境，只是在部署之后。此外，我们也不会停止尝试从root - dev/op关系中解决问题。但同时也想探索其他的可能性。

Answer 1

通常，测试是在生产服务器之外执行的，原因有三：

• 安全。如果出了问题，而且所有的数据都被意外地删除了，你就不在乎了。如果它发生在生产中，那就是.比如说很烦人。
• 性能。一套广泛的测试可以很容易地在几台服务器上使用100%的CPU，持续几分钟。你负担不起每小时放慢生产服务器几分钟10次的代价。
• 目标。测试的目标是防止生产中出现问题。如果在应用程序已经部署时发现问题，那就太迟了。此外，回到以前的修订可能会很复杂。例如，如果新版本在数据库中创建了一个列，同时在使用这个新列的地方有了新的记录，怎么办？

出于这些原因，我强烈建议您不要使用生产环境进行测试。此外，我不认为在生产中运行测试并将结果发回您的团队将有助于获得系统管理员的信任；他们可能会认为这是一种尝试性的规避他们设置的限制，以保护他们的基础设施不受您的团队的影响。

相反，要解决最初的问题，即开发人员和系统管理员之间缺乏信任。在此级别上存在通信和信任问题之前，测试和部署过程将是痛苦的，不管您将使用什么技巧来简化测试和部署过程。

Answer 2

只要您已经实现了一个健壮的版本控制系统，您就可以将测试分散开来，这样您就只需要确认基本功能。

例如，在这四种环境(简化为简洁)中完成了以下工作：

• 发展:单元测试，一些行为测试
• FAT:集成测试、回归测试、安装测试
• UAT:部署到现场的测试(可能使用伪数据)
• LIVE:通用功能，可能的环境测试

DEV (发展)环境

重点是单元测试，以测试新功能、bug修复和以前的测试；如果新的/修改的功能需要，可以执行一些行为测试。

FAT (工厂验收测试)环境

您可以测试安装程序，并允许测试人员在应用程序中运行，并测试新函数、错误修复，并通过回归测试确保旧功能不会被打破。

UAT (用户验收测试)环境

您的客户/客户/用户测试您的应用程序，以确保它按照他们的期望工作。值得注意的是，UAT应该与生活相同，所以在这里工作的应该在现场工作。

现场(生产)环境

您只需完成对最新版本的更新，并重新检查基础(烟雾测试)：可以访问数据、打开报告、查看文档、导出/导入数据等。

当软件到达活动环境时，它已经通过了所有以前的环境而没有问题，因此没有必要重新测试；如果任何环境由于任何原因失败，软件版本会返回到DEV，则会进行更改，整个过程将在一个新的发布号(例如1.2.3.0 -> 1.2.3.1 )下再次启动。

您通过遍历每个环境并完成测试来建立对发行版的信任，这样您就不需要在活动中重新测试。