Introduktion til testscenarie
Testscenario er en kombination af to ord, dvs. test og scenarie. Testen repræsenterer en handling med verifikation eller validering, og scenariet repræsenterer brugerens rejse. Enhver testbar funktionalitet kaldes et testscenarie. Testscenario kan beskrives som verifikation eller validering af brugerens rejse. Det vil være i form af dokumenter, der indeholder alle testsager, der er skrevet i detaljer for at teste applikationernes ende-til-ende-funktionalitet. Det er en af kategorierne på højt niveau af krav, der kan testes. Det er også kendt som en testmulighed eller en testbetingelse.
Hvorfor oprette testscenarier?
Flere testsager kan dækkes af et testscenarie. Forholdet mellem testscenarier og testsager er derfor en til mange. Men hvert scenarie skal tages hånd om af testeren, mens det oprettes. Testere opretter det for at teste applikationen set fra en slutbruger. Testere søger fra alle udviklere, interessenter og kunder om at forberede dem, der er kritiske.
Årsagen til at oprette dem er som følger:
- Komplet og korrekt testdækning sikres ved at skabe perfekte testscenarier.
- Oprettelse af dem bliver kritisk for at studere et programs ende-til-ende-funktionaliteter.
- De vigtigste og kritiske ende-til-ende-transaktioner eller realtidsanvendelse af applikationer kan bestemmes godt med den rette hjælp af dem.
- De kan bruges som et værktøj til hurtig bestemmelse af testning af arbejdsstyrke, hvilket yderligere hjælper klienter eller organisationer til oprettelse af forslag og organisering af testning af arbejdsstyrke effektivt og effektivt.
- For at sikre en grundig og korrekt test af applikationer, godkendes den på forskellige niveauer, herunder kunder, forretningsanalytikere, udviklere osv.
Tilsvarende kan der være visse omstændigheder, hvor skabelsen af den bør undgås.
- Det oprettes muligvis ikke i projekter, der følger agile metodologier såsom Scrum osv.
- Når de applikationer, der skal testes, er ustabile eller for komplicerede, eller når projektet er i en kritisk tidstilstand, kan det undgås.
- Oprettelse af det kan undgås til regressionstest eller for en ny fejl, fordi i vedligeholdelsesprojekter tunge dokumenter af dem ville ske i forvejen i de tidligere testcykler.
Hvordan kan testscenarier skrives?
Følgende trin kan udføres af en tester til oprettelse af testscenarier:
- Trin 1: Dokumentet med krav som f.eks. Forretningskravspecifikation (BRS), funktionskravspecifikation (FRS) og systemkravspecifikation (SRS) for den applikation, der skal testes, skal læses grundigt og omhyggeligt. Manualer, bøger, brugssager osv. For den applikation, der testes, kan henvises til det samme.
- Trin 2: Alle de mulige mål og brugerhandlinger skal beregnes korrekt for ethvert krav. Alle tekniske egenskaber ved ethvert krav skal også bestemmes.
- Trin 3: Alle de mulige årsager til systemhack og brugerevaluering skal udføres fra en hakers perspektiv. Brugerevaluering kan udføres ved at finde alle mulighederne for brugerdrift af applikationerne.
- Trin 4: Der skal laves en komplet liste over alle mulige testtilfælde til verifikation af alle funktionaliteterne i applikationen, når du har læst kravet og fuldstændigt analysen.
- Trin 5: Efter verifisering af alle dem, til verifikation af kravet og dets testscenarie, der matcher en sporbarhed, skal matrix oprettes.
- Trin 6: Alle de oprettede testscenarier gennemgås og evalueres af vejlederen. Det verificeres også yderligere af alle interessenter.
I henhold til projektproceduren skal hvert testscenarie tilpasses mindst en brugerhistorie eller -krav. Det er obligatorisk at verificere hvert testscenarie mod dets krav separat, før flere krav i et enkelt testscenario. Komplekse testscenarier med flere krav kan undgås for enkelhed. Prisen er direkte proportional med antallet af dem. Det tilrådes altid at køre kun valgt og krævet i henhold til kundens prioritet.
eksempler
Nedenfor er nogle eksempler på testscenario
Testscenario til Buykart-applikationer til online shopping
Testscenarier, der kan tages i betragtning til verificering af en online shopping-applikation Buykart, er som følger:
Testscenario 1: Loginfunktionskontrol
Testsager, der kan overvejes til oprettelsen, er:
- Applikationens adfærd, når du indtaster et gyldigt login-id og en gyldig adgangskode, kan kontrolleres.
- Applikationsadfærd, når du indtaster et gyldigt login-id og en ugyldig adgangskode, kan kontrolleres.
- Applikationsadfærd, når du indtaster et ugyldigt login-id og en gyldig adgangskode, kan kontrolleres.
- Applikationsadfærd, når du indtaster et ugyldigt login-id og en ugyldig adgangskode, kan kontrolleres.
- Applikationsadfærd, når du logger ind ved at indtaste login-id alene uden en adgangskode, kan kontrolleres.
- Applikationsadfærd, når du logger ind ved at indtaste adgangskode alene uden login-id, kan kontrolleres.
- Applikationsadfærd, når du logger på uden at indtaste både login-id og adgangskode, kan kontrolleres.
- Applikationsadfærd, når glemt adgangskode er valgt.
Testscenario 2: Søgning af funktionalitetssøgning
Testsager, der kan overvejes til oprettelsen, er:
- Ansøgningens adfærd, når der søges efter et gyldigt produkt.
- Ansøgningens adfærd, når der søges efter et ugyldigt produkt.
Testscenario 3: Kontrol af produktdetaljer
Testsager, der kan overvejes til oprettelsen, er:
- Programmets opførsel, når et produkt vælges.
- Opførsel af applikationen et produkt er på listen.
- Ansøgningens adfærd, når et produkt føjes til indkøbskurven.
- Ansøgningens adfærd, når indstillingen Køb nu er valgt.
- Ansøgningens adfærd, når der indtastes en ugyldig adresse.
- Ansøgningens adfærd, når der indtastes en gyldig adresse.
- Applikationens adfærd, når flere betalingsmuligheder kontrolleres.
Testscenario 4: Betalingsfunktionskontrol
Testsager, der kan overvejes til oprettelsen, er:
- Ansøgningens adfærd, når hver betalingsindstilling er valgt.
- Ansøgningens adfærd, når der vælges en gyldig betalingsmulighed.
- Ansøgningens adfærd, når der vælges en ugyldig betalingsmulighed.
- Ansøgningens adfærd, når en betaling er vellykket.
- Ansøgningens adfærd, når en betaling afvises.
Testscenario 5: Funktionskontrol af ordredetaljer
Testsager, der kan overvejes til oprettelsen, er:
- Programmets opførsel, når hver ordre vælges.
- Applikationens opførsel, når alternativet Returprodukt er valgt.
- Applikationens opførsel, når sporproduktindstilling er valgt.
- Applikationens opførsel, når indstillingen Gennemgå produkt er valgt.
Konklusion
Det fungerer som en korrekt guide til testerne og hjælper dem med at gøre testen mere effektiv og effektiv. Det hjælper med at reducere testkompleksitet og redundans. Hver test case er skrevet i detaljer for bedre forståelse. Det er meget tidsbesparende for testere.
Anbefalede artikler
Dette har været en guide til Hvad er testscenarie. Her diskuterer vi, hvordan man opretter testscenarier med forskellige eksempler. Du kan også se på de følgende artikler for at lære mere -
- Job usikkerhed stress
- Selvmotiveret og dedikeret
- Hvad er Agile Testing?
- Hvordan man skriver test sag?