Avtomatizirano testiranje aplikacije Windows

Izdaja je pripravljena, vendar nihče ne more z gotovostjo trditi, ali novo uvozno pogovorno okno, preverjanje pravic in tiskanje računov še vedno delujejo. Prav na tej točki postane zmožnost avtomatiziranega testiranja aplikacije Windows dragocena — ne kot predstavitev s tremi kliki, temveč kot ponovljiv del izdajnega procesa.

Namizna programska oprema je v mnogih podjetjih poslovno kritična. Upravlja premike zalog, proizvodne naloge, matične podatke strank ali odpremne dokumente. Napaka vpliva na več kot le zaslon: lahko blokira naročila, ustvari napačne nalepke ali prisili zaposlene v pozni izmeni v ročne obhode. Avtomatizirani testi zmanjšajo to tveganje, ko so usmerjeni na resnične delovne procese in tehnično nadzorovano testno okolje.

Zakaj se Windows testi razlikujejo od spletnih testov

Spletna aplikacija se običajno testira prek jasno naslovljivih elementov v brskalniku. Pri namiznih aplikacijah Windows je upravljanje bolj odvisno od oken, pogovornih oken, nativnih kontrolnikov, ločljivosti, pravic in nameščenih komponent. Test mora na primer ugotoviti, ali se je pogovorno okno dejansko odprlo, ali je polje mogoče urejati ali ali je bilo tiskalno opravilo pravilno preneseno.

Temu se pridružuje izrasla resničnost mnogih aplikacij. Nekateri vmesniki so sestavljeni iz klasičnih komponent WinForms ali WPF, drugi pa vežejo starejše module, pregledovalnike PDF ali vmesnike do tiskalnikov in strojne opreme skenerjev. Ne obstaja enoten postopek avtomatizacije, ki bi enako dobro deloval za vsako aplikacijo. Kdor to prikriva, ustvarja teste, ki dobro delujejo v laboratoriju in odpovedo pri naslednji posodobitvi.

Smiselno izhodišče torej ni orodje, temveč vprašanje: kateri procesi morajo dokazljivo delovati pri vsaki izdaji? Pri programski opremi za zaloge ali naročila bi to bili prijava, preverjanje pravic, vnos naročila, knjiženje zaloge, ustvarjanje dokumenta in prenos v vmesnik. Ti procesi prinašajo poslovno vrednost. Test, ki preverja le, ali je meni viden, to redko počne.

Avtomatizirano testiranje aplikacije Windows: izbira prave plasti

Za avtomatizacijo so na voljo v osnovi tri plasti. V idealnem primeru se kombinirajo, namesto da bi se izključno zanašali na vidni uporabniški vmesnik.

Na tehnični ravni enotni in integracijski testi preverjajo poslovno logiko, dostop do podatkov in vmesnike. Tečejo hitro in zgodaj pokažejo, ali je bil izračun cene, uvozna oblika ali pravilo pravic kršeno. Vendar ne nadomestijo operativnega testa: ali lahko dispečer dejansko doseže funkcijo in jo pravilno izvede, ostane odprto.
Drugo plast sestavljajo testi UI prek Windows Automation API. Testna orodja tu naslavljajo kontrolne elemente s pomočjo lastnosti, kot so ID avtomatizacije, ime ali vrsta kontrolnika. To je običajno bolj stabilno kot testi, ki zgolj klikajo na fiksne koordinate zaslona. Razvojne ekipe lahko aktivno spodbujajo to stabilnost z dodeljevanjem edinstvenih ID-jev in s tem, da relevantnih kontrolnikov ne preimenujejo ob vsaki spremembi vmesnika.

Tretja plast deluje vizualno. Tu sistem prepozna gumbe, vsebino tabel, pogovorna okna ali stanja na podlagi vsebine zaslona. To pomaga zlasti pri starejših aplikacijah, lastniških komponentah ali vmesnikih, ki ne zagotavljajo uporabnih informacij za avtomatizacijo. Vizualno prepoznavanje pa je bolj občutljivo na skaliranje, teme, nepričakovana pojavna okna in nejasna stanja zaslona. Zahteva določena delovna mesta, jasne pogoje čakanja in sledljive dokaze.

Pristop, podprt z UI, lahko bolje razvrsti vizualne signale kot čist klik po koordinatah. Kljub temu ne bi smel postati črna škatla. Pri kritičnih korakih ekipa potrebuje posnetke zaslona, dnevnike, pričakovane rezultate in izjavo, zakaj je bil zagon ocenjen kot neuspešen. Dolgočasna, dokazljiva zanesljivost namesto lovljenja trendov velja še posebej pri testiranju.

Začnite z majhnim, zanesljivim obsegom testiranja

Najpogostejša napaka je poskus takojšnje avtomatizacije vsakega zaslona. To veže proračun in ustvari veliko zbirko krhkih skript, še preden je sploh jasno, ali pristop izboljša vsakdanje izdaje. Boljši je ozek začetek s petimi do desetimi kritičnimi delovnimi procesi, ki se trenutno redno ročno preverjajo.

Dober prvi testni primer ima jasen začetek, realističen vnos in preverljiv rezultat.
Primer: uporabnik z vlogo skladišča se prijavi, ustvari prevzem blaga, knjiži artikel na skladiščno lokacijo in natisne dokument. Test nato preveri ne le sporočilo o uspehu, temveč tudi zalogo, številko dokumenta in zabeleženo tiskalno opravilo. Tako zaporedje klikov postane dokaz poslovnega procesa.

Ni vsak delovni proces takoj primeren. Funkcije z nestabilno strojno opremo, zunanjimi plačilnimi storitvami ali pogosto spreminjajočimi se sistemi tretjih oseb pogosto zahtevajo drugačno nastavitev. Tu lahko testirate lastno aplikacijo do predaje, zunanjo komponento pa preslikate prek nadzorovanega simulatorja. To ni bližnjica, temveč jasna razmejitev odgovornosti.

Testni podatki so del sistema

Avtomatizacija pogosto ne uspe ne zaradi vmesnika, temveč zaradi neuporabnih podatkov. Testni račun je zaklenjen, artikel je bil že uporabljen, ali je prejšnji zagon spremenil pričakovano količino zaloge. Zato testno okolje potrebuje določene začetne podatke in zanesljivo pot nazaj v to stanje.

V praksi to pomeni: ločene testne podatkovne baze, fiksne uporabniške vloge, znane nabore artiklov in strank ter nadzorovano logiko časa in številk. Pri občutljivih podatkih se produkcijskih podatkov ne bi smelo nenadzorovano kopirati. Anonimizirani ali posebej ustvarjeni nabori podatkov so običajno boljša izbira. So predvidljivi in zmanjšujejo tveganja za varstvo podatkov.

Posebno pozornost si zaslužijo tudi procesi zaklepanja računa. Če neuspešni testni zagoni ponavljajoče uporabljajo napačna gesla, lahko zaklenejo lasten dostop. Take scenarije je treba testirati zavestno, vendar ločeno od običajnega regresijskega testa.

Stabilnost izhaja iz delovanja, ne iz enega orodja

Test UI je koristen le, če teče pod ponovljivimi pogoji. Sem sodijo fiksna različica Windows, določena ločljivost in skaliranje zaslona, znane različice aplikacij ter čisto ravnanje s posodobitvami, pogovornimi okni in procesi v ozadju. Če testni strežnik zjutraj uporablja drugačne velikosti pisave kot ponoči, to ni težava testa — to je operativna težava.

Časov čakanja se ne bi smelo slepo vnašati kot fiksnih vrednosti. Trisekundni premor po vsakem kliku naredi test počasnega in ne reši težav s časom. Bolje je konkretno čakati na stanje: okno je vidno, tabela vsebuje pričakovan podatkovni zapis ali je proces shranjevanja zaključen. Resnični asinhroni procesi zahtevajo smiselne časovne omejitve in jasno diagnostiko napak. Neuspešni zagoni sodijo v triažo, ne v prezrto mapo.

Ali je bila aplikacija pokvarjena? Se je vmesnik spremenil na funkcionalno pravilen način? Ali testno okolje ni bilo dosegljivo? Posnetki zaslona, video posnetki zaslona, tehnični dnevniki in časovni žigi bistveno skrajšajo to pojasnjevanje. Poročilo v navadnem besedilu prav tako pomaga oddelkom razumeti, kateri poslovni proces je prizadet, ne da bi morali najprej brati testno skripto.

Načrtovanje varstva podatkov in dokazov od začetka

V namiznih aplikacijah posnetki zaslona pogosto prikazujejo imena strank, cene artiklov, naslove ali interne kazalnike. Če se testi izvajajo prek zunanjih storitev v oblaku, lahko podatki zaslona in promet aplikacije zapustijo lastno nadzorno cono. Za varnostno ozaveščene ekipe to ni majhna podrobnost, temveč arhitekturna odločitev.

Samostojno gostovan testni strežnik lahko izvajanje testov, slike in poročila obdrži v lastnem okolju.
V ta namen softify.pro uporablja COCO, okolje, ki izvaja avtomatizirane teste za spletne in Windows aplikacije ter ustvarja sledljive rezultate. Ali je namenski strežnik smiseln, je odvisno od zahtev po zaščiti, obstoječega IT-ja in števila testnih zagonov. Za majhno, nekritično aplikacijo lahko zadostuje preprost pristop; za notranje specializirane sisteme z občutljivimi podatki je lokalni nadzor pogosto smiselnejša izbira.

Hrambo dokazov je treba prav tako urediti. Ni treba vsakega posnetka zaslona trajno shraniti. Koristni so roki, dostop na podlagi vlog in jasna dodelitev med testnim zagonom, različico aplikacije in rezultatom. To omogoča reprodukcijo napak brez gradnje druge nenadzorovane zbirke podatkov.

Kaj prinaša smiselna uvedba

Po začetnem zagonu ekipa ne bi smela prejeti le števila uspešnih testov. Odločilno je, ali testi najdejo resnične napake, ali tečejo zanesljivo in ali se vzdrževalni napor ujema s koristjo. Test, ki ga je treba prilagajati vsak teden zaradi nepomembne spremembe postavitve, je predrag — tudi če tehnično deluje impresivno.

Naslednji korak je vključitev v izdajni proces. Hitri tehnični testi se lahko sprožijo pri vsaki gradnji; izbrani testi od začetka do konca tečejo pred odobritvijo ali ponoči v stabilnem okolju. Kritična odstopanja blokirajo izdajo, manj kritične opombe se dokumentirajo in prioritizirajo. Te pragove je treba tehnično dogovoriti. Ni vsaka vizualna razlika ovira za dobavo, napačno knjižena količina pa zagotovo je.

Avtomatizirani testi Windows ne nadomestijo strokovnega znanja. Vendar ustvarijo čas za preverjanja, ki zahtevajo presojo: nove procese, nenavadne posebne primere in vprašanje, ali je funkcija resnično razumljiva pri vsakodnevnem delu. Ko so standardni procesi zanesljivo preverljivi, se izdaji ni več treba zanašati na upanje.