Tyypillisessä yrityssovelluksessa monet alueet vaativat testausta. Yksinkertaisimmista komponenteista, luokista alkaen kehittäjien tai erikoistuneiden testikehittäjien on ohjelmoitava yksikkötestit varmistaakseen, että sovelluksen pienimmät yksiköt toimivat oikein. Jokainen komponentti voi mahdollisesti läpäistä yksikkötestit yksin; kehittäjien on kuitenkin varmistettava, että ne toimivat odotetulla tavalla - osana osajärjestelmää ja osana koko sovellusta -, joten integraatiotestit on suoritettava. Joissakin projekteissa suorituskykyvaatimukset on täytettävä, joten laadunvarmistusinsinöörit suorittavat kuormitustestit tarkistaa ja dokumentoida sovelluksen suorituskyky erilaisissa olosuhteissa. Sovelluskehityksen aikana laadunvarmistusinsinöörit suorittavat automaattisen ja manuaalisen toiminnalliset testit testata sovelluksen käyttäytymistä käyttäjän näkökulmasta. Kun kehityshanke on melkein valmis tiettyyn virstanpylvääseen, hyväksyntätestit voidaan tarkistaa, että sovellus täyttää vaatimukset.
HttpUnit on JUnit-pohjainen kehys, joka mahdollistaa automaattisten testiskriptien toteuttamisen verkkosovelluksille. Se soveltuu parhaiten automaattisten toimintatestien tai hyväksyntätestien toteuttamiseen. Kuten nimestä voi päätellä, sitä voidaan käyttää yksikötestauksessa; tyypilliset verkkokerroksen komponentit, kuten JSP (JavaServer Pages) -sivut, servletit ja muut mallikomponentit, eivät kuitenkaan sovellu yksiköiden testaamiseen. Mitä tulee erilaisiin MVC (Model-View Controller) -kehyspohjaisiin komponentteihin, nämä soveltuvat paremmin testaamiseen muiden testauskehysten kanssa. Struts-toiminnot voidaan testata yksiköllä StrutsUnit-toiminnolla, ja WebWork 2 -toiminnot voidaan testata yksikköä esimerkiksi ilman Web-säilöä.
Testikohteet
Ennen kuin siirrymme arkkitehtuurin ja toteutuksen yksityiskohtiin, on tärkeää selvittää tarkalleen, mitä testiohjelmien on todistettava verkkosovelluksesta. On mahdollista simuloida vain rento verkkosivustokäyttäjä napsauttamalla mielenkiintoisia linkkejä ja lukemalla sivuja satunnaisessa järjestyksessä, mutta näiden satunnaisten komentosarjojen tulos ei kuvaisi sovelluksen täydellisyyttä ja laatua.
Tyypillisessä yrityksen verkkosovelluksessa (tai monimutkaisessa verkkosivustossa) on useita asiakirjoja, jotka kuvaavat käyttäjien tai sovellusten ylläpitäjien vaatimukset. Näihin voivat sisältyä käyttötapaustiedot, ei-toiminnalliset vaatimukset -määritykset, muista esineistä johdetut testitapaustiedot, käyttöliittymän suunnitteluasiakirjat, mallit, näyttelijäprofiilit ja useita muita esineitä. Yksinkertaista sovellusta varten koko määrittely voi mahdollisesti koostua yksinkertaisesta tekstitiedostosta, jossa on luettelo vaatimuksista.
Näistä asiakirjoista meidän on luotava organisoitu luettelo testitapauksista. Jokainen testitapaus kuvaa skenaarion, jonka verkkokäyttäjä voi toteuttaa verkkoselaimen kautta. Hyvä käytäntö on pyrkiä samankokoisiin skenaarioihin - suuremmat skenaariot voidaan jakaa pienempiin paloihin. Monet erinomaiset kirjat ja artikkelit käsittelevät testitapaustietojen luomista. Oletetaan, että tässä artikkelissa sinulla on joukko kohteita, jotka haluat testata Web-sovelluksellesi, jaoteltuna testitapausten sarjaksi.
Aika ladata tavaraa!
Okei, nyt tiedämme tylsät jutut, ladataan hienoja leluja! Ensinnäkin tarvitsemme asennetun Java 2 SDK: n testien kokoamiseen ja suorittamiseen. Sitten meidän on ladattava HttpUnit-kehys - tällä hetkellä versiossa 1.5.5. Binaaripaketti sisältää kaikki vaaditut kolmannen osapuolen kirjastot. Tarvitsemme myös Ant-rakennustyökalun testien suorittamiseen ja raporttien luomiseen automaattisesti. Mikä tahansa melko uusi versio näistä työkaluista todennäköisesti toimii; Haluan vain käyttää uusinta ja suurinta versiota kaikesta.
Testien kirjoittamiseen ja suorittamiseen suosittelen IDE: tä, johon on upotettu JUnit-testijuoksija. Käytän Eclipse 3.0M7 -testiä komentosarjojeni kehittämiseen, mutta IntelliJ: llä on myös JUnit-tuki, samoin kuin viimeksi julkaistuilla IDE: llä.
HttpUnit: HTTP-asiakas simulaattori
Koska haluamme testata verkkosovelluksia, ihannetapauksessa testityökalun tulisi toimia täsmälleen samalla tavalla kuin käyttäjien verkkoselaimet. Sovelluksemme (testikohde) ei pitäisi olla tietoinen eroista palvellessasi sivuja verkkoselaimelle tai testityökalulle. Juuri HttpUnit tarjoaa: se simuloi normaalia selaimen GET- ja POST-pyyntöjä ja tarjoaa mukavan objektimallin, jolla testimme koodaamaan.
Tutustu yksityiskohtaiseen API-oppaaseen muille luokille ja menetelmille; Kuvassa 1 on vain lyhyt katsaus luokkiin, joita käytän eniten. Käyttäjäistunto (vuorovaikutussarja verkkosovelluksen kanssa) on kapseloitu a Verkkokeskustelu. Rakennamme WebRequests, yleensä määrittelemällä URL-osoitteen ja parametrit, ja sitten lähetämme sen alas Verkkokeskustelu. Kehys palauttaa sitten a WebResponse, joka sisältää palautetun sivun ja palvelimen määritteet.
Tässä on esimerkki HttpUnit-testitapauksesta HttpUnit-asiakirjoista:
/ ** * Vahvistaa, että kirjautumislomakkeen lähettäminen nimellä "master" johtaa * sivulle, joka sisältää tekstin "Top Secret" ** / public void testGoodLogin () heittää poikkeuksen {WebConversation keskustelu = new WebConversation (); WebRequest-pyyntö = new GetMethodWebRequest ("//www.meterware.com/servlet/TopSecret"); WebResponse response = keskustelu.getResponse (pyyntö); WebForm loginForm = response.getForms () [0]; pyyntö = loginForm.getRequest (); request.setParameter ("nimi", "päällikkö"); vastaus = keskustelu.getResponse (pyyntö); assertTrue ("Kirjautumista ei hyväksytty", response.getText (). indexOf ("Teit sen!")! = -1); assertEquals ("Sivun otsikko", "Salainen salaisuus", response.getTitle ()); } Arkkitehtoniset näkökohdat
Huomaa, kuinka yllä oleva Java-näyte sisältää sovelluksen suorittavan palvelimen toimialuenimen. Uuden järjestelmän kehittämisen aikana sovellus asuu useilla palvelimilla, ja palvelimilla voi olla useita versioita. Ilmeisesti on huono idea pitää palvelimen nimi Java-toteutuksessa - jokaisen uuden palvelimen kohdalla meidän on koottava lähteemme uudelleen. Muiden kohteiden, kuten käyttäjänimien ja salasanojen, ei pitäisi olla lähdetiedostoissa konfiguroitavissa erityistä käyttöönottoa varten. Toisaalta meidän ei pidä yksinkertaistaa yksinkertaisen testitapauksen toteutusta. Normaalisti testitapaustiedot sisältävät jo suurimman osan järjestelmän tilasta ja spesifisiä parametrien kuvauksia skenaariollemme, joten niitä on ei ole mitään tekemistä kaikesta parametroitavasta täytäntöönpanossa.
Koodauksen aikana huomaat, että monia koodiosia esiintyy useammassa kuin yhdessä testitapaustoteutuksessa (mahdollisesti kaikissa testitapauksissa). Jos olet kokenut olio-kehittäjä, sinulla on houkutus luoda luokkahierarkioita ja yhteisiä luokkia. Joissakin tapauksissa sillä on paljon järkeä - esimerkiksi sisäänkirjautumismenettelyn tulisi olla yleinen menetelmä, joka on käytettävissä kaikissa testitapauksissa. Sinun on kuitenkin palattava hieman taaksepäin ja ymmärrettävä, että et rakenna uutta tuotantojärjestelmää testisovelluksen päälle - nämä Java-luokat ovat vain testiskriptejä verkkosivuston ulostulon vahvistamiseksi. Harjoittele tervettä järkeä ja tavoittele yksinkertaisia, peräkkäisiä ja itsenäisiä testiskriptejä.
Testitapaukset ovat tyypillisesti hauraita. Jos kehittäjä muuttaa URL-osoitetta, järjestele asettelut uudelleen
Jäljitettävyys on ratkaisevan tärkeää testitapauksillemme. Jos jokin menee KA-BOOMiin tai esimerkiksi laskentatulos on väärä, on tärkeää ohjata kehittäjä vastaavaan testitapausmääritykseen ja käyttötapausspesifikaatioon virheen nopeaa ratkaisua varten. Siksi merkitse toteutuksesi viittauksilla alkuperäisiin määrittelyasiakirjoihin. Näiden asiakirjojen versionumeron lisääminen on myös hyödyllistä. Se voi olla vain yksinkertainen koodikommentti tai monimutkainen mekanismi, jossa testiraportit itse linkittävät asiakirjoihin; Tärkeää on, että koodissa on viite ja pitää jäljitettävyys.
Milloin saan kirjoittaa koodia?
Nyt kun olet tietoinen vaatimuksista (käyttötapaustiedot ja vastaavat testitapaustiedot), ymmärrät kehyksen perusteet ja sinulla on joukko arkkitehtonisia ohjeita, ryhdymme töihin.
Testitapaustoteutusten kehittämiseksi haluan työskennellä mieluummin Eclipsessä. Ensinnäkin, sillä on mukava JUnit-testijuoksija. Voit valita Java-luokan ja suorittaa Suorita-valikosta sen JUnit-yksikötestinä. Juoksija näyttää luettelon tunnustetuista testimenetelmistä ja suoritustuloksesta. Kun kaikki menee hyvin koeajon aikana, se antaa mukavan vihreän viivan. Jos tapahtui poikkeus tai väitevirhe, se näyttää ahdistavan punaisen viivan. Mielestäni visuaalinen palaute on todella tärkeää - se tarjoaa tunteen suorituksesta, varsinkin kun kirjoitat yksikötestejä omalle koodillesi. Haluan myös käyttää Eclipseä sen refaktorointiin. Jos ymmärrän, että testitapausluokassa minun on kopioitava ja liitettävä koodiosat, voin vain käyttää Refactoring-valikkoa luodaksesi menetelmän koodiosasta. Jos tajuan, että useat testitapaukset käyttävät samaa menetelmää, voin käyttää valikkoa vetääksesi menetelmän perusluokkaan.
Yllä olevien arkkitehtonisten vaatimusten perusteella luon jokaiselle projektille tyypillisesti testitapausluokan, joka laajentaa JUnit-yksikköä Testitapaus luokassa. Minä kutsun sitä ConfigurableTestCase. Jokainen testitapaustoteutus laajentaa tätä luokkaa, katso kuva 2.
ConfigurableTestCase sisältää tyypillisesti testitapauksen yleiset menetelmät ja alustuskoodin. Käytän ominaisuustiedostoa palvelimen nimen, sovelluskontekstin, kunkin kirjautumisnimen kullekin roolille ja joitain lisäasetuksia.
Erityiset testitapaustoteutukset sisältävät yhden testimenetelmän kutakin tapausskenaariota kohden (testitapausten määrittelyasiakirjasta). Jokainen menetelmä kirjautuu yleensä sisään tietyllä roolilla ja suorittaa vuorovaikutuksen Web-sovelluksen kanssa. Useimmat testitapaukset eivät tarvitse tiettyä käyttäjää suorittamaan toimintoja; ne edellyttävät tyypillisesti tietyssä roolissa olevaa käyttäjää, kuten Järjestelmänvalvoja, Vierailija tai Rekisteröity käyttäjä. Luon aina Kirjaudu sisään enum, joka sisältää käytettävissä olevat roolit. Käytän Jakarta Commons ValuedEnum -pakettia luodaksesi enumeja rooleille. Kun tietty testimenetelmä testitapaustoteutuksessa kirjautuu sisään, sen on määritettävä, mikä kirjautumisrooli vaaditaan kyseistä testiskenaariota varten. Tietysti myös tietyn käyttäjän kirjautumismahdollisuuden tulisi olla mahdollista, esimerkiksi rekisteröidyn käyttäjän käyttötapauksen varmistamiseksi.
Jokaisen pyynnön ja vastausjakson jälkeen meidän on yleensä tarkistettava, onko palautetulla sivulla virhe, ja meidän on vahvistettava väitteemme vastauksen sisällöstä. Meidän on oltava varovaisia myös tässä; meidän tulisi tarkistaa vain kohteet, jotka eivät ole vaihtelevia eivätkä sovelluksessa liian hauraita. Esimerkiksi, jos väitämme tiettyjä sivunimikkeitä, testimme eivät todennäköisesti toimi, jos kieli on valittavissa sovelluksessa ja haluamme vahvistaa toisen kielen käyttöönoton. Vastaavasti ei ole mitään järkeä tarkistaa sivun kohdetta sen sijainnin perusteella taulukon asettelussa; pöytäpohjaiset mallit muuttuvat usein, joten meidän on pyrittävä tunnistamaan elementit niiden tunnusten perusteella. Jos joillakin sivun tärkeillä elementeillä ei ole tunnuksia tai nimiä, meidän tulisi vain pyytää kehittäjiä lisäämään ne sen sijaan, että yritettäisiin kiertää niitä.
JUnit-väitteet tarjoavat huonon lähestymistavan tarkistaa, vastaavatko ulkoasu, ulkoasu ja sivun muotoilu vaatimuksia. Se on mahdollista, kun otetaan huomioon äärettömän aika testin kehittämiseen, mutta hyvä ihminen testaaja voi arvioida näitä asioita tehokkaammin. Keskity siis verkkosovelluksen toimivuuden tarkistamiseen sen sijaan, että tarkistat kaiken mahdollisen sivulla.
Tässä on päivitetty testiskenaario, joka perustuu testitapausarkkitehtuuriin. Luokka jatkuu ConfigurableTestCase, ja kirjautumistietoja käsitellään perusluokassa:
/ ** * Vahvistaa, että kirjautumislomakkeen lähettäminen nimellä "master" johtaa * sivulle, joka sisältää tekstin "Top Secret" ** / public void testGoodLogin () heittää poikkeuksen {WebConversation keskustelu = new WebConversation (); WebResponse response = login (keskustelu, LoginMode.ADMIN_MODE); assertTrue ("Kirjautumista ei hyväksytty", response.getText (). indexOf ("Teit sen!")! = -1); assertEquals ("Sivun otsikko", "Salainen salaisuus", response.getTitle ()); } Vinkkejä
Useimmat skenaariot voidaan hoitaa melko helposti asettamalla WebForm parametrit ja etsitään sitten tiettyjä elementtejä, joilla on tuloksia WebResponse sivuja, mutta haastavia testitapauksia on aina.
