timeout - 参数化检查点超时？

在QTP中，检查点可用于定义检查点随后检查的预期状态。

这导致对象存储库（OR）中的检查点条目，其包含要检查/查询数据的测试对象的标识属性，以及：超时值。

例如，位图检查点包含这样的超时值。

如果将其设置为5（使用位图检查点属性对话框），QTP会在5秒内尝试等待实际图像与预期图像匹配。

如果将其设置为0，则QTP不会等待。

这是所有记录良好定义的行为。行。

现在 - 如果我的应用程序变慢了，并且我的所有检查点超时都变得太低而现在所有这些都失败了怎么办？

我必须在所有检查点中手动增加超时值。或者，由于我“聪明”，我可以将对象存储库导出到XML，并使用一些聪明的工具在这些XML文件中进行智能大规模搜索和替换操作。

如果是一次性动作，这是可以的。但如果这种情况在一年左右的时间内不止一次发生怎么办？如果您不仅有一个中心OR，而且有很多动作存储库，该怎么办？仅出口就已经很乏味了。

现在 - 这是导致这个问题的真实情况 - 有一个统一的:)超时处理，我有一个常量定义为一个短和一个长时间间隔（以秒为单位）。所有我们的测试代码使用这两个常量中的一个，如果它需要等待某事，轮询一个状态或做任何与超时相关的事情。我们甚至将QTP的web配置中的默认对象识别延迟以编程方式设置为库init的短间隔常量值，以确保在播放期间没有人为“标准”超时使用不同的值。这确实有助于保持测试结果的可比性。

这样，我可以在我的库代码中集中定义最大等待时间（两者都是快速操作，如导航和长期“大”作业），只需编辑这两个常量值即可。 冷却。

除检查点外。 如何强制所有检查点使用，例如，短间隔常量值？我不能。所以让我们考虑一下变通方法（某些人会称之为解决方案;）：

第一个想法：参数化超时。抓一点，QTP不支持。
第二个想法：见上文 - 导出所有OR，批量搜索和替换，重新导入。抓住这一点，以这种方式复制核心变更并不完全是中心配置。如果您有大量的每个操作OR，则非常容易出错。
第三个想法：创建一个工具，使用QTPs对象模型（或自动化对象模型）API在测试运行时更新检查点值。嗯。 .Check电话的额外代码。 Mmmh。
第四个想法：考虑到在检查点执行期间，从OR获取的每个Checkpoint（）引用都传递给特定测试对象的Check方法，可以创建一个接受检查点的全局函数，修补其超时值，并使用修补的检查点调用原始的Check方法。然后，原始的Check方法将使用它在检查点中找到的超时值。很好。但我真的必须为我使用的每个测试对象类注册这个自定义Check方法。或者，为了使其正确，即使在所有测试对象类中，QTP也知道。此外，在测试运行时期间访问/更新检查点的超时值似乎远非微不足道。但至少所有.Check .Checkpoint检查点调用都可以保持原样。嗯嗯。

有更好的想法吗？有没有人试过这个，或者找到了一个优雅的解决方案来参数化检查点中的超时值？

参数化检查点超时？

1 个答案: