static testing dynamic testing difference between these two important testing techniques
Testovanie je Overenie a overenie . Všetci vieme, že na dokončenie testovania sú potrebné 2 Vs.
V dnešnom článku si posvietime Statické testovanie . Nazýva sa tiež Overenie. Dozvieme sa o tom všetko a budeme tomu venovať osobitný dôraz, pretože Dynamické testovanie často sa mu venuje maximálna pozornosť a má nespočetné množstvo podrobných článkov.
c ++ generuje náhodné číslo medzi 0 a 1
Žiadna diskusia o statickom testovaní by však nebola úplná bez vysvetlenia, čo znamená jej náprotivok, dynamické testovanie. Dynamické testovanie je validácia, druhé „V“.
Dynamické testovanie je, keď pracujete so skutočným systémom (nie s nejakým artefaktom alebo modelom, ktorý predstavuje) systému), poskytuje vstup, prijíma výstup a porovnáva výstup s očakávaným správaním. Jedná sa o praktickú prácu so systémom so zámerom nájsť chyby.
Počas tohto procesu pochopíme, že nasledujúce dve bežné mylné predstavy o testovaní nie sú pravdivé:
- Testovanie je aktivita, ktorá prichádza na konci
- Vykonávajú ho iba testéri a ostatní nemajú čo robiť
Začnime rýchlym odkazom na v-model :
- Na strana po ľavej ruke modelu V máme činnosti, ktoré nevykonáva tím QA.
- Na pravá strana , máme niektoré z nich, o ktoré sa stará tím vývojárov, časť testerov a časť používateľov.
Začnime s - Zhromažďovanie požiadaviek . Vykonáva to obchodný analytik a ďalší nadriadení - výstupným dokumentom pre túto fázu je dokument obchodných požiadaviek, BRD.
Ďalšou etapou je Návrh systému . Návrh systému je fázou, v ktorej sú obchodné požiadavky prevedené do funkčných požiadaviek v dokumente FRD (Funkčné požiadavky).
Keď dôjde k prekladu, tím vývojárov (ktorý je hlavným aktérom tohto kroku) prejde dokumentom BRD krok za krokom, stránku po stránke a riadok po riadku. Aj keď je hlavným cieľom spotrebovanie obchodných požiadaviek kvôli prekladu, dokument BRD sa postupne prehodnocuje.
Príklad: Povedzme, že toto je BRD pre bankovú stránku, ktorá je veľká z hľadiska bezpečnosti. V BRD je časť, ktorá hovorí o pravidlách hesiel pre rôznych používateľov, ktorí si vytvárajú účet na webe online bankovníctva. Jedným z pravidiel je: Používateľ nemôže použiť heslo, ktoré používa pre iné účty.
To nie je možné. Pretože stránka môže iba navrhnúť, ako by mal používateľ nastaviť prihlasovacie poverenia, nemožno to nijako obmedziť. Táto požiadavka teda nie je uskutočniteľná - inými slovami, nemožno ju splniť pomocou softvéru.
Uvažujme teraz na základe tohto príkladu nasledujúce body:
- Ako sa zistí, že táto požiadavka nie je zostaviteľná, a preto ju nemožno otestovať (inými slovami, nie je to možné)? Máme webovú stránku banky a potom nastavíme prihlasovacie meno a heslo - a potom si uvedomíme, že to nie je možné? Nie, vychádzame iba z našej revízie smernice BRD a samozrejme z nejakého spoločného obchodného zmyslu.
- Testujeme túto požiadavku? Iste, ale čisto na základe teoretického, koncepčného zmyslu, ale nie na skutočnom AUT (testovaná aplikácia).
- Aká je fyzická forma tohto testu? -Jednoduché prečítanie alebo formálne preskúmanie BRD alebo ešte formálnejšia analýza uskutočniteľnosti obchodných požiadaviek.
Keď sa vrátime k našim mylným predstavám:
- Kto vykonáva túto kontrolu smernice BRD? - Väčšinou vývojový tím a ďalšie technické tímy, ktoré sú zodpovedné za vytvorenie produktu. Nie testeri.
- Prebieha táto kontrola na konci vytvárania produktu? Nie, vo veľmi počiatočnej fáze vývoja projektu. Preto nielen koniec.
Techniky statického testovania:
Stručne povedané, statické testovanie je verifikačnou časťou testovania softvéru, ktorá sa riadi metódami:
- Recenzie dokumentov
- Návody
- Inšpekcia
- Analýza uskutočniteľnosti alebo iná forma analýzy na určenie, či je softvér taký, aký by mal byť alebo nie
- Preskúmanie kódu
Citovať CSTE CBOK, „Overenie odpovedá na otázku:„ Vytvorili sme správny systém? “ pri overovaní adresy „Vytvorili sme systém správne?“
Nasledujú všetky statické testovacie činnosti, ktoré sa vyskytujú na ľavej strane V-modelu.
| Fáza SDLC | Výkon | Overuje | Herci |
|---|---|---|---|
| Zhromažďovanie obchodných požiadaviek | BRD (dokument obchodných požiadaviek) | Rozsah dokumentu (ak existuje) | |
| Návrh systémových požiadaviek | FRD (dokument o funkčných požiadavkách) | Kontroluje / overuje BRD | Vývojové, technické tímy |
| Návrh technických požiadaviek | TDD (dokument o technickom dizajne) | Kontroluje / overuje FRD | Vývojové, technické tímy |
| Dizajn (kód) | Zákonníka | Kontroluje / overuje TDD. Kontrola kódu vývojovým tímom z hľadiska úplnosti, formátu atď. | Vývojové, technické tímy |
Poznámka: Tieto informácie môžu byť extrapolované pre projekty podľa akejkoľvek vývojovej metodológie, pretože kroky budú viac-menej podobné.
Na pravej strane modelu V je overenie.
Techniky dynamického testovania:
- Testovanie jednotiek
- Testovanie integrácie
- Testovanie systému
Fáza Unit, integrácia, systém a UAT sú zamerané na vytváranie testov, ktoré sa majú vykonať na AUT počas rôznych fáz jeho vývoja. Aj keď sú testy zamerané na validáciu rôznych druhov požiadaviek, všetky sú rovnaké.
Akákoľvek forma testovania, kde máme test, ktorý je potrebné vykonať na AUTe a jeho výstupe, je nevyhnutná na stanovenie výsledku testu (úspešného alebo neúspechu) - ide o validáciu.
Bolo by v poriadku zovšeobecniť, že na pravej strane (RHS) modelu V nie je vôbec žiadne overenie? Odpoveď znie: Nie.
Všetky testy, ktoré sa vytvoria v každej fáze RHS, sa niekoľkokrát skontrolujú počas fázy vytvárania / finalizácie testu. Podrobný proces kontroly dokumentácie k testu je na adrese https://www.softwaretestinghelp.com/test-documentation-reviews/
Na RHS:
ako spustiť súbory jar v systéme Windows
- Testy a kód vývojári kontrolujú vo fázach testovania jednotky / integrácie.
- Systémové testy prechádzajú počas dokumentácie vzájomným hodnotením a po dokončení sú podrobené kontrole vývojovým tímom a obchodným analytikom.
- Skúšky UAT prechádzajú pred začiatkom UAT kontrolou tímom QA aj používateľmi.
Záver
Záverom možno povedať, že statické testovanie je dôležitou testovacou technikou, ktorá má formu kontroly obchodných požiadaviek, kontroly funkčných požiadaviek, kontroly dizajnu, návodov na kódy a kontroly dokumentácie testu. Je to nepretržitá činnosť, ktorú nerobia iba testéri.
Overenie, časť s dynamickým testovaním je praktickejšia a deje sa na samotnom produkte, a nie na artefakte alebo znázornení produktu. Metódy dynamického testovania poznačuje veľa formálneho procesu identifikácie testovacích prípadov / podmienok, úvah o pokrytí, vykonania a hlásenia chýb.
O autorovi: Tento článok je napísaný členom tímu STH Swati S.
Podeľte sa, prosím, o svoje pripomienky, otázky a skúsenosti k téme statického a dynamického testovania.
Odporúčané čítanie
- Rozdiel medzi počítačom, klientskym serverom a webom
- Techniky agilného odhadu: Skutočný odhad v agilnom projekte
- Testovanie čiernej skrinky: Podrobný návod s príkladmi a technikami
- Čo je Testovanie zhody (Testovanie zhody)?
- Aký je rozdiel medzi testovaním SIT vs UAT?
- Alfa testovanie a beta testovanie (kompletný sprievodca)
- Kľúčové rozdiely medzi testovaním čiernej skrinky a testovaním bielej skrinky
- Rozdiely medzi testovaním jednotiek, testovaním integrácie a funkčným testovaním