Hvorfor har programmører brug for test?
De næste par niveauer vil blive afsat til test på den måde, som programmører har brug for det . Men lad os først finde ud af, hvad test er, og hvorfor det er nødvendigt.
Med hensyn til software kan vi sige, at opgaven med at teste er at kontrollere, at programmet:
- gør hvad hun skal
- gør ikke det hun ikke burde gøre
Det andet punkt er i øvrigt ikke mindre vigtigt end det første, men mere om det senere.
Lad os starte med det første punkt. Hvad betyder "programmet gør, hvad det skal"?
Først skal nogen lave en liste over alle use cases for programmet. For det andet skal de beskrive, hvordan programmet skal fungere, hvordan brugeren skal opføre sig, og hvilke resultater der forventes. Du kan ikke fortsætte videre.
Så snart vi skrev "hvordan brugeren skulle opføre sig", faldt hele ideen om at skrive god dokumentation fra hinanden. Mennesker er ikke maskiner, desuden opfører folk sig meget ofte med software, som de vil . Ingen begynder deres bekendtskab med teknologi ved at studere instruktionerne. Det er et faktum.
Derfor får vi et nyt faktum: Det særlige ved softwaren er, at den har mange forskellige arbejdsscenarier. Nogle af dem er indlysende, andre kan dokumenteres, andre kan antages, andre kan gættes, og de andre 50% vil ikke engang falde dig ind.
Fra en programmørs synspunkt er de fleste fejl slet ikke fejl. En fejl er, når et program ikke fungerer som det skal eller som forventet. Og der er mange situationer, hvor det ikke er klart, hvordan programmet skal fungere, eller scenarier, der modsiger hinanden ...
Der er et uendeligt antal scenarier, og der vil altid være tilfælde i produktet, hvor programmet ikke opfører sig som forventet (programmøren skrev koden til kun et par dusin scenarier). Derfor kan det argumenteres, at der altid er fejl i ethvert program , og ethvert produkt kan forbedres i det uendelige .
Herefter kommer det hele til formål. Først retter programmøren de største fejl, derefter de mindre fejl og så videre. Og endelig kommer der et trin, hvor ejeren af produktet mener, at det ikke er økonomisk muligt at fortsætte arbejdet med det.
Men tilbage til de fejl, som alle genkender som fejl: programmet gør åbenbart noget forkert, faldt, brød noget osv. Sådanne fejl kan betinget opdeles i 3 kategorier: store, mellemstore og små.
Og meget ofte sker det, at en programmør arbejder på at rette mellemstore eller endda små fejl, selvom der stadig er mange mere alvorlige problemer i projektet. Han fandt dem bare ikke , så han arbejder på de største, han kender til.
Derfor bør der i ethvert projekt være testere. Disse mennesker lærer specifikt at se på produktet fra forskellige vinkler. Så du kan se flere scenarier af programmet. Deres opgave er at finde fejl og skrive dem ned (for ikke at finde den samme fejl flere gange).
Test er en proces, der har til formål at finde fejl. Disse fejl skal findes, beskrives og prioriteres. Først efter prioritering af fejl kan vi tale om en effektiv softwareforbedringsproces.
Husk, at det første skridt til at løse et problem er at erkende, at der er et problem . Du kan ikke rette en fejl, du ikke kender til.
Test automatisering
Jeg tror, vi alle var enige om, at test er vigtigt, så lad os se på test som programmører. Hvordan ser programmører på test? Programmører automatiserer andre menneskers arbejde. Det sidste erhverv, der forsvinder, bliver programmeringsfaget.
Vi automatiserer alle processer, vi støder på. Så test skal automatiseres. Og hvordan automatiserer man søgningen efter fejl? Kort svar: nej. Men her kommer igen det faktum, at vi er programmører, os til hjælp.
Softwareudviklingsprocessen består af konstante ændringer af den. bare i færd med konstant at foretage ændringer, bryder programmører meget ofte noget, der fungerede fint indtil for nylig.
Og testere er i stedet for at lede efter nye fejl tvunget til hele tiden at tjekke, om vi har brudt noget, der har fungeret godt i lang tid. Den såkaldte regressionstest. Det er denne type test, der kan og bør automatiseres.
Her kan al software opdeles i to dele:
- programmet interagerer med personen
- programmet interagerer med et andet program
Den første mulighed er sværere at automatisere, den kræver specielle automator testere, de kaldes også QA Automation eller Software Test Engineer.
Men den anden mulighed kan og bør automatiseres uafhængigt. Hvis du har et stykke software, der:
- fungerer godt
- allerede testet
- implementeret som et separat modul eller logisk blok
- planlægger ikke at ændre
- andre moduler eller programmer afhænger af det
- funktionssvigt er dyrt
Jeg anbefaler, at du tager dig tid til at skrive test til den, der fanger nøgleaspekter af dens nuværende funktionalitet. Det ville være rimeligt at afsætte 5 % af din arbejdstid til dette eller 1 dag om måneden.
Ingen grund til at skrive prøver af hensyn til testene.
Ingen vil støtte dine tests. Ikke andre programmører, ikke dig selv. Ingen gør det. 99% af alle skriftlige prøver er opgivet og/eller deaktiveret. Hvis du ikke kan skrive prøver - så lad være med at skrive. Skriv kun, hvis du absolut ikke kan undvære dem.
Typer af test
Hver programmør, hvis han ikke har gennemgået en særlig uddannelse, vil med sine egne ord kunne fortælle, hvad test er: at kontrollere, om programmet gør, hvad det skal. Men fagfolk inden for dette felt skelner mellem hele områder (typer) af test.
Al test drejer sig egentlig om pålideligheden og tilgængeligheden af software, men for bedre at forstå testretningen, lad os se på et par eksempler.
Lad os sige, at du tester en typisk netbutik. Derefter kan områderne for test opdeles i følgende typer: præstationstest, funktionstest, integrationstest og enhedstest.
Hvis webstedsejeren beslutter sig for at lancere en seriøs reklamekampagne, vil mange brugere komme til webstedet på samme tid. Det kan godt være, at siden ikke falder, men nogle af dens sektioner kan være langsomme eller endda holde op med at fungere.
For at forhindre dette i at ske, skal du identificere sådanne problemer på forhånd og tage skridt til at eliminere dem. Dette gøres ved hjælp af belastningstest , eller det kaldes også præstationstest.
Du ønsker måske også at teste, hvordan din backend API fungerer og teste hver funktion af den: registrering, login, tilføjelse til indkøbskurv, betalingsbehandling, databaseskrivning osv. Alt skal fungere i henhold til TOR. I dette tilfælde skal du udføre funktionstest .
Din netbutik er højst sandsynligt integreret med tredjepartstjenester: afsendelse af breve og SMS, betalingssystemer, online supportchat, indsamling af feedback fra brugere, reklamesystemer osv. For at sikre dig, at alt dette fungerer efter hensigten, skal du gennemgå en integrationstest .
Endelig er komplekse produkter ofte opdelt i selvstændige moduler. Fra sådanne moduler kan du samle det endelige produkt, som fra en konstruktør. Hvis du udvikler et sådant modul eller interagerer med sådanne moduler, skal du lave enhedstest .
Sammenfattende kan vi sige, at funktionel test er nødvendig for at teste hver enkelt funktion på webstedet. Integration - til test af samspillet mellem store moduler og systemer i dit produkt. Modulær - for at teste et separat modul, ja, præstationstest - for at kontrollere driften af dit websted under belastning.
Der kan være endnu flere typer test: Jo mere komplekst produktet er, jo flere aspekter af dets udvikling skal kontrolleres.