what is test scenario
Denne veiledningen forklarer hva som er testscenario sammen med viktigheten, implementeringen, eksemplene og maler for testscenario:
Enhver programvarefunksjonalitet / funksjon som kan testes sies å være et testscenario. Sluttbrukerperspektivet vurderes når du skriver eventuelle testscenarier.
Denne opplæringen vil hjelpe deg med å svare på spørsmålene: hvorfor testscenarier kreves, når testscenarier skrives og hvordan du skriver testscenarier.
Hva du vil lære:
Hva er et testscenario?
Tenk på en hypotetisk situasjon: Det er et enormt hav. Du må reise over havet fra en strand til en annen. For eksempel, fra Mumbai, India Seashore til Colombo, Srilanka strand.
Reisemåten du kan velge er:
(i) Airways: Ta en flytur til Colombo
(ii) Vannveier:Foretrekker at et skip reiser til Colombo
(iii) Jernbaner:Ta tog til Srilanka
Nå for testscenariene: Å reise fra Mumbai-kysten til Colombo-kysten er en funksjonalitet som skal testes.
Testscenariene inkluderer:
- Reiser med Airways,
- Reiser med vannveier eller
- Å reise med jernbane.
Disse testscenariene vil ha testtilfeller.
Test tilfeller som kan skrives for de ovennevnte testscenariene inkluderer:
Test Scenario: Reiser med Airways
Testtilfeller kan omfatte scenarier som:
- Flyet er som planlagt.
- Flyet er ikke i henhold til planlagt tid.
- Det har oppstått en krisesituasjon (kraftig nedbør og storm).
På samme måte kan det skrives et eget sett med testtilfeller for andre gjenværende scenarier.
La oss nå komme til de teknologiske testscenariene.
Alt som kan testes er et testscenario. Dermed kan vi konstatere at enhver programvarefunksjonalitet som er under test og kan deles inn i flere mindre funksjonaliteter og kan betegnes som 'Test Scenario'.
hvilke programmer som kan åpne eps-filer
Før du leverer et produkt til klienten, må kvaliteten på produktet vurderes og evalueres. Testscenario hjelper til med å vurdere den funksjonelle kvaliteten til et program som er i samsvar med dets forretningskrav.
Testerscenario er en prosess der testeren tester programvare fra et sluttbrukerperspektiv. Programvarens ytelse og kvalitet blir grundig vurdert før implementering i produksjonsmiljøet.
Betydningen av testscenario
- Én testscenario kan ha flere 'testtilfeller'. Det kan figureres som et stort panoramabilde, og testtilfeller er de små delene som er viktige for å fullføre panoramaet.
- Det er en enkeltlinjesetning og testtilfeller består av trinnvis beskrivelse for å fullføre formålet med testscenarioerklæringen.
- Eksempel:
Test Scenario: Gjør betaling for drosjetjenesten benyttet.
Dette vil ha flere testsaker som angitt nedenfor:
(Jeg) Betalingsmåte som skal brukes: PayPal, Paytm, Kreditt- / Debetkort.
(ii) Betalingengjort er vellykket.
(iii) Betalingen er mislykket.
(iv) Betalingenprosessen avbrutt i mellom.
(v) Har ikke tilgang til betalingsmåter.
(vi) Søknadenbryter sammen i mellom.
- Testscenarier hjelper dermed med å evaluere programvaren i henhold til situasjonene i den virkelige verden.
- Test scenarier når de er bestemt, hjelp til å splitte omfanget av testing.
- Denne bifurkasjonen blir betegnet som prioritering som hjelper til med å bestemme viktige funksjoner i programvaren.
- Prioritert testing av funksjonalitetene, hjelper i stor grad til vellykket implementering av programvaren.
- Etter hvert som testscenariene blir prioritert, kan de viktigste funksjonene enkelt identifiseres og testes på prioritet. Dette sikrer at flertallet av de avgjørende funksjonene fungerer fint, og feil relatert til det blir behørig fanget opp og utbedret.
- Testscenarier bestemmer forretningsprosessflyten til programvaren, og dermed er end-to-end-testing av applikasjonen mulig.
Forskjellen mellom testscenario og testsak
Test Scenario | Test tilfeller |
---|---|
Kort dokumentasjon kreves. | Det kreves detaljert dokumentasjon. |
Testscenario er et konsept. | Test tilfeller er løsningene for å verifisere dette konseptet. |
Testscenario er en funksjonalitet på høyt nivå. | Testtilfeller er detaljert prosedyre for å teste funksjonalitet på høyt nivå. |
Testscenarier er hentet fra krav / brukerhistorier. | Testtilfeller er hentet fra testscenarier. |
Testscenario er 'Hvilken funksjonalitet skal testes' | Testtilfeller er 'Hvordan teste funksjonaliteten'. |
Testscenarier har flere testsaker. | Testtilfelle kan eller ikke være knyttet til flere testscenarier. |
Enkelte testscenarier kan aldri repeteres. | Én testtilfelle kan brukes flere ganger i forskjellige scenarier. |
Brainstorming er nødvendig for å fullføre et testscenario. | Det kreves detaljert teknisk kunnskap om programvaren |
Tidsbesparelse som detaljer er ikke nødvendig. | Tidkrevende ettersom hvert minutt detalj må tas vare på. |
Vedlikeholdskostnadene er lave ettersom ressursene som kreves er lave. | Vedlikeholdskostnadene er høye da ressursene som kreves er høye |
Hvorfor er testscenarier uunnværlige?
Testscenarier er hentet fra krav eller brukerhistorier.
- Ta eksemplet med et testscenario for bestilling av drosjer.
- Scenariene kan være som bestillingsalternativer for drosjer, betalingsmåter, GPS-sporing, veikart som vises riktig eller ikke, informasjon om førerhus og sjåfør vises riktig eller ikke, osv. Alt er oppført i testscenariomalen.
- Anta nå at testscenario er å sjekke om lokasjonstjenestene er slått på, hvis ikke slått på, vis meldingen 'Slå på lokasjonstjenester'. Dette scenariet er savnet og ikke oppført i malen for testscenarier.
- Scenarioet 'Lokasjonstjeneste' gir opphav til andre testscenarier knyttet til det. Disse kan være:
- Stedstjeneste nedtonet.
- Lokaliseringstjenesten er slått på, men ikke internett.
- Begrensninger for lokasjonstjenester.
- Feil plassering vises.
- Mangler et enkelt scenario kan bety at du går glipp av mange andre avgjørende scenarier eller testtilfeller . Dette kan ha en flott negativ påvirkning mens du implementerer programvaren. Dette resulterer i et stort tap av ressurser (tidsfrister).
- Testscenarier hjelper i stor grad i unngå uttømmende testing . Det sikrer at alle viktige og forventede forretningsstrømmer blir testet, noe som ytterligere hjelper til med å teste applikasjonen til slutt.
- Dette er tidsbesparende. Det er heller ikke nødvendig med en mye detaljert beskrivelse i henhold til testtilfellene. En one-liner beskrivelse er spesifisert om hva du skal teste.
- Testscenarier er skrevet etter idédugnad av teammedlemmene. Derfor er sannsynligheten for å savne noe scenario (avgjørende eller mindre) minimalt. Dette gjøres med tanke på det tekniske og også forretningsflyten til programvaren.
- Videre kan testscenariene godkjennes enten av forretningsanalytiker eller klient eller begge som har eksplisitt kunnskap om applikasjonen som testes.
Testscenarier er altså en uunnværlig del av SDLC.
Implementering av testscenarier
La oss se implementeringen av testscenarier eller hvordan vi skriver testscenarier-
- Epics / Business Requirements dannes.
- Eksempel på Epic : Opprett en Gmail-konto. Epic kan være hovedtrekket i et program eller et forretningskrav.
- Epics er delt inn i mindre brukerhistorier på tvers av sprints.
- Brukerhistorier er hentet fra Epics. Disse brukerhistoriene må baseres og godkjennes av interessenter.
- Testscenarier er avledet fra brukerhistorier eller BRS (Business Requirement Document), SRS (System Requirement Specification Document) eller FRS (Functional Requirement Document) som er avsluttet og grunnlinjert.
- Testere skriver testscenariene.
- Disse testscenariene er godkjent av teamleder, forretningsanalytiker eller prosjektleder, avhengig av organisasjon.
- Hvert testscenario må være knyttet til minst en brukerhistorie.
- Positive og negative testscenarier må identifiseres.
- Brukerhistorier består av Akseptkriterier som :
- Akseptkriterier er en liste over betingelser eller intensjon for kundens krav. Kundens forventninger og misforståelsene vurderes når man skriver akseptkriteriene.
- Disse er unike for en brukerhistorie, og hver brukerhistorie må ha minst ett akseptkriterium som skal kunne testes uavhengig av hverandre.
- Akseptkriterier hjelper deg med å bestemme hvilke funksjoner som er innenfor omfang og hvilke som ikke er i omfang for et prosjekt. Disse kriteriene bør omfatte funksjonelle så vel som ikke-funksjonelle funksjoner.
- Forretningsanalytikere skriver akseptkriteriene, og produkteieren godkjenner dem.
- Eller i noen tilfeller kan produkteieren selv skrive kriteriene.
- Testscenarier kan fås fra akseptkriteriene.
Eksempler på testscenarier
# 1) Testscenarier for Kindle App
Kindle er appen som gjør det mulig for e-leserne å søke etter e-bøker online, laste ned og kjøpe dem. Amazon Kindle gir e-bokleseren den virkelige opplevelsen av å holde en bok i hånden og lese den. Selv sidevending er simulert pent i appen.
La oss nå notere testscenariene. ( Merk: Begrensede scenarier er oppført nedenfor for å få en generell ide om hvordan du skriver testscenariet. Det kan være flere testtilfeller avledet fra det).
Test scenarier # | Test scenarier |
---|---|
7 | Kontroller at nedlastingsfunksjonaliteten fungerer som den skal. |
1 | Kontroller om Kindle App starter riktig. |
to | Bekreft skjermoppløsningen justeres i henhold til forskjellige enheter, etter at appen er startet. |
3 | Bekreft at den viste teksten er lesbar. |
4 | Bekreft at zoom inn og zoom ut fungerer. |
5 | Kontroller at kompatible filer importert i Kindle-appen er lesbare. |
6 | Bekreft lagringskapasiteten til Kindle App. |
8 | Kontroller at sidesimulering fungerer som den skal |
9 | Bekreft kompatibiliteten med eBook-formatene med Kindle-appen. |
10 | Bekreft skriftene som støttes av Kindle-appen. |
elleve | Bekreft batterilevetiden som brukes av Kindle-appen. |
12 | Bekreft ytelsen til Kindle, avhengig av nettverkstilkobling (Wi-Fi, 3G eller 4G). |
Flere testsaker kan utledes fra hvert testscenario som er angitt ovenfor.
# 2) Akseptkriterier for Google Dokumenter
‘Google docs’ er et nettbasert program for å opprette, redigere og dele orddokumenter, regneark, lysbilder og skjemaer. Alle filene er tilgjengelige på nettet ved hjelp av en nettleser som har en internettforbindelse.
Dokumentene som er opprettet kan deles som en webside eller et utskriftsklar dokument. Brukeren kan sette begrensninger på hvem som kan se og redigere dokumentene. Et enkelt dokument kan deles og bearbeides av forskjellige personer fra forskjellige geografiske steder.
Begrensede testscenarier er nevnt nedenfor for generell forståelse. Grundige testscenarier for Google-dokumenter kan være et eget tema helt.
Akseptkriterier # | Akseptkriterier |
---|---|
7 | Flere brukere kan jobbe med ett dokument. |
1 | Word, Sheets eller Forms kan åpnes uten feil. |
to | Maler er tilgjengelige for dokumenter, ark og lysbilder. |
3 | Tilgjengelige maler er tilgjengelige for brukere. |
4 | Malen som brukes, kan redigeres (f.eks: skrifttyper, skriftstørrelse, legge til tekst, slette tekst, sette inn lysbilde). |
5 | Hvis internettforbindelse ikke er tilgjengelig midlertidig, kan filen lagres lokalt og lastes opp på tilgjengeligheten av internettforbindelse. |
6 | Endringer gjort av flere brukere er ikke overskrevet. |
8 | Utført arbeid lagres hvis internettforbindelsen går tapt mens du laster opp en fil. |
9 | Delingsbegrensninger brukes riktig. |
10 | Visningsbegrensning brukere kan ikke redigere dokumentene. |
elleve | Dokumenter kan publiseres på internett for allmennheten. |
12 | Endringer gjort i dokumenter lagres med tidsstempel og forfatterdetaljer. |
Antall testscenarier vil være flere og veldig store for Google Dokumenter. I slike tilfeller er generelt bare akseptkriteriene satt og godkjent av interessenter, og teammedlemmene jobber med disse akseptkriteriene. Å skrive testsaker for eller rettere testscenarier kan være den uttømmende oppgaven for store applikasjoner.
Disse akseptkriteriene spiller en viktig rolle i planleggingen av iterativ prosess og bør aldri overses. Å definere dem på forhånd og på forhånd unngår overraskelser eller støt på slutten av spurter eller utgivelser
Gitt en forutsetning.
Når å gjøre en handling.
Deretter resultatet forventet.
Formatene til Gitt, When and Then er nyttige for å spesifisere akseptkriterier.
Eksempel på testscenariomal
Bruk historie-ID # | Test scenario ID # | Versjon # | Test scenarier | # Antall prøvesaker | Betydning |
---|---|---|---|---|---|
USID12.1 | TSID12.1.1 | Kin12.4 | Kontroller om Kindle App starter riktig. | 4 | Høy |
USID12.1 | TSID12.1.2 | Kin12.4 | Bekreft lagringskapasiteten til Kindle App. | 3 | Medium |
Konklusjon
I enhver programvaretesting er livssyklus forståelse og nedlegging av testscenarier et veldig viktig element. Kvaliteten på programvaren kan forbedres ved å ha et godt grunnlag for testscenarier. Ofte kan bruken av testtilfeller og testscenarier byttes ut.
Tommelfingerregelen er imidlertid at testscenariet brukes til å skrive flere testtilfeller, eller vi kan si at testtilfeller er hentet fra testscenarier. Godt definerte testscenarier sikrer programvare av god kvalitet.
Anbefalt lesing
- Eksempel på programvare Testplanmal med format og innhold
- Eksempel på prøvesaksmal med eksempler på prøvesaker (Last ned)
- Eksempelmal for akseptrapport med eksempler
- Maler i C ++ med eksempler
- Python DateTime Tutorial med eksempler
- Klipp kommandoen i Unix med eksempler
- Test Scenario Vs Test Case: Hva er forskjellen mellom disse?
- Blazemeter-plugin og Jmeter-mal