在 QTP 中，检查点可用于定义预期状态，然后检查点会检查该状态。
这会在对象存储库 (OR) 中产生一个检查点条目，其中包含要检查/查询数据的测试对象的标识属性，以及：超时值。
例如，位图检查点包含这样的超时值。
如果将其设置为 5（使用位图检查点属性对话框），QTP 会尝试在 5 秒内等待实际图像与预期图像匹配。
如果将其设置为 0，QTP 根本不会等待。
这都是记录在案的明确定义的行为。好的。
现在——如果我的应用程序变慢了，并且我所有的检查点超时都变得太低，所以现在所有的都失败了怎么办？
我将不得不在所有检查点手动增加超时值。或者，因为我很“聪明”，我可以将对象存储库导出为 XML，并使用一些聪明的工具在这些 XML 文件中进行智能的大规模搜索和替换操作。
如果它是一次性操作，这是可以的。但是，如果这种情况在一年左右发生不止一次怎么办？如果您不仅有一个中央 OR，而且还有大量的动作存储库，该怎么办？仅出口就已经很乏味了。
现在 - 这是导致这个问题的真实情况 - 有一个统一的 :) 超时处理，我为一个短时间间隔和一个长时间间隔（以秒为单位）定义了一个常量。如果需要等待某事、轮询状态或执行与超时相关的任何其他操作，我们所有测试的代码都使用这两个常量之一。我们甚至在 QTP 的 web 配置中以编程方式将默认对象识别延迟设置为库初始化时的短间隔常量的值，以确保没有人在播放期间为“标准”超时使用不同的值。这确实有助于保持测试结果的可比性。
这样，我可以在我的库代码中集中定义最大等待时间（两者，一个用于快速操作，如导航，另一个用于长时间的“大”作业），只需编辑这两个常量的值。凉爽的。
检查站除外。 如何强制所有检查点使用短间隔常量的值？我不能。因此，让我们考虑解决方法（某些人会称之为解决方案；）：
第一个想法：参数化超时。从头开始，QTP 不支持。
第二个想法：见上文——导出所有 OR，批量搜索和替换，重新导入。从头开始，以这种方式复制中央更改并不完全是中央配置。如果您有很多每个操作 OR，那么它非常容易出错。
第三个想法：创建一个使用 QTPs 对象模型（或自动化对象模型）API 在测试运行时更新检查点值的工具。嗯。.Check 调用的额外代码。嗯。
第四个想法：考虑到在检查点执行期间，从 OR 获取的每个 Checkpoint () 引用都传递给特定测试对象的 Check 方法，可以创建一个接受检查点的全局函数，修补其超时值，并调用原始的使用修补的检查点检查方法。然后，原始的 Check 方法将使用它在检查点中找到的超时值。伟大的。但是我真的必须在我使用的每个测试对象类中注册这个自定义的 Check 方法。或者，为了使它正确，即使在QTP 知道的所有测试对象类中。此外，在测试运行时访问/更新检查点的超时值似乎绝非易事。但至少所有这些
.Check .Checkpoint检查点调用都可以保持原样。嗯嗯。
有更好的想法吗？有没有人试过这个，或者找到一个优雅的解决方案来参数化检查点中的超时值？