Ahoj Habr! Raz na našom internom seminári môj vedúci, vedúci testovacieho oddelenia, začal svoju reč slovami „testovanie nie je potrebné“. Všetci v sále stíchli, niektorí sa dokonca pokúsili spadnúť zo stoličiek. Pokračoval vo svojej myšlienke: bez testovania je celkom možné vytvoriť zložitý a nákladný projekt. A s najväčšou pravdepodobnosťou to bude fungovať. Predstavte si však, o koľko istejšie sa budete cítiť s vedomím, že produkt funguje tak, ako má.
Na Badoo sa vydania vydávajú pomerne často. Napríklad serverová časť spolu s desktopovým webom vychádza dvakrát denne. Z prvej ruky teda vieme, že zložité a pomalé testovanie je kameň úrazu vývoja. Rýchle testovanie je požehnaním. Takže dnes budem hovoriť o tom, ako sa na Badoo organizuje testovanie dymu.
Čo je testovanie dymu
Tento termín prvýkrát použili kachliari, ktorí po zložení kachlí zatvorili všetky zátky, zatopili a zabezpečili, aby dym vychádzal iba z určených miest. WikipediaVo svojej pôvodnej aplikácii je testovanie dymom určené na testovanie najjednoduchších a najzrejmejších prípadov, bez ktorých by akýkoľvek iný typ testovania bol neoprávnene nadbytočný.
Pozrime sa na jednoduchý príklad. Predprodukčná verzia našej aplikácie sa nachádza na bryak.com (akákoľvek podobnosť so skutočnými stránkami je náhodná). Pripravili sme a nahrali sme tam nové vydanie na testovanie. Čo by ste mali skontrolovať ako prvé? Začal by som skontrolovaním, či sa aplikácia stále otvára. Ak nám webový server odpovie „200“, tak je všetko v poriadku a môžeme začať kontrolovať funkčnosť.
Ako automatizovať takúto kontrolu? V zásade môžete napísať funkčný test, ktorý zdvihne prehliadač, otvorí požadovanú stránku a uistí sa, že sa zobrazuje podľa očakávania. Toto riešenie má však množstvo nevýhod. Po prvé, je to dlhé: proces spustenia prehliadača bude trvať dlhšie ako samotné overenie. Po druhé, vyžaduje si to údržbu ďalšej infraštruktúry: na takýto jednoduchý test budeme musieť niekde ponechať server s prehliadačmi. Záver: problém musíme vyriešiť inak.
Náš prvý dymový test
Na Badoo je serverová strana napísaná väčšinou v PHP. Z pochopiteľných dôvodov sa v ňom píšu unit testy. Takže už máme PHPUnit. Aby sa technológie zbytočne nemnožili, rozhodli sme sa napísať dymové testy aj v PHP. Okrem PHPUnit budeme potrebovať klientsku knižnicu na prácu s URL (libcurl) a PHP rozšírenie na prácu s ňou – cURL.Testy v podstate jednoducho odosielajú požiadavky, ktoré potrebujeme, na server a kontrolujú odpovede. Všetko je viazané na metódu getCurlResponse() a niekoľko typov tvrdení.
Samotná metóda vyzerá asi takto:
Verejná funkcia getCurlResponse($url, pole $params = [ 'cookies' => , 'post_data' => , 'headers' => , 'user_agent' => , 'proxy' => , ], $follow_location = true, $ očakávaná_response = '200 OK') ( $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_HEADER, 1); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); if (isset( $params['cookies']) && $params['cookies']) ( $cookie_line = $this->prepareCookiesDataByArray($params['cookies']); curl_setopt($ch, CURLOPT_COOKIE, $cookie_line); ) ak ( isset($params['headers']) && $params['headers']) ( curl_setopt($ch, CURLOPT_HTTPHEADER, $params['headers']); ) if (isset($params['post_data']) && $params['post_data']) ( $post_line = $this->preparePostDataByArray($params['post_data']); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, $post_line); ) ak ($follow_location) ( curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); ) if (isset($params['proxy']) && $params['proxy']) ( curl_setopt($ch, CURLOPT_PROXY, $params['proxy ']);
Samotná metóda môže vrátiť odpoveď servera na základe danej adresy URL. Prijíma parametre ako vstup, ako sú súbory cookie, hlavičky, používateľský agent a ďalšie údaje potrebné na vytvorenie požiadavky. Keď je zo servera prijatá odpoveď, metóda skontroluje, či sa kód odpovede zhoduje s očakávaným. Ak tomu tak nie je, test zlyhá s chybou, ktorá to indikuje. To sa robí, aby sa uľahčilo určenie príčiny pádu. Ak test zlyhá pri niektorom tvrdení, ktoré nám hovorí, že na stránke nie je žiadny prvok, chyba bude menej informatívna ako správa, že kód odpovede je napríklad „404“ namiesto očakávaného „200“.
Po odoslaní požiadavky a prijatí odpovede žiadosť zaprotokolujeme, aby bolo možné v budúcnosti v prípade potreby jednoducho reprodukovať reťazec udalostí, ak test zlyhá alebo sa pokazí. Budem o tom hovoriť nižšie.
Najjednoduchší test vyzerá asi takto:
Verejná funkcia testStartPage() ( $url = ‘bryak.com’; $response = $this->getCurlResponse($url); $this->assertHTMLPresent("
Tento test trvá menej ako sekundu. Počas tejto doby sme overili, že úvodná stránka odpovedá „200“ a obsahuje prvok tela. S rovnakým úspechom môžeme otestovať ľubovoľný počet prvkov na stránke, dĺžka trvania testu sa výrazne nezmení.
Výhody takýchto testov:
- rýchlosť – test je možné spustiť tak často, ako je potrebné. Napríklad pri každej zmene kódu;
- na fungovanie nevyžadujú špeciálny softvér alebo hardvér;
- ľahko sa píšu a udržiavajú;
- sú stabilné.
Autorizácia
Predstavme si, že ubehli tri dni, odkedy sme napísali náš prvý dymový test. Počas tejto doby sme samozrejme pokryli všetky neautorizované stránky, ktoré sme našli, testami. Chvíľu sme sedeli, tešili sa, no potom sme si uvedomili, že za autorizáciou je všetko najdôležitejšie v našom projekte. Ako môžem získať príležitosť otestovať aj toto?
Najjednoduchšou možnosťou je autorizačný súbor cookie. Ak ho pridáme do požiadavky, server nás „rozpozná“. Takýto súbor cookie môže byť pevne zakódovaný v teste, ak je jeho životnosť pomerne dlhá, alebo ho možno získať automaticky odoslaním požiadaviek na autorizačnú stránku. Pozrime sa bližšie na druhú možnosť.
Zaujíma nás formulár, kde musíme zadať prihlasovacie meno a heslo používateľa.
Otvorte túto stránku v ľubovoľnom prehliadači a otvorte inšpektora. Zadajte údaje používateľa a odošlite formulár.
V inšpektorovi sa objavila požiadavka, ktorú potrebujeme v teste nasimulovať. Môžete vidieť, aké údaje sa okrem zrejmých údajov (prihlasovacie meno a heslo) odosielajú na server. Pre každý projekt je to iné: môže to byť vzdialený token, údaje z akýchkoľvek predtým prijatých súborov cookie, používateľský agent atď. Každý z týchto parametrov bude potrebné najskôr získať v teste pred vygenerovaním žiadosti o autorizáciu.
V nástrojoch pre vývojárov ľubovoľného prehliadača môžete žiadosť skopírovať tak, že vyberiete možnosť kopírovať ako cURL. V tomto formulári je možné príkaz vložiť do konzoly a zobraziť tam. Tam si to môžete vyskúšať zmenou alebo pridaním parametrov.
Ako odpoveď na takúto požiadavku nám server vráti cookies, ktoré pridáme k ďalším požiadavkám za účelom testovania autorizovaných stránok.
Keďže autorizácia je pomerne dlhý proces, navrhujem získať autorizačný súbor cookie iba raz pre každého používateľa a niekde ho uložiť. Takéto súbory cookie napríklad ukladáme do poľa. Kľúčom je prihlásenie používateľa a hodnotou informácie o ňom. Ak ešte neexistuje kľúč pre ďalšieho používateľa, prihláste sa. Ak existuje, okamžite urobíme požiadavku, ktorá nás zaujíma.
Verejná funkcia testAuthPage() ( $url = ‘bryak.com’; $cookies = $this->getAuthCookies(‘ [chránený e-mailom]', '12345');
$response = $this->getCurlResponse($url, [‘cookies’ => $cookies]);$this->assertHTMLPresent("
", $response, "Chyba: test nemôže nájsť prvok tela na stránke."); )
Metóda najprv skontroluje, či daný e-mail (vo vašom prípade môže ísť o prihlásenie alebo niečo iné) má predtým prijatý autorizačný súbor cookie. Ak existuje, vráti ho. Ak nie, odošle požiadavku na autorizačnú stránku (napríklad bryak.com/auth_page_adds) s potrebnými parametrami: e-mail používateľa a heslo. Ako odpoveď na túto požiadavku server odošle hlavičky, medzi ktorými sú súbory cookie, o ktoré máme záujem. Vyzerá to asi takto:
HTTP/1.1 200 OK Server: nginx Content-Type: text/html; charset=utf-8 Kódovanie prenosu: chunked Pripojenie: keep-alive Set-Cookie: name=value; expires=St, 30-Nov-2016 10:06:24 GMT; Max-Vek=-86400; cesta=/; doména=bryak.com
Z týchto hlavičiek pomocou jednoduchého regulárneho výrazu musíme získať názov súboru cookie a jeho hodnotu (v našom príklade je to názov=hodnota). Naša metóda, ktorá analyzuje odpoveď, vyzerá takto:
$this->assertTrue((bool)preg_match_all("/Set-Cookie: (([^=]+)=([^;]+);.*)\n/", $response, $mch1), " Nie je možné získať "cookies" z odpovede servera: " . $response);
Po prijatí súborov cookie ich môžeme bezpečne pridať k akejkoľvek žiadosti, aby bola autorizovaná.
Analýza neúspešných testov
Z vyššie uvedeného vyplýva, že takýto test je súbor požiadaviek na server. Podáme požiadavku, manipulujeme s odpoveďou, predkladáme ďalšiu požiadavku atď. Do hlavy sa mi vkráda myšlienka: ak takýto test zlyhá ani na desiatu žiadosť, nemusí byť ľahké zistiť príčinu jeho zlyhania. Ako si zjednodušiť život?V prvom rade by som chcel čo najviac poradiť atomizačné testy. V jednom teste by ste nemali testovať 50 rôznych prípadov. Čím jednoduchší test, tým jednoduchší bude v budúcnosti.
Užitočné je aj zbieranie artefaktov. Keď náš test zlyhá, uloží najnovšiu odpoveď servera do súboru HTML a hodí ju do úložiska artefaktov, kde je možné tento súbor otvoriť z prehliadača zadaním názvu testu.
Náš test napríklad zlyhal, pretože na stránke nenašiel kúsok kódu HTML:
Link
Ideme k nášmu zberateľovi a otvoríme príslušnú stránku:
S touto stránkou môžete pracovať rovnako ako s akoukoľvek inou HTML stránkou vo vašom prehliadači. Pomocou CSS lokátora sa môžete pokúsiť nájsť chýbajúci prvok a ak tam naozaj nie je, rozhodnúť, že sa buď zmenil, alebo je stratený. Možno sme našli chybu! Ak je prvok na svojom mieste, možno sme niekde v teste urobili chybu - musíme sa pozorne pozrieť týmto smerom.
Ťažba dreva tiež pomáha uľahčiť život. Snažíme sa zaznamenať všetky požiadavky vykonané neúspešným testom, aby sa dali ľahko zopakovať. Po prvé vám to umožňuje rýchlo vykonať súbor podobných akcií pomocou rúk na reprodukovanie chyby a po druhé vám to umožní identifikovať často zlyhávajúce testy, ak nejaké máme.
Okrem toho, že nám pomáhajú odstraňovať chyby, denníky opísané vyššie nám pomáhajú vytvárať zoznam autorizovaných a neautorizovaných stránok, ktoré sme testovali. Pri pohľade naň je ľahké nájsť a odstrániť medzery.
V neposlednom rade môžem poradiť, že testy by mali byť čo najpohodlnejšie. Čím ľahšie sa spúšťajú, tým častejšie sa budú používať. Čím jasnejšia a stručnejšia bude správa o páde, tým dôkladnejšie sa bude študovať. Čím je architektúra jednoduchšia, tým viac testov sa napíše a tým menej času zaberie napísanie nových.
Ak si myslíte, že používanie testov je nepohodlné, s najväčšou pravdepodobnosťou nie. Toto treba riešiť čo najskôr. V opačnom prípade riskujete, že v určitom bode začnete týmto testom venovať menšiu pozornosť, čo môže viesť k chybe vo výrobe.
Slovami sa myšlienka zdá zrejmá, súhlasím. Ale v skutočnosti máme všetci priestor na zlepšenie. Takže zjednodušte a optimalizujte svoje výtvory a žite bez chýb. :)
Výsledky
Momentálne máme *otvorený TimCity* wow, už 605 testov. Všetky testy, ak neprebiehajú paralelne, prejdú za menej ako štyri minúty.Počas tejto doby dbáme na to, aby:
- náš projekt sa otvára vo všetkých jazykoch (ktorých máme vo výrobe viac ako 40);
- pre hlavné krajiny sú zobrazené správne spôsoby platby s príslušnou sadou spôsobov platby;
- základné požiadavky API fungujú správne;
- vstupná stránka pre presmerovania funguje správne (aj na mobilnú stránku s príslušným užívateľským agentom);
- všetky interné projekty sa zobrazujú správne.
Pridajte značky
Dymové a hygienické testovanie začína ihneď po vydaní ďalšej verzie projektu. Pre mnohých mladých testerov sa tento proces javí ako absolútny chaos. Spoznávaš sa? Potom je tento článok určený práve vám. Teraz sa pozrieme na definície testovania dymu a sanitárneho testovania a ukážeme si rozdiely medzi nimi na ľahko pochopiteľných príkladoch.
Testovanie dymom sa vykonáva, aby sa zabezpečilo, že výsledná zostava je vhodná na testovanie. Nazýva sa aj overenie „nulového dňa“.
Tento typ testovania vám zabráni strácať čas. Je logické, že testovanie celej aplikácie nemá zmysel, ak sa vyskytnú problémy s kľúčovými charakteristikami a kritické chyby neboli opravené.
Hygienické testovanie:
Sanitárne testovanie sa vykonáva vo fáze vydania, aby sa skontrolovala základná funkčnosť aplikácie. Ďalej zvyčajne nejdú. Toto testovanie sa niekedy nazýva skrátená verzia regresného testovania.
Keď sú termíny vydania krátke, vykonanie dôkladného regresného testovania je takmer nemožné. V tomto prípade sanitárne testovanie robí skvelú prácu a kontroluje fungovanie hlavných funkcií aplikácie.
Príklad na lepšie pochopenie rozdielu medzi dymovým a hygienickým testovaním:
Existuje projekt, pre ktorý sa plánuje prvé vydanie. Vývojový tím uvoľní zostavu na testovanie a testovací tím začne pracovať. Úplne prvým testovaním je testovanie spôsobilosti. Musíte zistiť, či môžete pracovať s touto verziou alebo nie. Toto je testovanie dymom. Ak tím dá súhlas na ďalšiu prácu so zostavou, pošle sa do hlbších fáz testovania. Predstavme si, že zostava má tri moduly: „Prihlásenie“, „Správca“ a „Zamestnanec“. Tím testerov kontroluje funkčnosť iba základných funkcií každého modulu bez toho, aby zachádzal do detailov. Pôjde o hygienické testy.
Niekoľko ďalších rozdielov medzi dymovým a hygienickým testovaním:
- Testovanie dymu vykonávajú vývojári aj testeri;
- Sanitárne testovanie vykonávajú iba testeri.
- Testovanie dymom pokrýva všetky základné funkcie aplikácie od začiatku do konca;
- Sanitačné testovanie testuje iba konkrétny komponent aplikácie.
- Testovanie dymom prechádza stabilnými aj nestabilnými zostavami;
- Relatívne stabilná verzia zostavy prechádza sanitárnym testovaním.
Kirill Flyagin, herný dizajnér, vedúci QA
Urobme letnú analógiu s týmito typmi testovania. Povedzme, že si chcete kúpiť melón. Testovanie dymu je, keď to skontrolujete vizuálne, pozriete si prúžky, stlačíte, poklepete, vyhodnotíte. Sú majstri, ktorým sa takto podarí kúpiť naozaj chutné bobule. Pri sanitárnom testovaní vystrihnete pyramídu v hornej časti a skontrolujete jej farbu (ako jednu zo zložiek), ale vôbec neviete, či je taký celý melón. Ale v strihovej časti ste si úplne istí.
Preklad je riedený autorovými úvahami a doplnkami z vlastnej skúsenosti
O čo tu ide?
Ako testovací inžinier ste už určite počuli o testovaní dymom, testovaní zdravého rozumu, opätovnom testovaní a regresnom testovaní. Je dosť možné, že mnohé z týchto typov používate denne.V tomto článku by som chcel objasniť a vysvetliť rozdiel medzi týmito typmi testovania a pokúsiť sa na to prísť, vytýčiť hranice (aj keď podmienené), kde jeden typ testovania končí a druhý začína.
Pre tých, ktorí sú v testovaní noví (a dokonca aj pre skúsených testerov), môže byť oddelenie týchto konceptov ťažké. A naozaj, ako môžete zistiť, kde sa začína testovanie hygieny a kde končí testovanie dymu? Nakoľko potrebujeme obmedziť testovanie časti funkčnosti systému alebo jeho komponentov, aby sme to nazvali testovaním dymom? Je zadanie prihlasovacieho mena/hesla do prihlasovacieho formulára používateľa na stránke testom dymu, alebo je samotná skutočnosť jeho zobrazenia na stránke už úspešne vykonaným testom?
Presne povedané, stále budete môcť testovať, aj keď nebudete môcť presne povedať, aký je rozdiel. Nemusíte ani myslieť na rozlišovanie, aký typ testovania práve robíte. Ale stále, aby ste rástli nad seba v profesionálnom zmysle, musíte vedieť, čo robíte, prečo a ako správne to robíte.
Vzdelávací program
Nižšie sú uvedené stručné definície typov testovania, ktoré dnes porovnávame:- Dymové testy: sa vykonávajú vždy, keď dostaneme novú zostavu (verziu) projektu (systému) na testovanie, pričom ju považujeme za relatívne nestabilnú. Musíme zabezpečiť, aby kritické funkcie AUT (Application Under Test) fungovali podľa očakávania. Myšlienkou tohto typu testovania je identifikovať vážne problémy čo najskôr a odmietnuť túto zostavu (vrátiť na revíziu) v ranom štádiu testovania, aby ste sa nemuseli ponoriť do dlhých a zložitých testov, čím sa predíde strate času. na zjavne chybný softvér.
- Sanitárne testovanie: Používa sa vždy, keď získame relatívne stabilné zostavenie softvéru na podrobné určenie výkonu. Inými slovami, overuje sa, že dôležité časti funkčnosti systému fungujú podľa požiadaviek na nízkej úrovni.
- Otestujte znova: vykonáva sa v prípade, že funkcia/funkcia už mala chyby a tieto chyby boli nedávno opravené
- Regresné testy: čo vlastne zaberá leví podiel času a prečo existuje automatizácia testovania. Regresné testovanie AUT sa vykonáva vtedy, keď je potrebné uistiť sa, že nové (pridané) funkcie aplikácie / opravené chyby neovplyvnia súčasnú, už existujúcu funkčnosť, ktorá fungovala (a testovala) predtým.
| Dym | Zdravý rozum | Regresia | Otestujte znova |
|---|---|---|---|
| Vykonané na overenie, že kritické funkčné časti AUT fungujú podľa očakávania | Zamerané na zistenie, že určité časti AUT stále fungujú podľa očakávania po menších zmenách alebo opravách chýb | Potvrdzuje, že nedávne zmeny v kóde alebo aplikácii ako celku nemajú negatívny vplyv na existujúcu sadu funkcií/funkcií | Znova kontroluje a potvrdzuje skutočnosť, že predtým neúspešné testovacie prípady prejdú po odstránení chýb |
| Cieľom je skontrolovať „stabilitu“ systému ako celku s cieľom dať zelenú dôkladnejšiemu testovaniu | Cieľom je podrobne skontrolovať celkový stav systému, aby bolo možné pokračovať v dôkladnejšom testovaní | Cieľom je zabezpečiť, aby nové zmeny v kóde nemali vedľajšie účinky na zavedenú fungujúcu funkčnosť | Opätovným testom sa overí, či je chyba opravená |
| Opätovná kontrola defektov nie je cieľom Smoke | Opätovná kontrola defektov nie je cieľom Sanity | Opätovná kontrola defektov nie je účelom regresie | Skutočnosť, že chyba bola opravená, je potvrdená opätovným testom |
| Vykonané testovanie dymu predtým regresia | Vykonáva sa hygienické testovanie predtým regresia a po dymové testy | Vykonáva sa na základe požiadaviek projektu a dostupnosti zdrojov (uzavreté autotestami), „regresia“ sa môže vykonávať súbežne s opätovnými testami | - Pred testovaním zdravého rozumu sa vykoná opätovný test - Priorita opätovného testu je vyššia ako pri regresných kontrolách, preto sa musí vykonať pred nimi |
| Dá sa to urobiť automaticky alebo ručne | Najčastejšie ručne | Najlepší dôvod na automatizáciu tohto typu testovania je ten, že... manuál môže byť mimoriadne náročný na zdroje a čas | Nedá sa automatizovať |
| Je podmnožinou regresného testovania | Podmnožina akceptačných testov | Vykonáva sa pri akejkoľvek úprave alebo zmene v existujúcom projekte | Opätovný test sa vykonáva na opravenej zostave s použitím rovnakých údajov, v rovnakom prostredí, ale s inou sadou vstupných údajov |
| Testovacie prípady sú súčasťou prípadov regresného testovania, ale pokrývajú mimoriadne kritické funkcie | Sanitáciu je možné vykonať bez testovacích prípadov, vyžaduje sa však znalosť testovaného systému | Testovacie prípady regresného testovania je možné získať z funkčných požiadaviek alebo špecifikácií, používateľských príručiek a vykonávajú sa bez ohľadu na to, čo vývojári opravili. | Použije sa rovnaký testovací prípad, ktorý identifikoval chybu |
Ale v podstate?
Uvediem príklad rozdielu medzi pojmami v mojom aktuálnom projekte.Príklad: Máme webovú službu s užívateľským rozhraním a RESTful API. Ako testeri vieme:
- Že má 10 vstupných bodov, pre jednoduchosť v našom prípade umiestnených na rovnakej IP
- Vieme, že všetci akceptujú požiadavku GET na vstup a vrátia niektoré údaje vo formáte json.
- Vykonaním jednej jednoduchej požiadavky GET na jeden z týchto vstupných bodov a prijatím odpovede vo formáte json sme už presvedčení, že testovanie dymom prebehlo.
Ak jeden z týchto vstupných bodov vracia aj údaje z databázy, zatiaľ čo prvý nie, musíte dodatočne spustiť ďalší dotaz, aby ste sa uistili, že aplikácia
správne spracováva požiadavky do databázy. A tým je „dymový“ test dokončený.To znamená, že sme dokončili požiadavku - prišla odpoveď zo služby a „nefajčila“, to znamená, že namiesto json nevrátila chybu 4xx alebo 5xx a niečo vágne. V tomto bode môžeme povedať, že „dymový“ test bol úspešný. Ak chcete skontrolovať, či používateľské rozhranie funguje rovnakým spôsobom, stačí stránku otvoriť v prehliadači.
- Sanitárne testovanie bude v tomto prípade pozostávať z vykonania požiadavky na všetkých 10 vstupných bodov do api, kontroly prijatého json s očakávaným, ako aj prítomnosti požadovaných údajov v ňom.
- Regresné testy budú pozostávať z dymu + zdravého rozumu + používateľského rozhrania, ktoré budú bežať spolu na rovnakej hromade. Cieľ: skontrolujte, či pridanie 11. vstupného bodu nenarušilo napríklad obnovenie hesla.
- Opätovným testom v tomto príklade je kontrola bod po bode, či napríklad poškodený vstupný bod API v ďalšej zostave funguje tak, ako bolo zamýšľané.
Poďme si to zhrnúť
Dúfam, že po prečítaní tohto článku vám bude jasné, aký typ testovania v ktorej fáze používate a aký je rozdiel medzi týmito typmi testovania. Ako už bolo spomenuté na začiatku, hranica medzi týmito pojmami je veľmi ľubovoľná a zostáva na vašom uvážení v rámci projektu.UPD:
Často sa „testovanie konzistencie“ alebo „testovanie zdravého rozumu“ označuje ako „sanitárne testovanie“. Myslím si, že to vzniklo kvôli fonetickým vlastnostiam anglického slova sanity, ktoré je zvukovo podobné niečomu „sanitárnemu“. Prekladač Google prináša prehľadnosť. Obe možnosti sú dostupné na internete. Pokiaľ ide o tento článok, zvážte „sanitárne“ testovanie ako „testovanie konzistencie“.
dakujem za tip
Po vykonaní potrebných zmien, ako je oprava chyby/defektu, musí byť softvér znova otestovaný, aby sa potvrdilo, že problém bol skutočne vyriešený. Nasledujú typy testovania, ktoré je potrebné vykonať po inštalácii softvéru, aby sa potvrdila funkčnosť aplikácie alebo správnosť opravy chyby:
- Testovanie dymu(testovanie dymom)
- Regresné testovanie(Regresné testovanie)
- Testovanie zostavy(Test overenia zostavy)
- Hygienické testovanie alebo kontrola konzistencie/funkčnosti(Testovanie zdravého rozumu)
koncepcia dymové testovanie pochádzal z inžinierskeho prostredia. Pri uvádzaní nového zariadenia do prevádzky („hardvér“) sa test považoval za úspešný, ak z inštalácie nevychádzal žiadny dym. V oblasti testovania softvéru je zameraný na povrchovú kontrolu všetkých aplikačných modulov na funkčnosť a prítomnosť rýchlo zistených kritických a blokujúcich defektov. Na základe výsledkov testovania dymom sa urobí záver, či je nainštalovaná verzia softvéru prijatá na testovanie, prevádzku alebo dodanie zákazníkovi. Na uľahčenie práce, úsporu času a pracovnej sily sa odporúča implementovať automatizáciu testovacích skriptov pre testovanie dymom.
Regresné testovanie je typ testovania zameraný na overenie zmien vykonaných v aplikácii alebo prostredí (oprava defektu, zlúčenie kódu, migrácia na iný operačný systém, databázu, webový server alebo aplikačný server), aby sa potvrdilo, že už existujúca funkčnosť funguje tak, ako má (pozri tiež Sanitárne testovanie alebo testovanie konzistencie/funkčnosti). Regresie môžu byť podobné funkčný, tak a nefunkčné testy.
Na regresné testovanie sa spravidla používajú testovacie prípady napísané v počiatočných fázach vývoja a testovania. Tým sa zabezpečí, že zmeny v novej verzii aplikácie nepoškodia existujúcu funkčnosť. Odporúča sa automatizovať regresné testy, aby sa urýchlil následný proces testovania a odhalili sa defekty v počiatočných fázach vývoja softvéru.
Samotný pojem „regresné testovanie“ môže mať v závislosti od kontextu použitia rôzne významy. Opísal napríklad Sam Kaner 3 hlavné typy regresné testovanie:
- Regresia chýb– pokus dokázať, že opravená chyba nie je v skutočnosti opravená.
- Regresia starých chýb– pokus dokázať, že nedávna zmena kódu alebo údajov porušila opravu starých chýb, t.j. začali sa znova objavovať staré chrobáky.
- Regresia vedľajších účinkov– pokus dokázať, že nedávna zmena kódu alebo údajov narušila iné časti vyvíjanej aplikácie.
Testovanie zdravého rozumu – Ide o vysoko zamerané testovanie, ktoré je dostatočné na preukázanie, že konkrétna funkcia funguje tak, ako je špecifikované v špecifikácii. Je to podmnožina regresného testovania. Používa sa na určenie výkonu určitej časti aplikácie po zmenách v nej alebo v prostredí. Zvyčajne sa vykonáva ručne.
Rozdiel medzi sanitárnym testovaním a testovaním dymu. Niektoré zdroje sa mylne domnievajú, že sanitárne a dymové testy sú to isté. Veríme, že tieto typy testovania majú „vektory pohybu“, smery v rôznych smeroch. Na rozdiel od testovania dymom je testovanie Sanity zamerané do hĺbky na testovanú funkciu, zatiaľ čo testovanie dymu je zamerané do šírky, aby sa testami pokrylo čo najviac funkcií v čo najkratšom čase.
Testovanie zostavy Test overenia zostavy je testovanie zamerané na zistenie súladu vydanej verzie s kritériami kvality na začatie testovania. Svojimi cieľmi je obdobou Smoke Testingu, ktorého cieľom je prijatie novej verzie na ďalšie testovanie alebo prevádzku. Môže preniknúť hlbšie, v závislosti od požiadaviek na kvalitu vydanej verzie.
Testovanie inštalácie - zamerané na overenie úspešnej inštalácie a konfigurácie, ako aj na aktualizáciu alebo odinštalovanie softvéru. V súčasnosti je najbežnejším spôsobom inštalácie softvéru použitie inštalatéri(špeciálne programy, ktoré si tiež vyžadujú riadne testovanie). V reálnych podmienkach nemusia existovať inštalatéri. V takom prípade budete musieť softvér nainštalovať sami pomocou dokumentácie vo forme pokynov alebo súborov readme, ktoré krok za krokom popisujú všetky potrebné akcie a kontroly. V distribuovaných systémoch, kde je aplikácia nasadená v už spustenom prostredí, nemusí stačiť jednoduchý súbor inštrukcií. Na tento účel sa často píše inštalačný plán (Deployment Plan), ktorý zahŕňa nielen kroky na inštaláciu aplikácie, ale aj kroky na návrat k predchádzajúcej verzii v prípade zlyhania. Samotný inštalačný plán musí tiež prejsť skúšobným postupom, aby sa predišlo problémom pri uvedení do skutočnej prevádzky. To platí najmä vtedy, ak sa inštalácia vykonáva na systémoch, kde každá minúta výpadku znamená stratu reputácie a veľké množstvo finančných prostriedkov, napríklad: banky, finančné spoločnosti alebo dokonca bannerové siete. Testovanie inštalácie preto možno nazvať jednou z najdôležitejších úloh pri zabezpečovaní kvality softvéru.
Práve tento komplexný prístup s písaním plánov, testovaním inštalácie krok za krokom a vrátením inštalácie možno právom nazvať testovaním inštalácie alebo testovaním inštalácie.
Jednoduché chyby môžu byť pre vašu stránku fatálne – najmä ak ste spoločnosť využívajúca SaaS (angl. Software as a Service) ako my. Ak používateľ príde na vašu stránku a nemôže dokončiť jednoduchú úlohu, ako je registrácia alebo obnovenie zabudnutého hesla, riskujete, že tohto používateľa stratíte navždy.
Zažili sme to ťažko. Mať v tíme vlastných ľudí, ktorí aplikáciu testujú a hľadajú chyby, je samozrejme dôležité, no nie vždy je to vhodné a dostatočne dôkladné. V tomto článku vás, humanistov, chceme zaviesť do sveta dymových testov.
Ak máte stále otázky, môžete vyplniť medzery návštevou
Testovanie dymom bolo pôvodne vynájdené, aby vysvetlilo, ako elektrotechnici testovali, či ich spotrebič funguje zapnutím a či vychádza dym...
Počkať, ako sa to týka aplikácií?
Dôležitosť (a nákladová efektívnosť) dymových testov je manažérom a spoluzakladateľom humanitných vied vo všeobecnosti neznáma. Systematické dymové testy možno považovať za neoddeliteľnú súčasť, aby sa zabránilo zvýšeniu pravdepodobnosti hackingu. Minimalizujú možnosť zlyhania vašej webovej alebo telefónnej aplikácie – a ako všetci vieme, stačí jedno zlyhanie a môžete stratiť zákazníka navždy.
Toto je úvodná príručka o tom, čo to je, ako sa dá implementovať, aké zdroje sa používajú na jej vykonanie a príklady, ktoré čitateľom pomôžu.
Testy dymu sú určené na testovanie základnej funkčnosti a mali by byť neoddeliteľnou súčasťou vášho testovacieho procesu. Môžu zahŕňať niečo také jednoduché ako „Môžem sa zaregistrovať?“
Testovanie dymu pomáha zabezpečiť, aby žiadna z hlavných a zjavných porúch nebola ponechaná náhode. Nemali by ste robiť hlbší test, kým nie ste 100% hotový s dymovými testami, pretože odstraňujú základné chyby softvéru.
Krok 1: Rozhodnite sa, čo chcete testovať
Definujte, čo chce vaša aplikácia dosiahnuť. Aké sú najzrejmejšie detské kroky potrebné na to, aby ste sa tam dostali? Aké sú minimálne nevyhnutné požiadavky a v akom logickom poradí by ste ich uviedli?
Vytvorte testovaciu sadu. Testovacia sada je zoskupená zbierka testovacích prípadov (testovacie prípady), ktoré súvisia určitým spôsobom (napríklad funkčnosťou).
Testovanie dymu nebude zahŕňať premenné ani otázky typu „čo ak?“. Predpokladá len odpovede áno/nie, no pred prechodom na podrobnejšie testovanie musia všetky testovacie prípady prejsť s pozitívnym výsledkom.
Vezmime si ako príklad vytvorenie interaktívneho fóra. Aby to fungovalo, musím:
- registrovať.
- vytvoriť Používateľské meno.
- nahrajte fotku do svojho avatara.
- písať správy.
- odpovedať na správy.
Krok 2: Zaznamenajte výsledky do tabuľky
Obrázok vyššie je príkladom z nášho tímu. Šablónu nájdete. Je to potrebné na to, aby sme si evidovali, čo nám funguje a čo nie – základná organizácia ušetrí v budúcnosti veľa času. Naše výsledky sme rozdelili na úspešné, čiastočné a neúspešné.
- Úspešné: všetko funguje perfektne.
- Čiastočne: Možno si spočiatku neuvedomujete, že niektoré činnosti môžu byť ďalej rozdelené tak, že jedna časť funguje a druhá nie.
- Zlyhalo: Nefunguje.
Opísali sme presné kroky, ktoré sme chceli reprodukovať, a potom sme v ďalšom stĺpci pridali krátky popis toho, čo sme očakávali ako výstup. Príklad:
Krok 3: Automatizujte testy dymu
Je veľmi dôležité nebrať to ako axiómu, že ak sa nejaká akcia raz dokončí, vždy bude mať pozitívny výsledok. Testy dymu vám umožňujú nepretržite kontrolovať, či základné funkcie neboli poškodené v priebehu času alebo zlomené počas dlhého obdobia.
Neprestávajte testovať dym. Nikdy.
Keď sa vaša sada testovacích prípadov pre testovanie dymom dokončí s úspešným výsledkom 100%, premýšľajte o ich automatizácii. Odporúčaná frekvencia vykonávania dymových testov je každý deň, ak sa vaša spoločnosť vyvíja každý deň.
Minimálnou požiadavkou je spustenie dymových testov pred každým vydaním a po každom patchi.
Základné pravidlo pre test dymom:
- Minimálny čas: 30 minút.
- Maximálny čas: 60 minút.
Z dlhodobého hľadiska automatizácia dymových testov šetrí čas, no pri opakovanom opakovaní rovnakých testov si ľudské oko môže prestať všímať detaily, ale stroj nie.