7 principles software testing
Sedem princípov testovania softvéru: Vrátane ďalších podrobností o zhlukovaní chýb, Paretov princíp a paradox pesticídov.
Som si istý, že každý vie o „ Sedem princípov testovania softvéru “.
Tieto základné princípy testovania pomáhajú testovacím tímom využiť svoj čas a úsilie na zefektívnenie testovacieho procesu. V tomto článku sa podrobne dozvieme o dvoch princípoch t.j. Zhlukovanie defektov, Paretov princíp a paradox pesticídov .
Čo sa dozviete:
- Sedem princípov testovania softvéru
Sedem princípov testovania softvéru
Predtým, ako sa podrobne pozrieme na tieto dva princípy, poďme stručne pochopiť sedem princípov testovania softvéru.
Poďme preskúmať !!
# 1) Testovanie ukazuje prítomnosť chýb
Každá aplikácia alebo produkt sa uvoľní do výroby po dostatočnom testovaní rôznymi tímami alebo prechodom rôznymi fázami, ako sú napríklad Testovanie integrácie systému, Testovanie prijatia používateľa a Testovanie verzie Beta atď.
Takže už ste niekedy videli alebo počuli od niektorého z testovacích tímov, že testovali softvér úplne a že v softvéri nie je žiadna chyba ? Namiesto toho každý testovací tím potvrdzuje, že softvér spĺňa všetky obchodné požiadavky a funguje podľa potrieb koncového používateľa.
V priemysle testovania softvéru nikto nepovie, že existuje bez závady v softvéri, čo je celkom pravda, pretože testovanie nedokáže, že softvér je bezchybný alebo bezchybný.
Cieľom testovania je však nájsť čoraz viac skrytých chýb pomocou rôznych techník a metód. Testovaním sa môžu odhaliť neobjavené chyby. Ak sa nezistia žiadne chyby, neznamená to, že softvér je bez chýb.
Príklad 1 :
Zvážte bankovú aplikáciu, táto aplikácia je dôkladne testovaná a prechádza rôznymi fázami testovania, ako je SIT, UAT atď., A v súčasnosti nie sú v systéme zistené žiadne chyby.
Môže však existovať možnosť, že v produkčnom prostredí skutočný zákazník vyskúša funkčnosť, ktorá sa v bankovom systéme zriedka používa, a testéri túto funkcionalitu prehliadli, a preto sa do dnešného dňa nenašla žiadna chyba alebo sa vývojári nikdy nedotkli kódu. .
Príklad 2:
V televízii sme videli niekoľko reklám na mydlá, zubné pasty, práčky na ruky alebo dezinfekčné spreje atď.
Zvážte reklamu na ručné umývanie, ktorá v televízii hovorí, že ak sa použije toto konkrétne umývanie rúk, dá sa odstrániť 99% mikróbov. To jasne dokazuje, že výrobok nie je stopercentne bez choroboplodných zárodkov. V našom koncepte testovania teda môžeme povedať, že žiadny softvér nie je bezchybný.
# 2) Včasné testovanie
Testéri sa musia zapojiť v ranej fáze životného cyklu vývoja softvéru (SDLC). Takto je možné identifikovať chyby počas fázy analýzy požiadaviek alebo akékoľvek chyby dokumentácie. Náklady spojené s odstránením takýchto chýb sú v porovnaní s nákladmi zistenými v neskorších fázach testovania oveľa nižšie.
Zvážte nasledujúci obrázok, ktorý ukazuje, ako sa zvyšujú náklady na opravu defektov, keď sa testovanie posúva k živej produkcii.
[obrázok zdroj ]
Vyššie uvedený obrázok ukazuje, že náklady na opravu defektu zisteného počas analýzy požiadaviek sú nižšie a s pribúdajúcimi fázami testovania alebo údržby sa neustále zvyšujú.
Otázka teraz znie ako skoro by malo začať testovanie ?
Po dokončení požiadaviek je potrebné zapojiť testerov do testovania. Testovanie by sa malo vykonávať na dokumentoch s požiadavkami, špecifikácii alebo na akomkoľvek inom type dokumentu, aby bolo možné v prípade nesprávneho definovania požiadaviek okamžite opraviť tieto chyby vo fáze vývoja.
# 3) Vyčerpávajúce testovanie nie je možné
Počas skutočného testovania nie je možné vyskúšať všetky funkcie so všetkými platnými a neplatnými kombináciami vstupných údajov. Namiesto tohto prístupu sa zvažuje testovanie niekoľkých kombinácií na základe priority pomocou rôznych techník.
Vyčerpávajúce testovanie bude vyžadovať neobmedzené úsilie a väčšina z nich je neúčinná. Časové osi projektu taktiež neumožnia testovanie toľkého počtu kombinácií. Z tohto dôvodu sa odporúča testovať vstupné údaje pomocou rôznych metód, ako sú napríklad rozdelenie ekvivalencie a analýza hraničných hodnôt.
Napríklad ,Ak predpokladáme, že máme vstupné pole, ktoré prijíma iba abecedy, špeciálne znaky a čísla od 0 do 1 000. Predstavte si, koľko kombinácií by sa objavilo na testovanie, nie je možné vyskúšať všetky kombinácie pre každý typ vstupu.
Testovacie úsilie potrebné na testovanie bude obrovské a bude mať tiež vplyv na časovú os projektu a náklady. Preto sa vždy hovorí, že vyčerpávajúce testovanie nie je prakticky možné.
# 4) Testovanie je závislé od kontextu
Na trhu je k dispozícii niekoľko domén, ako sú bankovníctvo, poisťovníctvo, zdravotníctvo, cestovanie, reklama atď., A každá doména má množstvo aplikácií. Aj pre každú doménu majú ich aplikácie odlišné požiadavky, funkcie, iný účel testovania, riziká, techniky atď.
Rôzne domény sa testujú rôzne, testovanie je teda čisto založené na kontexte domény alebo aplikácie.
Napríklad ,testovanie bankovej aplikácie sa líši od testovania akejkoľvek aplikácie elektronického obchodu alebo reklamy. Riziko spojené s každým typom aplikácie je odlišné, a preto nie je efektívne testovať všetky typy aplikácií rovnakou metódou, technikou a typom testovania.
# 5) Zhlukovanie defektov
Počas testovania sa môže stať, že väčšina nájdených chýb súvisí s malým počtom modulov. Môže to mať niekoľko príčin, napríklad moduly môžu byť zložité, kódovanie súvisiace s týmito modulmi môže byť komplikované atď.
Toto je Paretov princíp testovania softvéru, kde sa 80% problémov nachádza v 20% modulov. Viac o zhlukovaní chýb a Paretovom princípe sa dozvieme ďalej v tomto článku.
# 6) Pesticídový paradox
Princíp Pesticide Paradox hovorí, že ak sa v danom časovom období opakovane vykonáva rovnaká sada testovacích prípadov, potom táto sada testov nie je schopná identifikovať nové chyby v systéme.
Na prekonanie tohto „paradoxu pesticídov“ je potrebné súbor testovacích prípadov pravidelne prehodnocovať a revidovať. V prípade potreby je možné pridať novú sadu testovacích prípadov a existujúce testovacie prípady môžu byť odstránené, ak nie sú schopné nájsť ďalšie chyby systému.
# 7) Absencia chyby
Ak je softvér plne otestovaný a ak pred jeho vydaním nenájdete žiadne chyby, môžeme povedať, že softvér je z 99% bez chýb. Čo však v prípade, ak je tento softvér testovaný na nesprávne požiadavky? V takýchto prípadoch by nepomohlo ani nájdenie defektu a jeho včasné odstránenie, pretože testovanie sa vykonáva na nesprávnych požiadavkách, ktoré nie sú podľa potrieb koncového používateľa.
Napríklad, Predpokladajme, že aplikácia súvisí s webom elektronického obchodu a požiadavkami na funkčnosť nákupného košíka alebo nákupného košíka, ktoré sú nesprávne interpretované a testované. Tu ani nájdenie ďalších chýb nepomôže presunúť aplikáciu do ďalšej fázy alebo do produkčného prostredia.
Toto je sedem princípov testovania softvéru.
Poďme to preskúmať Zhlukovanie defektov, Paretov princíp a paradox pesticídov v detail .
Zhlukovanie defektov
Pri testovaní ľubovoľného softvéru sa testéri väčšinou stretnú so situáciou, v ktorej väčšina zistených chýb súvisí s niektorými konkrétnymi funkciami a zvyšok funkcií bude mať nižší počet chýb.
Zhlukovanie chýb znamená malý počet modulov obsahujúcich väčšinu chýb. Poruchy nie sú v zásade distribuované rovnomerne v celej aplikácii, skôr sú chyby koncentrované alebo centralizované v dvoch alebo troch funkciách.
Niekedy je to možné kvôli zložitosti aplikácie, kódovanie môže byť zložité alebo zložité, vývojár môže urobiť chybu, ktorá môže mať vplyv iba na konkrétnu funkčnosť alebo modul.
Zhlukovanie defektov je založené na „ Paretov princíp ”, Ktorý je tiež známy ako 80-20 pravidlo . To znamená, že 80% nájdených chýb je spôsobených 20% modulov v aplikácii. Koncept Paretovho princípu bol pôvodne definovaný talianskym ekonómom - Vilfrodo Pareto .
Ak sa testéri pozriú na 100 chýb, potom nebude zrejmé, či existuje nejaký základný význam proti týmto 100 chybám. Ale ak je týchto 100 defektov kategorizovaných podľa určitých konkrétnych kritérií, potom je možné, aby testéri pochopili, že veľké množstvo defektov patrí len k veľmi málo konkrétnym modulom.
Napríklad ,uvažujme nižšie uvedený obrázok, ktorý je testovaný pre jednu z bankových aplikácií a ukazuje, že väčšina chýb súvisí s funkciou „Kontokorentný úver“. Zvyšok funkcií, ako je súhrn účtu, prevod prostriedkov, trvalý pokyn atď., Má obmedzený počet chýb.
[obrázok zdroj ]
Vyššie uvedený obrázok uvádza, že okolo funkčnosti Kontokorentu je 18 chýb z celkových 32 chýb, čo znamená, že 60% chýb je zistených v module „Prečerpanie“.
Testéri sa preto počas vykonávania sústredia väčšinou na túto oblasť, aby našli ďalšie a ďalšie chyby. Počas testovania sa odporúča, aby sa testery podobným spôsobom zameriavali aj na ostatné moduly.
Keď sa testuje rovnaký kód alebo modul, znova a znova, s použitím sady testovacích prípadov ako počas počiatočných iterácií, je počet chýb vysoký, po určitej iterácii sa však počet chýb významne zníži. Zhlukovanie defektov naznačuje, že oblasť náchylnú na chyby sa má počas regresného testovania dôkladne otestovať.
Paradox pesticídov
Ak sa zistí, že jeden z modulov má viac defektov, testéri vyvinuli ďalšie úsilie na otestovanie tohto modulu.
Po niekoľkých iteráciách testovania sa kvalita kódu zlepší a počet chýb začne klesať, pretože väčšinu chýb opraví vývojový tím, pretože vývojári sú tiež opatrní pri kódovaní konkrétneho modulu, kde testeri našli viac chýb.
Preto je v jednom okamihu väčšina chýb zistená a opravená tak, aby sa v danom module nenašli žiadne nové chyby.
Občas sa však môže stať, že pri mimoriadnej opatrnosti počas kódovania na jednom konkrétnom module (v našom prípade „ Kontokorentný úver ”Modul), môže vývojár zanedbať ostatné moduly, aby ho správne kódoval, alebo zmeny vykonané v tomto konkrétnom module môžu mať negatívny dopad na ďalšie funkcie, ako sú súhrn účtov, prevod prostriedkov a trvalé pokyny.
Keď testéri používajú rovnakú sadu testovacích prípadov na vykonanie modulu, kde sa nachádza väčšina chýb (modul Prečerpanie účtu), potom po odstránení týchto chýb vývojármi nie sú tieto testovacie prípady veľmi efektívne na nájdenie nových chýb. Na konci procesu prečerpania je modul dôkladne testovaný a vývojári tiež opatrne napísali kód pre tento modul.
Tieto testovacie prípady je potrebné revidovať a aktualizovať. Je tiež dobré pridať nové testovacie prípady, aby bolo možné nájsť nové a ďalšie chyby v rôznych oblastiach softvéru alebo aplikácií.
Preventívne metódy paradoxu pesticídov
Existujú dve možnosti, ako môžeme zabrániť Pesticide Paradox, ako je uvedené nižšie:
do) Napíšte novú sadu testovacích prípadov, ktoré sa zamerajú na inú oblasť alebo moduly (iné ako predchádzajúci modul náchylný na chyby - Príklad: „Prečerpanie“) softvéru.
b) Pripravte nové testovacie prípady a pridajte ich k existujúcim testovacím prípadom.
V „ metóda A ”, Testéri môžu nájsť ďalšie chyby v ostatných moduloch, na ktoré sa počas predchádzajúceho testovania nezamerali alebo vývojári neboli pri kódovaní nijako zvlášť opatrní.
V našom príklade uvedenom vyššie môžu testeri pomocou novej sady testovacích prípadov nájsť ďalšie chyby v moduloch Súhrn účtu, Prevod prostriedkov alebo Trvalé pokyny.
Môže sa ale stať, že testéri môžu zanedbať predchádzajúci modul ( Príklad: „Prečerpanie“), kde sa väčšina chýb zistila v staršej iterácii, čo by mohlo predstavovať riziko, pretože do tohto modulu (Prečerpanie) mohli byť po kódovaní ostatných modulov vložené nové chyby.
V „ metóda B ”, Sú pripravené nové testovacie prípady, aby sa vo zvyšných moduloch našli nové potenciálne chyby.
Tu v našom príklade budú novovytvorené testovacie prípady schopné pomôcť pri identifikácii chýb v moduloch, ako sú súhrn účtov, prevod prostriedkov a trvalé pokyny. Testéri však nemôžu ignorovať predchádzajúce moduly náchylné na chyby ( Príklad: „Prečerpanie“), pretože tieto nové testovacie prípady sa spájajú s existujúcimi testovacími prípadmi.
Existujúce testovacie prípady boli viac zamerané na modul „Prečerpanie“ a nové testovacie prípady boli zamerané na ďalšie moduly. Preto sa všetky súbory testovacích prípadov vykonajú najmenej raz, dokonca aj pri zmene kódu na ktoromkoľvek module. To zabezpečí, že sa vykoná správna regresia a bude možné identifikovať chybu v dôsledku tejto zmeny kódu.
Pri použití druhého prístupu sa celkový počet testovacích prípadov výrazne zvyšuje a vedie k väčšiemu úsiliu a času potrebnému na vykonanie. To bude mať zjavný dopad na časové harmonogramy projektu a hlavne na rozpočet projektu.
Na prekonanie tohto problému je preto možné nadbytočné testovacie prípady preskúmať a potom ich odstrániť. Existuje veľa testovacích prípadov, ktoré sa stanú nepoužiteľnými po pridaní nových testovacích prípadov a úprave existujúcich testovacích prípadov.
Je potrebné skontrolovať, ktoré testovacie prípady zlyhali, aby sme mohli identifikovať chyby v posledných 5 iteráciách (predpokladajme 5 iterácií) a ktoré testovacie prípady nie sú príliš dôležité. Môže sa tiež stať, že jediný prietok pokrytý v niekoľkých testovacích prípadoch môže byť pokrytý v iných testovacích prípadoch typu end-to-end a tie testovacie prípady, ktoré majú jediný tok, môžu byť odstránené.
To zase zníži celkový počet testovacích prípadov.
Napríklad ,máme 50 testovacích prípadov na pokrytie jedného konkrétneho modulu a videli sme, že z týchto 50 testovacích prípadov 20 testovacích prípadov nedokázalo zistiť novú chybu v posledných niekoľkých testovacích iteráciách (predpokladajme 5 iterácií). Týchto 20 testovacích prípadov je preto potrebné dôkladne preskúmať a musíme skontrolovať, aké dôležité sú tieto testovacie prípady, a podľa toho môžeme rozhodnúť, či si týchto 20 testovacích prípadov ponecháme alebo ich odstránime.
Pred odstránením ktoréhokoľvek testovacieho prípadu overte, či tok funkčnosti pokrytý v týchto testovacích prípadoch je zahrnutý v inom testovacom prípade. Tento proces je potrebné dodržiavať vo všetkých moduloch, aby sa významne znížil celkový počet testovacích prípadov. Takto sa zabezpečí zníženie celkového počtu testovacích prípadov, ale stále existuje 100% pokrytie požiadaviek.
Znamená to, že všetky zostávajúce testovacie prípady pokrývajú všetky obchodné požiadavky, a teda neexistuje žiadny kompromis v oblasti kvality.
Záver
Testovanie softvéru je základným krokom v SDLC, pretože overuje, či softvér funguje tak, ako to koncový používateľ potrebuje, alebo nie.
Testovaním sa zistí čo najviac defektov. Preto, aby bolo možné testovanie vykonávať efektívne a efektívne, mal by si každý byť vedomý a skutočne rozumieť siedmim princípom testovania softvéru jasne tak, ako sú známe ako piliere testovania.
Väčšina testerov tieto princípy implementovala a vyskúšala počas skutočného testovania.
ako otvoriť súbor .apk v systéme Windows
Pojem princíp vo všeobecnosti znamená pravidlá alebo zákony, ktoré je potrebné dodržiavať. Preto každý v priemysle testovania softvéru musí dodržiavať týchto sedem princípov. Ak niekto ignoruje ktorýkoľvek z týchto princípov, môže to projekt stáť obrovské peniaze.
Príjemné čítanie !!
Odporúčané čítanie
- Najlepšie nástroje na testovanie softvéru 2021 [QA Test Automation Tools]
- Úloha pomocníka QA pri testovaní softvéru
- Kurz testovania softvéru: Do ktorého inštitútu pre testovanie softvéru by som sa mal pripojiť?
- Ako svoju kariéru si zvolíte testovanie softvéru
- Práca na voľnej nohe pre spisovateľa technického obsahu, ktorý testuje softvér
- Čo je technika testovania na základe chýb?
- Niektoré zaujímavé otázky týkajúce sa testovania softvéru
- Spätná väzba a recenzie na kurz testovania softvéru