how classify positive
Něco můžete udělat snadno nebo těžce - důležité je, že to uděláte. Existuje několik jednoduchých každodenních věcí, ale bez důvěry nám něco z nich úplně nezapadá do mysli a míra úspěchu je trefa do černého.
Pojďme si dnes vzít jeden jednoduchý příklad a najdeme zkratky, které nejen vyjasní pojmy, ale také zajistí, že to vždy napravíte.
Pozitivní nebo negativní klasifikace testovacích scénářů / případů
Proces návrhu testu je trojnásobný:
- Určete požadavky
- Napište testovací scénáře (jeden řádek ukazatele toho, co testovat)
- Navrhněte podrobné pokyny k testování (testovací případy)
Při psaní testovacích scénářů je klasifikujeme do pozitivních a negativních podmínek. (Když o tom přemýšlíte, je opravdu důležité vytvořit tuto klasifikaci? Pokud ano, k jakému účelu slouží? Musíme je stejně všechny otestovat, že?) Většinou to také bije. Ale myslím si, že se jedná o pokus o vytvoření adekvátního pokrytí a pomáhá nám zjistit, že testujeme šťastné i alternativní cesty, které má systém zvládnout. Pokud víte o jakýchkoli dalších důvodech, proč se tak děje, prosím komentujte níže.
Nyní se podívejme na několik požadavků, vytvořme scénáře testu a proveďme klasifikaci.
# 1) Přihlaste se :Uživatel, který zadá správná pověření, se dostane do systému. Pokud jsou pověření nesprávná, přístup byl odepřen a zobrazí se chybová zpráva.
# 2) Zobrazit produkty: Předpokládejme, že v systému je k dispozici online katalog všech produktů, které po kliknutí na odkaz „Zobrazit produkty“ zobrazí všechny v seznamu.
# 3) Odhlášení: Po kliknutí na tento odkaz je uživatel odhlášen.
Pro tyto požadavky napíšu několik testovacích scénářů.
Tabulka A:Správná cesta
ID testovacího scénáře | Popis testovacího scénáře | Pozitivní negativní |
---|---|---|
TS_login_01 | Ověřte, zda se uživatel úspěšně přihlásí, pokud jsou zadaná pověření správná | Pozitivní |
TS_login_02 | Ověřte, zda uživateli není povolen přístup, když jsou zadané přihlašovací údaje nesprávné | Záporný |
TS_ViewProduct_01 | Ověřte, zda jsou po kliknutí na odkaz Zobrazit produkty uvedeny všechny položky | Pozitivní |
TS_logout_01 | Ověřte, zda je již přihlášený uživatel odhlášen ze systému po kliknutí na odhlášení | Pozitivní |
Někdy však vidím scénář testu napsaný takto.
Tabulka B: Položky označenéSíťjsou neplatné testovací scénáře.
ID testovacího scénáře | Popis testovacího scénáře | Pozitivní negativní |
---|---|---|
TS_login_01 | Ověřte, zda se uživatel úspěšně přihlásí, pokud jsou zadaná pověření správná | Pozitivní |
TS_login_02 | Ověřte, zda uživateli není povolen přístup, když jsou zadané přihlašovací údaje nesprávné | Záporný |
TS_ViewProduct_01 | Ověřte, zda jsou po kliknutí na odkaz Zobrazit produkty uvedeny všechny položky | Pozitivní |
TS_ViewProduct_02 | Ověřte, zda po kliknutí na odkaz Zobrazit produkty nejsou všechny položky uvedeny | Záporný |
TS_logout_01 | Ověřte, zda je již přihlášený uživatel odhlášen ze systému po kliknutí na odhlášení | Pozitivní |
TS_logout_02 | Ověřte, zda se uživatel po kliknutí na odkaz pro odhlášení neodhlásí | Záporný |
Pro úspěšný případ přihlášení existuje stejný a opačný případ, kdy nebude úspěšný. Ne všechny požadavky mají být takové a pro ně opravdu neexistuje nutkání psát negativní scénář.
Sečteno a podtrženo: Ne každý požadavek by měl mít negativní případy.
V tomto okamžiku, pokud si myslíte „Jak to budu vědět“ nebo „Stále si nejsem jistý“, zde je jednoduchý podvod, který vám pomůže.
aplikace špehovat na jiném telefonu
Pokud existuje jedna generalizace, kterou můžeme o aplikacích udělat, je to, že jsou dynamické. Vstup (data, kliknutí atd.), Který poskytneme, způsobí, že aplikace bude určitým způsobem a vygeneruje určitý výstup.
Jednoduchá korelace mezi vstupní a výstupní proměnnou to usnadní pochopení.
Vyzkoušejte pro přihlášení následující:
Vstup | Výstup | Pozitivní negativní |
---|---|---|
Správné (správné přihlašovací údaje) | Správně (uživatel přihlášen) | Pozitivní |
Nesprávné (nesprávné přihlašovací údaje) | Správně (Chybová zpráva) | Záporný |
Správné (správné přihlašovací údaje) | Nesprávně - přihlášení selhalo | Chyba / Vada |
Nesprávné (nesprávné přihlašovací údaje) | Nesprávně (systém je přihlásí) - „Ach, ta hrůza!“ :) | Chyba / vada |
Jak tedy vidíte z výše uvedené tabulky, můžeme říci, že primární tok kategorizujeme jako pozitivní a alternativní tok (také správné chování aplikace) je označen jako negativní.
Poslední dva případy v červené barvě jsou ve skutečnosti chyby. Testování se týká ověřování požadavků a pokud nefungují podle očekávání, najdeme chyby. Protože neprovádíme ověřování vad, poslední dva případy jsou neplatné.
Podle stejné myšlenkové linie a jejího uplatnění při odhlášení a prohlížení produktů získáte toto.
Vstup | Výstup | Pozitivní negativní |
---|---|---|
Odhlášení (klikněte) | Správně - odhlásí se | Pozitivní |
Odhlášení (klikněte) | Nesprávně - zůstane přihlášeno | Chyba / vada |
Zobrazit produkty (kliknout) | Správně - zobrazí produkty | Pozitivní |
Zobrazit produkty (kliknout) | Nesprávné (není seznam nebo zobrazení nesprávného seznamu) | Chyba / vada |
Jak vidíte, pro tyto požadavky není možné zadat nesprávný vstup. Proto nemusí být psány žádné negativní testovací scénáře / případy.
Závěrečné myšlenky:
Systém může být vystaven kladnému nebo zápornému vstupu. Ať tak či onak, systém by měl generovat správný výstup. Případy, které mají tendenci zabývat se správným vstupem, jsou pozitivní. Ty, které se týkají správného, ale záporného vstupu, jsou záporné.
Několik ukazatelů:
# 1) Když komplexní testovací případy jsou psány pro testování UAT nebo dokonce pro testování systému, do toku se vždy dostanou pozitivní testovací případy.
#dva) Někdy je klasifikace subjektivní.Například, pokud něco na webu mazám a dostanu potvrzovací zprávu s dotazem „Opravdu chcete tuto položku smazat?“ s možnostmi OK a Storno - podle mě je kliknutí na zrušení pozitivní případ. Někteří si však myslí, že je to negativní, protože primárním záměrem možnosti „Smazat“ je smazat a nezrušit operaci. Při klasifikaci tedy hraje roli také úsudek testera.
# 3) U každého pozitivního případu nemusí vždy existovat stejný a opačný negativní případ.
Výše uvedená metoda vždy zaručuje správnou klasifikaci. Zkuste to sami a řekněte mi, pokud ne. :) „Zkratka je často nesprávný střih.“ - Ale v tomto případě to tak nemusí být!
Pro formálnější vysvětlení negativního testování prosím zkontrolujte => Co je negativní testování a jak psát případy negativního testu?
O autorovi: Tento článek je napsán členem týmu STH Swati S. Připojte se k jejímu živému QA školení zde: „ Nejlepší školení v oblasti testování softwaru, jaké kdy získáte! '
Dejte nám prosím vědět, pokud se vám tento článek líbil a chcete vidět všechny takové základní pojmy, které budou v následujících článcích snadno vysvětleny.
Vaše komentáře, dotazy, zpětná vazba a čtenářství jsou zde na STH vysoce ceněny a oceňovány. Šťastné testování!
Doporučené čtení
- Pozitivní testování: význam a zásluhy vysvětlené scénáři skutečného testu
- Jak psát testovací případy pro přihlašovací stránku (ukázkové scénáře)
- Co je negativní testování a jak psát případy negativního testu?
- Jak psát testovací případy pro bankomat (ukázkové scénáře)
- Efektivní scénáře selenu a řešení potíží - Scénář selenu č. 27
- Typy testování migrace: S testovacími scénáři pro každý typ
- Výukový program QTP č. 24 - Používání virtuálních objektů a scénářů obnovy v testech QTP
- Testování aplikací ve zdravotnictví - tipy a důležité testovací scénáře (část 2)