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 Verhalten eines realen Benutzers nachzubilden.

Wenn ein Skript aufgezeichnet wird, beschreibt es einen einzelnen, geradlinigen Ablauf innerhalb der Anwendung. Ein echter Benutzer kann einen Prozess jedoch mehrmals durchlaufen, bevor er sich abmeldet. Die Verzögerung zwischen den Klicks (die sogenannte Denkzeit) variiert von Person zu Person, und manche Benutzer greifen über eine schnelle Internetverbindung auf Ihre Anwendung zu, andere nicht. Um also ein realistisches Benutzererlebnis zu erzielen, müssen wir unsere Skripte so optimieren, dass sie sich möglichst nah an das Verhalten echter Benutzer anpassen.

Das ist der wichtigste Aspekt bei der Durchführung von „Performance Testing„…“, aber ein VUser-Skript umfasst mehr. Wie messen Sie die Zeit, die ein VUser während des Lasttests (SUL) benötigt? Wie erkennen Sie, ob der VUser den Test erfolgreich abgeschlossen hat oder nicht, und wie erkennen Sie, ob ein Backend-Prozess ausgefallen ist oder die Serverressourcen nicht ausreichten?

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

Markenhinweis: VuGen wurde ursprünglich als HP, dann als Micro Focus vertrieben und ist jetzt Teil von OpenText Professionelles Performance EngineeringDie folgenden Funktionen und Einstellungen bleiben unverändert.

Verwenden von Transaktionen

Transaktionen messen die Serverantwortzeit für beliebige Operationen. Vereinfacht gesagt, misst eine „Transaktion“ die Zeit, die das System für eine bestimmte Anfrage benötigt. Das kann so einfach sein wie ein Klick auf eine Schaltfläche oder ein AJAX-Aufruf, der ausgelöst wird, wenn ein Textfeld den Fokus verliert.

Transaktionen anzuwenden ist unkompliziert. Schreiben Sie eine Codezeile vor der Anfrage und schließen Sie die Transaktion nach deren Abschluss. 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

Ejemplo:

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);

Code Hinweise: Die Codeausschnitte werden exakt wie veröffentlicht wiedergegeben, inklusive typografischer Anführungszeichen. Ein echtes VuGen-Skript benötigt jedoch doppelte ASCII-Anführungszeichen. Geben Sie diese daher neu ein, wenn Sie diesen Code kopieren.

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.
• Der Punkt (.) ist im Transaktionsnamen nicht zulässig, Leerzeichen und Unterstriche hingegen schon.
• Wenn Ihr Code gut strukturiert ist und Prüfpunkte zur Überprüfung der Serverantwort hinzugefügt wurden, können Sie eine benutzerdefinierte Fehlerbehandlung wie LR_PASS oder LR_FAIL verwenden. Andernfalls können Sie LR_AUTO verwenden; LoadRunner behandelt dann Serverfehler (HTTP 500, 400 usw.) automatisch.
• Achten Sie bei der Anwendung von Transaktionen darauf, dass keine Wartezeitanweisung zwischen den Transaktionen enthalten ist, da Ihre Transaktion sonst immer diesen Zeitraum einschließt.
• Da LoadRunner einen konstanten String als Transaktionsnamen benötigt, ist ein häufiges Problem beim Anwenden von Transaktionen die Diskrepanz der Strings. Wenn Sie beim Öffnen und Schließen einer Transaktion unterschiedliche Namen verwenden, erhalten Sie mindestens zwei Fehler. Die geöffnete Transaktion wurde nie geschlossen, daher gibt LoadRunner einen Fehler aus; und die zu schließende Transaktion wurde nie geöffnet, was einen zweiten Fehler verursacht.
• Beide Fehler erscheinen im Wiedergabeprotokoll. Überprüfen Sie daher immer zuerst den Transaktionsnamen in den Eröffnungs- und Abschlussbelegen, wenn einer der beiden Fehler gemeldet wird.
• Da LoadRunner die Synchronisierung von Anfragen und Antworten automatisch übernimmt, müssen Sie sich beim Anwenden von Transaktionen keine Gedanken über die Antwort machen.

Treffpunkte, Kommentare und Skriptfunktionen

Drei kleinere Verbesserungen sorgen dafür, dass sich ein Skript wie Produktionscode verhält und liest: Rendezvous-Punkte, Kommentare und der in VuGen integrierte Funktionsbrowser.

Treffpunkte

Ein Rendezvous-Punkt ist ein „Treffpunkt“. Es handelt sich um eine einzelne Anweisung, die LoadRunner anweist, Parallelverarbeitung einzuführen. Sie fügen Rendezvous-Punkte in VUser-Skripte ein, um eine hohe Benutzerlast auf dem Server zu simulieren.

Rendezvous-Punkte weisen einen virtuellen Benutzer (VUser) an, während der Ausführung zu warten, bis mehrere VUser an einem bestimmten Punkt eintreffen, um eine Aufgabe gleichzeitig auszuführen. Um beispielsweise eine Spitzenlast auf einem Bankserver zu simulieren, kann ein Rendezvous-Punkt eingefügt werden, der 100 VUser anweist, gleichzeitig Bargeld einzuzahlen.

Sind die Rendezvous-Punkte nicht korrekt platziert, greifen die virtuellen Benutzer selbst bei demselben Skript auf unterschiedliche Teile der Anwendung zu. Dies liegt daran, dass jeder virtuelle Benutzer eine unterschiedliche Antwortzeit erhält und es daher bei einigen Benutzern zu Verzögerungen kommt.

Syntax:

lr_rendezvous(“Logical Name”);

Korrekturhinweis: Die veröffentlichte Seite buchstabiert dies lr_rendesvousDer korrekte Funktionsname lautet: lr_rendezvousDie fehlerhafte Form lässt sich nicht kompilieren.

Best Practices:

• Stellen Sie einem Rendezvous-Punkt „rdv_“ voran, um die Lesbarkeit des Codes zu verbessern. zB „rdv_Login“
• Entfernen Sie alle unmittelbar angrenzenden Denkzeitaussagen.
• Nach der Aufzeichnung Rendezvouspunkte in der Skriptansicht anwenden.

Die untenstehende Skriptansicht zeigt eine in eine aufgezeichnete Aktion eingefügte Rendezvous-Anweisung:

Kommentare

Fügen Sie Kommentare hinzu, um eine Aktivität, einen Codeabschnitt oder eine Codezeile zu beschreiben. Kommentare tragen dazu bei, dass der Code für alle, die ihn später verwenden, verständlicher wird. Sie liefern Informationen zu einer bestimmten Operation und trennen zwei Abschnitte zur besseren Unterscheidung.

Sie können Kommentare hinzufügen

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

Best Practice: Markieren Sie alle Kommentare am Anfang jeder Skriptdatei.

Funktionen über das Menü einfügen

Sie können zwar direkt einfache Codezeilen schreiben, benötigen aber möglicherweise einen Hinweis, um sich an eine Funktion zu erinnern. Alternativ können Sie die Schritte-Toolbox (vor Version 12 als „Funktion einfügen“ bekannt) verwenden, um beliebige Funktionen zu finden und direkt in Ihr Skript einzufügen.

Die Schritte-Toolbox finden Sie unter Ansicht → Schritte-Toolbox, wie unten dargestellt.

Dadurch öffnet sich ein Seitenfenster. Schauen Sie sich den Screenshot an:

Was ist Parametrisierung?

Ein Parameter in VuGen ist ein Container, der einen gespeicherten Wert enthält, der für verschiedene Benutzer ersetzt wird.

Während der Ausführung des Skripts (in VuGen oder dem Controller), wird der vorherige Wert des Parameters durch einen Wert aus einer externen Quelle (z. B. einer .txt-Datei, XML oder einer Datenbank) ersetzt.

Parametrisierung ist nützlich, um dynamische (oder eindeutige) Werte an den Server zu senden. Beispielsweise kann es erforderlich sein, dass ein Geschäftsprozess 10 Iterationen durchläuft und dabei jedes Mal einen eindeutigen Benutzernamen auswählt.

Es hilft auch dabei, das Verhalten des betreffenden Systems im realen Leben zu simulieren. Sehen Sie sich die folgenden Beispiele an.

Problembeispiele:

• Ein Geschäftsprozess funktioniert nur für das aktuelle Datum, das vom Server stammt, daher kann es nicht als fest codierte Anfrage übergeben werden.
• Manchmal übergibt die Clientanwendung dem Server eine eindeutige ID (z. B. session_id), damit der Prozess fortgesetzt werden kann, selbst für nur einen Benutzer. In einem solchen Fall ist die Parametrisierung hilfreich.
• Die Clientanwendung speichert häufig einen Cache der Daten, die an den Server gesendet und von ihm empfangen werden. Dadurch erhält der Server kein tatsächliches Nutzerverhalten (bei dem der Server je nach Suchkriterien einen anderen Algorithmus ausführt). Das VUser-Skript wird zwar erfolgreich ausgeführt, die erfassten Leistungsstatistiken sind jedoch nicht aussagekräftig. Die Verwendung unterschiedlicher Daten durch Parametrisierung hilft, serverseitige Aktivitäten wie gespeicherte Prozeduren zu simulieren und das System zu testen.
• Ein während der Aufzeichnung im virtuellen Benutzer (VUser) fest codiertes Datum ist möglicherweise nach Ablauf dieses Datums nicht mehr gültig. Durch Parametrisierung des Datums kann die Ausführung des VUsers erfolgreich fortgesetzt werden, indem das fest codierte Datum ersetzt wird. Solche Felder oder Anfragen eignen sich für die Parametrisierung.

Sie erstellen einen solchen Wert, indem Sie in der Skriptansicht mit der rechten Maustaste auf den aufgezeichneten Wert klicken und „Durch einen Parameter ersetzen“ auswählen. VuGen fragt dann, welcher Datentyp den Wert liefert:

Zwei weitere Optionen legen fest, wie Daten über Iterationen hinweg genutzt werden:

Die folgende Schritt-für-Schritt-Anleitung zeigt die Parametrisierung eines aufgezeichneten Skripts:

Klicken Sie auf werden auf dieser Seite erläutert wenn das Video nicht zugänglich ist.

Laufzeiteinstellungen und deren Auswirkungen auf die VUser-Simulation

Die Laufzeiteinstellungen sind genauso wichtig wie Ihr VuGen-Skript. Unterschiedliche Konfigurationen können zu völlig verschiedenen Testdesigns führen. Daher sind inkonsistente Laufzeiteinstellungen die häufigste Ursache für nicht reproduzierbare Ergebnisse. Betrachten wir nun jedes Attribut einzeln.

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 vermutlich deutlicher, warum LoadRunner empfiehlt, kee zu verwenden.ping Der gesamte Login-Code befindet sich in vuser_init und der Logout-Teil in vuser_end, jeweils separat.

Wenn Sie mehrere Aktionen erstellt haben – beispielsweise Anmelden, Bildschirm öffnen, Miete berechnen, Geld senden, Kontostand prüfen und Abmelden – dann läuft für jeden virtuellen Benutzer das folgende Szenario ab:

Alle virtuellen Benutzer melden sich an, führen die Schritte „Bildschirm öffnen“, „Miete berechnen“, „Geld einzahlen“ und „Kontostand prüfen“ aus, dann erneut „Bildschirm öffnen“, „Miete berechnen“ usw., und wiederholen diesen Vorgang 10 Mal, bevor sie sich einmal abmelden.

Dies ist eine leistungsstarke Einstellung, die es dem Skript ermöglicht, sich wie ein echter Benutzer zu verhalten. Denken Sie daran: Ein echter Benutzer meldet sich nicht jedes Mal an und ab; er wiederholt in der Regel dieselben Schritte.

Wie oft klicken Sie auf „Posteingang“, bevor Sie Ihre E-Mails abrufen und sich abmelden?

Pacing

Das ist wichtig. Die meisten Menschen verstehen den Unterschied zwischen Arbeitstempo und Bedenkzeit nicht. Der einzige Unterschied besteht darin, dass sich das Arbeitstempo auf die Verzögerung zwischen den Iterationen bezieht, während die Bedenkzeit die Verzögerung zwischen zwei beliebigen Schritten ist.

Die empfohlene Einstellung hängt vom Testdesign ab. Wenn Sie jedoch eine hohe Last anwenden möchten, sollten Sie die Option „Sobald die vorherige Iteration beendet ist“ wählen, wie unten dargestellt.

Log

Ein Log ist im Allgemeinen eine Aufzeichnung aller Ereignisse während der Ausführung von LoadRunner. Sie können das Log aktivieren, um die Vorgänge zwischen Ihrer Anwendung und Ihrem Server nachzuvollziehen.

LoadRunner bietet einen leistungsstarken, robusten und skalierbaren Protokollierungsmechanismus. Sie können entweder nur ein „Standardprotokoll“ oder ein detailliertes und konfigurierbares erweitertes Protokoll führen oder die Protokollierung vollständig deaktivieren.

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

Im erweiterten Protokoll ist die Standardprotokollinformation nur eine Teilmenge. Zusätzlich kann die Parameterersetzung aktiviert werden. Dadurch wird die LoadRunner-Komponente angewiesen, vollständige Informationen zu allen Parametern (aus der Parametrisierung) einzuschließen, einschließlich Anfrage- und Antwortdaten.

Wenn Sie „Vom Server zurückgegebene Daten“ einbeziehen, wird Ihre Protokolldatei deutlich länger. Sie enthält dann sämtliche HTML-Codes, Tags, Ressourcen und sonstige Informationen direkt im Protokoll. Diese Option ist nur dann sinnvoll, wenn Sie eine umfassende Fehlerbehebung benötigen. In der Regel wird die Protokolldatei dadurch sehr groß und unübersichtlich.

Wie Sie sich inzwischen sicher schon gedacht haben, wenn Sie sich für „Erweitert“ entscheiden TracIhre Protokolldatei wird riesig sein. Sie müssen es unbedingt ausprobieren. Sie werden feststellen, dass sich die von VuGen benötigte Zeit ebenfalls deutlich erhöht, obwohl dies keinen Einfluss auf die von VuGen gemeldete Transaktionsantwortzeit hat. Dies sind sehr fortgeschrittene Informationen, die nur dann nützlich sind, wenn Sie die betreffende Anwendung, die Client-Server-Kommunikation zwischen Ihrer Anwendung und der Hardware sowie Details auf Protokollebene verstehen. Normalerweise erfordert das Lesen und die Fehlersuche dieser Informationen einen erheblichen Aufwand.

Tipps:

• Unabhängig davon, wie lange VuGen benötigt, wenn die Protokollierung aktiviert ist, hat dies keinen Einfluss auf die Transaktionsantwortzeit – der Protokollierungsaufwand wird nicht in die gemessene Zeit einbezogen.
• Deaktivieren Sie das Protokoll, wenn es nicht benötigt wird.
• Deaktivieren Sie die Protokollierung, sobald Sie Ihre Skripte abgeschlossen haben. Skripte mit aktivierter Protokollierung führen dazu, dass der Controller langsamer läuft und unnötige Fehlermeldungen ausgibt.
• Durch Deaktivieren der Protokollierung erhöht sich die maximale Anzahl der Benutzer, die Sie mit LoadRunner simulieren können.
• Erwägen Sie die Verwendung der Option „Nachrichten nur bei Fehlern senden“ – dadurch werden unnötige Informationsmeldungen unterdrückt und nur fehlerbezogene Meldungen ausgegeben.

Denken Sie mal nach

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

Die Denkzeit hilft, das Nutzerverhalten nachzubilden, da kein echter Nutzer eine Anwendung wie eine Maschine bedienen kann. VuGen generiert die Denkzeit automatisch. Sie haben weiterhin die volle Kontrolle darüber, wie lange die Denkzeit ansteigt, ob sie entfernt, vervielfacht oder variiert wird.

Um es besser zu verstehen: Ein Benutzer öffnet ein Fenster (eine Antwort, gefolgt von einer Anfrage) und gibt dann Benutzername und Passwort ein, bevor er die Eingabetaste drückt. Die nächste Interaktion zwischen Anwendung und Server erfolgt, wenn der Benutzer auf „Anmelden“ klickt. Die Zeit, die der Benutzer für die Eingabe von Benutzername und Passwort benötigt, wird in LoadRunner als Denkzeit bezeichnet.

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

Um jedoch ein realistisches Verhalten zu simulieren, können Sie „Zufällige Denkzeit verwenden“ auswählen und die Prozentsätze nach Wunsch festlegen.

Erwägen Sie, die Denkzeit mit „Limit Think Time“ auf einen angemessenen Zeitraum zu begrenzen. Normalerweise sind 30 Sekunden ausreichend.

Geschwindigkeitssimulation

Die Geschwindigkeitssimulation bezieht sich einfach auf die Bandbreitenkapazität jedes Client-Rechners.

Da wir Tausende von virtuellen Benutzern mit LoadRunner simulieren, ist es bemerkenswert, wie einfach LoadRunner die Simulation von Bandbreite und Netzwerkgeschwindigkeit gestaltet hat.

Wenn Ihre Kunden mit einer Bandbreite von über 128 kbit/s auf Ihre Anwendung zugreifen, können Sie dies hier steuern. Sie können realitätsnahe Zugriffsmuster simulieren, was Ihnen helfen sollte, die korrekten Leistungsstatistiken zu erhalten.

Die beste Empfehlung ist, die maximale Bandbreite zu verwenden. Dadurch können Sie netzwerkbedingte Leistungsengpässe ausblenden und sich zunächst auf potenzielle Probleme in der Anwendung konzentrieren. Sie können den Test jederzeit mehrmals ausführen, um das Verhalten unter verschiedenen Bedingungen zu beobachten.

Browser-Emulation

Die Benutzererfahrung hängt nicht vom verwendeten Browser ab und liegt daher weitgehend außerhalb des Rahmens von Leistungsmessungen. Sie können jedoch auswählen, welchen Browser Sie emulieren möchten, wie im folgenden Bereich dargestellt.

Wann genau spielt es in dieser Konfiguration eine Rolle, welchen Browser man auswählt?

Sie verwenden diese Konfiguration, wenn es sich bei Ihrer Anwendung um eine Webanwendung handelt, die für verschiedene Browser unterschiedliche Antworten liefert. Beispielsweise werden für Internet Explorer und Windows Explorer möglicherweise unterschiedliche Bilder und Inhalte angezeigt. Firefox.

Eine weitere wichtige Einstellung ist die Browser-Cache-Simulation. Wenn Sie die Antwortzeit mit aktiviertem Cache messen möchten, aktivieren Sie dieses Kontrollkästchen. Wenn Sie den ungünstigsten Fall untersuchen möchten, ist dies natürlich irrelevant.

Die Option „Nicht-HTML-Ressourcen herunterladen“ ermöglicht LoadRunner das Herunterladen von CSS, JS und anderen Rich Media-Dateien. Diese Option sollte aktiviert bleiben. Wenn Sie sie jedoch aus Ihrem Performance-Testdesign ausschließen möchten, können Sie sie deaktivieren.

Proxy

Am besten ist es, den Proxy vollständig von Ihrem System zu entfernen. Test Umgebung Ein Proxy im Testpfad macht die Testergebnisse unzuverlässig. Es kann jedoch Situationen geben, in denen dies unvermeidbar ist. In solchen Fällen bietet LoadRunner Proxy-Einstellungen.

Sie arbeiten (oder sollten arbeiten) mit der Einstellung „Kein Proxy“. Diese Einstellung finden Sie in Ihrem Standardbrowser. Vergessen Sie jedoch nicht zu überprüfen, welcher Browser als Standard festgelegt ist und welche Proxy-Konfiguration dieser Browser verwendet.

Wenn Sie einen Proxy verwenden, der eine Authentifizierung (oder ein Skript) erfordert, können Sie auf die Schaltfläche „Authentifizieren“ klicken. Dadurch öffnet sich ein neues Fenster. Siehe Screenshot unten.

Geben Sie auf diesem Bildschirm einen Benutzernamen und ein Passwort für die Authentifizierung am Proxy-Server ein. Klicken Sie auf OK, um das Fenster zu schließen.

Herzlichen Glückwunsch! Die Konfiguration Ihres VuGen-Skripts ist abgeschlossen. Vergessen Sie nicht, es auch für alle Ihre VUser-Skripte zu konfigurieren.

Als nächstes kommen Korrelation, das Szenario in der Controllerund Leseergebnisse LoadRunner-Analyse. Siehe LoadRunner-Architektur und Load Testing Führer.

Häufig gestellte Fragen