Testavimo automatikos privalumai ir trūkumai

Tinkamai atlikta bandymų automatika gali turėti daug privalumų ir būti labai naudinga projektui ir organizacijai. Tačiau turime žinoti apie bandymų automatikos spąstus ar trūkumus.

Testavimo automatikos pranašumai

Kokie yra bandymų automatikos pranašumai?

Žinomo patvirtinimas

Automatiniai patikrinimai yra puikus būdas patvirtinti, kad programa vis tiek tinkamai veikia atlikus jos pakeitimus.

Gali būti, kad kai prie programos pridedama nauja funkcija arba ištaisoma klaida, tai veikia veikiančios programinės įrangos funkcionalumą, t. Y. Įdiegiama regresijos klaida.

Vykdydami automatinių regresijos patikrinimų rinkinį, kai programa atnaujinama, galime nustatyti visas naujas klaidas, kurios atsirado dėl pakeitimų.

Pagrindinė informacija yra automatinių patikrinimų atlikimas, kai tik atnaujinama programa.

Nereikia vykdyti visų automatinių patikrinimų. Turėtų pakakti greito dūmų regresavimo paketo, kad išsiaiškintumėte bet kokius pagrindinius klausimus.

Greitas atsiliepimas

Kitas didelis automatizuotų patikrinimų privalumas yra greitas grįžtamasis ryšys, kurį gauname atnaujinę programą. Idealiu atveju kūrėjų komanda turėtų ištaisyti visas nesėkmes, kai tik jos atsiranda, prieš pereidama prie kitų užduočių.

Atkreipkite dėmesį kad šį greitą grįžtamąjį ryšį galima pasiekti tik atlikus vieneto testus ir API testus. Jei išbandysime funkcionalumą iš vartotojo sąsajos arba sistemos lygiu, bandymai gali užtrukti ilgai.

Greitas patikrinimų atlikimas

Automatinių patikrinimų scenarijus gali užtrukti. Tačiau kai mes juos įvykdome, jie paprastai yra greiti ir gali atlikti įvairius veiksmus daug greičiau nei žmogus. Todėl jie padeda greitai pateikti atsiliepimus kūrėjų komandai.

Tai ypač pasakytina apie duomenų valdomus scenarijus.

Atlaisvina testuotojų laiką

Geriausias automatinių patikrinimų naudojimas yra regresijos testai.

Regresijos testų automatizavimas atlaisvina testuotojų laiką, todėl jie gali daugiau dėmesio skirti tiriamiesiems naujų funkcijų bandymams.

Tuo pačiu principu, kai tinkamai įgyvendinami, automatiniai patikrinimai gali būti atliekami automatiškai, atliekant minimalią priežiūrą arba be jokios priežiūros ar rankiniu būdu.

Kūrėjų komanda gali prisidėti

Automatiniai patikrinimai paprastai rašomi ta pačia kalba kaip ir bandoma programa. Dėl šios priežasties atsakomybė už testų rašymą, palaikymą ir vykdymą tampa bendra atsakomybe.

Prie kūrimo komandos gali prisidėti visi, ne tik testuotojai.

Testavimo automatikos trūkumai

Kokie yra bandymų automatikos trūkumai?

Klaidingas kokybės jausmas

Saugokitės išlaikę testus! Tai ypač svarbu tikrinant funkcionalumą vartotojo sąsajos ar sistemos lygiu.

Automatinis patikrinimas tikrina tik tai, kas užprogramuota tikrinti.

Visi automatiniai patikrinimai testų rinkinyje gali būti laimingi, tačiau gali būti nepastebėta didelių trūkumų. To priežastis yra ta, kad automatinis patikrinimas nebuvo užkoduotas „ieškoti“ tų gedimų.

Sprendimas: prieš juos automatizuodami įsitikinkite, kad sukūrėte gerus bandymų scenarijus. Automatizuotas patikrinimas yra toks pat geras, kaip ir testo dizainas. Be to, automatinius patikrinimus papildykite rankiniais / tiriamaisiais bandymais.

Nepatikima

Automatizuoti patikrinimai gali nepavykti dėl daugelio veiksnių. Jei automatiniai patikrinimai vis nepavyksta dėl kitų problemų nei tikros klaidos, jie gali sukelti klaidingą aliarmą.

Pvz., Automatiniai patikrinimai gali nutrūkti dėl vartotojo sąsajos pakeitimo, neveikiančios paslaugos ar tinklo problemų.

Šios problemos nėra tiesiogiai susijusios su bandoma programa, tačiau gali turėti įtakos automatinių patikrinimų rezultatams.

Sprendimas: Jei įmanoma / taikoma, naudokite kamienus. Įspėjimai įveikia ryšio ar trečiųjų šalių sistemų pokyčių problemas. Todėl automatiniai patikrinimai būtų nepriklausomi nuo bet kokių gedimų pakopoje.

„Test Automation“ nėra testavimas

Deja, daugelis žmonių klaidina „Test Automation“ su „Testing“.

Turėdami įrankius testavimui automatizuoti, jie nori „automatizuoti visus testus“. Jie nori atsikratyti visų „rankinių bandytojų“.

Tiesa ta, kad bandymai yra tyrinėjimo pratybos. Testavimui reikalingos žinios apie sritį, susitelkęs protas ir noras išmokti programą.

Testavimas nėra tik iš anksto nustatytų bandymo veiksmų rinkinio vykdymas ir faktinių rezultatų palyginimas su laukiamais rezultatais. Tai yra automatizuotų patikrinimų darbas.

Norint tinkamai išbandyti programą, visada reikalingas žmogaus intelektas.

Sprendimas: Supraskite, kad norint sėkmingai įgyvendinti projektą reikia atlikti automatinį ir rankinį testavimą.

Vienas nėra kito pakaitalas; automatinius patikrinimus papildyti rankiniu / tiriamuoju bandymu.

Priežiūros laikas ir pastangos

Turite sutikti su tuo, kad automatinius bandymus reikia prižiūrėti. Keičiantis bandomajai programai, turėtų keistis ir automatiniai patikrinimai.

Automatizuoti patikrinimai yra trumpalaikiai. Jei regresijos paketai nėra atnaujinami, jūs pradedate matyti visokių gedimų.

Gal kai kurie patikrinimai nebėra aktualūs. O gal patikrinimai nėra tikras naujų įdiegimų pavyzdys.

Šie gedimai gali užteršti bandymų rezultatus.

Pradėti bandymų automatizavimą nėra vienkartinės pastangos. Norint kuo geriau išnaudoti automatizuotus patikrinimus, jie turi būti nuolat atnaujinami ir aktualūs. Tam reikia daug laiko, pastangų ir išteklių.

Sprendimas: Kadangi techninės priežiūros veiksnys yra nuolatinė veikla, investuokite laiką kurdami gerą sistemą. Norėdami palengvinti priežiūros darbus, naudokite daugkartinius modulius, atskirkite testus nuo sistemos ir naudokite gerus projektavimo principus.

Lėtas atsiliepimas

Kai funkcionalumas yra paruoštas išbandyti, dažniausiai rankiniu būdu patikrinama greičiau.

Problema ta, kad automatinių patikrinimų scenarijai gali užtrukti ilgai, atsižvelgiant į testo sudėtingumą. Todėl atlikus rankinį patikrinimą galima gauti greitesnį grįžtamąjį ryšį nei scenarijaus, paleidimo ir rezultatų tikrinimo.

Be to, kalbant apie vartotojo sąsają ir sistemos lygio testavimą, automatinių patikrinimų atlikimas ir ataskaitų pateikimas gali užtrukti ilgai. Todėl, jei yra tikra klaida, mes galime nežinoti, kol neužbaigsite visų bandymų.

Sprendimas: Pabandykite automatizuoti testus kartu su kūrimu, kad, kai kūrimas bus baigtas, galėsite atlikti automatinius testus pagal naują funkciją.

Be to, atskirkite automatinius patikrinimus skirtingose ​​pakuotėse.

Dūmų regresavimo paketas turėtų būti labai greitas. Testai turėtų tik patikrinti, ar galima paleisti programą ir pasiekti ją.

Tada galite turėti funkcinį regresijos paketą, kuris patikrins pagrindines funkcijas.

Į kitą regresijos paketą gali būti įtraukti visi nuo galo iki galo ir nuodugnūs testai. Šie patikrinimai gali būti atliekami per naktį.

Naktinio bėgimo pavyzdys yra kelių naršyklių automatiniai patikrinimai. Paprastai tai užtrunka ilgai, kol veikia visos naršyklės.

Aptikta nedaug klaidų

Atrodo, kad daugumą klaidų randa „nelaimingas atsitikimas“ arba atliekant žvalgomuosius bandymus.

Taip yra tikriausiai todėl, kad kiekvienoje tiriamojoje bandymo sesijoje programą galėtume išbandyti skirtingais būdais.

Kita vertus, automatiniai regresijos patikrinimai visada eina nurodytu keliu. Kartais su tuo pačiu bandymų duomenų rinkiniu. Tai sumažina galimybę rasti naujus programos trūkumus.

Regresijos klaidų skaičius taip pat yra mažesnis nei naujų funkcijų klaidų.

Sprendimas: Pabandykite sukurti atsitiktinumą scenarijuje ir duomenyse. Kiekvieną kartą bandydami skirtingus kelius su skirtingais duomenimis, galite atskleisti galimas problemas.

Išvada

Šiame įraše mes apžvelgėme kai kuriuos automatinio testavimo pranašumus ir trūkumus. Kai dalyvaujame automatizuojant testus, turėtume atsižvelgti į pirmiau nurodytus dalykus, kad gautume didžiausią naudą.