Gevinster:
- Evne til å transformere et krav og akseptkriterier til omfattende testcases med teknikker som ekvivalensklasser, grenseverdianalyse og beslutningstabeller, med støtte av kunstig intelligens
- Evne til å produsere positive, negative og edge case-scenarier separat og fullføre kantsakene som er savnet av kunstig intelligens med produktinformasjon
- Evne til å etablere sporbarhet og eliminere dekningshull og unødvendig oppblåsthet ved å koble testtilfeller til akseptkriterier
Testerens jobb starter ofte med denne blanke tavlen: han har et krav ("brukeren må kunne tilbakestille passordet sitt") og han må gjøre denne enkeltsetningen om til dusinvis av konkrete kontroller som vil bevise at programvaren faktisk fungerer som den skal. Denne transformasjonen kalles testdesign. Å vite forskjellen mellom et testscenario - et mål på høyt nivå som beskriver hva som skal testes, for eksempel "ugyldig passord bør avvises" - og en testcase - en kjørbar enhet som beskriver det scenariet med konkrete trinn, input og forventet utfall er nøkkelen. Kunstig intelligens (AI) akselererer akkurat dette øyeblikket på tomme sider: gjør ett krav om til dusinvis av utkastscenarier på sekunder. Men husk - AI gjengir hvilke situasjoner du kan tenke deg; Du velger med din produktkunnskap hvilke situasjoner som er virkelig viktige.
I denne enheten lærer du trinn for trinn hvordan du gjør et krav til en omfattende, men rotfri testsuite med AI-støtte.
Trinn for trinn: fra krav til testsett
Trinn 1 — Klargjør kravet. Samle akseptkriterier (betingelser som en jobb må oppfylle for å bli ansett som "ferdig") før du gir AI det rå kravet. "Passord må kunne tilbakestilles" er ikke nok; Regler som "tilbakestill lenke er gyldig i 30 minutter", "det samme passordet kan ikke gjenbrukes" er kilden til den virkelige testen.
Trinn 2 — Implementer testteknikker. Ikke bare si "skriv et script" om AI; Spør etter klassiske testdesignteknikker ved navn:
- Ekvivalensklasser (ekvivalenspartisjonering): Deling av innganger i grupper som forventes å produsere samme oppførsel. For eksempel, for aldersfeltet, er "gyldig område", "for lite" og "for stort" klasser; Det er tilstrekkelig å teste ett eksempel fra hver klasse.
- Grenseverdianalyse: Testing av terskelverdier basert på at feil oppstår mest ved grensene. Det er som å teste 17, 18, 19 separat for 18-årsgrensen.
- Beslutningstabell: Tabeller kombinasjoner av flere forhold og forventet utfall av hver kombinasjon.
- Tilstandsovergang: Testing av systemets overganger fra stat til stat (for eksempel ordre: opprettet → betalt → sendt) og ugyldige overganger.
Trinn 3 — Skill positive, negative og kanttilstander. Be om en positiv test (forventet resultat med riktig inntasting), en negativ test (riktig feil med ugyldig inndata) og en kantsak - grense eller uvanlige tilfeller. AI legger generelt vekt på det positive; Negative saker og kantsaker er ufullstendige med mindre du eksplisitt ber om dem.
Trinn 4 — Prioriter og beskjær. AI kan generere 60 scenarier; De er ikke alle like verdifulle. Prioriter de med høy risiko (penger, sikkerhet, tap av data) og kombiner de som er duplikater.
Tips: Send en separat forespørsel til AI og si "generer 5 utenkelige kantsaker fra dette kravet". Det mest verdifulle bidraget til AI er at det ofte minner deg om ekstraordinære situasjoner du har oversett.
Svak forespørsel / Sterk forespørsel
Svak: "Skriv testsaker for tilbakestilling av passord."
Sterkt: "Generer testtilfeller for funksjonen 'passordtilbakestilling' med følgende akseptkriterier: lenke gyldig i 30 minutter, engangsbruk, siste 3 passord kan ikke gjenbrukes, konto låst i 15 minutter etter 5 feil forsøk. Bruk ekvivalensklasser og grenseverdianalyse. Gi positive, negative og kanttilfeller i separate trinn, tilknyttede overskrifter, forutsetning, testresultat: for hver forutsetning, forutsetning, testresultat: kriterier for sikkerhet/låsing.
Kraftig ledetekst; Den gir regler, teknikker, utdataformat og prioritert rekkefølge. Dermed produserer AI kjørbare og sporbare testtilfeller, ikke dekorative.
Utdataformat for testcase
Be om et strukturert format som kan importeres direkte til teamets testadministrasjonsverktøy (f.eks. TestRail, Zephyr, Xray). Følgende tabell viser komponentene i en god testcase:
område
Beskrivelse
eksempel
ID
unik ID
TC-PWD-014
Tittel
kort formål
Utløpt lenke vil bli avvist
forutsetning
Tilstand nødvendig før testing
Tilbakestillingslink ble generert for 31 minutter siden
trinn
Sekvensielle handlinger
1. Klikk på lenken 2. Skriv inn nytt passord
testdata
Konkrete verdier brukt
gammel lenke, nytt passord "Abc!2345"
forventet resultat
Atferd som skal verifiseres
"Link utløpt" feil, passord endres ikke
Akseptkriterier
sporbarhetslenke
AK-3: link gyldig i 30 minutter
prioritet
Risikonivå
høy
Fire kopierbare maler
1) Teknisk basert scenarioproduksjon:
Din rolle: senior testdesigner.Generer testcaser for funksjon: [funksjon og akseptkriterier].Bruk: ekvivalensklasser, bruddpunktanalyse, beslutningstabell.Gi utdata i 3 grupper: Positiv / Negativ / Edge-tilfelle.Hver sak: ID, forutsetning, trinn, testdata, forventet resultat, tilhørende akseptkriterier, prioritet (Høy/Middels/Lav).
2) Edge case hunter:
Liste 10 normalt oversett kant tilfeller for følgende funksjon: [funksjon]. Skriv i én setning hvorfor det er risikabelt for hver. Tenk på akser som tom/null, for lang inndata, samtidighet, tidsavbrudd, formatfeil, Unicode/emoji, negativ/null, nettverksbrudd.
3) Produksjon av beslutningstabell:
Opprett beslutningstabell for følgende forretningsregel: [regler]. Kolonner: betingelseskombinasjoner; rader: hver betingelse og forventet handling. Flagg uoppnåelige eller motstridende kombinasjoner. Foreslå deretter en testcase for hver kombinasjon.
4) Sporbarhetskontroll:
Gitt følgende liste over akseptkriterier og følgende testtilfeller:[kriterier] / [tilfeller]. Vis i tabellform hvilke akseptkriterier som oppfylles av NO-testtilfeller (dekningsgap) og hvilke saker som ikke oppfylles av noen kriterier (overflødig sak).
tre minisaker
Tilfelle 1 — Verdi av kanttilstander. En ekspert fra et fintech-team hadde skrevet 18 skript for pengeoverføringsfunksjonen. Han brukte "edge case hunter"-malen på AI; AI minnet situasjonen om å "overføre den samme saldoen fra to enheter samtidig" (samtidig). Da dette scenariet ble testet, ble et dobbeltforbrukssårbarhet funnet og lukket før det ble publisert. En enkelt utkantssituasjon forhindret et potensielt sekssifret tap.
Tilfelle 2 — Trimming av bulen. Et team fikk AI til å produsere et manus for medlemsskjemaet og 74 saker kom gjennom. Ved å kjøre sporbarhetsmalen fant man at 74 tilfeller kun oppfylte 9 akseptkriterier, med mange som testet samme ekvivalensklasse på nytt. Settet ble redusert fra 74 til 23 signifikante saker; kjøretiden gikk ned med 68 %, dekningen ble ikke redusert.
Sak 3 – Feil antagelse. AI foreslo å teste ugyldige datoer som "31. februar" for et datofelt, men visste ikke at kalenderkomponenten teamet brukte allerede blokkerte dette. Eksperten eliminerte 4 av de 6 datoscenarioene produsert av AI som unødvendige i forbindelse med produktet. AI genererte muligheter; gjort et produktinformasjonsvalg.
Vanlige feil
- Be om et manus uten å oppgi akseptkriterier. Uten å vite hva som er sant, produserer AI overfladiske scenarier som ofte går glipp av den reelle risikoen.
- Bare nøye seg med positive tester. Vil eksplisitt ikke ha negative og kantsaker. Det er her feilene ofte ligger.
- Å akseptere det som produseres som det er. Å glemme at AI ikke kjenner produktkonteksten og etterlater unødvendige eller umulige scenarier på settet.
- Omgå sporbarhet. Å ikke knytte saker til akseptkriterier; som et resultat av det ses ikke hvilket kriterium som ikke testes (dekningsgap).
- Mengdefeil. Å være glad fordi "60 manus har blitt sluppet". Verdien er ikke i tallet, men i omfanget som dekker risikoen.
Oppsummert
Testdesign handler om å oversette et krav på én setning til konkrete, kjørbare tilfeller som beviser programvarens riktighet. AI akselererer denne transformasjonen kraftig: den produserer omfattende tegninger når du gir den akseptkriterier, klassiske testteknikker (ekvivalensklasser, bruddpunkt, beslutningstabell, tilstandsovergang) og et tydelig utdataformat. Men AI er partisk mot det positive, kjenner ikke produktkonteksten og kan gi unødvendig oppblåsthet. Din jobb er å eksplisitt etterspørre negative saker og kantsaker, etablere sporbarhet, prioritere etter risiko og beskjære.
Søknadsoppgave
Velg en funksjon fra ditt eget prosjekt og skriv ned akseptkriteriene. Få AI til å generere testtilfeller med malen "teknikkbasert scenariogenerering". Bruk deretter malene "edge case hunter" og "sporbarhetssjekk". Som et resultat: (1) legg til minst 3 kantsaker som AI hopper over, (2) beskjær tilfeller som ikke kobles til noen akseptkriterier, (3) skriv nye saker hvis det er noen akseptkriterier som ikke er testet. Hell det siste settet i et regneark.
sjekkliste
- [ ] Før jeg ba om et manus, avklarte jeg akseptkriteriene.
- [ ] Jeg spurte YZ om ekvivalensklasser og grenseverdianalyse etter navn.
- [ ] Jeg genererte positive, negative og kanttilstander separat.
- [ ] Jeg koblet hvert testtilfelle til et akseptkriterium (sporbarhet).
- [ ] Jeg sjekket omfangsgapet og unødvendige saker med tabellen.
- [ ] Jeg prioriterte etter risiko og beskjærte det hovne settet.