Den Anmeldestatus wiederverwenden. Veröffentlichen Sie das Geheimnis nicht.

Vor jeder kleinen Überprüfung meldet sich eine Release-Suite an. Die meiste Zeit wird damit verbracht, auf das gleiche Anmeldeformular zu warten. Durch das Speichern des authentifizierten Browserstatus kann diese Wiederholung vermieden werden, die gespeicherte Datei enthält jedoch keine harmlosen Testdaten. Es enthält möglicherweise genügend Informationen, um als Testkonto zu fungieren.

Diese Anleitung folgt der Playwright-Authentifizierungsdokumentation, um die Grenze explizit zu machen. Der beigefügte Screenshot ist ein lokaler gefälschter Kontobildschirm. Es wurde kein echter Login, Token oder Kundendatensatz verwendet. Die Frage ist, wie man den wiederverwendbaren Zustand sicher vorbereitet, und nicht, wie man die Authentifizierungsrichtlinie einer Anwendung umgeht.

Entscheiden Sie, was die Suite wiederverwenden darf

Ein Test einer Profileinstellung erfordert normalerweise eine authentifizierte Sitzung. Es ist nicht unbedingt erforderlich, das Anmeldeformular erneut auszufüllen. Ein Test der Anmeldung selbst hat eine andere Aufgabe: den tatsächlichen Authentifizierungsablauf, das Ablehnungsverhalten und relevante Sitzungsregeln zu überprüfen. Durch die Wiederverwendung des Status in der ersten Gruppe darf die zweite Gruppe nicht stillschweigend gelöscht werden.

Notieren Sie sich diese Gruppen, bevor Sie eine Verknüpfung hinzufügen. Ein Setup-Projekt kann die genehmigte Anmeldung durchführen und den Status speichern; Abhängige Tests können von diesem Zustand aus beginnen. Der Authentifizierungsleitfaden zeigt dieses Muster. Der Staat muss zu einer kontrollierten Testidentität in einer genehmigten Umgebung gehören und nur über die Berechtigungen verfügen, die der Test benötigt.

// After your approved test-account login has completed:
await expect(page.getByRole('button', { name: 'Sign out' })).toBeVisible();
await page.context().storageState({ path: 'playwright/.auth/user.json' });

Die sichtbare Schaltfläche ist der Bereitschaftsvertrag unserer illustrativen App und kein allgemeiner Beweis dafür, dass jede Authentifizierungsmethode abgeschlossen ist. Für Ihre Anwendung ist möglicherweise ein anderer stabiler Zustand erforderlich. Warten Sie, bis die Sitzung eingerichtet ist, bevor Sie sie speichern. Andernfalls erhält der nächste Test möglicherweise den Status „Unvollständig" und führt zu einem verwirrenden Fehler.

Die Datei gehört außerhalb des Repositorys

Playwright warnt davor, dass der gespeicherte Browserstatus vertrauliche Cookies und Header enthalten kann, die zur Identitätsfälschung eines Kontos verwendet werden können. Die Dokumentation rät davon ab, diese Dateien entweder in private oder öffentliche Repositories zu übertragen. Ein privates Repository ist immer noch ein Vertriebskanal und kein sicherer Speicher für Anmeldeinformationen.

playwright/.auth/

Das Ignorieren des Verzeichnisses dient der Vorbeugung und nicht der Abhilfe. Wenn eine Statusdatei bereits festgeschrieben wurde, werden durch das Entfernen aus der Arbeitsstruktur frühere Revisionen nicht gelöscht. Hören Sie auf, dieses Artefakt zu verbreiten, und befolgen Sie den Prozess zur Offenlegung von Anmeldeinformationen Ihrer Organisation. Fügen Sie keine echte Statusdatei in ein Tutorial, einen Issue-Anhang, ein Trace-Bundle oder einen Screenshot ein, um eine Erklärung konkreter zu machen.

Überprüfen Sie die Regeln zum Hochladen von Artefakten sowie die Regeln zur Quellcodeverwaltung. Ein CI-Job lädt nach einem Fehler möglicherweise den gesamten Arbeitsbereich hoch. Eine ignorierte Datei kann weiterhin in dieses Archiv gelangen. Halten Sie den gespeicherten Anmeldestatus ausdrücklich von Debugging-Bundles und Backups fern, die ihn nicht benötigen. Verwenden Sie Testkonten und kurzlebigen Zugriff, sofern Ihre Umgebung dies unterstützt.

Wiederverwendung ist kein lebenslanges Versprechen

Der gespeicherte Zustand läuft ab. Der Leitfaden empfiehlt, den abgelaufenen Status zu löschen und weist darauf hin, dass Projektausgabeverzeichnisse vor der Ausführung bereinigt werden. Wählen Sie einen Lebenszyklus, der der Sitzungsrichtlinie entspricht, anstatt davon auszugehen, dass die Datei von gestern für immer gültig ist. Ein Setup-Fehler sollte abhängige Prüfungen aus einem sinnvollen Grund stoppen und nicht zu Dutzenden unabhängiger Seitenfehler führen.

Auch Speichermechanismen sind wichtig. Im Authentifizierungsleitfaden von Playwright werden Cookies, lokale Speicherung und andere Mechanismen erörtert, mit einer besonderen Handhabung der Sitzungsspeicherung. Gehen Sie nicht davon aus, dass jede Login-Implementierung durch den einfachsten storageState-Aufruf erfasst wird. Überprüfen Sie, was Ihre Anwendung verwendet, und stellen Sie sicher, dass ein neuer Kontext die beabsichtigte authentifizierte Seite erreichen kann.

Ein sicheres lokales Experiment verwendet einen Fake-State, um den Mechanismus zu demonstrieren. Es beweist, dass der Browser diesen ausgewählten Wert wiederherstellen kann und nicht, dass ein Identitätsanbieter, eine MFA-Richtlinie oder eine Produktionssitzung validiert wurde. Behalten Sie diese Unterscheidung im Testbericht bei.

Geben Sie parallelen Tests einen ausreichend unabhängigen Status

Die Wiederverwendung eines Kontos kann für schreibgeschützte Tests sinnvoll sein, die den Status des gemeinsam genutzten Servers nicht ändern. Riskant wird es, wenn mehrere Tests dieselben Einstellungen oder Datensätze bearbeiten. Durch die Browserkontexttrennung wird das Serverkonto nicht getrennt. Unser früherer Isolationsleitfaden behandelt diese Kollision. Hier besteht die praktische Regel darin, die Authentifizierungseinrichtung an das Mutationsmuster der Suite anzupassen.

Halten Sie die Bereitschaftsprüfung, den Identitätsbereich, den Speichermechanismus, die Ablaufregel und die Artefaktausschlüsse in einer kleinen Einrichtungsnotiz fest. Dieser Hinweis erleichtert die Überprüfung eines generierten Tests. Ein Prüfer kann sehen, warum die Anmeldung wiederverwendet wird, welche Anmeldetests noch ausgeführt werden und wohin der Status gehen darf.

AnyTest beschreibt Agenten, die eine App erkunden und End-to-End-Tests zur menschlichen Überprüfung erstellen. Wenden Sie dieselben Fragen auf jede vorgeschlagene authentifizierte Reise an. Hierbei handelt es sich um eine Überprüfungspraxis und nicht um eine Aussage über die Anmeldeinformationsspeicherung oder Anmeldekonfiguration von AnyTest. Eine weniger wiederholte Einrichtung ist nur dann sinnvoll, wenn die Suite die Authentifizierungsgrenze weiterhin schützt.