基于AI进行GUI自动化测试

**摘要：**本文围绕一个基于 QT 的仿 QQ 音乐轻量级播放器，介绍了 GUI 自动化测试实践的项目背景。文章梳理了手动编写的测试用例及其覆盖的核心操作场景，指出了因项目功能未完全实现导致的测试用例数量不足问题，并分析了手动 GUI 自动化测试中覆盖不全、用例数量有限等局限性，进而引出对更高效的测试用例生成与管理方式的探索。

一.项目背景：

我们这里基于一个 QT 项目------仿 QQ 音乐的一个轻量级播放器，来进行 GUI 自动化测试的实践。该项目界面模仿了 QQ 音乐的主要布局和交互，但由于是轻量版本，部分功能仅保留了 UI 入口，并未实现完整的后端逻辑。

为了验证播放器的界面功能是否正常，我根据 QQ 音乐的实际交互逻辑手动点击并梳理了一份测试用例，覆盖了播放控制、歌曲搜索、我的音乐等核心操作场景：

不过，由于轻量版播放器的一些功能并未真正实现------界面上虽然展示了按钮，但点击后并无实际效果------导致对应的测试用例无法完整执行。这意味着当前的测试用例数量偏少，如果面对一个功能更加完整的大型项目，仅靠这些测试用例是无法覆盖所有业务场景的。

举个例子，在"我的音乐"模块中，我们想测试"添加本地音乐"功能。因为提前准备好了素材文件，所以点击添加按钮后可以顺利进入文件夹选择，整个交互流程是畅通的：

然而，在手动进行 GUI 自动化测试的过程中，我们遇到了一些明显的局限性：测试用例需要我们自行检查页面、手动补充，这不仅耗时，而且容易出现覆盖不全、用例数量不足、测试严谨性欠缺等问题。这促使我们去思考------是否有更高效的方式来生成和管理 GUI 自动化测试用例，提升测试的覆盖率和质量。

二codex赋能GUI测试自动化：

1.编写SPEC.md

我们这里开始一个项目时最好先进行对要求书的编写，后续的实现都走这个要求书，这样才不会

跑偏：

提示词：

图⽚的界⾯是部署在window系统上的仿QQ⾳乐程序,根据图⽚提供的应⽤程序界⾯设计GUI⾃动化测试 SPEC.md,⻚⾯包含顶部导航栏、左侧导航菜单、主内容区域、底部播放控制栏。要求书中包含测试用例模块（在每个阶段实现前先编写测试用例），项目架构等等，这个项目不复杂不需要考虑的那么深，在完成之前，先问我你想了解的问题，达到更好的效果

注意：

（1）技术栈要求：

1. 编程语⾔：Python
2. 测试框架：pytest
3. ⾃动化测试：pywinauto
4. 数据驱动：YAML
5. 报告：Allure
6. logging⽇志记录：⽇志分级输出，按天分割
7. 避免使⽤复杂的设计模式

这里让他实现时先问我问题，防止他自主意识来对这个项目进行幻读

把我们自己进行点点点的情况告诉AI防止他对其进行过度的解读来生成没有必要的测试用例，

这里让他了解更多的情况

这里是他第一版生成编写SPEC.md的计划：

但是这里我们经过详细阅读发现还有好几点没有补充：

最终版计划书：

仿 QQ 音乐 GUI 自动化测试 SPEC.md 编写计划

概要

创建可直接指导实现的 `SPEC.md`，测试目标为 Windows Qt5 程序 `D:\AI测试项目\qqmusic\QQMusic.exe`。技术栈固定为 Python、pytest、pywinauto、YAML、Allure，使用简单的主窗口操作封装，不采用复杂设计模式。

所有阶段遵循测试先行：先编写测试用例与预期断言，确认用例失败，再实现自动化代码并运行至通过。

架构与接口

• `config/`：使用 YAML 配置 exe、数据库、歌曲目录、窗口标题、超时、窗口尺寸和 pywinauto 后端。

• `data/`：使用 YAML 保存导航名称、提示文本、输入框文本和待添加 MP3 的预期信息。

• `core/`：负责应用启动、连接、关闭、等待及数据库备份恢复。

• `pages/main_window.py`：使用单一主窗口类封装导航、顶部输入框、歌曲列表、文件选择、播放栏和窗口按钮。

• `tests/`：按启动与窗口、导航、顶部输入、本地音乐、添加歌曲、播放控制划分测试模块。

• `conftest.py`：提供会话级应用 fixture；测试前备份 `QQMusic.db`，结束后关闭程序并恢复数据库。

• 定位优先级为 UIA 属性、Win32 可见属性、主窗口客户区相对坐标。相对坐标集中配置，禁止在测试函数中散落绝对屏幕坐标。

• 日志使用 UTF-8：控制台输出 INFO 以上，文件记录 DEBUG 以上，通过 `TimedRotatingFileHandler` 按天分割。

• Allure 用例添加 feature、story、title、severity；失败时附加窗口截图、控件信息和日志。

分阶段实施

1. 基础设施：先测试 YAML 加载、路径校验、中文编码、日志分级和轮转，再实现配置与日志模块。

2. 应用管理：先测试 exe 启动、窗口等待、进程关闭、数据库备份恢复，再实现应用管理和 fixture。

3. 页面骨架：先编写四个界面区域及主要控件的存在性用例，再实现主窗口定位封装。

4. 页面交互：先编写导航、顶部输入、本地歌曲、添加歌曲和播放控制用例，再实现对应操作。

5. 报告支持：先验证 Allure 步骤、失败截图和日志附件，再实现 pytest 钩子与执行配置。

核心测试场景

• 启动后验证顶部导航栏、左侧导航菜单、主内容区和底部播放控制栏正常显示。

• 推荐、我喜欢、本地下载、最近播放验证点击、选中态和主区域切换。

• 电台、音乐馆只验证按钮存在、可以点击并显示对应页面，不测试具体业务。

• 顶部灰色切边输入框仅作为可编辑输入控件测试，不进行搜索结果断言。

• 输入框验证获得焦点、输入中英文字符、使用退格键删除部分内容、全选后删除全部内容。

• 输入框内容变化不得被解释为搜索行为；不测试列表过滤、回车搜索或无结果提示。

• 本地下载页验证表头、歌曲行、歌手、专辑、收藏状态及 VIP/SQ 展示标签。

• VIP/SQ 标签只验证正确显示；点击后不应产生页面跳转、弹窗或状态变化。

• 点击添加按钮后操作 Windows 文件选择窗口，从 `D:\AI测试项目\qqmusic\musics` 选择 MP3。

• 验证歌曲添加成功、列表信息正确、可以选中并播放；测试不限定截图中的四首歌曲。

• 文件选择窗口取消后列表不变；重复添加同一歌曲时不得产生重复记录。

• 选择歌曲后验证底部歌曲名与歌手同步。

• 播放、暂停、上一首、下一首、随机播放、音量和收藏验证对应 UI 状态变化。

• 播放断言使用播放图标、当前歌曲和时间进度，不通过扬声器声音判断。

• "播放全部"验证从列表中首个可播放项开始播放。

• 换肤按钮点击后验证提示弹窗文本严格等于"换肤功能小哥哥正在紧急支持中"。

• 最小化按钮验证窗口进入最小化状态并能够恢复。

• 最大化按钮仅验证存在、可点击，并且点击后窗口位置和尺寸均不发生变化；不要求最大化或还原功能。

• 关闭按钮验证应用主窗口关闭；该用例结束后由 fixture 按需重新启动程序。

• 异常场景覆盖歌曲目录不可访问、配置路径错误、窗口启动超时和控件定位失败，并记录日志及 Allure 证据。

验收标准与默认值

• 默认使用 `uia` 后端、会话级启动和显式等待，不使用固定长时间 `sleep` 作为主要同步方式。

• 默认固定窗口尺寸约为 `1024×684`，坐标按客户区比例计算，执行前检查 Windows 显示缩放。

• 最大化按钮无功能属于预期行为，测试不得把窗口未最大化判定为失败。

• YAML 从现有 MP3 中指定稳定样例；添加前动态确认目标歌曲尚未出现在列表中。

• 测试结束后无论成功或失败都恢复原始 `QQMusic.db`，不保留自动化新增数据。

• `SPEC.md` 给出依赖安装、pytest 执行、生成 `allure-results`、查看 Allure 报告及通过/失败判定命令。

最终的SPEC.md文件：

2.阶段一：配置与日志

这样我们整个GUI测试涉及到的项目架构和配置都已经准备完毕，后面生成测试用例再开始进行

测试代码的编写即可

3.阶段二:应用生命周期

4.阶段三:启动应用测试用例的编写与实现

这里我当时有个疑问他有没有做窗口的恢复操作，因为这里的QQ音乐进来就是最小窗口：

如果再次点击最小化的话窗口会直接消失，他这里对我点击个性化皮肤按钮的文案进行了存疑

他认为这里的提示窗口的文案没有...其实是有的，我们截图给他看并且修改了一下：

他这里会重开一个新窗口，舍弃掉就窗口，这样的操作也是可以的，如果再次让他找到之前的

窗口的操作也行，两者都可以实现，只要做了窗口恢复操作就行，如果没做的话后面的窗口是

找不到的，这里做了这样的操作即可

5.阶段三:左侧导航栏测试用例的编写与代码的实现

这里对于之前写的操作进行一个补充，因为他第一个版本实现的测试用例不完整并且操作与实际软

件操作也有误，所以这里来进行一下调整：

这里还有一个要记住的点就是他会进行对我的喜欢的删除操作，补充一下删除操作也是点击爱心

还有要记住这里清除了我的喜欢的歌曲，后面的阶段我们进行对歌曲播放的测试时也要对我的喜欢

看看是否能进行正常播放，记得补充一下

这里我在终端手动执行了一下pytest发现了很多报错，我以为是代码的实现有问题实际上并不是

这里是因为阶段3的主窗口操作还没有进行，所以执行报错

启动应用的过程：

这里也就是通过配置文件已经编写好的路径来进行启动的

6.阶段三:主窗口测试的实现：

阶段三实现总结

本阶段完成了 WIN、NAV、INP 三部分，共 17 条 GUI 用例所需的页面对象与运行基础设施。

实现内容

• 新增 MainWindow 页面对象，集中封装：
  • 主窗口就绪、矩形和四个区域检查
  • 换肤提示、最小化、无效果最大化、关闭
  • 六个左侧导航项及页面身份判断
  • 本地下载、最近播放到"我喜欢"的独立收藏链路
  • 顶部输入框输入、退格和全选删除
  • 截图、控件等待和错误日志
• 补充 main_window fixture，每条用例重新获取有效窗口对象，并清理残留弹窗。
• 完成 INP-001～003 测试及 YAML 数据驱动。
• 所有定位优先使用 UIA automation_id；歌曲行爱心无法被 UIA 单独识别时，使用歌曲行相对比例坐标。
• 为 WIN、NAV、INP 测试增加 Allure 中文标题、步骤和严重级别。

遇到的问题与修复

1. 实际窗口标题与配置不一致

   规范配置为 QQ音乐，实际窗口标题为 QQMusic，导致启动等待超时。已修正标题正则。

2. 应用读取了错误的数据库

   原来启动进程时没有指定工作目录，应用读取了项目根目录的 QQMusic.db，而备份恢复针对的是应用目录数据库。已将启动工作目录固定为 QQMusic.exe 所在目录，确保测试修改和恢复的是同一个文件。

3. UIA 无法识别歌曲行内部控件

   Qt 只暴露了歌曲 ListItem，未暴露歌曲名和爱心子控件。修复方式：

   • 从数据库读取初始歌曲名称和顺序。
   • 使用 UIA 获取实际可见行数。
   • 按歌曲行宽高比例计算爱心点击位置。
   • 通过爱心区域颜色变化确认收藏状态。
   • 进入"我喜欢"后继续用界面行数验证收藏结果。

4. 页面身份判断非常缓慢

   逐个查询隐藏 Qt 页面时，每个页面可能阻塞约 5 秒。已改为一次枚举当前可见 UIA 树，根据可见页面的 automation_id 判断当前页面，单次判断降至约 0.1 秒。

5. 最小化行为不是普通隐藏

   点击后窗口仍被 Win32 标记为可见，但矩形移动到了 -32000 坐标。已按窗口移出桌面的实际状态判断"当前窗口消失"，没有依赖 is_minimized() 作为测试断言。

6. 最大化按钮被 UIA 标记为禁用

   产品仍显示该按钮，点击后窗口无变化。已允许定位可见但 disabled 的最大化按钮，并验证点击前后窗口矩形不变、没有进入最大化状态。

7. 数据库恢复时 os.replace 被短暂拒绝

   QQMusic 退出后，Windows 有时仍禁止替换数据库目录项，但允许覆盖文件内容。恢复逻辑现在优先原子替换；遇到权限占用时使用已校验备份覆盖，并再次计算 SHA-256 确认内容一致。

8. 测试进程残留

   原逻辑主要等待或终止主 PID，没有最终检查托盘或子进程。现已增加：

   • 超时时按明确 PID 清理进程树。
   • 正常关闭后再次检查配置 exe 路径。
   • 只清理本次测试产生的同路径 PID，不按进程名误杀用户实例。
   • 对应单元测试覆盖。

验证结果

• 阶段三 GUI：17 passed
  • WIN：6 条
  • NAV：8 条
  • INP：3 条
• 配置、日志和生命周期单元测试：18 passed
• 测试结束后：
  • QQMusic 测试进程无残留
  • Python 测试进程无残留
  • 数据库临时备份目录无残留
  • 收藏状态恢复为初始值，数据库 SHA-256 校验一致

问题：AI是如何进行定位控件的：

他整个定位的流程其实就是先打印当前窗口的所有控件信息然后来进行定位，而我们是借助UI spy

可视化工具来进行定位的

我这里手动执行了一下也是全部通过了，而且完成的效果也是不错的：

7.阶段四：本地下载列表页的实现：

我们这里实现代码之前先完善一下测试用例，完善好测试用例之后再进行代码的实现，这样可以

做一个约束：

8.阶段四:添加歌曲的实现：

这里因为我们现在的素材已经被我当时自己进行测试的时候添加完了，所以这里没办法进行多次验

证而这里导入的歌曲又没办法进行删除，所以这里我们只能上网找素材了，接下来就请到我们的

豆姐：

给出我们的困惑让他进行全网搜索，这里这个网站也是发现可以直接下载并导入

这就是我们刚才从网上获取到的歌曲用于测试，接下来就写提示词接着实现即可

这里他把可添加的歌曲名放到了测试数据的yaml文件中：

这里让他调整一下：

接下来就去实现代码了：

问题：

这里测试的时候还有一个问题，因为你添加了歌曲过后，再次进行测试，他读取的还是老的没有

添加歌曲的数据，但其实你添加完要及时更新数据，避免下次添加的时候还是那一首歌曲

是我多想了，他每次进行完测试之后会删除测试数据，也就是数据库中刚才导入的测试数据，

所以说这里添加操作添加的就是如此，我们还是想多了，所以这里让他确认一下并回退代码：

9.阶段四：播放测试的实现

提示词，因为随机播放和单曲循环还有列表循环的验证你要有充分的提示词，不然AI会遐想

SPEC.md(SPEC.md) 根据要求，完善阶段4中PLAY测试用例

注意：

1.这里除了去验证随机播放功能还要去验证单曲循环功能和列表循环功能，进入应用时默认是随机播放，点击随机播放按钮就是单曲循环，再次点击单曲循环就是列表循环，所以这里的测试用例要按照顺序排列

2.随机播放的验证是点击下一首的按钮，检查播放的下一首歌曲是否为歌曲列表中的下一首，如果连续三次都是的话，则随机播放功能有误，反之正确

3.列表循环的验证是将播放进度条拉到末尾，检查播放的下一首歌曲是否为歌曲列表中的下一首，如果连续三次都是列表中的下一首歌曲，则列表循环功能正确，反之播放功能有误

备注：这里两次验证用不一样的功能旨在验证不同的操作

这里AI补充的还是非常不错的整个边界限定的很清除，可以的，就按照这个继续执行了

问题：

控件定位方式

整体遵循项目约定的定位顺序：

1. 优先使用 UIA 的 automation_id + control_type。
2. UIA 无法提供状态时，通过控件截图的像素特征识别。
3. Qt 自绘区域无法被 UIA 单独识别时，基于已定位控件的矩形计算相对坐标。

不是单纯通过截图手工找固定屏幕坐标。截图主要用来分析 UIA 没有暴露的图标状态和自绘浮层。

播放栏大部分控件可以直接通过 UIA 定位，例如：

playMode   播放模式
playUp     上一首
play       播放/暂停
playDown   下一首
volume     音量

这些控件的完整 automation_id 都集中定义在 main_window.py (line 77)(D:\\AI测试项目\\AI-GUI自动化测试\\pages\\main_window.py:77)。

播放模式识别

播放模式按钮虽然能通过 UIA 定位，但三种状态都没有标题或可读取的状态值。因此我采集了随机播放、单曲循环和列表循环三种图标，分析其深色像素数量和纵向范围：

• 单曲循环图标的深色像素明显更多。
• 随机播放和列表循环通过图标纵向跨度区分。

识别逻辑位于 main_window.py (line 840)(D:\\AI测试项目\\AI-GUI自动化测试\\pages\\main_window.py:840)。点击后会轮询图标，确认模式确实发生变化，而不是只执行点击。

随机播放的问题

随机播放可能随机到当前正在播放的歌曲。

最初的同步逻辑要求歌曲名称必须发生变化，结果随机到同一首时会超时。之后又尝试通过播放时间是否归零判断，但应用随机到同一首时可能继续播放，时间也不会归零。

最终改成：

• 点击下一首后，在短时间窗口内轮询歌曲名称。
• 名称发生变化就立即记录新歌曲。
• 观察结束仍是原歌曲，就把原歌曲作为本次随机结果。
• 再根据三次结果判断是否连续三次都是列表顺序下一首。

这更符合测试用例本身的判定要求。

进度条的问题

进度条是 Qt 自绘 Custom 控件，没有可写的 Value 属性，但它本身有稳定的 UIA 控件矩形。

因此使用控件内部相对位置操作：

进度条宽度 × 99%

点击后先轮询确认时间已经跳到总时长前约 5 秒，再等待单曲重新播放或列表切换。这样可以证明操作确实命中了进度条末端，避免点击无效后产生假通过。实现位于 main_window.py (line 940)(D:\\AI测试项目\\AI-GUI自动化测试\\pages\\main_window.py:940)。

音量键为什么耗时较长

音量部分同时遇到了定位、状态判断和浮层交互三个问题。

最初我把底部音量图标理解成静音切换按钮。第一次点击后，图标像素发生变化，看起来像进入了静音状态；但第二次点击始终无法恢复。

通过截图和连续点击探测后发现，实际原因不是静音状态：

• 点击音量图标会打开一个竖向音量浮层。
• 图标像素变化来自鼠标悬停状态，不是静音状态。
• 浮层是 Qt 自绘区域，UIA 控件树中没有滑杆、圆点或百分比控件。
• 浮层会覆盖底部按钮附近区域，导致再次点击可能落到浮层或底层进度条。
• 曾经直接移动到推算位置点击时，浮层提前消失，点击穿透到进度条，导致播放时间跳转。

你说明正确操作方式后，我改为：

1. 通过 UIA 点击底部音量图标。
2. 截取音量按钮上方的相对区域。
3. 检测绿色滑杆圆点，确认浮层已经出现。
4. 根据绿色圆点纵向位置计算当前音量百分比。
5. 从圆点位置按住鼠标，拖动到目标音量位置。
6. 再读取圆点位置验证音量变化。
7. 最后拖回初始位置，并点击窗口空白区域关闭浮层。

相关实现位于 main_window.py (line 990)(D:\\AI测试项目\\AI-GUI自动化测试\\pages\\main_window.py:990) 和 PLAY-008 (line 219)(D:\\AI测试项目\\AI-GUI自动化测试\\tests\\test_06_playback.py:219)。

音量部分耗时较长，主要是因为不能仅凭截图坐标直接操作：必须先区分悬停图标和真实音量状态，再确认浮层的生命周期、点击穿透行为以及滑杆圆点的实际位置。最终定位仍然是基于 UIA 音量按钮矩形计算相对坐标，没有使用固定屏幕绝对坐标。

这里AI还是非常聪明的要夸一夸GPT 5.6sol 还是非常可以的当定位不到问题时他会自己进行操作

然后截图看一下是哪里不符合，这一点还是非常强大的，而且这里的推理程度才是中，还是非常

可以的一个模型。

10.阶段五：验收并生成测试报告：

下次想要进行测试执行的命令

pytest #批量执行测试用例

allure serve allure-results#运行生成测试报告

三.总结：

该项目是一个针对仿 QQ 音乐 Windows 桌面程序的 GUI 自动化测试项目，重点覆盖应用生命周期、窗口导航、本地歌曲管理和播放控制。

项目架构

项目采用轻量级分层结构，没有引入复杂的工厂、依赖注入或业务领域模型。

层次	主要文件	职责
配置层	config.yaml(D:/AI测试项目/AI-GUI自动化测试/config/config.yaml)、test_data.yaml(D:/AI测试项目/AI-GUI自动化测试/data/test_data.yaml)	保存应用路径、超时、窗口尺寸、日志配置和测试数据
核心层	config_loader.py(D:/AI测试项目/AI-GUI自动化测试/core/config_loader.py)、logger.py(D:/AI测试项目/AI-GUI自动化测试/core/logger.py)、app_manager.py(D:/AI测试项目/AI-GUI自动化测试/core/app_manager.py)	配置校验、日志管理、应用启动关闭、数据库备份恢复
页面操作层	main_window.py(D:/AI测试项目/AI-GUI自动化测试/pages/main_window.py)	封装窗口、导航、歌曲列表、收藏、播放和文件选择操作
测试编排层	tests(D:/AI测试项目/AI-GUI自动化测试/tests)	按业务场景组织测试步骤和断言
pytest 集成层	conftest.py(D:/AI测试项目/AI-GUI自动化测试/conftest.py)	提供 fixture、测试隔离、失败截图和 Allure 附件
报告层	reporting.py(D:/AI测试项目/AI-GUI自动化测试/core/reporting.py)	收集失败现场、筛选当前用例日志并写入 Allure

主要技术栈

• Python 3.13
• pytest：测试框架、fixture 和测试钩子
• pywinauto：Windows UIA/Win32 桌面自动化
• PyYAML：UTF-8 YAML 配置及测试数据加载
• allure-pytest：测试步骤、功能分类、优先级和失败附件
• Allure Commandline 2.30.0：生成 HTML 测试报告
• Python logging：控制台和 UTF-8 文件日志
• TimedRotatingFileHandler：日志按天轮转
• ContextVar：在完整测试生命周期中记录当前用例 ID
• pytest marker：区分 smoke、gui 和 destructive 用例

主要实现方式

应用与数据隔离

测试会话启动前检查是否存在用户手工启动的 QQMusic 实例，避免误连接或误关闭。

随后对数据库进行 SHA-256 校验和临时备份。无论测试通过、失败还是 fixture 异常，都会在 finally 中：

1. 关闭本次测试启动的进程。
2. 清理同路径残留子进程。
3. 原子恢复原始数据库。
4. 再次校验数据库内容。

因此添加歌曲、收藏歌曲等操作不会永久污染原始数据。

页面对象封装

所有 GUI 操作集中在 MainWindow 中，测试代码只表达业务，例如：

main_window.click_navigation("本地下载")
main_window.select_song(song_name)
main_window.toggle_favorite(song_name)

控件定位优先使用：

1. UIA automation_id、control_type 和标题。
2. Win32 窗口属性。
3. Qt 自绘控件的客户区相对坐标。

坐标统一定义在页面类中，并按窗口尺寸换算，没有散落在测试代码里。

测试同步

项目没有依赖固定的长时间 sleep，主要使用：

• pywinauto 控件等待；
• 短间隔状态轮询；
• 页面标识验证；
• 播放时间增长验证；
• 歌曲、收藏和窗口状态变化验证。

这比单纯等待固定秒数更稳定。

日志与报告

日志格式为：

时间 | 级别 | 模块 | 用例ID | 消息

每条测试的 setup、执行和 teardown 日志都会带有对应的 WIN-001、NAV-004、PLAY-007 等 ID。

GUI 测试使用 Allure 的：

• feature
• title
• severity
• step

失败时自动附加：

• 当前窗口 PNG 截图；
• 窗口矩形和页面标识；
• 控件定位条件及异常堆栈；
• 只属于当前用例的日志；
• 附件采集自身发生异常时的诊断信息。

测试结果

完整回归结果：

56 passed

其中包含 34 个 GUI 业务用例，所有 GUI 用例均包含 Allure 步骤。数据库恢复成功，测试结束后 QQMusic 残留进程数为 0。

另外通过一个隔离的预期失败探针，实际验证了 Allure 失败附件链路，截图、状态、异常和用例日志附件均正常生成。

被测对象的不足

虽然现有 56 条用例全部通过，但这是因为测试预期已经按照产品当前行为制定。测试过程中可以确认被测程序存在以下不足。

1. 顶部输入框不具备搜索能力

输入框只能输入和删除文本，不支持：

• 回车搜索；
• 歌曲列表过滤；
• 搜索结果展示。

从产品角度看，它目前只是一个普通文本框，而不是完整的音乐搜索功能。

2. 换肤功能尚未实现

点击换肤按钮只显示固定提示：

换肤功能小哥哥正在紧急支持中...

没有主题选择、皮肤预览、应用或恢复能力。

3. 最大化按钮没有实际效果

按钮虽然可见并可以点击，但点击前后的窗口位置和尺寸没有变化，也不会进入 Windows 最大化状态。

这会造成明显的交互预期落差：界面展示了标准最大化入口，却没有实现对应能力。

4. 最小化行为不符合标准 Windows 习惯

产品的最小化实际表现为窗口移动到桌面外或直接消失，而不是进入标准 Windows 最小化状态。

因此：

• 无法通过标准 is_minimized() 判断；
• 不适合通过任务栏正常还原；
• 自动化测试必须结束进程并重新启动应用。

这说明窗口生命周期实现不够规范。

5. 电台和音乐馆只是占位页面

两个入口可以点击并切换页面，但没有进一步的内容浏览、播放、分类或网络业务功能。

当前只能验证入口存在，不能形成完整业务闭环。

6. VIP 和 SQ 标签只有展示功能

标签可见，但没有详情说明或交互行为。用户无法通过标签了解会员要求、音质信息或升级入口。

7. UI 自动化可访问性不足

部分 Qt 自绘控件无法通过标准 UIA 属性稳定访问，需要依赖：

• 图像像素判断；
• 客户区相对坐标；
• 自绘区域位置推算。

特别是播放模式、音量滑杆、进度条等控件，对界面尺寸和显示缩放较敏感。这不仅增加自动化成本，也反映出程序的无障碍和可测试性支持不足。

8. 部分控件状态表达不规范

例如最大化按钮可能在 UIA 中被标记为 disabled，但实际上仍能收到点击；播放状态和播放模式也需要结合颜色或像素判断。

控件的可用状态、语义属性和实际行为不完全一致，容易影响自动化工具及辅助技术。

总体来看，被测程序已经具备本地歌曲、收藏和播放控制的基本闭环，但搜索、换肤、在线页面、标准窗口行为以及 UI 自动化可访问性仍明显不完整。

总的来说整个GUI测试AI表现的还是非常不错的，值得称赞