state transition testing technique
Lær hva som er State Transition Testing og hvordan du bruker State Transition Diagram:
I vår siste artikkel så vi Årsak og virkning graf ’Test case skriveteknikk. I dag la oss gå til neste dynamiske testmetode - State Transition-teknikk.
Dette dokumentet utforsker utvidelse av dette testkonseptet til større applikasjoner, som ikke er FSM-er som en helhet, men noen av komponentene deres er for å vedta det unike trekket med å være 'stateful' og overgangsregler, noe som resulterer i mange fordeler.
State Transition Testing
Testing av statlig overgang er en Black-box testing teknikk , som kan brukes til å teste 'Finite State Machines'.
En 'Finite State Machine (FSM)' er et system som vil være i forskjellige diskrete tilstander (som 'klar', 'ikke klar', 'åpen', 'lukket', ...) avhengig av innganger eller stimuli.
Den diskrete tilstanden som systemet ender med, avhenger av reglene for systemets overgang. Det vil si at hvis et system gir en annen utgang for samme inngang, avhengig av dets tidligere tilstand, er det et endelig tilstandssystem.
Videre, hvis hver transaksjon blir testet i systemet, kalles det '0-switch' dekning. Hvis testing dekker 2 par gyldige transaksjoner, er det '1-switch' dekning, og så videre.
Hva du vil lære:
Hva er State Transition Testing Technique?
Statlig overgangsteknikk er en dynamisk testteknikk, som brukes når systemet er definert i et begrenset antall stater og overgangene mellom statene styres av systemets regler.
Eller med andre ord, denne teknikken brukes når funksjoner i et system er representert som tilstander som forvandles til hverandre. Transformasjonene bestemmes av programvarens regler. Den billedlige fremstillingen kan vises som:
Så her ser vi at en enhet overganger fra stat 1 til stat 2 på grunn av noen inngang tilstand, noe som fører til en begivenhet og resulterer i handling og til slutt gir produksjon .
For å forklare det med et eksempel:
Du besøker en minibank og tar ut $ 1000. Du får kontanter. Nå går du tom for balanse og ber nøyaktig den samme forespørselen om å ta ut $ 1000. Denne gangen minibank nekter å gi deg pengene på grunn av utilstrekkelig balanse. Så her overgang , som forårsaket endring i tilstand er det tidligere uttaket
Definisjon av State Transition Testing
Etter å ha forstått hva State Transition er, kan vi nå komme til en mer meningsfull definisjon for State Transition testing. Så det er en slags black-box testing der testeren må undersøke oppførselen til AUT (Application Under Test) mot forskjellige inngangsbetingelser gitt i en sekvens.
Oppførselen til systemet registreres for både positive og negative testverdier.
Når skal jeg bruke State Transition Testing?
State Transition testing kan brukes i følgende situasjoner:
hvordan du åpner swf med Adobe Flash Player
- Når applikasjonen som testes er et sanntidssystem med forskjellige tilstander og overganger omfattet.
- Når applikasjonen er avhengig av hendelsen / verdiene / forholdene fra fortiden.
- Når hendelsesforløpet må testes.
- Når applikasjonen må testes mot et endelig sett med inngangsverdier.
Når skal du ikke bruke State Transition Testing?
Du bør ikke stole på testing av statlig overgang i følgende situasjoner:
- Når testing ikke er nødvendig for sekvensielle inngangskombinasjoner.
- Når det kreves at forskjellige funksjoner i applikasjonen skal testes (mer som utforskende testing).
Eksempel på statlig overgangstest i programvaretesting
I det praktiske scenariet får testere normalt tilstandsovergangsdiagrammene, og vi må tolke det.
Disse diagrammene er enten gitt av forretningsanalytikerne eller en interessent, og vi bruker disse diagrammene for å bestemme testtilfellene våre.
La oss se på situasjonen nedenfor:
Programvare navn - Manage_display_changes
Spesifikasjoner - Programvaren svarer på inngangsforespørsler om å endre visningsmodus for en tidsvisningsenhet.
Skjermmodus kan settes til en av de fire verdiene:
- To som tilsvarer enten tid eller dato.
- De to andre når du endrer enten tid eller dato.
De forskjellige tilstandene er som følger:
- Endre modus (CM): Aktivering av dette skal føre til at skjermmodus beveger seg mellom “display time (T)” og “display date (D)”.
- Tilbakestill (R): Hvis skjermmodus er satt til T eller D, skal en 'reset' føre til at skjermmodusen settes til 'endre tid (AT)' eller 'endre dato (AD)' -modus.
- Tidssett (TS): Aktivering av dette skal føre til at visningsmodusen går tilbake til T fra AT.
- Datosett (DS): Aktivering av dette skal føre til at visningsmodusen går tilbake til D fra AD.
Statlig overgangsdiagram
La oss nå tolke det:
Her:
# 1) Ulike stater er:
- Visningstid (S1),
- Endre tid (S3),
- Vis dato (S2), og
- Endre dato (S4).
# 2) Ulike innganger er:
- Endre modus (CM),
- Tilbakestill (R),
- Tidssett (TS),
- Datosett (DS).
# 3) Ulike utganger er:
- Alter Time (AT),
- Visningstid (T),
- Visningsdato (D),
- Endre dato (AD).
# 4) De forandrede stater er:
- Visningstid (S1),
- Endre tid (S3),
- Vis dato (S2) og
- Endre dato (S4).
Trinn 1: Skriv alle starttilstandene. For dette, ta en stat om gangen og se hvor mange piler som kommer ut fra den.
- For State S1 er det to piler som kommer ut av den. En pil skal si S3 og en annen pil skal si S2.
- For State S2 - Det er to piler. Den ene skal til S1 og den andre til S4
- For tilstand S3 - Bare én pil kommer ut av den, og går til tilstand S1
- For tilstand S4 - Bare én pil kommer ut av den, og går til tilstand S2
La oss legge dette på vårt bord:
Siden for tilstand S1 og S2 er det to piler som kommer ut, vi har skrevet det to ganger.
Steg 2: For hver stat, skriv ned de endelige overgangsstatene.
- For tilstand S1 - De endelige tilstandene er S2 og S3
- For tilstand S2 - De endelige tilstandene er S1 og S4
- For tilstand S3 - Den endelige tilstanden er S1
- For State S4 - Final State er S2
Sett dette på bordet som en Output / resulterende tilstand.
Trinn 3: For hver starttilstand og tilsvarende sluttilstand, skriv ned inngangs- og utgangsbetingelsene
- For at tilstand S1 skal gå til tilstand S2, er inngangen Endringsmodus (CM) og utgang er Visningsdato (D) vist nedenfor:
På en lignende måte, skriv ned inngangsbetingelsene og utdataene for alle tilstandene som følger:
Trinn 4:
Legg nå til test case ID for hver test vist nedenfor:
La oss nå konvertere det til formelle testsaker:
På denne måten kan alle gjenværende testtilfeller avledes. Jeg antar den andre attributtene til testsakene som forutsetninger, alvorlighetsgrad, prioritet, miljø, bygg osv. er også inkludert i testsaken.
Oppsummering av trinnene igjen:
- Identifiser de opprinnelige tilstandene og deres endelige tilstand basert på linjene / pilene som kommer ut av den opprinnelige tilstanden.
- For hver starttilstand, finn ut inngangsbetingelsen og utgangsresultatet
- Merk hvert sett som en egen testtilfelle.
Flere eksempler på statlig overgangsteknikk
Her er enda et eksempel på State Transition Testing-teknikken i større programvareapplikasjoner.
Beskrivelse:
' Stateful Functional Testing ' tilnærming kan brukes til å teste spesifikke deler eller komponenter i applikasjonen, med karakteristikken til en Finite State Machine (FSM).
Fremgangsmåte for implementering:
#1) Det første trinnet i implementeringen av 'Stateful Functional Testing' er å identifisere forskjellige komponenter / deler av applikasjonen som kan kategoriseres som FSM. Innganger, tilstander og utganger blir nøye sporet for hver av disse FSM-ene.
#to) Det neste trinnet vil være å utvikle testsaker for disse FSM-ene basert på overgangsregler, innganger, utganger og overgangstilstander.
# 3) Det tredje trinnet ville være å integrere testingen av disse komponentene med andre grensesnittkomponenter for å validere applikasjonen fra ende til annen.
Dette kan forklares ved hjelp av et eksempel på en applikasjon kalt 'House Project', som sporer byggingen av et hus, med forskjellige applikasjonskomponenter som godkjenning av husets arkitektur, registrering av tomten og huset, valg av byggentreprenør , godkjenning av boliglån mv.
For eksempel,
Vi skal vurdere å teste en FSM-komponent i 'House Project' -søknaden: Godkjenning av boliglånet.
Søknad om godkjenning av boliglån (HLA)
HLA-søknaden drives av en uavhengig bruker for lånebehandling, som behandler lånesøknaden. De forskjellige trinnene i behandlingen av søknaden er beskrevet nedenfor:
1.1.1 Trinn 1: Samling av dokumenter
Det første trinnet er innsamling av relevante dokumenter for å søke om lånet som nevnt i tabellen nedenfor. De er 'betingelsene' for en vellykket søknad. Søkeren samler de nødvendige dokumentene og bruker dem på boliglånet.
Lånebehandlingsbrukeren bekrefter mottak av dokumentene og overfører tilstanden til lånesøknaden (det vil si tilstanden til HLA-applikasjonskomponenten) til tilstanden “Anvendt”.
enkelt java-program for å sortere tall i stigende rekkefølge
Tabell 1: Dokumentliste
1.1.2 Trinn 2: Lånevurdering
På dette stadiet vurderer utlåneren lånesøknaden for å avgjøre om den oppfyller kredittkravene hans. Støttedokumentene er verifisert på dette tidspunktet.
Tabell 2: Dokumentets kritikk
Dokumentene som kreves for vurderingen, det vil si 'vilkårene' som må valideres på dette stadiet, er validert. Hver tilstand har en kritikk knyttet til seg (nevnt som ‘Y’ i tabellen ovenfor). Når alle nødvendige kritiske forhold er oppfylt, flytter applikasjonen til tilstanden “Bekreftet” - det vil si at HLA-applikasjonskomponenten er i “Bekreftet” tilstand.
Merk deg:
#1) Dette prinsippet bringer en struktur og objektivitet til testforholdene og 'State' -definisjonene til systemet .
Det er heller ikke alle 'vilkårene' for å validere systemet som er avgjørende for at det skal nå denne 'Bekreftede' tilstanden. I tabellen over er fire forhold merket som 'Ikke kritisk' for at applikasjonen skal nå 'Bekreftet'.
#to) Antall valideringer kan reduseres optimalt, avhengig av risikoen eller kritikken til reglene som kreves for hver stat. Dette vil redusere tiden som kreves for testutførelse betydelig, og samtidig ikke kompromittere testkvaliteten.
# 3) Dette er ikke bare nyttig for å teste de enkelte komponentene, men også for å teste systemet fra ende til annen.
# 4) Også veldig nyttig når du lager regresjonstestpakker.
Så på dette stadiet er det en 0-bryter type testing. Men senere stadier av godkjenning kan være 1-bryter eller 2-bryter typer valideringer for det trinnet.
For eksempel, 'Ekteskapsattest' er kanskje ikke så relevant på dette stadiet, men i de siste stadiene av godkjenning når risikoen for søkeren å betale EMI vurderes, kan vielsesattesten bli relevant - det vil si hvis ektefellen også er ansatt , det reduserer risikoen, og hvis den ikke er ansatt, øker den risikoen.
# 5) Ovennevnte prinsipp kan brukes til å utvide testforholdene avhengig av kravet til komponenten på det stadiet.
1.1.3 Trinn 3: Betinget godkjenning
Søknadens nåværende status er “Bekreftet”. Långiveren vil gi 'Betinget godkjenning' for at låneprosessen skal komme videre. Ytterligere valideringer er nødvendige for å flytte HLA-søknaden til staten “Godkjent”.
1.1.4 Trinn 4: Godkjenning
Kritiske valideringer gjennomføres på dette stadiet:
- Vurdering fra Lenders Mortgage Insurance (LMI): dette vil innebære 2-switch eller flere valideringer for eiendommens ekthet.
- Långiveren kan kreve informasjon som ikke ble gitt under 'Bekreftelsesfasen'.
Når vilkårene ovenfor er oppfylt, flytter applikasjonen til “Godkjent” -tilstand. Den endelige autoriteten til godkjenningsprosessen kan kryssjekke troverdigheten til lånesøkeren ved å be om mer informasjon eller kanskje ikke spørre om søkerens andre dokumenter er avgjørende. Det vil si at flere innganger fra forskjellige komponenter i hovedapplikasjonen ville være nødvendige for å bevise gyldigheten .
# 6) Med andre ord kan det kreves (eller reduseres) flere valideringer for overgangen til en annen tilstand, avhengig av inngangsbetingelsene til komponenten fra andre komponenter i applikasjonen.
Diagrammet nedenfor viser godkjenningsprosessen.
Figur 1: Godkjenningsprosess for lån
Risiko og utfordringer
- For store applikasjoner er dyp applikasjonskunnskap viktig for å dele applikasjonen i forskjellige logiske komponenter for å muliggjøre kategorisering som FSM og vanlige komponenter. Dette kan kreve kostbar tid fra SMB.
- Ikke alle applikasjoner vil ha muligheten for denne typen FSM-kategorisering.
- Siden FSM-komponenter samhandler med vanlige komponenter i applikasjonen, krever innganger til FSM fra forskjellige komponenter nøye planlegging og utføring.
Fordeler med statlig overgangstesting
- Under denne teknikken blir testeren kjent med applikasjonsdesignet ved å bruke en bildemessig eller tabellrepresentasjon av systematferd og føles lett å dekke og utforme testene effektivt og effektivt.
- De ikke planlagte eller ugyldige tilstandene i systemet blir også dekket ved å bruke denne teknikken.
- Ved hjelp av State Transition-diagrammet er det enkelt å verifisere om alle forholdene er dekket.
Ulemper ved testing av statlig overgang
- Denne teknikken kan ikke brukes i ikke-endelige statlige systemer.
- Å definere alle mulige tilstander for store og komplekse systemer er en ganske tungvint oppgave.
Konklusjon
State Transition testing er en nyttig tilnærming når forskjellige systemoverganger må testes for endelige tilstandssystemer.
Å teste en applikasjon med konseptet 'Stateful Functional Testing' kan gi testorganisasjoner en unik testtilnærming for å teste komplekse applikasjoner, noe som vil øke produktets produktivitet uten å gå på kompromiss med testdekning.
State Transition testing er en unik testtilnærming for testing av komplekse applikasjoner, som vil øke produktiviteten for testutførelse uten å gå på bekostning av testdekningen.
Begrensningen med denne teknikken er at den ikke kan brukes før og med mindre systemet som testes har bare endelige tilstander.
Anbefalt lesing
- Hva er feilbasert testteknikk?
- Hva er Orthogonal Array Testing Technique (OATS)?
- Funksjonstesting mot ikke-funksjonell testing
- Hva er sammenligningstesting (lær med eksempler)
- Hva er mutasjonstesting: opplæring med eksempler
- Hva er utholdenhetstesting i programvaretesting (eksempler)
- Hva er test til slutt til slutt: E2E Testing Framework med eksempler
- Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)