what is test scenario
Denne vejledning forklarer, hvad der er testscenarie sammen med vigtighed, implementering, eksempler og skabeloner til testscenario:
Enhver softwarefunktionalitet / funktion, der kan testes, siges at være et testscenario. Slutbrugerperspektivet overvejes, når man skriver eventuelle testscenarier.
Denne vejledning hjælper dig med at besvare spørgsmålene: hvorfor testscenarier kræves, hvornår testscenarier skrives, og hvordan man skriver testscenarier.
Hvad du vil lære:
Hvad er et testscenario?
Overvej en hypotetisk situation: Der er et stort hav. Du er nødt til at rejse over havet fra den ene strand til den anden. For eksempel, fra Mumbai, India Seashore til Colombo, Srilanka seashore.
Den rejsemåde, du kan vælge, er:
(i) Airways: Tag et fly til Colombo
(ii) vandveje:Foretrækker et skib at rejse til Colombo
(iii) Jernbaner:Tag et tog til Srilanka
Nu til testscenarierne: At rejse fra Mumbai-kysten til Colombo-kysten er en funktion, der skal testes.
Testscenarierne inkluderer:
- Rejser med Airways,
- Rejser ad vandveje eller
- Rejser med jernbaner.
Disse testscenarier vil have testtilfælde.
Testcases, der kan skrives til ovenstående testscenarier, inkluderer:
Testscenarie: Rejser med Airways
Testcases kan omfatte scenarier som:
- Flyvningen foregår som planlagt.
- Flyvningen er ikke i henhold til det planlagte tidspunkt.
- Der er opstået en nødsituation (kraftig regn og storm).
På samme måde kan der skrives et separat sæt testsager til andre resterende scenarier.
Lad os nu komme til de teknologiske testscenarier.
Alt, hvad der kan testes, er et testscenario. Således kan vi fastslå, at enhver softwarefunktionalitet, der er under test, og som kan opdeles i flere mindre funktioner og kan betegnes som 'Test Scenario'.
Før du leverer et produkt til klienten, skal produktets kvalitet vurderes og evalueres. Testscenarie hjælper med at vurdere den funktionelle kvalitet af en softwareapplikation, der er i overensstemmelse med dens forretningskrav.
Testerscenario er en proces, hvor testeren tester softwareapplikation fra et slutbrugerperspektiv. Ydelsen og kvaliteten af softwareapplikationen vurderes grundigt inden implementering i produktionsmiljøet.
Betydningen af testscenario
- Ét testscenario kan have flere 'testtilfælde'. Det kan ses som et stort panoramabillede, og testcases er de små dele, der er vigtige for at fuldende panoramaet.
- Det er en enkeltlinjeerklæring, og testtilfælde består af trinvis beskrivelse for at fuldføre formålet med testscenarioerklæringen.
- Eksempel:
Testscenarie: Foretag betalingen for taxitjenesten.
Dette vil have flere testsager som anført nedenfor:
(jeg) Betalingsmetode, der skal bruges: PayPal, Paytm, Kredit- / betalingskort.
(ii) Betalingengjort er vellykket.
(iii) Betaling er mislykket.
(iv) Betalingenprocessen afbrudt imellem.
(v) Kan ikke få adgang til betalingsmetoder.
(vi) Ansøgningenbryder sammen imellem.
- Testscenarier hjælper således med at evaluere softwareapplikationen efter de virkelige situationer.
- Testscenarier, når de er bestemt, hjælp til at fordele omfanget af test.
- Denne fordeling betegnes som prioritering, som hjælper med at bestemme de vigtige funktioner i softwareapplikationen.
- Prioriteret test af funktionaliteterne hjælper i vid udstrækning med en vellykket implementering af softwareapplikationen.
- Da testscenarierne prioriteres, kan de vigtigste funktionaliteter let identificeres og testes på prioritet. Dette sikrer, at størstedelen af de afgørende funktioner fungerer fint, og mangler relateret til det behørigt fanges og afhjælpes.
- Testscenarier bestemmer forretningsprocesflowet for softwaren, og det er derfor muligt at afslutte-til-slut-test af applikationen.
Forskellen mellem testscenarie og testsag
Testscenarie | Test tilfælde |
---|---|
Kort dokumentation krævet. | Detaljeret dokumentation er påkrævet. |
Testscenarie er et koncept. | Testcases er løsningerne til at kontrollere dette koncept. |
Testscenarie er en funktionalitet på højt niveau. | Testcases er en detaljeret procedure for at teste funktionaliteten på højt niveau. |
Testscenarier stammer fra krav / brugerhistorier. | Testcases stammer fra testscenarier. |
Testscenarie er 'Hvilken funktionalitet skal testes' | Testtilfælde er 'Sådan testes funktionaliteten'. |
Testscenarier har flere testsager. | Test tilfælde kan eller måske ikke være knyttet til flere test scenarier. |
Enkelt testscenarier kan aldrig gentages. | En enkelt testtilfælde kan bruges flere gange i forskellige scenarier. |
Brainstorming-sessioner er nødvendige for at afslutte et testscenario. | Detaljeret teknisk viden om softwareapplikationen er påkrævet |
Tidsbesparelse som minutoplysninger er ikke påkrævet. | Tidskrævende, da hvert minuts detaljer skal tages hånd om. |
Vedligeholdelsesomkostningerne er lave, da de krævede ressourcer er lave. | Vedligeholdelsesomkostningerne er høje, da de krævede ressourcer er høje |
Hvorfor er testscenarier uundværlige?
Testscenarier stammer fra krav eller brugerhistorier.
- Tag eksemplet på et testscenarie for taxa-reservation.
- Scenarierne kunne være som taxa-bookingsmuligheder, betalingsmetoder, GPS-sporing, kørekort vist korrekt eller ej, førerhus- og chaufføroplysninger vist korrekt eller ej osv. Alle er anført i testscenarioskabelonen.
- Antag nu, at testscenarie er at kontrollere, om placeringstjenesterne er slået til, hvis de ikke er slået til, skal du vise meddelelsen 'Tænd placeringstjenester'. Dette scenario savnes og er ikke angivet i testscenarioskabelonen.
- Scenarie 'Lokationstjeneste' giver anledning til andre testscenarier relateret til det. Disse kan være:
- Placeringstjeneste nedtonet.
- Lokationstjenesten er slået til, men intet internet.
- Begrænsninger for placeringstjenester.
- Den forkerte placering vises.
- Mangler et enkelt scenarie kan betyde at gå glip af mange andre afgørende scenarier eller testsager . Dette kan have en stor dårlig indflydelse under implementering af softwareapplikationen. Dette resulterer i et stort tab af ressourcer (deadlines).
- Testscenarier hjælper i høj grad i undgå udtømmende test . Det sikrer, at alle de afgørende og forventede forretningsstrømme bliver testet, hvilket yderligere hjælper i slutningen til slut-testen af applikationen.
- Disse er tidsbesparelser. Der kræves heller ikke en meget detaljeret beskrivelse i henhold til testsagerne. En one-liner beskrivelse er specificeret om, hvad der skal testes.
- Testscenarier er skrevet efter brainstorming sessioner af holdmedlemmerne. Derfor er sandsynligheden for at gå glip af ethvert scenario (afgørende eller mindre) minimal. Dette gøres under hensyntagen til de tekniske forhold og også forretningsstrømmen i softwareapplikationen.
- Desuden kan testscenarierne godkendes enten af forretningsanalytiker eller klient eller begge, der har eksplicit kendskab til den applikation, der testes.
Testscenarier er således en uundværlig del af SDLC.
Implementering af testscenarier
Lad os se implementeringen af testscenarier, eller hvordan man skriver testscenarier-
- Epics / forretningskrav dannes.
- Eksempel på Epic : Opret en Gmail-konto. Epic kan være det vigtigste træk ved en applikation eller et forretningskrav.
- Epics er opdelt i mindre brugerhistorier på tværs af sprints.
- Brugerhistorier stammer fra Epics. Disse brugerhistorier skal baseres og godkendes af interessenter.
- Testscenarier stammer fra brugerhistorier eller BRS (Business Requirement Document), SRS (System Requirement Specification Document) eller FRS (Functional Requirement Document), som er færdigbehandlet og baseline.
- Testere skriver testscenarierne.
- Disse testscenarier er godkendt af Team Lead, Business Analyst eller Project Manager afhængigt af organisationen.
- Hvert testscenarie skal være bundet til mindst en brugerhistorie.
- Positive såvel som negative testscenarier skal identificeres.
- Brugerhistorier består af Acceptkriterier som :
- Acceptkriterier er en liste over betingelser eller hensigtstilstand for kundens krav. Kundens forventninger og også misforståelserne overvejes, når man skriver acceptkriterierne.
- Disse er unikke for en brugerhistorie, og hver brugerhistorie skal have mindst et acceptkriterium, der skal kunne testes uafhængigt af hinanden.
- Acceptkriterier hjælper med at bestemme, hvilke funktioner der er inden for omfanget, og hvilke der er uden for anvendelsesområdet for et projekt. Disse kriterier skal omfatte funktionelle såvel som ikke-funktionelle funktioner.
- Forretningsanalytikere skriver acceptkriterierne, og produktejeren godkender dem.
- Eller i nogle tilfælde kan produktejeren selv skrive kriterierne.
- Testscenarier kan opnås fra acceptkriterierne.
Eksempler på testscenarier
# 1) Testscenarier til Kindle App
Kindle er den app, der gør det muligt for sine e-læsere at søge efter e-bøger online, downloade og købe dem. Amazon Kindle giver e-boglæseren den virkelige oplevelse af at holde en bog i hånden og læse den. Selv vendingen af sider simuleres pænt i appen.
Lad os nu notere testscenarierne. ( Bemærk: Begrænsede scenarier er angivet nedenfor for at få en generel idé til skrivning af testscenariet. Der kan være flere testsager, der stammer fra det).
Testscenarier # | Test scenarier |
---|---|
7 | Bekræft downloadfunktionalitet fungerer korrekt. |
1 | Kontroller, om Kindle App starter korrekt. |
to | Bekræft, at skærmopløsningen justeres efter forskellige enheder efter appstart. |
3 | Bekræft, at den viste tekst er læsbar. |
4 | Kontroller, at zoom ind og zoom ud fungerer. |
5 | Kontroller, at kompatible filer, der er importeret i Kindle-appen, kan læses. |
6 | Bekræft lagringskapacitet i Kindle App. |
8 | Bekræft, at side-sving-simulering fungerer korrekt |
9 | Kontroller kompatibiliteten med eBook-formater med Kindle-appen. |
10 | Bekræft skrifttyper, der understøttes af Kindle-appen. |
elleve | Bekræft batteriets levetid, der bruges af Kindle-appen. |
12 | Bekræft ydeevne for Kindle afhængigt af netværksforbindelse (Wi-Fi, 3G eller 4G). |
Flere testsager kan udledes fra hver testscenarie, der er angivet ovenfor.
# 2) Acceptkriterier for Google Docs
'Google docs' er en webbaseret applikation til at oprette, redigere og dele orddokumenter, regneark, dias og formularer. Du kan få adgang til alle filer online ved hjælp af en webbrowser med en internetforbindelse.
De oprettede dokumenter kan deles som en webside eller et udskrivningsklar dokument. Brugeren kan sætte begrænsninger for, hvem der kan se og redigere dokumenterne. Et enkelt dokument kan deles og bearbejdes af forskellige personer fra forskellige geografiske placeringer i samarbejde.
Begrænsede testscenarier er nævnt nedenfor for generel forståelse. Dybdegående testscenarier for Google-dokumenter kan være et separat emne helt.
Godkendelseskriterier # | Godkendelseskriterier |
---|---|
7 | Flere brugere kan arbejde på et enkelt dokument. |
1 | Word, Sheets eller Forms kan åbnes uden fejl. |
to | Skabeloner er tilgængelige til dokumenter, ark og dias. |
3 | Tilgængelige skabeloner er tilgængelige for brugere. |
4 | Den anvendte skabelon kan redigeres (f.eks. Skrifttyper, skriftstørrelse, tilføjelse af tekst, sletning af tekst, indsættelse af dias). |
5 | Hvis internetforbindelse ikke er tilgængelig midlertidigt, kan filen gemmes lokalt og uploades efter tilgængelighed af internetforbindelse. |
6 | Ændringer foretaget af flere brugere overskrives ikke. |
8 | Det udførte arbejde gemmes, hvis internetforbindelsen går tabt under upload af en fil. |
9 | Dele begrænsninger anvendes korrekt. |
10 | Visningsbegrænsning brugere kan ikke redigere dokumenterne. |
elleve | Dokumenter kan offentliggøres på internettet for offentligheden. |
12 | Ændringer udført på dokumenter gemmes med tidsstempel og forfatteroplysninger. |
Antallet af testscenarier vil være flere og meget enorme for Google Docs. I sådanne tilfælde er generelt kun acceptskriterierne indstillet og godkendt af interessenter, og teammedlemmerne arbejder på disse acceptkriterier. Skrivning af testsager til eller rettere testscenarier kan være den udtømmende opgave for store applikationer.
hvordan man får vist xml-filer i word
Disse acceptkriterier spiller en vigtig rolle i iterativ procesplanlægning og bør aldrig overses. Ved at definere dem på forhånd og på forhånd undgår du overraskelser eller stød i slutningen af sprints eller frigivelser
Givet en forudsætning.
Hvornår at gøre en handling.
Derefter det forventede resultat.
Formaterne for givet, hvornår og derefter er nyttige til angivelse af acceptkriterier.
Eksempel på testscenariskabelon
Brug historie-ID # | Test Scenario ID # | Version nr. | Test scenarier | # Antal testtilfælde | Betydning |
---|---|---|---|---|---|
USID12.1 | TSID12.1.1 | Kin12.4 | Kontroller, om Kindle App starter korrekt. | 4 | Høj |
USID12.1 | TSID12.1.2 | Kin12.4 | Bekræft lagringskapacitet i Kindle App. | 3 | Medium |
Konklusion
I enhver softwaretest er livscyklus forståelse og fastlæggelse af testscenarier et meget vigtigt element. Kvaliteten af softwaren kan forbedres ved at have et godt fundament for testscenarier. Ofte kan brugen af testsager og testscenarier blive udskiftet.
Tommelfingerreglen er dog, at testscenariet bruges til at skrive flere testcases, eller vi kan sige, at testcases stammer fra testscenarier. Veldefinerede testscenarier sikrer software af god kvalitet.
Anbefalet læsning
- Eksempel på software-testplanskabelon med format og indhold
- Eksempel på testcase-skabelon med eksempler på testcase (Download)
- Eksempelskabelon til acceptrapport med eksempler
- Skabeloner i C ++ med eksempler
- Python DateTime-tutorial med eksempler
- Klip kommando i Unix med eksempler
- Testscenarie mod testtilfælde: Hvad er forskellen mellem disse?
- Blazemeter-plugin og Jmeter-skabelon