Patikrinkite automatikos patarimus ir geriausią praktiką

Automatinis testavimas yra svarbi testavimo veikla per programinės įrangos kūrimo gyvavimo ciklą, nes tai gali greitai suteikti komandai grįžtamąjį ryšį, kai bus sukurta nauja funkcija.

Tai taip pat pašalina kokybės užtikrinimo naštą pakartotinai atliekant regresijos testus, o tai taupo laiką, kai QA gali sutelkti dėmesį į kitą testavimo veiklą.

„Test Automation“, atlikus teisingai, gali būti labai naudinga komandai. Toliau pateikiami patarimai padės jums kuo geriau išnaudoti automatizuoto testavimo procesą ir veiklą, taip pat pabrėžia spragas, kurių reikia išvengti pradedant automatizuoti testus.

Rankinis ir automatinis - testavimas ir tikrinimas

Venkite neautomatinio ir automatinio testavimo palyginimo. Jie abu reikalingi, nes kiekvienas iš jų turi skirtingą tikslą. Automatiniai testai - tai instrukcijų rinkinys, kurį asmuo parašo atlikti tam tikrą užduotį. Kiekvieną kartą, kai atliekamas automatizuotas testas, jis atliks tuos pačius veiksmus, kaip nurodyta, ir tikrins tik tuos dalykus, kuriuos prašoma patikrinti.

Kita vertus, atliekant rankinį bandymą, testerio smegenys yra įsitraukusios ir gali pastebėti kitus sistemos gedimus. Bandymo etapai nebūtinai turi būti vienodi kiekvieną kartą, nes bandymo metu testuotojas gali pakeisti srautus; tai ypač pasakytina apie tiriamuosius bandymus.

Automatizuokite regresijos testus

Pagrindinė priežastis, kodėl norite automatizuoti testą yra tai, kad norite pakartotinai atlikti kiekvieno naujo leidimo testą. Jei bandymą reikia atlikti tik vieną kartą, pastangos automatizuoti testą gali nusverti naudą.

Regresijos testai turi būti atliekami pakartotinai, kai bandoma programinė įranga tobulėja. Tai gali būti labai daug laiko reikalaujanti ir nuobodi užduotis, kad QA turėtų kasdien atlikti regresijos testus. Regresijos testai yra geri bandymų automatizavimo kandidatai.

Dizaino testai prieš juos automatizuojant

Visada yra gera praktika sukurti bandymų atvejus ir scenarijus prieš pradedant automatizuoti testus. Tai yra geras testo dizainas, kuris gali padėti nustatyti defektus, automatizuoti bandymai tik vykdo testo projektą.

Pereinant tiesiai į automatizavimą kyla pavojus, kad jus domina tik scenarijaus veikimas ir paprastai tik teigiamų ir laimingų srautų scenarijų automatizavimas, o ne galvojimas apie kitus galimus išbandomus scenarijus.

Taip pat nesumažinkite testavimo apimties, kad testas veiktų ar būtų išlaikytas.

Pašalinkite neapibrėžtumą iš automatizuotų bandymų

Vienas iš pagrindinių automatizuoto testavimo momentų yra galimybė pateikti nuoseklius rezultatus, kad būtume tikri, jog kažkas nepavyko, kai bandymas nepavyko.

Jei automatinis bandymas praeina per vieną bandymą ir nepavyksta kitame bandyme, be jokių bandomos programinės įrangos pakeitimų, negalime būti tikri, ar gedimas įvyko dėl programos, ar dėl kitų veiksnių, tokių kaip bandymo aplinkos problemos ar problemos pats testo kodas.

Kai yra nesėkmių, turime analizuoti rezultatus, kad sužinotume, kas nutiko ne taip, o kai turime daug nenuoseklių ar klaidingai teigiamų rezultatų, tai pailgina analizės laiką.

Nebijokite pašalinti nestabilių testų iš regresijos paketų; Vietoj to, siekite nuoseklių švarių rezultatų, kuriais galite pasikliauti.

Peržiūrėkite automatizuotus galiojimo testus

Jus sunerims didelis pasenusių automatizuotų testų skaičius, tik nieko netikrinkite arba netikrinate svarbiausių patikrinimų!

Tai gali būti perėjimo tiesiai į automatizavimą simptomas, neišleidžiant pakankamai laiko prieš tai planuojant, ką reikia padaryti, ir kuriant gerus bandymų scenarijus.

Visada turėkite kolegą, kuris peržiūrėtų automatizuotus validumo ir protingumo testus. Įsitikinkite, kad testai yra atnaujinti.

Negalima automatizuoti nestabilios funkcijos

Kuriant naują funkciją ar funkcionalumą, daug kas gali suklysti ir net ši funkcija gali būti nebetaikoma, nes verslas apsigalvojo.

Jei bandymus pradėjote automatizuoti tobulindami funkciją, testus reikia daug kartų atnaujinti, nes funkcija tobulėja ir gali būti gana nelengva bandant neatsilikti nuo visų pakeitimų. Ir jei ši funkcija nebetaikoma, visos bandymų automatikos pastangos yra švaistomos.

Todėl visada geriausia automatizuoti funkciją, kai ji bus stabilizuota ir bus mažiau keičiama.

Nesitikėkite magijos iš bandymų automatikos

Pagrindinė bandymų automatizavimo priežastis yra atlaisvinti QA laiką įdomiems tiriamiesiems bandymams ir suteikti komandai pasitikėjimo, kad programa vis dar tvarkinga, kai pateikiami nauji pakeitimai.

Nesitikėkite, kad automatika ras daugybę klaidų . Tiesą sakant, automatizavimo metu nustatytų klaidų yra daug mažiau nei rankiniu ir tiriamuoju bandymu.

Negalima pasikliauti vien automatika - saugokitės išlaikymo testų

Automatiniai regresijos testai gali suteikti komandai pasitikėjimo jausmą, nes regresijos testai vis tiek turėtų praeiti, kai pateikiama nauja funkcionalumas. Komanda pradeda pasikliauti testais ir turėti gerą regresijos testų rinkinį gali veikti kaip apsauginis tinklas.

Tačiau atkreipkite dėmesį, kad ne visi bandymai yra automatizuoti arba gali būti automatizuoti, todėl visada kartu su automatizuotais bandymais atliekami tiriamieji bandymai.

Kartais programinės įrangos pakeitimas gali nepavykti išbandyti; tačiau, jei visi bandymai yra sėkmingi, tai reiškia, kad defektas yra praleistas ir kadangi nebuvo raginimo veikti, defektas liko nepastebėtas.

Siekite greito grįžtamojo ryšio

Greitas grįžtamasis ryšys yra vienas iš automatizuotų bandymų tikslų, nes kūrėjai nori sužinoti, ar tai, ką jie sukūrė, veikia ir nepažeidė dabartinių funkcijų.

Norint gauti šią greitą grįžtamąjį ryšį, testus reikia automatizuoti komponento ar API sluoksnyje, nesikliaujant vartotojo sąsaja.

Vartotojo sąsajoje vykdomi bandymai yra daug lėtesni ir dėl klaidų dėl GUI pakeitimų yra linkę į klaidas. Kitaip tariant, funkcionalumas vis tiek veikia taip, kaip tikėtasi, tačiau testai nepavyksta dėl vartotojo sąsajos pakeitimų. Todėl testai gali tapti nepatikimi.

Suprasti kontekstą

Testus galima automatizuoti bet kuriame sluoksnyje, vienete, API, tarnyboje, GUI. Kiekvienas sluoksnis atlieka skirtingą bandymų tikslą.
„Unit Tests“ užtikrina, kad kodas veikia klasės lygiu, kad jis sudaromas ir logika yra tokia, kokios tikėtasi. Šio sluoksnio bandymai yra daugiau patikrinimas nei patvirtinimas.

API testai arba integravimo testai užtikrina, kad funkcijų ir klasių rinkinys gali veikti kartu, o duomenys gali būti perduodami iš vienos klasės į kitą.

Kita vertus, GUI testai tikrina vartotojo srautus ir keliones. Paprastai netikrinsime vartotojo sąsajos funkcionalumo. Tai turėtų būti padaryta žemesniuose sluoksniuose.

Pagrindinis vartotojo sąsajos testų tikslas yra užtikrinti, kad visa sistema veiktų pagal kai kuriuos įprastus vartotojo scenarijus ir naudojimo atvejus. Testavimas šiame sluoksnyje yra daugiau tikrinimas, o ne tikrinimas

Vartotojo sąsajos lygiu mes labiau automatizuojame scenarijus, o ne istorijas.

Negalima automatizuoti kiekvieno testo

100% testo aprėptis neįmanoma, nes gali būti milijonai derinių. Mes visada atliekame galimų bandymų pogrupį. Tas pats principas galioja ir automatiniams bandymams.

Norint sukurti automatizuotą scenarijų, reikia laiko ir pastangų, o siekiant „Kiekvieno testo automatizavimo“ reikia daug išteklių ir laiko, o tai daugeliu atvejų neįmanoma.

Vietoj to, naudokite rizika pagrįstą metodą, kad nustatytumėte, kurie testai turėtų būti automatizuoti. Norėdami gauti kuo daugiau naudos iš automatikos, automatizuokite tik svarbiausius verslo atvejus ir scenarijus.

Be to, didelis automatizuotų bandymų skaičius padidina priežiūros išlaidas ir juos sunku prižiūrėti.

Dar viena nepamirštama pastaba yra ta, kad ne visus bandymus galima automatizuoti. Kai kurie testai yra labai sudėtingo pobūdžio ir reikalauja daugybės sistemos patikrų ir gali būti nenuoseklūs. Tokiais atvejais geriausia palikti šiuos patikrinimus rankiniam patikrinimui.

Testavimo automatikoje naudokite bandymo metodiką

Testavimo metodai, kuriuos išmokote ISTQB, nėra skirti tik rankiniam testavimui. Jie taip pat taikomi automatiniams bandymams. Tokie metodai kaip ribinės vertės analizė, ekvivalentiškumo padalijimas, valstybinio perėjimo testavimas, porinis testavimas gali suteikti daug naudos atliekant automatizuotą testavimą.

Negalima automatizuoti chaoso

Norint kuo geriau išnaudoti automatizuotą testavimą, turėtų būti įdiegtas geras kokybės užtikrinimo procesas. Jei kokybės užtikrinimo procesas yra chaotiškas ir prie to chaoso pridedame automatizuotą testavimą, viskas, ką gauname, yra greitesnis chaosas.

Pabandykite atsakyti į tokius klausimus, kaip automatizuoti, Kada automatizuoti , Kada atlikti automatinius testus, kas automatizuos testus, kokie įrankiai turėtų būti naudojami bandymų automatizavimui ir kt.

Šie patarimai daugiausia surinkti iš automatikos bandytojo patirties ir kitų gerosios praktikos pavyzdžių.

Ar turite kokių nors bandymų automatizavimo patarimų, kuriuos norite įtraukti į šį sąrašą?