Menu

Testování pokrytí při testování softwaru (tipy k maximalizaci pokrytí testování)

test coverage software testing

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

Pokrytí testu softwaru Kompletní průvodce: Jak testovat více, ušetřit čas a dosáhnout lepších výsledků testování:

Testování softwaru je základní činností v životním cyklu vývoje a údržby softwaru. Je to praxe často používaná k rozhodování a zlepšování kvality softwaru.

JMS rozhovor otázky a odpovědi pro zkušené

Vývoj je v dnešní době systematičtější a organizace hledají měřítka úplnosti a účinnosti testování, aby ukázala kritéria pro dokončení testu. Ze všech je pokrytí považováno za zvlášť cenné.

Co se naučíte:

Co je Pokrytí testu?

Jednoduše řečeno, pokrytí je „Co testujeme a kolik testujeme?“

Pokrytí testů pomáhá monitorovat kvalitu testování a pomáhá testerům vytvářet testy pokrývající oblasti, které chybí nebo nejsou ověřeny.

testovací pokrytí

Většina týmů zakládá své výpočty pokrytí pouze na funkčních požadavcích. Je to také spravedlivé, protože aplikace by v první řadě měla dělat to, co má dělat. Pokud ne, jeho rychlost, bezpečnost nebo snadné použití - na ničem z toho nezáleží.

Je-li však oddaný a nezávislý nefunkční testování týmy pracují na výkonu, zabezpečení, testování použitelnosti atd., pak budou muset sledovat své požadavky až k provedení pomocí analýzy pokrytí testů.

Vyzkoušejte pokrytí a pokrytí kódu

Pokrytí testu je často zaměňováno s Pokrytím kódu. I když jsou základní principy stejné, jedná se o dvě různé věci.

Pokrytí kódu opravdu hovoří o postupech testování jednotek, které musí alespoň jednou zacílit na všechny oblasti kódu a provádí je vývojáři.

Test Coverage na druhé straně je testování každého požadavku alespoň jednou a je zjevně aktivitou týmu QA.

To, co se skutečně kvalifikuje jako krytý požadavek, závisí na interpretaci každého týmu.

Například , Některé týmy nazývají splněný požadavek, pokud je proti němu alespoň jeden testovací případ. Někdy je kryté, pokud je k němu přiřazen alespoň jeden člen týmu. Nebo pokud jsou provedeny všechny testovací případy s ním spojené.

  • Pokud je vytvořeno 10 požadavků a 100 testů - když těchto 100 testů zacílí na všech 10 požadavků a žádné nevynechá - nazýváme to odpovídající pokrytí testováním na úrovni designu.
  • Když je provedeno pouze 80 z vytvořených testů a je zaměřeno pouze na 6 požadavků. Říkáme, že 4 požadavky nejsou pokryty, přestože je provedeno 80% testování. Toto jsou statistiky pokrytí na úrovni provádění.
  • Pokud pouze 90 testů vztahujících se k 8 požadavkům přiřadilo testery a zbytek ne, říkáme, že pokrytí testovacích úkolů je 80% (8 z 10 požadavků).

Je také důležité, kdy vypočítat pokrytí.

Pokud to uděláte příliš brzy v procesu, uvidíte spoustu mezer, protože věci jsou stále neúplné. Obecně se tedy doporučuje počkejte až do posledního sestavení tj. Sestavení konečné regrese. To zajistí správné pokrytí testů provedených pro dané požadavky.

Přečtěte si také => Proces správy vydání a nasazení

Moje zkušenost

Scéna před 8 lety: Když jsem měl 2 roky zkušeností v oboru testování softwaru, myslel jsem si, že je v pořádku, když nevím nějaké základy o testování softwaru, jako něco, co se člověk může naučit se zkušenostmi a já taky udělám.

Měl jsem pravdu - a také špatně.

Správně, protože se zkušenostmi naučíte vidět větší obrázek, pochopíte skutečný význam „Kritické situace“ a více pochopíte koncového uživatele.

Špatně, protože žádná ze zmíněných věcí nevyžaduje zkušenosti, ale včasné učení, které jsem pochopil velmi pozdě. To je povzbudivý faktor pro napsání tohoto příspěvku.

Maximalizujte pokrytí testu za kratší dobu

Zde jsou moje zkušenosti z jednoho z rozhovorů v té době:

Jak zajistíte, aby pokrytí testu bylo úplné nebo maximální? Byl jsem požádán.

Hmmmm …… ujistil jsem se, že otestuji všechny funkce , Řekl jsem.

S o říkáte, že jakmile otestujete všechny funkce, máte pocit, že jste pokryli maximum aplikace / produktu, pokud jde o testování , tazatel selhal.

Hmmm… no… .mmmm…. Ano, protože při testování všech funkcí jste si jisti chováním aplikace / produktu, Podporil jsem svou odpověď .

Souhlasím, ale moje otázka zní - dodá vám jistotu, že vaše pokrytí testováním je maximální nebo úplné? tazatel neměl náladu, aby mě nechal jít.

Teď jsem začal být netrpělivý, neznám o tom, že se chystám naučit jedno z nejdůležitějších témat o testování softwaru - ' Testovací pokrytí “ .

Spíše než reprodukovat výňatky z rozhovoru zde shrnuji, co jsem se toho dne dozvěděl o Testování pokrytí. Ale dříve to vyjasníme v jednom bodě - pokrytí testováním nikdy neznamená vědět, zda testujete dostatečně nebo ne, ani to neznamená, že testujete dokonale nebo ne.

Význam pokrytí testu

Testování pokrytí může mít v jiném kontextu jiný význam. Pojďme objevit tyto kontexty jeden po druhém:

Pokrytí produktu - Na jaké aspekty produktu jste se podívali?

bezplatný čistič nevyžádaných souborů pro Windows 7

Ano, když se měří pokrytí testováním z hlediska produktu, hlavní oblastí, na kterou se zaměřit, je - které oblasti produktu jste testovali a které zůstávají nevyzkoušené?

Příklad č. 1:

Pokud je „nůž“ produkt, testujete; nesoustřeďte se jen na to, zda zeleninu / ovoce krájí správně. Je třeba hledat i další aspekty - uživatel by to měl zvládnout pohodlně.

Příklad č. 2:

Pokud je „poznámkový blok“ aplikace, kterou testujete, je kontrola příslušných funkcí nutností.

Ale je třeba se postarat o další aspekty - aplikace reaguje správně při současném používání jiných aplikací, aplikace nepadá když se uživatel pokusí udělat něco neobvyklého , uživateli jsou poskytována správná varovná / chybová hlášení, uživatel je schopen aplikaci snadno rozumět a používat ji, v případě potřeby je k dispozici obsah nápovědy.

Pokud se na uvedené scénáře nepodíváte, nemůžete tvrdit, že testování pokrytí aplikace je kompletní.

Krytí rizik - Jaká rizika jste testovali?

Krytí rizik je dalším aspektem, který má úplné pokrytí testováním. Produkt nebo aplikaci nemůžete označit jako „testovanou“, dokud nevyzkoušíte i související rizika. Pokrytí souvisejících rizik je důležitým faktorem celkového pokrytí testování.

Příklad č. 1:

Pokud vám při testování letounu tester řekne, že plně otestoval vnitřní systém letadla a funguje dobře, během testování nebyla pokryta pouze letová schopnost letounu - jaká bude vaše reakce?

To znamená pokrytí rizik. Identifikace rizika podle aplikace / produktu a jeho důkladné otestování je vždy dobrým postupem.

Příklad č. 2:

Při testování webu elektronického obchodování tester zvážil všechny účinné faktory, ale nezohlednil riziko, že počet uživatelů vstoupí na web současně a v den Super OFFER, neuvažované riziko se ukázalo jako obrovská chyba.

Doporučené čtení =>

Pokrytí požadavků - Jaké požadavky jste testovali?

Pokud je produkt nebo aplikace vyvinuta velmi dobře, ale pokud neodpovídá požadavkům zákazníka, není k ničemu. Pokrytí požadavků při testování je stejně důležité jako pokrytí produktu.

Příklad č. 1:

Nadšení pro rodinnou funkci jste požádali krejčího, aby vám šil šaty a nasadil si na výstřih ty modré páví knoflíky.

Když šil šaty, krejčí si myslel, že uvedení těchto knoflíků na výstřih nebude vypadat dobře, a tak místo toho našel zlatě zbarvený okraj. Ve zkušební den rozhodně nešťastný zákazník křičel na krejčího, že nedodržuje požadavky.

Příklad č. 2:

Při testování chatovací aplikace se tester postaral o všechny důležité body, jako je chatování více uživatelů ve skupině, dva uživatelé chatování samostatně, všechny typy emotikonů k dispozici, aktualizace zaslané uživateli okamžitě atd., Ale zapomněl se podívat do dokumentu s požadavky, který jasně uvedl, že když dva uživatelé chatují nezávisle, měla by být povolena možnost videohovoru.

Klient uvedl na trh chatovací aplikaci a tvrdil, že umožňuje volání, zatímco dva uživatelé chatují samostatně. Dokážete si představit, co by se stalo s chatovací aplikací.

Taky číst => Jak vytvořit matici sledovatelnosti požadavků

Jak přijmout správnou metodu pokrytí testu?

Povědomí je všechno:

Nejdříve je nutné, aby tým QA věděl, kolik práce je zapotřebí a kde se nacházejí konstrukční úkoly. Tímto způsobem si uvědomí, zda mají být přidány další testy. K tomu můžete použít RTM, jak je obvyklým postupem.

=> Podívejte se na tento článek a dozvíte se o něm více a o tom, jak jej používat: Jak vytvořit matici sledovatelnosti požadavků - přesný proces se vzorovou šablonou

Za druhé zkontrolujte přiřazení prostředků a proces provádění testu zjistit, zda je vše testováno efektivnějším způsobem.

Níže uvedená tabulka může být užitečná:

Typ testuCelkem případůProvedené případyPostaveníKomentáře
Funkční1008050 přihrávek, 30 neúspěšných
Kompatibilita100padesátka45 přihrávek, 5 neúspěšných
Použitelnost10010098 přihrávky, 2 neúspěchy
Konečná regrese10010099 přihrávek, 1 neúspěch

Jak zajistit, aby bylo vše testováno?

  • Každý tester by si měl být vědom požadavků a zkušebních metod
  • Upřednostněte své požadavky a zaměřte svou energii tam, kde je to nejvíce potřeba
  • Buďte informováni o tom, jak se určité vydání liší od předchozího, abyste mohli přesněji identifikovat kritické požadavky a zaměřit se na maximální pozitivní pokrytí
  • Přizpůsobte automatizaci testů
  • Použijte nástroje pro správu testů vždy zůstat ve vědomí
  • Chytré pracovní přiřazení - Nasměrujte své nejlepší zdroje na důležité úkoly a nechte nové testery prozkoumat více pro novou perspektivu
  • Udržování a kontrolní seznam pro všechny úkoly a různé činnosti
  • Interagujte více se svými týmy Dev / Scrum / BA a získejte přehled o chování aplikace
  • Sledujte všechny své cykly sestavení a opravy
  • Identifikujte nejvíce ovlivňující problémy v počátečních sestaveních (pokud je to možné), aby ty pozdější mohly pracovat na lepší stabilitě a dosáhnout oblastí blokovaných předchozími problémy

Kritické oblasti a metody účinného testování

efektivní testování

# 1)Jumbling zdrojů: Vyměňujte si úkoly mezi členy svého týmu. To pomáhá zlepšit zapojení a zabránit koncentraci znalostí.

#dva)Krytí kompatibility: Ujistěte se, že jste si vědomi a včetně různé prohlížeče a platformy otestovat vaši aplikaci.

# 3)Vlastnictví: Dejte testerům odpovědnost a dejte jim volnou ruku (samozřejmě s monitorováním a podporou) pro modul / úkol, na kterém pracují. To pomáhá budovat odpovědnost a umožňuje jim vyzkoušet kreativní způsoby, místo aby šli po vyšlapaných cestách.

# 4)Termíny: Znalost termínů vydání před zahájením testovací fáze pomáhá při efektivním plánování

# 5)Sdělení : Zůstaňte v kontaktu s vývojářem a dalšími týmy mezi cykly vydání, abyste věděli, o co jde.

# 6)Udržujte RTM: Působí jako dobrý derivát pro Zúčastněné strany nebo klienti , na základě kterého lze potvrdit plán vydání

Výhody testování povědomí o pokrytí pro testera:

  • Primárně pomáhá s upřednostňováním úloh testování
  • Pomáhá dosáhnout 100% pokrytí požadavků nebo jinými slovy zabraňuje úniku požadavků
  • Analýza dopadů bude snazší
  • Užitečné při určování KONEC kritéria
  • Umožňuje testovacímu vodiči připravit jasné zpráva o uzavření testu

Závěr

Pokrytí testu uvedenými kontexty nekončí. Existuje mnoho dalších bodů, které je třeba vzít v úvahu při testování pokrytí.

Není vždy pravda, že když testujete více, výsledky jsou lepší. Ve skutečnosti, když budete testovat více bez zjevné strategie, pravděpodobně nakonec investujete spoustu času.

Díky strukturovanějšímu přístupu, cíli na 100% pokrytí požadavků a efektivním metodám testování nebudete dělat kompromisy v kvalitě.

Doufáme, že techniky popsané v tomto článku vám poskytnou několik rad.

jak tisknout pole řetězců v Javě pomocí smyčky for

Nalijte své komentáře a názory k příspěvku. Jako obvykle vás rádi slyšíme.

Doporučené čtení

^