做了两年Windows客户端测试之后，我最大的一个感受就是：手工回归这事儿，干一次可以接受，干十次还能忍，干上百次真的会让人怀疑人生。所以当项目组提出“把核心功能的回归测试自动化起来”这个需求时，我几乎没有犹豫就接了。这篇是《Windows GUI自动化测试项目实战》系列的第一篇，我会从怎么选技术栈开始，到把第一个能跑、能断言的脚本搭起来，再把期间踩过的一些坑原原本本写出来。写之前先说明一下，文章里的演示对象是一个虚构的桌面应用，我叫它“模拟项目X”，窗口结构是典型的左侧导航加右侧列表布局，这种形态在各类Windows业务客户端里非常常见，看完你完全可以照着这套思路迁移到自己手头的软件上。
这篇文章适合两类人：一类是刚接触客户端自动化、想找一条从零开始的实践路径的测试同学；另一类是已经会用一些录制回放工具、但发现脚本总是一跑就挂，想搞明白底层原理和定位逻辑的测试同学。文章会把“为什么这么选”和“这里需要注意什么”都讲透，而不是只丢给你一段能跑的代码。
1. 项目背景与整体方案选型
1.1 触发这个项目的真实场景
先说说我手头的情况。某一段时间，项目组负责的一个Windows客户端软件进入了稳定迭代期，平均两个星期出一个版本，每个版本发布前需要把业务主流程完整回归一遍。起初我们是用一份Excel用例清单加人工点击，每次回归要花掉大概一天半到两天时间，而且人点到后面是真的会漏点、会误点。更麻烦的是，有些模块的测试数据准备非常繁琐，要在界面上一遍一遍录入，录错了还得删掉重新来，整个过程的体力消耗远大于脑力消耗。
真正压垮我的最后一次回归里，我在一个下拉框里连续选了三十多次同一个选项，只是为了验证不同前置条件下列表数据的展示结果。当天晚上我开始想一个问题：如果能让机器替我完成这些重复点击和输入，我是不是就能把时间花在更复杂、更需要判断的测试场景上？这就是整个自动化测试项目的起点。起点很朴素，没有谁给我下指令，纯粹是自己不想再做重复劳动了。
当然，项目启动前我也认真地做过一个粗略的收益估算。按当时的回归频率计算，每两周一次手工回归，成本大约是10到12个人工时。如果自动化脚本能覆盖核心流程的八成，脚本维护每周算3到4个小时，跑一次全流程只要半小时，那么每一轮回归能节省大约8个小时以上。折算下来，投入两周时间做自动化是划算的，而且随着脚本数量增加，收益会越来越明显。
1.2 技术选型：为什么是Python加pywinauto
说到Windows GUI自动化，技术选型是个绕不开的话题。市面上的方案大致可以分为几类。第一类是商业级的UI自动化测试工具，功能全面但价格不菲，而且脚本通常绑定在工具自身的平台上，迁移和维护的灵活性不太高。第二类是微软官方提供的UI Automation框架，能力很强，但从零开始写的学习成本比较高，开发效率也比较一般。第三类就是目前社区里用得最多的开源方案，包括Python的pywinauto、.NET系的FlaUI，以及基于WebDriver协议的WinAppDriver。
我在选型时主要关注三个维度：社区活跃度、开发效率和后期维护成本。三个方案里，WinAppDriver背后的理念很好，确实可以复用Web自动化那套API风格，但实际用下来它依赖Windows Application Driver服务，运行环境的搭建步骤相对繁琐，部分场景下对控件的识别率不如UIAutomation原生方案稳定。FlaUI的封装质量很高，C#生态下非常顺手，但对于我这支以Python为主要语言的测试团队来说，引入C#技术栈会让维护门槛变高。
最后定下的方案是Python加pywinauto。这个组合有几个明显的优势：第一，pywinauto底层同时支持Win32 API和UI Automation两套技术，兼容性覆盖很广；第二，Python上手快，团队内部其他成员也容易接手；第三，社区里关于pywinauto的资料和案例相当丰富，遇到问题基本都能搜到解决方案。在这里我想强调一个观点：技术选型没有绝对的好与不好，只有合不合适。如果你的团队全是C#背景，选FlaUI可能比我选pywinauto更合适。关键是搞清楚自己团队的技术积累和项目的实际需求，不要因为某一个方案听上去很火就盲目跟风。
2. 环境准备与底层原理理解
2.1 三步把环境搭起来
选型定了之后就进入环境搭建环节。整个环境准备只需要三步，过程比较顺利，但里面有一些细节值得注意。
第一步是安装Python环境。我自己用的是Python 3.10以上的版本，在Windows系统上安装Python时有一个容易忽略的选项，就是安装向导里的“Add Python to PATH”复选框。如果这里忘记勾选，后续在命令行里执行python命令就会提示找不到命令，虽然可以通过绝对路径解决，但每次都要拼一长串路径就很烦人。建议安装完以后第一时间打开命令提示符执行python --version确认一下。
第二步是安装pywinauto库。安装过程用pip一行搞定，但这里有个小坑：不同版本的pywinauto对Python版本的支持范围不一样。如果直接执行pip install pywinauto装到的是最新版本，而你的Python版本比较老，有可能会出现导入时报错的情况。我的建议是安装完成后马上执行python -c "from pywinauto import Application"验证一下导入是否正常，如果没问题再继续下一步。
第三步是准备好界面元素查看工具。Windows SDK里自带一个叫inspect.exe的工具，可以在系统提供的辅助工具目录里找到。这个工具对做UI自动化来说相当重要，它可以查看窗口的控件树、控件的AutomationId、ClassName、Name等属性。如果没有它，我们就像蒙着眼睛在操作界面，所有控件的定位信息都无从谈起。还有一款叫UISpy的工具，功能类似，但inspect.exe在系统更新后兼容性更好，所以我的主用工具是inspect.exe。
这三步做完，环境就算基本就绪了。从我个人的经验来看，环境搭建阶段最容易出问题的并不是Python或pywinauto本身，而是权限和运行方式的问题。比如后面脚本执行的时候需要以管理员身份运行，如果开发机平时用普通用户登录，遇到被UAC保护的应用窗口会无法访问。这个我们放到后面常见问题章节再展开。
2.2 框架到底是怎么控制界面元素的
很多人刚接触GUI自动化时，脑子里最大的疑问是：程序到底是怎么找到那个按钮、怎么点击它的？这个问题的答案，是理解整个GUI自动化的钥匙。
pywinauto的工作方式可以通俗地用一句话概括：它不是像人一样“看”屏幕，而是像侦探一样“读”界面。Windows系统里的每一个窗口、按钮、输入框，在系统层面都对应着一个或多个窗口句柄，这些句柄就像每个控件的身份证号码。窗口控件还带有各种属性，比如标题文字、控件类型、类名、位置信息。pywinauto做的最核心的事情，就是通过系统提供的访问接口，按照你给的条件去查找符合特征的控件，拿到它的句柄，然后向它发送操作指令。
这里需要区分两套底层技术。Win32 API是老牌的Windows界面访问技术，速度快，兼容老旧的软件，但遇到一些现代风格的界面（比如用WPF或UWP开发的）时，控件的可读性就会变差。UI Automation是微软后来推出的新一代无障碍框架，能够把界面呈现为一个层级树，每个节点都带有丰富的自动化属性，对复杂控件的支持要好得多。pywinauto的厉害之处在于它把两套方案都包装成了接近一致的API，你可以根据被测对象的界面技术来选择用哪种方式。
用代码来体会一下这个区别。下面这段代码演示了两种连接窗口的方式：
from pywinauto import Application # 连接一个已经打开的进程 app = Application(backend="uia").connect(process_id=12345) # 或者使用win32后端 app2 = Application(backend="win32").connect(title="模拟项目X - 资产管理")backend参数只有两个选项：uia和win32。当你对界面结构不熟悉时，最好的做法是先通过inspect.exe看一眼目标窗口的控件树，再决定用哪个后端。如果在代码中指定的后端跟应用实际支持的接口不匹配，最典型的现象就是控件能找到一部分，但关键按钮就是识别不出来。
2.3 认识界面结构查看工具
前面提到inspect.exe，这里稍微展开讲一下怎么用，因为后面所有脚本里的控件定位信息几乎都来自它。
打开inspect.exe后，用鼠标点击界面上的某个控件，工具左侧会展示出一棵控件树，右侧会列出当前选中控件的详细属性。我平时最关注几个属性：Name是控件的可见文本，AutomationId是该控件的唯一标识，ControlType表示控件种类，ClassName是窗口类的名称。对于一个按钮来说，AutomationId往往是定位它最稳定的方式，因为界面上可能会有多个按钮的文本相同，但AutomationId一般不会重复。
我第一次拿inspect.exe去查看被测软件时，发现很多按钮的AutomationId是空的，只有Name属性有值。这种情况下就只能用Name作为定位条件，但随之而来的问题是，界面如果发生文案调整，脚本就跟着挂了。后来我们和开发约定，新做的界面控件尽量都设置一个稳定的AutomationId，这条约定给后续脚本维护省了不少力气。如果你的开发团队也愿意配合，最好在一开始就把这个约定定下来。
还有一个小技巧：inspect.exe右上角有一个“鼠标悬停模式”的切换按钮，点开之后，把鼠标移到被测窗口上，工具会自动定位到鼠标所在的控件。对那种层级很深的复杂界面，这个功能比一级一级展开控件树要高效得多。
3. 实战案例：从启动到第一个自动化脚本
3.1 被测对象与目标场景说明
为了把整个过程讲清楚，我虚构了一个Windows桌面客户端，就叫“模拟项目X”，功能风格和很多企业级业务软件类似。它的主窗口布局是左侧一个导航栏，包含“资产列表”“资产录入”“统计报表”等菜单项，右侧是一个数据表格区，顶部是工具栏，有一排按钮和若干个输入框。
我们的测试目标是完成一条资产录入的完整流程：启动应用，在登录窗口输入账号密码，进入主窗口，点击“资产录入”菜单，填写表单里的资产名称、资产编号和所属部门，点击保存，最后在资产列表里检查是否出现刚才录入的数据。这条流程看起来简单，但其中包含了窗口切换、菜单导航、文本输入、按钮点击和数据校验这几个GUI自动化最核心的操作类型，非常适合作为第一个实战脚本。
我选择这个流程作为第一篇实战内容的另一个原因是，它几乎覆盖了新手会踩到的大部分典型问题：登录窗口和主窗口之间的连接切换、控件加载慢导致的找不到元素、弹窗断言。把这一条流程跑通，后面的脚本基本上就是在这个框架上堆业务逻辑了。
需要说明的是，写脚本前我建议先做一件看似无关的事情：手动把这条测试流程完整走一遍，并在走查的过程中记录每一步在界面上的反馈。为什么要这么做？因为只有知道界面每一步的预期反馈是什么，你才知道断言该写在哪里。这一步也是那些所谓“录制一下就能跑”的工具做不到的事情——录制工具只能录下操作，录不下预期结果。
3.2 启动应用与主窗口连接
编写脚本的第一步是启动应用。pywinauto里启动应用有两种常见方式：一种是直接指定可执行文件的路径，另一种是如果应用已经在运行，可以通过进程号或窗口标题来连接。在自动化测试场景里，一般都会要求测试从干净的状态开始，所以第一种方式用得更多。
下面是我在这个实战里用的启动连接代码：
from pywinauto import Application import time # 启动应用 app = Application(backend="uia").start(r"D:\Demo\SimulatedProjectX.exe") time.sleep(3) # 连接登录窗口 login_win = app.window(title_re=".*登录.*") login_win.wait("visible", timeout=10) print("登录窗口已出现")这里有几个值得注意的地方。time.sleep(3)是我故意加的，因为应用刚启动时，窗口从创建到完全渲染需要一点时间，如果不等待就直接去找登录窗口，脚本大概率会报找不到窗口。但sleep的时间又不能写死太长，否则整个测试套件跑下来会被无意义的等待拖慢。更合理的做法是用wait("visible", timeout=10)这类显式等待，它会一直等到窗口出现或者超时为止。
窗口标题我用的是正则表达式".登录."，目的是避免标题栏里附带版本号或者其他前缀导致精确匹配失败。在GUI自动化里，窗口标题最好用模糊匹配而不是完全匹配，这是我踩了几次坑之后养成的习惯。比如被测软件升级后标题从“模拟项目X 资产管理 v1.2”变成“模拟项目X 资产管理 v1.3”，如果用精确匹配，脚本就白写了。
3.3 定位控件与基本操作
窗口连上之后，第二步就是定位窗口里的控件并操作它们。结合我们虚构的登录窗口，它里面包含一个账号输入框、一个密码输入框和一个登录按钮。
定位控件时，pywinauto提供了好几种方式，可以参考下面的代码：
# 方式一：通过AutomationId定位 username_edit = login_win.child_window(auto_id="txt_username") # 方式二：通过控件类型和名称组合定位 password_edit = login_win.child_window(control_type="Edit", title="密码") # 方式三：直接通过属性查找 login_btn = login_win.child_window(title="登 录")在登录窗口这个例子里，我选择使用AutomationId来定位输入框，因为登录框的文案标签可能发生变化，但自动化ID是开发代码里定义的，稳定性更高。登录按钮没有AutomationId，所以我用title来定位。这里有一个细节：很多软件会在按钮文本里加入空格，比如“登 录”，如果查找不到，可以试试用title_re正则方法，或者先通过inspect.exe确认确切的文本内容。
控件定位好之后，执行操作就很简单了：
username_edit.set_text("tester01") password_edit.set_text("pass1234") login_btn.click()连续执行两步操作之间，脚本其实默认会有一定的动作间隔，但有时因为界面响应太慢，点击登录按钮后要过一两秒才跳转到主窗口。所以登录按钮点击之后，最好加上对主窗口的等待逻辑，再用主窗口对象继续后续操作。
主窗口连接的代码是：
main_win = app.window(title_re=".*资产管理.*") main_win.wait("visible", timeout=15) menu_asset_input = main_win.child_window(title="资产录入") menu_asset_input.click()这里需要理解一个关键点：app对象连接的是整个应用进程，而不是某一个窗口。所以即使用户从登录窗口跳到了主窗口，只要还是同一个进程，app.window()就能找到新出现的窗口。如果应用是多进程架构，登录窗口和主窗口属于不同进程，那就需要用process参数分别连接。
3.4 断言与测试执行顺序设计
写自动化脚本，操作只是过程，断言才是目的。没有断言的脚本，跑完了你也不知道测试到底过没过。在我们的资产录入流程里，断言点是最后一步：在资产列表里验证新录入的数据是否存在。
假设资产列表用的是一个表格控件，数据项里包含“资产编号”这一列。那么断言逻辑可以写成：在表格中查找是否存在一个行，其“资产编号”单元格的文本等于我们录入的编号。
代码可以这样写：
from pywinauto.controls.uiawrapper import UIAWrapper list_table = main_win.child_window(auto_id="grid_asset_list") list_table.wait("visible", timeout=10) record_found = False for row in list_table.rows(): cell_text = row.cells()[1].get_value() # 假设第2列是资产编号 if cell_text == "AST-2024-001": record_found = True break assert record_found, "资产列表中未找到新增记录 AST-2024-001"这种在表格里逐行遍历的方式效率谈不上高，但逻辑清晰，排查问题时也容易定位。如果表格数据量很大，更高效的方式是让开发在表格控件上暴露一个数据接口，测试直接通过接口取数去校验，但这种做法需要开发配合，而且少了一点端到端验证的意义。
另外，还要注意断言之后的清理工作。测试脚本如果跑完就结束，不清理测试数据，第二次再跑时会发现资产编号已经存在，导致断言逻辑判断方向要反过来写。所以更稳妥的做法是测试开始前先生成一个带随机后缀的资产编号，测试结束时再把这条数据删除。这样既能避免重复数据冲突，又不污染测试环境。
import random asset_code = f"AST-2024-{random.randint(1000, 9999)}"这个小改动可以让脚本反复执行而不会相互影响，是我在项目中养成的一个习惯。凡是会写入数据的用例，都必须考虑数据唯一性和清理机制。
4. 把脚本写稳：等待、重试与日志
4.1 等控件出现而不是盲目sleep
第一个脚本跑通之后，你会发现它时灵时不灵。很多时候昨天还能顺利跑完，今天就在某一步控件找不到直接报错。这种不稳定背后的大概率原因只有一个：时序问题。应用在加载数据、渲染界面、响应点击时都有延迟，而脚本的查找动作比界面渲染快得多，控件还没出现在界面树上，脚本就已经开始找了。
解决这个问题的标准做法是显式等待。pywinauto的wait()方法可以等待控件处于某个状态，常见的有visible、enabled、exists。和固定sleep相比，显式等待的优点是：只要条件满足立即继续执行，条件不满足则一直等到超时，这样既不会因为等待时间不够而误报，也不会白白浪费多余的等待时间。
我一般这样用：
save_btn = main_win.child_window(title="保存") save_btn.wait("enabled", timeout=10) save_btn.click()这里等的是“enabled”而不是“visible”，因为有时候按钮可见了但仍然是置灰状态，这时候点击会无效操作。对于按钮类控件，等待它可点击再操作是比较保险的策略。
还有一种情况是界面上的加载动画。某些界面在刷新数据时会先弹出一个进度条，数据加载完进度条才消失。这种情况下，判断加载完成的标志不应该是“进度条存在”，而是“进度条消失”。pywinauto的wait_not方法可以等待控件状态反转。或者更简单，等我们要操作的目标控件直接出现。总之，等待条件一定要选择最能代表“下一步可以继续”的那个信号。
4.2 自定义重试与日志截图
即使有了显式等待，脚本在高负载环境下还是可能偶尔超时。网络慢、磁盘IO高、后台任务占资源，都可能导致应用响应变慢。为了提升脚本的稳定性，我给关键操作加了一层重试机制。
最简单实用的重试逻辑是这样实现的：对某个控件的查找和点击操作放入一个循环，如果第一次执行时控件不存在，就等待一秒后重试，最多重试三次。为了防止异常信息被吞掉，每次失败时都要记录日志。
下面是我常用的一个重试装饰器写法：
import functools import time import logging def retry_on_failure(retries=3, interval=1.0): def decorator(func): @functools.wraps(func) def wrapper(*args, **kwargs): for attempt in range(retries): try: return func(*args, **kwargs) except Exception as e: logging.warning(f"第{attempt + 1}次尝试失败: {e}") if attempt < retries - 1: time.sleep(interval) else: raise return wrapper return decorator这个装饰器可以直接套在查找控件或者点击按钮的函数上。不过我要提醒一下，重试不应该被滥用。重试的适用场景是外部因素导致的临时不稳定，如果是因为控件的定位条件本身写错了，重试多少次都没有意义，反而会让失败暴露得更慢。所以每次脚本出错，第一件事永远应该是去分析根因，而不是无脑加重试。
日志和截图同样是脚本稳定性的重要组成部分。脚本在无人值守的机器上跑，失败时如果不能留下足够现场信息，排查问题会非常痛苦。我的做法是：在脚本的每个关键节点输出日志，在异常发生时自动截图并保存到指定目录，截图文件命名包含时间戳和当前操作名。
def take_screenshot(window, name): timestamp = time.strftime("%Y%m%d_%H%M%S") path = rf"D:\Demo\screenshots\{name}_{timestamp}.png" window.capture_as_image().save(path) return path有了日志和截图，哪怕脚本凌晨在测试机上跑挂了，第二天早上来上班，打开日志和截图，三分钟就能定位大概问题。这些细节决定了自动化测试能不能长期稳定运行，而不是只能靠现场盯着。
4.3 失败时到底该记什么
说到日志，很多初学者写的日志只有一行“控件未找到”。这句话对排查问题基本没有帮助。更实用的日志应该包含以下信息：是哪个步骤失败的、操作的控件有什么特征、当前界面树的关键上下文、以及当时的截图路径。
举个例子，如果“保存按钮点击失败”这条日志能自动带上按钮的Name、AutomationId和所在窗口标题，再加上当时的截图，那么即使是完全没有看过这条用例的人，拿到日志也能快速还原现场。如果日志只有一行“Traceback ... element not found”，那你还得重新手动复现一遍问题，效率完全不一样。
我在项目里统一封装了一个操作工具类，把查找控件、点击、输入文本这些动作都收纳进去，所有操作都自动记录日志和截图。这样一来，脚本代码本身会清爽很多，日志质量也有了保证。封装这个工具类的工作量不大，但对后期维护的帮助非常大。后面如果我写页面对象模型那一篇，会详细讲怎么把这套封装落地。
5. 常见问题与排查经验
5.1 定位不到元素的五步排查法
“元素定位不到”是GUI自动化里出现频率最高的报错，几乎每个新手都在这上面卡过。我遇到过太多类似情况，这里整理一套排查路径。
第一步，确认窗口连接是否正确。很多时候定位不到元素不是因为元素不存在，而是因为程序连错了窗口。比如窗口标题匹配用的是正则，正则写得太宽松，匹配到了另外一个隐藏窗口。这时候把app.window()拿到的窗口标题打印出来，一眼就能发现问题。
第二步，检查是否用对了backend。如果被测应用是WPF或者现代UI框架，用win32后端去连接，很多控件会识别不到。反过来，有些老旧的Win32应用，用uia后端连接时反而表现不稳定。判断的方法是打开inspect.exe，看控件树显示是否完整，如果控件树里能看到元素但代码里找不到，优先怀疑backend不匹配。
第三步，确认控件的自动化属性。用inspect.exe查看目标控件的Name、AutomationId、ControlType、ClassName，然后跟代码里的查找条件逐一对比。这里最容易踩的坑是：界面上的可见文本和控件的Name属性并不总是一样。有些按钮显示的是“保存并提交”，但Name属性是“保存”，如果照着界面上看到的文字去写定位条件，大概率找不到。
第四步，检查控件是否在窗口的弹出层或者独立进程中。某个“看似在窗口中”的按钮，可能实际上属于一个弹出窗口，甚至是另一个进程的窗口。比如点击某个菜单按钮后出现一个右键菜单，这个菜单的窗口层级和主窗口是平级的，你仍然用main_win.child_window去查它，自然查不到。这时候需要先获取弹窗对象，再从弹窗里查控件。
第五步，也是最容易被忽略的，检查脚本运行时机。前面反复提到的控件还没加载出来就执行查找，是这类问题最常见的根因。如果控件在等待超时之后还是没有出现，你可以截图保存下来，看看当时界面到底处于什么状态，是被弹窗挡住了，还是加载转圈卡住了。截图往往能直接揭示答案。
5.2 权限、DPI缩放、多显示器与虚拟桌面
这一小节要说的几个坑，都属于那种你可能跑了一周脚本都遇不到，但一旦遇到就完全摸不着头脑的问题。
权限问题是第一个坑。Windows的UAC机制保证了有些窗口必须以管理员权限运行。如果你的测试脚本是用普通权限启动的，而应用是用管理员权限运行的，进程之间的窗口消息访问就可能被系统拦截，表现为窗口能连上，但控件查找不到或者点击无效。反过来也一样。解决方案是让测试脚本和被测应用都运行在相同的权限级别下。通常我们会把运行脚本的命令行窗口设置为以管理员身份运行，然后由脚本去启动应用，这样两者的权限就是一致的。
DPI缩放是第二个坑。Windows系统在高分辨率屏幕上默认会对界面做缩放，缩放比例可能是125%或者150%。这会导致控件的位置坐标和系统逻辑坐标不一致，如果你的脚本里有依赖坐标点击的逻辑，就很有可能点偏。解决思路有两种：要么在测试机上把缩放比例固定为100%，要么在脚本启动时设置进程级别的DPI感知。pywinauto对DPI缩放有一些底层处理，但并不意味着所有场景都能自动适配，所以最省心的方式是在自动化专用测试机上把DPI设置为100%。
多显示器和虚拟桌面是第三个坑。被测应用如果被拉到了第二块显示器，而脚本在副屏上识别窗口时没有做对应的坐标换算，也会出现位置错乱。更麻烦的是Windows虚拟桌面功能，应用在虚拟桌面1打开，脚本跑去虚拟桌面2找窗口，结果自然是找不到。这类问题有一个统一的排查思路：跑脚本前检查当前显示环境，保证应用窗口和脚本运行在同一个桌面会话中。
5.3 常见问题速查表
为了方便查阅，我把这段时间遇到过的问题整理成一个表格，按问题现象、排查思路、解决方案三列排列。
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
| 窗口找不到 | 标题正则匹配过宽或过窄 | 用inspect查看实际窗口标题，调整正则 |
| 控件有时能找到有时不能 | 界面加载时序问题 | 使用wait方法显式等待，避免硬编码sleep |
| 按钮点击无效 | 控件处于禁用状态 | 等待控件enabled状态后再点击 |
| 输入框输不进去文字 | 控件类型判断错误或焦点未获取 | 先点击获取焦点再输入，或改用set_edit_text |
| 脚本报权限异常 | 脚本与应用权限级别不一致 | 统一以管理员权限运行脚本 |
| 控件识别为Pane而非Edit | backend选择错误 | 改用uia后端连接 |
| 点击坐标跑偏 | DPI缩放或多显示器布局不同 | 固定缩放100%，统一显示器位置 |
| 找不到弹出框里的控件 | 弹窗在独立窗口层级 | 重新获取弹窗窗口对象再查找 |
| 测试数据重复导致断言失败 | 未处理数据唯一性 | 生成随机后缀编号，测试结束清理数据 |
这张表是我实际排查问题的浓缩版，但真正排查时还是要从现场日志和截图出发，不能对着表格硬套。技术问题千变万化，掌握排查思路远比背结论重要。
6. 一些心得与后续打算
写到这里，我回看了一下这一篇的内容，从一个最初不想再手工点鼠标的念头出发，到选型、搭环境、写出第一个能跑的脚本，再到处理过程中遇到的各种莫名其妙的坑，算是一条比较完整的学习路径了。
我个人在实际操作中有几个体会想分享。第一，GUI自动化测试的难点不在写代码，而在对被测应用的理解。你对界面的结构理解得越深，脚本定位条件就写得越准，稳定性也越高。所以每次开始一个新项目的自动化，我不急着写脚本，而是先用inspect.exe把主要界面都看一遍，把控件树结构记录成文档，这个过程花不了多少时间，但后面的收益很大。第二，脚本的稳定性是靠等待机制、日志、截图和重试探出来的，不是靠堆代码堆出来的。每次跑挂，我都要求自己找到根因，把可以沉淀到框架里的改进沉淀下来。第三，自动化测试是持续投入的活，脚本写完不是终点，应用每次改版你都得跟着维护，所以设计时一定要把可维护性放在第一位，给控件稳定的标识、写清晰的日志、保持用例的独立性。
这篇先聊到这里。接下来我会再写一篇，把页面对象模型（POM）的封装思路和框架化的组织方式详细展开，让这套GUI自动化资产可以更规范地沉淀下来。如果你正在做Windows客户端测试，也想把回归测试从手工里解放出来，可以先按文章里这套流程把第一个脚本跑通。跑通之后你就会发现，自动化这扇门一旦走进去，就再也回不到纯手工点点的时代了。
