【问题标题】:Coded UI Test to test UI components in isolation编码 UI 测试以单独测试 UI 组件
【发布时间】:2023-03-23 17:02:01
【问题描述】:

我们希望使用编码的 ui 测试框架编写自动化测试。我们希望单独测试 ui 组件,而不是在单独的进程中启动应用程序。

例如,如果我们在应用程序中有一个弹出对话框来捕获用户的数据,我们希望只启动特定的对话框并验证不同的用例,而不是运行整个应用程序。

我们尝试通过启动对话框作为测试 initialize() 的一部分进行测试,但它无法找到控件...但如果我单独启动对话框,相同的测试工作正常。

有没有人尝试过这个或建议让它工作?

【问题讨论】:

  • 听起来你想要实现的是通过 GUI 进行单元测试,而这并不是 Coded UI 测试框架的全部意义所在。

标签: c# coded-ui-tests gui-test-framework


【解决方案1】:

Coded UI Framework 是一个非常强大的框架,但有很多(我的意思是很多)问题。

我不建议它做你想要完成的事情。

此外,测试“独立组件”是单元测试,根据我的经验,这根本不是编码 UI 测试的最佳实践。

编码的 UI 测试将帮助您从头到尾测试跨应用程序流程,因为它通过按键和鼠标点击模拟用户输入,因此最接近用户。

另外,由于 UI 在开发过程中往往会发生很大变化,而 Coded UI 依赖于此,我建议您主要将它用于您知道不会很快改变的窗口的回归测试。 这样,您将保持低维护和高生产力。

希望这会有所帮助。

【讨论】:

    【解决方案2】:

    编码 UI 旨在检查应用程序(以及网页)的功能。编码 UI 不用于测试与其应用程序分开的 UI 片段。但是,可以创建一个包含一个或多个 UI 组件的测试工具应用程序,以便在与实际应用程序隔离的情况下对其进行测试。

    测试工具可以很容易地为每个被测试的组件提供一个窗口。该窗口将包括正在测试的组件以及一些其他简单的控件。这些简单的控件可以暴露被测试组件的内部值,也可以用来将值传递给组件。

    【讨论】:

      【解决方案3】:

      我认为您尝试做的事情是可行的,但是适用于您自己的自定义控件。我认为你应该按这个顺序解决这个问题。

      1. VS 的第二个实例,用于在您的测试生成您的控件时捕获它实际看到的关于您的控件的内容。
      2. 更新您的搜索条件,例如进程名称,窗口标题
      3. 可能会向您的TestInitialize spawner 添加属性,以便它使用有用的ID、名称或标题创建您的控件。 (不确定您的控制在哪个技术栈中)
      4. 再次运行测试

      【讨论】:

        猜你喜欢
        • 2015-07-08
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2011-07-07
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多