4

使用功能切换时如何进行测试？您希望您的开发计算机尽可能接近生产。从我观看的视频来看，功能切换的实现方式允许某些人“使用”该功能（即 0 到 100% 的用户，或选定的用户等）。

为了正确地进行持续集成，在测试时您是否必须使用与生产服务器相同的功能切换设置？或者更好的是，如果该功能在生产中没有关闭，那么在构建管道中运行自动化测试时确保它处于打开状态？您最终是在测试代码中放置功能切换，还是在新文件中编写测试？新功能何时是系统测试必须执行的过程中的强制性步骤？

4

1 回答 1

6

在一个经常使用功能切换的多人团队中，对所有切换进行组合测试，甚至计划对预期交互的切换组合进行测试是不切实际的。测试切换代码的​​实用策略必须适用于单个切换，而不考虑其他切换的状态。我已经看到以下过程运行良好：

  • 因为我们会尽快将所有代码转移到生产环境中，所以当最初将切换引入项目时，会编写新的测试以覆盖所有切换代码并打开切换。因为我们进行了彻底的测试，所以已经存在对关闭切换代码的​​测试；这些测试已更改，因此切换显式关闭。只要需要，可以在切换后开发切换代码。

  • 在生产中打开切换之前，所有测试（不仅仅是切换代码的​​测试，而是应用程序的整个测试套件）都在切换打开的情况下运行。这可以捕获由于与其他功能不可预见的交互而导致的任何破损。

  • 切换在生产中打开

  • 从代码中删除切换（以及仅在切换关闭时才处于活动状态的任何代码）并将代码部署到生产环境

此过程适用于切换仅隐藏全新功能的情况（因此没有代码仅在切换关闭时运行）以及切换在两个或多个代码版本之间进行选择的情况，例如拆分测试.

回答您的几个具体问题：

  • 不同切换状态的测试是放在同一个文件还是不同的文件中，取决于切换功能的大小。如果是很小的更改，最简单的方法是将两个版本保存在同一个文件中。如果它是对主要功能的完全重写，那么拥有一个或多个新的测试文件可能更容易专门用于切换的新状态。受切换影响的文件数量还取决于您的测试架构。例如，在使用 RSpec 和 Cucumber 的 Rails 项目中，切换可能需要在 Cucumber 特性（验收/集成测试）、路由规范、控制器规范和模型规范中进行新的测试，并且同样，每个级别的切换测试可能根据切换功能的大小，位于同一文件或不同文件中。

  • 我认为“系统测试”是指手动测试。我宁愿没有那些。相反，我自动化了所有测试，包括验收测试，所以我上面写的适用于所有测试。撇开这一点不谈，当我们在生产中打开切换开关之前运行所有测试时，切换开关的新状态暂时成为法律，然后在我们移除切换开关时永久生效。

于 2016-02-01T13:29:02.103 回答