V typickej podnikovej aplikácii vyžaduje veľa oblastí testovanie. Počnúc najjednoduchšími komponentmi, triedami musia vývojári alebo špecializovaní vývojári testov naprogramovať jednotkové testy, aby sa zabezpečilo, že najmenšie jednotky aplikácie sa správajú správne. Každý komponent môže potenciálne prejsť jednotkovými testami sám; vývojári však musia zabezpečiť, aby spolupracovali podľa očakávania - ako súčasť subsystému a ako súčasť celej aplikácie - teda integračné testy treba vykonať. V niektorých projektoch musia byť splnené výkonnostné požiadavky, aby mohli pracovať inžinieri zabezpečovania kvality záťažové testy overiť a zdokumentovať výkonnosť aplikácie za rôznych podmienok. Počas vývoja aplikácie vykonávajú inžinieri zabezpečovania kvality automatizáciu a manuálne funkčné skúšky na otestovanie chovania aplikácie z pohľadu používateľa. Keď vývojový projekt takmer dokončí konkrétny míľnik, preberacie skúšky je možné vykonať na overenie, či žiadosť spĺňala požiadavky.
HttpUnit je rámec založený na JUnit, ktorý umožňuje implementáciu automatizovaných testovacích skriptov pre webové aplikácie. Najlepšie sa hodí na implementáciu automatizovaných funkčných testov alebo akceptačných testov. Ako naznačuje názov, dá sa použiť na testovanie jednotiek; typické komponenty webovej vrstvy, ako sú stránky JSP (JavaServer Pages), servlety a ďalšie komponenty šablón, sa však na testovanie jednotiek nehodia. Pokiaľ ide o rôzne komponenty založené na architektúre MVC (Model-View Controller), tieto sú vhodnejšie na testovanie s inými testovacími rámcami. Akcie Struts môžu byť testované na jednotkách pomocou StrutsUnit a akcie WebWork 2 môžu byť testované na jednotkách napríklad bez webového kontajnera.
Testovacie ciele
Predtým, ako sa pustíme do podrobností o architektúre a implementácii, je dôležité si presne ujasniť, čo testovacie skripty budú musieť o webovej aplikácii dokázať. Je možné len simulovať správanie príležitostného návštevníka webových stránok jednoduchým kliknutím na zaujímavé odkazy a čítaním stránok v náhodnom poradí, ale výsledok týchto náhodných skriptov by nepopisoval úplnosť a kvalitu aplikácie.
Typická podniková webová aplikácia (alebo zložitá webová stránka) má niekoľko dokumentov popisujúcich požiadavky rôznych používateľov alebo správcov aplikácií. Môžu to zahŕňať špecifikácie prípadu použitia, špecifikácie nefunkčných požiadaviek, špecifikácie testovacích prípadov odvodené z iných artefaktov, dokumenty o dizajne používateľského rozhrania, makety, profily aktérov a rôzne ďalšie artefakty. Pre jednoduchú aplikáciu by celá špecifikácia mohla pozostávať z jednoduchého textového súboru so zoznamom požiadaviek.
Z týchto dokumentov musíme vytvoriť organizovaný zoznam testovacích prípadov. Každý testovací prípad popisuje scenár, ktorý môže dosiahnuť návštevník webu prostredníctvom webového prehľadávača. Dobrým postupom je zamerať sa na scenáre podobnej veľkosti - väčšie scenáre je možné rozdeliť na menšie časti. Mnoho vynikajúcich kníh a článkov pojednáva o vytvorení špecifikácií testovacích prípadov. V tomto článku predpokladajme, že máte skupinu položiek, ktoré chcete testovať pre svoju webovú aplikáciu, usporiadanú do množín scenárov testovacích prípadov.
Je čas stiahnuť si veci!
Dobre, teraz už poznáme nudné veci, stiahnime si super hračky! Najskôr potrebujeme nainštalovanú sadu Java 2 SDK na zostavenie a vykonanie našich testov. Potom si musíme stiahnuť rámec HttpUnit - momentálne vo verzii 1.5.5. Binárny balík obsahuje všetky požadované knižnice tretích strán. Na automatické spustenie testov a generovanie správ budeme potrebovať aj nástroj na zostavenie Ant. Každá pomerne nedávna verzia týchto nástrojov by pravdepodobne fungovala; Radšej používam najaktuálnejšiu a najlepšiu verziu všetkého.
Na písanie a vykonávanie testov odporúčam použiť IDE, ktoré má vložený testovací bežec JUnit. Na vývoj svojich testovacích skriptov používam Eclipse 3.0M7, ale IntelliJ má tiež podporu JUnit, rovnako ako naposledy vydané IDE.
HttpUnit: Simulátor klienta HTTP
Pretože chceme testovať webové aplikácie, v ideálnom prípade by sa testovací nástroj mal správať presne ako webové prehliadače používateľov. Naša aplikácia (cieľ testu) by si nemala byť vedomá žiadneho rozdielu pri zobrazovaní stránok vo webovom prehliadači alebo v testovacom nástroji. To je presne to, čo poskytuje HttpUnit: simuluje požiadavky GET a POST bežného prehliadača a poskytuje pekný objektový model, pomocou ktorého je možné kódovať naše testy.
Pozrite si podrobného sprievodcu API pre ostatné triedy a metódy; Obrázok 1 poskytuje iba stručný prehľad tried, ktoré najčastejšie používam. Relácia používateľa (postupnosť interakcií s webovou aplikáciou) je zapuzdrená s a Webkonverzácia. Konštruujeme WebRequests, obvykle konfigurujúca URL a parametre, a potom ju pošleme dole cez Webkonverzácia. Rámec potom vráti a WebResponse, ktorý obsahuje vrátenú stránku a atribúty zo servera.
Tu je ukážka testovacieho prípadu HttpUnit z dokumentov HttpUnit:
/ ** * Overuje, či odoslanie prihlasovacieho formulára s menom „master“ vedie * na stránku obsahujúcu text „Prísne tajné“ ** / public void testGoodLogin () vyvolá výnimku {WebConversation conversation = new WebConversation (); Požiadavka WebRequest = nová GetMethodWebRequest ("//www.meterware.com/servlet/TopSecret"); WebResponse response = convers.getResponse (požiadavka); WebForm loginForm = response.getForms () [0]; request = loginForm.getRequest (); request.setParameter ("meno", "majster"); response = convers.getResponse (požiadavka); assertTrue ("Prihlásenie neprijaté", response.getText (). indexOf ("Zvládli ste to!")! = -1); assertEquals ("Názov stránky", "Prísne tajné", response.getTitle ()); } Architektonické úvahy
Všimnite si, ako vyššie uvedená ukážka jazyka Java obsahuje názov domény servera, na ktorom je aplikácia spustená. Počas vývoja nového systému žije aplikácia na viacerých serveroch a na serveroch môže bežať viac verzií. Je zrejmé, že nie je dobrý nápad ponechať názov servera v implementácii Java - pre každý nový server musíme prekompilovať naše zdroje. Ostatné položky by nemali byť v zdrojových súboroch, napríklad používateľské mená a heslá, ktoré by mali byť konfigurovateľný pre konkrétne nasadenie. Na druhej strane by sme nemali prehnane architektrovať jednoduchú implementáciu testovacích prípadov. Normálne špecifikácia testovacieho prípadu už obsahuje väčšinu stavu systému a popis konkrétnych parametrov pre náš scenár, takže tu je nemá zmysel robiť všetko parametrizovateľné pri implementácii.
Počas programovania si uvedomíte, že veľa sekcií kódu sa objavuje vo viac ako jednej implementácii testovacích prípadov (potenciálne vo všetkých testovacích prípadoch). Ak ste skúseným objektovo orientovaným vývojárom, bude vás lákať vytvárať hierarchie tried a bežné triedy. V niektorých prípadoch to dáva veľký zmysel - napríklad postup prihlásenia by mal byť bežnou metódou dostupnou pre všetky testovacie prípady. Musíte však trochu ustúpiť a uvedomiť si, že na produkcii zameranej na test netvoríte nový produkčný systém - tieto triedy Java nie sú ničím iným než testovacími skriptmi na overenie výstupu z webových stránok. Cvičte zdravý rozum a zamerajte sa na jednoduché, postupné a samostatné testovacie skripty.
Testovacie prípady sú zvyčajne krehké. Ak vývojár zmení adresu URL, reorganizuje rozloženie
Vysledovateľnosť je pre naše testovacie prípady rozhodujúca. Ak niečo pôjde KA-BOOM, alebo je napríklad výsledok výpočtu nesprávny, je potrebné vývojára nasmerovať na príslušnú špecifikáciu testovacieho prípadu a špecifikáciu prípadu použitia pre rýchle vyriešenie chyby. Preto anotujte svoju implementáciu odkazmi na pôvodné dokumenty so špecifikáciami. Užitočné je tiež uviesť číslo verzie týchto dokumentov. Môže to byť iba jednoduchý komentár k kódu alebo zložitý mechanizmus, keď samotné testovacie protokoly odkazujú na dokumenty; dôležité je mať odkaz v kóde a na zachovať sledovateľnosť.
Kedy môžem napísať kód?
Teraz, keď ste si vedomí požiadaviek (dokumenty prípadu použitia a príslušné špecifikácie testovacích prípadov), rozumiete základom rámca a máte súbor architektonických pokynov, poďme teda do práce.
Pri vývoji implementácií testovacích prípadov pracujem radšej v Eclipse. V prvom rade má pekného testovacieho bežca JUnit. Môžete zvoliť triedu Java a z ponuky Spustiť ju spustiť ako test jednotky JUnit. Bežec zobrazí zoznam rozpoznaných testovacích metód a výsledok vykonania. Keď je počas testovacej prevádzky všetko v poriadku, dáva to peknú zelenú čiaru. Ak došlo k chybe výnimky alebo tvrdenia, zobrazí sa to znepokojujúco červená čiara. Myslím si, že vizuálna spätná väzba je skutočne dôležitá - ponúka pocit úspechu, najmä pri písaní jednotkových testov pre váš vlastný kód. Tiež rád používam Eclipse pre jeho možnosti refaktoringu. Ak si uvedomím, že v rámci triedy testovacích prípadov musím skopírovať a vložiť sekcie kódu, môžem namiesto toho pomocou ponuky Refactoring vytvoriť metódu z sekcie kódu. Ak si uvedomím, že mnoho testovacích prípadov bude používať tú istú metódu, môžem pomocou ponuky vytiahnuť svoju metódu do svojej základnej triedy.
Na základe vyššie uvedených architektonických požiadaviek pre každý projekt zvyčajne vytvorím základnú triedu testovacích prípadov, ktorá rozširuje JUnit Testovacia situácia trieda. Ja tomu hovorím Konfigurovateľná skúška. Každá implementácia testovacích prípadov rozširuje túto triedu, pozri obrázok 2.
Konfigurovateľná skúška obvykle obsahuje bežné metódy a inicializačný kód pre testovací prípad. Súbor vlastností používam na ukladanie názvu servera, kontextu aplikácie, rôznych prihlasovacích mien pre každú rolu a niektorých ďalších nastavení.
Konkrétne implementácie testovacích prípadov obsahujú jednu testovaciu metódu pre každý scenár testovacieho prípadu (z dokumentu so špecifikáciou testovacieho prípadu). Každá metóda sa zvyčajne prihlási s konkrétnou rolou a potom vykoná interakciu s webovou aplikáciou. Väčšina testovacích prípadov nepotrebuje na vykonanie činností konkrétneho používateľa; zvyčajne vyžadujú používateľa v konkrétnej role, napríklad administrátora, návštevníka alebo registrovaného používateľa. Vždy vytvorím a Prihlasovací režim enum, ktorý obsahuje dostupné roly. Balíček Jakarta Commons ValuedEnum používam na vytváranie enumov pre úlohy. Keď sa konkrétna testovacia metóda v implementácii testovacieho prípadu prihlási, musí určiť, ktorá rola prihlásenia sa vyžaduje pre konkrétny testovací scenár. Možnosť prihlásenia sa s konkrétnym používateľom by mala byť samozrejme možná aj napríklad na overenie prípadu použitia Registrovaného používateľa.
Po každom cykle žiadosti a odpovede zvyčajne musíme overiť, či vrátená stránka obsahuje chybu, a musíme overiť naše tvrdenia o tom, aký obsah by odpoveď mala obsahovať. Aj tu musíme byť opatrní; mali by sme overovať iba položky, ktoré nie sú v aplikácii variabilné a nie sú príliš krehké. Napríklad, ak presadíme konkrétne názvy stránok, naše testy sa pravdepodobne nespustia, ak je v aplikácii zvoliteľný jazyk a chceme overiť nasadenie v inom jazyku. Podobne nemá zmysel kontrolovať položku na stránke na základe jej polohy v rozložení tabuľky; tabuľky sa často menia, takže by sme sa mali snažiť identifikovať prvky na základe ich ID. V prípade, že niektoré dôležité prvky na stránke neobsahujú ID alebo názvy, mali by sme vývojárov iba požiadať, aby ich pridali, a nie sa snažiť ich obísť.
Tvrdenia JUnit ponúkajú zlý prístup pri kontrole, či vzhľad a vzhľad, rozloženie a dizajn stránky zodpovedajú požiadavkám. Je to možné, vzhľadom na nekonečné množstvo času na vývoj testu, ale dobrý ľudský tester dokáže tieto veci posúdiť efektívnejšie. Namiesto kontroly všetkého možného na stránke sa sústreďte na overenie funkčnosti webovej aplikácie.
Tu je aktualizovaný testovací scenár založený na našej architektúre testovacích prípadov. Trieda sa rozširuje Konfigurovateľná skúška, a prihlasovacie údaje sú spracované v základnej triede:
/ ** * Overuje, či odoslanie prihlasovacieho formulára s menom „master“ vedie * na stránku obsahujúcu text „Prísne tajné“ ** / public void testGoodLogin () vyvolá výnimku {WebConversation conversation = new WebConversation (); Odpoveď WebResponse = prihlásenie (konverzácia, LoginMode.ADMIN_MODE); assertTrue ("Prihlásenie neprijaté", response.getText (). indexOf ("Zvládli ste to!")! = -1); assertEquals ("Názov stránky", "Prísne tajné", response.getTitle ()); } Tipy a triky
Väčšinu scenárov je možné pomerne jednoducho vyriešiť nastavením WebForm parametre a potom hľadať konkrétne prvky s výsledkami v WebResponse stránok, ale vždy sa nájdu náročné testovacie prípady.
