Winst:
- Mogelijkheid om robuuste UI-testcode te produceren met kunstmatige intelligentie, inclusief data-testid, open wait en assert die het echte gebruikersresultaat verifieert
- Mogelijkheid om kwetsbare tests (slechte selector, blind wachten) te vermijden en tests gemakkelijk te onderhouden in de Page Object Model-structuur
- Mogelijkheid om elke UI-test te testen die wordt geproduceerd door de code te breken en neptests te detecteren en te repareren
Elke klik, elke formulierinvulling, elke paginaovergang die een gebruiker in een browser maakt, kan niet keer op keer met de hand worden getest. Daarom bestaat er UI-testautomatisering (gebruikersinterface; deze tests bootsen gebruikersgedrag na door een echte browser programmatisch aan te sturen). Selenium, Toneelschrijver en Cypress zijn de meest gebruikte hulpmiddelen voor deze klus. Kunstmatige intelligentie (AI) is zeer bedreven in het schrijven van de code voor deze tools: jij beschrijft een testcase, AI geeft je een concept van een werkbaar automatiseringsscript. Maar hier komt de centrale waarschuwing van deze module weer om de hoek kijken: UI-testcode die de AI produceert, kunnen vaak fragiele tests zijn die “groen oplichten maar het verkeerde verifiëren” of wapperen in de wind. Jouw taak is niet om deze code uit te voeren, maar om ervoor te zorgen dat deze daadwerkelijk het juiste verifieert.
In deze unit streven we ernaar om robuuste, onderhoudbare en echt validerende UI-tests met AI te produceren; Je leert kwetsbare tests te vermijden.
De drie pijlers van solide UI-testen
1. Correcte elementzoeker. Een test gebruikt een selector om het element op de pagina te vinden. AI produceert vaak broze selectors: lange XPath-paden (adres is te afhankelijk van de paginastructuur), selectors gebaseerd op CSS-klassenamen (breken wanneer het ontwerp verandert). De robuuste manier is stabiele attributen zoals data-testid die de ontwikkelaar heeft toegevoegd om te testen. Leg dit expliciet op aan de AI.
2. Expliciet wachten. De belangrijkste bron van kwetsbaarheid bij UI-testen is timing. Constant slapen(3) (blind wachten) is een slechte gewoonte: soms is het niet genoeg, soms verspilt het tijd. De juiste manier is om expliciet wachten te gebruiken, wat zegt: "wacht tot dit element verschijnt". Toneelschrijver doet dit grotendeels automatisch; In Selenium moet je dit expliciet aanvragen.
3. Zinvolle bewering. De test moet het resultaat verifiëren dat de gebruiker daadwerkelijk te zien krijgt, zoals ‘bestellingsnummer verscheen op het scherm’, en niet alleen ‘pagina geladen’. Als de door de AI geproduceerde test geen bewering heeft of onbelangrijk is, levert die test een pseudo-pass (1e eenheid) op.
Let op: Wanneer u voor het eerst een door AI gegenereerde UI-test ziet, controleer dan maximaal drie dingen: zijn de selectors vastgelegd (data-testid), wachten ze op (geen blinde slaap) en verifieert de bewering het daadwerkelijke gebruikersresultaat? Als deze drie in orde zijn, is de test waarschijnlijk solide.
Pagina-objectmodel
Naarmate tests groter worden, wordt het schrijven van selectors in elke test een nachtmerrie voor onderhoud. Page Object Model (POM – ontwerppatroon dat selectors en acties voor elke pagina/scherm verzamelt in één klasse) houdt de selector op één plek; Wanneer de interface verandert, werkt u deze bij in één bestand. Laat de AI de tests in een POM-structuur produceren, in plaats van rechtstreeks; Dit maakt het onderhoud radicaal eenvoudiger.
Zwakke prompt/sterke prompt
Zwak: "Schrijf een Selenium-test voor de inlogpagina."
Strong: "Schrijf een login-flowtest met Playwright (TypeScript). Selectors gebruiken alleen data-testid; gebruiken geen controle over wat de gebruiker ziet, niet over de paginatitel."
Krachtige prompt; De tool geeft de taal, het selectorbeleid, de wachtstrategie, de architectuur (POM) en de expressieve verwachtingsverwachting.
Testgegevens en omgevingsonafhankelijkheid
Een solide UI-test is niet alleen correct geschreven, maar bouwt en schoont ook zijn eigen testgegevens op. Door AI gegenereerde tests linken vaak naar een gebruiker of record waarvan wordt aangenomen dat deze al in de omgeving bestaat (“log in als admin-gebruiker”). Deze aanname vervalt wanneer de test in een andere omgeving of na een andere test wordt uitgevoerd (volgordeafhankelijkheidsprobleem in unit 9). De waarheid is dat elke test aan het begin van de test de gegevens creëert die hij nodig heeft (of deze voorbereidt met een API-aanroep) en deze aan het einde opschoont. Geef de AI expliciet de opdracht om "alle gegevens waarvan deze test afhankelijk is binnen de test in te stellen; ga niet uit van kant-en-klare gegevens van buitenaf."
Een ander cruciaal punt is om geen UI-testen uit te voeren met echte gebruikersgegevens. Als in de testomgeving een productiedatabasekopie wordt gebruikt, zijn deze records gegevens van echte personen; screenshots en testopnames kunnen deze gegevens onthullen. Gebruik synthetische (fictieve) testaccounts; het beschermt zowel de vertrouwelijkheid als maakt tests reproduceerbaar. Het uitvoeren van een "orderannuleringstest" met een echte klantaccount is zowel een ethische als een operationele fout.
Tip: Houd UI-tests zo min mogelijk; Laat de daadwerkelijke verificatie over aan de API en unit-tests, die snel en stabiel zijn. UI-testen zijn duur en broos. Gebruik het alleen om een echte end-to-end gebruikersstroom te valideren (testpiramidelogica).
Voertuigvergelijking
functie
selenium
toneelschrijver
cipres
talen
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/typescript
automatische stand-by
Nee (met de hand)
Ja (sterk)
Ja
Meerdere browsers
breed
Chroom/Firefox/WebKit
Chroom-dominant
neiging tot broosheid
Hoog (handmatige stand-by)
laag
laag
Gemakkelijk te leren
middelmatig
gemakkelijk
gemakkelijk
parallelle werking
Raster vereist
ingebouwd
Ingezeten/betaald
Geef bij het opvragen van een code bij AI duidelijk aan bij welk voertuig deze hoort; Anders kan het verwarrende, niet-werkende code opleveren.
Vier kopieerbare sjablonen
1) Solide UI-testgeneratie:
Jouw rol: senior testautomatiseringsingenieur. Schrijf tests met [tool + taal] voor de volgende flow: [flow]. Regels: - Selectors data-testid only; XPath/CSS-klasse gebruiken. - Geen blinde slaap; Gebruik expliciet/automatisch wachten. - Pagina-objectmodel toepassen. - Laat elke bewering het daadwerkelijke gebruikersresultaat verifiëren. Geef aan het begin van elke test aan welke acceptatiecriteria u valideert.
2) Controle van kwetsbaarheid:
Onderzoek de volgende UI-test op broosheid: - Is er een onstabiele selector (lange
3) Conversie naar paginaobject:
Converteer de volgende eenvoudige testcode naar de Page Object Model-structuur. Verplaats selectors en acties naar paginaklassen; Laat het testbestand alleen de scenariostroom lezen. [Tool/taal]. Code: [plak code]
4) Pseudo-transitiebestendig:
Bewijs dat deze UI-test daadwerkelijk valideert: Welke enkele wijziging breng ik aan in de applicatiecode waardoor deze test ROOD wordt? Als je geen verandering kunt vinden die de test doorbreekt, is de test ontoereikend; voeg ontbrekende beweringen toe.Test: [plak test]
drie minikoffers
Casus 1 — Bevrijding van een kwetsbare selector. Van de 40 tests die één team met AI produceerde, was 70% kapot na een interface-update; geen van hen waren echte bugs, het waren allemaal kwetsbare XPath-selectors. Het team heeft de tests omgezet in een data-testid-basis met de 'fragility check'-sjabloon. Tijdens de volgende drie interface-updates daalde het aantal valse onderbrekingen tot nul; de onderhoudstijd daalde van 6 uur naar 30 minuten per week.
Geval 2 — Valse UI-test. AI produceerde een “add to cart”-test; de test was groen. Toen de 'fake-proof-of-passage'-sjabloon werd uitgevoerd, leek het erop dat de test alleen de knopklik en de paginatitel controleerde, en nooit verifieerde of de winkelwagenteller was gestegen of niet. Zelfs als de winkelwagenlogica volledig verbroken was, slaagde de test. Waarde bewering toegevoegd (karbadge is "1").
Geval 3 — Blinde wachtval. In de Selenium-test van AI was er na elke stap slaap (2); 60 tests duurden 14 minuten en braken nog steeds af en toe. Na het overschakelen naar open wait (wachten tot het element klikbaar is) daalde de tijd naar 5 minuten en verdween de broosheid. Blind wachten was zowel traag als onbetrouwbaar.
Veel voorkomende fouten
- Instemmen met fragiele kiezers. De lange XPaths gebruiken die door de AI zijn gegenereerd zoals ze zijn; Tests crashen bij de eerste interfacewijziging.
- Blinde ‘slaap’ achterlatend. De timing "oplossen" met een vaste wachttijd; zowel langzaam als besluiteloos.
- Triviale bewering. Controleer gewoon of de pagina is geladen; het daadwerkelijke gebruikersresultaat niet controleren (fake-pass).
- Groeien zonder POM. Verdeel selectors over elke test; Handmatig tientallen bestanden bijwerken wanneer de interface verandert.
- Het gereedschap wordt niet gespecificeerd. De AI niet vertellen welke tool/taal je wilt; rommelige, niet-werkende code krijgen.
- Vertrouwend wanneer u de gegenereerde code uitvoert en slaagt. Niet testen door de code te breken.
Samengevat
Automatisering van UI-tests verifieert het gedrag van gebruikers door de daadwerkelijke browser met het programma aan te sturen. AI genereert deze code snel, maar er zijn twee grote valkuilen: broze tests (slechte selector, blind wachten) en neptests (onvolledige/triviale bewering). De drie pijlers van solide UI-testen zijn de commit-selector (data-testid), expliciet await en beweren dat het daadwerkelijke gebruikersresultaat wordt geverifieerd. Het laten genereren van tests in het Page Object Model vereenvoudigt het onderhoud radicaal. Test elke gegenereerde test met de vraag "Welke verandering zal dit doorbreken?"
Applicatie taak
Selecteer een gebruikersstroom uit uw eigen project (bijvoorbeeld inloggen of zoeken). Laat de AI tests schrijven met de template ‘robuuste UI testgeneratie’. Vervolgens: (1) controleer en repareer de selectors en wacht met een "fragiliteitscontrole", (2) bewijs dat elke test daadwerkelijk valideert met een "pseudo-pass proof", (3) breek de code en observeer dat de test rood wordt. Rapporteer het aantal geproduceerde en gecorrigeerde tests en het aantal gevonden kwetsbaarheden en pseudo-passes.
controlelijst
- [ ] Ik heb de AI de tool, taal, selectorbeleid en architectuur (POM) duidelijk gegeven.
- [ ] Ik heb geverifieerd dat de selectors data-testid zijn.
- [ ] Ik heb ervoor gezorgd dat ik expliciet/automatisch wachten gebruikte in plaats van blind slapen.
- [ ] Ik heb gecontroleerd of elke bewering het daadwerkelijke gebruikersresultaat verifieert.
- [ ] Ik heb elke test getest door de code te breken; Ik zag het rood worden.
- [ ] Ik heb de tests verzameld in de Page Object Model-structuur.