Preskusite strategijo avtomatizacije za agilne projekte

Ta primer strategije avtomatizacije preizkusov predvideva model neprekinjene dostave z več agilnimi skupinami.

V prejšnjih člankih krovno Agilna preizkusna strategija dokument, kot tudi kako nastaviti funkcijo QA od začetka za agilen projekt in kako je avtomatizirano testiranje eden ključnih elementov v začetni nastavitvi.

V tem primeru strategije avtomatizacije preizkusa navajam ključne točke, ki jih je treba upoštevati, da bi kar najbolje izkoristili prizadevanja za avtomatizacijo preskusov.




Povzetek

Avtomatizirano testiranje je temeljna dejavnost katere koli agilne razvojne metodologije. Ko se premikamo k nenehni uvajanju, je avtomatizacija preizkusov vedno pomembnejša zaradi hitrega odziva s povratnimi informacijami, ki ga nudi razvojni skupini o zdravstvenem stanju aplikacije.

Da bi dobili te hitre povratne informacije, je treba avtomatizirane teste izvajati neprekinjeno, biti morajo hitri, rezultati testov pa morajo biti dosledni in zanesljivi.


Da bi jih dosegli, bi bilo treba večino preverjanj opraviti v okviru razvoja novih funkcij. Z drugimi besedami, razvoj in testiranje bi moralo biti skladna dejavnost, kakovost pa bi bilo treba že od samega začetka 'vpeti', tako da zagotovimo, da to, kar se razvija, deluje in da ni prekinilo obstoječe funkcionalnosti.

To zahteva 'obrnitev preizkusne piramide avtomatizacije' s potiskanjem testov GUI, ki se dolgo izvajajo, na nižje ravni, npr. Plast API, ki se lahko zažene takoj po preskusih enote kot del gradnje, da zagotovi začetno stopnjo zaupanja.

Sorodno:



Pregled strategije avtomatizacije preskusov

Preprečevanje in ne odkrivanje - čeprav je treba vložiti vse napore v preprečevanje vnašanja napak v aplikacijo, vendar tehnike in metode za to ne spadajo v to objavo. Tu so opredeljene metodologije, ki omogočajo hitro odkrivanje napak, ko so uvedene v sistem, in povratne informacije o razvoju.


Kakovost naj bo prednostna količini. V večini primerov je bolje, da izdate z eno značilnostjo, ki je trdno, namesto z več funkcijami, ki se luščijo. Kot minimalno merilo sprostitve nobena novo razvita lastnost ne sme vsebovati nobenih regresijskih napak.

Kot smo že omenili, so hitre povratne informacije o stanju aplikacije izjemno pomembne za podporo neprekinjene dostave, zato sta oblikovana postopek in mehanizem, s katerim lahko hitro pridobimo povratne informacije.

Eden od načinov hitrega pridobivanja povratnih informacij je povečanje števila preskusov enote, preskusov integracije in preskusov API. Ti preskusi na nizki ravni bodo zagotovili varnostno mrežo, ki bo zagotovila, da koda deluje, kot je predvideno, in pomagala preprečiti uhajanje napak v drugih slojih testiranja.

Enotni testi tvorijo temelje za avtomatizacijo testov na višjih ravneh.


Drugi element izboljšav je pogostejše izvajanje regresijskih testov in usklajenost s postopkom nenehne integracije, glej kasneje. Na avtomatizacijsko preskušanje ne bi smeli gledati kot na samostojno nalogo, temveč kot na skladno dejavnost, vgrajeno v SDLC.



Opredelitev regresijskih paketov

Avtomatizirani regresijski testi so jedro strategije avtomatizacije testov.

Komplet za regresijo dima

Regresijski paketi služijo kot preverjanje razumnosti, da je aplikacijo mogoče naložiti in dostopati do nje. Prav tako je treba zagnati le nekaj ključnih scenarijev, da zagotovite, da aplikacija še vedno deluje.

Cilj paketa za preizkušanje dima je ujeti najbolj očitne težave, na primer nenalaganje programov ali skupnega uporabniškega toka ni mogoče izvesti; zato preskusi dima ne smejo trajati dlje kot 5 minut za hiter odziv, če kaj večjega ne deluje.


Paket preizkusov dima se izvaja ob vsakem uvajanju in je lahko mešanica testov API in / ali GUI.

Funkcionalni regresijski paketi , Ki naj bi podrobneje preverjal funkcionalnost aplikacije kot test dima.

Obstaja več regresijskih paketov za različne namene. Če na različnih odsekih aplikacije deluje več skupin, bi bilo idealno, da obstajajo različni regresijski paketi, ki se lahko osredotočijo na področje, na katerem ekipa dela.

Ti paketi naj bi se lahko izvajali v katerem koli okolju, kadar koli je to potrebno, pod pogojem, da vedenje funkcij ostaja skladno v vseh okoljih. Izvajajo se večkrat na dan in naj trajajo največ 15 do 30 minut.


Ker so ti funkcionalni testi bolj podrobni, bodo trajali dlje časa, zato je pomembno, da je večina funkcionalnih testov na ravni API, kjer se lahko testi izvajajo hitreje, da smo lahko znotraj 15 do 30 minut rok.

Regresijski paket od konca do konca, ki preizkuša celotno aplikacijo kot celoto. Cilj teh testov je zagotoviti pravilno delovanje različnih delov aplikacije, ki se povezujejo z različnimi bazami podatkov in aplikacijami drugih proizvajalcev.

Preskusi od konca do konca niso namenjeni preizkusu vseh funkcionalnosti, saj so te že preizkušene v funkcionalnih regresijskih paketih, vendar so ti preskusi 'lahki', ki samo preverjajo prehode iz enega stanja v drugega in peščica najpomembnejših scenarijev ali uporabniških potovanj.

Ti testi se v glavnem izvajajo prek GUI-ja, saj preverjajo, kako bi uporabniki uporabili sistem. Čas, potreben za njihovo izvedbo, se lahko razlikuje od ene do druge aplikacije, vendar se običajno izvaja enkrat na dan ali ponoči.



Preizkusite strategijo avtomatizacije za več agilnih ekip

test_automation_strategy_agile

Avtomatizirani preskusi enot

Test Automation se začne na ravni enote. Enotne teste morajo razviti razvijalci za vsako novo funkcijo, ki je razvita. Ti enotni testi tvorijo temelj večje avtomatizacijske prakse, ki se razteza vse do preskusov sistemskega uporabniškega vmesnika.

Odgovornost razvijalcev je zagotoviti, da se za vsako novo funkcijo, ki se razvije, napiše sklop skladnih in trdnih preskusov enot, ki dokazujejo, da koda deluje, kot je predvideno, in izpolnjuje zahteve.

Preizkusi enot zagotavljajo največ donosnosti naložbe v ekipo, saj jih je zelo hitro zagnati, jih je enostavno vzdrževati in spreminjati (saj ni odvisnosti), in ko pride do napak v kodi, se hitro vrne razvijalcu.

Preizkusi enot se izvajajo na stroju razvijalca in okolju CI.

Avtomatizirana integracija / API ali preskusi storitev

Medtem ko enotni preskusi temeljijo na preizkušanju funkcij v razredu, integracijski preskusi tvorijo naslednjo stopnjo od preskusov enot, da preizkusijo razrede, ki skupaj sestavljajo komponento, in tako zagotovijo del funkcionalnosti. Ti preskusi se izvedejo šele, ko se preskusi enote zaženejo in opravijo.

Preizkusi storitev se običajno izvajajo na ravni API brez posredovanja spletnega vmesnika GUI; s tem bi lahko testi preizkusili funkcionalnost v čisti obliki in ker se testi neposredno pogovorijo s komponentami, jih je mogoče hitro izvesti in bodo del gradnje.

Po potrebi se posmehujejo, kot so žična mocka se bo uporabil za odštevanje odvisnosti drugih 3rdstranka sistemov in kadar nadaljnji sistemi niso na voljo za zagotavljanje podatkov, potrebnih za testiranje.

Integracijski testi in / ali servisni testi se lahko izvajajo tudi na stroju razvijalca in so del gradnje, če pa začnejo dolgo časa, je najbolje, da se izvajajo v okolju CI.

Orodja, kot je SoapUI, lahko uporabimo za servisne teste.

Preizkušanje aplikacij

Tipično aplikacijo za e-poslovanje lahko razdelimo na različne aplikacije ali 'aplikacije', ki ponujajo različne funkcionalnosti. Koncept »testiranja aplikacij« je mesto, kjer je skupina testov, ki preizkušajo funkcionalnost aplikacije, organizirana skupaj in deluje proti želeni aplikaciji. Ta paket bo uporaben v primerih, ko želi ekipa izdati posamezno aplikacijo in želi vedeti, ali deluje pravilno.

Preizkusi aplikacij običajno zahtevajo vmesnik za interakcijo z različnimi komponentami, zato se predvideva, da se ti preskusi izvajajo prek brskalnika na GUI.

Namen testiranja aplikacij je zagotoviti, da so funkcije aplikacije funkcionalno pravilne. Ker so testi organizirani tako, da zagotavljajo zaupanje v zdravje določene aplikacije, se ti testi običajno imenujejo vertikalni testi, saj izvajajo določeno aplikacijo 'navzdol'. Preizkusi so zelo temeljiti in obseg je velik.

Selen WebDriver se lahko uporablja za izvajanje teh samodejnih testov proti brskalniku. To orodje je najbolj priljubljeno za teste avtomatizacije brskalnikov in ponuja bogat API, ki omogoča kompleksna preverjanja.

Preskusi scenarijev od konca do konca

Avtomatizirani testi GUI, ki se izvajajo proti sistemu, služijo kot tipični tokovi uporabnikov, potovanja ali scenariji od konca do konca. Zaradi težav s tovrstnimi testi (o katerih bomo razpravljali spodaj) jih bo čim manj. Scenariji od konca do konca so vključeni v nočni regresijski paket.



Pretvorba preizkusne piramide za avtomatizacijo

Kot del strategije za avtomatizacijo preskusov moramo zagotoviti čim večje število samodejnih testov, ki se izvajajo na ravni GUI.

Medtem ko izvajanje avtomatiziranih testov prek grafičnega uporabniškega vmesnika zagotavlja dobre in smiselne teste v smislu simulacije uporabnikove interakcije z aplikacijo, je nagnjeno k številnim težavam, navedenim spodaj:

Krhka

Ker se testi zanašajo na lokatorje HTML, da identificirajo spletne elemente za interakcijo, takoj ko se ID spremeni, testi ne uspejo, zato nosijo veliko stroškov vzdrževanja.

Omejeno testiranje

GUI bi lahko omejil preizkuševalčevo zmožnost, da v celoti preveri funkcijo, saj GUI morda ne vsebuje vseh podrobnosti spletnega odziva, da bi omogočil preverjanje.

Počasi

Ker se testi izvajajo prek grafičnega uporabniškega vmesnika, lahko čas nalaganja strani bistveno podaljša celoten čas testiranja, zato so povratne informacije razvijalcem razmeroma počasne.

Najmanjša donosnost naložbe

Zaradi zgoraj omenjenih težav samodejni testi GUI zagotavljajo najmanj ROI.

Preizkusi avtomatizacije brskalnika bodo čim manjši in bodo uporabljeni za simulacijo vedenja uporabnika, ki vključuje skupne uporabniške tokove in scenarije od konca do konca, kjer se izvaja sistem kot celota.