Vrste testiranja, povezane s spremembami

Pozdravljeni, Habr! Nekoč na našem internem seminarju je moj nadrejeni, vodja oddelka za testiranje, začel svoj govor z besedami "testiranje ni potrebno." Vsi v dvorani so utihnili, nekateri so celo poskušali pasti s stolov. Nadaljeval je svojo misel: brez testiranja je povsem mogoče ustvariti kompleksen in drag projekt. In najverjetneje bo delovalo. Toda predstavljajte si, koliko bolj samozavestni se boste počutili, ko boste vedeli, da izdelek deluje, kot bi moral.

Na Badooju se izdaje dogajajo precej pogosto. Na primer, strežniški del, skupaj z namiznim spletom, se sprosti dvakrat na dan. Iz prve roke torej vemo, da je kompleksno in počasno testiranje kamen spotike pri razvoju. Hitro testiranje je blagoslov. Torej, danes bom govoril o tem, kako je testiranje dima organizirano na Badooju.

Kaj je testiranje dima

Ta izraz so prvi uporabljali štedilniki, ki so, ko so sestavili peč, zaprli vse čepe, jo zalili in poskrbeli, da se je kadilo le iz za to določenih mest. Wikipedia

Dimno testiranje je v svoji prvotni uporabi namenjeno testiranju najenostavnejših in najočitnejših primerov, brez katerih bi bilo vsako drugo testiranje neupravičeno odveč.

Poglejmo preprost primer. Predprodukcijska različica naše aplikacije se nahaja na bryak.com (vse podobnosti z resničnimi spletnimi mesti so naključne). Tja smo pripravili in naložili novo izdajo za testiranje. Kaj morate najprej preveriti? Začel bi s preverjanjem, ali se aplikacija še odpira. Če nam spletni strežnik odgovori "200", potem je vse v redu in lahko začnemo preverjati delovanje.

Kako avtomatizirati takšno preverjanje? Načeloma lahko napišete funkcionalni test, ki bo dvignil brskalnik, odprl želeno stran in se prepričal, da se prikaže po pričakovanjih. Vendar ima ta rešitev številne pomanjkljivosti. Prvič, dolgo je: postopek zagona brskalnika bo trajal dlje kot samo preverjanje. Drugič, to zahteva vzdrževanje dodatne infrastrukture: za tako preprost test bomo morali nekje obdržati strežnik z brskalniki. Sklep: problem moramo rešiti drugače.

Naš prvi test dima

Pri Badooju je strežniška stran napisana večinoma v PHP. Iz očitnih razlogov so v njem zapisani testi enot. PHPUnit torej že imamo. Da ne bi po nepotrebnem množili tehnologij, smo se odločili, da dimne teste pišemo tudi v PHP. Poleg PHPUnita bomo potrebovali odjemalsko knjižnico za delo z URL-ji (libcurl) in PHP razširitev za delo z njo - cURL.

V bistvu testi strežniku preprosto pošljejo zahteve, ki jih potrebujemo, in preverijo odgovore. Vse je vezano na metodo getCurlResponse() in več vrst trditev.

Sama metoda izgleda nekako takole:

Javna funkcija getCurlResponse($url, array $params = [ 'cookies' => , 'post_data' => , 'headers' => , 'user_agent' => , 'proxy' => , ], $follow_location = true, $ pričakovan_odziv = '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); ) if ( 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); ) če ($follow_location) ( curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); ) if (isset($params['proxy']) && $params['proxy']) ( curl_setopt($ch, CURLOPT_PROXY, $params['proxy') ']);
Sama metoda lahko vrne odgovor strežnika na podlagi podanega URL-ja. Kot vhod sprejema parametre, kot so piškotki, glave, uporabniški agent in drugi podatki, potrebni za oblikovanje zahteve. Ko prejme odgovor s strežnika, metoda preveri, ali se odzivna koda ujema s pričakovano. Če temu ni tako, preizkus ne uspe z napako, ki to kaže. To se naredi za lažje ugotavljanje vzroka padca. Če test ne uspe pri neki trditvi, ki nam pove, da na strani ni nobenega elementa, bo napaka manj informativna kot sporočilo, da je odzivna koda na primer »404« namesto pričakovane »200«.

Ko je zahteva poslana in prejet odgovor, zahtevo zabeležimo, tako da je v prihodnosti, če je potrebno, enostavno reproducirati verigo dogodkov, če test ne uspe ali se prekine. O tem bom govoril spodaj.

Najenostavnejši test izgleda nekako takole:

Javna funkcija testStartPage() ( $url = ‘bryak.com’; $response = $this->getCurlResponse($url); $this->assertHTMLPresent("
Ta preizkus traja manj kot sekundo. V tem času smo preverili, ali se začetna stran odziva z »200« in ima element body. Z enakim uspehom lahko testiramo poljubno število elementov na strani, trajanje testa se ne bo bistveno spremenilo.

Prednosti takih testov:

• hitrost – test je mogoče izvesti tako pogosto, kot je potrebno. Na primer, za vsako spremembo kode;
• za delovanje ne potrebujejo posebne programske ali strojne opreme;
• jih je enostavno napisati in vzdrževati;
• so stabilni.

Glede zadnje točke. Mislim nič manj stabilen kot sam projekt.

Pooblastilo

Predstavljajmo si, da so minili trije dnevi, odkar smo pisali naš prvi dimni test. Seveda smo v tem času s testi pokrili vse neavtorizirane strani, ki smo jih našli. Nekaj ​​časa smo posedeli, se veselili, potem pa ugotovili, da je vse najpomembnejše v našem projektu za avtorizacijo. Kako lahko dobim priložnost preizkusiti tudi to?

Najenostavnejša možnost je avtorizacijski piškotek. Če ga dodamo v zahtevo, nas bo strežnik »prepoznal«. Takšen piškotek je mogoče trdo kodirati v testu, če je njegova življenjska doba precej dolga, ali pa ga pridobiti samodejno s pošiljanjem zahtev avtorizacijski strani. Oglejmo si podrobneje drugo možnost.

Zanima nas obrazec, kjer moramo vpisati uporabniško ime in geslo.

Odprite to stran v katerem koli brskalniku in odprite inšpektor. Vnesite uporabniške podatke in oddajte obrazec.

V inšpektorju se je pojavila zahteva, ki jo moramo simulirati v testu. Vidite lahko, kateri podatki so poleg očitnih (prijava in geslo) poslani na strežnik. Za vsak projekt je drugačen: lahko je oddaljeni žeton, podatki iz vseh prej prejetih piškotkov, uporabniški agent itd. Vsakega od teh parametrov bo treba najprej pridobiti v testu, preden ustvarite zahtevo za avtorizacijo.

V orodjih za razvijalce katerega koli brskalnika lahko kopirate zahtevo tako, da izberete kopijo kot možnost cURL. V tej obliki lahko ukaz vstavite v konzolo in si ga tam ogledate. Tam ga lahko preizkusite tako, da spremenite ali dodate parametre.

Kot odgovor na tako zahtevo nam bo strežnik vrnil piškotke, ki jih bomo dodali nadaljnjim zahtevam za testiranje avtoriziranih strani.

Ker je avtorizacija precej dolg proces, predlagam, da avtorizacijski piškotek pridobite samo enkrat za vsakega uporabnika in ga nekje shranite. Takšne piškotke na primer shranimo v polje. Ključ je prijava uporabnika, vrednost pa podatki o njem. Če še ni ključa za naslednjega uporabnika, se prijavite. Če obstaja, takoj podamo zahtevo, ki nas zanima.

Javna funkcija testAuthPage() ( $url = 'bryak.com'; $cookies = $this->getAuthCookies(' [e-pošta zaščitena]', '12345'); $response = $this->getCurlResponse($url, ['piškotki' => $piškotki]);
$this->assertHTMLPresent("

", $response, "Napaka: test ne najde elementa telesa na strani."); )
Metoda najprej preveri, ali ima določeno e-poštno sporočilo (v vašem primeru je to lahko prijava ali kaj drugega) predhodno prejet avtorizacijski piškotek. Če obstaja, ga vrne. Če ne, pošlje zahtevo avtorizacijski strani (na primer bryak.com/auth_page_adds) s potrebnimi parametri: uporabniški e-poštni naslov in geslo. Kot odgovor na to zahtevo strežnik pošlje glave, med katerimi so piškotki, ki nas zanimajo. Videti je nekako takole:

HTTP/1.1 200 OK Strežnik: nginx Content-Type: text/html; charset=utf-8 Transfer-Encoding: chunked Povezava: keep-alive Set-Cookie: name=value; expires=sre, 30. november 2016 10:06:24 GMT; Največja starost=-86400; pot=/; domena=bryak.com
Iz teh glav moramo z uporabo preprostega regularnega izraza pridobiti ime piškotka in njegovo vrednost (v našem primeru je to ime=vrednost). Naša metoda, ki razčleni odgovor, je videti takole:

$this->assertTrue((bool)preg_match_all("/Set-Cookie: (([^=]+)=([^;]+);.*)\n/", $response, $mch1), " Ni mogoče dobiti "piškotkov" iz odgovora strežnika: " . $response);
Ko so piškotki prejeti, jih lahko varno dodamo vsaki zahtevi, da jo odobrimo.

Analiza neuspešnih testov

Iz zgoraj navedenega sledi, da je tak test niz zahtev do strežnika. Postavimo zahtevo, manipuliramo z odgovorom, naredimo naslednjo zahtevo in tako naprej. V glavo se mi prikrade misel: če takšen test ne uspe že na deseto zahtevo, morda ne bo lahko ugotoviti vzroka njegovega neuspeha. Kako si poenostaviti življenje?

Najprej bi rad čim bolj svetoval teste atomizacije. Ne bi smeli testirati 50 različnih primerov v enem testu. Enostavnejši ko je test, lažji bo v prihodnosti.

Koristno je tudi zbiranje artefaktov. Ko naš test ne uspe, shrani zadnji odziv strežnika v datoteko HTML in ga vrže v shrambo artefaktov, kjer je to datoteko mogoče odpreti iz brskalnika, tako da določite ime testa.

Na primer, naš preizkus ni uspel, ker na strani ni našel dela HTML:

Povezava
Gremo do našega zbiralnika in odpremo ustrezno stran:

S to stranjo lahko delate tako kot z vsako drugo stranjo HTML v brskalniku. Z lokatorjem CSS lahko poskusite najti manjkajoči element in, če ga res ni, ugotovite, da se je spremenil ali izgubil. Morda smo našli napako! Če je element na svojem mestu, smo morda nekje pri testu naredili napako - moramo skrbno pogledati v to smer.

Tudi sečnja pomaga olajšati življenje. Poskušamo zabeležiti vse zahteve, ki jih je povzročil neuspeli test, tako da jih je mogoče enostavno ponoviti. Prvič, to vam omogoča, da z rokami hitro izvedete niz podobnih dejanj, da poustvarite napako, in drugič, omogoča vam, da prepoznate pogosto neuspešne teste, če jih imamo.

Poleg tega, da nam pomagajo pri odpravljanju napak, nam zgoraj opisani dnevniki pomagajo ustvariti seznam pooblaščenih in nepooblaščenih strani, ki smo jih preizkusili. Z ogledom je enostavno najti in odpraviti vrzeli.

Nenazadnje lahko svetujem, da naj bodo testi čim bolj priročni. Lažje jih je zagnati, pogosteje jih bomo uporabljali. Čim bolj jasno in jedrnato bo poročilo o padcu, tem natančneje ga bomo preučili. Čim preprostejša je arhitektura, tem več testov bo napisanih in manj časa bo trajalo pisanje novih.

Če menite, da je uporaba testov neprijetna, najverjetneje ne. To je treba rešiti čim prej. V nasprotnem primeru tvegate, da boste na neki točki začeli posvečati manj pozornosti tem testom, kar lahko privede do napake, ki bo izpuščena v proizvodnji.

Z besedami se zdi ideja očitna, se strinjam. Toda v resnici imamo vsi prostor za izboljšave. Zato poenostavite in optimizirajte svoje kreacije in živite brez napak. :)

Rezultati

Trenutno imamo *odprt TimCity* wow, že 605 testov. Vsi testi, če ne potekajo vzporedno, potekajo v nekaj manj kot štirih minutah.

V tem času poskrbimo, da:

• naš projekt se odpre v vseh jezikih (od katerih jih imamo več kot 40 v produkciji);
• za glavne države so prikazani pravilni načini plačila z ustreznim naborom načinov plačila;
• osnovne zahteve API delujejo pravilno;
• ciljna stran za preusmeritve deluje pravilno (vključno z mobilno stranjo z ustreznim uporabniškim agentom);
• vsi interni projekti so prikazani pravilno.

Testi na Selenium WebDriver bi za vse to zahtevali večkrat več časa in sredstev.

Dodajte oznake

Dimno in sanitarno testiranje se začne takoj po izdaji naslednje različice projekta. Za mnoge mlade preizkuševalce se ta proces zdi kot popoln kaos. Se prepoznaš? Potem je ta članek za vas. Zdaj si bomo ogledali definicije testiranja dima in sanitarnega testiranja ter z lahko razumljivimi primeri prikazali razlike med njima.

Izvede se testiranje dima, da se zagotovi, da je nastala zgradba primerna za testiranje. Imenuje se tudi preverjanje "ničelnega dne".

Ta vrsta testiranja vam bo preprečila izgubo časa. Logično je, da testiranje celotne aplikacije ni smiselno, če obstajajo težave s ključnimi lastnostmi in kritične napake niso odpravljene.

Sanitarni pregled:

Sanitarno testiranje se izvede v fazi izdaje, da se preveri osnovna funkcionalnost aplikacije. Ponavadi ne gredo dlje. To testiranje včasih imenujemo skrajšana različica regresijskega testiranja.
Ko so roki za izdajo kratki, je izvajanje temeljitega regresijskega testiranja skoraj nemogoče. V tem primeru sanitarno testiranje odlično opravi svoje delo, saj preverja delovanje glavnih funkcij aplikacije.

Primer za boljše razumevanje razlike med testiranjem dima in sanitarnim testiranjem:

Obstaja projekt, za katerega je načrtovana prva izdaja. Razvojna skupina izda gradnjo za testiranje in ekipa za testiranje začne z delom. Prvo testiranje je preverjanje sposobnosti. Ugotoviti morate, ali lahko delate s to različico ali ne. To je testiranje dima. Če ekipa da zeleno luč za nadaljnje delo z gradnjo, se ta pošlje v globlje faze testiranja. Predstavljajmo si, da ima zgradba tri module: »Prijava«, »Administrator« in »Zaposleni«. Skupina preizkuševalcev preverja funkcionalnost le osnovnih funkcij vsakega modula, ne da bi se spuščala v podrobnosti. To bo sanitarno testiranje.

Še nekaj razlik med dimnim in sanitarnim testiranjem:

• Testiranje dima izvajajo razvijalci in preizkuševalci;
• Sanitarno testiranje izvajajo samo testerji.

• Preskušanje dima pokriva vse osnovne funkcije aplikacije od začetka do konca;
• Sanitarno testiranje testira samo določeno komponento aplikacije.

• Preskušanje dima prestane tako stabilne kot nestabilne zgradbe;
• Razmeroma stabilna različica zgradbe je podvržena sanitarnemu testiranju.

Kirill Flyagin, oblikovalec iger, QA Lead

Naredimo poletno analogijo s temi vrstami testiranj. Recimo, da želite kupiti lubenico. Testiranje dima je, ko ga vizualno preverite, pogledate trakove, stisnete, potrkate, ocenite. Obstajajo mojstri, ki jim na ta način uspe kupiti res okusne jagode. Pri sanitarnem testiranju izrežeš piramido na vrhu in preveriš njeno barvo (kot enega od sestavnih delov), pa sploh ne veš, ali je cela lubenica takšna. Toda v odrezanem delu ste popolnoma prepričani.

Prevod je razredčen z avtorjevimi razmišljanji in dodatki iz lastnih izkušenj

Kaj je to?

Kot testni inženir ste verjetno že slišali za testiranje dima, testiranje razumnosti, ponovno testiranje in regresijsko testiranje. Povsem mogoče je, da veliko teh vrst uporabljate vsak dan.

V tem članku bi rad razjasnil in razložil razliko med temi vrstami testiranja in jo poskušal ugotoviti, narisati meje (čeprav pogojne), kje se ena vrsta testiranja konča in začne druga.

Za tiste, ki so novi pri testiranju (in celo za izkušene preizkuševalce), je lahko ločevanje teh konceptov težko. In res, kako lahko ugotovite, kje se sanitarno testiranje začne in kje se konča testiranje dima? Koliko moramo omejiti testiranje dela funkcionalnosti sistema ali njegovih komponent, da bi temu rekli smoke test? Ali je vnos prijave/gesla v obrazec za prijavo uporabnika na spletnem mestu preizkus dima ali je že samo dejstvo, da se pojavi na strani spletnega mesta, opravljen test?

Strogo gledano, boste še vedno lahko testirali, čeprav ne boste mogli natančno povedati, kakšna je razlika. Sploh vam ni treba razmišljati o razlikovanju, katero vrsto testiranja trenutno opravljate. A vseeno, da bi zrasel nad samim seboj v profesionalnem smislu, moraš vedeti, kaj delaš, zakaj in kako pravilno to počneš.

Izobraževalni program

Spodaj so kratke definicije vrst testiranja, ki jih danes primerjamo:

• Preskusi dima: izvajajo se vsakič, ko prejmemo novo gradnjo (različico) projekta (sistema) v testiranje, pri čemer jo smatramo za razmeroma nestabilno. Zagotoviti moramo, da kritične funkcije AUT (Application Under Test) delujejo po pričakovanjih. Ideja te vrste testiranja je prepoznati resne težave čim prej in zavrniti to gradnjo (vrnitev v revizijo) v zgodnji fazi testiranja, da se ne poglabljamo v dolge in zapletene teste, s čimer se izognemo izgubi časa na očitno okvarjeno programsko opremo.
• Sanitarno testiranje: Uporabljeno vsakič, ko dobimo razmeroma stabilno različico programske opreme za podrobno določitev zmogljivosti. Z drugimi besedami, potrjuje, da pomembni deli funkcionalnosti sistema delujejo po zahtevah na nizki ravni.

Obe vrsti testiranja sta namenjena izogibanju izgubljenemu času in trudu, da bi hitro ugotovili pomanjkljivosti programske opreme in njihovo kritičnost ter ali si zasluži prehod v fazo bolj poglobljenega in temeljitega testiranja ali ne.

• Ponovno preizkusite: izvede se, če je funkcija/funkcionalnost že imela napake in so bile te napake nedavno odpravljene
• Regresijski testi: kaj pravzaprav vzame levji delež časa in zakaj obstaja avtomatizacija testiranja. Regresijsko testiranje AUT se izvede, ko se je treba prepričati, da nove (dodane) funkcije aplikacije / odpravljene napake ne vplivajo na trenutno, že obstoječo funkcionalnost, ki je delovala (in testirala) prej.

Za boljše razumevanje je spodaj predstavljena primerjalna tabela teh konceptov in področij uporabe:

dim	Zdrav razum	Regresija	Ponovno preizkusite
Izvedeno za preverjanje, ali kritični funkcionalni deli AUT delujejo po pričakovanjih	Namenjen ugotavljanju, ali nekateri deli AUT še vedno delujejo po pričakovanjih po manjših spremembah ali popravkih napak	Potrjuje, da nedavne spremembe kode ali aplikacije kot celote nimajo negativnega vpliva na obstoječo funkcionalnost/nabor funkcij	Ponovno preveri in potrdi dejstvo, da so predhodno neuspešni testni primeri uspešni, potem ko so napake odpravljene
Cilj je preveriti "stabilnost" sistema kot celote, da bi dali zeleno luč za temeljitejše testiranje	Cilj je podrobno preveriti splošno zdravje sistema, da bi lahko nadaljevali s temeljitejšim testiranjem	Cilj je zagotoviti, da sveže spremembe kode nimajo stranskih učinkov na vzpostavljeno delujočo funkcionalnost	Ponovni test potrdi, da je napaka odpravljena
Ponovno preverjanje napak ni cilj družbe Smoke	Ponovno preverjanje napak ni cilj Sanityja	Ponovno preverjanje napak ni namen regresije	Dejstvo, da je bila napaka odpravljena, potrdi Re-Test
Opravljeno testiranje dima prej regresija	Izvaja se sanitarni pregled prej regresijo in po testi dima	Izvaja se na podlagi projektnih zahtev in razpoložljivosti virov (zaprto s samodejnimi testi), "regresijo" pa je mogoče izvesti vzporedno s ponovnimi testi	- Ponovni test se izvede pred preizkusom zdrave pameti - Prav tako je prednost ponovnega testa višja od regresijskih pregledov, zato ga je treba izvesti pred njimi
Lahko se izvede samodejno ali ročno	Najpogosteje ročno	Najboljši razlog za avtomatizacijo te vrste testiranja je, ker... priročnik je lahko zelo potraten z viri in časom	Ni mogoče avtomatizirati
Je podnabor regresijskih testiranj	Podmnožica sprejemnega testiranja	Izvaja se za kakršne koli modifikacije ali spremembe v obstoječem projektu	Ponovni test se izvede na popravljenem sestavu z uporabo istih podatkov, v istem okolju, vendar z drugačnim nizom vhodnih podatkov
Testni primeri so del regresijskih testnih primerov, vendar pokrivajo izjemno kritično funkcionalnost	Sanitacijo je mogoče izvesti brez testnih primerov, vendar je potrebno poznavanje sistema, ki se preskuša	Testne primere regresijskega testiranja je mogoče pridobiti iz funkcionalnih zahtev ali specifikacij, uporabniških priročnikov in se izvajajo ne glede na to, kaj so popravili razvijalci	Uporabljen je isti testni primer, ki je identificiral napako

Ampak v bistvu?

Podal bom primer razlikovanja med pojmi v svojem trenutnem projektu.

Primer: imamo spletno storitev z uporabniškim vmesnikom in RESTful API. Kot preizkuševalci vemo:

• Da ima 10 vstopnih točk, zaradi poenostavitve, ki se v našem primeru nahajajo na istem IP-ju
• Vemo, da vsi sprejmejo zahtevo GET za vnos in vrnejo nekatere podatke v formatu json.

Nato je mogoče podati številne izjave o tem, katere vrste testov je treba uporabiti v katerem trenutku:

• Z izvedbo ene preproste zahteve GET na eno od teh vstopnih točk in prejemom odgovora v formatu json smo že prepričani, da je testiranje dima uspešno opravljeno.
  Če ena od teh vstopnih točk vrne tudi podatke iz baze podatkov, medtem ko prva ne, morate dodatno zagnati še eno poizvedbo, da se prepričate, da aplikacija
  pravilno obdeluje zahteve v bazo podatkov. In s tem je "dimni" test zaključen.

  To pomeni, da smo izpolnili zahtevo - odgovor je prišel iz storitve in ni "kadil", to pomeni, da ni vrnil napake 4xx ali 5xx in nekaj nejasnega, namesto json. Na tej točki lahko rečemo, da je "dimni" test opravljen. Če želite preveriti, ali uporabniški vmesnik deluje na enak način, morate samo enkrat odpreti stran v brskalniku.

• Sanitarno testiranje bo v tem primeru obsegalo izvedbo zahteve do vseh 10 vstopnih točk v api, preverjanje prejetega jsona s pričakovanim in prisotnost zahtevanih podatkov v njem.
• Regresijski testi bodo sestavljeni iz dima + zdravega razuma + uporabniškega vmesnika, ki se izvajajo skupaj na istem kupu. Cilj: preverite, ali dodajanje 11. vstopne točke ni prekinilo na primer obnovitve gesla.
• Ponovni preizkus v tem primeru je preverjanje točke za točko, da na primer pokvarjena vstopna točka API-ja v naslednji gradnji deluje, kot je predvideno.

Poleg tega, če ta API sprejema tudi zahteve za objavo, potem je očitno, da je treba te zahteve vključiti v drug niz testov razumnosti. Po analogiji z uporabniškim vmesnikom bomo preverili vse strani aplikacije.

Naj povzamemo

Upam, da vam bo po branju tega članka postalo jasno, katero vrsto testiranja uporabljate na kateri stopnji in kakšna je razlika med tema vrstama testiranja. Kot je bilo omenjeno na začetku, je meja med temi koncepti zelo poljubna in ostaja po vaši presoji v okviru projekta.

UPD:
Pogosto se "preizkušanje doslednosti" ali "testiranje zdravega zdravja" imenuje "sanitarno testiranje". Mislim, da je do tega prišlo zaradi fonetičnih lastnosti angleške besede sanity, ki je po zvoku podobna nečemu »sanitarno«. Google Translate prinaša jasnost. Obe možnosti sta na voljo na internetu. V zvezi s tem člankom upoštevajte "sanitarno" testiranje kot "testiranje doslednosti."

Hvala za namig

Po opravljenih potrebnih spremembah, kot je popravljanje hrošča/napake, je treba programsko opremo ponovno preizkusiti, da potrdite, da je bila težava dejansko odpravljena. Sledijo vrste testiranja, ki jih je treba izvesti po namestitvi programske opreme, da se potrdi funkcionalnost aplikacije ali pravilnost popravka napake:

- Testiranje dima(testiranje dima)

- Regresijsko testiranje(Regresijsko testiranje)

- Testiranje zgradbe(Test preverjanja gradnje)

- Sanitarno testiranje ali preverjanje doslednosti/funkcionalnosti(preizkus razumnosti)

Koncept testiranje dima prišel iz inženirskega okolja. Pri zagonu nove opreme (»strojne opreme«) se je štelo, da je bilo testiranje uspešno, če se iz instalacije ne kadi. Na področju testiranja programske opreme je namenjen površnemu preverjanju delovanja vseh aplikacijskih modulov in prisotnosti hitro odkritih kritičnih in blokirajočih napak. Na podlagi rezultatov dimnega testiranja se sklepa, ali je nameščena različica programske opreme sprejeta v testiranje, delovanje ali dostavo stranki ali ne. Za lažje delo, prihranek časa in delovne sile je priporočljivo implementirati avtomatizacijo testnih skriptov za testiranje dima.

Regresijsko testiranje je vrsta testiranja, katerega cilj je preverjanje sprememb v aplikaciji ali okolju (popravljanje napake, združevanje kode, selitev v drug operacijski sistem, bazo podatkov, spletni strežnik ali aplikacijski strežnik), da se potrdi, da že obstoječa funkcionalnost deluje, kot je bilo predvideno (glejte tudi sanitarno testiranje ali testiranje konsistence/funkcionalnosti). Regresije so lahko podobne funkcionalen, tako in nefunkcionalen testi.

Za regresijsko testiranje se praviloma uporabljajo testni primeri, napisani v zgodnjih fazah razvoja in testiranja. To zagotavlja, da spremembe v novi različici aplikacije ne poškodujejo obstoječe funkcionalnosti. Priporočljivo je avtomatizirati regresijske teste, da pospešite nadaljnji proces testiranja in odkrijete napake v zgodnjih fazah razvoja programske opreme.

Sam izraz »regresijsko testiranje« ima lahko različne pomene, odvisno od konteksta uporabe. Sam Kaner je na primer opisal 3 glavne vrste regresijsko testiranje:

- Regresija hrošča– poskus dokaza, da popravljena napaka dejansko ni odpravljena.

- Regresija starih hroščev– poskus dokaza, da je nedavna sprememba kode ali podatkov prekinila popravek starih napak, tj. spet so se začele pojavljati stare napake.

- Regresija stranskih učinkov– poskus dokazati, da je nedavna sprememba kode ali podatkov pokvarila druge dele aplikacije, ki se razvija.

Test zdrave pameti – To je zelo osredotočeno testiranje, ki zadostuje za dokaz, da določena funkcija deluje, kot je določeno v specifikaciji. Je podmnožica regresijskih testiranj. Uporablja se za določanje zmogljivosti določenega dela aplikacije po spremembah v njej ali okolju. Običajno ročno.

Razlika med sanitarnim testiranjem in testiranjem dima. Nekateri viri zmotno menijo, da sta sanitarno testiranje in testiranje dima ista stvar. Verjamemo, da imajo te vrste testiranja »vektorje gibanja«, smeri v različnih smereh. Za razliko od testiranja dima je testiranje razumnosti usmerjeno poglobljeno v preizkušano funkcijo, medtem ko je testiranje dima usmerjeno v širino, da s testi v najkrajšem možnem času pokrije čim več funkcionalnosti.

Testiranje zgradbe Build Verification Test je testiranje, namenjeno ugotavljanju skladnosti izdane različice z merili kakovosti za začetek testiranja. Po svojih ciljih je podoben testiranju dima, katerega namen je sprejeti novo različico za nadaljnje testiranje ali delovanje. Lahko prodre globlje, odvisno od zahtev glede kakovosti izdane različice.

Testiranje namestitve – namenjeni preverjanju uspešne namestitve in konfiguracije ter posodabljanju ali odstranitvi programske opreme. Trenutno je najpogostejši način namestitve programske opreme uporaba monterji(posebni programi, ki tudi sami zahtevajo ustrezno testiranje). V dejanskih razmerah morda ni namestitvenih naprav. V tem primeru boste morali sami namestiti programsko opremo z uporabo dokumentacije v obliki navodil ali datotek readme, ki korak za korakom opisujejo vsa potrebna dejanja in preverjanja. V porazdeljenih sistemih, kjer je aplikacija nameščena v že delujočem okolju, preprost nabor navodil morda ne bo dovolj. Da bi to naredili, je pogosto napisan načrt namestitve (Načrt uvajanja), ki vključuje ne samo korake za namestitev aplikacije, ampak tudi korake za povrnitev na prejšnjo različico v primeru okvare. Tudi sam načrt namestitve mora biti podvržen postopku testiranja, da bi se izognili težavam pri dejanskem zagonu. To še posebej velja, če se namestitev izvaja na sistemih, kjer vsaka minuta izpada pomeni izgubo ugleda in velike količine sredstev, na primer: banke, finančne družbe ali celo banner mreže. Zato lahko testiranje namestitve imenujemo ena najpomembnejših nalog pri zagotavljanju kakovosti programske opreme.

Prav ta celovit pristop s pisanjem načrtov, testiranjem namestitve po korakih in povrnitvijo namestitve lahko upravičeno imenujemo testiranje namestitve ali Testiranje namestitve.

Enostavne napake so lahko usodne za vaše spletno mesto – še posebej, če ste podjetje SaaS (eng. Software as a Service) kot mi. Če uporabnik pride na vaše spletno mesto in ne more dokončati preproste naloge, kot je registracija ali ponastavitev pozabljenega gesla, tvegate, da boste tega uporabnika za vedno izgubili.

To smo doživeli na težji način. Seveda je pomembno imeti v ekipi svoje ljudi, ki testirajo aplikacijo in iščejo napake, ni pa vedno primerno ali dovolj temeljito. V tem članku vas, humaniste, želimo uvesti v svet dimnih testov.

Če imate še vprašanja, lahko zapolnite vrzeli z obiskom

Testiranje dima je bilo prvotno izumljeno, da bi razložili, kako so inženirji elektrotehnike preverjali, ali njihova naprava deluje tako, da so jo vklopili in ali se je kadil ...

Počakaj, kako to velja za aplikacije?

Pomen (in stroškovna učinkovitost) dimnih testov je menedžerjem humanističnih ved in soustanoviteljem na splošno neznan. Sistematični testi dima se lahko obravnavajo kot sestavni del preprečevanja povečanja verjetnosti vdora. Zmanjšajo možnost, da bi se vaša spletna ali telefonska aplikacija zrušila – in kot vsi vemo, je potrebna samo ena napaka in lahko za vedno izgubite stranko.

To je uvodni vodnik o tem, kaj je, kako se lahko izvaja, kateri viri se uporabljajo za njegovo izvedbo in primeri za vodenje bralcev.

Preizkusi dima so zasnovani za preizkušanje osnovne funkcionalnosti in bi morali biti sestavni del vašega postopka testiranja. Lahko vključujejo nekaj tako preprostega, kot je "Ali se lahko registriram?"

Preizkušanje dima pomaga zagotoviti, da nobena od večjih in očitnih okvar ni prepuščena naključju. Ne bi smeli opraviti globljega preizkusa, dokler niste 100-odstotno opravljeni s preizkusi dima, ker odstranijo temeljne napake v programski opremi.

1. korak: Odločite se, kaj boste testirali

Določite, kaj želi vaša aplikacija doseči. Kateri so najočitnejši otroški koraki, ki so potrebni, da prideš tja? Kakšne so minimalne življenjske zahteve in v kakšnem logičnem vrstnem redu bi jih našteli?

Ustvari testno zbirko. Testna zbirka je združena zbirka testnih primerov (testnih primerov), povezanih na določen način (na primer po funkcionalnosti).

Testiranje dima ne bo vključevalo spremenljivk ali vprašanj "kaj če?" Predvideva samo odgovore da/ne, vendar je treba pred nadaljevanjem podrobnejšega testiranja opraviti vse testne primere s pozitivnim rezultatom.

Vzemimo za primer ustvarjanje interaktivnega foruma. Da bi deloval, moram:

1. register.
2. ustvarite uporabniško ime.
3. naložite fotografijo v svoj avatar.
4. pisati sporočila.
5. odgovarjati na sporočila.

2. korak: Zapišite rezultate v tabelo

Zgornja slika je primer naše ekipe. Predlogo lahko najdete. To je potrebno, da lahko vodimo evidenco, kaj nam gre in kaj ne – osnovna organiziranost bo v prihodnosti prihranila veliko časa. Naše rezultate smo razdelili na uspešne, delne in neuspešne.

• Opravljeno: vse deluje brezhibno.
• Delno: Morda se na začetku ne boste zavedali, da so nekatere dejavnosti lahko nadalje razdeljene, tako da en del deluje, drugi pa ne.
• Neuspešno: ne deluje.

Opisali smo natančne korake, ki smo jih želeli reproducirati, nato pa smo v naslednjem stolpcu dodali kratek opis tega, kar pričakujemo. primer:

3. korak: Avtomatizirajte preizkuse dima

Zelo pomembno je, da tega ne jemljemo kot aksiom, da bo imelo vsako dejanje, če je bilo enkrat opravljeno, vedno pozitiven rezultat. Preizkusi dima vam omogočajo, da nenehno preverjate, ali osnovne funkcije niso bile sčasoma poškodovane ali pokvarjene v daljšem obdobju.

Ne prenehajte s testiranjem dima. Nikoli.

Ko se vaš niz testnih primerov za testiranje dima zaključi z uspešnim izidom 100%, razmislite o njihovi avtomatizaciji. Priporočena pogostost izvajanja dimnih testov je vsak dan, če se vaše podjetje razvija vsak dan.

Minimalna zahteva je izvajanje dimnih testov pred vsako izdajo in po vsakem popravku.

Osnovno pravilo za preizkus dima:

• Minimalni čas: 30 minut.
• Najdaljši čas: 60 minut.

Dolgoročno gledano avtomatizacija dimnih testov prihrani čas, vendar pri vedno znova izvajanju istih testov človeško oko morda neha opaziti podrobnosti, stroj pa ne.