【发布时间】：2022-08-18 18:05:36
【问题描述】：
当超时设置为 10 秒时，UFT 需要超过 5 分钟来执行步骤。它只发生在某些网页中，其他脚本几乎立即执行。
【发布时间】：2022-08-18 18:05:36
【问题描述】：
这听起来像smart-identification issue，如果是这种情况，报告应该显示该步骤是使用智能 ID 重播的。
您应该修复对象的描述，或者，如果您希望测试在这种情况下失败，请禁用智能识别。
【讨论】：
虽然智能识别可能是这里的问题，但其他一些不容易解决的问题浮现在脑海中：
框架集。如果您使用的不是 IE，而是 Chrome 或 Edge，则在某些情况下，如果网页包含 FRAMESET 元素，则与网页的每次 UFT 交互（读取或写入）都会挂起大约 15 秒（但正确完成）。
模态对话框。如果存在消息框（例如 VBScript MsgBox 或 JavaScript alter()），则会发生类似的事情：在 Edge/Chrome 上，UFT 与网页的每次交互都会产生 15 秒的冻结/挂起。在 IE 上，它会生成不需要的聚焦/散焦操作，这也需要时间（但不会超过 15 秒）。
我们已将此追踪到 UFT 向网页发送消息（我认为是 JavaScript 消息），并等待回复消息超时，因为回复消息应由 UFT 浏览器扩展程序注入的 JavaScript 代码生成（我认为） ，但由于某种原因没有发送回复消息（我肯定知道）。
MicroFocus 过去常说 Edge 和 Chrome 不支持 FRAMESET。 （以上事实已通过检查浏览器消息流量的核心调试器会话挖掘出来，例如，MicroFocus 未确认它们。）该注释已消失，但事实仍然存在。仅修复：消除 FRAMESET，或坚持使用 IE（这不是一个真正的选择）。
我还没有提到 MicroFocus 的消息框问题（还）。他们在文档中有注释说，当您启动最初显示此类对话框的应用程序时，模态对话框会阻止扩展，因此这可能与此处应用的模态对话框类似的问题。
注册用户函数。如果您使用它，早期的 UFT 版本（最高 14.52）如果您将注册的函数作为方法调用并且总共有很多库代码（如果您有成千上万的库代码，则每次调用 6 秒开销）会有巨大的性能损失行）。后来的版本（我认为是 15.02）消除了这一点，但将延迟转移到了 RegisterUserFunc，所以如果你有很多 lib 代码，每个 RegisterUserFunc 调用都需要很多很多秒。这意味着启动可能需要几分钟（！）。 Microfocus 得到了我们的演示，但没有为我们解决这个问题，因为他们说激活数千行 lib 代码是不典型的。我不同意，但这有什么帮助？我的结果是：消除对 RegisterUserFunc 的所有依赖（必须修改所有已注册的方法调用到函数调用）。
最后，当我们将 14.52 与 2021R1 进行比较时，我们看到了巨大的性能损失;没有明显的原因，一切都变慢了。 MicroFocus 说这是设计使然，因为他们添加了使 UFT 必须做的事情复杂化的功能。所以他们说没关系。 我不同意这种观点。 升级到新版本后，我们的测试时间几乎是原来的两倍。 （不幸的是，从 14.52 切换到 15 包括从 Windows 7 切换到 Windows 10，因此 Windows 10 也可能导致性能下降。）我认为这没有被认真对待是一种耻辱。
您的问题也可能有其他原因。要挖掘它，我们需要查看脚本并获取有关应用程序的信息。
【讨论】：