Parametrisierung, Funktionen, Transaktionen in LoadRunner

Ein aufgezeichnetes Skript kann einen virtuellen Benutzer simulieren; Allerdings reicht eine bloße Aufzeichnung möglicherweise nicht aus, um das „echte Nutzerverhalten“ nachzubilden.

Wenn ein Skript aufgezeichnet wird, deckt es den einzelnen und direkten Ablauf der betreffenden Anwendung ab. Ein echter Benutzer hingegen kann mehrere Iterationen eines beliebigen Prozesses durchführen, bevor er sich abmeldet. Die Verzögerung zwischen dem Klicken auf Schaltflächen (Denkzeit) ist von Person zu Person unterschiedlich. Es besteht die Möglichkeit, dass einige echte Benutzer über DSL auf Ihre Anwendung zugreifen und andere über eine Einwahlverbindung. Um also das wirkliche Gefühl eines Endbenutzers zu vermitteln, müssen wir unsere Skripte so verbessern, dass sie exakt mit denen echter Benutzer übereinstimmen oder sich zumindest im Verhalten sehr ähnlich verhalten.

Das Obige ist die wichtigste Überlegung bei der Durchführung von „Performance Testing“, aber zu einem VU-Skript gehört noch mehr. Wie können Sie die genaue Zeit einschätzen, die ein VUser benötigt, wenn SUL einen Leistungstest durchläuft? Wie können Sie wissen, ob der VUser an einem bestimmten Punkt erfolgreich war oder ausgefallen ist? Was ist die Ursache für den Fehler, ob ein Backend-Prozess fehlgeschlagen ist oder die Serverressourcen begrenzt waren?

Wir müssen unser Skript verbessern, um alle oben genannten Fragen zu beantworten.

Verwenden von Transaktionen

Transaktionen sind Mechanismen zum Messen der Serverantwortzeit für beliebige Vorgänge. Einfach ausgedrückt hilft die Verwendung von „Transaktionen“ dabei, die Zeit zu messen, die das System für eine bestimmte Anforderung benötigt. Dabei kann es sich um so etwas Kleines wie einen Klick auf eine Schaltfläche oder einen AJAX-Aufruf handeln, wenn der Fokus vom Textfeld abweicht.

Das Anwenden von Transaktionen ist unkompliziert. Schreiben Sie einfach eine Codezeile, bevor eine Anfrage an den Server gestellt wird, und schließen Sie die Transaktion, wenn die Anfrage endet. LoadRunner benötigt lediglich einen String als Transaktionsnamen.

Um eine Transaktion zu eröffnen, verwenden Sie diese Codezeile:

lr_start_transaction(“Transaction Name”);

Um die Transaktion abzuschließen, verwenden Sie diese Codezeile:

lr_end_transaction(“Transaction Name”, <status>);

Der teilt LoadRunner mit, ob diese bestimmte Transaktion erfolgreich oder nicht erfolgreich war. Die möglichen Parameter könnten sein:

• LR_AUTO
• LR_PASS
• LR_FAIL

Beispiel:

lr_end_transaction(“My_Login”, LR_AUTO);
lr_end_transaction(“001_Opening_Dashboard Name”, LR_PASS);
lr_end_transaction(“Business_Workflow_Transaction Name”, LR_FAIL);

Punkte zu beachten:

• Vergessen Sie nicht, dass Sie mit „C“ arbeiten und dass es sich dabei um eine Sprache handelt, bei der die Groß-/Kleinschreibung beachtet wird.
• Das Zeichen „Punkt“ (.) ist im Transaktionsnamen nicht zulässig, Sie können jedoch Leerzeichen und Unterstriche verwenden.
• Wenn Sie Ihren Code gut verzweigt und Prüfpunkte hinzugefügt haben, um die Antwort vom Server zu überprüfen, können Sie eine benutzerdefinierte Fehlerbehandlung wie LR_PASS oder LR_FAIL verwenden. Andernfalls können Sie LR_AUTO verwenden und LoadRunner behandelt Serverfehler (HTTP 500, 400 usw.) automatisch.
• Stellen Sie beim Anwenden von Transaktionen sicher, dass keine vorhanden sind Denkzeit Die Abrechnung muss eingefügt werden, andernfalls wird Ihre Transaktion immer diesen Zeitraum umfassen.
• Da LoadRunner eine konstante Zeichenfolge als Transaktionsnamen erfordert, besteht ein häufiges Problem bei der Anwendung einer Transaktion darin, dass die Zeichenfolge nicht übereinstimmt. Wenn Sie beim Öffnen und Schließen einer Transaktion einen anderen Namen angeben, treten mindestens zwei Fehler auf. Da die von Ihnen geöffnete Transaktion nie geschlossen wurde, gibt LoadRunner einen Fehler aus. Außerdem wurde die Transaktion, die Sie schließen möchten, nie geöffnet, was zu einem Fehler führte.
• Können Sie Ihre Intelligenz nutzen und sich selbst sagen, welcher der oben genannten Fehler zuerst gemeldet wird? Warum machen Sie nicht Ihren eigenen Fehler, um Ihre Antwort zu bestätigen? Wenn Sie richtig geantwortet haben, sind Sie auf dem richtigen Weg. Wenn Sie falsch geantwortet haben, müssen Sie sich konzentrieren.
• Da LoadRunner automatisch die Synchronisierung von Anfragen und Antworten übernimmt, müssen Sie sich beim Anwenden von Transaktionen keine Gedanken über die Antworten machen.

Denkzeit, Treffpunkte und Kommentare verstehen

Treffpunkte

Rendezvous Points bedeutet „Treffpunkte“. Es ist nur eine Anweisungszeile, die LoadRunner anweist, Parallelität einzuführen. Sie fügen Rendezvous-Punkte in VUser-Skripte ein, um eine hohe Benutzerlast auf dem Server zu emulieren.

Rendezvous-Punkte weisen VUser an, während der Testausführung darauf zu warten, dass mehrere VUser an einem bestimmten Punkt ankommen, damit sie gleichzeitig eine Aufgabe ausführen können. Um beispielsweise Spitzenlasten auf dem Bankserver nachzubilden, können Sie einen Treffpunkt einfügen, der 100 VUser anweist, gleichzeitig Bargeld auf ihre Konten einzuzahlen. Dies lässt sich ganz einfach mit Rendezvous erreichen.

Wenn die Rendezvous-Punkte nicht korrekt platziert sind, greift der VUser auf verschiedene Teile der Anwendung zu – sogar für dasselbe Skript. Dies liegt daran, dass jeder VUser unterschiedliche Reaktionszeiten erhält und daher nur wenige Benutzer hinterherhinken.

Syntax: lr_rendesvous(“Logischer Name”);

Best Practices:

• Stellen Sie einem Rendezvous-Punkt „rdv_“ voran, um die Lesbarkeit des Codes zu verbessern. zB „rdv_Login“
• Entfernen Sie alle Anweisungen zur unmittelbaren Bedenkzeit
• Anwenden von Rendezvouspunkten in einer Skriptansicht (nach der Aufzeichnung)

Ihre Nachricht

Fügen Sie Kommentare hinzu, um eine Aktivität, einen Codeabschnitt oder eine Codezeile zu beschreiben. Kommentare helfen dabei, den Code für jeden verständlich zu machen, der in Zukunft darauf zurückgreift. Sie liefern Informationen zu bestimmten Vorgängen und trennen zwei Abschnitte zur Unterscheidung.

Sie können Kommentare hinzufügen

• Während der Aufnahme (mit Werkzeug)
• Nach der Aufnahme (direktes Schreiben im Code)

Best Practice: Markieren Sie alle Kommentare oben in jeder Skriptdatei

Einfügen von Funktionen über das Menü

Während Sie einfache Codezeilen direkt schreiben können, benötigen Sie möglicherweise einen Hinweis, um eine Funktion abzurufen. Sie können auch die Steps Toolbox (vor Version 12 als Insert Function bekannt) verwenden, um jede Funktion zu suchen und direkt in Ihr Skript einzufügen.

Sie finden die Steps-Symbolleiste unter „Ansicht“ à „Steps-Toolbox“.

Dadurch wird ein Seitenfenster geöffnet. Sehen Sie sich den Schnappschuss an:

Was ist Parametrisierung?

A Parameter In VUGen handelt es sich um einen Container, der einen aufgezeichneten Wert enthält, der für verschiedene Benutzer ersetzt wird.

Während der Ausführung des Skripts (in VUGen oder Controller) ersetzt der Wert aus einer externen Quelle (wie .txt, XML oder Datenbank) den vorherigen Wert des Parameters.

Die Parametrisierung ist beispielsweise nützlich, um dynamische (oder eindeutige) Werte an den Server zu senden. Ein Geschäftsprozess soll 10 Iterationen ausführen, dabei aber jedes Mal einen eindeutigen Benutzernamen auswählen.

Es hilft auch dabei, ein realitätsnahes Verhalten des Subjektsystems zu stimulieren. Schauen Sie sich das folgende Beispiel an:

Problembeispiele:

Der Geschäftsprozess funktioniert nur für das aktuelle Datum, das vom Server kommt, und kann daher nicht als fest codierte Anfrage übergeben werden.

Manchmal übergibt die Clientanwendung eine eindeutige ID an den Server (z. B. session_id), damit der Prozess fortgesetzt werden kann (auch für einen einzelnen Benutzer). In einem solchen Fall hilft die Parametrisierung.

Häufig verwaltet die Clientanwendung einen Cache mit Daten, die an und von dem Server gesendet werden. Infolgedessen empfängt der Server kein echtes Benutzerverhalten (falls der Server je nach Suchkriterium einen anderen Algorithmus ausführt). Während das VUser-Skript erfolgreich ausgeführt wird, sind die erstellten Leistungsstatistiken nicht aussagekräftig. Die Verwendung unterschiedlicher Daten durch Parametrisierung hilft dabei, serverseitige Aktivitäten (Prozeduren usw.) zu emulieren und das System zu trainieren.

Ein Datum, das während der Aufzeichnung im VUser fest codiert wird, ist möglicherweise nicht mehr gültig, wenn dieses Datum überschritten ist. Durch die Parametrisierung des Datums kann die VUser-Ausführung erfolgreich ausgeführt werden, indem das fest codierte Datum ersetzt wird. Solche Felder oder Anfragen sind die richtigen Kandidaten für die Parametrisierung.

Klicken Sie HIER wenn das Video nicht zugänglich ist

Laufzeiteinstellungen und ihre Auswirkungen auf die VU-Simulation

Laufzeiteinstellungen sind genauso wichtig wie Ihr VUGen-Skript. Durch unterschiedliche Konfigurationen können Sie unterschiedliche Testdesigns erhalten. Aus diesem Grund kann es zu nicht wiederholbaren Ergebnissen kommen, wenn die Laufzeiteinstellungen nicht konsistent sind. Lassen Sie uns jedes Attribut einzeln besprechen.

Führen Sie Logic aus

Run Logic definiert die Häufigkeit, mit der alle Aktionen außer vuser_init und vuser_end ausgeführt werden.

Dies macht wahrscheinlich deutlicher, warum LoadRunner empfiehlt, den gesamten Anmeldecode ausschließlich in vuser_init und den Abmeldeteil in vuser_end zu belassen.

Wenn Sie mehrere Aktionen erstellt haben, beispielsweise „Anmelden“, „Bildschirm öffnen“, „Miete berechnen“, „Geld einreichen“, „Kontostand prüfen“ und „Abmelden“, dann findet für jeden VUser das folgende Szenario statt:

Alle V-Benutzer melden sich an, führen „Bildschirm öffnen“, „Miete berechnen“, „Mittel einreichen“, „Guthaben prüfen“ aus – und dann – erneut „Bildschirm öffnen“, „Mieten berechnen“ usw. – zehnmal iterierend – gefolgt von der Abmeldung (einmal).

Dies ist eine leistungsstarke Einstellung, die es ermöglicht, sich eher wie ein echter Benutzer zu verhalten. Denken Sie daran, dass sich ein echter Benutzer nicht jedes Mal an- und abmeldet – er wiederholt normalerweise dieselben Schritte.

Wie oft klicken Sie beim Überprüfen Ihrer E-Mails auf „Posteingang“, bevor Sie sich abmelden?

Pacing

Das ist wichtig. Die meisten Menschen sind nicht in der Lage, den Unterschied zwischen Tempo und Bedenkzeit zu verstehen. Der einzige Unterschied besteht darin, „Pacing bezieht sich auf die Verzögerung zwischen Iterationen“, während die Denkzeit die Verzögerung zwischen zwei beliebigen Schritten ist.

Die empfohlene Einstellung hängt vom Testdesign ab. Wenn Sie jedoch eine aggressive Auslastung wünschen, sollten Sie die Option „Sobald die vorherige Iteration endet“ in Betracht ziehen.

Log

Ein Protokoll (im Allgemeinen verstanden) ist eine Buchhaltung aller Ereignisse, während Sie LoadRunner ausführen. Sie können das Protokoll aktivieren, um zu erfahren, was zwischen Ihrer Anwendung und Ihrem Server passiert.

LoadRunner bietet einen leistungsstarken Protokollierungsmechanismus, der eigenständig robust und skalierbar ist. Es ermöglicht Ihnen, nur das „Standardprotokoll“ oder ein detailliertes, konfigurierbares erweitertes Protokoll zu führen oder es ganz zu deaktivieren.

Ein Standardprotokoll ist informativ und leicht verständlich. Es enthält genau die Menge an Wissen, die Sie im Allgemeinen für die Fehlerbehebung Ihrer VUser-Skripte benötigen.

Im Fall des erweiterten Protokolls sind alle Standardprotokollinformationen eine Teilmenge. Darüber hinaus ist eine Parameterersetzung möglich. Dadurch wird die LoadRunner-Komponente angewiesen, vollständige Informationen zu allen Parametern (aus der Parametrisierung), einschließlich Anforderungen, sowie Antwortdaten einzuschließen.

Wenn Sie „Vom Server zurückgegebene Daten“ angeben, wird Ihr Protokoll länger. Dazu gehören alle HTML-, Tags-, Ressourcen- und Nicht-Ressourcen-Informationen, die direkt im Protokoll enthalten sind. Die Option ist nur dann sinnvoll, wenn Sie eine ernsthafte Fehlerbehebung benötigen. Normalerweise ist die Protokolldatei dadurch sehr groß und nicht leicht verständlich.

Wie Sie sich vielleicht schon gedacht haben, wird Ihre Protokolldatei riesig sein, wenn Sie sich für „Advance Trace“ entscheiden. Sie müssen es unbedingt ausprobieren. Sie werden feststellen, dass sich auch die von VUGen benötigte Zeit deutlich erhöht hat, obwohl dies keine Auswirkungen auf die von VUGen gemeldete Transaktionsantwortzeit hat. Dies sind jedoch sehr vorläufige Informationen und möglicherweise nützlich, wenn Sie die betreffende Anwendung, die Client-Server-Kommunikation zwischen Ihrer Anwendung und der Hardware sowie Einzelheiten auf Protokollebene verstehen. Normalerweise sind diese Informationen von ihrer Bedeutung her wertlos, da sie einen enormen Aufwand erfordern, um sie zu verstehen und Fehler zu beheben.

Tipps:

• Unabhängig davon, wie viel Zeit VUGen benötigt, wenn das Protokoll aktiviert ist, hat es keinen Einfluss auf die Reaktionszeit der Transaktion. HP bezeichnet dieses Phänomen als „modernste Technologie“.
• Deaktivieren Sie das Protokoll, wenn es nicht erforderlich ist.
• Deaktivieren Sie das Protokoll, wenn Sie mit Ihren Skripten fertig sind. Das Einbinden von Skripten mit aktivierter Protokollierung führt dazu, dass der Controller langsamer läuft und störende Meldungen meldet.
• Durch das Deaktivieren des Protokolls wird die Kapazität der maximalen Anzahl von Benutzern erhöht, die Sie von LoadRunner aus simulieren können.
• Erwägen Sie die Verwendung von „Nachricht nur senden, wenn ein Fehler auftritt“ – dadurch werden unnötige Informationsmeldungen stummgeschaltet und nur fehlerbezogene Meldungen gemeldet.

Denken Sie mal nach

Die Denkzeit ist einfach die Verzögerung zwischen zwei Schritten.

Think Time hilft bei der Replikation des Benutzerverhaltens, da kein echter Benutzer eine Anwendung wie eine Maschine (VUGen) verwenden kann. VUGen generiert automatisch Denkzeit. Sie haben weiterhin die vollständige Kontrolle darüber, wie Sie die Bedenkzeit entfernen, vervielfachen oder variieren können.

Um mehr zu verstehen, kann ein Benutzer beispielsweise einen Bildschirm öffnen (das ist eine Antwort, gefolgt von einer Anfrage) und dann seinen Benutzernamen und sein Passwort eingeben, bevor er die Eingabetaste drückt. Die nächste Interaktion der Anwendung mit dem Server erfolgt, wenn er auf „Anmelden“ klickt. Die Zeit, die ein Benutzer für die Eingabe seines Benutzernamens und Passworts benötigte, ist in LoadRunner die Denkzeit.

Wenn Sie eine aggressive Belastung der Anwendung simulieren möchten, sollten Sie die Bedenkzeit vollständig deaktivieren.

Um jedoch ein echtes ähnliches Verhalten zu simulieren, können Sie „Zufällige Denkzeit des Benutzers“ wählen und die Prozentsätze wie gewünscht festlegen.

Erwägen Sie, die Bedenkzeit auf einen legitimen Zeitraum zu begrenzen. Normalerweise reichen 30 Sekunden völlig aus.

Geschwindigkeitssimulation

Die Geschwindigkeitssimulation bezieht sich einfach auf die Bandbreitenkapazität für jeden Client-Computer.

Da wir Tausende von VUsern über LoadRunner simulieren, ist es erstaunlich, wie einfach LoadRunner die Steuerung der Bandbreiten-/Netzwerkgeschwindigkeitssimulation gemacht hat.

Wenn Ihre Kunden über 128 Kbit/s auf Ihre Anwendung zugreifen, können Sie diese von hier aus steuern. Sie können ein „echtes Verhalten“ simulieren, was dabei helfen soll, die richtigen Leistungsstatistiken zu erhalten.

Die beste Empfehlung ist die Einstellung „Maximale Bandbreite verwenden“. Dies hilft dabei, netzwerkbezogene Leistungsengpässe zu ignorieren und sich zunächst auf potenzielle Probleme in der Anwendung zu konzentrieren. Sie können den Test jederzeit mehrmals ausführen, um unterschiedliches Verhalten unter verschiedenen Umständen festzustellen.

Browser-Emulation

Die Benutzererfahrung hängt nicht vom Browser ab, den ein Endbenutzer verwendet. Dies liegt eindeutig außerhalb des Rahmens von Leistungsmessungen. Sie können jedoch auswählen, welchen Browser Sie emulieren möchten.

Können Sie sich selbst sagen, wann genau es für Sie in dieser Konfiguration wirklich darauf ankommt, den richtigen Browser auszuwählen?

Sie verwenden diese Konfiguration, wenn es sich bei Ihrer Subjektanwendung um eine Webanwendung handelt, die für verschiedene Browser unterschiedliche Antworten zurückgibt. Beispielsweise können Sie verschiedene Bilder und Inhalte für IE und sehen Firefox usw.

Eine weitere wichtige Einstellung ist Browser-Cache simulieren. Wenn Sie die Reaktionszeit bei aktiviertem Cache messen möchten, aktivieren Sie dieses Kontrollkästchen. Wenn Sie nach dem Worst-Case-Szenario suchen, spielt dies natürlich keine Rolle.

Durch das Herunterladen von Nicht-HTML-Ressourcen kann LoadRunner alle CSS-, JS- und anderen Rich Media-Inhalte herunterladen. Dies sollte überprüft bleiben. Wenn Sie dies jedoch aus Ihrem Leistungstestdesign entfernen möchten, können Sie dies deaktivieren.

Proxy

Es ist am besten, den Proxy vollständig von Ihrem Computer zu entfernen Test Umgebung – Dadurch werden die Testergebnisse unzuverlässig. Es kann jedoch vorkommen, dass Sie mit Situationen konfrontiert werden, in denen dies unvermeidlich ist. In einer solchen Situation erleichtert Ihnen LoadRunner die Proxy-Einstellungen.

Sie arbeiten (oder sollten arbeiten) mit der Einstellung „Kein Proxy“. Sie können es über Ihren Standardbrowser abrufen. Vergessen Sie jedoch nicht zu prüfen, welcher Browser als Standard eingestellt ist und welche Proxy-Konfiguration für den Standardbrowser vorliegt.

Wenn Sie einen Proxy verwenden und dieser eine Authentifizierung (oder ein Skript) erfordert, können Sie auf die Schaltfläche „Authentifizieren“ klicken, die zu einem neuen Fenster führt. Siehe Screenshot unten.

Verwenden Sie diesen Bildschirm, um Benutzernamen und Passwort einzugeben, um sich auf dem Proxyserver authentifizieren zu lassen. Klicken Sie auf OK, um den Bildschirm zu schließen.

Glückwunsch. Sie sind mit der Konfiguration Ihres VUGen-Skripts fertig. Vergessen Sie nicht, es für alle Ihre VUser-Skripte zu konfigurieren.