你好，我叫阿列克谢，是一名C#开发者。有一天我面前有一个任务，需要编写一个用于与Windows和所有主流浏览器中的各种UI元素交互的工具。这个工具本身并不涉及测试，但非常适合用于自动化机器上的某些操作，因为它易于管理和直观。我喜欢在这个方向上工作，并萌生了创建一个工具的想法，它不会像RPA解决方案那样功能繁重，但会借鉴它们所有对界面测试有用的部分，以成为一个真正对入门级QA人员有用的助手工具。我把它命名为RTHelper。
我想在这篇文章中讲几个事情：
如何将界面元素转化为我们之后能明确找到的结构
如何影响这些元素，而不使用常规的输入方式
如何构建稳定的UI操作链，即使元素移动了或加载时间超过3秒也不会崩溃
如果界面不稳定，我们需要获取这些变化的详细报告
而且，我当然会向测试人员以及所有与使用计算机进行重复性工作有关的人员展示我希望他们使用的工具
引言
在UI测试中存在一个令人不快的中间地带，介于手动检查和完全自动化之间。手动操作既耗时又枯燥，而完全自动化仍然需要代码、时间和维护。特别是在回归测试中，需要重复执行典型操作：打开窗口、点击按钮、输入数据、检查文本、获取结果。我正是想填补这个空白：开发一个无需代码即可收集和回放UI场景的工具，但同时又不会变成沉重的RPA系统。与由AI控制的Playwright等框架相比，一个配备完整工具集的可视化构建器，在场景或界面复杂、需要维护算法时，应该更方便，尤其是在需要修改和测试定位器时。
我的道路始于创建一个能够简单从不同应用程序中收集元素树并显示其属性的实用工具。对于Windows，这样的工具有很多，通过它们我了解到我们能从元素中获得哪些信息以及如何获取这些信息。对于浏览器来说，情况稍微复杂一些，我尝试了几个选项，最终选择了编写自己的扩展，但那之后再谈。
接下来，在扩展功能时，我在我的工具中添加了与保存元素交互的功能：点击、滚动、拖放，任何事……此外，还处理应用程序本身的实体：带参数启动、最小化、键盘输入模拟……
本身这样的程序不会给我们带来任何东西，除了按钮的代理点击和查看这些按钮属性列表（类、ID、坐标等）的机会，但如果稍微思考一下，我们就获得了管理计算机的良好基础，特别是测试的界面。为了让解决方案达到稍微认真一些的水平，我还需要一些东西：
算法播放器，由“元素+动作”类型的步骤组成
用于稳定算法的操作集（等待，截图检查等）
用于分析启动结果的工具，提供详细报告
当然还有相应的界面，包含参数编辑器、算法树等
显然这不足以舒适使用，更不用说“低门槛”了，但这却是必须构建的基础。随着时间的推移，这些功能逐渐增加了大量用于快速和简单开发算法的功能和特性，这些算法有助于在创建自动化测试时遵循良好的实践。但首先更令人感兴趣的是介绍程序的核心，具体来说是用于与UI元素交互的库是如何工作的。
从内部处理UI元素
我决定从简单的开始，实现两种UI工作模式：windows和web。其他平台目前还在发展计划中，至于这些平台，我决定采用以下方法：
对于windows- UIAutomation，可以认为是微软用于与UI交互的目标API，是MSAA的继承者
对于网页 - 经过多次尝试和错误，我决定自己编写一个浏览器扩展，以便完全掌控网页界面
这两个选择都受到以下要求的制约：
元素可执行操作的最大范围，就像在大型的RPA解决方案中一样
能够抓取鼠标下方的元素并获取其标准描述符，通过该描述符我们可以快速且唯一地找到它
能够根据用户指定的属性集来查找元素
对应用程序本身的控制功能：启动、调整大小、切换标签、关闭等
当然还有可靠性和稳定性，因为测试脚本不应该因为工具本身的问题而崩溃
使用UIAutomation（UIA模式）
UIAutomation 是构建 Windows 自动化 UI 领域几乎所有解决方案和框架的基础库。文档丰富，使用起来并不困难，尤其是如果你深入了解如何构建和遍历界面元素树，但也不应期望它能施展魔法。我们不能排除以下复杂性：
元素缺乏可靠的标识属性
存在大量具有相同属性的元素
单个应用程序拥有多个具有相同属性和进程名称的窗口
过时的界面（例如在c++/delphi上），其中界面有时构建得完全不可预测
界面中元素根本不存在/未加载
遗憾的是，尽管我尽可能想让一切对用户来说都神奇地工作，但在列举的情况下，可靠性和稳定性方面的责任在于用户。但我可以提供一些解决方案和实际操作方法来处理这些问题：
为元素使用搜索区域（先寻找一个稳定的元素，然后在其子元素中搜索）
有时可以使用MatchIndex/MatchReverse（在合适的范围内按索引搜索)
使用截图测试，特别是可以记录元素本身的基准截图，并仅比较它
使用智能元素等待，wait（我们尝试在屏幕上找到元素，直到超时）
锚定到相邻或相关元素并从它们出发操作（在极端情况下可以通过编程移动光标或点击坐标）
不要忘记程序中的快捷键并通过它们进行交互（在我的实现中为此提供了SendKeys）
在网页模式下可以直接在页面中执行JS脚本，对于Windows程序如果存在这样的可能性则通过API进行操作
为了方便应用上述所有内容，我编写了一个用于与 UI 交互的库，它最大限度地抽象了我们对元素数据的直接操作，并将算法简化为大约如下代码：
隐藏文本
service.Wait(element_attributes);
var webElement = service.Find<WebElement>(element_attributes);
webElement.Click();我希望在单独一篇文章中描述更低层次上交互的机制，那里有许多自己的细节，同时我也想展示如何通过Win32 API控制界面.
浏览器（Web模式）
我最初以为可以不用费心，使用像Selenium这样的框架，因为实际上它实现了我上面描述的方法：代码将内部界面操作和属性及搜索的麻烦隐藏起来，让程序员不用操心。
刚一接触到现实，就明白自己能力不足，一切都归结于调用脚本，无法（至少在当时）处理窗口、标签页等。我转向了更底层的方案：使用native messaging编写了自己的浏览器扩展——当需要在桌面应用和扩展之间交换消息时，这被认为是目标解决方案，关于这一点我还有单独的说明。文章 附带设置指南.
但是这也不适合我，所以我转向了WebSockets，因为原生消息传递的想法不适合我，并且导致工作不稳定。主要原因：通过控制台通信和在发行版中携带多余的exe，这需要额外的环境配置。所以我不认为通过localhost上的WS交换数据有什么不好，尤其是我们能够轻松地遵循自己的清晰DTO，并且拥有对浏览器中所有操作的完全访问权限。
整体获取元素的逻辑变成以下操作链：给用户提供已启动应用列表 -> 用户选择需要的来缩小上下文 -> 用户点击"捕获元素" -> 用鼠标选择元素 -> 根据坐标获取具有完整元素描述的实体 ->> 解析它并返回给界面。反向操作：用户选择从元素 "input" 读取文本 ->> 获取我们保存的描述符 ->> 根据描述符的属性查找元素 ->> 执行操作，返回结果.
搜索元素的细节
在元素被捕获的瞬间，它存在于特定的进程、窗口、标签页或DOM树中。但一分钟后，应用可能被重启，页面可能被刷新，窗口可能被移动，而内存中的对象本身已经不同。因此，我们需要的不只是一个“按钮的指针”，而是一组特征，通过这些特征可以重新找到这个按钮。在代码中，这样一组特征会转化为元素的描述符，简化来说就是：
隐藏文本
public class ElementDescriptor
{
public string Name { get; set; }
public CaptureType CaptureType { get; set; }
public string? ElementType { get; set; }
public List<Property> Properties { get; set; }
public SearchScopeDescriptor? SearchScope { get; set; }
}有些属性仅用于信息，另一些则过于多变，还有一些则非常适合用于搜索。例如，在win模式下可以获取AutomationId、Name、ClassName、ControlType、元素位置、可用状态、父窗口和进程数据。在理想世界中，仅搜索功能就足够了AutomationId，因为这是一个稳定的技朧标识符。实际上它经常是空的，重复出现，或者在一些老旧和自定义的界面上不存在。这时就需要组合多个特征：控件类型、名称、父窗口，有时还需要相邻或父级元素。
在Web模式下情况类似，只是我们有DOM，在捕获元素时可以收集它的id、name、class。tag，type，role，文本，属性集aria-*，XPath，CSS类似特征，树中的位置和其他属性。但这里也没有一个完美的答案。id可能由框架生成，类可以是哈希值，文本可能取决于区域设置或测试数据，而XPath可能在布局的微小更改后失效。
因此我会将属性分为几组：
稳定的特征：
AutomationId、id、role、ControlType、tag、：按钮文本、字段标签、
Name上下文特征：窗口，进程，标签页，父容器，表单，表格
：结构特征：XPath，在相似元素中的位置，匹配索引
：辅助特征：坐标，尺寸，可见状态，启用/禁用
前三个组表现最好。结构特征在没有其他选项时有用，而坐标和尺寸我根本不把它们作为搜索的基础：它们只适用于回退场景.
为了让用户不独自面对这些问题，我添加了帮助使搜索更稳定的工具：
在搜索过程中，会采用两阶段方法：首先获取用户标记为重要的所有属性，并尝试生成候选列表，然后，如果候选项有多个，会应用额外的筛选条件：正则表达式、通配符比较、父项限制、搜索范围、匹配索引。
当剩余几个相似的元素时，可以使用
MatchIndex。MatchReverse：在找到的元素中选择第一个、第二个或最后一个。这是一个有用的机制，但我认为它是妥协，因为如果表格中的行顺序取决于排序或数据，那么索引很容易成为导致崩溃的原因。建议积极使用高亮显示找到的元素：设置属性后可以检查程序认为合适的元素是什么。如果高亮显示了五个相似的按钮——定位器太宽泛了，而如果没有任何东西被高亮显示——我们选择的特征太严格了，或者元素还没有出现。
有时需要限制搜索范围：先锚定在模态窗口、表格或表单上，再在里面搜索按钮、字段或行。在界面中，这需要两次点击和一次拖动。
管理元素时的细节
元素找到后情况同样不简单："点击"有多种方式，而通过键盘输入文本和直接设置值并不相同。按钮点击、文本输入、从列表中选择值或读取状态根据是Web还是Windows、我们面对的是哪种类型控件以及它支持哪些功能，可以以不同方式执行。
我试图在库中将这统一为一种模型：元素有类型，而类型有一组可用的操作。例如，按钮能被点击，文本框能接收文本并返回值，复选框能切换，表格能返回单元格或行，窗口能激活、关闭或改变大小。这种抽象使得在场景的步骤级别看起来大致如下：
隐藏的文本
public class Step
{
public ElementDescriptor Element { get; set; }
public string TypeName { get; set; }
public string ActionName { get; set; }
public List<MethodParameter> Parameters { get; set; }
public int AutoWaitMs { get; set; }
public AutoWaitOptions AutoWaitOptions { get; set; }
public string ResultVariable { get; set; }
}在 win-模式下部分操作可以通过 UIAutomation 模式执行：例如，InvokePattern对于按钮，ValuePattern对于输入字段，SelectionItemPattern 用于列表项。如果按钮移动了 20 像素，逻辑点击仍然应该生效，但 UIA 模式并不总是可用。有些控件没有实现所需的模式，有些返回奇怪的状态，还有些旧界面根本无法与 UIAutomation 一起工作。因此，我们需要备用方案：Win32 调用、SendKeys、有时是坐标操作，但我尽量将这视为回退方案，而不是主要的管理方式。
在Web模式下逻辑类似。如果需要点击按钮，可以触发DOM事件或使用浏览器API。如果需要向input写入值，仅改变value是不够的：现代前端框架通常等待事件链input、change，有时blur。因此，操作不仅要改变元素属性，还要让页面将此变化视为用户输入。
在执行命令前，最好确认元素确实准备好执行操作。为此我将常规等待和元素就绪分开处理。我的程序中在步骤前实现了可配置的自动等待，它会检查：元素是否被找到、是否可见、是否可访问、是否未被其他元素遮挡、是否已停止移动、是否已滚动到可视区域。这是防止场景尝试过早点击的情况的保护措施。
在 Web 模式下，尤其重要检查 "visible"、"enabled"、"uncovered" 和 "stable"。在 Windows 应用程序中情况类似：窗口可能已经存在，但控件还没准备好接受操作。
还有一点很重要，操作元素应该返回结果。如果我们读取了文本，最好将其保存在变量中并继续使用。如果我们调用了动作，最好检查该动作的结果。因此，在常规步骤之后，可以添加对返回值的检查：等于、不等于、包含、匹配正则表达式等等。这使得脚本不仅仅是命令序列，而是一个可检查的链。
这种做法并未完全消除UI自动化的复杂性，但用户会看到清晰的步骤提示，如“点击按钮”或“输入文本”，而内部库会根据具体情况选择如何在Windows或浏览器中实现。如果出现错误，原因会一目了然：元素未找到/错误，命令不受支持，或结果与预期不符。为了进一步弥补这些复杂性，我添加了调试模式，以便逐步监控执行过程。
脚本如何成为测试
在这个阶段，我们已经拥有所有管理界面的功能：我们能够定位元素、等待它们就绪并执行操作。但仅凭操作集合本身还不足以让脚本成为测试。我们需要具备测试逻辑功能：检查、数据、报告、调试、日志和崩溃分析。
因此接下来会开始出现脚本中的特殊步骤，这些步骤不再负责管理界面，而是负责指示一切看起来都符合预期，并负责分析脚本的工作情况.
最简单的例子是身份验证。如果脚本输入了登录名、密码并点击了"登录"，这还不足以构成测试。可能按钮没有响应，表单显示了错误，用户仍然停留在同一页面，但点击操作在技术上已经成功完成。 测试通常看起来是这样的：登录后应该出现某个元素，文本应该是这样，API 应该返回状态 200，而个人资料块应该视觉上符合标准 .
等待：不是等待时间，而是等待状态
对几乎任何 UI 场景来说，首先需要的是正常的等待。不是 sleep(3000)，而是等待具体的状态。因此需要单独的步骤Wait 我不把它看作是暂停，而是场景意义的一部分。它回答了这样的问题：“在继续之前，应用程序应该处于什么状态？” 例如：
元素出现了
元素消失了
文本发生了变化
窗口变得可用
值变得等于预期值
在手动测试用例中，我们也写的是"等待2秒"，而不是"等待成功保存消息的出现"。
断言：检查并比较结果
验证应该放在产生结果的行为旁边。如果我们点击了"保存"，最好立即等待消息并检查其文本。如果我们只在最后才进行验证，场景可能会长时间处于错误状态，而崩溃的原因会变得不那么明显。
同时，不同类型的比较也很有用：精确相等、"包含"、正则表达式、大于/小于等。实际上，UI经常返回带有空格、前缀、动态部分的文本。因此，并非总是需要严格检查，有时检查结果的有效部分更可靠。
关于变量：如果脚本开始运行超过一次，其中会出现登录信息、申请编号、文件路径、预期状态。应该能够重用和加载这些数据，为此我添加了变量及其从文件中加载的功能。LoadData 可以将"变量名 - 值"对导出为CSV、XLS或XLSX，并在步骤中替换它们，这已经显著减少了重复。
视觉和API验证
有时，结果无法通过常规的属性和文本检查来验证。例如，布局错乱、按钮在视觉上变得不可用或颜色改变。为此，我添加了截图测试。
最实用的方法是对比最小有效区域，或者尽可能只对比一个元素。理想情况下，在对比前需要稳定画面：等待加载完成，关闭动画，隐藏与检查无关的动态模块。这样视觉检查就成为了测试界面的正常工具。可以对比整个屏幕的截图，但它几乎总是充满杂乱：时间、动画、随机数据、不同窗口尺寸、系统元素。
有时也需要发送HTTP请求来检查状态和响应中的其他值。为此，我添加了API操作功能，将返回值的检查和临时时间戳的清除放在快速访问中。这可能用得上的一个大致场景如下：
通过接口创建对象
从屏幕上的消息中读取其号码
根据此号码调用API
检查JSON中的状态和字段
返回UI并确认对象是否显示在列表中
但我不希望将视觉脚本变成只有作者能理解的隐藏代码。一个好的脚本应该像扩展的手动测试用例一样易于阅读：点击、等待、检查、保存值、调用API、比较结果。如果测试人员在一个月后打开算法，他不仅要明白脚本的作用，还要理解每个步骤的目的。因此，在操作和检查之后，我们不可避免地会进入调试、日志和报告的阶段。
报告和测试结果
当场景失败时，我们不仅要知道“第17步未通过”，还需要理解：这是哪一步，寻找的是哪个元素，等待了多长时间，返回了什么结果，以及错误具体在哪里。因此，围绕场景执行过程出现了调试、步骤日志、运行历史和失败时的截图。
对于常规运行，不仅需要在程序界面中生成报告，还需要以可以进一步传递的格式生成报告：JSON、JUnit、Allure。这样，视觉上构建的脚本就更接近于常规的测试运行：可以运行它、分析它、保存历史记录，并将其连接到团队的工作流程中。
在这里，似乎可以停下来回归整个工具的原始想法。我没有试图在代码自动化已经很好地建立的地方进行替换。我更希望的是填补手动回归和完整框架之间的空白：提供快速构建清晰场景的能力，逐步通过检查来加强它，然后像正常测试运行一样启动它。但无论如何，工具的适用边界仍然取决于用户：在哪些任务中可视化构建确实节省时间，而在哪里编写代码自动化测试更简单。
往哪里去
界面不同，命令不同，测试人员的习惯和技能也不同。因此，我认为发展有几个重要的方向：
更智能地处理定位器。现在工具会提示哪些属性不稳定，并承担了很多工作，但希望完全解放用户 khỏi UI 操作的细节，并隐藏这些设置。理想情况下，制作一个目标按钮“录制”，它只需记录用户对界面的所有手动操作。
改进坠落分析。我肯定想进一步完善发布历史可视化，让每个用户运行都极其信息丰富和易懂。力求让场景步骤包含尽可能多的关于它做什么或已经做了的信息。
更多平台和检查类型。目前我的主要重点是Windows和Web，但使用描述符、预期和其他方法的方法可以扩展到更远。我非常想并且计划将程序与移动设备测试结合起来。
与常用流程集成。用户不应被锁定在程序内部，我已经尝试在代码中提供导出功能，这可能对开发者感兴趣。此外还有JUnit、Allure和JSON格式的报告，它们对于连接持续集成和团队开发至关重要。目前我正在积极完善这一方向，但需要更多反馈意见。
结论
这个工具适用于复杂的\老旧界面、非典型检查以及同时需要与Windows应用程序和网页交互的复杂场景。在这种情况下，它应该比例如Playwright更方便，因为即使使用代码库，在Playwright中也会生成一个需要维护所有定位器的长脚本。这没有编程技能很难，而我制作的工具中所有功能都在手边，可以通过可视化构建器查看算法并对其进行调试。
如果您想尝试RTHelper（无需强制注册），可以从最简单的方式开始：打开表单，填写字段，点击按钮，检查结果。如果能让它至少连续运行几次，马上就会明白这个工具在哪些地方节省时间，哪些地方还不足。
我会很乐意收到反馈，尤其是批评性的，以便这个工具真正能工作。我很想知道哪些地方工作正常，哪些地方出了问题：哪些界面无法工作，哪些操作不够用，哪些报告令人费解，或者哪些场景仍然更简单直接写代码。为了发展，最好是不要猜测抽象的需求，而是关注实际应用中的真实问题。