使用功能切换时如何进行测试？您希望您的开发计算机尽可能接近生产。从我观看的视频中，功能切换的实现方式允许某些人使用＆＃34;功能（即0到100％的用户或选定的用户等）。
要正确进行持续集成，在测试时，您是否必须使用与生产服务器相同的功能切换设置？或者更好的是，如果该功能没有在生产中关闭，请确保在构建管道中运行自动化测试时它是否已启用？您是否最终在测试代码中放置功能切换，或者在新文件中编写测试？新功能何时成为系统测试必须进行的过程中的必需步骤？
答案 0 :(得分：4)
在一个由多个人组成的团队中，常规使用功能切换，对所有切换进行组合测试甚至计划测试预期会相互作用的切换组合是不切实际的。测试切换代码的实用策略必须适用于单个切换，而不考虑其他切换的状态。我已经看到以下过程工作得相当好：
因为我们会尽快将所有代码转移到生产环境中，所以当最初将一个切换引入项目时，会编写新的测试以覆盖所有切换的代码并打开切换。因为我们进行了彻底的测试，所以已经存在关闭切换的代码测试;这些测试被更改，以便明确关闭切换。只要有必要，可以在切换后面开发切换代码。
在生产中打开切换之前，所有测试（不仅仅是切换代码的测试，而是应用程序的整个测试套件）都会在切换开启的情况下运行。这可以捕获由于与其他功能无法预见的交互而造成的任何破坏。
生产中的开关已打开
从代码中删除切换（以及仅在切换关闭时处于活动状态的任何代码）并将代码部署到生产
此过程适用于切换仅隐藏全新功能的情况（因此没有代码仅在切换关闭时运行）以及切换在两个或更多版本的代码之间选择的情况，例如分裂测试。
回答几个具体问题：
不同切换状态的测试是在同一文件中还是在不同文件中，取决于切换功能的大小。如果这是一个小改动，最简单的方法是将两个版本保存在同一个文件中。如果它是一个主要功能的完全重写，那么将一个或多个新的测试文件专门用于切换的新状态可能更容易。受切换影响的文件数量也取决于您的测试体系结构。例如，在使用RSpec和Cucumber的Rails项目中，切换可能需要在Cucumber功能（接受/集成测试），路由规范，控制器规格和模型规范中进行新测试，并且再次测试每个级别的切换可能根据切换功能的大小，位于同一文件或不同文件中。
通过“系统测试”我认为你的意思是手动测试。我宁愿没有那些。相反，我自动化所有测试，包括验收测试，所以我上面写的内容适用于所有测试。除此之外，当我们在生产中打开所有测试并且在我们移除切换时永久地执行所有测试时，切换的新状态暂时成为法律。