Testiranje Windows aplikacij: praktičen načrt

Windows aplikacija je lahko videti urejeno v demo načinu, pa vseeno v ponedeljek zjutraj upočasni poslovanje. Neshranjen dobavnica, uporabnik, blokiran po treh neuspešnih poskusih, ali dialog za tiskanje, ki se po posodobitvi obnaša drugače, niso kozmetične napake. Kdor želi vedeti, kako testirati Windows aplikacije, zato ne bi smel začeti pri posameznih gumbih, temveč pri procesih, ki stanejo dela, denarja, ali sledljivosti.

Prav v skladišču, delavnici, dispoziciji, in administraciji poteka veliko kritičnih procesov prek namizne programske opreme, ki je rasla skozi leta. Tam ni pomembno, ali je testni primer vtisljivo formuliran. Odločilno je, ali lahko zaposleni zanesljivo opravljajo svoje naloge v realističnih pogojih - tudi ob nepopolnih podatkih, spreminjajočih se dovoljenjih, počasnih omrežjih, in nenačrtovanih prekinitvah.

Testiranje Windows aplikacij se začne s kritičnimi procesi

Ne zasluži vsaka funkcija enakega testnega napora. Redko uporabljen izvoz z ročnim naknadnim delom je treba oceniti drugače kot knjiženje prejema blaga, izdelavo nalepke, ali dnevno usklajevanje naročil. Začnite zato z enostavnim vprašanjem: kaj se konkretno zgodi, če ta proces spodleti?

Visoko prioriteto imajo procesi z neposrednim vplivom na zaloge, dostavo, fakturiranje, varnost, ali komunikacijo s stranko. Sem sodijo na primer prijava in preverjanje pravic, ustvarjanje in spreminjanje matičnih podatkov, knjiženja transakcij, tiskanje dokumentov, vmesniki do ERP ali dostavnih storitev, ter ponovni zagon po napaki. Tudi funkcije, ki jih uporablja le majhna skupina ljudi, so lahko kritične, če blokirajo mesečno zaključevanje ali sprostitev blaga.

Iz teh procesov ne nastanejo abstraktni seznami testov, temveč sledljivi delovni koraki. Test prejema blaga bi se lahko na primer začel z obstoječim naročilom, evidentiral delno dobavo, prijavil odstopajočo količino, dodelil skladiščno lokacijo, in nato preveril, ali se zaloga, dnevnik knjiženj, in natisnjen dokument ujemajo. Tako testirate dejanski učinek programske opreme, ne le posameznih vnosnih polj.

Ustvariti testno osnovo, ki odraža poslovanje

Mnoge napake postanejo vidne šele, ko se testno okolje približa resničnosti. Aplikacija se s praznim testnim najemnikom pogosto obnaša drugače kot z več leti gibalnih podatkov, blokiranimi artikli, manjkajočimi obveznimi informacijami, ali že odprtimi transakcijami.

Zato zavestno pripravite testne podatke. Ne potrebujete nujno popolne kopije produkcije. Smiselnejši je nadzorovan nabor podatkov s tipičnimi, mejnimi, in namerno napačnimi primeri: artikli z različnimi merskimi enotami, stranke s posebnimi pogoji, naročila z delnimi dobavami, uporabniki z različnimi vlogami, in transakcije, ki so že v obdelavi. Osebne podatke bi bilo treba pri tem anonimizirati ali nadomestiti z realističnimi vzorčnimi podatki.

K testni osnovi sodi tudi tehnično okolje. Dokumentirajte različico Windows, ločljivost, prilagajanje merila, nameščene tiskalnike, omrežne diske, različico baze podatkov, povezane storitve, in dovoljenja. To se sliši suhoparno, a kasneje prihrani čas. Če se napaka pojavlja le na delovnih mestih s 125-odstotnim merilom ali z določenim gonilnikom tiskalnika, mora biti to ponovljivo.

Ne preverjati le idealnega primera

Idealni primer predvsem dokazuje, da je bila aplikacija zgrajena za pričakovano pot. V poslovanju ob njem nastajajo težke situacije. Kaj se zgodi, če uporabnik pusti obvezno polje prazno, sproži isto knjiženje dvakrat, ali izgubi povezavo med shranjevanjem? Ali transakcija ostane dosledna? Ali oseba prejme razumljivo sporočilo? Ali lahko varno nadaljuje z delom?

Pri Windows aplikacijah sta poleg tega še posebej pomembna upravljanje in stanje. Pogovorna okna se lahko pojavijo v ozadju, bližnjice na tipkovnici se lahko prekrivajo, pogovorna okna za izbiro datotek lahko blokirajo potek. Preverite, ali so fokus, sporočila o napakah, in zaklepanja nedvoumni. Tehnična izjema brez navodila za ukrepanje vodji izmene ne pomaga.

Ročne teste uporabiti tam, kjer je potrebna presoja

Ročni testi niso znak nezadostne zrelosti. Nepogrešljivi so, kadar nastaja nov proces, se vmesnik prenavlja, ali strokovno znanje odloča o kakovosti. Izkušen vodja skladišča hitreje kot skripta prepozna, ali je maska razumljiva pod velikim časovnim pritiskom, ali se opozorilo pojavi prepozno.

Ročno testiranje pa postane drago in nezanesljivo, ko se isti stabilni procesi ponavljajo pred vsako različico. Tedaj izdaja je odvisna od razpoložljivih oseb, spomina, in razpršenih zapiskov. Pravi trenutek za prehod na avtomatizacijo je običajno tam, kjer se proces pogosto izvaja, lahko povzroči veliko škodo, in ima jasne pričakovane rezultate.

Dober ročni testni primer opisuje izhodiščno situacijo, korake, pričakovani rezultat, in potrebne podatke. Pri napaki dodajte posnetek zaslona, časovni žig, različico aplikacije in izgradnje, ter natančno dejanje. "Tiskanje ne deluje" ni uporaben opis napake. "Po spremembi dostavnega naslova ostane dialog tiskanja odprt, naročilo 4711 ne prejme PDF-ja, in ne prikaže se nobeno sporočilo" pa je.

Avtomatizirani regresijski testi za ponavljajoča se tveganja

Avtomatizacija ne preverja, ali je programska oprema temeljno dobra. Preverja, ali prej delujoči, opredeljeni procesi po spremembi še delujejo. To je še posebej dragoceno pri Windows programski opremi, katere vmesniki, logika baze podatkov, in zunanji vmesniki se razvijajo skozi leta.

Začnite majhno. Najprej izberite pet do deset poslovno kritičnih procesov, ki bi jih bilo treba preveriti pred vsako izdajo. Sem lahko sodijo prijava s postopkom zaklepanja računa, vnos naročil, skladiščno knjiženje, tiskanje PDF ali nalepk, menjava vloge, in centralni uvoz. Šele ko ti testi zanesljivo delujejo, se izplača razširitev na posebne primere.

Pri namiznih aplikacijah avtomatizirani testi pogosto upravljajo vidne elemente vmesnika: okna, vnosna polja, tabele, gumbe, in pogovorna okna. To deluje, a je občutljivejše od čistega testa vmesnika. Majhne spremembe postavitve, počasnejši računalniki, ali nejasno poimenovani elementi lahko pokvarijo teste. Zato bi morali razvijalci, strokovni oddelek, in odgovorni za testiranje skupaj določiti, kateri elementi so stabilno naslovljivi in katere korake preverjanja je bolje zavarovati prek baze podatkov, dnevnika, ali vmesnika.

Smiseln test poleg tega ne preverja le, ali je bilo mogoče klikniti gumb. Nadzoruje strokovno posledico: ali je bilo knjiženje shranjeno? Ali je zaloga pravilna? Ali je bil ustvarjen dokument? Ali ni bil ustvarjen podvojen zapis? Vidna interakcija in preverljiv rezultat spadata skupaj.

Dokazi so del rezultata testa

Zelen status sam po sebi pri kritičnih aplikacijah redko zadostuje. Ko test spodleti, ekipe hitro potrebujejo odgovor na tri vprašanja: kakšna je bila izhodiščna situacija? Pri katerem koraku je proces spodletel? Kaj je aplikacija v tistem trenutku prikazovala?

Posnetki zaslona, dnevniki izvajanja, in po potrebi snemanja zaslona naredijo napake pogovorljive. Znatno skrajšajo predajo med poslovanjem, QA, in razvojem. Za regulirana ali varnostno ozaveščena podjetja so poleg tega trdna podlaga za sledenje odobritvam in odstopanjem.

Pri tem lokacija shranjevanja ni stranska zadeva. Testni zagoni lahko vsebujejo interne podatke strank, cenike, informacije o naročilih, ali prikaze zaslona. Kdor avtomatizirano testira občutljive Windows aplikacije, bi moral razjasniti, ali smejo ti podatki zapustiti lastno infrastrukturo. Samostojno gostovano okolje, kot je COCO, je lahko tu smiselno, ker izvajanje testov, dokazi, in ocenjevanje ostanejo pod lastnim nadzorom. Ali je to potrebno, je odvisno od zahtev varstva podatkov, pogodbene situacije, in potrebe po zaščiti - vsaka ekipa ne potrebuje enake arhitekture za to.

Vgraditi testiranje v proces izdaje

Najboljši katalog testov izgubi vrednost, če se uporabi šele po kaotičnem uvajanju v produkcijo. Določite fiksen trenutek: avtomatizirane osnovne regresije se izvajajo pred vsako izdajo, ročno prevzemanje preverja nove ali spremenjene procese, znane omejitve pa se odkrito dokumentirajo.

Ni treba, da vsak neuspešen test ustavi izdajo. Napaka v redko uporabljenem administrativnem pogledu je lahko sprejemljiva, če obstaja varna obhodna rešitev in je prizadeto področje jasno obveščeno. Napako, ki napačno knjiži zaloge ali neopazno blokira uporabnike, je treba obravnavati drugače. To odločitev bi bilo treba sprejeti glede na poslovni vpliv, ne glede na golo število rdečih testov.

Vzdržujte teste skupaj z aplikacijo. Ko se proces namerno spremeni, posodobite testni primer, testne podatke, in pričakovani rezultat skupaj z zahtevo. Zastareli testi ustvarjajo hrup in se sčasoma prezrejo. Nekaj zaupanja vrednih preverjanj je vrednejših kot stotine avtomatiziranih procesov, katerih rezultatov nihče več ne jemlje resno.

Na koncu ne gre za simulacijo vsakega mogočega vnosa. Gre za zaščito dela, ki mora naslednje jutro spet delovati. Začnite z enim samim kritičnim procesom, naredite njegov rezultat dokazljiv, in gradite naprej od tam.