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