UI自动化最佳实践

Question

我们已经开发了一些UI自动化测试用例。目前，我们正在开发中的应用程序上执行这些。根据我们的观察，在执行过程中，大多数脚本都会因为应用程序相关的性能问题而失败(比如窗口没有正确加载/窗口加载时间比预期的要长等等)。

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

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

Answer 1

如果你实现了某种机制来重试刚刚失败的操作，你会一直陷入困境，因为有时，由于应用程序处于意外的UI状态，或者类似的事情，重试是不可能的。

1. 通常情况下，每个应用程序都有一个预期的和最坏的响应时间。使用该时间作为播放配置的最大超时。
2. 总是尝试预测什么时候会发生什么，并相应地编写脚本。使您的脚本能够容忍意外的UI状态(如长时间延迟等)
3. 作为一种相当粗鲁的措施，您可以设计一个至少重试操作一次(或在特定时间段内)的恢复方案。这可以帮助你获得一个“稳定的”回放，而不需要知道要使用什么超时。

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

因此:相应地进行修复。

这是我的2 (OK - 3)美分:)

Answer 2

不是“最好的”，而是工作实践。

脚本必须是可移植的。从环境到环境(我们都知道，测试环境比UAT/Pre-prod或生产环境慢得多)-维护工作最少/为零。

因此：

• 使用synchronization
• don't硬编码可以更改什么
• 使脚本可以从QTP IDE

外部进行配置

关于图形用户界面步骤自动化的一小部分，这里有一个通用的启发式和缩写词需要记住：SEED NATALI。

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

Type Type Synchronize Number

• Exists

• Enabled

• Displayed

• verify Number of Arguments

• verify Arguments

• Log
• 调查

出现的任何问题

谢谢,

阿尔伯特·加雷耶夫

http://automation-beyond.com/

Answer 3

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

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