Som softwaretestere og automatiseringsingeniører tænker vi ofte på den forventede sti: den sti, brugeren sandsynligvis vil følge, når vedkommende bruger vores applikation. Når vi skriver vores automatiserede UI-tests, vil vi sikre os, at vi automatiserer disse forventede stier, og når vi skriver API-automatisering, vil vi verificere, at hvert API-slutpunkt returnerer et “200 OK” eller et lignende vellykket svar.
Men det er vigtigt at tænke på negativ testning i både vores manuelle og automatiserede tests. Her er nogle få grunde til hvorfor.
Vores automatiserede tests består måske af de forkerte grunde
Da jeg først begyndte at skrive automatiserede UI-tests i JavaScript, forstod jeg ikke begrebet løfte. Jeg gik bare ud fra, at når jeg sendte en anmodning om at finde et element, ville den ikke returnere elementet, før det faktisk var blevet fundet. Jeg blev så begejstret, da mine tests begyndte at vende tilbage med det grønne resultat “Bestået”, indtil en kollega foreslog, at jeg skulle prøve at få testen til at fejle ved at lave en assertion på en anden værdi. Den bestod igen, fordi den faktisk validerede det eksisterende løfte, som altid returnerede “Sandt”. Det lærte mig en værdifuld lektie: Gå aldrig ud fra, at dine automatiserede tests fungerer korrekt, blot fordi de består. Sørg for at køre nogle scenarier, hvor dine tests bør fejle, og sørg for, at de faktisk gør det. På den måde kan du være sikker på, at du virkelig tester det, du tror, du tester.
Have an account? Log In
Negativ testning kan afsløre fejl, der ikke håndteres korrekt, og som kan påvirke en bruger
Ved API-testning bør enhver klientrelateret fejl resultere i et svar på 400-niveau i stedet for en serverfejl på 500-niveau. Hvis du udfører negativ testning og opdager, at et 403-svar nu kommer tilbage som et 500-svar, kan det betyde, at koden ikke længere håndterer dette brugsscenarie korrekt. Et 500-svar fra serveren kan forhindre brugeren i at få de relevante oplysninger, vedkommende har brug for til at rette sin fejl, eller endnu værre, det kan få applikationen til at gå ned.
Negativ testning kan finde sikkerhedshuller
Lige så vigtigt som det er at sikre, at en bruger kan logge ind i en applikation, er det at sikre, at en bruger ikke kan logge ind i en applikation, når vedkommende ikke bør kunne det. Hvis du kun kører en logintest med et gyldigt brugernavn og en gyldig adgangskode, overser du dette afgørende område! Jeg har set en situation, hvor en bruger kunne logge ind med en hvilken som helst adgangskode, en situation, hvor en bruger kunne logge ind med en tom adgangskode, og en situation, hvor en bruger kunne logge ind med et forkert brugernavn og en forkert adgangskode.
Det er også afgørende at verificere, at bestemte brugere ikke har adgang til dele af en applikation. Det betyder ikke meget at have en grundigt testet og funktionel administratorside, hvis det viser sig, at enhver tilfældig bruger kan få adgang til den.
Negativ testning holder din database ren
Som jeg nævnte i kapitel 12, vil gode og gyldige data i din database hjælpe med at holde din applikation sund. Data, der ikke lever op til forventningerne, kan få websider til at gå ned eller ikke indlæses, eller få oplysningerne til at blive vist forkert. Jo mere negativ testning du kan udføre af dine input, desto bedre kan du sikre, at du kun har gode data.
For hvert inputfelt, jeg er ansvarlig for at teste, vil jeg gerne vide præcis, hvilke tegn der er tilladt. Derefter kan jeg køre en hel række negative tests for at sikre, at indtastninger med de forbudte tegn afvises.
More Articles
Nogle gange vælger brugerne den negative sti
Det er så nemt, især med en ny funktion, der bliver fremskyndet for at overholde en deadline, at glemme at teste de brugerforløb, hvor brugerne klikker på knappen Annuller eller Slet. Men brugere gør dette hele tiden. Tænk bare på de gange, hvor du har overvejet at foretage et onlinekøb og derefter ombestemt dig og fjernet en vare fra din indkøbskurv. Forestil dig din frustration, hvis du ikke kunne fjerne noget fra din indkøbskurv, eller hvis en Annuller-knap ikke ryddede en formular, så du kunne begynde igen. Brugeroplevelsen på dette område er lige så afgørende som den forventede sti.
Softwaretest handler om at lede efter uventet adfærd, så vi finder den, før en bruger gør det. Når negativ testning kombineres med testning af den forventede sti, kan vi sikre, at vores brugere ikke får ubehagelige overraskelser.
Hvis du ønsker at optimere dine testprocesser yderligere, kan du overveje at integrere et førsteklasses databaseadministrationsværktøj til at håndtere dine komplekse databehov.
Den komplette bog om softwaretest
Da jeg opdagede min kærlighed til softwaretest i 2009, ønskede jeg at lære alt, hvad jeg kunne, om softwaretest, men jeg fandt meget få bøger, der kunne lære mig det. Jeg endte med at lære gennem forsøg og fejl, ved at læse blogindlæg og tale med mine kolleger. I dag findes der nogle fremragende bøger om specifikke områder inden for softwaretest, såsom eksplorativ testning, agil testning og testautomatisering, men jeg kender ikke til nogen bog, der har til formål at være en komplet reference om testning.
Jeg skrev Den komplette softwaretester, fordi jeg ønskede at give både nye og erfarne testere de idéer og værktøjer, de har brug for, for at være så effektive som muligt. Hvis du vil have hurtige QA-tips og flere boganbefalinger, kan du abonnere på The QA Lead-nyhedsbrevet.
Relateret læsning: HVAD ER ZEPHYR SCALE?
Relateret liste over værktøjer:
Se også:
