我们正在寻找使用编码的 ui 测试框架编写自动化测试。我们希望单独测试 ui 组件,而不是在单独的进程中启动应用程序。
例如,如果我们在应用程序中有一个弹出对话框来捕获用户的数据,我们希望只启动特定的对话框并验证不同的用例,而不是运行整个应用程序。
我们尝试通过启动对话框作为测试 initialize() 的一部分来进行测试,但它无法找到控件……但如果我单独启动对话框,相同的测试工作正常。
有没有人试过这个或建议让它工作?
我们正在寻找使用编码的 ui 测试框架编写自动化测试。我们希望单独测试 ui 组件,而不是在单独的进程中启动应用程序。
例如,如果我们在应用程序中有一个弹出对话框来捕获用户的数据,我们希望只启动特定的对话框并验证不同的用例,而不是运行整个应用程序。
我们尝试通过启动对话框作为测试 initialize() 的一部分来进行测试,但它无法找到控件……但如果我单独启动对话框,相同的测试工作正常。
有没有人试过这个或建议让它工作?
Coded UI Framework 是一个非常强大的框架,但有很多(我的意思是很多)问题。
我不建议它做你想要完成的事情。
此外,测试“隔离组件”是单元测试,根据我的经验,这根本不是编码 UI 测试的最佳实践。
编码的 UI 测试将帮助您测试端到端的跨应用程序流程,因为它通过按键和鼠标点击模拟用户输入,因此最接近用户。
此外,由于 UI 在开发过程中往往会发生很大变化,而 Coded UI 依赖于此,我建议您主要将它用于您知道不会很快改变的窗口的回归测试。这样,您将保持低维护和高生产力。
希望这可以帮助。
编码 UI 旨在检查应用程序(以及网页)的功能。编码 UI 不用于测试与其应用程序分开的 UI 片段。但是,可以创建一个包含一个或多个 UI 组件的测试工具应用程序,从而使它们能够独立于实际应用程序进行测试。
测试工具可以很容易地为每个被测试的组件提供一个窗口。该窗口将包括正在测试的组件以及一些其他简单的控件。这些简单的控件可以公开被测试组件的内部值,也可以用于将值传递到组件中。
我认为您尝试做的事情是可行的,但仅适用于您自己的自定义控件。我认为你应该按这个顺序解决这个问题。
TestInitialize
以便它使用有用的 ID、名称或标题创建您的控件。(不确定您的控制在哪个技术堆栈中)