Positiv testning og negativ testning med eksempler
Thomas Hamilton
⚡ Smart opsummering
Positiv og negativ testning afgør tilsammen, om software accepterer, hvad den skal, og afviser, hvad den ikke skal. Denne artikel forklarer begge tilgange, teknikkerne bag dem, praktiske eksempler og de fremgangsmåder, der holder defektlækage lav.
Softwaretestning er processen med at verificere og validere en softwareapplikation for at kontrollere, om den fungerer som forventet. Formålet er at finde fejl og forbedre produktkvaliteten. Der er to måder at teste software på, nemlig positiv testning og negativ testning.
De to tilgange besvarer modsatrettede spørgsmål: Virker applikationen, når alt går godt, og forbliver den stabil, når noget går galt?
Hvad er positiv testning?
Positiv test er en type test, der udføres på en softwareapplikation ved at levere gyldige datasæt som input. Den kontrollerer, om softwareapplikationen opfører sig som forventet med positive input eller ej.
Positiv testning udføres for at kontrollere, om softwareapplikationen gør præcis, hvad den forventes at gøre. Det kaldes derfor også happy path-testning.
For eksempel, overvej det numeriske tekstfelt vist nedenfor.
.png)
Der er en tekstboks i en applikation, som kun kan acceptere tal. Indtastning af værdier op til 99999 vil være acceptable af systemet, og alle andre værdier ud over dette bør ikke være acceptable. For at udføre positiv test skal du indstille de gyldige inputværdier fra 0 til 99999 og kontrollere, om systemet accepterer værdierne.
Hvad er negativ test?
Negativ test er en testmetode, der udføres på softwareapplikationen ved at levere ugyldige eller forkerte datasæt som input. Den kontrollerer, om softwareapplikationen opfører sig som forventet med negative eller uønskede brugerinput.
Formålet med negativ testning er at sikre, at softwareapplikationen ikke går ned og forbliver stabil med ugyldige datainput. Det kaldes derfor også fejlstitestning eller fejltestning.
For eksempel, overvej at det samme felt modtager tegn i stedet for cifre.
.png)
Negativ test kan udføres ved at indtaste tegnene A til Z eller fra a til z. Enten bør softwaresystemet ikke acceptere værdierne, eller også bør det sende en fejlmeddelelse for disse ugyldige datainput.
Ved begge typer test skal følgende overvejes:
- Indtast data
- En handling, der skal udføres
- Output resultat
Positiv test vs. negativ test: Vigtigste forskelle
Begge tilgange deler det samme test sag struktur. Forskellen ligger i det input, du leverer, og i hvad et forbigående resultat beviser.
| Parameter | Positiv test | Negativ test |
|---|---|---|
| Også kendt som | Lykkelig sti-testning | Fejlsti eller fejltestning |
| Brugt input | Gyldige, forventede data | Ugyldige, ekstreme eller uventede data |
| Mål | Bekræft at funktionen gør hvad den skal | Bekræft, at funktionen afviser det, den ikke burde |
| Forventet resultat | Flowet er fuldført | Der vises en tydelig fejl, og systemet forbliver stabilt |
| Fejl ved håndtering | Ikke fokus | Hele fokus |
| Dækning | Smal, følger specifikationen | Bred, udforsker alt uden for specifikationen |
| Typisk risiko hvis oversprunget | Kernefunktioner leveres i stykker | Nedbrud og sikkerhedshuller når produktionen |
En fejlende positiv test signalerer defekt funktionalitet. En fejlende negativ test signalerer en manglende beskyttelsesskærm, som er langt dyrere at reparere, når brugerne først har fundet den.
Testteknikker anvendt til positiv og negativ testning
I praksis genererer to klassiske input-designteknikker både positive og negative cases ud fra det samme krav:
- Grænseværdianalyse
- Ækvivalenspartitionering
Grænseværdianalyse
Dette er en af softwaretestteknikkerne, hvor testcases er designet til at inkludere værdier ved grænsen. Hvis inputdata bruges inden for grænseværdigrænserne, siges det at være positiv test. Hvis inputdata er plukket uden for grænseværdigrænserne, siges det at være negativ test.
Se for eksempel på det accepterede interval illustreret nedenfor.
.png)
Et system kan acceptere tallene fra 0 til 10 numeriske værdier. Alle andre tal er ugyldige værdier. Under denne teknik vil grænseværdierne -1,0,1 og 9,10,11 blive testet.
Ækvivalenspartitionering
Dette er et software test teknik, som deler inputdataene op i mange partitioner. Værdier fra hver partition skal testes mindst én gang. Partitioner med gyldige værdier bruges til positiv test. Mens partitioner med ugyldige værdier bruges til negativ test.
Undersøg for eksempel de to partitioner vist nedenfor.
.png)
Numeriske værdier fra nul til ti kan opdeles i to (eller tre) partitioner. I vores tilfælde har vi to partitioner -10 til -1 og 0 til 10. Eksempelværdier (5 og -5) kan tages fra hver del for at teste scenarierne. Se ækvivalenspartitionering og randværdianalyse lektion for flere bearbejdede eksempler.
Sådan udfører du positiv og negativ testning
Den følgende sekvens omdanner ét krav til et afbalanceret sæt af positive og negative tilfælde.
- Læs kravet til grænser. Bemærk alle accepterede formater, områder og obligatoriske felter. Alt, hvad specifikationen tillader, bliver et positivt tilfælde, og alt, hvad den udelukker, bliver et negativt tilfælde.
- Skriv det positive tilfælde først. Angiv gyldige data, udfør handlingen, og registrer det forventede succesresultat som udgangspunkt.
- Udled negative tilfælde fra de samme grænser. Brug randværdianalyse og ækvivalenspartitionering til at producere tomme felter, forkerte datatyper og tal uden for området.
- Tilføj fjendtlige input. Medtag SQL-indsprøjtning strenge, udløbne tokens og misdannede API-nyttelaster, så sikkerhedstest huller dukker tidligt op.
- Udvid til ikke-funktionelle kontroller. A belastningstest ved det understøttede brugerantal er positivt, mens en stresstest ud over denne grænse er det matchende negative tilfælde.
- Vælg hvor hver sag kører. Hold negative tilfælde ude af røg- og sundhedstest, som er hurtige positive porte, og kører dem i funktionelle og regressionstest cyklusser.
En hævning i hæveautomaten viser parringen. Det positive tilfælde indtaster en korrekt pinkode og et gyldigt beløb, så kontanter og en kvittering følger. Det negative tilfælde indtaster en forkert pinkode og forventer en afvisningsbesked og derefter en kortblokering.
De bedste øvelser til at holde balancen i orden
- Skriv mindst to cases pr. krav, et positivt og et negativt, før udviklingen starter.
- Prioritér negative sager efter effekt, så injektions- og betalingsfejl kommer før kosmetiske inputfejl.
- Angiv selve fejlmeddelelsen, ikke kun at handlingen mislykkedes, for vage meddelelser er også defekter.
- Giv plads til udforskende testningog loggfør fund via din proces til håndtering af fejl.
⚠️ Advarsel: Kør aldrig negative sager mod et live produktionsmiljø. De eksisterer for at fremtvinge fejl, og et bevidst nedbrud påvirker rigtige brugere og rigtige data.
