Hergebruik de inlogstatus. Publiceer het geheim niet.

Een releasesuite meldt zich vóór elke kleine controle aan. Het grootste deel van de run wordt besteed aan het wachten op hetzelfde inlogformulier. Het opslaan van de geverifieerde browserstatus kan die herhaling verwijderen, maar het opgeslagen bestand is geen onschadelijke testgegevens. Het kan voldoende informatie bevatten om als testaccount te fungeren.

Deze handleiding volgt de authenticatiedocumentatie van Playwright om de grens expliciet te maken. De bijbehorende schermafbeelding is een lokaal nepaccountscherm. Er werd geen echte login, token of klantrecord gebruikt. De vraag is hoe je de herbruikbare status veilig kunt voorbereiden, en niet hoe je het authenticatiebeleid van een applicatie kunt omzeilen.

Bepaal wat de suite mag hergebruiken

Voor het testen van een profielinstelling is doorgaans een geverifieerde sessie nodig. Het is niet noodzakelijkerwijs nodig om het inlogformulier opnieuw uit te voeren. Een inlogtest zelf heeft een andere taak: het verifiëren van de daadwerkelijke authenticatiestroom, het afwijzingsgedrag en de relevante sessieregels. Het hergebruiken van de status in de eerste groep mag de tweede groep niet stilletjes uitwissen.

Schrijf deze groepen op voordat u een snelkoppeling toevoegt. Een installatieproject kan de goedgekeurde aanmeldings- en opslagstatus uitvoeren; afhankelijke tests kunnen vanuit die status starten. De authenticatiegids laat dit patroon zien. De staat moet behoren tot een gecontroleerde testidentiteit in een goedgekeurde omgeving, met alleen de rechten die de test nodig heeft.

// 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' });

De zichtbare knop is het gereedheidscontract van onze illustratieve app, en geen universeel bewijs dat elke authenticatiemethode is voltooid. Uw toepassing heeft mogelijk een andere stabiele toestand nodig. Wacht tot de sessie tot stand is gebracht voordat u deze opslaat, anders kan de volgende test een onvolledige status krijgen en een verwarrende fout veroorzaken.

Het bestand hoort buiten de repository

Playwright waarschuwt dat de opgeslagen browserstatus gevoelige cookies en headers kan bevatten die kunnen worden gebruikt om een account na te bootsen. De documentatie ervan ontmoedigt het vastleggen van deze bestanden in privé- of openbare opslagplaatsen. Een privérepository is nog steeds een distributiekanaal en geen veilige opslagplaats voor inloggegevens.

playwright/.auth/

Het negeren van de map is preventie, geen herstel. Als een statusbestand al is vastgelegd, worden eerdere revisies niet gewist door het uit de werkboom te verwijderen. Stop met het verspreiden van dat artefact en volg het proces voor het blootleggen van referenties van uw organisatie. Plaats geen echt statusbestand in een tutorial, uitgavebijlage, tracebundel of screenshot om een ​​uitleg concreter te maken.

Controleer de uploadregels voor artefacten en de regels voor bronbeheer. Een CI-taak kan na een fout de gehele werkruimte uploaden. Een genegeerd bestand kan nog steeds dat archief binnendringen. Houd de opgeslagen inlogstatus expliciet buiten debugbundels en back-ups die deze niet nodig hebben. Gebruik testaccounts en kortstondige toegang waar uw omgeving deze ondersteunt.

Hergebruik is geen levenslange belofte

Opgeslagen status verloopt. De handleiding raadt aan om de verlopen status te verwijderen en merkt op dat projectuitvoermappen worden opgeschoond voordat ze worden uitgevoerd. Kies een levenscyclus die overeenkomt met het sessiebeleid in plaats van ervan uit te gaan dat het bestand van gisteren voor altijd geldig is. Een installatiefout zou afhankelijke controles om een ​​nuttige reden moeten stoppen, en niet uitmonden in tientallen niet-gerelateerde paginafouten.

Opslagmechanismen zijn ook van belang. De authenticatiegids van Playwright bespreekt cookies, lokale opslag en andere mechanismen, met speciale afhandeling voor sessie-opslag. Ga er niet van uit dat elke aanmeldingsimplementatie wordt vastgelegd door de eenvoudigste storageState-aanroep. Controleer wat uw toepassing gebruikt en controleer of een nieuwe context de beoogde geverifieerde pagina kan bereiken.

Een veilig lokaal experiment maakt gebruik van een nepstatus om het mechanisme te demonstreren. Het bewijst dat de browser die geselecteerde waarde kan herstellen, en niet dat een identiteitsprovider, MFA-beleid of productiesessie gevalideerd is. Houd dat onderscheid vast in het testrapport.

Geef parallelle tests voldoende onafhankelijke status

Het hergebruiken van één account kan redelijk zijn voor alleen-lezen-tests waarbij de status van de gedeelde server niet wordt gewijzigd. Het wordt riskant als meerdere tests dezelfde voorkeuren of records bewerken. Door browsercontextscheiding wordt het serveraccount niet gescheiden. Onze eerdere isolatiegids behandelt die botsing; hier is de praktische regel om de authenticatie-instellingen af ​​te stemmen op het mutatiepatroon van de suite.

Bewaar de gereedheidscontrole, het identiteitsbereik, het opslagmechanisme, de vervalregel en de uitsluitingen van artefacten in een kleine installatienotitie. Die opmerking maakt het gemakkelijker om een ​​gegenereerde test te beoordelen. Een reviewer kan zien waarom login wordt hergebruikt, welke inlogtests er nog lopen en waar de staat naartoe mag.

AnyTest beschrijft dat agenten een app verkennen en end-to-end tests bouwen voor menselijke beoordeling. Pas dezelfde vragen toe op elke voorgestelde geauthenticeerde reis. Dit is een beoordelingspraktijk en geen claim over de opslag van inloggegevens of de inlogconfiguratie van de AnyTest. Minder herhaalde configuratie is alleen nuttig als de suite nog steeds de authenticatiegrens beschermt.