TechCodeview

Plán testování je podrobný dokument, který popisuje oblasti a činnosti testování softwaru. Popisuje testovací strategii, cíle, harmonogram testování, požadované zdroje (lidské zdroje, software a hardware), odhad testu a výsledky testu.

Testovací plán je základem testování každého softwaru. Je to nejdůležitější činnost, která zajišťuje dostupnost všech seznamů plánovaných činností ve vhodném pořadí.

Plán testování je šablonou pro provádění činností testování softwaru jako definovaného procesu, který je plně monitorován a řízen manažerem testování. Plán testování připravuje vedoucí testu (60 %), manažer testu (20 %) a testovací technik (20 %).

Typy zkušebního plánu

Existují tři typy zkušebního plánu

• Hlavní testovací plán
• Plán fázových testů
• Zkušební plány specifické pro typ testování

Hlavní testovací plán

Master Test Plan je typ plánu testování, který má více úrovní testování. Zahrnuje kompletní testovací strategii.

Plán fázových testů

Fázový testovací plán je typ testovacího plánu, který se zabývá kteroukoli fází testovací strategie. Například seznam nástrojů, seznam testovacích případů atd.

Specifické testovací plány

Specifický testovací plán určený pro hlavní typy testování, jako je bezpečnostní testování, zátěžové testování, testování výkonu atd. Jinými slovy, specifický testovací plán určený pro nefunkční testování.

Jak napsat testovací plán

Vytvoření plánu testování je nejdůležitějším úkolem procesu řízení testu. Podle IEEE 829 postupujte podle následujících sedmi kroků k přípravě plánu testování.

• Nejprve analyzujte strukturu a architekturu produktu.
• Nyní navrhněte testovací strategii.
• Definujte všechny cíle testu.
• Definujte testovací oblast.
• Definujte všechny použitelné zdroje.
• Naplánujte si všechny aktivity vhodným způsobem.
• Určete všechny výsledky testu.

Komponenty nebo atributy testovacího plánu

Testovací plán se skládá z různých částí, které nám pomáhají odvodit celou testovací činnost.

Cíle: Skládá se z informací o modulech, funkcích, testovacích datech atd., které udávají cíl aplikace, tedy chování aplikace, cíl atd.

Rozsah: Obsahuje informace, které je třeba testovat s příslušnou aplikací. Rozsah lze dále rozdělit na dvě části:

• V rozsahu
• Mimo rozsah

V rozsahu: Toto jsou moduly, které je třeba důkladně (podrobně) testovat.

Mimo rozsah: Jedná se o moduly, které není třeba přísně testovat.

Například , Předpokládejme, že máme k testování aplikaci Gmail, kde funkce k testování jako Psaní pošty, odeslaných položek, doručené pošty, konceptů a funkce, které nebyly testovány jako Pomoc , a tak dále, což znamená, že ve fázi plánování rozhodneme, zda kterou funkcionalitu je třeba zkontrolovat či nikoli, na základě časového limitu uvedeného v produktu.

Nyní jak se rozhodneme, které funkce nebudou testovány?

Máme následující aspekty, kde se můžeme rozhodnout, která funkce nebude testována:

• Jak vidíme výše Pomoc funkce nebudou testovány, protože je napsán a vyvinut technickým autorem a zkontrolován jiným profesionálním autorem.
• Předpokládejme, že máme jednu aplikaci, která má P, Q, R a S vlastnosti, které je třeba vyvinout na základě požadavků. Ale zde byla funkce S již navržena a používána nějakou jinou společností. Vývojový tým tedy koupí S od této společnosti a integruje se s dalšími funkcemi, jako jsou P, Q a R.

Nyní nebudeme provádět funkční testování funkce S, protože již byla použita v reálném čase. Provedeme však integrační testování a testování systému mezi funkcemi P, Q, R a S, protože nové funkce nemusí správně fungovat s funkcí S, jak můžeme vidět na obrázku níže:

• Předpokládejme, že v prvním vydání produktu budou prvky, které byly vyvinuty, jako např P, Q, R, S, T, U, V, W…..X, Y, Z . Nyní klient poskytne požadavky na nové funkce, které zlepšují produkt ve druhém vydání a nové funkce jsou A1, B2, C3, D4 a E5.

Poté zapíšeme rozsah během testovacího plánu jako

Rozsah

Vlastnosti k testování

A1, B2, C3, D4, E5 (nové funkce)

P, Q, R, S, T

java plátek

Vlastnosti, které se netestují

W…..X, Y, Z

Proto nejprve zkontrolujeme nové funkce a poté budeme pokračovat se starými funkcemi, protože to může být ovlivněno po přidání nových funkcí, což znamená, že to ovlivní i oblasti dopadu, takže provedeme jedno kolo regresního testování pro P, Q , R…, T funkce.

Metodika testu:

Obsahuje informace o provádění jiného druhu testování, jako je funkční testování, integrační testování a testování systému atd. v aplikaci. V tomto se rozhodneme, jaký typ testování; budeme provádět různé funkce na základě požadavků aplikace. A zde bychom také měli definovat, jaký druh testování použijeme v metodologii testování, aby každý, jako vedení, vývojový tým a testovací tým, snadno porozuměl, protože podmínky testování nejsou standardní.

Například, pro samostatnou aplikaci, např Adobe Photoshop , provedeme následující typy testování:

Kouřové testování → Funkční testování → Integrační testování → Systémové testování → Adhoc testování → Testování kompatibility → Regresní testování → Globalizační testování → Testování přístupnosti → Testování použitelnosti → Testování spolehlivosti → Testování obnovy → Testování instalace nebo odinstalace

A předpokládejme, že to musíme otestovat https://www.jeevansathi.com/ aplikace, takže provedeme následující typy testování:

Přístup

Tento atribut se používá k popisu toku aplikace při provádění testování a pro budoucí použití.

Toku aplikace můžeme porozumět pomocí níže uvedených aspektů:

Napsáním scénářů na vysoké úrovni Napsáním průtokového grafu

Napsáním scénářů na vysoké úrovni

Například , předpokládejme, že testujeme Gmail aplikace:

• Přihlaste se do Gmailu – odešle e-mail a zkontrolujte, zda je na stránce Odeslaná pošta
• Přihlásit se do …….
• ……
• ……..

Píšeme to proto, abychom popsali přístupy, které je třeba použít pro testování produktu a pouze pro kritické funkce, kde budeme psát scénáře na vysoké úrovni. Zde se nezaměříme na pokrytí všech scénářů, protože konkrétní testovací technik může rozhodnout o tom, které funkce je třeba otestovat nebo ne.

Napsáním průtokového grafu

Vývojový graf je napsán, protože psaní scénářů na vysoké úrovni zabere trochu času, jak můžeme vidět na obrázku níže:

Vytváříme vývojové grafy, abychom získali následující výhody, jako jsou:

• Pokrytí je snadné
• Sloučení je snadné

Přístup lze rozdělit do dvou částí, které jsou následující:

• Přístup shora dolů
• Přístup zdola nahoru

Předpoklad

Obsahuje informace o problému nebo problému, který se mohl vyskytnout během testovacího procesu a když píšeme testovací plány, budou vytvořeny zajištěné předpoklady jako zdroje a technologie atd.

Riziko

Toto jsou výzvy, kterým musíme čelit při testování aplikace v aktuálním vydání, a pokud předpoklady selžou, jsou s tím spojena rizika.

Například, účinek pro aplikaci se datum vydání odkládá.

Plán zmírnění nebo krizový plán

Je to záložní plán, který je připraven k překonání rizik nebo problémů.

Podívejme se na jeden příklad pro předpoklad, riziko a pohotovostní plán společně, protože spolu souvisí.

V každém produktu, předpoklad zajistíme, že všichni 3 testovací inženýři tam budou až do dokončení produktu a každému z nich jsou přiřazeny různé moduly, jako je P, Q a R. V tomto konkrétním scénáři riziko mohlo by to být, kdyby zkušební inženýr opustil projekt uprostřed toho.

Proto, náhradní plán bude každému prvku přiřazen primární a podřízený vlastník. Pokud tedy jeden testovací technik odejde, podřízený vlastník převezme tuto specifickou funkci a také pomůže novému testovacímu technikovi, aby mohl porozumět jim přiřazeným modulům.

Předpoklady, rizika a plán zmírnění nebo nepředvídaných událostí jsou vždy přesné na samotném produktu. Různé typy rizik jsou následující:

• Pohled zákazníka
• Zdrojový přístup
• Technický posudek

Role a odpovědnost

Definuje kompletní úkol, který musí provést celý testovací tým. Když přijde velký projekt, pak Správce testů je osoba, která píše plán testování. Pokud existují 3-4 malé projekty, pak vedoucí testu přiřadí každý projekt každému vedoucímu testu. Poté vedoucí testu napíše plán testování projektu, který je mu přidělen.

Podívejme se na jeden příklad, kde pochopíme role a odpovědnost manažera testu, vedoucího testu a testovacích techniků.

Role: manažer testu

Jméno: Ryan

Odpovědnost:

• Připravte (napište a zkontrolujte) plán testu
• Proveďte schůzku s vývojovým týmem
• Proveďte schůzku s testovacím týmem
• Proveďte schůzku se zákazníkem
• Uspořádejte jedno měsíční stand up setkání
• Podepište poznámku k vydání
• Řešení eskalace a problémů

Role: Vedoucí testu

Jméno: Harvey

Odpovědnost:

• Připravte (napište a zkontrolujte) plán testu
• Pořádejte každodenní schůzky ve stoje
• Zkontrolujte a schvalte testovací případ
• Připravte RTM a zprávy
• Přiřadit moduly
• Harmonogram manipulace

Role: Testovací technik 1, Testovací technik 2 a Testovací technik 3

Jméno: Louis, Jessica, Donna

Přiřaďte moduly: M1, M2 a M3

Odpovědnost:

• Napište, zkontrolujte a spusťte testovací dokumenty, které se skládají z testovacích případů a testovacích scénářů
• Přečtěte si, zkontrolujte, pochopte a analyzujte požadavek
• Napište tok aplikace
• Proveďte testovací případ
• RTM pro příslušné moduly
• Sledování defektů
• Připravte zprávu o provedení testu a předejte ji vedoucímu testu.

Plán

Používá se k vysvětlení načasování práce, co je třeba udělat, nebo tento atribut pokrývá, kdy přesně by měla každá testovací aktivita začít a skončit? A u každé testovací aktivity k danému datu jsou uvedeny také přesné údaje.

Jak tedy můžeme vidět na obrázku níže, pro konkrétní aktivitu bude datum zahájení a datum ukončení; pro každé testování na konkrétní sestavení bude uvedené datum.

Například

• Psaní testovacích případů
• Proces provádění

Sledování defektů

Obvykle se to provádí pomocí nástrojů, protože nemůžeme ručně sledovat stav každé chyby. A také komentujeme, jak sdělujeme chyby, které byly zjištěny během procesu testování, a posíláme to zpět vývojovému týmu a jak vývojový tým odpoví. Zde také zmíníme prioritu chyb, jako je vysoká, střední a nízká.

Následují různé aspekty sledování defektů:

Techniky sledování chyby
…..
……
……
……Nástroje pro sledování chyb
Můžeme se vyjádřit k názvu nástroje, který budeme používat pro sledování chyb. Některé z nejčastěji používaných nástrojů pro sledování chyb jsou Jira, Bugzilla, Mantis a Trac atd.<Vážnost
Závažnost může být následující:
Blocker nebo showstopper
…..
….. (Vysvětlete to příkladem v plánu testu)
Například , bude v modulu závada; nemůžeme jít dále a testovat další moduly, protože pokud je chyba zablokována, můžeme přistoupit ke kontrole dalších modulů.
Kritické
……
….. (Vysvětlete to příkladem v plánu testu)
V této situaci vady ovlivní obchod.
Hlavní, důležitý
….
…. (Vysvětlete to příkladem v plánu testování)
Méně důležitý
…..
….. (Vysvětlete to příkladem v plánu testu)
Tyto vady jsou ty, které ovlivňují vzhled a dojem z aplikace.Přednost
High-P1
…..
Střední-P2
…..
Nízké P3
…..
…..
P4

Proto je na základě priority chyb, jako je vysoká, střední a nízká, budeme kategorizovat jako P1, P2, P3 a P4.

Testovací prostředí

Toto jsou prostředí, kde budeme aplikaci testovat, a zde máme dva typy prostředí, které jsou software a Hardware konfigurace.

The softwarovou konfiguraci znamená podrobnosti o různých Operační systémy jako Windows, Linux, UNIX a Mac a různé Prohlížeče jako Google Chrome, Firefox, Opera, Internet Explorer , a tak dále.

A hardwarová konfigurace znamená informace o různých velikostech RAM, ROM a procesory .

Například

• The Software zahrnuje následující:

Server

Poznámka: Výše ​​uvedené servery jsou servery, které používá testovací tým k testování aplikace.

Klient

Poznámka: Výše ​​uvedené podrobnosti poskytují různé operační systémy a prohlížeče, ve kterých bude testovací tým aplikaci testovat.

• The Hardware zahrnuje následující:

Server : Sun StarCat 1500

Tento konkrétní server může testovací tým použít k testování své aplikace.

Klient:

Má následující konfiguraci, která je následující:

Poznámka: Poskytne konfiguraci systémů testovacích techniků, kteří jsou testovacím týmem.

Proces instalace softwaru
……
…..
…..

Vývojový tým poskytne konfiguraci, jak software nainstalovat. Pokud vývojový tým ještě proces nezajistí, zapíšeme jej do plánu testování jako Task-Based Development (TBD).

Vstupní a výstupní kritéria

Je to nezbytná podmínka, která musí být splněna před zahájením a zastavením procesu testování.

Vstupní kritéria

Vstupní kritéria obsahují následující podmínky:

• Testování bílé krabice by mělo být dokončeno.
• Pochopte a analyzujte požadavek a připravte testovací dokumenty nebo až budou testovací dokumenty připraveny.
• Testovací data by měla být připravena.
• Sestavení nebo aplikace musí být připraveny
• Moduly nebo funkce musí být přiřazeny různým testovacím technikům.
• Potřebný zdroj musí být připraven.

Výstupní kritéria

Výstupní kritéria obsahují následující podmínky:

• Když jsou provedeny všechny testovací případy.
• Většina testovacích případů musí být prošel .
• Závisí na závažnosti chyb, což znamená, že se nesmí vyskytovat žádná blokující nebo závažná chyba, zatímco některé drobné chyby existují.

Než začneme provádět funkční testování, vše výše uvedené Vstupní kritéria by se mělo dodržovat. Poté, co jsme provedli funkční testování a předtím, než provedeme integrační testování, pak Výstupní kritéria pro funkční testování by mělo následovat, protože o % výstupních kritérií rozhoduje schůzka s vývojovým i testovacím manažerem, protože jejich spolupráce může procenta dosáhnout. Pokud však nejsou dodržena výstupní kritéria funkčního testování, nemůžeme pokračovat v integračním testování.

Tady na základě závažnosti chyba znamená, že testovací tým by se rozhodl pokračovat v dalších fázích.

Automatizace testů

V tomto se rozhodneme pro následující:

• Která funkce musí být automatizována a která nemá být automatizována?
• Jaký nástroj pro automatizaci testů použijeme na kterém automatizačním rámci?

Testovací případ automatizujeme až po prvním vydání.

Zde se nabízí otázka, na jakém základě my vůle rozhodnout, které funkce je třeba otestovat?

Na obrázku výše, jak vidíme, že nejčastěji používané funkce je třeba testovat znovu a znovu. Předpokládejme, že musíme zkontrolovat aplikaci Gmail, kde jsou základní funkce Psaní pošty, odeslaných položek a doručené pošty . Tyto funkce tedy otestujeme, protože ruční testování zabere více času a také se z toho stává monotónní práce.

Nyní, jak rozhodneme, které funkce nebudou testovány?

Předpokládat pomoc funkce aplikace Gmail není znovu a znovu testována, protože tyto funkce nejsou pravidelně používány, takže je nemusíme často kontrolovat.

Ale pokud jsou některé funkce nestabilní a mají spoustu chyb , což znamená, že tyto funkce nebudeme testovat, protože se musí testovat znovu a znovu při ručním testování.

Li existuje funkce, kterou je třeba často testovat , ale očekáváme změnu požadavku na tuto funkci, takže ji nekontrolujeme, protože změna ručních testovacích případů je pohodlnější ve srovnání se změnou skriptu automatizačního testu.

Odhad úsilí

V tomto budeme plánovat úsilí, které musí vynaložit každý člen týmu.

Test Dodávka

Jedná se o dokumenty, které jsou výstupem z testovacího týmu, který jsme předali zákazníkovi spolu s produktem. Zahrnuje následující:

Testovací plán Testovací případy Testovací skripty RTM (Matice sledovatelnosti požadavků) Hlášení závady Zpráva o provedení testu Grafy a metriky Poznámky k vydání

Grafy a metriky

Graf

V tomto budeme diskutovat o typech grafy zašleme a poskytneme také ukázku každého grafu.

Jak vidíme, máme pět různých grafů, které ukazují různé aspekty procesu testování.

Graf1: V tomto ukážeme, kolik defektů bylo identifikováno a kolik defektů bylo opraveno v každém modulu.

funkce python chr

Graf 2: Obrázek 1 ukazuje, kolik kritických, hlavních a menších defektů bylo identifikováno u každého modulu a kolik bylo opraveno u příslušných modulů.

Graf 3: V tomto konkrétním grafu znázorňujeme vytvořit moudrý graf , což znamená, že v každém sestavení, kolik defektů bylo identifikováno a opraveno pro každý modul. Na základě modulu jsme určili chyby. doplníme R ukázat počet defektů v P a Q a také přidáme S ukázat defekty v P, Q a R.

Graf 4: Testovací kabel navrhne Analýza trendů chyb grafu, který se vytváří každý měsíc a zašlete jej také do vedení. A je to jako předpověď, která se provádí na konci produktu. A tady můžeme také hodnotit opravy chyb jak to můžeme pozorovat oblouk má vzestupnou tendenci na obrázku níže.

Graf5: The Správce testů navrhl tento typ grafu. Tento graf je určen k pochopení mezery v hodnocení chyb a skutečných chyb, které se vyskytly, a tento graf také pomáhá zlepšit hodnocení chyb v budoucnu.

Metriky

Stejně jako výše vytvoříme graf distribuce chyb, který je na obrázku 1, a pomocí výše uvedených dat navrhneme i metriky.

Například

Na obrázku výše uchováváme záznamy všech testovacích techniků v konkrétním projektu a kolik defektů bylo identifikováno a opraveno. Tato data můžeme také použít pro budoucí analýzu. Když přijde nový požadavek, můžeme se rozhodnout, komu poskytneme náročnou funkci k testování na základě počtu defektů, které dříve našli podle výše uvedených metrik. A budeme v lepší situaci, abychom věděli, kdo si s problematickými vlastnostmi velmi dobře poradí a najde maximum závad.

Poznámka k vydání: Jedná se o dokument, který je připraven během uvedení produktu na trh a podepsán Test Managerem.

Na obrázku níže můžeme vidět, že finální produkt je vyvinut a nasazen u zákazníka, a název nejnovější verze je Beta .

The Poznámka k vydání se skládá z následujícího:

• Uživatelský manuál.
• Seznam nevyřízených a otevřených defektů.
• Seznam přidaných, upravených a odstraněných funkcí.
• Seznam platformy (Operační systém, Hardware, Prohlížeče), na které je produkt testován.
• Platforma, na které není produkt testován.
• Seznam chyb opravených v aktuální verzi a seznam opravených chyb v předchozí verzi.
• Proces instalace
• Verze softwaru

Například

Předpokládejme, že Beta je druhým vydáním aplikace po prvním vydání Alfa je vydána. Některé z defektů identifikovaných v prvním vydání a které byly opraveny v pozdějším vydání. A zde také upozorníme na seznam nově přidaných, upravených a smazaných funkcí z alfa verze do beta verze.

Šablona

Tato část obsahuje všechny šablony pro dokumenty, které budou použity v produktu, a všichni testovací inženýři budou v projektu používat pouze tyto šablony, aby byla zachována konzistence produktu. Zde máme různé typy šablon, které se používají během celého procesu testování, jako například:

• Šablona testovacího případu
• Šablona revize testovacího případu
• RTM šablona
• Šablona hlášení chyby
• Zpráva o provedení testu

Podívejme se na jeden příklad dokumentu plánu testování

Strana 1

Strana3-strana18

Strana-20

Na stránce 1 primárně vyplňujeme pouze Verze, autor, komentáře a recenze pole a poté, co to manažer schválí, zmíníme podrobnosti v Schváleno do a datum schválení pole.

Testovací plán většinou schvaluje Test Manager a testovací inženýři jej pouze kontrolují. A až přijdou nové funkce, upravíme plán testování a provedeme potřebné úpravy Verze pole a poté bude znovu odesláno k další kontrole, aktualizaci a schválení manažerem. Testovací plán musí být aktualizován vždy, když nastanou nějaké změny. Na straně 20, Reference specifikovat podrobnosti o všech dokumentech, které budeme používat k sepsání dokumentu plánu testování.

Poznámka:

Kdo píše plán testování?

• Testovací zájemce→60 %
• Správce testů→20 %
• Testovací technik→20 %

Jak tedy vidíme shora, u 60 % produktu je plán testu napsán vedoucím testu.

Kdo kontroluje plán testování?

• Testovací vedení
• Správce testů
• Zkušební inženýr
• Zákazník
• Vývojářský tým

Testovací technik zkontroluje plán testování z hlediska jejich modulové perspektivy a manažer testu zkontroluje plán testování na základě názoru zákazníka.

Kdo schvaluje plán testování?

• Zákazník
• Správce testů

Kdo píše testovací případ?

• Testovací vedení
• Testovací inženýr

Kdo kontroluje testovací případ?

• Testovací inženýr
• Testovací vedení
• Zákazník
• Vývojářský tým

Kdo schvaluje testovací případy?

• Správce testů
• Testovací vedení
• Zákazník

Pokyny pro testovací plán

• Sbalte svůj testovací plán.
• Vyvarujte se překrývání a nadbytečnosti.
• Pokud si myslíte, že nepotřebujete sekci, která je již zmíněna výše, pak tuto sekci odstraňte a pokračujte vpřed.
• Buď konkrétní. Když například zadáte softwarový systém jako součást testovacího prostředí, uveďte verzi softwaru místo pouze názvu.
• Vyhněte se dlouhým odstavcům.
• Kdekoli je to možné, používejte seznamy a tabulky.
• Aktualizujte plán v případě potřeby.
• Nepoužívejte zastaralý a nepoužitý dokument.

Význam zkušebního plánu

• Testovací plán udává směr našemu myšlení. Je to jako kniha pravidel, která se musí dodržovat.
• Plán testování pomáhá při určování potřebného úsilí pro ověření kvality testované softwarové aplikace.
• Plán testování pomáhá těmto lidem porozumět podrobnostem testu, které se týkají vnějšku, jako jsou vývojáři, obchodní manažeři, zákazníci atd.
• Důležité aspekty, jako je plán testování, strategie testování, rozsah testu atd., jsou zdokumentovány v plánu testování, aby je manažerský tým mohl přezkoumat a znovu použít pro jiné podobné projekty.