UI自动化最佳实践

Question

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

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

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

Answer 1

如果你实现了一些机制来重新尝试失败的操作，你就会陷入困境，因为有时，由于应用程序处于意外的UI状态或类似的事情，无法重新尝试。

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

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

3. 作为一种相当粗鲁的措施，您可以设计一个至少重试一次（或在特定时间段内）重试该操作的恢复方案。这可以帮助您获得“稳定”的播放，而无需查找要使用的超时时间。

但一般情况下：如果窗户显示太长时间，则表示存在缺陷。如果您的超时太低，那就是一个错误 - 在您的测试机器人配置中。如果没有定义“需要太长时间”的意思，请获得性能要求。

因此：相应修复。

那是我的2（OK - 3）美分:)。

Answer 2

不是“最佳”，而是工作练习 脚本必须可移植。从环境到环境（我们都知道，测试环境比UAT / Pre-prod或生产慢得多） - 维护成本极小/为零。
因此：

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

关于GUI Step Automation的小部分，这里有一个通用的启发式和首字母缩略词：SEED NATALI。

SEED NATALI缩写代表以下内容。

• 同步到对象
• 已存在
• 启用
• 显示
• 验证参数数量
• 验证参数类型
• 记录测试流程
• 调查发生的任何问题

谢谢你，
Albert Gareev
http://automation-beyond.com/

Answer 3

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

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

Answer 4

如果您现在为应用程序开发中尚未稳定的阶段添加重试，则应确保在应用程序稳定后删除它们。

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