how classify positive
Môžete robiť niečo ľahkým alebo ťažkým spôsobom - dôležité je, že to urobíte. Existuje niekoľko jednoduchých každodenných vecí, ale bez dôvery nám niečo z nich celkom nesedí v našich mysliach a miera úspechu je trefa do čierneho.
Uveďme si dnes jeden jednoduchý príklad a nájdime skratky, ktoré nielen objasnia pojmy, ale tiež zabezpečia, že ich vždy správne uvediete.
Pozitívna alebo negatívna klasifikácia testovacích scenárov / prípadov
Proces návrhu testu je trojnásobný:
- Identifikujte požiadavky
- Napíšte testovacie scenáre (jednoriadkové ukazovatele toho, čo treba testovať)
- Navrhnite podrobné pokyny na testovanie (testovacie prípady)
Pri písaní testovacích scenárov ich zaraďujeme do pozitívnych a negatívnych podmienok. (Keď sa nad tým zamyslíte, je skutočne dôležité urobiť túto klasifikáciu? Ak áno, na aký účel slúži? Aj tak ich musíme všetky otestovať, však?) Väčšinou ma to tiež poráža. Ale myslím si, že je to pokus o zabezpečenie adekvátneho pokrytia a pomáha nám zistiť, že testujeme šťastné aj alternatívne cesty, ktoré má systém zvládnuť. Ak viete o akýchkoľvek ďalších dôvodoch, prečo sa tak deje, komentár nižšie.
Teraz sa pozrime na niekoľko požiadaviek, napíšme testovacie scenáre a vykonajme klasifikáciu.
# 1) Prihláste sa :Používateľ, ktorý zadá správne poverenia, sa dostane do systému. Ak sú poverenia nesprávne, prístup je odmietnutý a zobrazí sa chybové hlásenie.
# 2) Zobraziť produkty: Predpokladajme, že v systéme je k dispozícii online katalóg všetkých produktov a po kliknutí na odkaz „Zobraziť produkty“ ich všetky zobrazí v zozname.
# 3) Odhlásiť sa: Po kliknutí na tento odkaz je používateľ odhlásený.
Napíšem niekoľko testovacích scenárov pre tieto požiadavky.
Tabuľka A:Správna cesta
ID testovacieho scenára | Popis testovacieho scenára | Pozitívny negatívny |
---|---|---|
TS_login_01 | Overte, či sa používateľ úspešne prihlási, ak sú zadané poverenia správne | Pozitívne |
TS_login_02 | Overte, či používateľovi nie je povolený prístup, keď sú zadané poverenia nesprávne | Negatívne |
TS_ViewProduct_01 | Overte, či sú po kliknutí na odkaz Zobraziť produkty uvedené všetky položky | Pozitívne |
TS_logout_01 | Overiť, či je už prihlásený používateľ odhlásený zo systému po kliknutí na odhlásenie | Pozitívne |
Niekedy však vidím scenár testu napísaný takto.
Tabuľka B: Položky označenéNettosú neplatné testovacie scenáre.
ID testovacieho scenára | Popis testovacieho scenára | Pozitívny negatívny |
---|---|---|
TS_login_01 | Overte, či sa používateľ úspešne prihlási, ak sú zadané poverenia správne | Pozitívne |
TS_login_02 | Overte, či používateľovi nie je povolený prístup, keď sú zadané poverenia nesprávne | Negatívne |
TS_ViewProduct_01 | Overte, či sú po kliknutí na odkaz Zobraziť produkty uvedené všetky položky | Pozitívne |
TS_ViewProduct_02 | Overte, či po kliknutí na odkaz Zobraziť produkty nie sú všetky položky v zozname | Negatívne |
TS_logout_01 | Overiť, či je už prihlásený používateľ odhlásený zo systému po kliknutí na odhlásenie | Pozitívne |
TS_logout_02 | Overte, či sa používateľ po kliknutí na odkaz na odhlásenie neodhlási | Negatívne |
Pre úspešný prípad prihlásenia existuje rovnaký a opačný prípad, keď nebude úspešný. Nie všetky požiadavky majú byť tak a pre ne skutočne neexistuje nutkanie napísať negatívny scenár.
Záver: Nie každá požiadavka by mala mať záporné prípady.
Ak si v tomto okamihu myslíte „Ako to budem vedieť“ alebo „Stále si nie som istý“, tu je jednoduchý podvod, ktorý vám pomôže.
ako otvárať torrentované súbory v systéme Windows 10
Ak existuje jedna generalizácia, ktorú môžeme o aplikáciách urobiť, je to, že sú dynamické. Vstup (údaje, kliknutia atď.), Ktorý poskytneme, spôsobí, že aplikácia bude určitým spôsobom a vygeneruje určitý výstup.
Jednoduchá korelácia medzi vstupnými a výstupnými premennými to uľahčí pochopenie.
Skúsme sa prihlásiť nasledovne:
Vstup | Výkon | Pozitívny negatívny |
---|---|---|
Správne (správne prihlasovacie údaje) | Správne (používateľ prihlásený) | Pozitívne |
Nesprávne (nesprávne prihlasovacie údaje) | Správne (chybové hlásenie) | Negatívne |
Správne (správne prihlasovacie údaje) | Nesprávne - prihlásenie zlyhalo | Chyba / chyba |
Nesprávne (nesprávne prihlasovacie údaje) | Nesprávne (systém ich prihlási) - „Och, hrôza!“ :) | Chyba / chyba |
Ako teda vidíte z vyššie uvedenej tabuľky, môžeme povedať, že primárny tok kategorizujeme ako pozitívny a alternatívny tok (tiež správne správanie aplikácie) je označený ako negatívny.
Posledné dva prípady v červenej farbe sú v skutočnosti chyby. Testovanie sa týka overenia požiadaviek. Ak nefungujú podľa plánu, nájdeme chyby. Pretože nejde o overenie chýb, posledné dva prípady sú neplatné.
Rovnakým spôsobom a aplikovaním na odhlásenie a prezeranie produktov získate aj toto.
Vstup | Výkon | Pozitívny negatívny |
---|---|---|
Odhlásiť sa (kliknúť) | Správne - odhlási sa | Pozitívne |
Odhlásiť sa (kliknúť) | Nesprávne - zostáva prihlásený | Chyba / chyba |
Zobraziť produkty (kliknúť) | Správne - zobrazuje produkty | Pozitívne |
Zobraziť produkty (kliknúť) | Nesprávne (zoznam sa nezobrazuje alebo sa zobrazenie nesprávne zobrazuje) | Chyba / chyba |
Ako vidíte, pre tieto požiadavky nie je možné zadať nesprávny vstup. Preto nemusia byť napísané negatívne scenáre / prípady testu.
Záverečné myšlienky:
Systém by mohol byť vystavený pozitívnym alebo negatívnym vstupom. Či tak alebo onak, systém by mal generovať správny výstup. Prípady, ktoré majú tendenciu zaoberať sa správnymi vstupmi, sú pozitívne. Tie, ktoré sa týkajú správneho, ale záporného vstupu, sú záporné.
Niekoľko ukazovateľov:
# 1) Keď sa komplexné testovacie prípady sú určené pre UAT alebo dokonca pre testovanie systému, do testov sa dostanú vždy prípady pozitívneho testu.
#dva) Niekedy je klasifikácia subjektívna.Napríklad, ak niečo na webe odstraňujem a zobrazí sa mi potvrdzujúca správa s otázkou „Naozaj chcete odstrániť tento záznam?“ s možnosťami OK a Zrušiť - podľa mňa je kliknutie na zrušiť pozitívny prípad. Niektorí si však myslia, že je to negatívne, pretože primárnym zámerom možnosti „Odstrániť“ je operáciu odstrániť a nezrušiť. Pri klasifikácii teda zohráva úlohu aj úsudok testéra.
# 3) Pre každý pozitívny prípad nemusí vždy existovať rovnaký a opačný negatívny prípad.
Vyššie uvedená metóda vždy zaručuje správnu klasifikáciu. Vyskúšajte to sami a povedzte mi, ak to tak nie je. :) „Skratka je často nesprávny strih.“ - Ale v takom prípade to tak nemusí byť!
Pre formálnejšie vysvetlenie negatívneho testovania prosím skontrolujte => Čo je negatívne testovanie a ako písať prípady negatívnych testov?
O autorovi: Tento článok napísal člen tímu STH Swati S. Pripojte sa k jej živému školeniu QA tu: „ Najlepšie školenie o testovaní softvéru, aké kedy získate! „
Ak sa vám tento článok páčil a chcete vidieť nasledujúce základné pojmy, ktoré sa dajú ľahko vysvetliť v nasledujúcich článkoch, dajte nám vedieť.
Vaše pripomienky, otázky, spätná väzba a čítanosť sa tu na STH veľmi cení a oceňuje. Príjemné testovanie!
Odporúčané čítanie
- Pozitívne testovanie: význam a zásluhy vysvetlené pri scenároch skutočného testu
- Ako písať testovacie prípady pre prihlasovaciu stránku (vzorové scenáre)
- Čo je negatívne testovanie a ako písať prípady negatívnych testov?
- Ako písať testovacie prípady pre bankomat (vzorové scenáre)
- Efektívne scenáre selénu a riešenie problémov - scenáre selénu # 27
- Typy testovania migrácie: S testovacími scenármi pre každý typ
- Výukový program QTP # 24 - Používanie virtuálnych objektov a scenáre obnovy v testoch QTP
- Testovanie aplikácií v zdravotníctve - tipy a dôležité testovacie scenáre (2. časť)