将被测应用从32位迁移至64位时，UFT测试需注意哪些问题？

很多团队都遇到过类似场景，结论是：不需要全部更新对象库，但需要针对部分控件做适配调整，具体取决于应用升级的细节和UFT配置。

关键适配场景分析 #

• 标准无改动控件：如果AUT仅从32位迁移到64位，控件核心属性（如name、id、classname）未发生变化，且你的UFT版本在12.0及以上（原生支持64位Windows应用），原有对象库的识别逻辑大概率依然有效，无需修改。
• 属性变更的控件：部分32位控件在64位环境下会修改属性，比如自定义控件的classname可能新增*64后缀，或内部控件ID发生变化。这种情况下，对应的对象库条目需要更新——可以手动修改匹配属性（比如用正则忽略版本后缀），或重新录制该控件。
• UFT运行配置：必须确保UFT的测试运行模式适配64位环境。通过Tools > Options > GUI Testing > General进入设置，在"Test Run"区域选择对应64位应用的运行选项（比如针对64位桌面应用的设置），否则会出现识别失败。

POC阶段的验证重点 #

1. 优先选取核心业务流程的用例，覆盖标准控件、自定义控件、第三方控件等不同类型，验证识别成功率。
2. 对识别失败的控件分类处理：
   • 若仅属性小幅度变化，调整对象库的匹配规则即可（比如增加正则匹配、调整属性优先级），无需重新录制整个控件。
   • 若控件结构完全替换（如32位专属控件被替换为64位版本），则需要重新添加控件到对象库。
3. 确认UFT版本兼容性：UFT 11.5及以下版本对64位应用的支持有限，可能需要安装官方补丁；12.0及以上版本原生支持，无需额外补丁。

额外注意事项 #

• 第三方控件（如DevExpress、Telerik）在32/64位环境下的识别逻辑可能不同，要确认UFT对应的控件插件是否支持64位版本。
• 运行UFT时务必以管理员权限启动，避免64位系统的权限限制导致控件识别失败。

内容的提问来源于stack exchange，提问作者CodesForFun