Kvalitet og stabil drift

Teststrategi til en AI-bygget app: bevis det vigtigste før udgivelse

En app er ikke testet, fordi nogen har klikket rundt i den én gang. En brugbar teststrategi beskriver de vigtigste brugerrejser og risici, vælger den rette type test til hver af dem og giver et tydeligt stop, når en ændring har brudt noget vigtigt.

Start med risikoen – ikke med et antal tests

Skriv de handlinger ned, som appen ikke må ødelægge. Det kan være login, oprettelse af en ordre, godkendelse af timer, beregning af et beløb eller adgang til den rigtige kundes data. Vurdér for hver handling både sandsynligheden for fejl og konsekvensen, hvis den fejler.

Forretning: Hvilken arbejdsgang stopper medarbejderen eller kunden?
Data: Hvilken fejl kan oprette dubletter, miste ændringer eller ramme den forkerte post?
Adgang: Hvilken handling skal altid afvises for den forkerte rolle eller virksomhed?
Integration: Hvad sker der, hvis en ekstern tjeneste svarer sent, svarer med fejl eller sender samme hændelse igen?
Udgivelse: Hvilket lille sæt kontroller skal bestå, før ændringen må blive tilgængelig?

En lille suite kan være den rigtige start. Fem præcise tests af kritiske arbejdsgange giver mere ro end mange tests, der kun bekræfter interne detaljer uden at beskytte brugeren eller dataene.

Vælg testtypen efter det, der kan gå galt

Testtyperne konkurrerer ikke. De undersøger forskellige dele af samme løsning. Vælg det smalleste niveau, som stadig kan bevise den adfærd, I er afhængige af.

Unit-test: en afgrænset forretningsregel: Brug den til eksempelvis beregning, validering eller statusskift, som kan køres med kontrollerede input uden browser, database eller netværk. Test både gyldige værdier, grænsetilfælde og forventede afvisninger.
Komponenttest: det brugeren ser og gør: Kontrollér formularer, fejlbeskeder, knapper og tilstande gennem synlige labels, roller og tekst. Det gør testen mindre afhængig af CSS-klasser og interne komponentdetaljer og kan samtidig afsløre problemer i den tilgængelige struktur.
Integrationstest: grænserne mellem dele: Kontrollér eksempelvis API, database, adgangsregler eller køer sammen. Brug et isoleret testmiljø, en lokal emulator eller en kontrolleret testservice, så testen ikke skriver i produktion eller afhænger af tilfældige produktionsdata.
End-to-end-test: den kritiske brugerrejse: Kør få vigtige forløb i en rigtig browser: log ind, udfør kernehandlingen, genindlæs og bekræft resultatet. En browser-test kan bevise, at flere lag virker sammen, men den skal have styrede data og være uafhængig af de øvrige tests.

Skriv scenariet, før AI'en skriver testen

Et testværktøj kan kun kontrollere det krav, nogen har gjort tydeligt. Beskriv hvert kritisk scenarie i forretningens sprog, før en AI-assistent eller udvikler vælger framework og kode.

Felt	Eksempel
Situation	En medarbejder registrerer tid på en åben sag.
Forventet resultat	Registreringen gemmes én gang og vises efter genindlæsning.
Afvisning	Lukket sag, negativ varighed og en anden virksomheds sag afvises.
Testdata	Navngivne testbrugere og sager, som nulstilles mellem kørsler.
Bevis	Svarstatus, synlig besked og den forventede post i testdatabasen.

Bed gerne AI'en om at skrive en fejlende test først og forklare, hvilket krav den beviser. Læs derefter både testen og ændringen. Genereret testkode kan gentage samme forkerte antagelse som den genererede produktionskode.

Hold testdata adskilt fra produktion

Automatiske tests skal kunne oprette, ændre og rydde data uden at ramme rigtige kunder. Brug separate projekter, databaser eller emulatorer efter den stack, appen allerede anvender. Firebase Local Emulator Suite kan blandt andet bruges til lokale integrations- og manuelle tests af understøttede Firebase-tjenester uden at skrive i produktion.

Kend starttilstanden: Opret de nødvendige testdata som en del af opsætningen.
Nulstil efter behov: En test må ikke kun bestå, fordi en tidligere test efterlod en bestemt post.
Brug testkonti: Læg aldrig private adgangskoder eller produktionsnøgler direkte i testkoden.
Kontrollér tredjepartsgrænsen: Erstat eksterne svar med en kontrolleret testvariant, når I ikke ejer eller kan styre tjenesten.
Test kontrakten særskilt: Hav en kontrolleret kontrol af den rigtige integration, hvis en mock ellers kan skjule en ændring hos leverandøren.

Gør browser-tests stabile nok til at stole på

Playwright anbefaler isolerede tests og lokatorer baseret på brugerrettede egenskaber. Find derfor knapper efter rolle og tilgængeligt navn frem for en tilfældig CSS-klasse, og lad hver test oprette sin egen kendte tilstand.

Vent på et resultat: Vent på den synlige besked, navigation eller netværkstilstand – ikke et fast antal sekunder.
Undgå kæder: Test B må ikke kræve, at test A blev kørt først.
Gem fejlbevis: En trace fra en fejlet kørsel kan vise handlinger, DOM-tilstand og netværk, så fejlen kan undersøges bagefter.
Skjul ikke ustabilitet: En test, der kun består ved gentagelse, skal stadig undersøges. Gentagelser er et diagnoseværktøj, ikke et kvalitetsstempel.

Kør de rigtige kontroller på det rigtige tidspunkt

Hurtige, afgrænsede tests kan køres under udvikling. De kritiske integrations- og browser-tests kan køres ved pull requests eller før udgivelse. Et lille smoke test efter deployment kan kontrollere, at den faktiske version kan nås og udføre en sikker kernehandling i det relevante miljø.

Ved kodeændringen: Kør de tests, der dækker den ændrede regel eller komponent.
Ved pull request eller main: Kør den aftalte suite og produktionsbuildet automatisk.
Før udgivelse: Kræv grønt resultat fra de kontroller, der reelt skal blokere en fejlbehæftet version.
Efter udgivelse: Kør et sikkert smoke test uden at oprette ukontrollerede produktionsdata.

En grøn GitHub Actions-kørsel er kun så stærk som de kommandoer og scenarier, den faktisk kører. Tilføj ikke en ustabil test som hård udgivelsesblokering, før dens data, afhængigheder og fejlsøgning er under kontrol.

Typiske fejl

Kun den glade vej testes: Forkert rolle, ugyldigt input og fejl fra integrationen bliver aldrig afprøvet.
Testen kopierer implementationen: Både kode og test kan være enige om den samme forkerte forretningsregel.
Alt testes gennem browseren: Små regler bliver langsomme og svære at diagnosticere, selv om de kunne testes afgrænset.
Kun interne funktioner testes: Ingen kontrol beviser, at login, API, database og brugerflade virker sammen.
Produktionsdata bruges som testdata: Testen kan ændre rigtige oplysninger og bliver afhængig af en ukendt tilstand.
Fejlende tests køres bare igen: Ustabilitet bliver normaliseret, og et reelt problem kan blive overset.
AI'en erklærer testen færdig: Ingen har kontrolleret, at testen fejler, når den beskyttede adfærd bevidst brydes.

Tjekliste før medarbejdere eller kunder får adgang

☐ De vigtigste brugerrejser og deres forretnings-, data- og adgangsrisici er skrevet ned.
☐ Hvert kritisk scenarie har forventet resultat, afvisninger og kendte testdata.
☐ Forretningsregler testes afgrænset med relevante grænsetilfælde.
☐ Formularer og komponenter testes gennem synlig og tilgængelig adfærd.
☐ API, database og adgangsregler har relevante integrationstests.
☐ Få kritiske brugerrejser er dækket i en rigtig browser.
☐ Tests skriver ikke i produktion og bruger ikke rigtige kundedata.
☐ Hver test kan køres uafhængigt med en kendt starttilstand.
☐ Fejl fra eksterne tjenester og gentagne hændelser er afprøvet, hvor det er relevant.
☐ Testkommandoer og produktionsbuild kører automatisk ved de aftalte ændringer.
☐ En kontrolleret fejl beviser, at den relevante test faktisk bliver rød.
☐ En navngiven ansvarlig undersøger ustabile eller fejlende tests.

Relaterede guides

GitHub Actions til automatisk test og build Testmiljø og rollback ved udgivelse Roller, rettigheder og negative adgangstests Logning og overvågning efter udgivelse Se hele guidebiblioteket

Officielle kilder

Framework, kommandoer og testmiljø afhænger af appens stack. Vælg værktøjer, der passer til den eksisterende kodebase, og kontrollér altid den aktuelle dokumentation for den valgte løsning.