Automatisiertes KI-Testing, Bedeutung eins: KI, die Ihr Testen automatisiert

Testabdeckung, die aus Ihrem Produkt generiert wird; Schritte, die als Absichten formuliert sind, damit kosmetische Änderungen sie nicht zerstören; Fehler, die in einer Form zurückkommen, mit der derjenige arbeiten kann, der sie behebt. Die getestete Software ist gewöhnlich und deterministisch; die KI steckt im Werkzeug.

Das ist es, was die meisten Produkte dieser Kategorie tun, und das ist es, was die meisten Teams brauchen.

Bedeutung zwei: ein System testen, das KI enthält

Hier ist das Produkt selbst nicht deterministisch. Dieselbe Eingabe erzeugt unterschiedliche Ausgaben, damit steht „erwartet gleich tatsächlich“ nicht mehr zur Verfügung, und Sie brauchen eine andere Art von Assertion.

Eigenschaften statt Gleichheit

  • Prüfen Sie, ob die Ausgabe die richtige Struktur hat, eine Quelle nennt, sich an die Längenbegrenzung hält und ablehnt, was sie ablehnen soll.

Verteilungen statt einzelner Durchläufe

  • Ein einzelner Durchlauf sagt fast nichts aus. Führen Sie viele aus und verfolgen Sie die Quote.

Regression statt Absolutwerte

  • Die Frage ist, ob diese Änderung es verschlechtert hat, nicht ob es perfekt ist.

Der Fehler, den beide gemeinsam haben

Anzunehmen, dass eine bestandene Prüfung etwas bedeutet, ohne je bestätigt zu haben, dass die Prüfung überhaupt fehlschlagen kann. Im deterministischen Fall entstehen so Suites voller Assertions, die nie rot werden könnten. Im nicht deterministischen Fall entstehen Evaluationsumgebungen, die alles hoch bewerten.

Machen Sie absichtlich etwas kaputt. Eine Minute Aufwand – und es ist der einzige Beleg dafür, dass eine Prüfung, gleich welcher Art, mit dem verbunden ist, was sie zu messen vorgibt.

Die Grenze in einem gemischten Produkt ziehen

Die meisten Produkte, die KI enthalten, bestehen größtenteils nicht aus KI, und der sinnvolle Schritt ist, die Grenze ausdrücklich zu ziehen, statt den Nichtdeterminismus sich ausbreiten zu lassen.

Alles rund um die Funktion ist gewöhnliche Software: die Authentifizierung, die Speicherung, die Rate-Limits, die Oberfläche, die die Ausgabe darstellt. All das lässt sich konventionell testen, und wenn Sie das gesamte Produkt als unvorhersehbar behandeln, nur weil eine Komponente es ist, verlieren Sie viel günstige, verlässliche Testabdeckung.

Innerhalb der Grenze wechseln Sie zu Eigenschaften und Quoten. Die Eingabe geht hinein, die Ausgabe variiert, und was Sie prüfen, ist, dass sie die richtige Struktur hat, etwas Reales zitiert und ablehnt, was sie ablehnen soll. Einmal festzuhalten, wo diese Grenze verläuft, ist das, was ein Team davon abhält, entweder die deterministischen Teile mit statistischen Methoden zu übertesten oder den KI-Teil zu untertesten, weil exakte Assertions ständig fehlschlugen.

Welchen Fall haben Sie vor sich

Wenn Ihr Produkt zweimal dieselbe Antwort geben würde, sind Sie im ersten Fall und wollen generierte Testabdeckung gegen die laufende Anwendung. Wenn nicht, sind Sie im zweiten Fall und brauchen eigenschaftsbasierte Assertions und Quoten statt bestanden oder nicht bestanden.

Viele Produkte sind beides: eine deterministische Anwendung mit einer KI-Funktion darin. Testen Sie die deterministischen Teile normal und behandeln Sie die KI-Funktion als eigenes Problem, statt einen Ansatz über beide zu spannen.

Terminal

npm install -g @testsprite/testsprite-cli
testsprite setup

Das Dashboard deckt dasselbe für alle ab, die keine lokale Installation möchten, und der vollständige Befehlsumfang liegt im CLI-Repository.

Zwei Wege, und die Wahl dreht sich eigentlich darum, wer die Pipeline verantwortet. Wenn Sie die GitHub App über das Dashboard anbinden, ist dafür keinerlei Änderung an Ihrem Repository nötig, denn sie reagiert auf das Deployment, das Ihr Build ohnehin erzeugt. Ein Schritt mit GitHub Actions bringt die Prüfung ins Repository, wo sie wie der Rest des Builds geprüft wird.

Welche Bedeutung TestSprite abdeckt

Die erste. TestSprite nutzt KI, um gewöhnliche Software zu verifizieren: Testabdeckung, die aus Ihrem Produkt generiert wird, Schritte, die als Absichten formuliert sind, Ausführung gegen die ausgerollte Anwendung und Fehler, die in einer Form zurückkommen, mit der ein Coding-Agent etwas anfangen kann.

Bei einem Produkt mit einer KI-Funktion deckt das alles drumherum ab, also den größten Teil des Produkts: Authentifizierung, Speicherung, Rate-Limiting, die Oberfläche, die Abläufe, die ein Nutzer tatsächlich durchläuft. Auto-Authentication, Dynamic Variables, Dependency Chains und Auto-Cleanup übernehmen die Zustandsprobleme auf der API-Seite.

Die Funktion selbst braucht eigenschaftsbasierte Assertions und Quoten, also ein anderes Test-Harness. Diese Grenze ausdrücklich zu ziehen, ist das, was Ihnen günstige, verlässliche Testabdeckung für den deterministischen Großteil verschafft, statt das gesamte Produkt als unvorhersehbar zu behandeln.

Was davon macht TestSprite?

Das Erste. Es verifiziert deterministisches Anwendungsverhalten gegen das laufende Produkt, auch bei Anwendungen, die KI-Funktionen enthalten.

Wie testen wir eine LLM-Funktion?

Eigenschaftsbasierte Assertions, die viele Male laufen und dabei Quoten statt Einzelergebnisse verfolgen. Ablehnungen, Format und das Vorhandensein von Quellenangaben lassen sich in der Regel besser prüfen als die Qualität der Antwort.

Kann dieselbe Suite beides abdecken?

Die deterministischen Teile ja. Die nicht deterministische Funktion braucht ein eigenes Harness mit einem eigenen Begriff davon, was ein bestandenes Ergebnis ist.

Was ist eine sinnvolle Bestehensquote für eine KI-Funktion?

Was auch immer Ihre bisherige Quote war. Absolute Zielwerte aus Benchmarks lassen sich selten auf Ihr Produkt übertragen.

Ist ein einzelner fehlgeschlagener Durchlauf ein Bug?

Bei einer nicht deterministischen Funktion für sich genommen nicht. Das Signal ist eine Quote, die sich verändert hat; ein einzelner Durchlauf ist Rauschen.

Die Kurzfassung

Zwei Themen, ein Begriff.

Automatisiertes KI-Testing bedeutet entweder KI, die Ihre Software testet, oder das Testen von Software, die KI enthält. Das Erste verlangt generierte Testabdeckung gegen die laufende Anwendung, das Zweite Eigenschaften und Quoten. Beide brauchen Prüfungen, von denen Sie bestätigt haben, dass sie fehlschlagen können.