Neu: TestSprite CLI ist jetzt live!

Ihr Testplan ist eine JSON-Datei. Behandeln Sie ihn auch so.

Jeder TestSprite-Testplan ist eine einfache JSON-Datei aus action- und assertion-Schritten. Holen Sie ihn mit testsprite test code get, committen Sie ihn, diffen Sie ihn in einem Pull Request und lassen Sie ihn von einem Teammitglied reviewen — statt ihn in einem proprietären GUI-Recorder gefangen zu lassen.

Teil derselben CLI, die Sie bereits nutzen

GitHub ActionsGitLab CILokale LäufeAgent-Loops
Ein Testplan, den Sie nicht diffen können, ist ein Testplan, den Sie nicht reviewen können. Liegt er nicht in git neben dem Code, den er testet, steht er streng genommen nicht unter Versionskontrolle.

Reines JSON, keine Black Box

Jeder Testplan ist eine lesbare JSON-Datei aus expliziten action- und assertion-Schritten — Sie können sie öffnen, durchsuchen und genau nachvollziehen, was sie tut, ohne eine Aufzeichnung abspielen zu müssen.

Committen wie jede andere Datei

Da ein Testplan eine Datei auf der Festplatte ist, liegt er in Ihrem Repository direkt neben dem Code, den er testet — genauso getrackt, verzweigt und versioniert.

In einem Pull Request diffen

Eine Änderung am Testplan erzeugt einen echten git diff — ein Reviewer sieht genau, welcher Schritt sich geändert hat, statt darauf vertrauen zu müssen, dass ein neu aufgezeichneter Flow noch dasselbe tut.

Direkt bearbeiten

Holen Sie die zugrunde liegende Datei mit testsprite test code get, ändern Sie die Schritte von Hand in Ihrem Editor und schieben Sie sie mit testsprite test code put zurück.

$ testsprite test code get TC_checkout_promo
  Wrote test-plans/TC_checkout_promo.json

$ git diff test-plans/TC_checkout_promo.json
    {
      "action": "click #promo-code-input",
-     "assertion": "input is focused"
+     "action": "type '10PERCENT' into #promo-code-input",
+     "assertion": "discount line shows -10%"
    }

$ testsprite test code put TC_checkout_promo
  Updated test plan from local file

Schluss mit Testabdeckung per Bildschirmaufzeichnung reviewen

Ein aufgezeichneter Flow lebt in einem proprietären Tool, sodass ein Teammitglied ihm entweder vertrauen oder ihn erneut ausführen muss, um zu erfahren, was sich geändert hat. Ein JSON-Testplan kann in denselben Pull Request wie der Code, den er testet, aufgenommen und genauso reviewt werden.

Entwickelt für Teams, die bereits Code reviewen

Passt in Ihren bestehenden Workflow

Ein Testplan liegt im selben Repository und im selben Pull Request wie die Änderung, die er abdeckt — reviewt mit den git diff-Gewohnheiten, die Ihr Team bereits hat.

Zuerst Gerüst, dann Feinschliff

testsprite test scaffold erzeugt einen Ausgangs-Testplan; testsprite test lint validiert dessen Struktur, bevor Sie committen.

Kostenlose Community-Version

Bietet eine kostenlose Community-Version und macht es dadurch für alle zugänglich.

Ergänzt den Run-Vergleich

Sobald ein Testplan versioniert ist, nutzen Sie testsprite test diff, um zwei Läufe damit zu vergleichen und genau zu sehen, was sich im Verhalten geändert hat.

Weltweit von Unternehmen geschätzt

"TestSprite bietet eine umfangreiche Testfallgenerierung, eine klare Struktur und leicht lesbaren Code. Es unterstützt auch einfaches Online-Debugging mit der Möglichkeit, schnell durch die Generierung neuer Testfälle zu erweitern."

"Die Automatisierung von TestSprite hilft uns, Tonnen manueller Arbeit zu reduzieren. Die Entwickler können Fehler im Entwicklungsprozess leichter und früher erkennen und beheben."

FAQ

Was bedeutet es, dass ein Testplan "nur JSON" ist?

Jeder Testplan ist eine einfache JSON-Datei aus action- und assertion-Schritten — kein proprietäres Format, keine Binäraufzeichnung. Er lässt sich in jedem Editor öffnen und diffen sauber in git.

Wie komme ich an die zugrunde liegende Datei eines Testplans?

testsprite test code get <testId> holt das JSON auf Ihren lokalen Rechner. Bearbeiten Sie die Schritte direkt und schieben Sie Ihre Änderungen mit testsprite test code put zurück.

Kann ein Teammitglied einen Testplan wie Code reviewen?

Ja — da es sich um eine diffbare JSON-Datei handelt, kann sie in denselben Pull Request wie die Änderung, die sie testet, aufgenommen und mit einem gewöhnlichen git diff reviewt werden, statt mit einer Bildschirmaufzeichnung.

Muss ich jeden Testplan von Grund auf neu erstellen?

Nein — testsprite test scaffold erzeugt eine Ausgangsstruktur, und testsprite test lint validiert sie, bevor Sie committen.

Was, wenn ich zwei Testläufe vergleichen möchte, nicht zwei Dateiversionen?

Dafür gibt es testsprite test diff — es vergleicht zwei Läufe, um zu zeigen, was sich in der Ausführung geändert hat, getrennt von der eigenen Historie des Testplans in git.

Ihre Testabdeckung gehört in die Versionskontrolle.