在多个环境中测试相同的测试用例

Question

目前我们已经在一个环境（开发）中设置了我们的 UI 测试自动化。我们正在使用 C#、.Net、Visual Studio、specflow 和 MSTest

配置

我们读取了一个app.config 文件以获取特定于环境的变量。我们使用 Azure Pipeline for CI 并在每晚构建中运行这些测试。

<configuration>
    <appSettings>
        <add key="DevApp" value="https://dev.websitename.com />
    </appSettings>
    <connectionStrings>
        <add name="DevDatabase" connectionString="http://dev.url/" />
    </connectionStrings>
</configuration>

现在我们也想在我们的 UAT 环境中运行这些测试。设置将是相同的，我们希望使用相同的数据运行相同的测试。唯一的区别是，对于 UAT，我们将指向不同的 URL 和不同的数据库。

例如

Dev env = https://dev.websitename.com
UAT env = https://uat.websitename.com

server name="DevDatabase" connectionString="http://dev.url/"
server name="UATDatabase" connectionString="http://uat.url/"

密码

在密码方面，out 应用程序是一个内部应用程序，我们使用 windows auth。因此，在我们的 dev 和 uat 环境中，我们为所有用户设置了相同的密码。所以在 Dev = devpassword 和 UAT = uatpassword

对于开发和测试，我们使用相同的用户，密码是唯一的区别。在测试时，我们使用模拟启动浏览器，并以该用户的“运行身份”启动浏览器

var service = ChromeDriverService.CreateDefaultService(driverpath)

如果用户不为空，那么我们这样做

var pwd = new SecureString()

service.StartDomain = Configurationhelper.Domain
service.StartupUserName = username
service.StartupPassword= = pwd
service.StartupLoadUserProfile = true

我们将域和密码以及其他环境变量作为常量存储在单独的配置文件中。

**主要问题：** 这现在不起作用，所以我认为最好将密码作为机密存储在 AZURE 管道变量中？如果是这样，我将如何更改此代码？例如

服务器团队、数据库团队和 devops 团队负责服务器、数据库设置和 url 等

所以对我来说，它只是通过我对配置的更改来配置测试自动化存储库

有什么优雅的方法可以做到这一点？

天蓝色管道

我们如何同时为这两种环境运行测试？并行我的意思是让两者都在夜间运行。我们的 Azure 管道有 2 个独立的客户端 UAT 和 DEV 指向同一个工件。两种环境的任务和变量是相同的，但显然具有不同的值

目前它们都将单独运行

Answer 1

此问题的解决方案归结为上下文（在您的情况下是环境及其所有关联的连接字符串和 URL）如何到达将要使用它们的测试。在您的问题中，您陈述了几个正交的问题：

• 使用相同的数据
• 在不同的环境中运行
• 并行运行

未提及是另一个问题

• 如何处理机密信息（例如连接字符串中的密码）

我将解释一个解决这些问题的解决方案（实际上是一种策略），以及为什么它看起来是一个可维护和可扩展的解决方案。

使用相同的数据

这可以很简单也可以很复杂。简单的解决方案是创建一个包含规范和代表性测试数据的数据库，然后将该数据库交换到您的环境中。这可以通过数据库的备份/恢复或以编程方式创建数据来完成。无论测试成功还是失败，您都需要有一种机制来恢复或擦除数据。

“按原样”使用环境的数据库很少会导致可靠的测试；测试经常修改状态，而数据库是状态的最终形式；状态的突变会影响未来的测试。

正是这最后一句话，每次测试之前/之后发生的完全交换可能a）更快（发生在具有更快交换功能的批量/宏观级别），b）更易于维护（可以查看数据/提前创建）和c）不那么脆弱。

在不同的环境中运行

就像您讨论的问题的核心一样，这就是您归结为使用多个文件还是单个文件的地方。使用多个文件意味着您可以利用一些允许您指定环境的内置 .NET 配置机制。这意味着复制文件并更改值以反映环境。

您提到的另一种方法是将所有这些信息存储到一个配置文件中。如果您这样做，您需要某种鉴别器来消除条目的歧义，并且您的测试需要能够将环境名称传递给某个 API 以提取值。我个人更喜欢这种机制，因为当您添加新功能/测试时，您可以将所有配置添加到一个地方。

所以这两种机制在工作方面大致相同，除了后者在添加新配置时会导致更紧凑的编辑会话，并且从可读性/可维护性场景来看，您可以查看的地方更少。

秘密

如果您遵循单一来源的配置方法，您只需将其扩展到您的机密，但您选择适当的机密存储（例如机密文件或 Azure Key Vault，或类似的……再次使用环境 -基于鉴别器）。这是一个例子：

{
   "DEV.Some.Key" : "http://devhost/some/path",
   "UAT.Some.Key" : "https://uathost/some/other/path"
   ...
}

使用鉴别器意味着对 DevOps 管道的更改远少，也就是说，从开发人员/编辑经验来看，这很可能比编辑文件或密钥库更慢且更麻烦。

并行运行

虽然您可以轮换上下文并设计解决方案以使用 MSTest 机制并行运行，但将其分配给您的管道本身会更优雅，并且有足够的资源能够并行运行这些管道有足够的构建代理等等。

结论

归结为解决方案的哪些部分应由哪些资源解决。上面的解决方案将环境选择和测试执行分配给管道本身。将连接字符串和机密等细粒度值分配给单个源，以减少在必须编辑这些值时发生的摩擦。

遵循此策略也可能更好地利用您团队的技能。拥有 DevOps 思维方式的人很可能比开发人员思维方式更容易构建新环境并进行并行化，后者更清楚需要设置哪些数据以及如何制作测试。