Įprastoje įmonės programoje reikia išbandyti daugelį sričių. Pradedant nuo paprasčiausių komponentų, klasių, kūrėjai ar specializuoti testų kūrėjai turi užprogramuoti vieneto testus, kad įsitikintų, jog mažiausi programos vienetai elgiasi teisingai. Kiekvienas komponentas gali sėkmingai išlaikyti vieneto testus; tačiau kūrėjai turi užtikrinti, kad jie, kaip tikimasi, dirbtų kartu - kaip posistemio ir visos programos dalis - taigi, integracijos testai turi būti atlikta. Kai kuriuose projektuose turi būti įvykdyti našumo reikalavimai, todėl kokybės užtikrinimo inžinieriai dirba apkrovos bandymai patikrinti ir dokumentuoti, kaip programa veikia įvairiomis sąlygomis. Kuriant programą, kokybės užtikrinimo inžinieriai atlieka automatizuotą ir rankinį darbą funkciniai testai išbandyti programos elgseną vartotojo požiūriu. Kai plėtros projektas beveik užbaigia konkretų etapą, priėmimo testai galima patikrinti, ar paraiška atitinka reikalavimus.
„HttpUnit“ yra „JUnit“ pagrindu sukurta sistema, leidžianti įdiegti automatizuotus žiniatinklio programų testavimo scenarijus. Tai geriausiai tinka automatiniams funkciniams arba priėmimo testams įgyvendinti. Kaip rodo pavadinimas, jį galima naudoti bandant vienetą; tačiau tipiniai žiniatinklio sluoksnio komponentai, tokie kaip JSP (JavaServer Pages) puslapiai, servletai ir kiti šablonų komponentai, nėra tinkami bandyti vienetus. Kalbant apie įvairius MVC („Model-View Controller“) pagrindų komponentus, jie geriau tinka bandymams su kitomis testavimo sistemomis. Struts veiksmus galima patikrinti vienetu naudojant „StrutsUnit“, o „WebWork 2“ veiksmus galima išbandyti, pavyzdžiui, be žiniatinklio sudėtinio rodinio.
Testo taikiniai
Prieš pereinant prie architektūros ir diegimo detalių, svarbu tiksliai išsiaiškinti, kokius bandomuosius scenarijus reikės įrodyti apie žiniatinklio programą. Galima tiesiog imituoti atsitiktinio Svetainės lankytojo elgesį tiesiog spustelėjus įdomias nuorodas ir atsitiktine tvarka skaitant puslapius, tačiau šių atsitiktinių scenarijų rezultatas neapibūdintų programos išsamumo ir kokybės.
Įprastoje įmonės žiniatinklio programoje (arba sudėtingoje svetainėje) yra keli dokumentai, apibūdinantys įvairių vartotojų ar programų prižiūrėtojų reikalavimus. Tai gali būti naudojimo atvejo specifikacijos, neveikiančių reikalavimų specifikacijos, bandomųjų atvejų specifikacijos, gautos iš kitų artefaktų, vartotojo sąsajos projektavimo dokumentai, maketai, veikėjų profiliai ir įvairūs papildomi artefaktai. Paprastos programos atveju visa specifikacija gali susidaryti iš paprasto teksto failo su reikalavimų sąrašu.
Iš šių dokumentų turime sukurti organizuotą bandomųjų atvejų sąrašą. Kiekvienas bandymo atvejis apibūdina scenarijų, kurį interneto lankytojas gali įvykdyti per interneto naršyklę. Gera praktika yra siekti panašaus dydžio scenarijų - didesnius scenarijus galima suskirstyti į mažesnius gabalus. Daugelyje puikių knygų ir straipsnių diskutuojama apie bandomųjų atvejų specifikacijų kūrimą. Tarkime, kad šiame straipsnyje turite elementų rinkinį, kurį norite išbandyti savo žiniatinklio programai, suskirstytą į bandomųjų atvejų rinkinius.
Laikas atsisiųsti medžiagą!
Gerai, dabar mes žinome nuobodų dalyką, atsisiųskime keletą puikių žaislų! Visų pirma mums reikia įdiegto „Java 2 SDK“, kad galėtume surinkti ir atlikti bandymus. Tada turime atsisiųsti „HttpUnit“ sistemą - šiuo metu 1.5.5 versijoje. Dvejetainiame pakete yra visos reikalingos trečiųjų šalių bibliotekos. Mums taip pat reikės skruzdėlių kūrimo įrankio, kad testai būtų vykdomi ir ataskaitos būtų generuojamos automatiškai. Bet kuri gana nauja šių įrankių versija tikriausiai veiktų; Aš tiesiog norėčiau naudoti naujausią ir geriausią visko variantą.
Norint rašyti ir vykdyti testus, rekomenduoju naudoti IDE, kuriame yra įdėtas „JUnit“ testų bėgikas. Kuriu bandomuosius scenarijus, naudoju „Eclipse 3.0M7“, tačiau „IntelliJ“ taip pat turi „JUnit“ palaikymą, kaip ir neseniai išleisti IDE.
HttpUnit: HTTP kliento treniruoklis
Norint išbandyti žiniatinklio programas, idealiu atveju bandymo įrankis turėtų elgtis tiksliai taip, kaip naudotojų žiniatinklio naršyklės. Mūsų programa (bandomasis tikslas) neturėtų žinoti apie skirtumus teikiant puslapius žiniatinklio naršyklėje ar bandymo įrankyje. Tai yra būtent tai, ką teikia „HttpUnit“: jis imituoja įprastas naršyklės GET ir POST užklausas ir pateikia gražų objekto modelį, pagal kurį galima užkoduoti mūsų testus.
Peržiūrėkite išsamų likusių klasių ir metodų API vadovą; 1 paveiksle pateikiama trumpa klasių, kurias dažniausiai naudoju, apžvalga. Vartotojo sesija (sąveikos su žiniatinklio programa seka) yra susieta su a Interneto pokalbis. Mes konstruojame „WebRequest“s, paprastai sukonfigūruoja URL ir parametrus, tada mes jį siunčiame per Interneto pokalbis. Tada sistema grąžina a „WebResponse“, kuriame yra grąžintas puslapis ir atributai iš serverio.
Štai pavyzdys „HttpUnit“ bandymo atvejis iš „HttpUnit“ dokumentų:
/ ** * Patvirtina, kad pateikus prisijungimo formą pavadinimu „pagrindinis“, rezultatas * puslapyje, kuriame yra tekstas „Visiškai slapti“ ** / public void testGoodLogin () išmeta išimtį {WebConversation conversation = new WebConversation (); „WebRequest“ užklausa = nauja „GetMethodWebRequest“ ("//www.meterware.com/servlet/TopSecret"); „WebResponse response“ = pokalbis.getResponse (užklausa); WebForm loginForm = response.getForms () [0]; užklausa = loginForm.getRequest (); request.setParameter („vardas“, „meistras“); atsakymas = pokalbis.getResponse (užklausa); assertTrue ("Prisijungimas nepriimtas", response.getText (). indexOf ("Jūs tai padarėte!")! = -1); „assertEquals“ („Puslapio pavadinimas“, „Visiškai slapta“, response.getTitle ()); } Architektūriniai sumetimai
Atkreipkite dėmesį, kaip aukščiau pateiktame „Java“ pavyzdyje yra serverio, kuriame veikia programa, domeno vardas. Kuriant naują sistemą, programa veikia keliuose serveriuose, o serveriuose gali būti kelios versijos. Akivaizdu, kad bloga idėja išsaugoti serverio pavadinimą įgyvendinant „Java“ - kiekvienam naujam serveriui turime iš naujo sukompiliuoti savo šaltinius. Kiti elementai neturėtų būti šaltinio failuose, pvz., Vartotojo vardai ir slaptažodžiai, kurie turėtų būti konfigūruojamas konkrečiam dislokavimui. Kita vertus, neturėtume per daug suprojektuoti paprasto bandomojo atvejo. Paprastai bandomojo atvejo specifikacijoje jau yra didžioji dalis sistemos būsenos ir konkrečių parametrų aprašų, susijusių su mūsų scenarijumi, taigi yra nėra tikslo padaryti viską parametruojamą įgyvendinant.
Koduodami suprasite, kad daugybė kodo sekcijų atsiranda įgyvendinant daugiau nei vieną bandomąjį atvejį (galbūt visais bandomaisiais atvejais). Jei esate patyręs į objektą orientuotas kūrėjas, susigundysite kurti klasių hierarchijas ir bendras klases. Kai kuriais atvejais tai turi daug prasmės - pavyzdžiui, prisijungimo procedūra turėtų būti įprastas metodas, galimas visais bandymo atvejais. Tačiau jūs turite šiek tiek atsitraukti ir suvokti, kad nestatote naujos gamybos sistemos virš bandomosios programos - šios „Java“ klasės yra ne tik bandomieji scenarijai, skirti patvirtinti svetainės išvestį. Pasinaudokite sveiku protu ir siekite paprastų, nuoseklių ir savarankiškų bandomųjų scenarijų.
Bandomieji atvejai paprastai yra trapūs. Jei kūrėjas pakeičia URL, pertvarkykite išdėstymą
Mūsų bandymų atvejais atsekamumas yra labai svarbus. Jei kažkas vyksta KA-BOOM, arba, pavyzdžiui, skaičiavimo rezultatas yra neteisingas, svarbu nurodyti kūrėjui atitinkamą bandomojo atvejo specifikaciją ir naudojimo atvejo specifikaciją, kad būtų galima greitai išspręsti klaidas. Todėl pažymėkite savo įgyvendinimą nuorodomis į originalius specifikacijos dokumentus. Taip pat naudinga įtraukti tų dokumentų versijos numerį. Tai gali būti tik paprastas kodo komentaras arba sudėtingas mechanizmas, kai bandymo ataskaitos pačios susiejamos su dokumentais; svarbu, kad kode būtų nuoroda ir išlaikyti atsekamumą.
Kada turiu parašyti kodą?
Dabar, kai jau žinote reikalavimus (naudojimo atvejų dokumentus ir atitinkamas bandymo atvejų specifikacijas), suprantate sistemos pagrindus ir turite architektūros gairių rinkinį, pradėkime dirbti.
Kuriant bandomojo atvejo įgyvendinimą, aš norėčiau dirbti „Eclipse“. Visų pirma, jis turi gražų „JUnit“ bandymo bėgiką. Galite pasirinkti „Java“ klasę ir meniu Vykdyti galite ją paleisti kaip „JUnit“ vieneto testą. Bėgikas pateikia pripažintų bandymo metodų sąrašą ir vykdymo rezultatą. Kai bandymo metu viskas gerai, tai suteikia gražią žalią liniją. Jei įvyko išimtis arba tvirtinimo klaida, ji rodo kankinančią raudoną liniją. Manau, kad vizualinis grįžtamasis ryšys yra tikrai svarbus - jis suteikia jausmą, kad pasiekta, ypač kai rašote savo kodo testus. Aš taip pat norėčiau naudoti „Eclipse“ savo atnaujinimo galimybėms. Jei suprantu, kad bandomųjų atvejų klasėje turiu nukopijuoti ir įklijuoti kodo skiltis, galiu naudoti meniu Refactoring, kad vietoje kodo sukurtumėte metodą. Jei suprantu, kad daugelyje bandymų atvejų bus naudojamas tas pats metodas, naudodamas meniu galiu patekti į savo pagrindinę klasę.
Remdamasis aukščiau pateiktais architektūros reikalavimais, kiekvienam projektui paprastai sukuriu pagrindinę bandomųjų atvejų klasę, kuri pratęsia JUnit „TestCase“ klasė. Aš tai vadinu „ConfigurableTestCase“. Kiekvienas bandymo atvejis pratęsia šią klasę, žr. 2 paveikslą.
„ConfigurableTestCase“ paprastai yra įprasti bandymo atvejo metodai ir inicializavimo kodas. Aš naudoju nuosavybės failą serverio pavadinimui, programos kontekstui, įvairiems kiekvieno vaidmens prisijungimo vardams ir keliems papildomiems nustatymams išsaugoti.
Konkrečiuose bandymo atvejų įgyvendinimuose yra vienas bandymo metodas kiekvienam bandymo atvejo scenarijui (iš bandymo atvejo specifikacijos dokumento). Kiekvienas metodas paprastai prisijungia naudodamas konkretų vaidmenį ir tada atlieka sąveiką su žiniatinklio programa. Daugumai bandomųjų atvejų veiklai atlikti nereikia konkretaus vartotojo; jiems paprastai reikalingas konkretaus vaidmens vartotojas, pvz., administratorius, lankytojas arba registruotas vartotojas. Aš visada kuriu „LoginMode“ enum, kuriame yra galimi vaidmenys. Aš naudoju „Jakarta Commons ValuedEnum“ paketą, kad sukurtumėte vaidmenų sąskaitas. Kai prisijungia prie konkretaus bandymo metodo bandymo byloje, jis turi nurodyti, kuris prisijungimo vaidmuo reikalingas tam tikram bandymo scenarijui. Be abejo, galimybė prisijungti prie konkretaus vartotojo taip pat turėtų būti įmanoma, pavyzdžiui, patikrinti registruoto vartotojo naudojimo atvejį.
Po kiekvieno užklausos ir atsakymo ciklo paprastai turime patikrinti, ar grąžintame puslapyje yra klaida, ir mes turime patvirtinti savo teiginius apie tai, kokio turinio turėtų būti atsakymas. Čia taip pat turime būti atsargūs; turėtume patikrinti tik tuos dalykus, kurie nėra kintami ir nėra per trapi programoje. Pvz., Jei mes tvirtiname konkrečius puslapių pavadinimus, bandymai greičiausiai nebus vykdomi, jei kalbą galima pasirinkti programoje ir mes norime patikrinti kitos kalbos diegimą. Panašiai nėra prasmės tikrinti elementą puslapyje, atsižvelgiant į jo padėtį lentelės makete; lentelių dizainas dažnai keičiasi, todėl turėtume stengtis identifikuoti elementus pagal jų ID. Jei kai kurie svarbūs puslapio elementai neturi ID ar pavadinimų, turėtume tiesiog paprašyti kūrėjų juos pridėti, o ne bandyti juos apeiti.
„JUnit“ teiginiai siūlo netinkamą požiūrį tikrinant, ar išvaizda, išdėstymas ir puslapio dizainas atitinka reikalavimus. Tai įmanoma, turint begalę laiko testo kūrimui, tačiau geras žmogaus testuotojas gali šiuos dalykus įvertinti efektyviau. Taigi daugiau dėmesio skirkite žiniatinklio programos funkcionalumui, o ne tikrinkite viską, kas įmanoma puslapyje.
Štai atnaujintas bandymo scenarijus, pagrįstas mūsų bandymo atvejo architektūra. Klasė tęsiasi „ConfigurableTestCase“, o prisijungimo duomenys tvarkomi pagrindinėje klasėje:
/ ** * Patvirtina, kad pateikus prisijungimo formą pavadinimu „pagrindinis“, rezultatas * puslapyje, kuriame yra tekstas „Visiškai slapti“ ** / public void testGoodLogin () išmeta išimtį {WebConversation conversation = new WebConversation (); „WebResponse“ atsakymas = prisijungimas (pokalbis, „LoginMode.ADMIN_MODE“); assertTrue ("Prisijungimas nepriimtas", response.getText (). indexOf ("Jūs tai padarėte!")! = -1); „assertEquals“ („Puslapio pavadinimas“, „Visiškai slaptas“, response.getTitle ()); } Patarimai ir gudrybės
Daugumą scenarijų galima gana lengvai įgyvendinti nustatant „WebForm“ parametrus ir tada ieškote konkrečių elementų su rezultatais „WebResponse“ puslapių, tačiau visada yra keletas iššūkių keliančių bandomųjų atvejų.
