Get your 6-month No-Cost Opt-Out offer for Unlimited Software Automation?

“Smoke” testavimas – tai procesas, naudojamas programinei įrangai testuoti, siekiant nustatyti, ar įdiegta programinės įrangos sąranka yra stabili.

Testuojant programinę įrangą, atliekami keli testai, skirti įvertinti kiekvieną pagrindinę programinės įrangos funkciją.

“Smoke” testavimo įrankiais patikrinama, ar veikia svarbiausios programinės įrangos funkcijos. Egzistuoja daugybė skirtingų “dūmų” testavimo metodų, o šiuolaikinės technologijos suteikia galimybę atlikti automatinį “dūmų” testavimą daugeliui programinės įrangos kūrimo atvejų.

Šiame straipsnyje gilinsimės į “dūmų” testavimą ir apžvelgsime programinės įrangos testuotojų naudojamus “dūmų” testavimo tipus, procesus ir metodus. Taip pat apžvelgsime šiuolaikinius dūmų testavimo įrankius, įskaitant dūmų testavimo automatizavimą.

Trumpai tariant, sužinosite viską, ką kada nors reikės žinoti apie dūmų testavimą.

 

Table of Contents

Kas yra dūmų testavimas programinės įrangos inžinerijoje?

 

“Smoke” testavimas – tai programinės įrangos testavimo procesas, kuriuo siekiama užtikrinti, kad ji atitiktų pagrindinius funkcionalumo ir stabilumo reikalavimus. Tai iš esmės yra miniatiūrinis greitas regresinis testavimas, kurio metu išbandomos svarbiausios programinės įrangos funkcijos, siekiant įsitikinti, kad jos veikia pagrindiniu lygmeniu.

Bandomasis testavimas yra svarbus ankstyvasis QA proceso etapas, nes jis parodo, ar komanda turėtų tęsti tolesnį testavimą, ar iš karto grąžinti produktą kūrėjams.

Jei produktas neišlaiko “dūmų” testo, tai reiškia, kad pirminis rinkinys turi reikšmingų trūkumų, kuriuos reikia pašalinti prieš atliekant tolesnius bandymus.

 

Kada reikia atlikti dūmų bandymus?

 

Programinę įrangą testuojame, kai kuriamos naujos funkcijos ir integruojamos į esamą sąranką, ir prieš perduodant naują sąranką į QA. Šiame etape atlikdami “dūmų” testavimą, išvengsite pinigų ir kitų išteklių švaistymo QA testavimui programinei įrangai, kurioje yra esminių problemų.

Norint atlikti QA bandymą, kūrėjų komanda QA sistemoje įdiegia naują programinės įrangos sąranką, iš kurios paimamas ir paleidžiamas tam tikras bandymų atvejų pogrupis. Kokybės užtikrinimo komanda testuoja programą pagal svarbiausias jos funkcijas. Jei “smoke” testas išlaikomas, QA komanda tęsia funkcinį testavimą, o jei testas nepavyksta, kūrimo komandai perduodamas tolesniam kūrimui.

Tokie bandymai atliekami kiekvieną kartą, kai į programinės įrangos rinkinį įtraukiamos naujos funkcijos.

Gali būti ir kitų atvejų, kai kokybės užtikrinimo komandos testuos programinę įrangą, pvz:

● Prieš perduodami naują kodą į saugyklą
● Prieš didelę bandymų seriją, įskaitant regresijos ir priėmimo bandymus
● Įdiegus naują programinės įrangos rinkinį

Jei šiuose etapuose neatliksite bandymų, vėlesniuose funkcionalumo testavimo etapuose galite aptikti didelių defektų, kurie gali turėti įtakos naujojo rinkinio išleidimo datai arba rimčiau sutrikdyti jūsų tvarkaraštį.

 

Kai nereikia atlikti dūmų testavimo

 

Testuojant programinę įrangą svarbu atlikti “dūmų” testavimą, kai atliekate programinės įrangos kodo pakeitimus arba į sąranką įtraukiate naujų funkcijų.

Be to, tai svarbus parengiamasis funkcionalumo testavimo etapas, nes jis neleidžia QA komandoms gaišti laiko testuojant neparuoštą programinę įrangą.

Jei jūsų programinė įranga neatitinka šių kriterijų, šiuo metu jums gali nereikėti atlikti “dūmų” testavimo… nors automatizuotos “dūmų” testavimo priemonės leidžia lengvai ir ekonomiškai efektyviai atlikti reguliarius “dūmų” testus, kad programinė įranga visada veiktų tinkamai.

 

Kas dalyvauja atliekant dūmų bandymus

 

“Smoke” testavimą atlieka QA inžinieriai arba QA vadovas; tai pirmasis QA testavimo etapas, atliekamas QA aplinkoje.

Užtikrinimo kokybės komanda yra atsakinga už programinės įrangos bandymus ir jos veikimo įvertinimą įvairiomis sąlygomis ir sąlygomis. Atlikdami bandomąjį testavimą, QA inžinieriai ieško “stabdžių”, t. y. klaidų, kurios stabdo kūrimą ir turi būti ištaisytos prieš tęsiant testavimą.

Lyginant “dūmų testavimą” ir ” tinkamumo testavimą ” bei regresijos testavimą, svarbu atsižvelgti ne tik į tai, kas yra testuojama, bet ir į tai, kas atlieka testus.

Programinės įrangos testavimo metu dūmų testavimą visada atlieka QA specialistai. Taip “dūmų” testavimas skiriasi nuo “sveikumo” testavimo, kuris atliekamas kūrimo aplinkoje ir kuriame paprastai nedalyvauja kokybės užtikrinimo komanda.

 

Dūmų bandymo gyvavimo ciklas

 

Dūmų testavimo gyvavimo ciklas rodo, kaip dūmų testavimas atliekamas kuriant gaminį ir atliekant kokybės užtikrinimo bandymus. Kiekvieno šio ciklo etapo supratimas padės jums geriau suprasti, kaip “dūmų” testavimas įsilieja į testavimo procesą ir kuo skiriasi “dūmų” testavimas nuo tinkamumo testavimo ir regresijos testavimo.

 

1. Kodas

Pirmasis bet kokios programinės įrangos kūrimo etapas visada yra kodo rašymas ir kūrimas. Kodas yra bet kokios programinės įrangos pagrindas, todėl kūrėjų komanda turi parašyti kodą ir tik po to išbandyti jo stabilumą ir funkcionalumą.

 

2. Vieneto testavimas

Vienetų testavimą paprastai atlieka programuotojai, nors kartais kai kuriuos vienetinius testus gali atlikti ir QA inžinieriai. Prieš integruojant atskirus vienetus į vieną programinės įrangos rinkinį, vienetų testavimu užtikrinama, kad skirtingi kodo vienetai ar elementai veiktų taip, kaip tikimasi.

Vieneto testavimas paprastai atliekamas kartu su kūrimu, nes jo metu išryškėja kodo klaidos ir klaidos, kurias galima greitai ištaisyti.

 

3. Integracijos testavimas

Integracijos testavimas – tai procesas, kurio metu tikrinama, kaip atskiri vienetai veikia kartu, kai yra integruojami į vieną programinės įrangos vienetą.

Net jei kiekvienas atskiras padalinys veikia gerai, dažnai gali kilti problemų, kai šie padaliniai integruojami vienas su kitu. Integracijos bandymus paprastai atlieka programuotojai, nors dėl skirtingų požiūrių į šios rūšies bandymus jie gali būti atliekami skirtingais programinės įrangos kūrimo proceso etapais.

 

4. Tinkamumo testavimas

Tinkamumo testavimas yra regresijos testavimo tipas, kuris paprastai yra paskutinis regresijos testavimo tipas. Tai atliekama kūrimo etape, po to, kai ištaisomos visos per regresinį testavimą išryškėjusios klaidos.

Tinkamumo testavimas paprastai yra labai greitas ir juo tiesiog siekiama užtikrinti, kad programinė įranga veiktų sklandžiai ir kad visos rastos klaidos būtų tinkamai ištaisytos.

Kartais painiojami “dūmų” ir “tvarkingumo” testai, tačiau svarbu prisiminti, kad “tvarkingumo” testai atliekami kūrimo aplinkoje, o “dūmų” testai – kokybės užtikrinimo aplinkoje.

 

5. Dūmų bandymas

“Smoke” testavimas – tai pirmasis kokybės užtikrinimo testavimo etapas ir pirmasis testavimo tipas, atliekamas kokybės užtikrinimo aplinkoje.

“Smoke” testavimas paprastai atliekamas prieš tinkamumo testavimą ir regresijos testavimą, nepaisant to, kad jį paprastai atlieka QA komandos. Tai greitas ir paprastas testavimo procesas (šiais laikais dauguma QA komandų programinės įrangos testavimui naudoja automatinį “dūmų” testavimą), kurio metu nustatoma, ar sąranka yra stabili ir ar reikia atlikti tolesnius testus.

Kadangi dūmų testavimas yra greičiausias ir paprasčiausias testas, lyginant dūmų testavimą su tinkamumo testavimu ir regresijos testavimu, jį tikslinga atlikti pirmiausia, prieš pereinant prie kitų, sudėtingesnių testų.

 

6. Funkcinis testavimas

Funkcinis testavimas yra kitas programinės įrangos testavimo gyvavimo ciklo etapas, kuris atliekamas QA aplinkoje.

Funkciniu testavimu tikrinama kiekviena programinės įrangos programos funkcija, atsižvelgiant į jos reikalavimus, ir daugiausia dėmesio skiriama funkcijoms, patogumui, prieinamumui ir klaidų sąlygoms.

Funkcinis testavimas gali būti pradėtas po to, kai išlaikomas “dūmų” testas.

 

Įvairių lygių dūmų testavimo programos

Dūmų testavimas taikomas trimis skirtingais testavimo lygiais: priėmimo lygio dūmų testavimas, sistemos lygio dūmų testavimas ir integravimo lygio dūmų testavimas.

 

1. Priėmimo testavimo lygis

Priėmimo lygmens bandymai paprastai atliekami, kai programinės įrangos kūrimas perduodamas QA. Šio tipo QA “dūmų” testas tiesiog patikrina pagrindinį sukonstruotos programos funkcionalumą ir tai, ar jis atitinka numatytą funkcionalumą.

 

2. Sistemos testavimo lygis

Sistemos lygmens bandymai apima svarbiausių sistemos darbo srautų testavimą. Tai atliekama po to, kai išbandoma pati sistema, ir prieš atliekant visą sistemos regresijos testą.

Sistemos lygmeniu automatinis dūmų testavimas yra labiausiai paplitusi dūmų testavimo forma.

 

3. Integracijos testavimo lygis

Integracijos testavimo lygmenyje “bandomaisiais” testais užtikrinama, kad visos programinės įrangos galutinės funkcijos veiktų taip, kaip tikimasi, ir kad pagrindinė integracija veiktų.

Toks “dūmų” testavimas paprastai atliekamas tada, kai įgyvendinami atskiri moduliai arba kai keli moduliai integruojami į vieną programinės įrangos rinkinį.

 

Rankiniai ir automatiniai dūmų testai

 

Kai programinės įrangos komandos pirmą kartą pradeda atlikti “dūmų” testus, jos turi nuspręsti, ar jos atliks rankinius, ar automatinius “dūmų” testus.

Nors automatiniai “dūmų” testai paprastai užtikrina greitesnius ir ekonomiškesnius rezultatus, jų kūrimas ir įgyvendinimas gali užtrukti. Daugelis komandų, prieš pradėdamos kurti rankinius “dūmų” testus, svarsto apie automatizavimą.

 

1. Rankinis dūmų testavimas

 

Rankiniu būdu atliekamus “dūmų” testus gana lengva sukurti, o juos paprastai gali atlikti ne techninės srities specialistai, nepriklausantys QA ar kūrimo komandoms. Tai reiškia, kad mažesnėse įmonėse, kurios dar neturi specialaus QA vadovo, dažnai teikiama pirmenybė rankiniams “dūmų” testams.

Atliekant rankinį “dūmų” testavimą svarbu išbandyti keletą naudojimo atvejų, kurie apimtų pakankamai pagrindinių programinės įrangos funkcijų ir neapimtų tiek daug, kad “dūmų” testavimas užtruktų per ilgai. Paprastai manoma, kad idealus naudojimo atvejų skaičius yra nuo 20 iki 50.

 

Rankiniu būdu atliekamų dūmų bandymų privalumai

 

Rankiniai dūmų testai kokybės užtikrinimo srityje turi daug privalumų, palyginti su automatiniais dūmų testais. Rankiniu būdu atliekami bandymai dažnai suteikia išsamesnės informacijos apie programinės įrangos našumą ir funkcionalumą, palyginti su automatizuotais bandymais.

 

Ne inžinieriai gali atlikti rankinį testavimą

Automatizuotam “dūmų” testavimui paprastai reikia programinės įrangos inžinierių ir kūrėjų patirties, o rankiniu būdu atliekamus “dūmų” testus gali atlikti komandos nariai, turintys mažiau specialių žinių.

Paprastai tai naudinga mažesnėms komandoms, kurių ištekliai jau gali būti išsemti, o specialistų laikas yra labai vertingas.

 

Kiekvienam darbui galite sukurti pasirinktinį dūmų testą

Jei norite įsitikinti, kad “dūmų” testas tiksliai apima svarbiausias bet kurios programinės įrangos programos funkcijas ir sutelkia dėmesį į tas funkcijas, kurios yra svarbesnės kiekvienai programinei įrangai, sukurdami rankinį “dūmų” testą, testuotojai gali pritaikyti testą kiekvienam projektui.

Tokie rankiniu būdu atliekami bandymai gali duoti daugiau naudingų rezultatų, palyginti su kai kuriais automatizuotais bandymais, tačiau tai reiškia, kad jų parengimas ir vykdymas užima daug laiko.

 

Rankiniai testai atskleidžia kokybinius duomenis

Kai paleidžiate automatinį bandymą, galite tikėtis gauti tik kiekybinius duomenis apie tai, kurie bandymo aspektai buvo sėkmingi, o kurie – ne.

Kai komandos nariai atlieka rankinį “dūmų” testavimą, jie gali pasinaudoti savo įžvalgomis, intuicija ir vertinimu, kad įvertintų ne tik tai, ar kūrimas pavyko, bet ir kaip ir kodėl.

 

Rankinio dūmų testavimo iššūkiai

 

Atliekant dūmų testavimą rankiniu būdu taip pat kyla daug sunkumų, todėl daugelis įmonių, kai įmanoma, renkasi automatizuotą dūmų testavimą.

Rankiniu būdu atliekami bandymai yra kruopštūs, tačiau jie taip pat atima daug laiko.

 

Rankiniai dūmų testai užima laiko

Rankiniu būdu atliekami “dūmų” testai užtrunka gerokai ilgiau nei automatiniai testai, be to, jiems reikia skirti daugiau komandos dėmesio.

Nors automatizuoti testai gali tiesiog patys veikti fone, jūsų komandai reikės skirti laiko rankiniam “dūmų” testui atlikti.

 

Rankiniai testai negali būti atliekami per dažnai

Kadangi rankiniai “dūmų” testai reikalauja daug laiko ir išteklių, jie negali būti atliekami taip reguliariai, kaip automatiniai “dūmų” testai.

Atlikdami rankinį “dūmų” testą, programinės įrangos testuotojai, priklausomai nuo testo sudėtingumo, turi skirti nuo kelių valandų iki pusės dienos.

Tai panaikina galimybę kasdien tikrinti dūmus, o tai laikoma geriausia pramonės praktika.

 

Visada galima suklysti

Kadangi rankinį testavimą atlieka žmonės, visada yra tikimybė, kad atliekant rankinius bandymus gali būti padaryta klaidų.

Dėl šios priežasties rankinis testavimas paprastai nėra toks išsamus kaip automatinis testavimas, ypač kai norima aptikti subtilias klaidas, kurių lengviau nepastebėti, arba kai atliekami labai pasikartojantys testai, dėl kurių testuotojai gali prarasti koncentraciją testavimo metu.

 

Kada naudoti rankinį dūmų testavimą

 

Rankinis “dūmų” testavimas dažniausiai naudojamas mažesnėse komandose, kurios gali neturėti išteklių, kad galėtų skirti inžinierių automatizuotam “dūmų” testavimui, arba tais atvejais, kai norima ar reikia papildomos žmogaus įžvalgos ir vertinimo.

Dėl šios priežasties rankinis dūmų testavimas dažnai įgyvendinamas integracijos lygmens dūmų testuose.

 

2. Automatinis dūmų testavimas

 

Automatinį “dūmų” testavimą gali atlikti programinės įrangos inžinieriai, turintys programavimo įgūdžių, reikalingų sukurti ir paleisti atitinkamų naudojimo atvejų seriją kiekvienai programinės įrangos sąrankai.

Automatinis “dūmų” testavimas yra daug greitesnis nei rankinis testavimas – paprastai jis trunka ne ilgiau kaip 30-60 minučių ir gali būti atliekamas fone, kol visi kūrimo ir kokybės užtikrinimo komandos nariai tęsia savo kasdienes užduotis.

Dėl šios priežasties automatinis dūmų testavimas tapo įprastu programinės įrangos pramonėje, nes vis daugiau įmonių siekia pagerinti darbo vietos efektyvumą.

 

Dūmų testavimo automatizavimo privalumai

 

Smoke testų automatizavimas suteikia daug naudos toms įmonėms, kurios turi laiko ir išteklių jam įgyvendinti. Tai greita ir veiksminga, o dėl to, kad automatizuoti testai nesukelia didelio krūvio komandoms ir ištekliams, juos galima reguliariai atlikti net ir mažose įmonėse.

 

Automatizuotas testavimas yra greitas

Automatizuotas “dūmų” testavimas yra daug greitesnis nei rankinis testavimas, o dauguma automatizuotų testų trunka ne ilgiau kaip 30-60 minučių.

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

Palyginimui, rankiniu būdu atliekami bandymai gali užtrukti kelias valandas.

Automatizuotiems “dūmų” testams reikia nedaug išteklių, o juos įdiegus labai lengva atlikti.

 

Automatizavimas leidžia atlikti kasdienius dūmų bandymus

Pagal dabartinę geriausią pramonės praktiką geriausia kasdien atlikti “dūmų” bandymus, ypač kai dirbama su nuolat kintančia programine įranga.

Kasdien atlikti rankiniu būdu atliekamus “dūmų” testus užima per daug laiko, tačiau automatinius “dūmų” testus lengva atlikti kiekvienos darbo dienos pradžioje.

 

Automatizavimas pašalina žmogiškąsias klaidas

Automatiniai testai atliekami pagal iš anksto parengtus scenarijus, sukurtus laikantis itin griežtų standartų. Tai reiškia, kad tikimybė, jog automatinis testas nepastebės didelės klaidos ar svarbios problemos, yra labai maža.

 

Automatizavimas gali imituoti apkrovos ir našumo testus

Apkrovos ir našumo testais įvertinama, kaip gerai veikia programa, kai ja vienu metu naudojasi daug naudotojų. Automatizuotas “dūmų” testavimas gali imituoti papildomą kelių naudotojų apkrovą taip, kaip to neįmanoma padaryti atliekant rankinį testavimą, ir suteikti papildomų duomenų apie programinės įrangos veikimą tam tikromis sąlygomis.

 

Dūmų testavimo automatizavimo iššūkiai

 

Dūmų bandymų automatizavimas neapsieina be iššūkių. Automatizuotam “dūmų” testavimui įdiegti gali prireikti daugiau laiko ir išteklių, ypač mažesnėse komandose, turinčiose mažiau inžinierių.

 

Techniniai reikalavimai

Automatizuotiems “dūmų” testams reikia daugiau techninių žinių ir kodavimo įgūdžių nei rankiniams “dūmų” testams. Programinės įrangos inžinieriai turi turėti laiko ir žinių, kaip sukurti automatinius testus, ir tik tada juos įgyvendinti, o ne visos komandos turi tam reikalingų išteklių.

 

Žmogiškosios įžvalgos trūkumas

Automatinis testavimas leidžia susidaryti bendrą vaizdą apie programinės įrangos funkcionalumą, o atlikdami automatinį “dūmų” testą programinės įrangos testuotojai gali susipažinti su pagrindinėmis programinės įrangos funkcijomis, o tai yra pagrindinis “dūmų” testo tikslas.

Tačiau automatiniai testai nesuteikia jokios informacijos apie svarbesnius programinės įrangos veikimo aspektus, pavyzdžiui, tinkamumą naudoti ir prieinamumą.

 

Kada įdiegti dūmų testavimo automatizavimą

 

Automatizavimas dažnai naudojamas atliekant “dūmų” testavimą, nes “dūmų” testavimo tikslas – patikrinti pagrindinį funkcionalumą, o tai automatizuotam testavimui gana gerai sekasi.

Komandos, turinčios pakankamai techninių įgūdžių automatizuotam dūmų testavimui įdiegti, greičiausiai turės laiko ir išteklių investuoti į šį procesą, o didesnės, labiau įsitvirtinusios įmonės greičiausiai jaus didesnį spaudimą laikytis geriausios kasdienio dūmų testavimo praktikos standartų.

 

Dūmų testavimo automatizavimas ir rankinis dūmų testavimas

 

Nėra teisingo ar neteisingo būdo, kaip atlikti dūmų testavimą, ir tai, kas tinka vienai komandai, gali netikti kitai.

Prieš atlikdamos “dūmų” testą, programinės įrangos komandos turėtų apsvarstyti savo tikslus, išteklius ir ilgalaikius projekto planus. Rankiniu būdu atliekamo programinės įrangos testavimo procesas gali būti naudingas jauniems specialistams, pradedantiems dirbti su kokybės užtikrinimu, tačiau labiau įsitvirtinusioms komandoms rankinio testavimo privalumai retai kada būna naudingesni nei automatinio testavimo.

 

Hibridiniai dūmų bandymai

 

Trečioji galimybė komandoms, kurios negali apsispręsti tarp rankinio ir automatizuoto “dūmų” testavimo ir tinkamumo testavimo, – rinktis hibridinį testavimą.

Hibridinis testavimas apjungia rankinio ir automatinio “dūmų” testavimo aspektus, kad padidėtų bendras testų našumas ir efektyvumas. Taikant hibridinį dūmų bandymo metodą, didžioji dalis bandymo gali būti automatizuota, tačiau tam tikri aspektai gali būti atliekami rankiniu būdu. Tai leidžia komandoms daugiau dėmesio skirti tiems surinkimo aspektams, kuriems to reikia, ir kartu išlaikyti mažus bendrus laiko reikalavimus, reikalingus “dūmų” bandymui atlikti.

 

Dūmų bandymų tipai

 

Dūmų bandymus iš esmės galima suskirstyti į dvi kategorijas: formalius ir neformalius dūmų bandymus. Ar “dūmų” testavimas yra oficialus, ar neoficialus, priklauso nuo to, ar jį oficialiai inicijuoja QA vadovas, ar jis tiesiog atliekamas kaip kūrimo dalis.

 

1. Oficialūs dūmų bandymai

Atliekant oficialų bandymą, programinės įrangos kūrėjai perduoda sukurtą programinę įrangą QA inžinieriui arba QA vadovui, kad šis atliktų oficialų bandymą. Kokybės užtikrinimo vadovas paskiria testuotojams “dūmų testavimo” užduotį ir paprašo, kad jie atliktų “dūmų testavimą” naudodami “dūmų testavimo” įrankius, pvz., automatizavimo įrankius, arba rankiniu būdu.

Atlikdami oficialius “dūmų” testus, QA testuotojai parengia oficialią ataskaitą, kurią gali analizuoti QA vadovas.

Formalūs bandymai atliekami svarbiais programinės įrangos kūrimo proceso momentais, pavyzdžiui, prieš atliekant naujų funkcijų funkcinius bandymus.

 

2. Neformalūs dūmų bandymai

Neformalūs “dūmų” testai – tai programinės įrangos kūrimo ar kokybės užtikrinimo proceso metu atliekami “dūmų” testai, apie kuriuos oficialiai nepranešama arba kurių nereikalauja kokybės užtikrinimo vadovas.

Kasdieniai “dūmų testai”, kuriuos daugelis programinės įrangos komandų atlieka pagal protokolą, yra neformalių “dūmų testų” pavyzdys.

Neformalius bandymus galima atlikti ad hoc, kai QA inžinieriai mano, kad tai gali būti naudinga.

 

Ko reikia norint pradėti dūmų testavimą

 

Prieš pradedant programinės įrangos testavimą, svarbu surinkti visus reikalingus dalykus, įskaitant duomenų failus ir įgūdžius jūsų organizacijoje.

Tai, ko jums reikės “dūmų” testavimui atlikti, priklausys nuo to, ar planuojate atlikti automatinį, ar rankinį “dūmų” testavimą ir kokius testavimo įrankius naudosite, kad palengvintumėte šį procesą.

 

1. Testavimo atvejų sąrašas

Prieš pradėdami “dūmų” testą, turite sudaryti išsamų visų testavimo atvejų, kuriuos norite įvertinti, sąrašą.

Testavimo atvejai – tai atskiri veiksmų rinkiniai, kuriuos norite išbandyti, norėdami įvertinti, ar šių veiksmų rezultatai atitinka jūsų laukiamus rezultatus.

Pavyzdžiui, labai paprastas bandomasis atvejis gali būti toks, kad programinė įranga įkelia pagrindinį prietaisų skydelį, kai atidarote programą.

 

2. Bandomieji failai

Prieš paleisdami bandomąjį testą, turite surinkti visus bandomuosius failus, su kuriais ketinate atlikti bandomąjį testą. Gali būti, kad galėsite naudoti naudojamos dūmų testavimo programinės įrangos komandinę eilutę ir surinkti visus failus į vieną vietą.

Kaip kaupsite failus ir kur juos laikysite, priklausys nuo to, kaip veikia jūsų organizacija.

 

3. Dūmų testavimo įrankiai

Pagrindinį dūmų testą galite atlikti nenaudodami jokių konkrečių įrankių, tačiau naudojant dūmų testavimo įrankius galima padidinti rezultatų tikslumą ir pagreitinti dūmų testavimo procesą.

Pirmiausia ištirkite dūmų testavimo įrankius internete ir pasirinkite programinę įrangą, kuri automatizuoja arba optimizuoja dūmų testavimą pagal jūsų konkrečius poreikius ir biudžetą.

 

Dūmų bandymo procesas

 

Įvairiose organizacijose geriausias būdas atlikti “dūmų” testavimą yra skirtingas, o jei pradedate atlikti “dūmų” testavimą, galbūt norėsite išbandyti įvairius metodus, kad sužinotumėte, kas geriausiai tinka jūsų komandai.

Toliau pateikiamas pavyzdys, kaip atlikti pagrindinį “dūmų” testą, kad būtų įvertintos pagrindinės programinės įrangos funkcijos.

 

1 žingsnis: pasirinkite testavimo atvejus

Pirmasis žingsnis atliekant “dūmų” testą – pasirinkti testavimo atvejus, su kuriais bus atliekamas “dūmų” testas.

Kurdami “dūmų” testą, programinės įrangos inžinieriai ir kokybės užtikrinimo inžinieriai turėtų apsvarstyti, kurios programinės įrangos funkcijos yra svarbiausios programinei įrangai ir kaip geriausiai šias funkcijas išbandyti. Nešvaistykite laiko bandydami funkcijas, kurios nėra svarbios programinės įrangos veikimui.

 

2 žingsnis: Sukurkite dūmų testus

Nustačius naudotinus testavimo atvejus, galima rašyti testavimo scenarijus jiems patikrinti. Naudokite vieną scenarijų “dūmų” testams, kad padidintumėte lankstumą vykdydami testą.

Jei nuspręsite automatizuoti “dūmų” testavimą, jums nereikės kaskart rašyti rankinių testavimo scenarijų, kai norėsite atlikti “dūmų” testą. Tokiems scenarijams automatizuoti galite naudoti programinės įrangos testavimo automatizavimo rinkinius.

 

3 žingsnis: Atlikite “dūmų” testus

Sukūrę bandomųjų testų scenarijus, galite juos paleisti ir ieškoti klaidų bei kitų svarbių klaidų. Tai neturėtų užtrukti ilgiau nei 30-60 minučių, o baigę testus galėsite įvertinti rezultatus ir nustatyti tolesnius veiksmus.

 

4 veiksmas: ištaisykite visas klaidas

Programinės įrangos kūrimo bandymų tikslas – nustatyti pagrindines klaidas ar trikdžius prieš pradedant visapusišką kokybės užtikrinimo testavimą.

Jei atlikus bandomuosius testus nustatomos reikšmingos problemos, trikdančios pagrindines programinės įrangos kūrimo funkcijas, prieš tęsiant kokybės užtikrinimą svarbu grąžinti programinę įrangą ir jos analizę kūrėjų komandai, kad ši ištaisytų klaidas.

 

Geriausia dūmų bandymų praktika

 

“Smoke” testavimas yra patikimas būdas nustatyti pagrindines programinės įrangos kūrimo klaidas visuose kūrimo etapuose. Geriausias būdas užtikrinti, kad dūmų bandymai būtų veiksmingi, tikslūs ir produktyvūs, yra laikytis geriausios pramonės praktikos.

 

1. Dažnai atlikite dūmų testus

Ne visada įmanoma kasdien atlikti “dūmų” testus, ypač jei atliekate ne automatinius, o rankinius testus.

Kuo dažniau atlikite bandomuosius testus ir kiekvieną kartą, kai įgyvendinate programinės įrangos pakeitimus. Kai galėsite, geriausia praktika laikoma kasdien atlikti dūmų testus.

 

2. Niekada nepraleiskite testavimo etapų

Jei skubate, gali kilti pagunda praleisti kai kuriuos testavimo etapus, kad kūrimo procesas vyktų greičiau, tačiau tiek “dūmų”, tiek regresijos testavimas yra labai svarbūs, kad jūsų kūrimas vyktų sklandžiai.

Prieš pereidami prie kito etapo, visada išbandykite savo sukurtą versiją, atlikdami “dūmų” ir tinkamumo testus.

 

3. Patikrinkite kiekvieną pakeitimą

Nėra vienos vienintelės dūmingumo testo taikymo srities. Galite ir turėtumėte naudoti “smoke” testus, kad patikrintumėte kiekvieną programinės įrangos kūrimo pakeitimą ir išbandytumėte programinę įrangą tarp skirtingų kūrimo etapų.

“Smoke” testai turėtų būti integracijos testavimo, našumo testavimo ir funkcinio testavimo pradžia.

 

4. Stebėkite savo tyrimų rezultatus

Standartinė praktika yra patikrinti oficialaus dūmų bandymo rezultatus, tačiau net ir atlikdami neoficialius dūmų bandymus inžinieriai turėtų užfiksuoti rezultatus.

Taip lengviau perduoti rezultatus kūrėjams ir stebėti, kurios funkcijos neišlaiko testo.

 

5. Du kartus atlikite dūmų testą

Gali atrodyti, kad du kartus atlikti “dūmų testą” yra perteklinis dalykas, tačiau jei tikrai norite aptikti visas testo klaidas, geriausia jį atlikti du kartus.

Taip užtikrinama, kad atliekant bandomąjį testą būtų visos galimybės aptikti pagrindines klaidas ir problemas, kurios gali sukelti papildomų problemų, jei nebus nedelsiant pašalintos.

 

6. Pasirinkite tinkamą dūmų testo tipą

Tai, ar turėtumėte naudoti rankinį, ar automatinį “dūmų” testavimą, priklauso nuo jūsų komandos dydžio ir poreikių. Įsitikinkite, kad pasirinkote geriausią testavimo tipą savo projektui, kad optimizuotumėte veiksmingumą ir nesumažintumėte rezultatų tikslumo.

 

Dūmų bandymo rezultatų tipai

Atlikdami “dūmų” testą galite tikėtis, kad kiekvieno vertinamo testavimo atvejo rezultatas bus vienas iš dviejų: teigiamas arba neigiamas.

1. Perduoti

Vienas iš galimų kiekvieno paleisto testavimo atvejo rezultatų yra tas, kad “dūmų” testas yra teigiamas. Tai reiškia, kad faktinis testo rezultatas atitinka laukiamą testo rezultatą.

Pavyzdžiui, jei paleidžiate testą, kas vyksta įkėlus programą, ir ji įkeliama į ekraną, kuris turėtų atsidaryti įkrovimo metu, jūsų scenarijus turėtų rodyti tai kaip teigiamą rezultatą.

2. Nepavyksta

Jei “dūmų testas” nepavyksta atlikti tam tikro testo atvejo, tai paprastai reiškia, kad faktinis testo rezultatas neatitiko tikėtino testo rezultato.

Pavyzdžiui, jei testuojate apsipirkimo programą ir vienu iš atliekamų testavimo atvejų tikrinama prekių pridėjimo į krepšelį funkcija, testas nepavyksta, jei į krepšelį pridėtos prekės nepasirodo krepšelyje taip, kaip tikėjotės.

 

Bandymų atvejų pavyzdžiai, skirti “dūmų” testavimui

Kai bandote sugalvoti, kokius testavimo atvejus įtraukti į bandomąjį testą, sudarykite pagrindinių programinės įrangos funkcijų sąrašą ir apsvarstykite, kurios iš jų yra būtinos programinei įrangai paleisti ir naudoti.

Kai kurie “dūmų” testavimo atvejų pavyzdžiai gali padėti jums nustatyti, kokius testavimo atvejus naudoti savo “dūmų” testavime.

 

1. Prisijungimo duomenų patvirtinimas

Jei jūsų programoje reikalaujama, kad naudotojai prisijungtų, galite norėti sukurti bandomąjį atvejį, kuris patikrintų, ar prisijungimo duomenų patvirtinimo procesas veikia taip, kaip turėtų.

Norėdami tai padaryti, sukurkite scenarijų, kuris automatizuotų prisijungimo, testo paleidimo ir rezultatų patikrinimo veiksmus. Jei programinė įranga prisijungia, kaip tikimasi, šis bandomasis atvejis yra teigiamas.

 

2. Naujo dokumento kūrimas

Galite sukurti bandomąjį atvejį, kad įvertintumėte, ar jūsų programinė įranga leidžia naudotojams tinkamai sukurti naują dokumentą. Sukurkite scenarijų, kuris automatizuotų dokumentų kūrimą, pavadinimų suteikimą ir išsaugojimą jūsų programoje, ir paleiskite jį.

Bet kokios svarbios problemos, kurios trukdo šiam procesui, reiškia, kad šis dūmų bandymas nepavyko.

 

3. Atsijungimas

Jei jūsų programoje yra prisijungimo funkcija, joje taip pat turėtų būti ir išsiregistravimo funkcija. Paleiskite scenarijų, kad išbandytumėte, kas atsitinka, kai naudotojai paspaudžia “Atsijungti”.

Jei paspaudus šį mygtuką naudotojas negali sėkmingai atsijungti, “dūmų testas” nepavyksta.

 

Klaidų ir klaidų tipai, aptikti atliekant “dūmų” testavimą

 

“Smoke” testai gali padėti nustatyti klaidas ir klaidas, kurios trikdo pagrindinį programinės įrangos funkcionalumą. Priklausomai nuo to, kada atliekate “dūmų” testą ir ką norite patikrinti, atlikdami “dūmų” testavimą galite rasti įvairių tipų klaidų ir klaidų.

 

1. Funkcinės klaidos

Funkcinės klaidos – tai klaidos, kurios atsiranda, kai programinė įranga veikia ne taip, kaip tikėjotės, arba kai ji veikia netinkamai.

Dauguma testavimo atvejų, kuriems patikrinti naudosite “dūmų testus”, yra funkciniai testai, todėl funkcinės klaidos greičiausiai bus nustatytos atliekant tokius “dūmų testus”.

 

2. Loginės klaidos

Loginės klaidos – tai kodo logikos klaidos, dėl kurių programinė įranga gali elgtis neteisingai. Dėl loginių klaidų veiksmai gali duoti neteisingus rezultatus arba net sukelti programinės įrangos gedimus.

Dažniausiai pasitaikanti loginė klaida yra begalinė kilpa, dėl kurios programinė įranga vis kartoja tuos pačius veiksmus, kol sugenda.

 

3. Integracijos klaidos

Jei atliekate bandomąjį testą integracijos lygmeniu, testo metu galite rasti integracijos klaidų. Taip nutinka, kai du atskiri kodo rinkiniai nėra nepriekaištingai tarpusavyje integruoti. Jos gali atsirasti dėl įvairių kodo suderinamumo problemų, o joms pašalinti gali prireikti sudėtingų sprendimų.

 

Bendrosios dūmų testavimo metrikos

 

Atlikdamos “dūminį” testą, QA komandos gali naudoti metrikas, kad įvertintų “dūminio” testo rezultatus ir nuspręstų, ar testas buvo sėkmingas, ar ne.

Be to, ar programinė įranga gali tinkamai atlikti savo pagrindines funkcijas, atliekant bandomuosius testus gali būti vertinamas ir programinės įrangos greitis bei įkėlimo laikas.

 

1. Programinės įrangos greitis

“Smoke” testai gali būti naudojami siekiant patikrinti, ar programinės įrangos greitis ir įkėlimo laikas atitinka tam tikrus kriterijus, nurodytus atskiruose testavimo atvejuose.

Pavyzdžiui, jei tikrinate, kaip programinė įranga elgiasi įkėlus programą, ir programa įkeliama, kaip tikėtasi, tačiau jos įkėlimas užtrunka dvi minutes, galite tai pažymėti kaip nesėkmę, nes ji neatitinka jūsų numatyto įkėlimo laiko.

 

2. Patikimumas

Du kartus atlikdami “dūmų” testą taip pat galite patikrinti savo programinės įrangos patikimumą. Jei tam tikri bandymų atvejai vieną kartą praeina, bet vieną kartą nepavyksta, tai reiškia, kad tam tikra kodo klaida sukelia klaidų, kurios gali nepasireikšti kiekvieną kartą naudojant programinę įrangą, bet vis tiek gali sukelti rimtų problemų naudotojams.

 

Geriausi nemokami dūmų testavimo įrankiai

Dūmų testavimo įrankiai gali padėti efektyviau ir greičiau atlikti dūmų testus, kad iš jų gautumėte kuo daugiau naudos.

Toliau pateikiami keli geriausi šiandien nemokamai prieinami dūmų testavimo įrankiai.

 

5 geriausi nemokami dūmų testavimo įrankiai

1. ZAPTEST NEMOKAMAS leidimas

ZAPTEST yra nemokamas įrankis, leidžiantis vartotojams automatizuoti programinės įrangos testavimą ir RPA nemokant nė cento.

Galite naudoti “ZAPTEST FREE” versiją, kad atliktumėte paprastus “dūmų” testus keliose platformose, įskaitant mobiliąsias, žiniatinklio, API ir LOAD platformas.

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

Jei norite išbandyti automatizuotą dūmų testavimą, nemokama ZAPTEST versija padės jums įsitikinti automatizavimo privalumais iš pirmų lūpų. Ją taip pat lengva naudoti, net jei nesate techninio išsilavinimo, nes jos sąsaja neturi kodo ir joje naudojama naujausia kompiuterinės regos technologija.

Svarbiausia, ZAPTEST FREE yra gerai…. nemokamai visiems laikams! Priešingai, daugelyje dūmų testavimo ir bendrųjų programinės įrangos automatizavimo įrankių numatytas pradinis testavimo laikotarpis, po kurio reikia mokėti prenumeratos mokesčius.

 

2. Selenas

“Selenium” yra nemokamas atvirojo kodo įrankis, kurį galite naudoti įvairiems programinės įrangos bandymams atlikti, įskaitant “dūmų” ir regresijos bandymus. Ji veikia su daugybe skirtingų programavimo kalbų ir ypač tinka žiniatinklio programoms testuoti.

 

3. Appium

Jei norite atlikti mobiliųjų programėlių “dūmų” ir tinkamumo testavimą, “Appium” yra geresnis pasirinkimas nei “Selenium”. Programą “Appium” lengva įdiegti ir naudoti, ja galima atlikti nesudėtingus “iOS” ir “Android” sukurtų programėlių “dūmų” testus.

 

4. Testlink

Testlink – tai nemokama žiniatinklio valdymo priemonė, leidžianti naudotojams rengti bandymų planus ir bandymų atvejus vienoje struktūrizuotoje sistemoje. “Testlink” gali padėti jums suplanuoti “dūmų” testus, taip pat nusakyti jūsų lūkesčius ir rodiklius prieš pradedant “dūmų” testavimą.

 

5. QA Wolf

“QA Wolf” – tai nemokama visapusiško testavimo priemonė, kuria naudotojai gali kurti automatizuotą QA dūmų testą kartu su kitais funkciniais testais. “QA Wolf” gali naudotis net ir žmonės, neturintys techninių ar programavimo įgūdžių, todėl tai puiki įžanga į bandymų automatizavimą daugumai QA komandų.

 

Geriausi įmonės dūmų testavimo įrankiai

 

Jei esate pasirengę investuoti šiek tiek pinigų į dūmų testavimo įrankius, galite nusipirkti įmonės įrankius, kurie turi platesnes dūmų testavimo galimybes ir išsamesnius rezultatus.

Toliau pateikiamas penkių geriausių rinkoje esančių įmonės dūmų testavimo automatizavimo įrankių sąrašas.

 

5 geriausi įmonės dūmų testavimo automatizavimo įrankiai

 

1. ZAPTEST ENTERPRISE leidimas

“ZAPTEST ENTERPRISE edition” – tai programinės įrangos testavimo ir RPA rinkinys, kuriuo galima visiškai automatizuoti bet kokio tipo testus, įskaitant “dūmų” testavimą.

Nemokama versija tinka mažesnėms įmonėms, norinčioms sužinoti, ką gali ZAPTEST, tačiau jei ieškote mokamo sprendimo, kurį lengva naudoti ir kuris tinka bet kokiai programinei įrangai ar programėlei testuoti bet kurioje platformoje, naršyklėje ar įrenginyje, ir kuriame būtų įdiegta 1SCRIPT, tuomet ZAPTEST ENTERPRISE yra puiki pradžia.

 

2. SoapUI

“SoapUI” – tai įmonės testavimo įrankis, kuris leidžia lengvai valdyti ir atlikti programinės įrangos galutinius QA testus. Tai gana paprastas įrankis, tačiau jis turi trūkumų, kurie atsispindi jų kainodaroje.

 

3. Testas

“Testim” yra mokamas “smoke test” įrankis, kuris naudoja dirbtinį intelektą, kad sukurtų bekodinius testus, kuriais įvertinamas jūsų programinės įrangos funkcionalumas. Testim Javascript API galima naudoti testams pertvarkyti, pritaikyti ir derinti.

 

4. “T-Plan” robotas

“T-Plan Robot” yra įmonės testavimo įrankis, kurį QA inžinieriai gali naudoti skriptuotiems naudotojų veiksmams automatizuoti ir robotų procesų automatizavimui (RPA ) “Windows”, “Mac”, “Linux” ir mobiliuosiuose įrenginiuose. Naudodami “T-Plan Robot” galite automatizuoti įvairių taikomųjų programų “dūmų” testus ir kurti automatizuotus scenarijus, kuriuos galima paleisti svarbiausiais kūrimo etapais.

 

5. Rainforest QA

“Rainforest QA” – tai QA dūmų testavimo įrankis, leidžiantis naudotojams valdyti ir įgyvendinti rankinį ir automatinį dūmų testavimą iš vieno prietaisų skydelio. Todėl ji idealiai tinka organizacijoms, norinčioms išbandyti hibridinį požiūrį, ir tinka įvairioms platformoms, įskaitant debesų programoms, “Windows” ir “Mac”.

 

Kada reikėtų naudoti įmonės, o kada – nemokamus dūmų testavimo įrankius?

 

Įmonių ir nemokami dūmų testavimo įrankiai gali patenkinti panašius poreikius šiek tiek skirtingais būdais. Paprastai nemokami įrankiai yra puikūs vartai į organizacijas, kurios gerai įvaldžiusios rankinį dūmų testavimą, bet nori išsamiau ištirti automatinį dūmų testavimą.

Jie taip pat gali būti tinkamesni labai mažoms pradedančiosioms įmonėms, kuriose dar nėra pinigų mokamoms priemonėms.

Įmonių testavimo įrankiai paprastai tampa perspektyvesne galimybe įmonėms plečiantis. Jie turi daug privalumų, palyginti su nemokamomis priemonėmis, ir paprastai pasižymi didesniu lankstumu, geresniu palaikymu ir patogesnėmis vartotojo sąsajomis, todėl automatizuotą dūmų testavimą gali lengvai atlikti net ir techninių žinių neturintys specialistai.

 

Dūmų testavimo kontrolinis sąrašas

 

Prieš pradėdami “dūmų” testavimą, programinės įrangos kokybės užtikrinimo komandos nariai gali pasinaudoti šiuo kontroliniu sąrašu, kad įsitikintų, jog jie apima visus “dūmų” testavimo proceso etapus.

● Nustatykite naudotinus dūmų testavimo įrankius
● Pasirinkite, ar ketinate kurti rankinį, ar automatinį testą
● Pasirinkite testavimo atvejus, kuriuos norite testuoti
● Sukurti kiekvieno atvejo testavimo scenarijus
● Nustatykite kiekvieno testavimo atvejo “išlaikymo” reikalavimus
● Atlikite dūmų testus
● Analizuokite rezultatus
● Grįžtamasis ryšys su kūrimu ir kokybės užtikrinimu

 

Išvada

 

“Smoke” testavimas yra esminis programinės įrangos kūrimo ir kokybės užtikrinimo etapas. Taip užtikrinama, kad produktas būtų funkcionalus prieš atliekant tolesnį testavimą, todėl išvengiama rizikos, kad kokybės užtikrinimo komandos gaiš laiką ir išteklius intensyviam funkciniam testavimui su dar nestabiliomis sudėtinėmis versijomis.

“Smoke” testavimas yra gana greitas ir paprastas procesas, kurį programinės įrangos komandos turėtų atlikti kuo dažniau.

Įmonėms stengiantis pasiekti optimalų efektyvumą naudojant pažangias priemones, palaikančias hiperautomatizavimą, RPA ir kitas susijusias technologijas, automatizuotas dūmų testavimas tampa vis labiau paplitęs įvairaus dydžio organizacijose.

Šiuolaikinėje kokybės užtikrinimo aplinkoje vis dar yra vietos ir rankiniam, ir automatiniam “dūmų” testavimui, tačiau, kadangi automatinis testavimas tampa vis labiau paplitęs, nėra abejonių, kad jis taps norma.

 

DUK ir ištekliai

 

Kokie yra geriausi kursai apie dūmų testavimo automatizavimą?

 

Jei norite daugiau sužinoti apie dūmų testavimo automatizavimą, galite pasinaudoti šiais internetinių kursų pavyzdžiais:

● “Coursera” dūmų testavimo kursai
● “Udemy” dūmų testavimo kursai
● “Skillshare” dūmų testavimo kursai

Vienas iš geriausių kursų pradedantiesiems yra “Udemy” siūlomas “Certified Tester ISTQB Foundation Level” (CTFL).

Kiekviename iš šių internetinių išteklių siūlomi dūmų testavimo kursai, skirti įvairių gebėjimų mokiniams, ir šiose svetainėse galima lankyti tiek nemokamus, tiek mokamus kursus.

Jei norite gauti sertifikatą, ieškokite CAST akredituotų kursų.

 

Kokios yra geriausios knygos apie dūmų testavimą?

 

Jei norite daugiau sužinoti apie “dūmų testavimą”, galite skaityti knygas apie programinės įrangos testavimą ir “dūmų testavimą”, kad geriau suprastumėte “dūmų testavimo” metodus ir privalumus. Keletas geriausių knygų apie dūmų testavimą:

● “Programinės įrangos testavimo menas”, autoriai Glenfordas J. Myersas, Tomas Badgettas ir Corey Sandleris
● Programinės įrangos testavimas, autorius Ron Patton
● Programinės įrangos testavimo automatizavimas, Mark Fewster ir Dorothy Graham

Tačiau yra daugybė puikių knygų apie programinės įrangos testavimą, kurios gali padėti geriau suprasti, kaip, ką ir kodėl testuoti.

Pasirinkite jums patrauklią knygą, kurioje išsamiau nagrinėjamos jus labiausiai dominančios temos.

 

Kokie yra 5 svarbiausi interviu klausimai apie dūmų testavimą?

 

Jei ketinate dalyvauti pokalbyje dėl darbo vietos, kurioje gali tekti atlikti dūmų testavimą, pasiruoškite pokalbiui ir pasiruoškite atsakymus į dažniausiai užduodamus klausimus, pvz:

● Kada reikia atlikti dūmų bandymus?
● Kaip nuspręstumėte, kokius testavimo atvejus naudoti atliekant bandomąjį testą?
● Kuo dūmų testavimas skiriasi nuo kitų testavimo tipų, pvz., tinkamumo testavimo?
● Kiek programavimo žinių reikia norint atlikti dūmų testus?
● Ką darytumėte, jei dūmų bandymas nepavyktų?

 

Kokios yra geriausios “YouTube” pamokos apie dūmų testavimą?

 

Jei mokotės vizualiai, galite pasinaudoti šiais “YouTube” vaizdo įrašais, kad sužinotumėte daugiau apie dūmų testavimą:

“Edureka” dūmų testavimo pamoka
Kas yra dūmų bandymas?
Dūmų testavimas ir tinkamumo testavimas

 

Kaip atlikti dūmų bandymus?

 

“Smoke” testų priežiūra – tai užtikrinimas, kad jūsų sukurti “smoke” testai išliktų sveiki ir aktualūs, kai programinės įrangos kūrimo projektas tęsiamas.

Kasdien atlikite “smoke” testus ir kurkite naujus testavimo atvejus, kai jų prireikia.

Taip pat galite maksimaliai padidinti “dūmų” testų naudą glaudžiai bendradarbiaudami su tais kūrėjais, kurių indėlis nepagerina jų kodo kokybės.

 

Kas yra dūmų testavimas programinės įrangos inžinerijoje?

 

Programinės įrangos inžinerijoje “dūmų” testavimas taip pat vadinamas kūrimo patikros testavimu ir yra paprastas ir greitas testas, kuriuo užtikrinama, kad programinės įrangos kūrimas būtų stabilus.

“Smoke” testavimas naudojamas pagrindinėms sąrankos funkcijoms išbandyti ir yra preliminarus testavimas prieš atliekant tolesnį QA testavimą.

 

Dūmų testavimas ir tinkamumo testavimas

 

“Smoke” ir “Sanity” testavimas – tai testavimo tipai, apimantys greitą programinės įrangos ar produkto pagrindinių funkcijų testavimą.

Tačiau atliekant “dūmų” testavimą tikrinama, ar pagrindinės programinės įrangos funkcijos veikė taip, kaip tikėtasi, o “tvarkingumo” testavimas paprastai naudojamas siekiant patikrinti, ar ištaisius klaidas buvo ištaisytos nustatytos problemos.

“Smoke” testavimas yra labiau formalus ir dokumentuotas procesas, kuris paprastai atliekamas prieš tikrinant, ar dieginys yra stabilus, o “Sanity” testavimas yra neoficialus testavimas, kuris gali būti atliekamas kaip palyginti stabilių dieginių regresijos testavimo dalis.

 

Dūmų testavimas ir regresijos testavimas

 

“Smoke” ir regresinis testavimas – tai abiejų tipų testavimas, kurio metu tikrinama, ar programinė įranga tinkamai veikia ir po naujų pakeitimų.

Tačiau “dūmų testavimas” yra palyginti greitas ir nedidelio išsamumo testavimo būdas, kurio metu tiesiog tikrinamos pagrindinės funkcijos ir užtikrinamas programinės įrangos stabilumas.

Regresijos testavimas yra gilesnio lygio testas, kuris trunka daug ilgiau ir kurio metu išsamiau įvertinama sąranka.

 

“Smoke” testavimas vs “Sanity” testavimas vs regresijos testavimas

 

Lygindami “dūmų” ir tinkamumo testavimą su regresijos testavimu, svarbu suprasti, kad visi šie trys testų tipai yra būtini norint gerai kurti programinę įrangą ir užtikrinti jos kokybę.

“Smoke” testavimas ir “sanity” testavimas yra greitas būdas patikrinti, ar programinė įranga veikia normaliai, o regresijos testavimas leidžia geriau suprasti, kaip veikia produktas.

Kokybės užtikrinimo komandos pirmiausia atlieka programinės įrangos bandymus, o jei programinė įranga išlaiko šią patikrą, galima atlikti tinkamumo testavimą, o vėliau – regresijos testavimą.

Automatizuotas “dūmų” testavimas naudojant “dūmų” testavimo įrankius tampa vis labiau paplitęs, tačiau kai kurių tipų testavimo, pavyzdžiui, regresijos testavimo, dar neįmanoma visiškai automatizuoti dėl sudėtingo testavimo pobūdžio.

Galiausiai, jei ieškote įrankių, kurie padėtų atlikti bandymus “Windows” platformose, “iOS”, ” Android”, vartotojo sąsajos testus, “Linux” ir daugelyje kitų, imkitės ir atsisiųskite ZAPTEST NEMOKAMAI!

Download post as PDF

Alex Zap Chernyak

Alex Zap Chernyak

Founder and CEO of ZAPTEST, with 20 years of experience in Software Automation for Testing + RPA processes, and application development. Read Alex Zap Chernyak's full executive profile on Forbes.

Get PDF-file of this post