【发布时间】：2018-08-17 13:25:06
【问题描述】：
我正在尝试将测试自动化流程设置为在多个在中间代理上运行的测试环境中执行。见下图
现有的测试自动化流程基于数据驱动的测试，它包含手动测试人员从生产分析中提供的 url（例如错误、新功能等）。
此测试自动化过程可以在各种测试环境（例如预生产和生产）上执行，具体取决于运行时决定的各种因素。
我不想为环境提供一个数据驱动的场景，因为我更愿意避免多个场景维护。也许我正在考虑使用中间代理解决。在我的想法中，这个代理将成为 TA 设置的一部分，并将流量切换到仅用于运行的一个环境。
我正在研究 Squid 作为可能的解决方案，但我不清楚是否：
我的想法可行
Squid 是正确的工具，或者可能有更适合的工具
-
最好有：
- 一个代理实例/环境
- 一个代理实例和 TA 设置会动态更改目标环境。
问候
【问题讨论】：
-
每个被测环境到底有什么不同？只是预生产环境和生产环境之间的 URL 不同吗？还有什么让每个环境都独一无二？
-
这两个环境包含两个不同的功能集。预生产环境包含将要投入生产的构建（例如新功能、错误修复等...）
-
好的，但是测试是否因环境而异？如果不是，是什么让每个环境的测试都是独一无二的？如果预生产环境中有新功能，那么在将其部署到生产环境时，您不想测试这些新功能吗？如果是，那么我不明白为什么您不能只使用一个简单的配置文件来指向用于测试的环境——预生产环境或生产环境。
-
测试用例在两种环境中以相同的方式执行。对于新功能，您是对的，因为最好直接在生产中进行测试。相关的错误修复，测试场景在预生产中运行以确保错误解决，因此在运行时切换环境的可能性很方便。除了带有数据驱动测试的场景文件（由手动测试人员提供）之外，没有配置文件。到目前为止，为了确保测试服务器在正确的环境中执行测试，我们覆盖了 hosts 文件，但我不喜欢这个解决方案。出于这个原因，我正在评估使用代理的替代方案。
-
那么为什么不直接使用指向正确环境的配置文件来进行测试呢？比配置代理简单得多，您可以轻松地更新该配置文件以指向预生产，然后指向生产（假设所有内容都在预生产中传递）。
标签： proxy automated-tests integration-testing http-proxy regression-testing