state transition testing technique
Lees wat is State Transition Testing en hoe u State Transition Diagram kunt gebruiken:
In ons laatste artikel zagen we de ‘ Oorzaak en gevolg-grafiek 'Testcase-schrijftechniek. Laten we vandaag naar de volgende dynamische schrijfmethode voor testcases gaan: State Transition-techniek.
Dit document onderzoekt de uitbreiding van dit testconcept naar grotere applicaties, die geen FSM's als geheel zijn, maar sommige van hun componenten wel, om zo de unieke eigenschap van ‘stateful’ en overgangsregels toe te passen, wat resulteert in vele voordelen.
State Transition Testing
State Transition testen is een Black-box-testtechniek , die kan worden toegepast om ‘Finite State Machines’ te testen.
Een ‘Finite State Machine (FSM)’ is een systeem dat zich in verschillende discrete toestanden bevindt (zoals ‘gereed’, ‘niet gereed’, ‘open’, ‘gesloten’, ...) afhankelijk van de input of stimuli.
De discrete stelt dat het systeem eindigt, hangt af van de regels van de overgang van het systeem. Dat wil zeggen, als een systeem een andere uitvoer geeft voor dezelfde invoer, afhankelijk van de eerdere toestand, dan is het een systeem met een eindige toestand.
Verder, als elke transactie in het systeem wordt getest, wordt dit '0-switch' -dekking genoemd. Als het testen betrekking heeft op 2 paar geldige transacties, dan is het '1-switch' -dekking, enzovoort.
Wat je leert:
Wat is de testtechniek voor staatstransitie?
Toestandsovergangstechniek is een dynamische testtechniek die wordt gebruikt wanneer het systeem wordt gedefinieerd in termen van een eindig aantal toestanden en de overgangen tussen de toestanden worden beheerst door de regels van het systeem.
Met andere woorden, deze techniek wordt gebruikt wanneer kenmerken van een systeem worden weergegeven als toestanden die in elkaar overgaan. De transformaties worden bepaald door de regels van de software. De picturale weergave kan worden weergegeven als:
Dus hier zien we dat een entiteit overgangen vanwege sommigen van staat 1 naar staat 2 invoer conditie, wat leidt tot een evenement en resulteert in actie en geeft tenslotte de output
Om het met een voorbeeld uit te leggen:
U bezoekt een geldautomaat en neemt $ 1000 op. U krijgt uw geld. Nu heb je geen saldo meer en doe je precies hetzelfde verzoek om $ 1000 op te nemen. Dit keer weigert ATM u het geld te geven vanwege onvoldoende saldo. Dus hier de overgang , waardoor de verandering in staat is de eerdere terugtrekking
Definitie van testen van statusovergang
Nu we hebben begrepen wat State Transition is, kunnen we nu tot een zinvollere definitie komen voor het testen van State Transition. Het is dus een soort black-box-testen waarbij de tester het gedrag van AUT (Application Under Test) moet onderzoeken tegen verschillende inputcondities die in een reeks worden gegeven.
Het gedrag van het systeem wordt geregistreerd voor zowel positieve als negatieve testwaarden.
Wanneer State Transition Testing gebruiken?
Toestandsovergangstesten kunnen in de volgende situaties worden gebruikt:
website die youtube-video's naar mp3 converteert
- Wanneer de te testen applicatie een real-time systeem is met verschillende toestanden en overgangen.
- Wanneer de toepassing afhankelijk is van de gebeurtenis / waarden / omstandigheden uit het verleden.
- Wanneer de volgorde van gebeurtenissen moet worden getest.
- Wanneer de applicatie moet worden getest tegen een eindige set invoerwaarden.
Wanneer moet u State Transition Testing niet gebruiken?
In de volgende situaties mag u niet vertrouwen op het testen van de staatstransitie:
- Wanneer testen niet vereist is voor opeenvolgende invoercombinaties.
- Wanneer verschillende functionaliteiten van de applicatie moeten worden getest (meer zoals Exploratory testing).
State Transition Testing Voorbeeld in Software Testing
In het praktische scenario krijgen testers normaal gesproken de State Transition-diagrammen en moeten we deze interpreteren.
Deze diagrammen worden gegeven door de Business Analisten of een stakeholder en we gebruiken deze diagrammen om onze testcases te bepalen.
Laten we eens kijken naar de onderstaande situatie:
Software naam - Manage_display_changes
Specificaties - De software reageert op invoerverzoeken om de weergavemodus voor een tijdweergaveapparaat te wijzigen.
De weergavemodus kan worden ingesteld op een van de vier waarden:
- Twee komen overeen met het weergeven van de tijd of de datum.
- De andere twee bij het wijzigen van de tijd of de datum.
De verschillende staten zijn als volgt:
- Wijzigingsmodus (CM): Als dit wordt geactiveerd, zal de weergavemodus schakelen tussen 'weergavetijd (T)' en 'weergavedatum (D)'.
- Reset (R): Als de weergavemodus is ingesteld op T of D, zal een 'reset' ervoor zorgen dat de weergavemodus wordt ingesteld op de modi 'tijd wijzigen (AT)' of 'datum wijzigen (AD)'.
- Tijdset (TS): Activering hiervan zal ertoe leiden dat de weergavemodus van AT terugkeert naar T.
- Datum ingesteld (DS): Activering hiervan zorgt ervoor dat de weergavemodus vanuit AD terugkeert naar D.
Staat Overgangsdiagram
Laten we het nu gaan interpreteren:
Hier:
# 1) Verschillende staten zijn:
- Weergavetijd (S1),
- Tijd wijzigen (S3),
- Weergavedatum (S2), en
- Datum wijzigen (S4).
# 2) Verschillende ingangen zijn:
- Wijzigingsmodus (CM),
- Reset (R),
- Tijdset (TS),
- Datum ingesteld (DS).
# 3) Verschillende outputs zijn:
- Tijd wijzigen (AT),
- Weergavetijd (T),
- Weergavedatum (D),
- Datum wijzigen (AD).
# 4) De gewijzigde staten zijn:
- Weergavetijd (S1),
- Tijd wijzigen (S3),
- Weergavedatum (S2) en
- Datum wijzigen (S4).
Stap 1: Schrijf alle startstatussen. Neem hiervoor één toestand tegelijk en kijk hoeveel pijlen eruit komen.
- Voor staat S1 komen er twee pijlen uit. De ene pijl gaat naar S3 en een andere pijl naar S2.
- Voor staat S2 - Er zijn 2 pijlen. De ene gaat naar staat S1 en de andere gaat naar S4
- Voor staat S3 - Er komt maar 1 pijl uit, naar toestand S1
- Voor staat S4 - Er komt maar 1 pijl uit, naar toestand S2
Laten we dit op onze tafel zetten:
Omdat er voor toestand S1 en S2 twee pijlen naar buiten komen, hebben we het twee keer geschreven.
Stap 2: Noteer voor elke staat hun laatste overgangstoestanden.
- Voor toestand S1 - De eindtoestanden zijn S2 en S3
- Voor staat S2 - De eindtoestanden zijn S1 en S4
- Voor staat S3 - De eindtoestand is S1
- Voor State S4 - Final State is S2
Zet dit op de tafel als een Output / Resultant-status.
Stap 3: Schrijf voor elke startstatus en de bijbehorende eindtoestand de invoer- en uitvoervoorwaarden op
- Om status S1 naar status S2 te laten gaan, is de invoer de wijzigingsmodus (CM) en de uitvoer is de weergavedatum (D) hieronder weergegeven:
Noteer op dezelfde manier de ingangsvoorwaarden en de uitvoer ervan voor alle toestanden als volgt:
Stap 4:
maak een kopie van array java
Voeg nu de testcase-ID toe voor elke onderstaande test:
Laten we het nu converteren naar formele testcases:
Op deze manier kunnen alle resterende testgevallen worden afgeleid. Ik neem het andere aan attributen van de testgevallen zoals randvoorwaarden, ernst, prioriteit, omgeving, build, etc. worden ook meegenomen in de testcase.
Nogmaals de stappen samenvattend:
- Identificeer de begintoestanden en hun eindtoestand op basis van de lijnen / pijlen die uit de begintoestand komen.
- Zoek voor elke begintoestand de invoervoorwaarde en het uitvoerresultaat op
- Markeer elke set als een aparte testcase.
Meer voorbeelden van State Transition Technique
Hier is nog een voorbeeld van de State Transition Testing-techniek in grotere softwaretoepassingen.
Omschrijving:
Stateful Functional Testing ’ aanpak kan worden gebruikt om specifieke onderdelen of componenten van de applicatie te testen, met het kenmerk van een Finite State Machine (FSM).
Stappen in implementatie:
# 1) De eerste stap bij het implementeren van de ‘Stateful Functional Testing’ is het identificeren van verschillende componenten / delen van de applicatie die kunnen worden gecategoriseerd als FSM's. De inputs, statussen en outputs worden zorgvuldig bijgehouden voor elk van deze FSM's.
#twee) De volgende stap zou zijn om testcases te ontwikkelen voor deze FSM's op basis van overgangsregels, inputs, outputs en transitiestaten.
# 3) De derde stap zou zijn om het testen van deze componenten te integreren met andere interfacecomponenten om de applicatie end-to-end te valideren.
Dit kan worden verklaard door middel van een voorbeeld van een applicatie genaamd 'House Project', die de bouw van een huis volgt, met verschillende applicatiecomponenten zoals goedkeuring van de architectuur van het huis, registratie van het perceel en huis, selectie van de aannemer , goedkeuring van woonkrediet, etc.
Bijvoorbeeld,
We zullen overwegen om één FSM-onderdeel van de “House Project” -toepassing te testen: goedkeuring van de huisvestingslening.
Aanvraag voor goedkeuring van huisvestingsleningen (HLA)
De HLA-aanvraag wordt beheerd door een onafhankelijke Leningverwerkende Gebruiker, die de Leningaanvraag verwerkt. De verschillende stappen bij de verwerking van de aanvraag worden hieronder beschreven:
1.1.1 Stap 1: Verzameling van documenten
De eerste stap is het verzamelen van relevante documenten voor het aanvragen van de lening, zoals vermeld in onderstaande tabel. Het zijn de ‘voorwaarden’ voor een succesvolle aanvraag. De aanvrager verzamelt de benodigde documenten en past deze toe op het woonkrediet.
De Uitleenverwerkende Gebruiker erkent de ontvangst van de documenten en zet de status van de Leenaanvraag (dat wil zeggen de staat van de HLA-aanvraagcomponent) over naar de status “Toegepast”.
Tabel 1: lijst met documenten
1.1.2 Stap 2: Beoordeling van de lening
In dit stadium beoordeelt de kredietgever de Kredietaanvraag om te bepalen of deze voldoet aan zijn kredietvereisten. De ondersteunende documenten worden op dit moment geverifieerd.
Tabel 2: kriticiteit van documenten
De documenten die nodig zijn voor de beoordeling, dat zijn de “voorwaarden” die in dit stadium gevalideerd moeten worden, worden gevalideerd. Aan elke voorwaarde is een kritiek verbonden (vermeld als ‘Y’ in de bovenstaande tabel). Zodra aan alle vereiste kritieke voorwaarden is voldaan, gaat de toepassing naar de status 'Bevestigd' - dat wil zeggen dat de HLA-toepassingscomponent zich in de status 'Bevestigd' bevindt.
Let op:
# 1) Dit principe zorgt voor een structuur en objectiviteit in de testomstandigheden en 'State' -definities van het systeem
Ook zijn niet alle 'voorwaarden' voor het valideren van het systeem kritiek om deze status 'Bevestigd' te bereiken. In de bovenstaande tabel zijn 4 voorwaarden gemarkeerd als 'Niet kritiek' voordat de toepassing de status 'Bevestigd' bereikt.
#twee) Het aantal validaties kan optimaal worden verminderd, afhankelijk van het risico of de kritikaliteit van de regels die voor elke staat vereist zijn. Dit zal de tijd die nodig is voor het uitvoeren van tests aanzienlijk verkorten en tegelijkertijd de kwaliteit van het testen niet in gevaar brengen.
# 3) Dit is niet alleen handig om de afzonderlijke componenten te testen, maar ook om het systeem end-to-end te testen.
# 4) Ook erg handig bij het maken van regressietestsuites.
In dit stadium is het dus een test met 0 schakelaars. Maar latere goedkeuringsfasen kunnen validaties met 1 schakelaar of 2 schakelaars voor die fase zijn.
Bijvoorbeeld, 'Huwelijksakte' is in dit stadium misschien niet al te relevant, maar in de laatste stadia van goedkeuring, wanneer het risico van de aanvrager om het EMI te betalen wordt overwogen, kan de huwelijksakte relevant worden - dat wil zeggen, als de echtgenoot ook in dienst is , het vermindert het risico, en als het niet wordt gebruikt, verhoogt het het risico.
# 5) Het bovenstaande principe kan worden gebruikt voor het uitbreiden van de testomstandigheden, afhankelijk van de vereisten van het onderdeel in dat stadium.
1.1.3 Stap 3: voorwaardelijke goedkeuring
De huidige status van de applicatie is 'Bevestigd'. De geldschieter zou ‘voorwaardelijke goedkeuring’ geven om het leningsproces verder te laten gaan. Verdere validaties zijn vereist om de HLA-applicatie naar de status 'Goedgekeurd' te verplaatsen.
1.1.4 Stap 4: goedkeuring
In deze fase worden kritische validaties uitgevoerd:
- Beoordeling door de Lenders Mortgage Insurance (LMI): dit zou 2-switch of meer validaties voor de echtheid van het onroerend goed inhouden.
- De Financier kan informatie opvragen die niet tijdens de “Bevestigingsfase” is verstrekt.
Zodra aan de bovenstaande voorwaarden is voldaan, gaat de toepassing naar de status 'Goedgekeurd'. De uiteindelijke autoriteit van het goedkeuringsproces kan de geloofwaardigheid van de Kredietaanvrager kruisen door om meer details te vragen of kan niet vragen of de andere documenten van de Aanvrager doorslaggevend zijn. Dat wil zeggen dat er meer input nodig is van verschillende componenten van de hoofdtoepassing om de validiteit te bewijzen
# 6) Met andere woorden, er kunnen meer validaties nodig (of verminderd) zijn voor de overgang naar een andere status, afhankelijk van de invoervoorwaarden voor de component vanuit andere componenten van de applicatie.
Onderstaand schema geeft het goedkeuringsproces weer.
Figuur 1: goedkeuringsproces voor leningen
Risico's en uitdagingen
- Voor grote applicaties is diepgaande applicatiekennis essentieel om de applicatie op te splitsen in verschillende logische componenten om categorisering als FSM's en reguliere componenten mogelijk te maken. Dit kan kostbare tijd vergen van het MKB.
- Niet alle toepassingen zouden de haalbaarheid hebben van dit soort FSM-categorisering.
- Omdat FSM-componenten interageren met reguliere componenten in de applicatie, is een zorgvuldige planning en uitvoering vereist voor input van FSM's van verschillende componenten.
Voordelen van State Transition-testen
- Met deze techniek raakt de tester vertrouwd met het applicatieontwerp door gebruik te maken van een picturale of tabelweergave van het systeemgedrag en voelt hij zich gemakkelijk om de tests effectief en efficiënt te dekken en te ontwerpen.
- De ongeplande of ongeldige toestanden van het systeem worden ook gedekt door deze techniek te gebruiken.
- Met behulp van het State Transition-diagram is het gemakkelijk om te controleren of aan alle voorwaarden is voldaan.
Nadelen van State Transition-testen
- Deze techniek kan niet worden gebruikt voor niet-eindige-toestandssystemen.
- Het definiëren van alle mogelijke toestanden voor grote en complexe systemen is een behoorlijk omslachtige taak.
Gevolgtrekking
Toestandsovergangstesten zijn een nuttige benadering wanneer verschillende systeemovergangen moeten worden getest voor eindige-toestandssystemen.
Het testen van een applicatie met het concept van 'Stateful Functional Testing' kan testorganisaties een unieke testaanpak geven voor het testen van complexe applicaties, die de productiviteit van de testuitvoering zou verhogen zonder afbreuk te doen aan de testdekking.
State Transition-testen is een unieke testbenadering voor het testen van complexe applicaties, die de productiviteit van de testuitvoering zou verhogen zonder afbreuk te doen aan de testdekking.
De beperking van deze techniek is dat deze niet kan worden gebruikt totdat en tenzij het te testen systeem slechts eindige toestanden heeft.
Aanbevolen literatuur
- Wat is een op defecten gebaseerde testtechniek?
- Wat is orthogonale array-testtechniek (OATS)?
- Functioneel testen versus niet-functioneel testen
- Wat is vergelijkende testen (leren met voorbeelden)
- Wat is mutatietesten: zelfstudie met voorbeelden
- Wat is duurtesten bij softwaretests (voorbeelden)
- Wat is end-to-end testen: E2E-testraamwerk met voorbeelden
- Beste softwaretesttools 2021 (QA Test Automation Tools)