Analýza testů a základy testování
Thomas Hamilton
⚡ Chytré shrnutí
Testovací analýza, nazývaná také Test Basis, je strukturovaný přehled požadavků, návrhové dokumentace a dalších artefaktů používaných k odvození testovatelných podmínek. Tento článek vysvětluje zdroje, podrobný pracovní postup a umístění testovací analýzy ve V-modelu.
Analýza testů – známá také jako základ testů – se nachází na samém začátku životního cyklu testování. Každá testovací podmínka a testovací případ nakonec traczpět k tomu. Následující části definují termín, vysvětlují jeho zdroje, procházejí pracovním postupem analýzy a umisťují jej do V-modelu.
Co je to testovací analýza?
Analýza testu V testování softwaru je proces kontroly vstupů použitých k odvození testovacích podmínek a testovacích případů. Tyto vstupy – specifikace, požadavky, návrhová dokumentace, uživatelské příběhy a podobné výstupy – se souhrnně nazývají testovací artefaktyCílem testovací analýzy je zjistittracCíle testu jsou dostatečně jasné, aby každý z nich mohl být přeměněn na jednoznačnou testovací podmínku. Protože analyzovaný materiál tvoří základ, ze kterého jsou odvozeny všechny testy, nazývá se také Základ testu.
Mezi typické zdroje, ze kterých testeři čerpají informace o testech, patří:
- SRS — Specifikace softwarových požadavků
- BRS — Specifikace obchodních požadavků
- Dokumenty funkčního designu
- Uživatelské příběhy, kritéria přijetí a wireframy
Testeři mohou také generovat testovací podmínky přímým prozkoumáním testované aplikace nebo na základě minulých zkušeností, ale většina... testovací případy jsou odvozeny z testovacích artefaktů pro udržení tracsnadnost.
👉 Zaregistrujte se do projektu bezplatného živého testování softwaru
Proč je Test Basic důležitý?
Testovací báze je nejdůležitějším faktorem určujícím, zda testovací sada zachycuje skutečné vady, nebo se snaží najít ty skryté. Její zacházení jako s volitelným nástrojem je nejčastější příčinou toho, že se uniklé chyby dostanou do produkčního prostředí. Solidní analýza testů přináší čtyři konkrétní výhody:
- Tracsnadnost: Každý testovací případ lze propojit s konkrétním požadavkem, což usnadňuje analýzu dopadu změn a zjednodušuje auditní kontroly.
- Jasnost pokrytí: Revprohlížení mezer v bázových plochách – nespecifikovaných chybových stavů, chybějících okrajových případů, nedefinovaných nefunkčních prahových hodnot – dříve, než se stanou produkčními incidenty.
- Sladění se zainteresovanými stranami: Když testovací tým odvozuje podmínky ze stejných dokumentů, na kterých staví vývojový tým, obě strany sdílejí definici „hotovo“.
- Včasná detekce vad: Mnoho vad v požadavcích (nejednoznačnost, rozpory, chybějící kritéria přijetí) je odhaleno během samotné testovací analýzy, dlouho předtím, než je napsán jakýkoli kód – zdaleka nejlevnější místo pro jejich opravu.
Běžné zdroje testovacích bází
Různé artefakty podporují různé úrovně testování. Níže uvedenou tabulku použijte jako rychlou referenci při rozhodování, který dokument si při psaní testovacích případů přečíst.
| Zdrojový artefakt | Nejvhodnější pro | Co jsi bývalý/átract |
|---|---|---|
| Specifikace obchodních požadavků (BRS) | Přejímací a systémové testování | Komplexní obchodní pravidla, regulační omezení, kritéria úspěchu |
| Specifikace softwarových požadavků (SRS) | Testování systému | Funkční a nefunkční požadavky s měřitelnými prahovými hodnotami |
| Dokumentace funkčního / technického návrhu | Integrační testování | Rozhraní modulů, tok dat, specifikace ošetření chyb |
| Uživatelské příběhy a kritéria přijetí | Testování agilního sprintu | Behaviorální očekávání ve formě „Dáno–Když–Pak“ |
| Wireframy a makety uživatelského rozhraní | Testování uživatelského rozhraní / použitelnosti | Rozvržení, navigace, pravidla ověřování vstupu |
| Aplikace v testovací fázi (průzkumná) | Průzkumné a regresní testování | Nedokumentované chování, pracovní postupy v reálném světě, okrajové případy |
Jak provést testovací analýzu krok za krokem
Efektivní analýza testů se řídí opakovatelným pětikrokovým pracovním postupem bez ohledu na velikost projektu nebo metodologii.
- Shromážděte a proveďte inventuru testovací báze. Shromážděte všechny artefakty, které popisují zamýšlené chování – SRS, BRS, návrhovou dokumentaci, uživatelské příběhy, makety. Všimněte si, který dokument vlastní který požadavek, aby… tracSchopnost zůstává zachována.
- Revpohled na testovatelnost. Každý artefakt si přečtěte se třemi otázkami: Je toto tvrzení měřitelné? Je jednoznačné? Je úplné? Označte jakýkoli požadavek, který neprojde jednou z těchto kontrol, a před napsáním testů jej předejte autorovi.
- Určete testovací podmínky. Pro každý testovatelný příkaz uveďte podmínky, které je třeba ověřit (kladné cesty, záporné cesty, okrajové hodnoty, ošetření chyb, bezpečnost, výkon). Testovací podmínka je abs.trac„co“ – například „systém odmítá objednávky s nulovým množstvím“ – odlišné od konkrétního „jak“ v testovacím případě.
- Stanovte priority a seskupte podmínky. Klasifikujte každou podmínku podle rizika a četnosti použití. Vysoce rizikové a často se vyskytující podmínky si vyžádají podrobný popis; nízkorizikové podmínky lze kombinovat nebo vzorkovat. Zde také rozhodujete, které podmínky jsou kandidáty na automatizaci.
- Převeďte podmínky na testovací případy. Každá podmínka s prioritou se stává jednou nebo více testovací případy s předpoklady, kroky, testovacími daty a očekávanými výsledky. Udržujte požadavky tracMatice proveditelnosti propojující každý testovací případ s jeho původním požadavkem.
Dodržování této posloupnosti se vyhne nejčastějším chybám při analýze testů: psaní testovacích případů bez jasného základu, vynechávání negativních scénářů a vytváření testů, které nelze během třídění defektů propojit s požadavkem.
Analýza testů ve V-modelu
V-Model spojuje každou vývojovou aktivitu s odpovídající testovací aktivitou. Analýza testů probíhá na každé úrovni s použitím libovolného dokumentu, který je v daném bodě životního cyklu k dispozici.
Obrázek 1: Analýza testů napříč fázemi V-model.
Případová studie: Odvození testovacích případů z požadavku klienta
Uvažujme scénář, ve kterém klient odešle následující jednořádkový požadavek.
Client requirement: Add search functionality to an eCommerce Store
I když aplikace ještě nebyla sestavena, tester může již odvodit několik testovacích podmínek analýzou toho, co daný požadavek implikuje – jak chování typu „happy Path“, tak i režimy selhání, které klient explicitně neuvedl. Mezi příklady patří:
- Ověřte výsledek vyhledávání, pokud není zadáno žádné klíčové slovo.
- Ověřit výsledek vyhledávání, pokud pro zadané klíčové slovo neexistuje žádný odpovídající produkt.
- Ověřte výsledek vyhledávání, pokud pro dané klíčové slovo existuje několik odpovídajících produktů.
- Ověřte chování pomocí speciálních znaků, úvodních/koncových mezer a velmi dlouhých vstupů.
- Ověřte rozlišování velkých a malých písmen a chování při částečné shodě.
- Ověřte dobu odezvy vyhledávání při očekávaném zatížení uživatelem.
Tester vezme požadavek klienta (testovací základ), analyzuje ho a převede ho do testovacích podmínek. Tento vzorec se opakuje v každé fázi V-modelu – testovací plány a testovací případy se vytvářejí s použitím jakéhokoli dokumentu, který je v daném bodě životního cyklu k dispozici.
Video: Vysvětlení analýzy testů
Pokud se video nenačte, podívejte se na něj přímo na YouTube.
