QTP LoadAndRunAction -- 来自调用者运行结果的被调用者部分的事务时间？
如果我使用 LoadAndRunAction 从另一个测试 A 调用操作 X，被调用操作中收集的事务时间是否正确报告？
即，如果我将这样的调用者脚本 A 插入到在 LoadRunner 场景中，LoadRunner 的结果报告是否包括测试 A 和操作 X 中测量的事务时间？
老实说，我只是问，因为我懒得测试这个临时项目。
背景：我们有一些使用 QTP 脚本来模拟 GUI 用户活动的 LR 场景。这些 QTP 脚本非常大，并且一次又一次地部署到每个负载生成器。这个想法是手动部署一次大型 QTP 测试，然后编写一个调用大型测试的紧凑型 QTP 测试，并将该紧凑型测试插入到 LR 场景中。
If I call an action X from another test A using LoadAndRunAction, are transaction times that are collected in the called action reported correctly?
I.e. if I insert such a caller script A into a LoadRunner scenario, will LoadRunner's result reports include both the transaction times measured in test A and action X?
Honestly I am just asking because I am too lazy to test this ad hoc.
Background: We have some LR szenarios that use QTP scripts to simulate GUI user activity. Those QTP scripts are quite big and get deployed to every load generator again and again. The idea is to deploy the big QTP test once manually, and to write a compact QTP test that calls the big test, and insert that comptact test into the LR scenario.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好的，既然我自己找到了答案，那么分享它们是公平的：
LoadAndRunAction没有正确报告其事务时间，调用者看不到被调用者中测量的事务。但是，您可以使用常规操作调用来调用目标操作。然而，除了最琐碎的被调用者之外，这不起作用，因为 LoadRunner Controller 以某种方式搞乱了调用者和被调用者之间的依赖关系，试图将调用者的东西部署到不存在的负载生成器。
我们的解决方案是创建一个愚蠢的 QTP 调用程序脚本 A，它调用第二个 QTP 测试 B，它什么也不做，只是调用“真正的”QTP 测试 C，所有这些都使用“插入对外部操作的调用”。即：
结果：LoadRunner 成功将 A 部署到负载生成器，执行它。 A 调用 B 测试，B 测试又调用 C。C 执行事务，这些事务通过 B 和 A 报告给场景的运行结果。任务完成了。 （自然地，B和C需要存储在所有机器上完全相同的路径中，并且A和B中的动作引用必须基于绝对路径，而不是相对路径）。
当然，修改 B 或 C 时必须小心。每次修改都必须手动分发到所有其他负载生成器。 A 可以更新为通常的方式（因为它总是会被部署）。
OK, now that I found out answers myself, it's just fair to share them:
LoadAndRunActiondoes not report its transaction times correctly, the caller does not see the transactions measured in the callee.You can, however, use a conventional action call to call the target action. However, this does not work except for the most trivial callees since LoadRunner Controller somehow messes up the dependencies between the caller and the callee, trying to deploy caller stuff to the load generator that does not exist.
The solution for us was to create a dumb QTP caller script A that calls a second QTP test B which does nothing but calls the "real" QTP test C, all using "Insert call to external action". That is:
Result: LoadRunner successfully deploys A to the load generators, executes it. A does its call to the B test, which in turn calls C. C does transactions, which are reported through B and A to the scenarios' run results. Mission accomplished. (Naturally, B and C need to be stored in exactly the same path on all machines, and the action references in A and B must be based on absolute, not relative paths).
Of course, one has to be careful about modifying B or C. Each modification must be distributed to all other load generators manually. A can be updated to usual way (since it always will be deployed).