state transition testing technique
Zistite, čo je Testovanie prechodov stavu a ako používať diagram prechodov stavu:
V našom poslednom článku sme videli ‘ Graf príčin a následkov ‘Technika písania testovacích prípadov. Dnes sa presunieme k ďalšej metóde písania dynamických testovacích prípadov - technike prechodu stavu.
Tento dokument skúma rozšírenie tohto testovacieho konceptu na väčšie aplikácie, ktoré nie sú FSM ako celok, ale niektoré z ich komponentov sú, aby si osvojil svoju jedinečnú vlastnosť „byť stavový“ a prechodových pravidiel, čo má za následok mnoho výhod.
Štátne prechodové testovanie
Štátne prechodové testovanie je a Technika testovania čiernej skrinky , ktoré je možné použiť na testovanie „strojov konečných stavov“.
„Finite State Machine (FSM)“ je systém, ktorý bude v rôznych samostatných stavoch (napríklad „pripravený“, „nie je pripravený“, „otvorený“, „zatvorený“, ...) v závislosti od vstupov alebo podnetov.
Diskrétne uvádza, že systém skončí, závisí od pravidiel prechodu systému. To znamená, že ak systém poskytuje rozdielny výstup pre ten istý vstup, v závislosti od jeho skoršieho stavu, potom ide o systém konečného stavu.
Ďalej, ak je každá transakcia testovaná v systéme, nazýva sa to pokrytie „prepínačom 0“. Ak testovanie pokrýva 2 páry platných transakcií, potom ide o pokrytie „jedným prepínačom“ atď.
Čo sa dozviete:
Aká je technika testovania prechodného stavu?
Technika prechodu stavu je technika dynamického testovania, ktorá sa používa, keď je systém definovaný ako konečný počet stavov a prechody medzi stavmi sa riadia pravidlami systému.
Alebo inými slovami, táto technika sa používa, keď sú vlastnosti systému reprezentované ako stavy, ktoré sa navzájom transformujú. Transformácie sú určené pravidlami softvéru. Obrázkové znázornenie môže byť zobrazené ako:
Takže tu vidíme túto entitu prechody zo štátu 1 do štátu 2 kvôli niektorým vstup stav, ktorý vedie k udalosť a výsledky v akcia a nakoniec dáva výkon .
Na vysvetlenie príkladom:
Navštívite bankomat a vyberiete 1 000 dolárov. Dostanete svoju hotovosť. Teraz sa vám minie rovnováha a požadujete výber peňazí 1000 dolárov. Bankomat vám tentokrát odmietne dať peniaze z dôvodu nedostatočného zostatku. Takže tu prechod , ktorá spôsobila zmena stavu je skorší výber
Definícia testovania prechodového stavu
Po pochopení toho, čo je štátny prechod, môžeme teraz dospieť k zmysluplnejšej definícii testovania štátneho prechodu. Jedná sa teda o druh testovania čiernej skrinky, pri ktorom musí tester skúmať správanie AUT (testovaná aplikácia) proti rôznym vstupným podmienkam uvedeným v poradí.
Chovanie systému sa zaznamenáva pri pozitívnych aj negatívnych hodnotách testu.
Kedy použiť Testovanie štátneho prechodu?
Testovanie stavu prechodu je možné použiť v nasledujúcich situáciách:
softvér na kopírovanie DVD z PC
- Keď je testovanou aplikáciou systém v reálnom čase s rôznymi stavmi a prechodmi.
- Kedy je aplikácia závislá na udalosti / hodnotách / podmienkach minulosti.
- Kedy je potrebné testovať sled udalostí.
- Keď je potrebné aplikáciu otestovať na základe konečnej sady vstupných hodnôt.
Kedy nepoužívať Testovanie štátneho prechodu?
Na testovanie Štátneho prechodu by ste sa nemali spoliehať v nasledujúcich situáciách:
- Keď sa testovanie nevyžaduje pre sekvenčné kombinácie vstupu.
- Keď sa vyžaduje testovanie rôznych funkcionalít aplikácie (napríklad Prieskumné testovanie).
Príklad testovania prechodu stavu v testovaní softvéru
V praktickom scenári dostanú testeri zvyčajne diagramy prechodov štátov a my sme povinní ich interpretovať.
Tieto diagramy poskytujú buď obchodní analytici alebo zainteresované strany a pomocou týchto diagramov určujeme naše testovacie prípady.
Zvážme nasledujúcu situáciu:
Názov softvéru - Manage_display_changes
Technické údaje - Softvér reaguje na vstupné požiadavky na zmenu režimu zobrazenia pre zariadenie na zobrazovanie času.
Režim displeja je možné nastaviť na jednu zo štyroch hodnôt:
- Dve zodpovedajúce zobrazeniu času alebo dátumu.
- Ďalšie dva pri zmene času alebo dátumu.
Jednotlivé stavy sú tieto:
- Zmeniť režim (CM): Jeho aktivácia spôsobí, že sa režim zobrazenia bude pohybovať medzi „časom zobrazenia (T)“ a „zobrazením dátumu (D)“.
- Reset (R): Ak je režim zobrazenia nastavený na T alebo D, potom „reset“ spôsobí nastavenie režimu zobrazenia na režimy „pozmeniť čas (AT)“ alebo „pozmeniť dátum (AD)“.
- Nastavený čas (TS): Jeho aktivácia spôsobí, že sa režim zobrazenia vráti z AT do polohy T.
- Nastavený dátum (DS): Aktivácia tohto spôsobí, že sa režim zobrazenia vráti z režimu AD do polohy D.
Schéma prechodu stavu
Teraz to poďme interpretovať:
Tu:
# 1) Rôzne štáty sú:
- Čas zobrazenia (S1),
- Čas zmeny (S3),
- Zobraziť dátum (S2) a
- Dátum zmeny (S4).
# 2) Rôzne vstupy sú:
- Zmeniť režim (CM),
- Resetovať (R),
- Nastavený čas (TS),
- Nastavený dátum (DS).
# 3) Rôzne výstupy sú:
- Čas zmeny (AT),
- Čas zobrazenia (T),
- Zobraziť dátum (D),
- Dátum zmeny (AD).
# 4) Zmenené štáty sú:
- Čas zobrazenia (S1),
- Čas zmeny (S3),
- Zobraziť dátum (S2) a
- Dátum zmeny (S4).
Krok 1: Napíšte všetky počiatočné stavy. Za týmto účelom berte jeden štát po druhom a uvidíte, koľko šípov z neho vychádza.
- Pre štát S1 z neho vychádzajú dve šípky. Jedna šípka smeruje do stavu S3 a ďalšia šípka smeruje do stavu S2.
- Pre štát S2 - existujú 2 šípky. Jeden smeruje do štátu S1 a druhý do štátu S4
- Pre štát S3 - z neho vychádza iba 1 šípka smerujúca do stavu S1
- Pre štát S4 - z neho vychádza iba 1 šípka smerujúca do stavu S2
Dajme to na náš stôl:
Keďže pre štát S1 a S2 vychádzajú dve šípky, napísali sme to dvakrát.
Krok 2: Pre každý štát si napíšte ich konečné prechodné stavy.
- Pre stav S1 - Konečné stavy sú S2 a S3
- Pre štát S2 - konečné stavy sú S1 a S4
- Pre štát S3 - konečný stav je S1
- Pre štát S4 - konečný stav je S2
Položte to na stôl ako stav Výstup / Výsledok.
Krok 3: Pre každý začiatočný stav a jeho zodpovedajúci konečný stav si zapíšte vstupné a výstupné podmienky
- Pre prechod do stavu S1 do stavu S2 je vstupom režim zmeny (CM) a výstupom je dátum zobrazenia (D) uvedený nižšie:
Podobným spôsobom zapíšte Vstupné podmienky a ich výstup pre všetky stavy nasledovne:
Krok 4:
Teraz pridajte ID testovacieho prípadu pre každý test uvedený nižšie:
Teraz to prevedieme na formálne testovacie prípady:
Týmto spôsobom je možné odvodiť všetky zostávajúce testovacie prípady. Predpokladám, že druhý atribúty testovacích prípadov do testovacieho prípadu sú zahrnuté aj predpoklady, závažnosť, priorita, prostredie, zostavenie atď.
Zhrnutie krokov ešte raz:
- Identifikujte počiatočné stavy a ich konečný stav na základe čiar / šípok, ktoré vychádzajú z počiatočného stavu.
- Pre každý počiatočný stav zistite vstupné podmienky a výstupné výsledky
- Každú súpravu označte ako samostatný testovací prípad.
Viac príkladov techniky prechodu štátu
Tu je ďalší príklad techniky State Transition Testing vo väčších softvérových aplikáciách.
Popis:
„ Stavové funkčné testovanie “ Na testovanie konkrétnych častí alebo komponentov aplikácie s charakteristikou stroja s konečným stavom (FSM) sa môže použiť tento prístup.
Kroky pri implementácii:
# 1) Prvým krokom pri implementácii „Stavového funkčného testovania“ je identifikácia rôznych komponentov / častí aplikácie, ktoré možno kategorizovať ako FSM. Vstupy, stavy a výstupy sú starostlivo sledované pre každý z týchto FSM.
#dva) Ďalším krokom by bolo vyvinúť testovacie prípady pre tieto MFŠ založené na prechodných pravidlách, vstupoch, výstupoch a prechodových stavoch.
# 3) Tretím krokom by bola integrácia testovania týchto komponentov s ostatnými komponentmi rozhrania na účely overenia platnosti aplikácie medzi koncami.
To sa dá vysvetliť na príklade aplikácie s názvom „Domový projekt“, ktorá sleduje stavbu domu s rôznymi komponentmi aplikácie, ako je schválenie architektúry domu, registrácia pozemku a domu, výber dodávateľa stavby. , schválenie úveru na bývanie a pod.
Napríklad,
Zvážime testovanie jednej zložky FSM aplikácie „Projekt domu“: Schválenie pôžičky na bývanie.
najlepší bezplatný firewall pre Windows 7
Žiadosť o schválenie pôžičky na bývanie (HLA)
Aplikáciu HLA bude prevádzkovať nezávislý používateľ spracovania pôžičky, ktorý spracuje žiadosť o pôžičku. Jednotlivé kroky pri spracovaní žiadosti sú podrobne uvedené nižšie:
1.1.1 Krok 1: Zbierka listín
Prvým krokom je zhromaždenie príslušných dokumentov týkajúcich sa žiadosti o pôžičku, ako je uvedené v nasledujúcej tabuľke. Sú „podmienkami“ pre úspešnú aplikáciu. Žiadateľ zhromaždí požadované dokumenty a použije ich na úver na bývanie.
Používateľ spracúvajúci pôžičku potvrdzuje prijatie dokumentov a prechádza do stavu Žiadosť o pôžičku (to je stav komponentu Aplikácia HLA) do stavu „Aplikované“.
Tabuľka 1: Zoznam dokumentov
1.1.2 Krok 2: Hodnotenie pôžičky
V tejto fáze veriteľ posúdi žiadosť o pôžičku, aby určil, či spĺňa jeho úverové požiadavky. Podporné dokumenty sú momentálne overené.
Tabuľka 2: Kritickosť dokumentov
Dokumenty požadované na posúdenie, to sú „podmienky“, ktoré je potrebné v tejto fáze validovať, sú validované. Každá podmienka má svoju kritickosť (uvedená v tabuľke vyššie ako „Y“). Keď sú splnené všetky požadované kritické podmienky, aplikácia sa presunie do stavu „Potvrdené“ - to znamená, že komponent aplikácie HLA je v stave „Potvrdené“.
Upozorňujem:
# 1) Tento princíp vnáša do testovacích podmienok a „stavových“ definícií systému štruktúru a objektivitu .
Nie všetky „podmienky“ na overenie platnosti systému sú takisto dôležité pre dosiahnutie tohto „potvrdeného“ stavu. V tabuľke vyššie sú 4 podmienky označené ako „Nie kritické“, aby aplikácia dosiahla stav „Potvrdené“.
#dva) Počet validácií je možné optimálne znížiť v závislosti od rizika alebo kritickosti pravidiel vyžadovaných pre každý štát. To výrazne zníži čas potrebný na vykonanie testu a zároveň nebude mať negatívny vplyv na kvalitu testovania.
# 3) To je užitočné nielen pri testovaní jednotlivých komponentov, ale aj pri testovaní celého systému.
# 4) Je to tiež veľmi užitočné pri vytváraní balíkov regresných testov.
V tejto fáze teda ide o testovanie typu 0 prepínačov. Ale neskoršie fázy schvaľovania môžu byť pre túto fázu typy overenia s 1 alebo 2 prepínačmi.
Napríklad, „Sobášny list“ nemusí byť v tejto fáze príliš relevantný, ale v posledných fázach schvaľovania, keď sa zvažuje riziko, že žiadateľ zaplatí EMI, môže byť relevantný sobášny list - teda ak je aj manžel / manželka zamestnaný , znižuje riziko, a ak nie je zamestnaný, zvyšuje riziko.
# 5) Vyššie uvedený princíp sa môže použiť na rozšírenie testovacích podmienok v závislosti od požiadaviek na komponent v danom štádiu.
1.1.3 Krok 3: Podmienené schválenie
Aktuálny stav aplikácie je „Potvrdené“. Veriteľ poskytne „Podmienené schválenie“, aby sa proces pôžičky mohol posunúť vpred. Na presun aplikácie HLA do stavu „Schválené“ sú potrebné ďalšie validácie.
1.1.4 Krok 4: Schválenie
Kritické validácie sa vykonávajú v tejto fáze:
- Posúdenie poistením hypotéky veriteľom (LMI): malo by sa vyžadovať overenie pravosti nehnuteľnosti dvojitým prepínačom alebo viac.
- Veriteľ môže požadovať informácie, ktoré neboli poskytnuté počas fázy „Potvrdenia“.
Po splnení vyššie uvedených podmienok sa aplikácia presunie do stavu „Schválené“. Konečný orgán schvaľovacieho procesu môže skontrolovať dôveryhodnosť žiadateľa o pôžičku tým, že požiada o ďalšie podrobnosti, alebo sa nemusí pýtať, či sú ďalšie doklady žiadateľa presvedčivé. To znamená, že na preukázanie platnosti by bolo potrebných viac vstupov z rôznych komponentov hlavnej aplikácie .
# 6) Inými slovami, na prechod do iného stavu sa môže vyžadovať (alebo obmedzovať) viac validácií v závislosti od vstupných podmienok pre komponent z iných komponentov aplikácie.
Nasledujúca schéma zobrazuje proces schvaľovania.
Obrázok 1: Proces schválenia pôžičky
Riziká a výzvy
- Pre veľké aplikácie je nevyhnutná hlboká znalosť aplikácie, aby sa aplikácia rozdelila na rôzne logické komponenty, čo umožní kategorizáciu ako FSM a bežné komponenty. Môže to vyžadovať od MSP nákladný čas.
- Nie všetky aplikácie by umožnili uskutočnenie tohto druhu kategorizácie FSM.
- Pretože komponenty FSM interagujú s bežnými komponentmi v aplikácii, vstupy do FSM z rôznych komponentov si vyžadujú starostlivé plánovanie a vykonávanie.
Výhody testovania štátneho prechodu
- V rámci tejto techniky sa tester pomocou obrazového alebo tabuľkového znázornenia správania systému oboznámi s dizajnom aplikácie a cíti sa ľahko efektívne a efektívne testovať a navrhovať.
- Použitím tejto techniky sa pokryjú aj neplánované alebo neplatné stavy systému.
- Pomocou diagramu štátneho prechodu je ľahké overiť, či sú splnené všetky podmienky.
Nevýhody testovania štátneho prechodu
- Túto techniku nie je možné použiť pre systémy s neurčitým stavom.
- Definovanie všetkých možných stavov pre veľké a zložité systémy je dosť ťažkopádna úloha.
Záver
Testovanie stavu prechodu je užitočný prístup, keď sa vyžaduje, aby sa pre systémy konečného stavu testovali rôzne prechody systému.
Testovanie aplikácie s konceptom „Stavové funkčné testovanie“ môže dať testovacím organizáciám jedinečný prístup k testovaniu testovania zložitých aplikácií, čo by zvýšilo produktivitu vykonávania testu bez kompromisu v oblasti pokrytia testom.
State Transition testing je jedinečný testovací prístup pre testovanie zložitých aplikácií, ktorý by zvýšil produktivitu vykonávania testu bez toho, aby došlo k zníženiu pokrytia testom.
Obmedzením tejto techniky je, že ju nemožno použiť, kým a pokiaľ testovaný systém nebude mať iba konečné stavy.
Odporúčané čítanie
- Čo je technika testovania na základe chýb?
- Čo je to technika testovania ortogonálnych polí (OATS)?
- Funkčné testovanie vs. Nefunkčné testovanie
- Čo je to porovnávacie testovanie (ďalšie informácie s príkladmi)
- Čo je to testovanie mutácií: Návod s príkladmi
- Čo je testovanie výdrže pri testovaní softvéru (príklady)
- Čo je komplexné testovanie: Testovací rámec E2E s príkladmi
- Najlepšie nástroje na testovanie softvéru 2021 [QA Test Automation Tools]