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

Question

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

配置

我们读取了一个app.config文件以获取特定于环境的变量。 我们使用 Azure 管道进行 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)

如果用户不是 null 那么我们这样做

var pwd = new SecureString()

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

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

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

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

所以对我来说，它只是用我对配置的更改来配置测试自动化回购

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

AZURE 管道

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

目前他们都将孤立运行

Answer 1

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

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

未提及是另一个问题

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

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

使用相同的数据

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

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

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

在不同的环境中运行

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

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

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

秘密

如果您遵循单一来源的配置方法，您只需将其扩展到您的秘密，但您 select 适当的秘密存储（例如秘密文件或 Azure 密钥库，或一些这样的......再次使用基于环境的鉴别器） . 这是一个例子：

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

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

并行运行

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

结论

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

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