difference between test plan
Naučte sa, aký je rozdiel medzi plánom testu, stratégiou testu, prípadom testu, skriptom testu, scenárom testu a podmienkami testu s príkladmi:
Testovanie softvéru obsahuje niekoľko základných aj dôležitých konceptov, ktoré by mal každý tester softvéru poznať.
V tomto článku sú vysvetlené rôzne koncepty testovania softvéru a ich porovnanie.
Testovací plán vs Stratégia testu, Testovací prípad vs Testovací skript, Testovací scenár vs Testovací stav a Testovací postup vs Testovací balík sú pre lepšie pochopenie podrobne vysvetlené.
=> Kliknutím sem zobrazíte kompletnú sériu návodov na kompletný testovací plán
Vyššie uvedená otázka, ktorú položil Sasi C., je najčastejšou otázkou v našej Trieda testovania softvéru a vždy hovorím našim účastníkom, že so skúsenosťami si tieto slová takmer nevšimneme a že sa stanú súčasťou našej slovnej zásoby.
Často ich však obklopuje zmätok a v tomto článku sa pokúšam definovať niekoľko bežne používaných výrazov.
Rôzne koncepty testovania softvéru
Nižšie sú uvedené rôzne koncepty testovania softvéru spolu s ich porovnaním.
Začnime!!
Čo sa dozviete:
- Rozdiel medzi plánom testu a stratégiou testu
- Rozdiel medzi testovacím prípadom a testovacím skriptom
- Rozdiel medzi scenárom testu a podmienkou testu
- Rozdiel medzi skúšobným postupom a skúšobnou sadou
- Záver
Rozdiel medzi plánom testu a stratégiou testu
Stratégia testovania a plán testov sú dva dôležité dokumenty v životnom cykle testovania každého projektu. Tu sa snažíme poskytnúť vám dôkladné znalosti o stratégii testovania a dokumentoch plánu testov.
Plán skúšok
Testovací plán možno definovať ako dokument, ktorý definuje rozsah, cieľ a prístup k testovaniu softvérovej aplikácie. Testovací plán je termín a výsledok.
Plán testov je dokument, ktorý obsahuje zoznam všetkých aktivít v projekte QA, ich harmonogram, definuje rozsah projektu, úlohy a zodpovednosti, riziká, vstupné a výstupné kritériá, cieľ testu a všetko, na čo si spomeniete.
Testovací plán je to, čo by som rád nazval „super dokumentom“, ktorý obsahuje všetko, čo je potrebné vedieť a potrebovať. Prosím skontrolujte tento odkaz pre viac informácií a ukážku.
Plán skúšok bude navrhnutý na základe požiadaviek. Pri zadávaní práce testovacím technikom je z niektorých dôvodov jeden z testerov nahradený iným. Tu sa aktualizuje plán testov.
Stratégia Test načrtáva testovací prístup a všetko ostatné, čo ho obklopuje. Líši sa od plánu testov v tom zmysle, že stratégia testovania je iba podmnožinou plánu testov. Je to tvrdý testovací dokument, ktorý je do istej miery všeobecný a statický. Diskutuje sa aj o tom, na akých úrovniach sa stratégia alebo plán testovania používajú -, ale naozaj nevidím žiadny výrazný rozdiel.
Príklad: Plán testov poskytuje informácie o tom, kto a kedy bude testovať. Napríklad, Modul 1 bude testovaný „X testerom“. Ak tester Y z nejakého dôvodu nahradí X, je potrebné aktualizovať plán testov.
Dokument plánu skúšok
Testovací plán je dokument, ktorý poskytuje úplné informácie o testovacích úlohách týkajúcich sa softvérového projektu. Poskytuje podrobnosti ako Rozsah testovania, Typy testovania, Ciele, Metodika testovania, Úsilie o testovanie, Riziká a nepredvídané udalosti, Kritériá uvoľnenia, Výsledky testovania atď. Sleduje možné testy, ktoré sa po kódovaní v systéme spustia.
Plán testov sa zjavne chystá zmeniť. Spočiatku bude vypracovaný návrh plánu testov založený na vtedajšej jasnosti projektu. Tento pôvodný plán sa bude v priebehu projektu upravovať. Vedúci testovacieho tímu alebo vedúci testu môže pripraviť dokument plánu testu. Opisuje technické parametre a na základe toho sa môže meniť.
Čo testovať, kedy testovať, kto bude testovať a ako testovať, bude definované v testovacom pláne. Testovací plán usporiada zoznam problémov, závislostí a základných rizík.
Druhy plánu skúšok
Plány testov môžu byť rôzneho typu podľa stupňa testovania. Spočiatku bude existovať hlavný testovací plán pre celé uskutočnenie projektu. Pre konkrétne typy testovania, ako je testovanie systému, testovanie systémovej integrácie, testovanie akceptácie používateľom, je možné vytvoriť samostatné testovacie plány.
Ďalším prístupom je mať samostatné plány testovania funkčného a nefunkčného testovania. V tomto prístupe bude mať testovanie samostatný plán testovania.
Obsah dokumentu Plán testu ( Štruktúra testovacieho plánu IEEE-829 )
Je ťažké vypracovať jasný formát plánu testov. Formát plánu testov sa môže líšiť v závislosti od konkrétneho projektu. IEEE definovalo štandard pre testovacie plány, ktoré sú opísané ako štruktúra testovacieho plánu IEEE-829.
Ďalej nájdete odporúčania IEEE týkajúce sa štandardného obsahu plánu testov:
- Identifikátor testovacieho plánu
- Úvod
- Testovacie položky
- Problémy so softvérovým rizikom
- Vlastnosti, ktoré sa majú testovať
- Funkcie sa netestujú
- Prístup
- Kritériá vyhovenia / zlyhania položky (alebo) kritériá prijatia
- Kritériá pozastavenia a požiadavky na obnovenie
- Testovanie dodávok
- Testovacie úlohy
- Environmentálne požiadavky
- Personálne a školiace potreby
- Zodpovednosti
- Časový plán
- Schválenia
Navrhované čítanie => Výukový program pre testovací plán - dokonalý sprievodca
Stratégia testovania
Stratégia testovania je súbor pokynov, ktoré vysvetľujú koncepciu testu a určujú, ako je potrebné testovanie vykonať.
Príklad: Stratégia testovania obsahuje podrobnosti ako „Jednotlivé moduly majú testovať členovia testovacieho tímu“. V takom prípade na tom, kto to otestuje, nezáleží - je to teda všeobecné a zmena člena tímu sa nemusí aktualizovať, aby bola statická.
Dokument o stratégii testovania
Účelom testovacej stratégie je definovať testovací prístup, typy testov, testovacie prostredia a nástroje, ktoré sa majú použiť na testovanie, a podrobnosti na vysokej úrovni o tom, ako bude testovacia stratégia zosúladená s inými procesmi. Dokument stratégie testovania má byť živým dokumentom a bude sa aktualizovať **, keď získate viac jasnosti v požiadavkách, parametroch SLA, testovacom prostredí a prístupe k správe zostavenia atď.
Stratégia testovania je určená pre kompletný projektový tím, ktorý pozostáva z projektových sponzorov, obchodných MSP, vývoja aplikácií / integrácie, partnerov pre systémovú integráciu, tímov pre konverziu dát, tímov pre správu a zostavenie / vydanie, ako sú technickí vedúci, vedúci architektúry a tímy nasadenia a infraštruktúry.
** Niektorí tvrdia, že raz definovaná testovacia stratégia by sa nikdy nemala aktualizovať. Vo väčšine testovacích projektov sa zvyčajne aktualizuje podľa priebehu projektu.
Ďalej sú uvedené dôležité časti, ktoré by dokument stratégie testovania mal obsahovať:
# 1) Prehľad projektu
Táto časť sa môže začať poskytnutím prehľadu o organizácii a následným stručným opisom použitého projektu. Môže obsahovať nasledujúce podrobnosti
- Aká bola potreba projektu?
- Aké ciele projekt dosiahne?
Tabuľka skratiek: Je lepšie zahrnúť tabuľku so skratkami, s ktorou by čítačka dokumentov mohla prísť do súvislosti s odkazom na dokument.
# 2) Rozsah požiadaviek
Rozsah požiadavky môže zahŕňať rozsah aplikácie a funkčný rozsah
Rozsah aplikácie definuje testovaný systém a vplyv na systém v dôsledku novej alebo zmenenej funkčnosti. Môžu byť definované aj súvisiace systémy.
| Systém | Dopad (nová alebo zmenená funkčnosť) | Súvisiaci systém |
|---|---|---|
| Opisuje, ako testovať, kedy testovať, kto bude testovať a čo testovať. | Opisuje, aký typ techniky je potrebné dodržať a ktorý modul testovať. | |
| Systém A | Nové vylepšenia a opravy chýb | • Systém B • Systém C |
Funkčný rozsah definuje dopad na rôzne moduly v systéme. Tu bude vysvetlený každý súvisiaci systém s ohľadom na funkčnosť.
| Systém | Modul | Funkčnosť | Súvisiaci systém |
|---|---|---|---|
| Systém C. | Modul 1 | Funkčnosť 1 | Systém B |
| Funkčnosť 2 | Systém C. |
# 3) Plán testov na vysokej úrovni
Plán testov je samostatný dokument. Do stratégie testovania možno zahrnúť plán testov na vysokej úrovni. Plán testov na vysokej úrovni môže obsahovať ciele testu a rozsah testu. Rozsah testu by mal definovať aktivity rozsahu aj rozsahu.
# 4) Testovací prístup
Táto časť popisuje prístup k testovaniu, ktorý sa bude dodržiavať počas životného cyklu testovania.
Podľa vyššie uvedeného diagramu bude testovanie prebiehať v dvoch fázach, tj. Stratégia a plánovanie testu a Vykonanie testu. Fáza stratégie a plánovania testu bude pre celý program jednorazová, zatiaľ čo fázy vykonania testu sa budú opakovať pre každý cyklus celkového programu. Vyššie uvedený diagram zobrazuje rôzne fázy a výsledky (výstupy) v každej fáze prístupu k vykonávaniu.
Skúšobný prístup by mal obsahovať nasledujúce pododdiely
a) Časový plán skúšky: V tejto pododdiele vysvetlite navrhovaný harmonogram projektu
b) Prístup funkčného testovania: Pomocou tohto pododdielu získate prehľad o každej fáze a príslušných vstupných a výstupných kritériách. Rôzne fázy testovania sú testovanie jednotiek, testovanie systému, testovanie integrácie systému, testovanie akceptácie používateľov a testovanie typu end-to-end.
c) Testovanie kľúčových ukazovateľov výkonnosti:
- Priorita testovacích prípadov: Definujte prístup uprednostňovania testovacích prípadov tak, aby v prípade časových obmedzení mohol testovací tím vykonať scenáre s vysokou prioritou. Medzi zúčastnenými stranami projektu by mala existovať dohoda o možných rizikách spojených s nerealizovaním všetkých plánovaných scenárov.
- Priorita defektov: Ďalšou témou, ktorá sa tu bude zaoberať, je stratégia prioritizácie chýb. Definujte úroveň priority a popíšte jednotlivé úrovne ako kritické, vysoké, stredné atď. Tiež
- Doba obratu chyby: Čas opravy defektu je definovaný ako čas medzi tým, kedy bola chyba prvýkrát vyvolaná a kedy je chyba opravená a prichádza na opätovné testovanie. Rýchly obrat zaisťuje rýchle testovanie a dodržiavanie časovej osi projektu. Pre každú úroveň priority defektu definujte čas obratu.
| Úroveň priority | Defekt Doba obratu |
|---|---|
| 1 - Kritické | Doba odozvy: 2 hodiny alebo menej Oprava pripravená na migráciu: 1 pracovný deň alebo menej |
# 5) Test pokrytia
Táto časť popisuje procesy, ktoré bude tím QA dodržiavať pri optimalizácii pokrytia obchodných / funkčných požiadaviek v testovacích scenároch a testovacích prípadoch. Matica sledovateľnosti požiadavky: (RTM) možno použiť na vysledovanie všetkých požiadaviek s príslušnými testovacími scenármi a testovacími prípadmi.
# 6) Testovacie prostredie
Definujte rôzne dostupné prostredia zabezpečovania kvality. Uveďte, čo sa bude testovať v ktorom prostredí a kým. Vytvorte plán zálohovania prostredia, ktorý sa postará o mimoriadne situácie. Prístup do každého prostredia by mal byť regulovaný a volaný s jasnosťou.
V tejto časti je možné spomenúť aj testovacie nástroje, ktoré sa majú použiť.
| Činnosť | Nástroj | Poznámky |
|---|---|---|
| Správa testov | HP ALM | Uveďte dôvod použitia tohto nástroja |
| Manažment defektov | JIRA | Uveďte dôvod použitia tohto nástroja |
# 7) Dodávky a metriky zabezpečenia kvality
Vymenujte všetky výstupy QA
| S. č. | Doručiteľný |
|---|---|
| 1 | Dokument o stratégii testovania |
| dva | Matica sledovateľnosti požiadavky |
| 3 | Skúšobné skripty ST |
| 4 | Súhrnná správa o teste |
| 5 | Zoznam vhodných scenárov pre automatizáciu |
Vymenujte všetky metriky QA
| # | Metrický názov | Metrická definícia | Metrický vzorec | Metrická merná jednotka | Správy, v ktorých sa majú použiť metriky |
|---|---|---|---|---|---|
| 1 | Metriky pokrytia požiadaviek (RCM) | Pokrytie požiadaviek QA | Pomer # testovaných požiadaviek k # identifikovaných požiadaviek | % | Týždenná správa o stave kontroly kvality, Súhrnná správa o teste |
| dva | Pokrytie testu | Pokrytie vykonaného testovacieho prípadu | Pomer počtu vykonaných testovacích prípadov / plánovaného počtu testovacích prípadov | % | Správa o dennom vykonávaní, Týždenná správa o stave kontroly kvality, Súhrnná správa o teste |
# 8) Správa chýb
Jasne definujte stratégiu správy defektov vytvorením pracovného toku defektov, metodiky sledovania defektov a procesu triedenia defektov. Uveďte zodpovednosť za chyby v úlohách jednotlivých testerov. Periodická analýza chýb a analýza hlavných príčin zlepšia celkovú kvalitu testovania
# 9) Správa komunikácie
Stanovte pokyny pre správy o stave, schôdzky o stave a komunikáciu na mieste mimo pobrežia.
# 10) Predpoklady, riziká a závislosti
Popíšte predpoklady, na ktorých je projekt založený. Môže ísť o načasovanie, zdroje a systémové schopnosti. Popíšte akékoľvek závislosti, ako napríklad iné projekty, dostupnosť dočasných zdrojov, iné termíny, ktoré môžu mať vplyv na projekt
# 11) Príloha
V tejto časti uveďte veci ako Úlohy a zodpovednosti, Pracovné časové pásmo a Referencie
Ďalšie čítanie=> Sprievodca napísaním dokumentu Stratégia dobrého testu .
Skúšobný plán vs. Skúšobná stratégia
| SKÚŠOBNÝ PLÁN | STRATÉGIA TESTU |
|---|---|
| Je odvodený zo špecifikácie softvérových požiadaviek (SRS). | Je odvodený z dokumentu obchodných požiadaviek (BRS). |
| Pripravuje ho vedúci testu alebo manažér. | Vyvíja ho projektový manažér alebo obchodný analytik. |
| Súčasťou plánu testu sú ID testovacieho plánu, vlastnosti, ktoré sa majú testovať, testovacie techniky, testovacie úlohy, kritériá vyhovenia alebo neúspechu komponentov, výstupy testu, zodpovednosť a plán atď. | Ciele a rozsah, formáty dokumentácie, testovacie procesy, štruktúra tímových správ, komunikačná stratégia klienta atď. Sú súčasťami testovacej stratégie. |
| Ak dôjde k novej funkcii alebo k zmene v požiadavke, aktualizuje sa dokument plánu testu. | Stratégia testovania zachováva štandardy pri príprave dokumentu. Nazýva sa tiež ako statický dokument. |
| Plán testov môžeme pripraviť individuálne. | V menších projektoch sa stratégia testov často nachádza ako súčasť plánu testov. |
| Môžeme pripraviť plán testov na úrovni projektu. | Stratégiu Testovania môžeme použiť na viacerých projektoch. |
| O špecifikáciách môžeme popísať pomocou plánu testov. | Stratégia testovania popisuje všeobecné prístupy. |
| Plán skúšok sa bude v priebehu projektu meniť. | Stratégia testovania sa po schválení zvyčajne nezmení. |
| Plán testov je napísaný po odhlásení požiadavky. | Skúšobná stratégia sa zostavuje pred plánom skúšok. |
| Testovacie plány môžu byť rôznych typov. Bude existovať hlavný plán testov a samostatný plán testov pre rôzne typy testovania, ako je plán testov systému, plán testov výkonnosti atď. | Pre projekt bude existovať iba jeden dokument stratégie testovania. |
| Plán testov by mal byť jasný a stručný. | Stratégia testovania poskytuje celkové usmernenie pre daný projekt. |
Rozdiel medzi týmito dvoma dokumentmi je jemný. Stratégia testovania je statický dokument na vysokej úrovni o projekte. Na druhej strane bude plán testov určovať, čo sa má testovať, kedy a ako sa má testovať.
Ako môžem prehrať súbory SWF
Rozdiel medzi testovacím prípadom a testovacím skriptom
Podľa môjho názoru sa tieto dva pojmy dajú zameniť. Áno, hovorím, že v tom nie je žiadny rozdiel. Testovací prípad je postupnosť krokov, ktoré nám pomôžu vykonať určitý test aplikácie. Rovnaký je aj testovací skript.
Teraz existuje názorová koncepcia, že testovací prípad je termín používaný v prostredí manuálneho testovania a testovací skript sa používa v automatizovanom prostredí. To je čiastočne pravda kvôli úrovni pohodlia testerov v príslušných oblastiach a tiež kvôli tomu, ako nástroje odkazujú na testy (niekto volá testovacie skripty a niekto ich volá testovacie prípady).
Takže testovací skript aj testovací prípad sú vlastne kroky, ktoré je potrebné vykonať v aplikácii na overenie jej funkčnosti, či už manuálne alebo automatizovane.
Ďalšie čítanie=> Ako písať efektívne testovacie prípady? a Príklad šablóny testovacieho prípadu .
| TESTOVACIA SITUÁCIA | SKRIPT TESTU |
|---|---|
| Je to základný formulár na postupné testovanie žiadosti. | Po vývoji ho skript spustí viackrát, kým sa požiadavka nezmení. |
| Jedná sa o krok za krokom postup, ktorý sa používa na testovanie aplikácie | Jedná sa o súbor pokynov na automatické testovanie aplikácie. |
| Termín Testovací prípad sa používa v prostredí manuálnych testov. | Termín Test Script sa používa v prostredí automatizačného testovania. |
| Robí sa to ručne. | Robí sa to skriptovacím formátom. |
| Je vyvinutý vo forme šablón. | Je vyvinutý vo forme skriptovania. |
| Šablóna testovacieho prípadu obsahuje ID testovacieho obleku, testovacie údaje, testovací postup, skutočné výsledky, očakávané výsledky atď. | V Test Scrip môžeme na vývoj skriptu použiť rôzne príkazy. |
| Používa sa na testovanie aplikácie. | Používa sa tiež na testovanie aplikácie. |
| Príklad: Musíme overiť prihlasovacie tlačidlo v aplikácii, Tieto kroky zahŕňajú: a) Spustite aplikáciu. b) Skontrolujte, či sa tlačidlo prihlásenia zobrazuje alebo nie. | Príklad: Chceme kliknúť na tlačidlo obrázka v aplikácii. Skript obsahuje: a) Kliknite na tlačidlo Obrázok. |
Rozdiel medzi scenárom testu a podmienkou testu
Scenár testu: Je to spôsob, ako definovať všetky možné spôsoby testovania aplikácie. Je to jediné vyhlásenie, ktoré obsahuje všetky možné spôsoby testovania aplikácie.
Podmienka testu: Podmienkou testu je špecifikácia, ktorú musí tester dodržiavať pri testovaní aplikácie.
Toto je jednoriadkový ukazovateľ, ktorý testeri vytvárajú ako úvodný prechodný krok do fázy návrhu testu. Toto je väčšinou jednoriadková definícia „Čo“ budeme testovať s ohľadom na určitú vlastnosť. Na vytvorenie testovacích prípadov sú zvyčajne vstupom testovacie scenáre.
V agilných projektoch sú testovacie scenáre jedinými výstupmi návrhu testu a za nimi sa už nepíšu žiadne testovacie prípady. Scenár testu môže mať za následok viac testov.
Príklady testovacích scenárov:
- Overte, či môže správca pridať novú krajinu
- Overte, či správca môže vymazať existujúcu krajinu
- Overte, či je možné existujúcu krajinu aktualizovať
Podmienky testu sú na druhej strane konkrétnejšie. Dá sa to zhruba definovať ako cieľ / cieľ určitého testu.
Príklad skúšobného stavu: Ak by sme vo vyššie uvedenom príklade mali testovať scenár 1, môžeme otestovať nasledujúce podmienky:
- Zadajte názov krajiny ako „India“ (platný) a skontrolujte pridanie krajiny
- Zadajte medzeru a skontrolujte, či sa krajina pridá.
- V obidvoch prípadoch sú opísané konkrétne údaje a cieľ testu je oveľa presnejší.
Ďalšie čítanie=> 180+ ukážkových testovacích scenárov na testovanie webových a desktopových aplikácií.
| TESTOVACÍ SCENÁR | PODMIENKA TESTU |
|---|---|
| Toto sú jednoriadkové vyhlásenia, ktoré vysvetľujú, čo budeme testovať. | Podmienka testu popisuje hlavný cieľ testovania aplikácie. |
| Jedná sa o proces testovania aplikácie všetkými možnými spôsobmi. | Podmienky testu sú statické pravidlá, ktoré treba dodržiavať pri testovaní aplikácie. |
| Testovacie scenáre sú vstupom pre vytváranie testovacích prípadov. | Dáva hlavný cieľ otestovať aplikáciu. |
| Testovací scenár pokrýva všetky možné prípady testovania aplikácie. | Podmienka testu je veľmi konkrétna. |
| Znižuje to zložitosť. | Robí systémovú chybu zadarmo. |
| Testovacím scenárom môže byť jeden alebo skupina testovacích prípadov. | Je to cieľ testovacích prípadov. |
| Pri písaní scenárov bude ľahké pochopiť funkčnosť aplikácie. | Podmienka testu je veľmi konkrétna. |
| Príklady testovacích scenárov: # 1) Overte, či môže administrátor pridať novú krajinu. # 2) Overte, či správca môže vymazať existujúcu krajinu. # 3) Overte, či je možné aktualizovať existujúcu krajinu. | Príklady testovacích podmienok: # 1) Zadajte názov krajiny ako „India“ a skontrolujte pridanie krajiny. # 2) Nechajte prázdne polia a skontrolujte, či je krajina pridaná. |
Rozdiel medzi skúšobným postupom a skúšobnou sadou
Testovací postup je kombináciou testovacích prípadov založených na určitých logických dôvodoch, napríklad na vykonaní komplexnej situácie alebo na niečo podobné. Poradie, v ktorom sa majú testovacie prípady spustiť, je pevné.
Skúšobný postup: Nie je to nič iné ako testovací životný cyklus. V testovaní životného cyklu je 10 krokov.
Oni sú:
- Odhad úsilia
- Začatie projektu
- Štúdia systému
- Plán skúšok
- Dizajnový testovací prípad
- Automatizácia testov
- Vykonajte testovacie prípady
- Hlásiť chyby
- Regresné testovanie
- Analýza a súhrnná správa
Napríklad , ak by som mal otestovať odoslanie e-mailu z Gmail.com, poradie testovacích prípadov, ktoré by som skombinoval do jedného testovacieho postupu, by bolo:
- Test na kontrolu prihlásenia
- Test na zostavenie e-mailu
- Test na pripojenie jednej alebo viacerých príloh
- Formátovanie e-mailu požadovaným spôsobom pomocou rôznych možností
- Pridanie kontaktov alebo e-mailových adries do polí Komu, BCC, CC
- Odosielanie e-mailových správ a zaistenie ich zobrazenia v časti „Odoslaná pošta“
Všetky vyššie uvedené testovacie prípady sú zoskupené tak, aby sa na konci z nich dosiahol určitý cieľ. Testovacie postupy tiež obsahujú kombináciu niekoľkých testovacích prípadov kedykoľvek.
Testovací balík je na druhej strane zoznam všetkých testovacích prípadov, ktoré je potrebné vykonať ako súčasť testovacieho cyklu alebo regresnej fázy atď. Neexistuje logické zoskupenie založené na funkčnosti. Poradie, v akom sa vykonajú testovacie prípady, v ktorých sú zložené komponenty, môže alebo nemusí byť dôležité.
Testovacia sada: Sada testov je kontajner obsahujúci sadu testov, ktoré testerom pomáhajú pri vykonávaní a hlásení stavu vykonania testu. Môže trvať ktorýkoľvek z troch stavov, tj. Aktívny, prebieha a je dokončený.
Ukážka testovacej sady : Ak je aktuálna verzia aplikácie 2.0. Predchádzajúca verzia 1.0 mohla mať 1 000 testovacích prípadov, ktoré ju mohli úplne otestovať. Pre verziu 2 existuje 500 testovacích prípadov, ktoré slúžia iba na otestovanie novej funkčnosti, ktorá je pridaná v novej verzii.
Aktuálna testovacia sada by teda predstavovala 1 000 + 500 testovacích prípadov, ktoré zahŕňajú regresiu aj novú funkcionalitu. Sada je tiež kombináciou, ale nesnažíme sa dosiahnuť cieľovú funkciu.
Testovacie balíčky môžu obsahovať 100 alebo dokonca 1 000 testovacích prípadov.
| SKÚŠOBNÝ POSTUP | TESTOVACIA SADA |
|---|---|
| Tvorba testovacích postupov je založená na postupe testovania medzi koncovými bodmi. | Testovacie balíčky sa vytvárajú na základe cyklu alebo na základe rozsahu. |
| Jedná sa o kombináciu testovacích prípadov na otestovanie aplikácie. | Ide o skupinu testovacích prípadov na otestovanie aplikácie. |
| Jedná sa o logické zoskupenie založené na funkčnosti. | Na základe funkčnosti neexistuje logické zoskupenie. |
| Testovacie postupy sú dodávané produkty v procese vývoja softvéru. | Vykonáva sa ako súčasť testovacieho cyklu alebo regresie. |
| Poradie vykonania je pevné. | Poradie exekúcie nemusí byť dôležité. |
| Testovací postup obsahuje kompletné testovacie prípady. | Testovacia sada obsahuje všetky nové funkcie a regresné testovacie prípady. |
| Skúšobné postupy sú kódované v novom jazyku s názvom TPL (jazyk skúšobných postupov). | Sada testov obsahuje manuálne testovacie prípady alebo automatizačné skripty. |
Záver
Koncepty testovania softvéru hrajú hlavnú úlohu v životnom cykle testovania softvéru.
Jasné pochopenie vyššie diskutovaných konceptov spolu s ich porovnaním je pre každého softvérového testera veľmi dôležité pre efektívne vykonanie procesu testovania.
Články ako tieto sú zvyčajne vynikajúcim východiskom pre hlbšie diskusie. Takže, prosím, prispejte svojimi myšlienkami, dohodami, nezhodami a čímkoľvek iným do komentárov nižšie. Tešíme sa na vašu spätnú väzbu.
Uvítame tiež vaše otázky týkajúce sa testovania softvéru všeobecne alebo akýchkoľvek otázok týkajúcich sa vašej testovacej kariéry. Týmto sa budeme podrobnejšie venovať v našich pripravovaných príspevkoch z tej istej série.
Príjemné čítanie !!
=> Celý seminár s kompletným plánom testovacieho plánu nájdete tu
Výukový program PREV | NEXT Tutorial
Odporúčané čítanie
- Výukový program pre testovací plán: Sprievodca písaním dokumentu o softvérovom testovacom pláne od nuly
- Ako napísať dokument stratégie testovania (so vzorovou šablónou stratégie testovania)
- Ako sa pripraviť na písanie testovacích prípadov [Tipy pre produktivitu]
- Čo je testovací scenár: Šablóna testovacieho scenára s príkladmi
- Rozdiel medzi plánom testovania výkonnosti a stratégiou testovania výkonu
- Ako písať testovacie prípady: Najdôležitejší sprievodca s príkladmi
- Ukážka šablóny plánu testovania softvéru s formátom a obsahom
- Scenár testu Vs Testovací prípad: Aký je rozdiel medzi nimi?