Glossar

API

Ein "Application Programming Interface" ist eine von einem Softwaresystem bereitgestellte Programmierschnittstelle. Sie ermöglicht Entwicklern die Erweiterung des Softwaresystems oder die Nutzung der vom Softwaresystem angebotenen Funktionalität durch eigene Programme.

Action (XLT)

Eine "Action" im XLT-Programmiermodell repräsentiert einen einzelnen, abgeschlossenen Schritt in einem Testfall. Konzeptuell sind Actions wiederverwendbare Bausteine, die in unterschiedlichen Testfällen genutzt werden können. Eine wichtige Action beim Test einer Web-Suchmaschine ist beispielsweise das Eingeben eines Suchbegriffs mit dem anschließenden Klick auf den "Suchen"-Knopf, um die Liste der Ergebnisse abzurufen. Eine Action kann einen oder mehrere Requests auslösen.

Agent (XLT)

Ein Agent simuliert eine Anzahl virtueller Nutzer, die wiederholt bestimmte Testfälle gegen das zu testende System ausführen.

Agent Controller (XLT)

Auf jeder lasterzeugenden Maschine gibt es mindestens einen Agent Controller, der vom Master Controller Befehle und Daten empfängt und Testergebnisse zurücksendet. Die Agent Controller steuern aus ihrer Sicht lokale Agenten-Prozesse, die die eigentliche Lasterzeugung ausführen.

Ankunftsrate / Arrival Rate

Siehe "Konstante Ankunftsrate".

Antwortzeit / Response Time

Zeitspanne vom Absenden eines Auftrages (Request) bis zum Eintreffen der Antwort (Response). Die gesamte Antwortzeit besteht aus verschiedenen Komponenten. Dazu gehören die Übertragung der Anfrage vom Client zum Server, die eventuelle Wartezeit beim Server bis zur Bearbeitung, die Bearbeitungszeit und die Übertragung der Antwort zurück zum Client. Bei der Übertragung und der Verarbeitung eines Requests können mehrere Zwischenstationen, beispielsweise andere Server, beteiligt sein. Auf der Seite des Clients kann schließlich noch die Zeit für die Interpretation und Anzeige der Antwort hinzukommen. Bei einem Webbrowser sind das beispielsweise das Laden von CSS und Bildern, der Aufbau des DOM, das Laden und die Interpretation von JavaScript und das Rendern der Anzeige. Bei der Simulation durch XLT entfällt das Rendern, da client-seitig ein Headless Browser genutzt wird. Browser-Caching verkürzt die Antwortzeiten entsprechend, wenn bestimmte Requests direkt aus dem Browser Cache beantwortet werden können, ohne zum Server gesendet werden zu müssen. Bei der Interpretation von Antwortzeiten ist immer genau zu prüfen, welche Zeitkomponenten enthalten sind und welche Systeme an der Datenübertragung und Berechnung der Antwort beteiligt waren.

Arithmetisches Mittel (auch "Durchschnitt" oder "Mittelwert") / Arithmetic Mean

Das arithmetische Mittel wird gebildet, indem die Summe aller Werte durch die Anzahl der Werte geteilt wird. Bei der Bewertung von Lasttest-Ergebnissen, beispielsweise bei Antwortzeiten, ist das arithmetische Mittel allein nicht ausreichend, da einzelne, stark abweichende Werte das arithmetische Mittel zu stark beeinflussen.

Bei fünf Antwortzeiten kann ein arithmetisches Mittel von 5s bedeuten, dass alle Requests jeweils in 5s beantwortet wurden. Eine Antwort könnte aber auch 21s benötigt haben und die anderen vier Antworten jeweils 1s. Daher sollten neben dem arithmetischen Mittel immer auch Metriken wie Minimalwerte, Maximalwerte, die Standardabweichung und der Median betrachtet werden.

Capture & Replay Tool, auch Capture & Playback Tool

Typ von Testwerkzeugen, bei dem von einem Tester manuell ausgeführte Schritte aufgezeichnet werden und vom Testwerkzeug später automatisch abgespielt werden können. Reines Capture & Replay ist im Allgemeinen nicht ausreichend und daher oft nur ergänzend in einem umfassenderen Testwerkzeug vorhanden oder es wird durch weitere Bearbeitungsmöglichkeiten ergänzt. Zumindest müssen aufgezeichnete Testfälle meist manuell erweitert werden, um wiederverwendbare und robuste Testscripte zu erhalten. Häufige Probleme mit reinen aufgezeichneten Scripten sind:

• mangelnde Dynamik - in einem Online-Shop werden zum Beispiel immer wieder die gleichen Produktseiten aufgerufen, statt diese zufällig aus einer Liste auszuwählen oder dynamisch zu crawlen
• geringe Robustheit gegenüber veränderten Testdaten - zum Beispiel fehlende Reaktionsmöglichkeiten, wenn sich bei verwendeten Suchwörtern die Anzahl der Ergebnisse ändert; bei null Treffern erscheint vielleicht das Suchformular erneut, bei einem Treffer erscheint sofort die Ergebnisseite, bei mehreren Treffern erscheint eine Auswahlliste
• geringe Robustheit gegenüber Veränderungen in der zu testenden Anwendung selbst
• Ansammlung vieler kleiner, unabhängiger Testscripte statt einer strukturierten Architektur der Testsuite; mangelnde Wiederverwendung und schlechte Wartbarkeit
• oft nicht ausreichend berücksichtigte Validierung von Ergebnissen

Client

Prozess im Client-Server-Modell, welcher Anfragen zu einem anderen Prozess (Server) sendet, um eine dort angebotene Dienstleistung zu nutzen. Clients eines Webservers sind zum Beispiel Webbrowser, Suchmaschinen-Roboter oder im Fall eines Lasttests die virtuellen Nutzer mit ihrem eingebetteten Browser.

Cookie

Kleine Informationsmenge, die meist zusammen mit einer HTTP/HTTPS-Response von einem Webserver zum Webbrowser gesendet und vom Webbrowser gespeichert wird. Der Webbrowser fügt das Cookie zukünftigen Requests wieder hinzu, die an den gleichen Webserver gesendet werden, von dem das Cookie stammt. So kann der Webserver die im Cookie enthaltenen Informationen auswerten, um beispielsweise einen bestimmten Nutzer wiederzuerkennen. Cookies werden im HTTP-Header übertragen. Ein Cookie besteht mindestens aus einem Namen und den Nutzdaten, die meist nur von dem Server interpretiert werden können, der das Cookie erzeugt hat. Cookies können alternativ aber auch auf der Seite des Webbrowsers mit Hilfe von JavaScript erzeugt, ausgelesen und genutzt werden.

Cookies können transient oder persistent sein. Transiente Cookies werden meist nur im Hauptspeicher des Browserprozesses abgelegt, so dass ihre Lebensdauer auf die Laufzeit des Webbrowsers beschränkt ist. Persistente Cookies werden dagegen bei der Erzeugung mit einer Angabe zu einer gewünschten Lebensdauer versehen und vom Webbrowser im Dateisystem abgelegt. Dadurch sind persistente Cookies auch noch nach dem Neustart des Webbrowsers oder des Client-Rechners verfügbar.

Denkzeit / Think Time

Zeit zwischen dem Eintreffen einer Response vom Server beim Client und dem Absenden des nächsten Requests durch den Client. Die Think Time stellt aus Sicht des Servers eine Pause des Nutzer dar. Ein realer Nutzer benötigt diese Zeit beispielsweise, um Text auf der abgerufenen Webseite zu lesen, einen Link oder Button auszuwählen oder um ein Formular auszufüllen. In XLT können separate Werte für Think Times zwischen Actions und Think Times zwischen Transactions konfiguriert werden. Außerdem können die Think Times zufällig variiert werden.

Dauerlasttest / Endurance Test

Dauerlasttests sind Lasttests, die kontinuierlich über einen längeren Zeitraum laufen. Ziel ist die Prüfung der Langzeitstabilität des getesteten Systems sowie des Ressourcenbedarfs (beispielsweise Memory Leaks) und des Antwortzeitverhaltens. Die Testdauer beträgt oft 12h bis mehrere Tage. Es wird beispielsweise die später im Produktivbetrieb erwartete Last oder eine Last etwa 30% unter der im Stresstest ermittelten Maximallast simuliert. Dauerlasttests werden auch Stabilitätstests genannt.

DOM

Das "Document Object Model" ist ein durch das W3C standardisiertes API für den Zugriff auf HTML- und XML-Dokumente. Moderne Webbrowser nutzen das DOM als Repräsentation für Webseiten und erlauben den Zugriff darauf mittels JavaScript. Das ermöglicht das Lesen und Ändern von Inhalt, Struktur und Layout eines Dokuments. So kann beispielsweise die Darstellung einer Webseite in einem Webbrowser durch Zugriffe auf das DOM mittels JavaScript dynamisch geändert werden.

Durchsatz / Throughput

Maß für die Menge an Anfragen oder Daten, die innerhalb eines festgelegten Zeitraums verarbeitet oder übertragen werden. Bei Lasttests sind das beispielsweise die Anzahl der verarbeiteten Requests pro Zeiteinheit oder die pro Zeiteinheit vom Server zu den virtuellen Nutzern übertragene Datenmenge.

Effizienz / Efficiency

Die Effizienz ist ein Qualitätsmerkmal nach ISO 9126. Sie beschreibt die Leistung der Software im Verhältnis zu den eingesetzten Betriebsmitteln. Es werden zwei Untermerkmale unterschieden, das Zeitverhalten und das Verbrauchsverhalten. Das Zeitverhalten umfasst die Antwort- und Verarbeitungszeiten sowie den Durchsatz. Das Verbrauchsverhalten beschreibt die Menge und Dauer der benötigten Betriebsmittel.

End-Zu-End-Test / End-To-End Test

Ein End-Zu-End-Test testet ein Gesamtsystem aus Sicht des Endanwenders oder Dienstnutzers. Ein solcher Test schließt alle Komponenten ein, die an der Erbringung der Dienstleistung beteiligt sind.

Für einen automatisierten End-Zu-End-Test oder für das End-Zu-End-Monitoring wird mit Hilfe einer Testsoftware das Verhalten der Nutzer simuliert. Eine Anfrage durchläuft dann das System vom Client über alle Zwischenschichten zu allen beteiligten Servern und Backendsystemen, bis die Antwort schließlich wieder beim Client eintrifft ("End-Zu-End"). Dort wird sie verifiziert, zum Beispiel hinsichtlich Verfügbarkeit, Antwortzeiten und funktionaler Korrektheit.

Entwicklungs-Modus / Development-Mode (XLT)

XLT-Testfälle, die nicht vom Master Controller und den Agents, sondern von einem beliebigen JUnit-Testrunner als direkte JUnit-Test ausgeführt werden, arbeiten automatisch im Development-Mode. Das ist zum Beispiel bei der Ausführung von XLT-Testfällen durch Eclipse oder ANT der Fall. Im Development-Mode werden zusätzliche Property-Dateien eingelesen. Dadurch ist es möglich, Einstellungen für lokale Testläufe während der Entwicklung umzudefinieren, ohne die Lasttesteinstellungen des verteilten Modus zu verändern oder zu gefährden.

Favicon

"Favicon" ist die abgekürzte Schreibweise für "Favourite Icon". Es handelt sich um eine Grafik im Windows-Icon-Format, welche unter anderem in der Adresszeile eines Webbrowsers oder neben einem im Browser gesetzten Lesezeichen (Favorit) angezeigt wird. Die Favicon-Datei muss dazu im Wurzelverzeichnis einer Domain erreichbar sein:

http://www.mysite.com/favicon.ico

 
Alternativ kann man auch im Kopf einer HTML-Datei eine URI zur Favicon-Datei angeben:

<link rel="shortcut icon" type="image/x-icon" href="/favicon.ico">

 
Von vielen Webbrowsern wird automatisch ein Request auf die Favicon-Datei ausgeführt, wenn der Nutzer einen Link aus dieser Domain zu seinen Favoriten hinzufügt. Wenn der Server die Datei nicht findet, liefert er HTTP-Code 404 zurück. Das Favicon wurde ursprünglich von Microsoft mit einer früheren Version des Internet Explorer eingeführt.

Flaschenhals / Bottleneck

Als "Bottleneck" bezeichnet man eine Hardware- oder Softwarekomponente, die so hoch ausgelastet oder so ineffizient ist, dass sie maßgeblich die Gesamtleistung eines Systems begrenzt. Wenn diese Komponente optimiert oder mit höherer Leistung ausgestattet wird, steigt die Performance des Gesamtsystems. Wenn unter Last alle Komponenten gleichmäßig ausgelastet sind und gleichermaßen zum Antwortverhalten des Gesamtsystems beitragen, exisitert kein Bottleneck.

Flash Cookie

Siehe "Local Shared Object".

Flow (XLT)

Gelegentlich möchte man in XLT-Testfällen größere Blöcke wiederverwenden, die mehr als nur eine einzelne Action enthalten. Dazu erstellt man eine eigene Klasse mit einer Methode, die eine Abfolge mehrerer XLT-Actions zu einem sogenannten "Flow" zusammenfasst. Unterschiedliche Testfälle können diese Methode nun aufrufen, um den Flow wiederzuverwenden. Es handelt sich hierbei um ein Konzept, welches man bei Bedarf implementieren kann, für das aber im XLT-Framework keine explizite Unterstützung implementiert oder notwendig ist.

Google WebDriver

Google WebDriver ist ein Werkzeug zum automatisierten Test von Webanwendungen. Damit werden entweder reale Webbrowser gesteuert oder Web-Nutzer werden direkt simuliert. Google WebDriver besitzt ein einfaches und effizient nutzbares API. In XLT wird für die schnelle Erstellung einfacher Testfälle auch das Google WebDriver API unterstützt.

Fremde Testfälle, die gegen das Google WebDriver API programmiert wurden, können daher grundsätzlich auch in XLT ausgeführt werden. (Umgekehrt gilt das nur eingeschränkt, denn in XLT wurde das Google WebDriver API um das Setzen von Action-Namen erweitert. In XLT gegen dieses API programmierte Testfälle müssten daher eventuell angepasst werden, bevor sie mit einem Google-WebDriver-kompatiblen Testtreiber ausgeführt werden könnten.)

Headless Browser

Als "Headless Browser" bezeichnet man einen Webbrowser ohne GUI-Komponente. In XLT benutzen die virtuellen Nutzer einen eingebetteten Headless Browser zum Laden und interpretieren von HTML-Seiten, zum Aufbau des DOM, zur Ausführung von JavaScript usw. Nur so lassen sich auf einem Betriebssystem, welches typischer Weise die Ressource "GUI" nur einmal zur Verfügung stellt, mehrere virtuelle Nutzer mit eignenen, unabhängigen Webbrowsern simulieren.

Hit

Ein "HTTP Hit" (deutsch: Treffer) bezeichnet einen bei einem Webserver eintreffenden Request. Jede einzelne abgerufene Datei wird als ein Hit gezählt. Für die Anzeige einer HTML-Seite in einem Webrowser sind meist mehrere, oft einige zehn, Hits notwendig. Hits sind beispielsweise der ursprüngliche Request auf die HTML-Datei sowie die automatisch vom Webbrowser ausgelösten Requests auf die in der HTML-Datei referenzierten CSS-, JavaScript- oder Bilddateien. Auch beim Server fehlgeschlagene Requests werden als Hit mitgezählt. Die Anzahl der Hits sagt daher nicht notwendiger Weise etwas über die Anzahl der Visits oder der abgerufenen Webseiten aus, sondern erhöht sich auch mit der Komplexität jeder Webseite.

Hochverfügbarkeits-Test / Fail-Over-Test

Ein Fail-Over-Test prüft Hochverfügbarkeits-Eigenschaften einer Anwendung. Dazu werden während der Lastsimulation der Ausfall und der Wiederanlauf einzelner, redundant ausgelegter Systemkomponenten provoziert und die korrekte Reaktion (Fail-Over) des Systems geprüft.

HtmlUnit

HtmlUnit ist ein in Java geschriebener Headless Browser, der sich zum Test von Webanwendungen einsetzen lässt. Über das API von HtmlUnit kann man Webseiten aufrufen, auf Elemente in der Webseite zugreifen, Formulare ausfüllen, Links anklicken usw. Auch die Ausführung von JavaScript wird unterstützt. HtmlUnit ermöglicht die Simulation von Firefox oder Internet Explorer. HtmlUnit wird typischer Weise mit Hilfe von Testframeworks genutzt, beispielsweise JUnit oder TestNG. XLT nutzt ebenfalls HtmlUnit als Komponente in den virtuellen Nutzern.

Image Loading

Dieser Begriff bezeichnet oft das automatische Anfordern und Laden von Bildern und anderen multimedialen Ressourcen durch einen Webbrowser. Eine HTML-Datei enthält selbst keine Bilddaten. Um Bilder anzuzeigen, parst der Webbrowser eine geladene HTML-Datei und führt beim Finden von eingebetteten Bild-URLs selbstständig Requests aus, um die Bilddateien zu laden und die Bilder anzuzeigen. Das Laden von Bildern kann auch durch CSS-Regeln definiert sein. In XLT kann das Laden solcher Bilder mit der Property com.xceptance.xlt.css.download.images konfiguriert werden. Manchmal wird unter dem Begriff "Image Loading" begrifflich unsauber auch das Laden anderer statischer Ressourcen, wie CSS oder JavaScript zusammengefasst. Siehe auch "Laden statischer Inhalte".

Initial Delay (XLT)

Das "Initial Delay" ist die Zeitdauer am Anfang eines Testlaufs, in der XLT weder Lastgenerierung noch Messungen ausführt (com.xceptance.xlt.loadtests.default.initialDelay). Aus Sicht von XLT handelt es sich um eine reine Wartezeit bis zum Beginn aller Aktivitäten. Das kann bei vollautomatisch gestarteten, komplexeren Testabläufen sinnvoll sein, um beispielsweise einem ebenfalls automatisch gestarteten zu testenden System Zeit bis zum Erreichen eines stabilen Betriebszstands zu geben.

Instrumentierung / Instrumentation

Zufügen zusätzlichen Codes zu einer zu testenden Anwendung zum Sammeln von Informationen während der Programmlaufzeit. Beispiele sind Informationen über die durchlaufenen Code-Zweige (Code Coverage) oder die Häufigkeit und Dauer von Methodenaufrufen (Profiling).

JUnit

JUnit ist ein Testframework für automatisierte Unit-Tests von Java-Programmen. Es wurde ursprünglich von Kent Beck und Erich Gamma konzipiert. In Java geschriebene Testfälle, die den JUnit-Konventionen folgen, können von einem beliebigen JUnit-Testrunner ausgeführt werden.

Konstante Ankunftsrate / Constant Arrival Rate

Dieser Begriff bezeichnet eine Art der simulierten Last, bei der die virtuellen Nutzer unabhängig vom Zustand des zu testenden Systems mit einer konstanten Rate neue Visits starten. Die Anzahl der parallelen Visits hängt vom Antwortverhalten des zu testenden Systems ab. Auch wenn das System sehr langsam oder gar nicht mehr antwortet, werden trotzdem neue Nutzer eintreffen, das heißt, Requests an das System absenden.

Theoretisch könnte die Anzahl der parallelen Visits auf diese Weise unbegrenzt steigen. Wenn das zu testende System die Last verarbeiten kann, schwingt sich das System auf einem bestimmten Niveau paralleler Visits ein. Dieser Zustand ist erreicht, wenn pro Zeiteinheit so viele Visits beendet werden, wie Requests für neue Visits beim Server eintreffen.

Kann das zu testende System die eintreffenden Requests nicht schnell genug bearbeiten, erhöht sich die parallele Nutzeranzahl automatisch. Diese Art der simulierten Last entspricht oft eher dem Verhalten realer Systeme, da dort bei einem langsamen Server die Anzahl der neu eintreffenden Nutzer ebenfalls nicht durch den Zustand des Servers beeinflusst wird.

In XLT wird eine clusterweite, konstante Ankunftsrate simuliert, wenn die Property com.xceptance.xlt.loadtests.default.arrivalRate gesetzt ist und keine Iterationsanzahl in der Property com.xceptance.xlt.loadtests.default.iterations konfiguriert ist. Die Property gibt die Anzahl der neuen Visits pro Stunde an. Die maximale Anzahl der parallelen virtuellen Nutzer wird auch bei der Simulation einer konstanten Ankunftsrate durch die Pflicht-Property com.xceptance.xlt.loadtests.default.users begrenzt.

Konstante Nutzerzahl / Steady Load

Bei dieser Art der simulierten Last wird eine konstante, genau festgelegte Anzahl virtueller Nutzer verwendet. Jeder virtuelle Nutzer führt nacheinander mehrere Transaktionen (Testfälle) aus. Erst wenn eine Transaktion beendet ist, kann ein virtueller Nutzer eine neue Transaktion beginnen. Selbst sehr lange Antwortzeiten des getesteten Systems führen daher nicht zu einer höheren Anzahl paralleler Visits.

Das Verfahren entspricht weniger dem Verhalten in der realen Welt, ist aber günstig für kontrollierte Messungen, da es zu starke Schwankungen und unkontrollierbare Nebeneffekte vermindert. Mit XLT wird eine konstante Nutzerzahl simuliert, wenn die Property com.xceptance.xlt.loadtests.default.arrivalRate nicht gesetzt ist.

Laden statischer Inhalte / Static Content Loading

Dieser Begriff bezeichnet das automatische Laden von Bildern, CSS, JavaScript und anderen statischen Ressourcen durch einen Webbrowser. Eine HTML-Datei enthält Referenzen auf solche Daten, die dann vom Webbrowser mit Hilfe weiterer Requests geladen und angezeigt oder interpretiert werden.

Ein Test ohne das Laden von Bildern und anderer statischer Inhalte ist oft sinnvoll, um nur die Anwendungslogik und die dynamische Erzeugung von Webseiten zu testen und nicht das meist von anderen Komponenten durchgeführte Ausliefern der statischen Inhalte. So werden Ressourcen beim getesteten System, im Netzweerk und auf der Client-Seite geschont, so dass mit weniger Ressourcen eine höhere Anzahl virtueller Nutzer simuliert werden kann. Auf diese Weise können die zu testenden Kernkomponenten einer höheren Last ausgesetzt werden.

XLT besitzt verschiedene Properties, um das Laden statischer Inhalte zu steuern (com.xceptance.xlt.loadStaticContent). Hinweis: Wenn die XLT-Property com.xceptance.xlt.javaScriptEnabled = true gesetzt ist, führen die virtuellen Nutzer JavaScript-Code aus, auch wenn com.xceptance.xlt.loadStaticContent = false gesetzt ist.

Lastprofil

Ein Lastprofil ist die Beschreibung aller relevanten Lastparameter, wie zum Beispiel Anzahl und Typ der virtuellen Nutzer, die Simulation einer konstanten Ankunftsrate oder einer konstanten Nutzerzahl, eine Ramp-Up-Period, die Denkzeit, usw.

Lasttest

Bei einem Lasttest wird die zukünftige Nutzung des zu testenden Systems unter Berücksichtigung bestimmter Benutzer- und Transaktionsmengen simuliert und bewertet. Dabei werden zwei grundsätzliche Ziele verfolgt. Das erste Ziel ist die Aufdeckung funktionaler Fehler, die nur unter paralleler oder intensiver Nutzung des Systems auftreten. Das zweite Ziel ist die Überprüfung des Zeit- und Verbrauchsverhaltens des getesteten Systems unter einer gegebenen Last. Dabei werden beispielsweise Antwortzeiten sowie der Verbrauch von Hauptspeicher und Rechenleistung ermittelt.

Lasttests können auf unterschiedliche Aspekte eines Systems ausgerichtet sein. Dafür sind jeweils auch unterschiedliche Lastprofile und Testszenarien erforderlich, die oft mit eigenen Begriffen bezeichnet werden. Beispiele dafür sind "Skalierungstest", "Stresstest" oder "Dauerlasttest". Der Begriff "Lasttest" ist der Oberbegriff für alle diese Testarten.

Local Shared Object

Im Umfeld der Web-Entwicklung bezeichnet "Local Shared Object" eine Datei, die mit Hilfe des Adobe Flash Players auf dem lokalen Rechner eines Nutzers gespeichert wird, wenn der Nutzer eine Webseite mit einem entsprechenden Flash-Inhalt besucht. Daher werden diese Dateien auch als "Flash Cookie" bezeichnet.

Local Shared Objects werden zu den gleichen Zwecken genutzt, wie HTTP-Cookies und unterliegen den gleichen Regeln. So können sie nur von der Website ausgelesen werden, die ihre Speicherung veranlasst hat. Local Shared Objects sind jedoch im Gegensatz zu HTTP-Cookies browserunabhängig. Local Shared Objects, die durch den Flash-Player in einem Webbrowser geschrieben werden, können durch den Flash-Player in einem anderen Webbrowser gelesen und an die Website gesendet werden. Außerdem können Local Shared Objects deutlich größere Datenmengen speichern und haben kein Verfallsdatum. Das Speichern von Local Shared Objects kann derzeit in den meisten Webbrowsern nicht ohne Weiteres verboten werden.

Master Controller (XLT)

Der Master Controller steuert den gesamten Lasttest. Er verteilt die Testsuite auf alle Agent Controller, verteilt die Lasttestaufgaben gleichmäßig und startet und beendet die Lasterzeugung. Schließlich sammelt der Master Controller auch die Testergebnisse und speichert sie zentral in seinem Dateisystem.

Measurement Period (XLT)

Zeitdauer, in der Messwerte gesammelt werden (com.xceptance.xlt.loadtests.default.measurementPeriod). Die Measurement Period beginnt nach der Warm-Up Period.

Median

Der Median ist der Wert "in der Mitte" einer Datenverteilung. Der Median halbiert die Menge der Messwerte wie folgt: Höchstens die Hälfte der Werte ist kleiner als der Median und höchstens die Hälfte der Werte ist größer.

Zur Ermittlung des Medians werden alle Werte geordnet. Bei einer ungeraden Anzahl der Werte ist der Wert in der Mitte der Liste der Median. Bei einer geraden Anzahl von Werten ergibt sich der Median aus dem arithmetischen Mittel der beiden Werte in der Mitte der Liste.

Der Median ist wesentlich robuster gegenüber einzelnen stark abweichenden Werten, als das arithmetische Mittel. Der Median der fünf Antwortzeiten 1s, 1s, 1s, 1s, 21s beträgt 1s, das arithmetische Mittel wäre dagegen 5s.

Metrik (Kennzahl) / Metrics

Eine Metrik ist eine Maßzahl zur Erfassung quantifizierbarer Eigenschaften. Jeder Metrik liegt eine eindeutige, reproduzierbare Messvorschrift zugrunde. Beispiele für Metriken im Umfeld von Lasttests sind die erreichte Anzahl der Requests/s, die mittlere Antwortzeit in Sekunden oder die CPU-Auslastung in %.

Nutzerszenario

Siehe "Testszenario".

Page Impression

Siehe "Page View".

Parallele Nutzer / Concurrent Users

Die realen Nutzer oder die im Rahmen eines Lasttests simulierten Nutzer, die ein System gleichzeitig nutzen. Es werden auch die Bgriffe "Parallele Sessions" oder "Parallele Visits" verwendet.

Bei Webanwendungen ergibt sich diese Anzahl wie folgt. Jeder Nutzer sendet einzelne Requests, erhält Antworten und wartet dann für eine gewisse Zeit (Thinktime), bis er den nächsten Request absendet. Dennoch zählt er auch in dieser Zeit als paralleler Nutzer. Die Parallelität bezieht alle Nutzer ein, die einen Besuch auf der Website gestartet (erster Request) und noch nicht beendent haben, das heißt, es folgen weitere Requests. Dabei spielt es keine Rolle, ob sich gerade ein Requests des Nutzers beim Server in Bearbeitung befindet, oder ob der Nutzer die letzte Response bereits erhalten und noch keinen neuen Request gesendet hat.

Wenn die realen Nutzerszenarien lange Think Times zwischen den gesendeten Requests enthalten, genügt unter Umständen eine Simulation mit einer geringeren Anzahl virtueller Nutzer, die dafür mit entsprechend kürzeren Think Times arbeiten. Ziel ist in diesem Fall, die gleiche Anzahl paralleler Requests zu simulieren. Ein solches Szenario ist nicht vollständig äquivalent zur einer höheren Nutzerzahl mit längeren Think Times, kann aber je nach Testziel in vielen Fällen ausreichend sein.

Parallele Requests

Als parallele Requests zählen alle Requests, die abgesendet aber noch nicht vollständig beantwortet sind. Die Anzahl der parallelen Requests ist oft geringer, als die Anzahl der parallelen Nutzer. Sie kann jedoch auch höher sein, da Webbrowser für eine von einem Nutzer aufgerufene Webseite mehrere parallele Requests ausführen, um beispielsweise Bilder zu laden.

Performance-Test

Der Begriff Performance-Test wird nicht immer einheitlich verwendet. Teilweise meint man damit einen Test, der die Einhaltung der vorgegebenen Lastanforderungen prüft, indem man die geforderte Last simuliert und das Verhalten des Systems mit den Anforderungen an Antwortzeiten, Durchsatz usw. vergleicht. Teilweise wird von einem Performance-Test gesprochen, wenn der Test Bottlenecks aufspüren soll, ohne das getestete System zu überlasten. Dazu werden während der Testläufe detaillierte Monitoring-Informationen über alle Hardware- und Softwarekomponenten gesammelt und ausgewertet. Gelegentlich wird der Begriff auch synonym zum Oberbegriff "Lasttest" benutzt.

Property-Dateien

Es handelt sich um Textdateien mit einem definierten Format, die im Java-Umfeld zum Speichern von Einstellungen verwendet werden. Diese Dateien enthalten pro Zeile maximal eine Property, die einen Namen und einen Wert besitzt.

QS / QA

"Qualitätssicherung" oder englisch "Quality Assurance" bezeichnet alle Maßnahmen zur Erzielung und Überprüfung der gewünschten Qualität. Manchmal werden auch die beteiligten Organisationseinheiten, beispielsweise Testteams, so bezeichnet.

Ramp-Up Period (XLT)

Zeitdauer, während der die Anzahl der virtuellen Nutzer automatisch bis auf 100% erhöht wird (com.xceptance.xlt.loadtests.default.rampUpPeriod). So lässt sich ein langsames Ansteigen der Last simulieren, um zum Beispiel die maximal verarbeitbare Last zu ermitteln. Diese Einstellung ist unabhängig von der Warm-Up Period, der Measurement Period und der Shutdown Period. Die Ramp-Up Period beginnt nach dem Initial Delay.

Ramp-Up Step Size (XLT)

Die Anzahl der virtuellen Nutzer, um die die Last bei jedem Schritt automatisch erhöht wird (com.xceptance.xlt.loadtests.default.rampUpStepSize). Die Dauer zwischen zwei Erhöhungsschritten wird durch XLT automatisch ermittelt. Mit der letzten Erhöhung, unmittelbar bei Ablauf der Ramp-up Period, wird die konfigurierte Gesamtzahl der virtuellen Nutzer erreicht.

Regressionstest

Ein Regressionstest ist die wiederholte Ausführung von Testfällen nach Änderungen an bereits getesteter Software, um unerwünschte Nebenwirkungen aufzuspüren. Dabei können je nach Anforderungen nur eine ausgewählte Teilmenge oder alle bereits vorher ausgeführten Testfälle wiederholt werden.

Request

Ein Request ist eine Anfrage eines Clients an einen Server, bei Webapplikationen meist unter Nutzung der Protokolle HTTP oder HTTPS. Siehe auch "Hit".

Response

Eine Response ist die Antwort eines Servers auf einen Request eines Clients. Bei Webanwendungen kann der vom Server zurückgelieferte Inhalt beispielsweise HTML, CSS oder JavaScript sein, aber auch Bilder oder Videos, Flash, Silverlight-Applikationen oder beliebige Dateien zum Download.

Sättigung / Saturation

Wenn eine Ressource oder ein System voll ausgelastet ist, spricht man von Sättigung. Wenn dieser Zustand erreicht ist, bewirkt eine weitere Erhöhung der angelegten Last, beispielsweise eine höhere Zahl eintreffender Requests, keine weitere Erhöhung des Durchsatzes mehr.

Seitenaufruf / Page View

Vollständiger Aufruf einer Webseite mit allen in diese Seite eingebundenen multimedialen Inhalten wie Bildern, Sounds, aber auch CSS, JavaScript usw. Aus Sicht des Nutzers wird nur eine einzige URL im Browser aufgerufen und eine einzige Seite angezeigt, aus technischer Sicht findet dafür jedoch eine Anzahl von Requests zum Laden der einzelnen Bestandteile statt.

Server

Ein System, welches Dienste anbietet, die von sogenannten Clients über eine definierte Schnittstelle genutzt werden können. Bei Webanwendungen kann es sich beispielsweise um Webserver oder Application Server handeln, die von Webbrowsern gesendete Requests entgegennehmen und als Responses HTML-Seiten oder andere Inhalte zurückliefern.

Service Level Agreement (SLA)

Ein "Service Level Agreement", deutsch auch "Dienstgütevereinbarung", bezeichnet eine verbindliche Vereinbarung zwischen einem Dienstanbieter (Auftragnehmer) und einem Dienstnutzer (Auftraggeber) hinsichtlich bestimmter Leistungseigenschaften, beispielsweise Verfügbarkeit oder maximale Antwortzeiten.

Session-ID (SID)

Eindeutiger Identifikator für Besucher einer Website, um mehrere zusammengehörige Anfragen eines Benutzers zu erkennen. Eine Session-ID wird bei der Verarbeitung des ersten Requests eines Nutzers vom Server erzeugt und mit der Response an den Client des Nutzers gesendet. Ab diesem Zeitpunkt wird die Session-ID normalerweise mit jedem Request und jeder Response zwischen Client und Server übertragen. Die Session-ID kann in einem Cookie im HTTP-Header, in der URL oder als versteckter Formularparameter in den POST-Daten übermittelt werden.

Eine Sesion-ID muss eindeutig und sehr schwer zu erraten sein. Außerdem sollten weitere Mechanismen verwendet werden, die die Übernahme einer fremden Session durch Angreifer erschweren.

Shutdown Period (XLT)

Bis Version 3.3.0: Die Shutdown Period ist die Zeitdauer am Ende eines Testlaufs, in der die virtuellen Nutzer weiterhin Transaktionen ausführen, jedoch keine Messwerte mehr gespeichert werden (com.xceptance.xlt.loadtests.default.shutdownPeriod). Die Shutdown Period dient dazu, bis zum Ende der Messung eine konstante Last auf das zu testende System zu geben, um durch das Stoppen der virtuellen Nutzer die Messwerte nicht zu verfälschen. Bis zum Ende der Shutdown Period werden auch noch neue Transaktionen gestartet. Ab dem Ende der Shutdown Period werden nur noch die bereits laufenden Transaktionen fertiggestellt. Dadurch kann die Gesamtdauer eines Testlaufs über das Ende der Shutdown Period hinausgehen.

Ab Version 3.3.1: Die Shutdown Period ist die Zeitdauer am Ende eines Testlaufs, in der die virtuellen Nutzer die zuletzt begonnenen Transaktionen zuende führen, jedoch keine Messwerte mehr gespeichert werden (com.xceptance.xlt.loadtests.default.shutdownPeriod). Die Shutdown Period dient dazu, nach der eigentlichen Messung ein sauberes Beenden der Nutzertransaktionen zu ermöglichen. Am Ende der Shutdown Period noch immer laufende Transaktionen werden hart gestoppt.

Simulierter Nutzer / Simulated User

Siehe "Virtueller Nutzer".

Sitzung / Session

Bezeichnung für die zusammengehörenden Aktivitäten eines Nutzers im Rahmen einer Visit sowie für deren technische Repräsentation beim Server. Bei aktiven Webanwendungen, die über das reine Anzeigen statischer Web-Inhalte hinausgehen, muss der Server alle Requests, die ein Nutzer innerhalb einer Visit an den Server sendet, dieser gleichen Visit zuordnen können. Durch die Verwendung zustandsloser Protokolle und das Fehlen einer bei jedem Request verfügbaren, eindeutigen ID kann ein Nutzer im Web jedoch nur mit zusätzlichen Hilfsmitteln wiedererkannt werden. Dazu erzeugt der Server für jeden Besucher beim Eintreffen des ersten Requests eine eindeutige Session-ID, die er mit der Response an den Client sendet. Ab diesem Zeitpunkt wird die Session-ID zusammen mit allen Requests und Reponses zwischen Client und Server übertragen. Intern speichert der Server je nach Anwendung zu jeder Session-ID bestimmte Zustandsdaten, beispielsweise den Warenkorb eines Online-Shops, den Login-Zustand und die gewählte Anzeigesprache bei mehrsprachigen Websites.

Das Ende einer Session kann oft nicht eindeutig bestimmt werden, weil nicht bekannt ist, ob der Nutzer weitere Requests senden wird. Daher werden Sessions oft serverseitig über einen Timeout beendet, wenn für eine bestimmte Zeit kein weiterer Request beim Server eintraf (Session Timeout). In diesem Fall werden die Sessiondaten beim Server gelöscht oder entsprechend markiert. Solange zwar eine Session-ID zugeordnet ist, aber der Nutzer noch keine Aktion durchgeführt hat, die ihn eindeutig identifiziert (Login), spricht man von einer "anonymen Session".

Sizing-Test

Mit einem Sizing-Test bestimmt man den Umfang der benötigten Hardware und Software für bestimmte Lastanforderungen. Dazu werden die Grenzen unterschiedlicher Hardware-/Software-Konfigurationen ermittelt, um später auf Basis gegebener Lastanforderungen Schätzungen zur voraussichtlich benötigten Hardware und Software durchführen zu können.

Skalierbarkeit / Scalability

Die Skalierbarkeit beschreibt, wie gut eine Anwendung bei Hinzunahme von Ressourcen wachsende Arbeitslasten verarbeiten kann, ohne dass dazu weitere Änderungen an der Anwendung notwendig sind.

Im Idealfall steigt die Arbeitslast, die eine skalierbare Anwendung bewältigen kann, linear mit der Menge der verfügbaren Ressourcen. Eine solche Anwendung würde zum Beispiel bei Verdopplung der verfügbaren Ressourcen auch die doppelte Anzahl von Requests pro Zeiteinheit beantworten können. In diesem Fall spricht man von "linearer Skalierbarkeit". Voraussetzung für lineare Skalierbarkeit ist, dass alle Ressourcen gleichzeitig hoch ausgelastet werden können.

In der Praxis führen jedoch Synchronisations-, Kommunikations- und Verwaltungs-Overhead dazu, dass die hinzugefügten Ressourcen nicht vollständig durch die Anwendung nutzbar sind. Die Folge ist "sub-lineare Skalierbarkeit", bei der sich bei Verdopplung der Ressourcen die bewältigte Arbeitslast um weniger als 100% erhöht.

Skalierbarkeitstest

Mit einem Skalierbarkeitstest wird erstens geprüft, wie sich das Antwortverhalten und der Ressourcenverbrauch eines Systems mit steigender Last verändern. Im Idealfall steigen die Antwortzeiten linear zur Last. In diesem Bereich "skaliert" das System. In realen Systemen verschlechtert sich dieses Verhalten mit zunehmender Last, so dass eine weitere Lasterhöhung ab einem gewissen Punkt einen stark überproportionalen Anstieg der Antwortzeiten zur Folge hat. Damit ist die Grenze der Skalierbarkeit erreicht. Es wird also getestet, wie stark die Last auf einem gegebenen System erhöht werden kann, bis diese Grenze erreicht ist.

Zweitens wird durch Skalierbarkeitstests geprüft, inwiefern sich diese Grenze durch Hinzunahme von Hardware- und Softwarekomponenten nach oben verschieben lässt. Solange die maximal verarbeitbare Last annähernd linear mit der Menge der eingesetzten Komponenten steigt, "skaliert das System über die Hardware- und Software".

Speicherleck / Memory Leak

Ein Memory Leak ist ein Softwarefehler, durch den Bereiche des Arbeitsspeichers nach der Benutzung nicht wieder freigegeben werden. Wird solch ein Fehler im Laufe des Betriebs wiederholt wirksam, so wächst der Speicherbedarf, bis nicht mehr genügend Speicher zur weiteren Programmausführung zur Verfügung steht.

Standardabweichung / Standard Deviation

Die Standardabweichung ist ein Maß für die Streubreite aller Werte. Sie liefert eine Aussage über die durchschnittliche Entfernung der Werte vom arithmetischen Mittelwert. Berechnet wird sie als Quadratwurzel der Varianz.

Bei der Einschätzung der Streuung von Messwerten ist die Standardabweichung immer in Relation zum arithmetischen Mittelwert zu betrachten. Eine vergleichsweise hohe Standardabweichung zeigt eine starke Steuung der Messwerte an.

Falls die Messwerte normalverteilt sind, liegen 68% der Werte höchstens um die Standardabweichung vom arithmetischen Mittel entfernt und 95% der Werte höchstens um die doppelte Standardabweichung entfernt. Wenn zum Beispiel die Messwerte einer Antwortzeit normalverteilt sind, mit einem arithmetischen Mittel von 5s sowie einer Standardabweichung von 2, so liegen 68% aller Antwortzeiten im Bereich 3s..7s und 95% aller Antwortzeiten im Bereich 1s..9s.

Stresstest

Bei einem Stresstest wird die simulierte Last über das im Normalbetrieb erwartete Maß erhöht, bis funktionale Fehler auftreten oder das Antwortverhalten des getesteten Systems bestimmte Grenzen überschreitet. Hierfür wird oft eine kontinuierlich ansteigende Nutzerzahl simuliert. Stresstests verwendet man beispielsweise zur Ermittlung des Systemverhaltens in und nach Überlastsituationen, zur Ermittlung der maximal akzeptierbaren Last oder zum Finden von einzelnen Performance-Schwachstellen (Bottlenecks).

Super Cookie

Siehe "Local Shared Object".

System Under Test (SUT)

Die Hardware und Software des zu testenden Systems, beispielsweise die mit XLT mitgelieferte Demo-Anwendung "Pebble" auf einem bestimmten Rechner.

Szenario

Siehe "Testszenario".

Testfall / Test Case (XLT)

Bei XLT ist ein Testfall ein Stück Code, welches eine Nutzertransaktion (Transaction) implementiert und von einem JUnit-Testrunner aufgerufen werden kann.

Test Recorder (XLT)

Der XLT Test Recorder ist ein FireFox-Plugin, welches Aktionen im Webbrowser aufzeichnet und ein Java-Codegerüst für einen XLT-Testfall generiert.

Testsuite (XLT)

Eine zusammengehörende, gemeinsam auszuführende Menge von Testfällen.

Testszenario

Ein Testszenario ist eine Abfolge von Schritten in der zu testenden Anwendung, die von echten oder virtuellen Nutzern ausgeführt wird. Es handelt sich beispielsweise um Anwendungsfälle wie das Browsing oder die Registrierung eines neuen Nutzers in einem Online-Sho

Manchmal wird der Begriff Testszenario auch umfassender gebraucht und bezeichnet beispielsweise ein gesamtes Lastprofil mit einer Mischung mehrerer virtueller Nutzertypen.

Transaction (XLT)

Ausführung eines bestimmten Testfalls, um ein Testszenario zu modellieren. Eine Transaction führt meist wiederum mehrere Actions aus.

Verteilter Modus (XLT)

Wenn Testfälle durch den XLT Master Controller und die XLT Agents ausgeführt werden, arbeiten sie im verteilten Modus. XLT erkennt den Modus abhängig vom verwendeten Testtreiber automatisch. Der verteilte Modus wird hauptsächlich für Lasttests verwendet und daher auch als "Lasttest-Modus" bezeichnet. Bei Testläufen im verteilten Modus werden die zusätzlichen Property-Dateien nicht gelesen, die nur für den Development-Modus vorgesehen sind.

Virtueller Nutzer / Virtual User

Als "virtuellen Nutzer" bezeichnet man die Simulation eines realen Nutzers und des von ihm verwendeten Programms durch ein Testwerkzeug. Die virtuellen Nutzer sollten alle für den jeweiligen Testzweck wichtigen Eigenschaften möglichst realistisch abbilden.

So muss ein virtueller Nutzer für den Lasttest einer Webanwendung das Verhalten eines realen Nutzers und seines Webbrowsers simulieren. Dazu gehören das Ausfüllen von Formularen, das Absenden von HTTP-Requests, das Interpretieren von HTML-Seiten, das parallele Laden von statischen Inhalten, eventuell das Ausführen von JavaScript, Denkzeiten bis zum Absenden des nächsten Requests, aber auch performance-relevante Eigenschaften wie Caching im Webbrowser.

Während eines Lasttests wird eine Anzahl virtueller Nutzer parallel ausgeführt, die unabhängig voneinander Testfälle abarbeiten.

Visit

Ein "Visit" ist der Besuch eines Nutzers auf einer Website. Es handelt sich um eine zeitlich zusammenhängende Folge von Pageviews eines Nutzers.

Beispielsweise ist ein Visit in einem Online-Shop mit einem Besuch eines realen Ladengeschäfts vergleichbar. Der Nutzer betritt den Laden (erster Request), sucht vielleicht nach Produkten, betrachtet einzelne Produkte genauer, legt Produkte in den Warenkorb und kauft diese eventuell.

Alle Requests, die ein Nutzer innerhalb eines Visits an den Server sendet, müssen dem gleichen Visit zugeordnet werden können. Dazu erzeugt der Server für jeden Besucher eine Session-ID, die mit allen Requests und Reponses zwischen Client und Server übertragen wird. Intern verwaltet der Server Zustandsdaten zu jeder Session, beispielsweise den Warenkorb, den Login-Zustand und die gewählte Anzeigesprache bei mehrsprachigen Websites. Der Begriff "Visit" wird häufig bei statistischen Auswertungen verwendet, der Begriff "Session" eher im technischen Umfeld. Oft werden "Visit" und "Session" auch synonym benutzt.

Aus technischer Sicht gibt es im Web kein eindeutiges Ende einer Visit, da nicht vorausgesagt werden kann, ob der Nutzer noch einen weiteren Request ausführt. Oft wird daher nach einer bestimmten Wartezeit ohne einen neuen Requests eine Visit als beendet betrachtet und der Zustand der Session beim Server gelöscht. Abhängig vom Webangebot beträgt dieser Zeitraum oft 30 Minuten bis 24 Stunden. Der nächste Request des gleichen Nutzers erzeugt dann eine neue Session und wird einer neuen Visit zugeordnet.

Daher gilt, dass der letzte Besuch bereits einige Zeit zurückliegen muss, damit ein Besuch tatsächlich als neuer Besuch gilt. Alle Requests eines Nutzers, die innerhalb dieser Zeitspanne eintreffen, werden der gleichen Visit zugeordnet. Ein Visit hat mindestens einen Pageview, meist aber mehrere. Wichtige Messgrößen sind die Länge eines Visits (Visit Duration), die Anzahl der Pageviews und der Abstand zwischen zwei Pageviews (Think Time). Andere Begriffe für Visits sind "Besuch", "Besucher" oder "Session".

Warm-Up Period (XLT)

Zeitdauer, während der bereits Last generiert, aber noch keine Messwerte gespeichert werden (com.xceptance.xlt.loadtests.default.warmUpPeriod). Hiermit lässt sich eine Einschwingzeit konfigurieren, in der die Antwortzeiten und andere Messwerte vielleicht noch nicht repräsentativ sind und daher noch nicht berücksichtigt werden. Die Warm-Up Period beginnt direkt nach dem Initial Delay.

Webseite

Eine "Webseite" ist eine einzelne Seite, die unter Verwendung von Webtechnologien, wie zum Beispiel HTML, erstellt wurde und mit einer URI adressiert werden kann. Eine Webseite wird mit Hilfe eines Webbrowsers oder eines anderen geeigneten Programms von einem Webserver abgerufen und dann meist auf dem Bildschirm dargestellt. Für die Darstellung einer Webseite werden heute neben der ursprünglichen HTML-Datei meist weitere Dateien für CSS, Bilder und andere Inhalte geladen und vom Webbrowser verarbeitet. Eine Webseite wird auch als Internetseite bezeichnet.

Website

Der Begriff "Website" bezeichnet einen kompletten, zusammenhängenden Webauftritt. Eine Website umfasst im Allgemeinen die Gesamtheit der Webseiten und online angebotenen Dienste einer Organisation.

Xceptance LoadTest (XLT)

"Xceptance LoadTest" ist ein Werkzeug zur Erstellung und Durchführung von Lasttests und automatisierten Regressionstests, insbesondere für Web-Anwendungen.

XLT Basislizenz / XLT Basic License

Kostenfreie Lizenz, die automatisch in jedem XLT-Softwarepaket enthalten ist. Sie erlaubt die Entwicklung und den wiederkehrenden Test aller Szenarien mit bis zu fünf simulierten Nutzern mit uneingeschränktem Funktionsumfang. Die Basislizenz gilt zeitlich unbegrenzt und darf produktiv eingesetzt werden, auch in Kundenprojekten. Für die Nutzung von XLT mit der Basislizenz wird keine Lizenzdatei benötigt.

XLT Community-Lizenz / XLT Community License

Die Community-Lizenz ist eine kostenfreie, in der Anzahl der virtuellen Nutzer unlimitierte Lizenz für Open-Soure-Projekte. Diese Lizenzen dürfen nur für nicht-kommerzielle Zwecke und nur durch das jeweilige Open-Source-Projekt selbst genutzt werden.

XLT Standardlizenz / XLT Standard License

Kostenpflichtige On-Demand-Lizenz zur Lasttestausführung mit mehr als fünf virtuellen Nutzern. Umfang und Preis richten sich nach der Gültigkeitsdauer (auf Monatsbasis) und der Anzahl der benötigten virtuellen Nutzer.

XPath

Die "XML Path Language" ist eine Abfragesprache zur Adressierung von Bestandteilen innerhalb eines XML-Dokumentes. In XLT kann XPath verwendet werden, um Elemente in einer geladenen HTML-Seite zu adressieren.

XPI

Die Dateinamenserweiterung "XPI" steht für "XPInstall" oder "Cross-Platform Install". Das XPI-Format wurde von der Mozilla Foundation entwickelt. XPI-Dateien sind ZIP-komprimierte Installationsdateien. Sie enthalten ein Installationsscript und andere benötigte Dateien.

XSL

Die "Extensible Stylesheet Language" ist eine Menge von Transformationssprachen. Sie dienen der Transformation oder Präsentation von XML-Dokumenten. Zu dieser Familie gehören XSL-FO (XSL Formatting Objects) für Formatierungsanweisungen zur Ausgabe von XML-Dokumenten, XSLT (XSL Transformations) für die Transformation von XML-Dokumenten in andere XML-Dokumente sowie XPath zur Adressierung von Bestandteilen innerhalb eines XML-Dokuments.