Menu

Testovanie pokrytia pri testovaní softvéru (Tipy na maximalizáciu pokrytia testovania)

test coverage software testing

Pokrytie testu softvéru Testovací sprievodca: Ako testovať viac, ušetriť čas a dosiahnuť lepšie výsledky testovania:

Testovanie softvéru je podstatnou činnosťou v životných cykloch vývoja a údržby softvéru. Je to prax často používaná pri rozhodovaní a zlepšovaní kvality softvéru.

Vývoj je v dnešnej dobe systematickejší a organizácie hľadajú opatrenia na úplnosť a účinnosť testovania, aby preukázali kritériá na dokončenie testu. Z nich je pokrytie považované za zvlášť cenné.

Čo sa dozviete:

Čo je pokrytie testom?

Zjednodušene povedané, pokrytie je „Čo testujeme a koľko testujeme?“

Pokrytie testom pomáha monitorovať kvalitu testovania a pomáha testerom vytvárať testy, ktoré pokrývajú oblasti, ktoré chýbajú alebo nie sú overené.

pokrytie testom

Väčšina tímov vychádza pri výpočtoch pokrytia iba z funkčných požiadaviek. Je to tiež spravodlivé, pretože v prvom rade by aplikácia mala robiť to, čo má. Ak nie, jeho rýchlosť, bezpečnosť alebo jednoduché použitie - na ničom nezáleží.

Ak je však oddaný a nezávislý nefunkčné testovanie tímy pracujú na výkone, zabezpečení, testovaní použiteľnosti atď., potom budú musieť sledovať svoje požiadavky až po vykonanie prostredníctvom analýzy pokrytia testom.

Testujte pokrytie a pokrytie kódu

Pokrytie testu je často zamieňané s Pokrytím kódu. Aj keď sú základné princípy rovnaké, jedná sa o dve odlišné veci.

Pokrytie kódu skutočne hovorí o postupoch testovania jednotiek, ktoré musia aspoň raz zacieliť na všetky oblasti kódu, a robia ich vývojári.

Test Coverage na druhej strane je testovanie každej požiadavky aspoň raz a je zjavnou aktivitou tímu QA.

To, čo sa skutočne kvalifikuje ako splnená požiadavka, závisí od interpretácie každého tímu.

Napríklad , Niektoré tímy označia požiadavku za splnenú, ak je proti nej aspoň jeden testovací prípad. Niekedy je pokrytá, ak je k nej priradený aspoň jeden člen tímu. Alebo ak sa vykonajú všetky súvisiace testovacie prípady.

  • Ak je vytvorených 10 požiadaviek a 100 testov - keď sa týchto 100 testov zameriava na všetkých 10 požiadaviek a nevynechá žiadne - nazývame to adekvátne pokrytie testovaním na úrovni návrhu.
  • Keď sa vykoná iba 80 z vytvorených testov a zamerajú sa iba na 6 požiadaviek. Hovoríme, že 4 požiadavky nie sú pokryté, aj keď je vykonaných 80% testovania. Toto je štatistika pokrytia na úrovni vykonávania.
  • Ak iba 90 testov týkajúcich sa 8 požiadaviek priradilo testerov a zvyšok nie, hovoríme, že pokrytie testovacích úloh je 80% (8 z 10 požiadaviek).

Je tiež dôležité, kedy je potrebné vypočítať pokrytie.

Ak to urobíte príliš skoro v procese, uvidíte veľké medzery, pretože veci sú stále neúplné. Všeobecne sa preto odporúča počkajte do poslednej stavby tj. Konečná regresná zostava. Takto získate správne pokrytie Testov vykonaných pre dané Požiadavky.

Prečítajte si tiež => Proces riadenia vydania a nasadenia

Moje skúsenosti

Scéna pred 8 rokmi: Keď som mal 2 roky skúseností v priemysle testovania softvéru, myslel som si, že je v poriadku, ak nepoznám nejaké základy testovania softvéru, čo sa dá naučiť človekom so skúsenosťami a urobím to aj ja.

Mal som pravdu - a tiež som sa mýlil.

Správne, pretože so skúsenosťami sa naučíte vidieť väčší obraz, pochopíte skutočný význam „Kritickej situácie“ a pochopíte viac koncového používateľa.

Omyl, pretože žiadna zo spomenutých vecí nevyžaduje skúsenosti, ale skoré učenie, ktoré som pochopil veľmi neskoro. To je povzbudivý faktor pre napísanie tohto príspevku.

Maximalizujte pokrytie testu za kratší čas

Tu sú moje skúsenosti z jedného z vtedajších rozhovorov:

Ako zaistíte, aby pokrytie testu bolo úplné alebo maximálne? Opýtali sa ma.

Hmmmm …… uistil som sa, že otestujem každú funkčnosť , Povedal som.

S o hovoríte, že akonáhle otestujete všetky funkcionality, máte pocit, že ste z hľadiska testovania pokryli maximum aplikácie / produktu , opýtal sa anketár.

Hmmm ... no ... .ummm .... áno, pretože keď vyskúšate všetky funkcie, máte istotu v správaní sa aplikácie / produktu, Podporil som svoju odpoveď .

Súhlasím, ale moja otázka znie - dodá vám istotu, že vaše testovacie pokrytie je maximálne alebo úplné? anketár nemal náladu ma pustiť.

Teraz som začal byť netrpezlivý, neznámy o tom, že sa chystám naučiť jednu z najdôležitejších tém o testovaní softvéru - „ Test pokrytia “ .

Namiesto reprodukcie úryvkov z rozhovoru tu zhŕňam, čo som sa v ten deň dozvedel o testovacom pokrytí. Ale predtým to vyjasnime v jednom bode - pokrytie testovaním nikdy neznamená vedieť, či testujete dosť alebo nie, neznamená to, že testujete dokonale alebo nie.

Význam pokrytia testu

Testovacie pokrytie môže mať v rôznych súvislostiach iný význam. Poďme tieto kontexty objaviť po jednom:

Produktové pokrytie - Na ktoré aspekty produktu ste sa pozreli?

Áno, keď sa meria pokrytie testovaním z hľadiska produktu, hlavnou oblasťou, na ktorú sa treba zamerať, je - ktoré oblasti produktu ste testovali a ktoré zostávajú nevyskúšané?

Príklad č. 1:

Ak je „nôž“ produktom, testujete; nesústreďte sa len na to, či správne krája zeleninu / ovocie. Je potrebné hľadať ďalšie aspekty, ako napríklad - používateľ by mal byť schopný zaobchádzať s ním pohodlne.

otázky týkajúce sa manuálneho testovania po dobu 4 rokov

Príklad č. 2:

Ak je „poznámkový blok“ aplikácia, ktorú testujete, kontrola relevantných funkcií je nevyhnutnosťou.

Ale je potrebné dbať na ďalšie aspekty - aplikácia reaguje správne pri súčasnom používaní ďalších aplikácií, nedochádza k jej zlyhaniu keď sa používateľ pokúsi urobiť niečo neobvyklé , užívateľovi sú poskytované správne varovné / chybové správy, užívateľ je schopný aplikácii porozumieť a ľahko ju používať, v prípade potreby je k dispozícii obsah pomocníka.

Ak sa nepodívate na uvedené scenáre, nemôžete tvrdiť, že testovacie pokrytie aplikácie je úplné.

Krytie rizík - na aké riziká ste sa testovali?

Krytie rizika je ďalším aspektom úplného pokrytia testovaním. Produkt alebo aplikáciu nemôžete označiť ako „testované“, kým nevyskúšate aj súvisiace riziká. Krytie súvisiacich rizík je dôležitým faktorom pri celkovom testovaní krytia.

Príklad č. 1:

Ak vám tester pri testovaní letúna povie, že plne otestoval vnútorný systém letúna a je v poriadku, počas testovania nebola pokrytá iba letová schopnosť letúna - aká by bola vaša reakcia?

To je to, čo znamená krytie rizika. Identifikácia rizika podľa aplikácie / produktu a jeho dôkladné otestovanie je vždy dobrým zvykom.

Príklad č. 2:

Pri testovaní webu elektronického obchodu tester bral do úvahy všetky účinné faktory, ale nezohľadňoval riziko, že počet používateľov vstúpi na web súčasne a v deň super ponuky, sa nepovažované riziko ukázalo ako obrovská chyba.

Odporúčané čítanie =>

Pokrytie požiadaviek - Aké požiadavky ste testovali?

Ak je produkt alebo aplikácia vyvinutá veľmi dobre, ale ak nezodpovedá požiadavkám zákazníka, potom sú nepoužiteľné. Pokrytie požiadaviek pri testovaní je rovnako dôležité ako pokrytie produktu.

Príklad č. 1:

Nadšení pre rodinnú funkciu ste požiadali krajčíra, aby vám šil šaty a na výstrih si nasadil tie pávovo modré výstavné gombíky.

Počas prešívania šiat si krajčír myslel, že uvedenie týchto gombíkov na výstrih nebude vyzerať dobre, a preto namiesto nich prešil zlatistý okraj. V skúšobný deň rozhodne nešťastný zákazník na krajčíra zakričal, že nedodržiava požiadavky.

Príklad č. 2:

Počas testovania chatovacej aplikácie sa tester postaral o všetky dôležité body, ako napríklad chatovanie viacerých používateľov v skupine, dvaja používatelia chatovania nezávisle, všetky dostupné typy emotikonov, aktualizácie odoslané používateľovi okamžite atď., Ale zabudol sa pozrieť do dokumentu s požiadavkami, ktorý jasne uviedol, že keď dvaja používatelia chatujú nezávisle, mala by byť povolená možnosť videohovoru.

Klient uviedol na trh chatovú aplikáciu s tvrdením, že umožňuje volanie, zatiaľ čo dvaja používatelia chatujú nezávisle. Môžete si predstaviť, čo by sa stalo s aplikáciou na rozhovor.

Tiež čítať => Ako vytvoriť maticu sledovateľnosti požiadaviek

Ako prijať správnu metódu pokrytia testu?

Povedomie je všetko:

Najdôležitejšie je, že tím QA musí vedieť, koľko práce to vyžaduje a kde sa nachádzajú dizajnérske úlohy. Týmto spôsobom budú informovaní, ak majú byť pridané ďalšie testy. K tomu môžete použiť RTM, ako je obvyklým zvykom.

=> V tomto článku nájdete ďalšie informácie o ňom a o tom, ako ho používať: Ako vytvoriť maticu sledovateľnosti požiadaviek - presný proces so vzorovou šablónou

Po druhé, skontrolujte priradenie zdrojov a proces vykonania testu aby sme zistili, či je všetko testované efektívnejšie.

Môže vám pomôcť tabuľka uvedená nižšie:

Typ testuCelkový počet prípadovVykonané prípadyPostaveniePripomienky
Funkčné1008050 prihrávok, 30 neúspešných
Kompatibilita100päťdesiat45 prihrávok, 5 neúspešných
Použiteľnosť10010098 prihrávok, 2 zlyhanie
Záverečná regresia10010099 prihrávok, 1 chyba

Ako zabezpečiť, aby bolo všetko otestované?

  • Každý tester by mal poznať požiadavky a testovacie metódy
  • Stanovte priority svojim požiadavkám a zamerajte svoju energiu tam, kde je to najviac potrebné
  • Buďte informovaní o tom, ako sa určité vydanie líši od predchádzajúceho, aby ste mohli presnejšie identifikovať kritické požiadavky a zamerať sa na maximálne pozitívne pokrytie
  • Prispôsobiť automatizáciu testov
  • Používajte nástroje na správu testov vždy zostať v povedomí
  • Inteligentné pracovné zadanie - nasmerujte svoje najlepšie zdroje na kritické úlohy a nechajte nových testerov preskúmať viac pre novú perspektívu
  • Udržiavanie a kontrolný zoznam pre všetky úlohy a rôzne činnosti
  • Interagujte viac so svojimi tímami Dev / Scrum / BA a získajte prehľad o správaní aplikácie
  • Sledujte všetky svoje cykly a opravy
  • Identifikujte najviac ovplyvňujúce problémy v počiatočných zostaveniach (ak je to možné), aby neskoršie mohli pracovať na lepšej stabilite a dosiahnuť oblasti blokované predchádzajúcimi problémami

Kritické oblasti a metódy efektívneho testovania

efektívne testovanie

# 1)Žmurkanie zdrojov: Vymieňajte si úlohy medzi členmi vášho tímu. To pomáha zlepšovať zapojenie a zabrániť koncentrácii vedomostí.

#dva)Krytie kompatibility: Uistite sa, že viete a vrátane rôzne prehliadače a platformy na otestovanie vašej žiadosti.

# 3)Vlastníctvo: Dajte testerom zodpovednosť a dajte im voľnú ruku (samozrejme s monitorovaním a podporou) pre modul / úlohu, na ktorej pracujú. To pomáha budovať zodpovednosť a umožňuje im vyskúšať kreatívne spôsoby namiesto toho, aby sledovali vyšliapané cesty.

# 4)Termíny: Poznanie termínov vydania pred začatím testovacej fázy pomáha pri efektívnom plánovaní

# 5)Komunikácia : Zostaňte v kontakte s vývojármi a ďalšími tímami medzi cyklami vydania, aby ste vedeli, o čo ide.

# 6)Udržiavajte RTM: Pôsobí ako dobrý derivát pre Zainteresované strany alebo klienti , na základe ktorých je možné potvrdiť plán vydania

Výhody testovania povedomia o pokrytí pre testera:

  • Primárne pomáha pri stanovovaní priorít testovacích úloh
  • Pomáha dosiahnuť 100% pokrytie požiadaviek alebo inými slovami zabraňuje úniku požiadaviek
  • Analýza dopadov sa stáva ľahším
  • Užitočné pri určovaní Kritériá EXIT
  • Umožňuje testovaciemu vodičovi pripraviť jasný signál správa o uzavretí testu

Záver

Pokrytie testom sa spomínanými kontextmi nekončí. Pri testovaní pokrytia by sa malo brať do úvahy ešte veľa ďalších vecí.

ako otvoriť súbor .jar s Java

Nie vždy platí, že keď testujete viac, výsledky sú lepšie. V skutočnosti, keď budete testovať viac bez zjavnej stratégie, pravdepodobne budete nakoniec investovať veľa času.

Pri štruktúrovanejšom prístupe, zameraní na 100% pokrytie požiadaviek a efektívnych metód testovania, nebudete robiť kompromisy v kvalite.

Dúfame, že techniky uvedené v tomto článku vám poskytnú niekoľko rád.

Nalejte svoje komentáre a názory na príspevok. Ako obvykle, radi vás počujeme.

Odporúčané čítanie

^