Process UI自动化最佳实践

我们已经开发了一些UI自动化测试用例。目前，我们正在开发中的应用程序上执行这些操作。根据我们的观察，在执行过程中，由于与应用程序相关的性能问题，大多数脚本都会失败（例如窗口未正确加载/窗口加载时间超出预期等）。

所以为了避免这种情况，在执行过程中，我们计划检查哪个步骤失败，并计划再次重新执行相同的步骤，检查窗口是否正确加载，以及是否继续执行。但我觉得，由于这种方法，一些与应用程序性能相关的问题可能会被掩盖，并且不确定我们是否应该遵循这种方法。

---

我想知道它是否可以算作最佳实践。

如果目标是执行功能测试， 定义应用程序在不同环境中的响应时间基准点会很有帮助，例如，如果您有一个web应用程序，则最大加载时间定义为20秒，而对于其他应用程序，则为10秒。同样，一旦你有了一个明确的基准，你就可以抓住问题

---

请注意，在定义应用程序的基准测试时，有许多标准（如网络带宽、服务器类型）需要在定义基准测试时加以考虑。

如果您现在正在为性能尚不稳定的应用程序开发阶段添加重试，您应该确保在应用程序稳定后删除它们

---

如果要在客户端服务器应用程序（例如web）上测试多个用户的性能，QTP足以测试单个用户的桌面应用程序或客户端服务器应用程序的性能也许你应该考虑使用一个像LoadRunner这样的负载测试工具。

如果你实现了一些重新尝试刚刚失败的操作的机制，你会不断地陷入漏洞，因为有时候，由于应用程序处于一个意想不到的UI状态，或者类似的事情，重试是不可能的。p>

通常，每个应用程序都有一个预期的和最差的响应时间。将该时间用作播放配置的最大超时

始终尝试预测什么时候应该发生什么，并相应地编写脚本。让您的脚本容忍意外的UI状态（如长延迟等）只会使您的测试工作变得更为“被动”的自动化工作

作为一个相当粗糙的度量，您可以设计一个至少重试一次（或在特定时间段内）操作的恢复场景。这可以帮助您获得“稳定”的播放，而无需找到要使用的超时

但一般来说：如果一个窗口显示时间太长，这是一个缺陷。如果您的超时时间太低，那就是一个bug——在您的测试机器人配置中。如果没有定义“耗时过长”的含义，请获取性能要求

因此：相应地进行修正

这是我的2（好的——3）美分：）

不是“最佳”而是工作实践。
脚本必须可移植。从一个环境到另一个环境（我们都知道，测试环境比UAT/Pre-prod或生产环境慢得多），只需最少的维护工作量。
因此：

• 使用同步
• 不要硬编码什么可以改变
• 使脚本从QTP IDE外部可配置

关于GUI步骤自动化的一小部分，这里有一个需要记住的通用启发式和首字母缩略词：

SEED NATALI的首字母缩写代表以下内容

• 同步到对象
• 存在
• 启用
• 展示
• 验证参数的数量
• 验证参数的类型
• 日志测试流
• 调查发生的任何问题

谢谢你，
阿尔伯特·加雷夫

相关问题：