自动化的用户界面测试是一个即使有经验的开发人员也要警惕的话题。 而且，这种测试的技术并不是什么特别的东西，对于Visual Studio编码的UI测试，它是对内置单元测试系统Visual Studio Team Test的扩展。 在本文中，我将主要讨论UI测试的主题，以及我们在使用PVS-Studio静态分析器时使用Visual Studio编码的UI测试的个人经验。
基础知识
首先，让我们尝试找出为什么UI测试在开发人员中不像传统的单元测试那样受欢迎。
网络上有许多所谓的“测试金字塔”，它们显示了跨应用层的测试数量的最佳推荐分布。 所有金字塔都是相似的，并且包含一个总体思想：尽可能多的测试应尽可能接近代码。 反之亦然。 我将给出其中一个金字塔的示例，其中包含有关测试数量百分比的其他建议。
金字塔的基础是单元测试。 确实，这样的测试在开发阶段更容易进行，并且将很快执行。 另一方面，自动金字塔测试位于金字塔的顶部。 这些测试不应太多，因为它们创建的复杂性以及执行时间都非常大。 另外，不清楚谁委托UI测试的创建。 实际上，从本质上讲，我们正在谈论模拟用户操作。 所有这些都与应用程序代码相去甚远，因此开发人员不愿意进行此类工作。 为了在没有程序员参与（或参与最少）的情况下进行高质量的接口自动化测试，需要使用付费工具。 所有这些因素的结合通常导致UI测试根本不执行这样的事实，从而将其自身限制为对新功能的单个手动测试。 另外，接口测试不仅在开发阶段，而且在进一步的应用程序生命周期中，都是非常昂贵的。 即使用户界面稍有变化，也可能导致许多测试的执行出现错误，并需要对其进行修改。
我注意到，目前，我们的测试系统总体上符合建议。 自动化GUI测试的次数（45）约为PVS-Studio测试总数的十分之一。 同时，单元测试的数量不是很大，但是它们由许多其他测试系统补充：
- 分析器（C / C ++ / C＃/ Java）的性能测试，在此过程中，他们检查不同操作系统（Windows，Linux，macOS）上的大量测试项目，并将新警告的日志与参考警告进行比较；
- 测试特定功能（跟踪编译器的启动等）；
- 命令行应用程序的外部测试；
- 测试正确的组装，安装和部署；
- 文档测试。
在开发的最初阶段，PVS-Studio分析仪是用于在将C / C ++代码移植到64位平台时发现错误的应用程序。 是的，当时他以另一种方式被称为“ Viva64”。 该产品的历史可以在文章“
PVS-Studio项目如何十年前开始 ”中找到。 集成到Visual Studio 2005中之后，分析仪获得了图形用户界面，本质上是Visual Studio IDE本身的界面，在安装插件后，其中出现了一个用于访问分析仪功能的附加菜单。 菜单有两个或三个项目，因此没有要测试的地方。 那时的Visual Studio不包含任何用于测试GUI的内置工具。
Visual Studio编码的UI测试和替代方法
随着Visual Studio 2010的发布，一切都发生了变化，该版本引入了用于创建UI测试的集成系统：Visual Studio编码的UI测试（CUIT）。 CUIT基于Visual Studio Team Test单元测试系统，最初使用Microsoft Active Accessibility（MSAA）技术来访问可视界面元素。 将来，技术会得到改进，目前它是用于测试UIA代码（UI自动化）的用户界面自动化的开发模型。 它允许测试系统访问COM和.NET UI元素的开放字段（对象名称，对象的内部类名称，对象的当前状态，其在接口的层次结构中的位置等），并且系统允许您模拟对这些元素的影响通过标准输入设备（鼠标，键盘）。 开箱即用，支持用于记录与界面交互时用户动作的模式（类似于Visual Studio宏），自动构建“界面映射”（控件的属性，搜索参数和对其的访问）以及自动生成控件代码的模式。 将来，所有积累的信息很容易修改和维护，并且可以按需定制测试序列，同时只需很少的编程技能即可。
而且，正如我之前所说，现在，当您创建复杂的智能UI测试时，只要您使用专门的付费工具，就可以完全不需要任何编程技能。 好吧，如果没有使用专有测试环境的愿望或能力，那么有很多免费的产品和框架。 Visual Studio编码的UI测试系统是一个中间解决方案，它不仅允许尽可能自动地创建UI测试的过程。 有了它的帮助，很容易用C＃或VB编程语言创建任意测试序列。
所有这些都可以大大降低创建和维护GUI测试的相关性的成本。 所使用的框架易于理解，通常可以以图表的形式表示。
在关键元素中，应注意所谓的“接口适配器”，它们处于最低的抽象级别。 该层与用户界面的有限元素进行交互，并且可以使用其他适配器来扩展其功能。 上一层是对其余代码隐藏GUI访问技术的层，包括程序访问接口和实际的测试应用程序代码，其中包括用于测试自动化的所有必需元素。 该技术是可扩展的，可以在框架的框架内为每个级别补充必要的元素。
Microsoft CUIT的主要功能包括：
- 用户界面的功能测试。 支持基于Windows的经典应用程序，Web应用程序和服务，WPF
- VB / C＃中的代码生成（包括自动）
- 能够集成到组装过程中
- 本地或远程启动，报告收集
- 记录和再现测试序列的可用性
- 良好的扩展性
尽管CUIT有许多困难，但出于多种原因，还是首选使用此测试技术：
- 使用一种工具和编程语言进行开发人员和测试人员的有效交互
- 与“接口卡”一起使用的其他功能，可以“实时”识别控件，同步元素并完成测试序列
- 微调回放机制，它允许与基本设置（例如操作之间的延迟，元素搜索超时等）一起在代码中使用专门的机制。 例如，使用带有WaitForReadyLevel枚举的WaitForControlExist或WaitForReady方法 ，锁定当前线程，直到激活（可视化）控件为止。
- 能够编写无限复杂的测试
我不会进一步研究Visual Studio Coded UI Tests技术的理论方面，所有这些都在相关文档中进行了详细介绍。 您可以在此处找到详细的分步说明，以基于该系统创建最简单的UI测试。 是的，该系统不是免费的，您将需要Visual Studio Enterprise才能使用它。
所描述的技术不是市场上唯一的技术。 还有许多其他解决方案。 所有其他UI测试系统都可以分为付费和免费。 而且，特定系统的选择并不总是取决于其价格。 例如，无需编程就可以创建测试的能力可能是一个重要因素，但同时，测试可能不够灵活。 支持必要的测试环境-操作系统和应用程序也很重要。 最后，应用程序及其接口的纯粹特定功能可能会影响选择。 以下是一些用于测试GUI的流行系统和技术。
付费 ：
TestComplete （SmartBear），
统一功能测试 （Micro Focus），Squis（froglogic），
自动化测试工具 （Ranorex），
茄子功能 （eggplant）等。
免费 ：
AutoIt （Windows），
Selenium （网络），
Katalon Studio （网络，移动），
Sahi （网络），
Robot Framework （网络），
LDTP （Linux桌面测试项目），开放源代码框架：
TestStack.White +
UIAutomationVerify ，。 NET Windows自动化库等
当然，这个清单并不完整。 但是，很明显，自由系统通常专注于特定的操作系统或测试技术。 一般规则是，在付费系统中，您会发现更快的东西可以满足您的特定需求，测试的开发和维护将更加容易，并且受支持的测试环境的列表非常详尽。
在我们的案例中，没有选择问题：随着Visual Studio 2010的发布以及编码UI测试的添加，可以轻松地向我们的测试环境中添加一组功能测试，以测试用于Visual Studio的PVS-Studio插件的用户界面。
PVS-Studio UI测试
因此，我们公司的GUI测试已经使用了6年以上。 Visual Studio 2010的最初UI测试集基于当时唯一可用的MSAA（Microsoft Active Accessibility）技术。 随着Visual Studio 2012的发布，MSAA技术得到了长足的发展，现在被称为UIA（UI自动化）。 决定继续使用UIA，并保留基于MSAA的测试来测试Visual Studio 2010的插件（我们从Visual Studio 2010开始支持和测试所有版本的Visual Studio的插件）。
结果，我们形成了两个UI测试“分支”。 此外，在测试项目中，这两个分支都使用了公共接口映射和共享代码。 在代码中，它看起来像这样（在运行测试之前将Visual Studio设置重置为标准方法）：
public void ResetVSSettings(TestingMode mode) { .... #region MSAA Mode if (mode == TestingMode.MSAA) { .... return; } #endregion
更改插件界面时，必须更改UI测试的两个分支，并且添加新功能使得有必要复制映射中的界面元素：即为MSAA和UIA技术中的每一个创建两个不同的元素。 所有这些不仅需要大量的努力来创建或修改测试，而且还需要使测试环境保持稳定状态。 我将在这方面更详细地介绍。
根据我的观察，测试GUI时测试环境的稳定性是一个重大问题。 这主要是由于此类测试对许多外部因素的强烈依赖。 实际上，实际上，用户的行为是模拟的：按下键，移动鼠标光标，单击鼠标等。 有很多事情可能会“出错”。 例如，如果在测试过程中有人与连接到测试服务器的键盘进行交互。 另外，出乎意料的是，监视器的分辨率可能不足以显示任何控件，并且测试环境将找不到它。
等待中：
现实情况：
粗心调整（以后找不到）的界面映射元素实际上是问题行为的领导者。 例如，在创建新控件时，Visual Studio编码的UI测试界面映射向导会为其使用默认的“等于”搜索条件。 即，要求属性名称与指定值精确匹配。 这通常是可行的，但有时可以通过使用不太严格的搜索条件“包含”而不是“等于”来显着提高测试执行的稳定性。 这只是在进行UI测试时可能遇到的“调整”的一个示例。
最后，您的某些测试可能包括执行操作并进一步等待结果，例如，与显示窗口相关联。 在这种情况下，关于搜索元素的问题，将添加设置播放延迟直到窗口出现然后同步作品的问题。 这些问题中的一些可以通过标准框架方法（
WaitForControlExist等）解决，而其他问题则需要发明巧妙的算法。
在进行插件测试之一时，我们遇到了类似的问题。 在此测试中，首先打开一个空的Visual Studio环境，然后将某个测试解决方案加载到该环境中，并使用PVS-Studio（菜单“ PVS-Studio”->“检查”->“解决方案”）进行了全面测试。 问题在于确定何时完成验证。 根据许多条件，检查可能不会总是花费相同的时间，因此简单的超时在这里不起作用。 同样，您不能使用标准机制来挂起测试流并等待任何控件的出现（或隐藏），因为没有任何附加条件。 在检查过程中，将显示一个具有工作状态的窗口，但此窗口可以隐藏，并且检查将继续。 即 该窗口无法引导（此外，其设置为“分析完成后不关闭”）。 我想使该算法更通用，以便将其用于与检查项目和等待该过程完成有关的各种测试。 找到了解决方案。 在开始测试并完成之前，菜单项“ PVS-Studio”->“检查”->“解决方案”处于禁用状态。 我们只需要在一定时间间隔（通过界面映射对象）检查此菜单项的“ Enabled”属性，并且，如果发现该元素已变为活动状态，则认为决策验证过程已完成。
因此，就UI测试而言，仅创建测试是不够的。 在每种情况下都需要进行细微的调整。 有必要了解并同步执行的整个动作序列。 例如，在屏幕上显示此菜单之前，将找不到上下文菜单项。 还需要仔细准备测试环境。 在这种情况下，您可以依靠测试的稳定运行和足够的结果。
让我提醒您，我们公司自2010年以来一直在开发UI测试系统。 在这段时间内，创建了几十个测试序列，并编写了许多辅助代码。 随着时间的推移，独立的应用程序测试已添加到插件测试中。 此时，用于Visual Studio 2010的旧的插件测试分支已经失去了相关性并被放弃了，但是根本不可能从项目中删除此“死”代码。 首先，正如我前面所展示的那样，代码已非常深入地集成到测试方法中。 其次，现有接口卡的一半以上元素属于旧的MSAA技术，但在许多新测试中与UIA元素一起被重用（而不是重复）（由于技术的连续性，这是可能的）。 同时，大量自动生成的代码和测试方法的内容都与“旧”元素联系在一起。
到2017年秋季，需要改进UI测试系统。 通常，这些测试工作正常，但有时由于未知原因某些测试“崩溃”。 更准确地说，原因通常是找到一个控件。 在每种情况下，我都必须遍历界面映射树以找到特定元素，并检查其搜索条件和其他设置。 有时，对这些设置进行软件重置有助于运行测试。 考虑到接口卡已经（在许多方面，从许多方面来看）已经增长了接口映射，并且存在“死”代码，此过程需要大量的工作。
一段时间以来，任务“一直在等待英雄”，直到最终出现在我眼前。
我不会给您带来细微差别的描述。 我只能说这项工作并不困难，但需要相当的毅力和关注。 一切都花了我大约两个星期的时间。 我花了一半的时间重构代码和接口卡。 在剩余的时间里，他从事稳定测试执行的工作，该工作基本上归结为对视觉元素的搜索标准（编辑界面图）进行更精细的调整，以及对代码进行一些优化。
结果，我们设法将测试方法的代码大小减少了约30％，并且接口映射树中的控件数量减少了一半。 但最重要的是，UI测试开始显示出更稳定的性能，并且需要更少的关注。 由于对分析仪功能进行更改或检测到不一致（错误）的原因，坠落现象开始更加频繁。 实际上，出于这些目的，我们需要一个UI测试系统。
因此，目前，PVS-Studio界面的自动测试系统具有以下基本特征：
- Visual Studio编码的UI测试
- 45个场景
- 4,095行代码用于测试方法
- 19,889行自动生成的代码（不包括用于存储UI Map设置的xml文件的大小）
- 1小时34分钟的执行时间（根据最近30次启动的结果得出的平均值）
- 在专用服务器上运行（运行MSTest.exe实用工具）
- 绩效监控和绩效报告分析（Jenkins）
结论
最后，我想给出一个自动GUI测试成功标准的列表，该标准基于对我们在该技术上的经验的分析（一些标准适用于其他测试技术，例如单元测试）。
合适的工具 。 根据应用程序的功能以及测试环境，选择用于创建和执行CUIT的环境。 付费解决方案并非总是有意义，但是通常它们可以非常有效地帮助解决问题。
高质量的基础架构设置 。 开发接口卡时不要保存。 通过仔细描述元素的所有属性并设置智能搜索条件来简化搜索元素时的框架工作。 注意进一步修改的可能性。
减少体力劳动 。 如有可能，请确保使用自动方式生成代码和记录序列。 因此，您将大大加快开发速度并最大程度地减少出错的可能性（很难找到导致UI测试崩溃的原因，尤其是在使用框架的代码中出错的情况下）。
简单而独立的智能测试 。 测试越简单越好。 尝试做一个单独的测试来测试特定的控件或模拟的情况。 还应确保测试相互独立。 其中一项测试的失败不应影响整个过程。
友好的名字 。 在类似测试的名称中使用前缀。 许多环境允许您通过按名称过滤来运行测试。 也请尽可能使用测试分组。
孤立的运行时 。 确保测试在专用服务器上运行，并且对外部的影响最小。 断开所有外部用户输入设备的连接，为您的应用程序提供必要的屏幕分辨率，或者使用模拟高分辨率显示器连接的硬件虚拟设备。 确保在测试运行期间，其他与桌面和显示消息交互的应用程序没有运行。 还必须计划开始时间并考虑最大测试持续时间。
分析已发表的报告 。 提供简单明了的表单来报告进度。 使用持续集成系统来调度测试，以及快速获取和分析测试结果。
如果您想与讲英语的读者分享这篇文章，请使用以下链接：Sergey Khrenov。
Visual Studio编码的UI测试：理论和我们公司的用户体验