Nudný blog testerov: Negatívne scenáre testovania. Skúšobný obrázok pre negatívne a pozitívne myslenie Testované produkty získali pozitívne

Pri testovaní softvérový produkt používa sa obrovské množstvo rôzne druhy testy. Najširšiu a najpodrobnejšiu klasifikáciu navrhol autor knihy „Testing Dot Com“ Roman Savin. Kombinoval typy testovania podľa takých charakteristík, ako je objekt, predmet testovania, úroveň, pozitivita testovania a stupeň automatizácie testovania. Klasifikácia bola doplnená na základe takých zdrojov, ako je kniha Sama Kanera „Testovanie softvéru“ a online zdroj venovaný testovaniu „O testovaní – Testovanie softvéru“.

Testovaním objektu

· Funkčné testovanie. Funkčné testovanie je dnes jedným z najčastejšie používaných typov testovania. Účelom takéhoto testovania je zistiť, do akej miery vyvinutý softvér spĺňa požiadavky zákazníka z hľadiska funkčnosti. Inými slovami, vykonávanie funkčných testov vám umožňuje skontrolovať schopnosť informačný systém vyriešiť používateľské problémy.
· Nefunkčné testovanie. Umožňuje kontrolovať súlad vlastností softvéru so zadanými nefunkčnými požiadavkami. Nefunkčné testovanie je teda testovanie všetkých vlastností programu, ktoré nesúvisia s funkčnosťou systému. Takéto vlastnosti môžu byť prezentované charakteristikami z hľadiska parametrov, ako sú:
- Spoľahlivosť (schopnosť systému reagovať na neočakávané situácie).
- Výkon (schopnosť systému pracovať pri veľkom zaťažení).
- Pohodlie (študovanie používateľskej jednoduchosti používania s aplikáciou).
- Škálovateľnosť (možnosť škálovať aplikáciu vertikálne aj horizontálne).
- Bezpečnosť (výskum možnosti narušenia aplikácie a odcudzenia používateľských dát útočníkmi).
- Prenosnosť (možnosť preniesť aplikáciu na špecifickú sadu platforiem)

A mnoho ďalších vlastností.

· Testovanie užívateľské rozhranie. Ide o testovanie správneho zobrazenia prvkov používateľského rozhrania na rôzne zariadenia, správnosť ich reakcie na používateľa, ktorý vykonáva rôzne akcie, ako aj posúdenie očakávaného správania programu ako celku. Takéto testovanie umožňuje vyhodnotiť, ako efektívne a nakoľko bude môcť používateľ s aplikáciou pracovať vzhľad aplikácie zodpovedá schváleným dokumentom vytvoreným projektantmi. Pri testovaní používateľského rozhrania je hlavnou úlohou testera identifikovať vizuálne a štrukturálne chyby v grafickom rozhraní aplikácie, overiť schopnosť a jednoduchosť navigácie v aplikácii a zabezpečiť, aby aplikácia spracovávala vstup z klávesnice, myši a iných vstupov. zariadenia správne. Testovanie používateľského rozhrania je potrebné na to, aby sa zabezpečilo, že rozhranie vyhovuje schváleným požiadavkám a normám, a aby s ním používateľ mohol pracovať grafické rozhranie aplikácie.
· Testovanie použiteľnosti. Ide o testovaciu metódu, ktorá umožňuje vyhodnotiť mieru jednoduchosti používania aplikácie, rýchlosť učenia sa používateľa pri práci s programom a tiež to, nakoľko ho používatelia vyvíjaného produktu považujú za zrozumiteľný a atraktívny v kontexte dané podmienky. Takéto testovanie je potrebné na zabezpečenie čo najpozitívnejšej používateľskej skúsenosti pri práci s aplikáciou.
· Testovanie bezpečnosti. Umožňuje identifikovať hlavné softvérové zraniteľnosti v súvislosti s rôznymi útokmi narušiteľov. Počítačové systémy Pomerne často sú predmetom kybernetických útokov s cieľom narušiť chod informačného systému alebo odcudziť dôverné údaje. Bezpečnostné testovanie umožňuje analyzovať skutočnú reakciu a účinnosť obranných mechanizmov používaných v systéme pri pokuse o prienik. Počas testovania bezpečnosti sa tester pokúša vykonať rovnaké akcie, aké by vykonal skutočný útočník. Keď sa tester pokúsi hacknúť systém, môže byť použitý akýkoľvek prostriedok: napadnutie systému pomocou špeciálne služby; pokúša sa zistiť prihlasovacie údaje a heslá pomocou externých prostriedkov; DDOS útoky; cielené generovanie chýb na zistenie možnosti prieniku do systému počas procesu jeho obnovy; zneužitie známych neopravených systémových zraniteľností.
· Testovanie inštalácie. Tento pojem znamená testovanie správnosti inštalácie (inštalácie) určitého softvérového produktu. Takéto testovanie zvyčajne prebieha v umelo vytvorených prostrediach s cieľom zistiť stupeň pripravenosti softvéru na použitie. Hlavné dôvody na vykonávanie takýchto testov súvisia s potrebou overiť správne správanie sa softvérového produktu počas automatizovaného nasadenia alebo aktualizácie. Zabezpečenie správnej a stabilnej inštalácie softvéru je veľmi dôležitým faktorom pri vytváraní softvérového produktu, pretože umožňuje používateľom začať produkt používať rýchlejšie a s menšou námahou a zároveň zabezpečiť, aby sa produkt správal rovnako správne vo všetkých testovaných softvérových prostrediach.
· Testovanie konfigurácie. Testovanie konfigurácie je určené na vyhodnotenie výkonu softvéru v rôznych systémových konfiguráciách. V závislosti od typu testovaného softvérového produktu môže testovanie konfigurácie slúžiť na rôzne účely. Zvyčajne ide buď o určenie optimálnej hardvérovej konfigurácie, ktorá poskytuje dostatočné výkonové parametre pre fungovanie softvéru, alebo o kontrolu určitej hardvérovej konfigurácie (alebo platformy, ktorá okrem hardvéru zahŕňa aj softvér tretích strán potrebný na spustenie programu) na kompatibilitu s testovaným produktom. Ak hovoríme o o klient-server softvér, potom sa testovanie konfigurácie vykoná zvlášť pre server a zvlášť pre klienta. Zvyčajne pri testovaní kompatibility servera s konkrétnou konfiguráciou je úlohou nájsť optimálnu konfiguráciu, pretože stabilita a výkon servera sú dôležité. Kým pri testovaní klienta sa naopak snažia identifikovať softvérové nedostatky v akejkoľvek konfigurácii a pokiaľ je to možné, odstrániť ich.
· Testovanie spoľahlivosti a zotavenie sa z porúch (záťažové testovanie). Tento typ testovania sa pomerne často vykonáva pre softvér, ktorý pracuje s cennými používateľskými údajmi, ktorých nepretržitá prevádzka a rýchlosť zotavenia sa z porúch sú pre používateľa kritické. Testovanie zlyhania a obnova testuje schopnosť programu rýchlo a úspešne sa zotaviť zo zlyhania hardvéru, výpadkov siete alebo kritických chýb v samotnom softvéri. To umožňuje posúdiť možné následky poruchy a čas potrebný na následnú obnovu systému. Na základe údajov získaných počas testovania možno posúdiť spoľahlivosť systému ako celku a v prípade neuspokojivého výkonu možno prijať vhodné opatrenia zamerané na zlepšenie systémov obnovy.
· Testovanie lokalizácie. Lokalizačné testovanie umožňuje zistiť, ako dobre je produkt prispôsobený obyvateľstvu určitých krajín a ako dobre zodpovedá jeho kultúrnym charakteristikám. Typicky sa berú do úvahy kultúrne a jazykové nuansy, konkrétne preklad používateľského rozhrania, sprievodnej dokumentácie a súborov do konkrétneho jazyka, testuje sa aj správnosť formátov mien, čísel, časov a telefónnych čísel.
· Záťažové testovanie. Testovanie záťaže vám umožňuje identifikovať maximálny počet podobných úloh, ktoré môže program vykonávať paralelne. Najpopulárnejším účelom testovania záťaže v kontexte aplikácií klient-server je odhad maximálneho počtu používateľov, ktorí môžu súčasne využívať služby aplikácie.
· Testovanie stability. Testovanie stability preveruje funkčnosť aplikácie pri dlhodobom používaní pri miernom zaťažení. V závislosti od typu aplikácie sa vytvárajú určité požiadavky na dobu jej nepretržitej prevádzky. Testovanie stability sa snaží identifikovať nedostatky aplikácie, ako sú úniky pamäte, prítomnosť výrazného nárastu záťaže a ďalšie faktory, ktoré môžu zabrániť aplikácii pracovať na dlhú dobu.
· Testovanie objemu. Úlohou objemového testovania je identifikovať odozvu aplikácie a posúdiť možné zhoršenie prevádzky softvéru s výrazným zvýšením množstva dát v databáze aplikácie. Toto testovanie zvyčajne zahŕňa:
- Meranie času vykonávania operácií súvisiacich so získavaním alebo zmenou databázových údajov pri určitej intenzite požiadavky.
- Identifikácia závislosti predĺženia prevádzkového času od objemu dát v databáze.
- Stanovenie maximálneho počtu používateľov, ktorí môžu súčasne pracovať s aplikáciou bez znateľného oneskorenia z databázy.
Testovanie škálovateľnosti. Ide o typ testovania softvéru určeného na testovanie schopnosti produktu zväčšiť (alebo niekedy zmenšiť) určité nefunkčné funkcie. Niektoré typy aplikácií musia byť ľahko škálovateľné a zároveň, samozrejme, zostať funkčné a vydržať určitú užívateľskú záťaž.

Testovanie súvisiace so zmenami

· Príčetnosť je jedným z typov testovania, ktorého účelom je preukázať výkon konkrétnej funkcie alebo modulu v súlade s technickými požiadavkami uvedenými zákazníkom. Sanitárne testovanie sa pomerne často používa na testovanie niektorej časti programu alebo aplikácie, keď sa v nej vykonajú určité zmeny v dôsledku environmentálnych faktorov. Tento typ testovanie sa zvyčajne vykonáva ručne.
· Testovanie dymom je krátka séria testov, ktorých účelom je potvrdiť, že nainštalovaná aplikácia je spustená a vykonáva funkcie po vytvorení nového alebo upraveného kódu. Po ukončení testovania najdôležitejších segmentov aplikácie sú poskytnuté objektívne informácie o prítomnosti alebo neprítomnosti chýb v prevádzke testovaných segmentov. Na základe výsledkov testovania dymu sa rozhodne, či žiadosť poslať na vylepšenie, alebo ju treba otestovať naplno.
· Regresné testovanie – testovanie zamerané na odhalenie chýb v už testovaných oblastiach. Regresné testovanie kontroluje, či produkt neobsahuje chyby, ktoré sa mohli objaviť v dôsledku pridania novej časti programu alebo opravy iných chýb. Účelom tohto typu testovania je zabezpečiť, aby aktualizácia zostavy alebo oprava chýb neviedla k novým chybám.

Podľa úrovne testovania

· Testovanie jednotiek (Unit testy). Pozostáva z kontroly každého jednotlivého modulu (originálneho prvku systému) spustením automatizovaných testov v umelom prostredí. Implementácia takýchto testov často využíva rôzne stuby a ovládače na simuláciu fungovania reálneho systému. Automatizované testovanie jednotiek je úplne prvou príležitosťou na spustenie a kontrolu zdrojového kódu. Vytvorenie Unit testov pre všetky moduly systému umožňuje veľmi rýchlo identifikovať chyby v kóde, ktoré sa môžu objaviť počas vývoja.
· Testovanie integrácie. Ide o testovanie jednotlivých modulov systému na správnu interakciu. Hlavným cieľom integračného testovania je nájsť defekty a identifikovať nesprávne správanie spojené s chybami v interpretácii alebo implementácii interakcie medzi modulmi.
· Testovanie systému. Ide o testovanie programu ako celku, takéto testovanie overuje, či program spĺňa uvedené požiadavky.
· Akceptačné testovanie. Ide o komplexný test, ktorý zisťuje skutočnú úroveň pripravenosti systému na prevádzku. koncových užívateľov. Testovanie sa vykonáva na základe súboru testovacích scenárov pokrývajúcich hlavné obchodné operácie systému.

Spustením kódu

· Statické testovanie. Ide o identifikáciu artefaktov, ktoré sa objavujú počas vývoja softvérového produktu analýzou zdrojových súborov, ako je dokumentácia alebo programový kód. Takéto testovanie sa vykonáva bez priameho spustenia kódu kvalita zdrojových súborov a ich súlad s požiadavkami sa posudzuje manuálne alebo pomocou pomocné nástroje. Statické testovanie by sa malo vykonať pred dynamickým testovaním, takže chyby zistené počas fázy statického testovania budú lacnejšie. Z pohľadu zdrojový kód, statické testovanie je vyjadrené v revízii kódu. Zvyčajne revízia kódu samostatné súbory je vykonávaná po každej zmene týchto súborov programátorom, ale samotnú revíziu môže vykonať buď iný programátor, alebo vedúci vývojár, alebo individuálny zamestnanec zaoberajúci sa revíziou kódu. Použitie statického testovania umožňuje udržiavať kvalitu softvéru vo všetkých fázach vývoja a skracuje čas vývoja produktu.
· Dynamické testovanie. Na rozdiel od statického testovania tento typ testovania zahŕňa spustenie zdrojového kódu aplikácie. Dynamické testovanie teda obsahuje mnoho ďalších typov testovania, ktoré už boli popísané vyššie. Dynamické testovanie vám umožňuje identifikovať chyby v správaní programu analýzou výsledkov jeho vykonávania. Ukazuje sa, že takmer všetky existujúce typy testovania zodpovedajú triede dynamického testovania.

Podľa testovacieho predmetu

· Alfa testovanie. Toto testovanie sa vykonáva pre väčšinu staršie verzie počítačový softvér (alebo hardvérové zariadenie). Alfa testovanie takmer vždy vykonávajú samotní vývojári softvéru. Počas procesu alfa testovania vývojári aplikácií nachádzajú a opravujú chyby a problémy v programe. Väčšinou pri Alpha testovaní dochádza k napodobňovaniu práce s programom zo strany vývojárov na plný úväzok, menej často prebieha reálna práca potenciálnych užívateľov aj zákazníkov s produktom. Alfa testovanie sa spravidla vykonáva v najskoršom štádiu vývoja softvéru, ale v v niektorých prípadoch možno použiť pre hotový alebo takmer hotový výrobok, napríklad ako akceptačné testovanie.
· Beta testovanie. Testovanie produktu, ktorý je stále vo vývoji. V beta testovaní je tento produkt sprístupnený malému počtu používateľov, aby mohli študovať a hlásiť vznikajúce problémy, s ktorými sa používatelia stretávajú. Takéto testovanie je potrebné na nájdenie chýb, ktoré vývojári mohli prehliadnuť. Beta testovanie sa zvyčajne vykonáva v dvoch fázach: uzavreté beta testovanie a otvorené beta testovanie. Uzavretý beta test testuje prísne obmedzený okruh vybraných používateľov. Takýmito používateľmi môžu byť známi vývojárov, prípadne ich kolegovia, ktorí priamo nesúvisia s vývojom testovaného produktu. Otvorené beta testovanie pozostáva z vytvárania a odosielania otvorený prístup verejná beta. IN v tomto prípade každý používateľ môže pôsobiť ako beta tester. Spätná väzba z takýchto beta testerov sa vykonáva pomocou recenzií na stránke a systémov analýzy a protokolovania akcií používateľov zabudovaných do programu, tieto systémy sú potrebné na analýzu správania používateľov a zisťovanie ťažkostí a chýb, s ktorými sa stretávajú;

Podľa pozitivity scenára

· Pozitívne testovanie. Testy s pozitívnym scenárom kontrolujú schopnosť programu vykonávať zamýšľanú funkčnosť. Spravidla sa pre takéto testovanie vyvíjajú testovacie scenáre, ktorých vykonávanie by za normálnych prevádzkových podmienok pre softvér nemalo spôsobovať žiadne ťažkosti.
· Negatívne testovanie. Negatívne testovanie softvéru sa vyskytuje v scenároch, ktoré zodpovedajú abnormálnemu správaniu programu. Takéto testy kontrolujú správnu činnosť programu v núdzových situáciách. To vám umožňuje zabezpečiť, aby program produkoval správne chybové hlásenia, nepoškodil používateľské údaje a vo všeobecnosti sa správal správne v situáciách, v ktorých nie je zamýšľané normálne správanie produktu. Hlavným cieľom negatívneho testovania je preveriť odolnosť systému voči rôznym vplyvom, schopnosť správne validovať vstupné dáta a zvládať výnimočné situácie, ktoré vznikajú ako v samotných softvérových algoritmoch, tak aj v obchodnej logike.

Podľa stupňa automatizácie

· Manuálne testovanie. Manuálne testovanie sa vykonáva bez použitia ďalších softvér, umožňuje vám testovať program alebo webovú stránku simuláciou akcií používateľa. V tomto modeli tester vystupuje ako používateľ, ktorý sleduje špecifické skripty a súčasne analyzuje výstup programu a celkové správanie.
· Automatizované testovanie. Takéto testovanie umožňuje pomocou dodatočného softvéru na automatizáciu testovania výrazne urýchliť proces testovania. Takýto doplnkový softvér vám umožňuje sledovať a riadiť vykonávanie testov a porovnávať očakávané a skutočné výsledky programu. Podrobnejšie sa o tom bude diskutovať neskôr.

Článok bol revidovaný s ohľadom na kritiku a odporúčania prijaté vo fóre.

Týmto článkom by som chcel opísať moje chápanie testovania softvéru – procesu, ktorý nie je triviálny, ako sa mi vždy zdal, a ani som si nevedel predstaviť, že je veľmi zaujímavý.

Vždy ma zaujímalo, čo je testovanie softvéru. Prečo najímať niekoho na testovanie softvérového produktu, ak samotný vývojár môže stráviť pár hodín pri takejto úlohe s nízkou prioritou. A nakoniec, prečo vôbec testovať? Koniec koncov, programátori sú chytrí chlapi - píšu správne. Ale

nie je všetko také jednoduché ako sa mi zdalo.

Po prechode od programátorov k testerom bez toho, aby som mal dostatok teórie, som strávil pomerne dlhý čas pokusmi „rozbiť“ softvérový produkt poskytnutím zámerne nesprávnych vstupných údajov. A napodiv sa to zlomilo. Vygenerovalo sa chybové hlásenie a ďalší deň sa považoval za neprežitý nadarmo.

Neskôr som sa začal stretávať s tým, že bez ohľadu na to, koľko testov spustím, chyby sa stále objavujú. Bez akejkoľvek predstavy o tom, čo a ako by sa malo poskytnúť ako vstup do testovanej aplikácie, sa proces testovania zdal nekonečný. Výsledkom je začarovaný kruh, v ktorom sa nedodržiavajú termíny testovania, nahnevaný PM a vývojári unavení z „nezmyslov“ sú unavení.

A až oveľa neskôr som pre seba identifikoval jasnú postupnosť akcií, ktoré je potrebné vykonať na testovanie softvéru:

Preštudujte si špecifikáciu. Táto fáza je najdôležitejšia, nazýva sa tiež návrhová a/alebo analýza požiadaviek. Niekedy sa používa názov „testovanie špecifikácií“ o niečo neskôr pochopíme, prečo „testovanie“. Tu si musíte pozorne prečítať dokumentáciu (špecifikáciu) k aplikácii.
Testovanie dymu. V tejto fáze je potrebné skontrolovať, či systém vôbec funguje (či funguje správne, či správne „nadáva“, ak nefunguje správne atď.). To sa robí s cieľom pochopiť, či je aplikácia vhodná na ďalšie testovanie alebo či vôbec nefunguje (nepracuje správne).
"Pozitívne" testovanie. V tejto tretej fáze je potrebné skontrolovať výsledok aplikácie, keď dostane „správne“ vstupné údaje.
"Negatívne" testovanie. Toto je štvrtá a posledná fáza počiatočného testovania. Tu musíte vidieť, ako sa aplikácia správa, keď dostane „nesprávne“ údaje ako vstup. Toto sa robí s cieľom určiť, ako sa aplikácia v tomto prípade správa. Ak je takáto možnosť opísaná v špecifikácii a mala by byť opísaná, porovnajte očakávaný výsledok so získaným výsledkom.

Poďme sa teda pozrieť na všetko v poriadku.

Špecifikácia, požiadavky, SRS.

Ako určiť, kedy a ako má samotná aplikácia fungovať, kedy a ako sa má „pokaziť“ (teda ako má systém alebo jeho modul reagovať na neplatné údaje alebo nesprávne správanie používateľa)? Čo by malo byť výsledkom správneho spracovania, za akých podmienok a vstupných údajov má prebehnúť správne spracovanie? Čo by sa malo stať v dôsledku nesprávneho vykonania testovanej aplikácie, za akých podmienok by k tomu malo dôjsť?

Všetky tieto otázky sú zodpovedané v dokumentácii testovanej aplikácie. V každom prípade tam musí byť odpoveď, inak dokumentácia nie je úplná, čo znamená chybu v dokumentácii. Upozorňujem, že už v tejto fáze môžu nastať prvé chyby - chyba v špecifikácii (v požiadavkách) je pre systém rovnako dôležitá (a niekedy aj vyšší prednostne!) defekt. Za zmienku tiež stojí, že testovanie požiadaviek je plnohodnotným typom testovania, ktorému sa nezaslúžene venuje malá pozornosť. Hlavnými indikátormi úspešného testovania požiadaviek je splnenie kritérií úplnosti (testovateľnosti) a konzistentnosti požiadaviek.

Dokumentácia vám umožňuje pochopiť hlavné kroky testovania aplikácie, kde a ako by mala aplikácia fungovať a kde sa „zlomí“. A čo je rovnako dôležité, Ako prestávka. Čo „povedať“, keď je testovanie úspešné, aké chybové hlásenia sa môžu/mali objaviť počas testovania.

Po pochopení celej „múdrosti“ požiadaviek na aplikáciu a vlastností implementácie týchto požiadaviek vývojárom môžete začať testovať konečný výsledok.

Proces testovania

Tento proces možno opísať v nasledujúcich krokoch:

Skontrolujte, ako aplikácia funguje, keď dostane „správne“ údaje ako vstup (ak chcete zistiť, „čo je dobré a čo zlé“, prečítajte si dokumentáciu);
Ak všetko funguje a funguje správne (t. j. presne tak, ako je popísané v špecifikácii), ďalším krokom je kontrola hraničných hodnôt (t. j. kde začínajú a kde končia „správne“ údaje);
Kontrola fungovania aplikácie pri zadávaní údajov, ktoré nie sú v rozsahu prijateľných hodnôt (znova si pozrite špecifikáciu).

Prvý a druhý odsek opisujú proces nazývaný „pozitívne“ testovanie. „Pozitívne“ testovanie je testovanie údajov alebo scenárov, ktoré zodpovedajú normálnemu (štandardnému, očakávanému) správaniu testovaného systému.

Tretí bod popisuje opačný proces ako „pozitívne“ – „negatívne“ testovanie. Ide o testovanie na dátach alebo scenároch, ktoré zodpovedajú abnormálnemu správaniu testovaného systému – rôzne chybové hlásenia, výnimočné situácie, „prehnané“ stavy atď.

„Pozitívnemu“ a „negatívnemu“ testovaniu však musí predchádzať testovanie „dymom“.

Informačný slovník poskytuje pomerne jasnú definíciu pojmu „testovanie dymom“:

rudimentárna forma testovania softvérového produktu po zmene jeho konfigurácie alebo po jeho zmene (softvérového produktu) samotného. Počas testovania dymom tester kontroluje softvér na prítomnosť „dymu“, t.j. hľadá nejaký kritické chyby programy;
prvé spustenie programu po jeho kritickej zmene alebo „zostavení“.

Priority testovania

Prečo sa „pozitívne“ testovanie považuje za rádovo dôležitejšie ako „negatívne“ testovanie?

Predpokladajme, že systém nie je veľmi odolný voči „zlým“ vstupným údajom. Je to desivé? Často nie príliš. Používatelia sa skôr či neskôr naučia obísť „ úskalia“, nebude robiť „nebezpečné“ alebo „neoprávnené“ akcie, službu technickú podporuČoskoro si spomenie, aké problémy majú používatelia zvyčajne a poradí ako „v žiadnom prípade nenechávajte toto pole prázdne, inak...“.

Ale toto všetko sa vôbec nestane, ak systém neplní svoj hlavný účel, ak používatelia (zákazníci) nedokážu vyriešiť svoje obchodné problémy, ak všetko urobia správne, zadajú dobré údaje, ale nedostanú výsledky. A v tejto situácii im nemožno nič radiť. A odchádzajú...

To je dôvod, prečo je „pozitívne“ testovanie oveľa, oveľa dôležitejšie ako „negatívne“.

To však neznamená, že „negatívne“ testy možno zanedbať, pretože Hodnotové priority nezostávajú nezmenené vo všetkých fázach životného cyklu softvéru.

Obnoviť

Teraz, keď ste urobili prvé úspešné kroky pri testovaní aplikácie a získali pozitívny výsledok, môžete premýšľať o sofistikovanejších spôsoboch testovania aplikácie, ako sa hovorí: „Čoraz viac. Všetko závisí od hĺbky požadovanej úrovne testovania, túžby a schopnosti testovať aplikáciu. Prirodzene, štyri fázy opísané vyššie nepokrývajú celý cyklus testovania aplikácie, ale sú povinné pre počiatočné testovanie.

My (nie je to až také tajomstvo) sa veľmi obávame o kvalitu našich produktov a s obavami sledujeme kolaps systému. To ospravedlňuje existenciu testerov vo svete. Vďaka tomu sa cítime ako hrdinovia: prišiel skvelý tester a zachránil svojich používateľov pred hroznými kritickými chybami!

A naši testeri nikdy nezabudnú na negatívne testovanie, hoci nie všetci pokročilí sú z toho nadšení. Takéto kontroly však nie sú rozmarom „zlých testerov“; sú spôsobené potrebou uzavrieť zraniteľné miesta a chrániť pred hackermi a robotmi vstupujúcimi do systému, útokmi Dos/DDos.

Samozrejme, aké je povolanie testovacích špecialistov? Musíme nájsť problémy. Problémy, nad ktorými najčastejšie nikto nemá čas premýšľať, nikto ich nechce vidieť ani sa nimi zaoberať. A ak sa preverí nielen správnosť fungovania systému, ale aj jeho abnormálne správanie, tak sa pridá napätie v tíme.

Vidíte, programátori píšu softvér, zameraný na výsledok, na plánované vydanie, letiaci na krídlach inšpirácie! A tu prichádza fáza kontroly a početných opráv a úprav „ideálneho“ kódu. A to je všetko, niekde sa schovajte, systém sa testuje.

Aby to nikoho nedráždilo, niektorí špecialisti môžu negatívne testovanie odložiť na neskôr alebo ho úplne ignorovať (hrôza!), aby skrátili termíny a rozpočty. Prečo teda kontrolovať, či program nerobí to, čo by mal, však? nie.

Pozitívne a negatívne testovanie

Ale prvé veci. Pri testovaní softvéru pomocou testovacích prípadov existujú dve skupiny kontrol: pozitívna a negatívna. Navyše, tých druhých je zvyčajne viac ako tých prvých.

Pozitívne testovanie- ide o kontrolu prevádzky systému z hľadiska zhody s jeho bežným (štandardným, očakávaným) správaním, podľa technických špecifikácií a. To znamená, že sa tu pozrieme na to, či softvér robí to, čo sa od neho očakáva, či implementácia spĺňa moderné požiadavky, či sú podporované pokyny pre používateľské rozhranie atď.

A negatívne testovanie- toto je testovanie systému na abnormálne správanie. Pozeráme sa na to, či je softvér odolný voči nesprávnemu zadávaniu údajov, ako sa riešia výnimočné situácie, aké informácie sa zobrazujú v chybových hláseniach, či je možné narušiť fungovanie produktu a/alebo ovplyvniť výkon riešenia a pod. na.

Už sme povedali, že niektorí špecialisti nechávajú negatívne testovanie na neskôr alebo naň úplne zabudnú, čo je takmer to isté. Viete, to, čo sa odkladá na neskôr, zostáva takmer vždy nesplnené.

Preto podľa nášho názoru

Negatívne a pozitívne testovanie nie je potrebné oddeľovať a rozdeľovať v čase.

Pretože môžeme povedať, že systém funguje tak, ako má, ak testujeme iba jeho odozvu na správne vstupy?

Pozitívne-negatívne testovanie

Pri testovaní, ach, aká dôležitá je intuícia, inštinkty, lovecké inštinkty – nazvite si to ako chcete. A tu sedí náš inžinier a kontroluje napríklad registračný formulár.

Všetko skontroluje podľa špecifikácií a testovacích scenárov, sleduje, ako sa spracovávajú údaje, ktoré musí používateľ zadať do polí (mimochodom to nie je fakt, ktorý zadá) a potom je to tu - náhľad! Zdá sa mu, že ak do tohto prihlasovacieho poľa zadá nejaké „%adynadyn/>“ a nie obyčajný text, tak sa určite niečo stane. Niečo temné a ponuré nie je v poriadku.

a čo? Musí si povedať: „Nie. Práve teraz musím urobiť pozitívny test a nič iné. Na budúci týždeň mám negatívny termín, potom príde čas na %adynadyn/>. Možno"?

Sme presvedčení, že tento prístup k negatívnemu testovaniu je neefektívny, a preto:

Ak robíte pozitívne a negatívne testovanie oddelene, bude to trvať dlhšie. Prinajmenšom preto, že to už budú dve iterácie testovania.
Testeri a kóderi žijú v termínoch. A ak je čas prísne obmedzený, potom odloženie negatívneho testu na neskôr zvyšuje riziko, že sa naň nakoniec zabudne. Koniec koncov, čím bližšie k okamihu X, tým rýchlejšie čas letí, tým skôr musíte dokončiť zadané úlohy, opraviť chyby, aplikovať konečné obchodné požiadavky (ktoré sa môžu zmeniť) a dokončiť kopu ďalších vecí. Termín - zaneprázdnený čas!
Oddelenie negatívneho a pozitívneho testovania je podľa nás jednoducho v rozpore s povahou testera! Koniec koncov, jeho hlavnou úlohou je skontrolovať systém na všetko. možné akcie koncového užívateľa. Ale ľudia sú väčšinou nelogickí a môžu so softvérom robiť všetky druhy obscénnych vecí;)

Ako testeri máme veľké obavy, ak systém obsahuje chyby v kontrolách, ktoré spadajú do negatívnej kategórie. A najmä ak sú dôsledky takýchto chýb kritické pre celý systém. Ale nebojíme sa ich nahlásiť. Najmä s takýmto esom v rukáve – v tíme máme testerky. A kto dokáže tvrdohlavo brániť „ideálnosť“ kódu, keď jemnými hlasmi trhá výkon projektu na márne kúsky? To isté.

Aké závery teda môžeme vyvodiť?

Nezabudnite na negatívne testovanie, kombinujte ho s pozitívnym testovaním, zhromaždite skúsených špecialistov do tímu a pokúste sa presunúť reportovanie na plecia dievčat! Všetko okrem posledného odporúčame na 100% a váš projektový manažér to vyrieši.

A, samozrejme, nezabudnite skontrolovať svoj produkt, nemyslite si, že programátori okamžite napíšu čistý a krásny kód - stále sa nezaobídete bez chýb! Nehovoriac o početných zraniteľnostiach, ktorých dôkazom sú osobné a dôverné údaje, ktoré pravidelne unikajú do siete.

Prečo ľudia podstupujú psychologické testy? Prirodzene, každý má svoje motívy. Niekto chce pochopiť sám seba a „pochopiť, kto som“. Niekto si chce potvrdiť svoj existujúci názor na svoj charakter. Niektorí jednoducho zabijú svoj voľný čas a zabávajú sa. Ale každý, aj keď často bez toho, aby si to uvedomoval, teda čisto, chce o sebe počuť niečo dobré. za čo? Áno, pretože to zlepšuje náladu. Test, ktorý vám odporúčame absolvovať, má jediný účel, priniesť trochu pozitivity do vášho súčasného stavu. V skutočnosti to vôbec nie je test, ale niečo ako pozitívna predpoveď. A ako viete, veľmi často sa splnia!

06.10.2018 16947 +67

Chcete vedieť, ako vaše meno vnímajú iní ľudia? Zadarmo online službu Fonosemantická analýza vám umožňuje zistiť, ako je konkrétne slovo vnímané na podvedomej úrovni. S jeho pomocou môžete napríklad vybrať meno pre dieťa alebo meno do firmy.
Zistite, ako sa budete cítiť o mesiac! Práve teraz si na našej stránke môžete vypočítať svoje biorytmy úplne zadarmo. Na základe výsledkov výpočtu dostanete osobné odporúčania a harmonogram zmien biorytmov na ďalší mesiac.
Populárne psychologické testy Obrovské množstvo populárnych psychologických testov pre každý vkus. Pre mužov, pre ženy, ezoterické, profesionálne... A to všetko online, zadarmo a bez registrácie!

Veľmi znepokojený kvalitou výrobkov. To vysvetľuje celosvetovú dostupnosť softvérových testerov. Poskytovaním títo ľudia zabezpečujú jeho kvalitu.

Mnoho testerov nikdy nezabudne na negatívne testovanie, aj keď nie všetci programátori sú z toho nadšení. Takáto kontrola je potrebná na ochranu pred hackermi, botmi, útokmi Dos/DDos.

Aké je povolanie špecialistov na testovanie? Musia nájsť problémy, ktoré nie sú viditeľné pre ostatných. Neváhajte s negatívnym testovaním, inak vystavujete systém nebezpečenstvu.

Pozitívne a negatívne testovanie

Začnime od začiatku. Keď sú testovacie prípady zahrnuté do testovania, existujú 2 typy kontroly: pozitívna a negatívna. Ten druhý má výhodu.

Pozitívne testovanie je proces kontroly správneho správania podľa technických požiadaviek a dokumentácie. Pozitívne testovanie sa vykonáva, aby sa zabezpečilo, že systém robí presne to, čo sa očakáva.

Negatívne testovanie je proces kontroly nesprávneho správania. Takýmto testovaním sa môžeme naučiť, že systém si dokáže poradiť aj s neočakávanými situáciami.

Pozitívne-negatívne testovanie

Na testovanie softvéru potrebujete mať intuíciu alebo lovecký inštinkt. Špecialista na testovanie je všestranný človek, ktorý dokáže vykonávať obchodnú analýzu aj testovanie.

Testeri kontrolujú, či sa proces vykonáva správne: či je v súlade s technickými požiadavkami a testovacími scenármi. Vykonanie pozitívneho a negatívneho testovania oddelene bude trvať dlhšie ako ich vykonanie súčasne. Je to preto, že existujú dve testovacie iterácie.

Koniec koncov, čím viac sa blíži hodina X, tým rýchlejšie plynie čas a tým skôr je potrebné dokončiť úlohy, opraviť chyby, uplatniť obchodné požiadavky (ktoré sa môžu líšiť) a urobiť oveľa viac. Termín je najteplejší čas!

Oddelenie negatívneho a pozitívneho testovania je jednoducho v rozpore s povahou testera! Jeho úlohou je kontrolovať systém na všetky možné akcie koncového užívateľa.

Ľudia sú vo všeobecnosti nelogickí a môžu spôsobiť problémy v softvéri. Negatívne testovanie pomôže vyhnúť sa problémom.

Tematické materiály: