Was JMeter hervorragend kann
Nebenläufige Last erzeugen. Thread-Gruppen, Ramp-up, verteilte Lastgeneratoren. Genau dafür wurde es gebaut, und es bleibt eine der besten kostenlosen Optionen.
Protokollvielfalt. Weit über HTTP hinaus, was bei Enterprise-Systemen mit Messaging- und Datenbankschichten zählt.
Schon installiert zu sein. Kein technischer Vorzug und ein realer Grund, warum Teams es einsetzen.
Wo JMeter API Testing umständlich wird
Testpläne sind XML
Eine Änderung im Pull Request zu reviewen, ist nahezu unmöglich.
Merge-Konflikte in einer .jmx-Datei sind ein Elend für sich.
Assertions sind standardmäßig oberflächlich
Response-Code und Substring-Vergleich decken die häufigen Fälle ab und sonst wenig.
Alles Strukturelle bedeutet ein Scripting-Element.
Zustand ist Handarbeit
Extraktoren, Variablen und Controller, alles von Hand verdrahtet.
Der Abhängigkeitsgraph steckt in der Struktur des Plans, statt deklariert zu sein.
Die Aufteilung, die funktioniert
Behalten Sie JMeter für die Kapazitätsfrage: wie verhält sich der Dienst unter anhaltender Nebenläufigkeit, wo bricht die Latenz ein, was bricht zuerst. Dafür ist es da, und nichts davon legt nahe, es zu ersetzen.
Verlagern Sie die funktionale Korrektheit dorthin, wo Sessions, erfasste Werte, Reihenfolge und Cleanup Teil des Produkts sind und nicht Elemente, die Sie selbst zusammenstecken. Eine Beschreibung dieser vier finden Sie in der Dokumentation zum API-Testing.
Eine Sache, die sich in JMeter trotzdem lohnt
Ergänzen Sie Ihre Lastpläne um Body-Assertions, und sei es nur für eine Stichprobe der Requests. Ein Lasttest, der nur Statuscodes prüft, meldet einen sauberen Durchlauf, während der Dienst leere Ergebnisse liefert, und schnell und falsch ist das schlechteste Ergebnis, weil niemand der Sache nachgeht.
Die funktionale Ebene aufsetzen
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Das Dashboard bietet dasselbe für alle, die keine lokale Installation möchten, und der vollständige Befehlsumfang liegt im CLI-Repository.
Das .jmx-Problem, klar benannt
Der Grund, warum funktionale Abdeckung in JMeter schlecht altert, sind nicht die Assertions, sondern das Dateiformat, und es lohnt sich, konkret zu werden, warum.
Ein Testplan ist XML, das von einer GUI erzeugt wurde. Ein Pull Request, der eine einzige Assertion ändert, produziert ein Diff aus umsortierten Elementen und generierten Identifiern, womit das Review zur Vertrauenssache wird. Bearbeiten zwei Personen denselben Plan innerhalb einer Woche, entsteht ein Merge-Konflikt, der sich leichter lösen lässt, indem man eine Seite verwirft, als indem man sie liest. Und weil Reviews unpraktikabel sind, sammeln sich im Plan Änderungen an, die niemand angesehen hat.
Das sind reale Kosten, und sie bleiben unsichtbar, solange eine einzelne Person den Plan verantwortet, also genau unter den Bedingungen, unter denen die meisten JMeter-Suiten entstehen.
Unterschiedliche Taktungen
Last vor Releases und nach Architekturänderungen. Korrektheit bei jedem Pull Request, weil eine Regression dann am günstigsten zu beheben ist.
Die GitHub App ist ein Webhook, den Sie im TestSprite-Dashboard einrichten. Er lauscht auf das Deployment-Event, das Ihre Pipeline ohnehin erzeugt, sodass sich in Ihrem Repository nichts ändert.
GitHub Actions bindet den Schritt in Ihren eigenen Workflow ein, konfiguriert über das Terminal.
Was TestSprite dem Lastplan abnimmt
Die funktionale Abdeckung, die in JMeter gelandet ist, weil JMeter schon da war. Pläne entstehen aus einem Discovery-Durchlauf plus Ihrer Spezifikation, beschrieben in natürlicher Sprache statt aus Elementen zusammengesteckt, und im Pull Request reviewbar statt in generiertem XML vergraben.
Auto-Authentication hält Sessions über einen ganzen Lauf hinweg aktiv, Dynamic Variables transportieren Werte zwischen Aufrufen, Dependency Chains leiten die Ausführungsreihenfolge daraus ab, was jeder Testfall benötigt und erzeugt, und Auto-Cleanup entfernt genau das, was der Lauf angelegt hat. Das sind die Teile, die Sie heute aus Extraktoren, Variablen, Controllern und Teardown-Thread-Gruppen selbst bauen.
Ihre Lastpläne bleiben genau so, wie sie sind, und tun das, worin JMeter wirklich hervorragend ist. Der Gewinn: Korrektheit läuft bei jedem Pull Request statt vor Releases, und die Änderung an einer Assertion ist etwas, das eine zweite Person lesen kann.
Kann JMeter funktionale API-Tests durchführen?
Ja, und die Ergonomie arbeitet gegen Sie. XML-Pläne, oberflächliche Standard-Assertions und manuelle Zustandsverwaltung sind der Preis.
Sollten wir JMeter ersetzen?
Nicht für Last. Ersetzen Sie die funktionale Abdeckung, die dort zufällig gelandet ist, und behalten Sie die Lastpläne.
Was ist mit Taurus oder JMeter DSL?
Beide verbessern das Schreiben von Tests erheblich. Woraufhin das Werkzeug optimiert ist, ändern sie nicht.
Können wir beides in CI laufen lassen?
Ja. Sie beantworten unterschiedliche Fragen in unterschiedlichen Taktungen, und keines muss vom anderen wissen.
Erzeugt TestSprite Last?
Nein. Es prüft Korrektheit, einschließlich Grenzfällen. Anhaltende Nebenläufigkeit ist JMeter-Terrain.
Behalten Sie die Lastpläne, verlagern Sie die Korrektheit.
JMeter API Testing funktioniert, weil JMeter ohnehin da ist, nicht weil es passt. Behalten Sie es für die Kapazität, ergänzen Sie Ihre bestehenden Lastpläne um Body-Assertions, und bringen Sie die funktionale Korrektheit dorthin, wo Session, Zustand, Reihenfolge und Cleanup von vornherein vorgesehen sind.