Introduktion til adhoc-test
Adhoc-test er tilfældig eller uformel test, som kan have evnen til at bryde systemet. Dette er normalt ikke planlagt, og der er ingen testteknikker som at designe testsager, hvilket skaber involverede testsager. Det kan gøres på enhver del af applikationen. Hovedmålet her er at finde problemer eller defekter i systemet ved tilfældigt at kontrollere dele af koden. Det følger teknikken med at gætte fejl. Det kan gøres af folk, der har arbejdet med applikationen før og let kan finde ud af fejl eller problemer ved at udføre denne type test.
Hvordan udføres adhoc-test?
Adhoc-test udføres på flere måder. Dette kan gøres når som helst. Dette kan være i begyndelsen, midten eller mod slutningen af projekttesten. Der er tre måder, hvorpå Adhoc-test udføres. De er som nedenfor:
- Buddy Testing
- Par test
- Monkey Testing
Lad os se nærmere på disse
1. Buddy Testing
Som navnet antyder, kan det siges, at to venner, en tester og en udvikler vil arbejde sammen. De vil blive valgt til at arbejde på et bestemt modul. Så snart udvikleren afslutter enhedstesten, og testeren har nogle tilfælde i tankerne, kan de begge arbejde på dette modul. Ved at udføre denne type test kan du sikre dig, at den nye fremtid eller funktionalitet kontrolleres gennem et bredere aspekt for både udvikleren og testeren. Udvikleren kan forstå de forskellige scenarier, som koden går igennem og tænke ud fra det perspektiv.
Mens testeren kan få udviklerens perspektiv på det eksisterende design, og det vil hjælpe med at undgå de ugyldige scenarier i testsager. Dette vil hjælpe med at undgå ugyldige fejl. Begge parter kan tænke som hinanden og få et klarere syn på applikationen under udvikling og testning. Det hjælper også med at udvikle bedre testsager og udviklere til at få et bedre design. Dette finder normalt sted, når enhedstestingen er afsluttet.
2. Par test
I denne test arbejder to testere sammen om et modul. De har en fælles opsætning udført til testformål. Ved at implementere denne form for testning sørges det for, at begge testere finder måder at registrere et større antal fejl i den indbyggede applikation. De deler testarbejdet og udarbejder også nødvendig dokumentation af alle de observationer, de har foretaget sammen. Et maksimalt antal scenarier kan findes ved hjælp af denne type test.
3. Monkey Testing
Denne test udføres på enhedsforsøgsniveauet. Den person, der tester modulet, tester applikationen på en helt tilfældig måde. Dette gøres for at kontrollere, om systemet tåler enhver nedbrud på ethvert tidspunkt. Ved at udføre denne type test kan der findes mange mangler, som kunne have været tilbage tidligere. Denne test kan også ødelægge systemet, hvormed vi kan forstå ydelsesproblemerne, hvis nogen, er vedvarende. Der ville ikke være nogen testsager her, ligesom for andre.
Adhoc-testteknikker
Den grundlæggende idé bag valget af Adhoc-test er, at testere, der arbejder uden testdesign eller uden at der oprettes testsager. Det sørger for, at den udførte test er afsluttet, og at vejen er nyttig til at finde effektivitet i den test, der udføres. Den vigtigste måde at teste ethvert program i denne type test-id er så tilfældigt som muligt. Du kan hoppe fra et modul til et andet og udføre en aktivitet. Systemet må ikke gå i stykker. Hovedformålet med dette system er at finde defekter, der kan gå glip af under normal test.
Denne teknik giver også et indblik i hele applikationen, og gætningen kan udføres af testeren, der har ekspertviden om systemet. Du kan også involvere en anden testet eller endda invitere udvikleren, så vi ikke har nogen form for scenarie, der er gået glip af under test. Når to mennesker sidder sammen, er brainstorming ganske fordelagtigt. Vi kan finde mangler, som tidligere er undgået. Ved at bruge denne teknik er chancerne mere for at finde manglerne mere.
Adhoc-testværktøjer
Der er ingen specifikke værktøjer, der bruges i ad hoc-test. Som et resultat kan alle værktøjer, der allerede bruges til at teste applikationen, bruges efter behov. For at kontrollere et bestemt modul bruges Selenium. Selen kan bruges til at teste moduler implementeret efter det forrige modul. Dette kan hjælpe med at fremskynde processen og få nøjagtige detaljer. Tilsvarende kan andre værktøjer som QTP, Agurk bruges til enhver type Adhoc-test, når det er nødvendigt.
Fordele ved adhoc-test
- Den største fordel ved denne type test er, at testeren ikke behøver at følge den traditionelle testproces. De kan teste applikationen på enhver måde, de vil. Dette hjælper dem med at lære systemet bedre at kende.
- Når der ikke er tid til korrekt test, kan Adhoc-test være en frelser og hjælpe med at få fejl, der kan overgå til produktion.
- Det sparer testeren tid, da der ikke er behov for nogen dokumentation. Her fokuseres det kun på at teste og forstå arkitekturen bedre og finde eventuelle problemer, hvis de findes.
Ulemper ved adhoc-test
- Det er ikke muligt at spore scenarierne, der testes, da der ikke er nogen involveret dokumentation.
- Testtilfældene kan være gentagne, hvilket kan føre til spild af tid.
- Effektiviteten af test her afhænger fuldstændigt af testeren.
Konklusion
Adhoc-test er en effektiv måde at finde problemer på runtime. Adhoc-test kan udføres af en erfaren tester, der kender til det eksisterende system. Der er ikke behov for dokumentation, og det kan gøres med udviklere ved siden af. Forskellige perspektiver på testning kan give anledning til problemer, der ikke når produktion, og som et resultat hjælpe med at spare en masse penge. Det viser sig at være omkostningseffektivt og produktivt.
Anbefalet artikel
Dette har været en guide til adhoc-test. Her diskuterer vi Introduktion til Adhoc Testing og dens teknikker sammen med værktøjer. Du kan også gennemgå vores andre foreslåede artikler for at lære mere_- Typer af softwaretestning
- Funktionelle testværktøjer
- Sikkerhedstest
- Statlig overgangstest
- Typer og håndteringsfejl i JavaScript