QTP LoadAndRunAction - temps de transaction de partie callee du résultat de l'exécution de l'appelant?

Question

Si je l'appelle une action X d'un autre test A l'aide LoadAndRunAction, sont les temps de transaction qui sont collectés dans l'action appelées reported correctement?

i.e.. si je insérer un tel script appelant A dans un scénario de LoadRunner, seront les rapports de résultats de LoadRunner comprennent à la fois les temps de transaction mesurés dans le test A et de l'action X?

Honnêtement, je vous demande simplement parce que je suis trop paresseux pour tester cette ad hoc.

Contexte: Nous avons quelques LR szenarios que les scripts de l'utilisation QTP pour simuler l'activité des utilisateurs de l'interface graphique. Ces scripts QTP sont assez grandes et sont déployés à chaque générateur de charge encore et encore. L'idée est de déployer le grand test QTP manuellement une fois, et d'écrire un test QTP compact qui appelle le grand test, et insérer ce test comptact dans le scénario LR.

Answer 1

OK, maintenant que je trouve moi-même des réponses, il est juste juste de les partager:

LoadAndRunAction ne signale pas correctement son temps de transaction, l'appelant ne voit pas les transactions mesurées dans le callee.

Vous pouvez toutefois utiliser un appel d'action classique pour appeler l'action cible. Toutefois, cela ne fonctionne pas, sauf pour les plus futiles depuis LoadRunner fonctions appelées contrôleur en quelque sorte de bousille les dépendances entre l'appelant et l'appelé, en essayant de déployer des trucs de l'appelant au générateur de charge qui n'existe pas.

La solution pour nous était de créer un script appelant muet QTP A qui appelle une seconde QTP le test B qui ne fait rien, mais appelle le test de QTP C « réel », tout en utilisant « appel à l'action extérieure Insérer ». C'est:

• Développer A et B à l'aide d'une machine à QTP qui détient déjà C
• Copie A et B au contrôleur
• Insérer A dans le scénario
• pré-déploiement (à savoir copier uniquement) B et C à tous les générateurs de charge

Résultat: LoadRunner déploie avec succès un des générateurs de charge, l'exécute. A fait son appel à l'épreuve B, qui appelle à son tour C. C fait des transactions qui sont faites par le B et A aux résultats d'exécution des scénarios. Mission accomplie. (Bien entendu, B et C doivent être stockés dans exactement le même chemin sur toutes les machines, et les références d'action en A et B doivent être basées sur des chemins absolus et non relatifs).

Bien sûr, on doit faire attention à la modification B ou C. Chaque modification doit être distribué à tous les autres générateurs de charge manuellement. A peut être mis à jour comme d'habitude (car il sera toujours déployée).