state transition testing technique
Aflați ce este testarea tranziției de stat și cum să utilizați diagrama de tranziție de stat:
În ultimul nostru articol, am văzut „ Graficul cauzei și efectului Tehnica de scriere a cazului de testare. Astăzi să trecem la următoarea metodă dinamică de scriere a cazurilor de testare - tehnica tranziției de stat.
Acest document explorează extinderea acestui concept de testare la aplicații mai mari, care nu sunt FSM-uri în ansamblu, dar unele dintre componentele lor sunt, astfel încât să adopte caracteristica sa unică de „a fi stat” și a regulilor de tranziție, rezultând multe avantaje.
Testarea tranziției de stat
Testarea tranziției de stat este o Tehnica de testare a cutiei negre , care poate fi aplicat pentru a testa „Mașini cu stare finită”.
O „Mașină de stat finit (FSM)” este un sistem care va fi în diferite stări discrete (cum ar fi „gata”, „nu este gata”, „deschisă”, „închisă”, ...) în funcție de intrări sau stimuli.
Stările discrete cu care sistemul ajunge, depinde de regulile de tranziție a sistemului. Adică, dacă un sistem oferă o ieșire diferită pentru aceeași intrare, în funcție de starea sa anterioară, atunci este un sistem de stare finită.
Mai mult, dacă fiecare tranzacție este testată în sistem, aceasta se numește acoperire „0-switch”. Dacă testarea acoperă 2 perechi de tranzacții valide, atunci este acoperirea „cu 1 comutator” și așa mai departe.
Ce veți învăța:
Care este tehnica de testare a tranziției de stat?
Tehnica de tranziție a stării este o tehnică de testare dinamică, care este utilizată atunci când sistemul este definit în termenii unui număr finit de stări și tranzițiile între stări sunt guvernate de regulile sistemului.
Sau cu alte cuvinte, această tehnică este utilizată atunci când trăsăturile unui sistem sunt reprezentate ca stări care se transformă una în alta. Transformările sunt determinate de regulile software-ului. Reprezentarea picturală poate fi prezentată ca:
Deci, aici vedem că o entitate tranziții de la statul 1 la statul 2 din cauza unora intrare condiție, care duce la o eveniment și are ca rezultat acțiune și în cele din urmă dă ieșire .
Pentru a o explica cu un exemplu:
Vizitați un bancomat și retrageți 1000 USD. Îți primești banii. Acum rămâneți fără echilibru și faceți exact aceeași cerere de retragere de 1000 USD. De data aceasta ATM refuză să vă ofere banii din cauza soldului insuficient. Deci, aici tranziție , care a cauzat schimbare de stare este retragerea anterioară
Definiția testării tranziției de stat
După ce am înțeles ce este tranziția de stat, putem ajunge acum la o definiție mai semnificativă pentru testarea tranziției de stat. Deci, este un fel de testare a cutiei negre în care testerul trebuie să examineze comportamentul AUT (Application Under Test) împotriva diferitelor condiții de intrare date într-o succesiune.
Comportamentul sistemului este înregistrat atât pentru valorile pozitive, cât și pentru cele negative.
Când se folosește testarea tranziției de stat?
Testarea tranziției de stat poate fi utilizată în următoarele situații:
cel mai bun convertor video pentru Mac
- Când aplicația testată este un sistem în timp real cu stări și tranziții diferite cuprinse.
- Când aplicația depinde de evenimentul / valorile / condițiile din trecut.
- Când succesiunea evenimentelor trebuie testată.
- Când aplicația trebuie testată în raport cu un set finit de valori de intrare.
Când să nu folosiți testarea tranziției de stat?
Nu trebuie să vă bazați pe testarea tranziției de stat în următoarele situații:
- Când testarea nu este necesară pentru combinații secvențiale de intrare.
- Când sunt necesare diferite funcționalități ale aplicației pentru a fi testate (mai mult ca testarea exploratorie).
Exemplu de testare a tranziției de stat în testarea software-ului
În scenariul practic, testerilor li se oferă în mod normal diagrame de tranziție de stat și ni se cere să o interpretăm.
Aceste diagrame sunt date fie de către analistii de afaceri, fie de către un părți interesate și folosim aceste diagrame pentru a determina cazurile noastre de testare.
Să luăm în considerare situația de mai jos:
Numele software-ului - Manage_display_changes
Specificații - Software-ul răspunde la solicitările de intrare pentru a schimba modul de afișare pentru un dispozitiv de afișare a timpului.
Modul de afișare poate fi setat la una dintre cele patru valori:
- Două corespund afișării orei sau datei.
- Celelalte două la modificarea orei sau datei.
Diferitele stări sunt după cum urmează:
- Mod de schimbare (CM): Activarea acestui lucru va determina modul de afișare să se deplaseze între „ora de afișare (T)” și „data afișării (D)”.
- Resetare (R): Dacă modul de afișare este setat la T sau D, atunci o „resetare” va face ca modul de afișare să fie setat la modurile „alter time (AT)” sau „alter date (AD)”.
- Timp stabilit (TS): Activarea acestui lucru va determina revenirea modului de afișare la T de la AT.
- Set de date (DS): Activarea acestui lucru va determina revenirea modului de afișare la D din AD.
Diagrama tranziției de stat
Acum, să trecem să-l interpretăm:
Aici:
# 1) Diferite state sunt:
- Afișare timp (S1),
- Schimbă timpul (S3),
- Afișează data (S2) și
- Data schimbării (S4).
# 2) Diverse intrări sunt:
- Mod de schimbare (CM),
- Resetați (R),
- Set de timp (TS),
- Set de date (DS).
# 3) Diverse ieșiri sunt:
- Alter Time (AT),
- Afișare timp (T),
- Data de afișare (D),
- Data de schimbare (AD).
# 4) Statele modificate sunt:
- Afișare timp (S1),
- Schimbă timpul (S3),
- Afișează Data (S2) și
- Data schimbării (S4).
Pasul 1: Scrieți toate stările de început. Pentru aceasta, luați câte o stare la rând și vedeți câte săgeți ies din ea.
- Pentru State S1, există două săgeți care ies din ea. O săgeată va stoca S3 și o altă săgeată va stoca S2.
- Pentru State S2 - Există 2 săgeți. Unul se îndreaptă spre statul S1 și altul se îndreaptă spre S4
- Pentru statul S3 - Doar o săgeată iese din ea, ajungând la statul S1
- Pentru statul S4 - Doar o săgeată iese din ea, ajungând la statul S2
Să punem acest lucru pe masa noastră:
Deoarece pentru starea S1 și S2, sunt două săgeți care ies, am scris-o de două ori.
Pasul 2: Pentru fiecare stat, scrieți stările lor trecute finale.
- Pentru starea S1 - Stările finale sunt S2 și S3
- Pentru statul S2 - Stările finale sunt S1 și S4
- Pentru statul S3 - Starea finală este S1
- Pentru statul S4 - starea finală este S2
Puneți acest lucru pe masă ca stare de ieșire / rezultată.
Pasul 3: Pentru fiecare stare de pornire și starea de finisare corespunzătoare, scrieți condițiile de intrare și ieșire
- Pentru ca starea S1 să treacă la starea S2, intrarea este Mod de schimbare (CM) și ieșirea este Data afișării (D) prezentată mai jos:
În mod similar, scrieți condițiile de intrare și ieșirea acesteia pentru toate stările după cum urmează:
Pasul 4:
Acum adăugați ID-ul cazului de test pentru fiecare test prezentat mai jos:
Acum să-l convertim în cazuri de testare oficiale:
În acest fel, pot fi derivate toate celelalte cazuri de testare. Îl presupun pe celălalt atributele cazurilor de testare cum ar fi condițiile prealabile, severitatea, prioritatea, mediul, construirea etc. sunt, de asemenea, incluse în cazul testului.
Rezumând încă o dată pașii:
- Identificați stările inițiale și starea finală a acestora pe baza liniilor / săgeților care ies din starea inițială.
- Pentru fiecare stare inițială, aflați condiția de intrare și rezultatul de ieșire
- Marcați fiecare set ca un caz de testare separat.
Mai multe exemple de tehnică de tranziție de stat
Iată încă un exemplu de tehnică de testare a tranziției de stat în aplicații software mai mari.
Descriere:
' Testare funcțională de stare ” abordarea poate fi utilizată pentru a testa anumite părți sau componente ale aplicației, cu caracteristica unei mașini de stat finit (FSM).
Pași în implementare:
# 1) Primul pas în implementarea „testării funcționale de stat” este identificarea diferitelor componente / părți ale aplicației care pot fi clasificate ca FSM-uri. Intrările, stările și ieșirile sunt urmărite cu atenție pentru fiecare dintre aceste FSM.
#Două) Următorul pas ar fi dezvoltarea de cazuri de testare pentru aceste FSM pe baza regulilor de tranziție, a intrărilor, a rezultatelor și a stărilor de tranziție.
# 3) Al treilea pas ar fi integrarea testării acestor componente cu alte componente de interfață pentru validarea aplicației cap la cap.
Acest lucru poate fi explicat printr-un exemplu de aplicație denumită „Proiect de casă”, care urmărește construcția unei case, cu diferite componente ale aplicației, cum ar fi aprobarea arhitecturii casei, înregistrarea parcelei și a casei, selectarea contractorului de construcție , aprobarea împrumutului pentru locuințe etc.
De exemplu,
Vom lua în considerare testarea unei componente FSM a aplicației „Proiectul casei”: aprobarea împrumutului pentru locuințe.
Cerere de aprobare a împrumutului pentru locuințe (HLA)
Aplicația HLA va fi administrată de un utilizator independent de procesare a împrumutului, care procesează cererea de împrumut. Diferitele etape ale procesării cererii sunt detaliate mai jos:
1.1.1 Pasul 1: Colectarea documentelor
Primul pas este colectarea documentelor relevante pentru aplicarea împrumutului, după cum se menționează în tabelul de mai jos. Acestea sunt „condițiile” pentru o cerere de succes. Solicitantul colectează documentele solicitate și le aplică la împrumutul pentru locuință.
Utilizatorul de procesare a împrumutului recunoaște primirea documentelor și trece starea cererii de împrumut (adică starea componentei cererii HLA) la starea „Aplicată”.
Tabelul 1: Lista documentelor
1.1.2 Pasul 2: Evaluarea împrumutului
În această etapă, creditorul evaluează cererea de împrumut pentru a determina dacă îndeplinește cerințele sale de credit. Documentele justificative sunt verificate în acest moment.
Tabelul 2: Criticitatea documentelor
Documentele necesare pentru evaluare, adică „condițiile” care trebuie validate în această etapă, sunt validate. Fiecare condiție are o criticitate atașată (menționată ca „Y” în tabelul de mai sus). Odată îndeplinite toate condițiile critice necesare, aplicația se mută în starea „Confirmată” - adică componenta aplicației HLA se află în starea „Confirmată”.
Punct de reținut:
# 1) Acest principiu aduce o structură și obiectivitate condițiilor de testare și definițiilor „stării” sistemului .
De asemenea, nu toate „condițiile” pentru validarea sistemului sunt esențiale pentru ca acesta să ajungă la această stare „Confirmată”. În tabelul de mai sus, 4 condiții sunt marcate ca „Nu sunt critice” pentru ca aplicația să ajungă la starea „Confirmat”.
#Două) Numărul de validări poate fi redus în mod optim, în funcție de riscul sau criticitatea regulilor necesare pentru fiecare stat. Acest lucru va reduce semnificativ timpul necesar pentru executarea testului și, în același timp, nu va compromite calitatea testării.
# 3) Acest lucru este util nu numai pentru testarea componentelor individuale, ci și pentru testarea sistemului cap la cap.
# 4) De asemenea, foarte util la crearea suitelor de testare de regresie.
Deci, în această etapă, este un tip de testare cu 0 comutatoare. Dar etapele ulterioare ale aprobării pot fi tipuri de validări cu 1 comutator sau 2 comutatoare pentru acea etapă.
De exemplu, „Certificatul de căsătorie” poate să nu fie prea relevant în această etapă, dar în ultimele etape ale aprobării, atunci când se ia în considerare riscul solicitantului de a plăti IME, certificatul de căsătorie poate deveni relevant - adică dacă soțul este angajat și el , reduce riscul și, dacă nu este angajat, crește riscul.
# 5) Principiul de mai sus poate fi utilizat pentru extinderea condițiilor de testare în funcție de cerința componentei în etapa respectivă.
eșantion de CV pentru tester software experimentat
1.1.3 Pasul 3: aprobare condiționată
Starea actuală a aplicației este „Confirmată”. Împrumutătorul va acorda „aprobare condiționată” pentru ca procesul de împrumut să avanseze. Sunt necesare validări suplimentare pentru mutarea aplicației HLA în starea „Aprobat”.
1.1.4 Pasul 4: Aprobare
Validările critice sunt efectuate în această etapă:
- Evaluare de către Asigurătorii de credite ipotecare (LMI): aceasta ar presupune validări cu 2 comutatoare sau mai multe pentru autenticitatea proprietății.
- Împrumutătorul poate solicita informații care nu au fost date în timpul etapei „Confirmare”.
Odată îndeplinite condițiile de mai sus, aplicația trece la starea „Aprobat”. Autoritatea finală a procesului de aprobare poate controla credibilitatea solicitantului împrumutului solicitând mai multe detalii sau nu poate întreba dacă celelalte documente ale solicitantului sunt concludente. Adică, ar fi necesare mai multe intrări de la diferite componente ale aplicației principale pentru a demonstra validitatea .
# 6) Cu alte cuvinte, pot fi necesare (sau reduse) mai multe validări pentru trecerea la o stare diferită în funcție de condițiile de intrare în componentă de la alte componente ale aplicației.
Diagrama de mai jos prezintă procesul de aprobare.
Figura 1: Procesul de aprobare a împrumuturilor
Riscuri și provocări
- Pentru aplicații mari, cunoștințele profunde ale aplicației sunt esențiale pentru a împărți aplicația în diferite componente logice pentru a permite clasificarea ca FSM și componente obișnuite. Acest lucru ar putea necesita timp costisitor de la IMM-uri.
- Nu toate aplicațiile ar avea fezabilitatea acestui tip de clasificare FSM.
- Întrucât componentele FSM interacționează cu componentele obișnuite din aplicație, intrările în FSM de la diferite componente necesită o planificare și o execuție atentă.
Avantajele testării tranziției de stat
- În cadrul acestei tehnici, utilizând o reprezentare picturală sau tabelară a comportamentului sistemului, testerul se familiarizează cu designul aplicației și se simte ușor să acopere și să proiecteze testele în mod eficient și eficient.
- Stările neplanificate sau nevalide ale sistemului sunt acoperite și prin utilizarea acestei tehnici.
- Folosind diagrama Tranziției de stat, este ușor să verificați dacă sunt acoperite toate condițiile.
Dezavantaje ale testării tranziției de stat
- Această tehnică nu poate fi utilizată pentru sistemele cu stare nonfinită.
- Definirea tuturor stărilor posibile pentru sistemele mari și complexe este o sarcină destul de greoaie.
Concluzie
Testarea tranziției de stat este o abordare utilă atunci când sunt necesare tranziții de sistem diferite pentru a fi testate pentru sisteme cu stare finită.
Testarea unei aplicații cu conceptul „Testare funcțională de stare” poate oferi organizațiilor de testare o abordare de testare unică pentru testarea aplicațiilor complexe, care ar crește productivitatea executării testelor fără a compromite acoperirea testului.
Testarea tranziției de stat este o abordare de testare unică pentru testarea aplicațiilor complexe, care ar crește productivitatea executării testului fără a compromite acoperirea testului.
Limita acestei tehnici constă în faptul că nu poate fi utilizată până și dacă sistemul testat nu are decât stări finite.
Lectură recomandată
- Ce este tehnica de testare bazată pe defecte?
- Ce este tehnica de testare a matricei ortogonale (OATS)?
- Testarea funcțională Vs testarea nefuncțională
- Ce este testarea comparativă (Aflați cu exemple)
- Ce este testarea mutației: Tutorial cu exemple
- Ce este testarea de anduranță în testarea software (exemple)
- Ce este testul de la capăt la capăt: Cadrul de testare E2E cu exemple
- Cele mai bune instrumente de testare software 2021 (Instrumente de automatizare a testelor de calitate)