Testin ensimmäinen kehitys FitNessen kanssa

Viime vuosina olen työskennellyt kaikissa testausprosessin rooleissa palvelinpuolen JavaScript-, Perl-, PHP-, Struts-, Swing- ja mallipohjaisten arkkitehtuurien avulla. Kaikki projektit poikkesivat toisistaan, mutta niillä kaikilla oli joitain yhteisiä piirteitä: määräajat myöhästyivät, ja hankkeilla oli vaikeuksia saavuttaa asiakas Todella tarvittu.

Jokaisella projektilla oli jonkinlainen vaatimus, jotkut olivat hyvin yksityiskohtaisia, toiset vain muutaman sivun pituisia. Näille vaatimuksille tehtiin yleensä kolme vaihetta:

• Ne olivat joko asiakkaan tai urakoitsijan kirjoittamia ja saivat jonkinlaisen virallisen hyväksynnän
• Testaajat yrittivät työskennellä vaatimusten kanssa ja pitivät niitä enemmän tai vähemmän riittämättöminä
• Projekti siirtyi hyväksyntätestauksen vaiheeseen, ja asiakas yhtäkkiä muisti kaikenlaisia ​​asioita, joita ohjelmiston tarvitsi tehdä lisäksi / eri tavalla

Viimeinen vaihe johti muutoksiin, mikä johti määräaikojen puuttumiseen, mikä aiheutti kehittäjille stressiä, mikä puolestaan ​​lisäsi virheitä. Virhemäärä alkoi nousta nopeasti, ja järjestelmän yleinen laatu heikkeni. Kuulostaa tutulta?

Tarkastellaan, mikä meni pieleen edellä kuvatuissa projekteissa: Asiakas, kehittäjä ja testaaja eivät toimineet yhdessä; he välittivät vaatimukset, mutta jokaisella roolilla oli erilaiset tarpeet. Lisäksi kehittäjät kehittivät yleensä jonkinlaisia ​​automatisoituja testejä, ja testaajat yrittivät automatisoida myös joitain testejä. Yleensä he eivät voineet koordinoida testausta riittävästi, ja monia kohteita testattiin kahdesti, kun taas toiset (yleensä kovat osat) eivät ollenkaan. Ja asiakas ei nähnyt testejä. Tässä artikkelissa kuvataan tapa ratkaista nämä ongelmat yhdistämällä vaatimukset automaattisiin testeihin.

Kirjoita FitNesse

FitNesse on wiki, jossa on joitain lisätoimintoja JUnit-testien käynnistämiseen. Jos nämä testit yhdistetään vaatimuksiin, ne toimivat konkreettisina esimerkkeinä, mikä tekee vaatimuksista entistä selkeämmät. Lisäksi testitiedot on järjestetty loogisesti. Tärkeintä FitNessen käytössä on kuitenkin idea sen takana, mikä tarkoittaa, että vaatimukset osoittautuvat kirjoitettaviksi (osittain) testeinä, mikä tekee niistä testattavat ja siten niiden täyttämisen todennettavissa.

FitNessen avulla kehitysprosessi voi näyttää tältä: Vaatimusinsinööri kirjoittaa vaatimukset FitNesseen (Wordin sijaan). Hän yrittää saada asiakkaan mukaan niin paljon kuin mahdollista, mutta sitä ei yleensä voida saavuttaa päivittäin. Testaaja kurkistaa asiakirjaa toistuvasti ja esittää vaikeita kysymyksiä alusta alkaen. Koska testaaja ajattelee toisin, hän ei ajattele: "Mitä ohjelmisto tekee?" mutta "Mikä voi mennä pieleen? Kuinka voin rikkoa sen?" Kehittäjä ajattelee enemmän vaatimusten insinööri; hän haluaa tietää: "Mitä ohjelmistolla on tehtävä?"

Testaaja aloittaa testien kirjoittamisen aikaisin, kun vaatimuksia ei vielä ole vielä tehty. Ja hän kirjoittaa ne vaatimuksiin. Testeistä tulee osa vaatimusten lisäksi vaatimusten tarkistus- / hyväksymisprosessia, jolla on joitain tärkeitä etuja:

• Asiakas saa miettimään myös testejä. Yleensä hän jopa osallistuu niiden luomiseen (saatat olla yllättynyt siitä, kuinka hauskaa hänellä voi olla tämän kanssa).
• Määrittelystä tulee paljon yksityiskohtaisempi ja tarkempi, koska testit ovat yleensä tarkempia kuin pelkkä teksti.
• Aikojen miettiminen todellisissa skenaarioissa, testitietojen toimittaminen ja esimerkkien laskeminen johtaa paljon selkeämpään näkymään ohjelmistosta - kuten prototyyppi, vain enemmän toimintoja.

Lopuksi vaatimukset luovutetaan kehittäjälle. Hänellä on nyt helpompi työ, koska määrittely ei todennäköisesti muutu ja kaikkien mukana olevien esimerkkien vuoksi. Katsotaanpa, miten tämä prosessi helpottaa kehittäjän työtä.

Testaus ensin

Yleensä vaikein osa testien ensimmäisen kehityksen aloittamisessa on, että kukaan ei halua viettää niin paljon aikaa testien kirjoittamiseen, vasta sitten löytää tapa saada ne toimimaan. Edellä kuvattua prosessia käyttäen kehittäjä saa toiminnalliset testit osana sopimustaan. Hänen tehtävänsä vaihtuvat "Rakenna haluamasi asia ja olet valmis, kunnes tutkin työsi ja teen muutoksia", "Tehdä nämä testit toimimaan ja olet valmis". Nyt kaikilla on parempi käsitys siitä, mitä tehdä, milloin työ on tarkoitus saada päätökseen ja missä projekti on.

Kaikki nämä testit eivät ole automatisoituja eivätkä kaikki ole yksikötestejä. Jaamme testit yleensä seuraaviin luokkiin (yksityiskohdat seuraavat):

• Tietopohjaiset testit, jotka on toteutettava yksikkötesteinä. Laskelmat ovat tyypillinen esimerkki.
• Avainsanapohjaiset testit, jotka automatisoivat sovellusten käytön. Nämä ovat järjestelmätestejä ja vaativat sovelluksen olevan käynnissä. Painikkeita napsautetaan, tiedot syötetään ja tuloksena olevat sivut / näytöt tarkistetaan sisältävän tiettyjä arvoja. Testiryhmä toteuttaa nämä testit yleensä, mutta myös jotkut kehittäjät hyötyvät niistä.
• Manuaaliset testit. Nämä testit ovat joko liian kalliita automatisoitaviksi ja mahdolliset virheet eivät ole riittävän vakavia, tai ne ovat niin perustavanlaatuisia (aloitussivua ei näytetä), että niiden rikkoutuminen löydettäisiin kerralla.

Kun luin ensimmäisen kerran FitNessestä vuonna 2004, nauroin ja sanoin, että se ei koskaan toimi. Ajatus testien kirjoittamisesta wikiksi, joka muutti ne automaattisesti testeiksi, tuntui liian järjetön. Osoitin, olin väärässä. FitNesse on todella yksinkertainen kuin miltä se näyttää.

Tämä yksinkertaisuus alkaa asennuksesta. Lataa vain FitNessen koko jakelu ja pura se. Oletan, että olet seuraavassa keskustelussa purkanut jakelun C: \ fitnesse -pakkaukseen.

Käynnistä FitNesse suorittamalla run.bat (run.sh Linuxissa) komentosarja C: \ fitnesse. Oletusarvon mukaan FitNesse käyttää verkkopalvelinta portissa 80, mutta voit määrittää toisen portin, esimerkiksi 81, lisäämällä - 81 komentojonotiedoston ensimmäiselle riville. Siinä kaikki siinä on; pääset nyt FitNesseen osoitteessa // localhost: 81.

Tässä artikkelissa käytän FitNessen Java-versiota Windowsissa. Esimerkkejä voidaan kuitenkin käyttää myös muille versioille (Python, .Net) ja alustoille.

Jotkut testit

FitNessen online-ohjeet tarjoavat joitain yksinkertaisia ​​esimerkkejä (verrattavissa JUnitin surulliseen rahan esimerkkiin), jotta pääset alkuun. Heillä on hyvä oppia käyttämään FitNesseä, mutta ne eivät ole riittävän monimutkaisia ​​suostuttelemaan joitain epäilijöitä. Siksi käytän tosielämän esimerkkiä eräästä viimeaikaisesta projektistani. Olen yksinkertaistanut ongelmaa huomattavasti, ja koodi, jota ei ole otettu suoraan projektista, kirjoitettiin havainnollistamistarkoituksiin. Tämän esimerkin tulisi silti olla riittävän monimutkainen osoittamaan FitNessen yksinkertaisuuden voima.

Oletetaan, että työskentelemme projektissa, joka toteuttaa monimutkaisen Java-pohjaisen yritysohjelmiston suurelle vakuutusyhtiölle. Tuote hoitaa yrityksen koko liiketoiminnan, mukaan lukien asiakas- ja sopimushallinta sekä maksut. Esimerkissämme tarkastelemme pientä osaa tästä sovelluksesta.

Sveitsissä vanhemmilla on oikeus yhteen lapsilisään lasta kohden. He saavat tämän korvauksen vain, jos tietyt olosuhteet täyttyvät, ja määrä vaihtelee. Seuraava on yksinkertaistettu versio tästä vaatimuksesta. Aloitamme "perinteisillä" vaatimuksilla ja siirrämme ne myöhemmin FitNesseen.

Lapsilisää on useita vaiheita. Korvaus alkaa lapsen syntymiskuukauden ensimmäisenä päivänä ja päättyy sen kuukauden viimeisenä päivänä, jolloin lapsi saavuttaa ikärajan, päättää oppisopimuskoulutuksensa tai kuolee.

Saavutettuaan 12-vuotiaat vaate korotetaan 190 CHF: iin (Sveitsin virallinen valuuttamerkki) syntymäkuukauden ensimmäisestä päivästä alkaen.

Vanhempien kokopäiväinen ja osa-aikainen työsuhde johtaa erilaisiin korvausvaatimuksiin, kuten kuvassa 1 on kuvattu.

Nykyinen työllisyysaste lasketaan aktiivisista työsopimuksista. Sopimuksen on oltava voimassa, ja jos lopetuspäivä asetetaan, sen on sijaittava "aktivointijaksossa". Kuvasta 2 näkyy, kuinka paljon rahaa vanhemmalla on oikeus lapsen iästä riippuen.

Näitä maksuja koskevia säännöksiä mukautetaan kahden vuoden välein.

Ensimmäisessä käsittelyssä eritelmä saattaa kuulostaa tarkalta, ja kehittäjän pitäisi pystyä toteuttamaan se helposti. Mutta olemmeko todella varmoja rajaehdoista? Kuinka testaisimme nämä vaatimukset?

Skenaariot voivat olla suuri apu poikkeusten ja rajaehtojen löytämisessä, koska ne tarjoavat hyvän tavan saada toimialan asiantuntijat puhumaan liiketoiminnasta.

Skenaariot

Useimpien projektien vaatimusinsinööri luovuttaa eritelmän kehittäjälle, joka tutkii vaatimukset, kysyy joitain kysymyksiä ja alkaa suunnitella / koodata / testata. Sen jälkeen kehittäjä luovuttaa ohjelmiston testitiimille ja jonkin verran muokkausten ja korjausten jälkeen välittää sen asiakkaalle (joka todennäköisesti ajattelee joitain muutoksia edellyttäviä poikkeuksia). Tekstin siirtäminen FitNesseen ei muuta tätä prosessia; kuitenkin lisäämällä esimerkkejä, skenaarioita ja testejä.

Skenaariot ovat erityisen hyödyllisiä, kun pallo pyörii testauksen aikana. Seuraavassa on joitain esimerkkejä. Vastaaminen kysymykseen siitä, kuinka paljon lapsilisää kullekin maksetaan, selventää paljon:

• Maria on yksinhuoltaja. Hänellä on kaksi poikaa (Bob, 2, ja Peter, 15), ja hän työskentelee osa-aikaisesti (20 tuntia viikossa) sihteerinä.
• Maria menettää työpaikkansa. Myöhemmin hän työskentelee 10 tuntia viikossa kaupan avustajana ja vielä 5 tuntia lastenhoitajana.
• Paulilla ja Laralla on tytär (Lisa, 17), jolla on fyysinen haaste, ja poika (Frank, 18), joka on vielä yliopistossa.

Pelkästään näiden skenaarioiden keskusteleminen pitäisi auttaa testausprosessissa. Suorittamalla ne manuaalisesti ohjelmistolla löydät melkein varmasti löysät päät. Luuletko, ettemme voi tehdä sitä, koska meillä ei vielä ole prototyyppiä? Miksi ei?

Avainsanavetoinen testaus

Avainsanavetoista testausta voidaan käyttää prototyypin simulointiin. FitNesse antaa meille mahdollisuuden määritellä avainsanavetoisia testejä (katso lisätietoja kohdasta "Totally Data-Driven Automated Testing"). Jopa ilman ohjelmistoja testien suorittamiseksi (automaattisesti), avainsanavetoiset testit auttavat paljon.

Kuva 3 näyttää miltä avainsanavetoinen testi voi näyttää. Ensimmäinen sarake edustaa FitNessen avainsanoja. Toinen sarake edustaa Java-luokan menetelmiä (kirjoitamme ne, ja heidän on noudatettava Java-menetelmien nimille asetettuja rajoituksia). Kolmas sarake edustaa tietoja, jotka on syötetty menetelmään toisesta sarakkeesta. Viimeinen rivi osoittaa, miltä epäonnistunut testi voi näyttää (hyväksytyt testit ovat vihreitä). Kuten näette, on melko helppo selvittää, mikä meni pieleen.

Tällaisia ​​testejä on helppo ja jopa hauska luoda. Testaajat, joilla ei ole ohjelmointitaitoa, voivat luoda ne, ja asiakas voi lukea ne (lyhyen esittelyn jälkeen).

Testien määrittelemisellä tällä tavalla, aivan vaatimuksen vieressä, on joitain tärkeitä etuja verrattuna perinteiseen testitapausten määrittelyyn, jopa ilman automaattista:

• Konteksti on käsillä. Itse testitapaus voidaan kirjoittaa mahdollisimman pienellä määrällä työtä ja se on edelleen tarkka.
• Jos vaatimus muuttuu, on suuri mahdollisuus, että myös testi muuttuu (ei kovin todennäköistä, kun käytetään useita työkaluja).
• Testi voidaan suorittaa kerralla osoittamaan, mikä on korjattava, jotta tämä uusi / muuttunut vaatimus toimisi.

Testin automatisoimiseksi luodaan ohut kerros ohjelmistoa, joka delegoidaan todelliselle testikoodille. Nämä testit ovat erityisen hyödyllisiä manuaalisten GUI-testien automatisoinnissa. Kehitin HTTPUnit-pohjaisen testikehyksen verkkosivujen testauksen automatisoimiseksi.

Tässä on FitNessen automaattisesti suorittama koodi:

paketti stephanwiesner.javaworld;
tuonti sovi.ColumnFixture;
public class ChildAllowanceFixture laajentaa ColumnFixture {public void personButton () {System.out.println ("henkilöpainikkeen painaminen"); } public void securityNumber (int-numero) {System.out.println ("suojausnumeron syöttäminen" + numero); } public int childAllowance () {System.out.println ("lapsilisän laskeminen"); paluu 190; } [...]} 

Testien tuloksia voidaan tutkia myös FitNessessä (katso kuva 4), mikä auttaa suuresti virheenkorjauksessa. Päinvastoin kuin JUnit, jossa estetään kirjoittamasta virheenkorjausviestejä, pidän niitä ehdottoman välttämättöminä työskenneltäessä automaattisten verkkotestien kanssa.

Testattaessa verkkopohjaista sovellusta virhesivut sisällytetään FitNesse-sivulle ja näytetään, mikä tekee virheenkorjauksesta paljon helpompaa kuin lokitiedostojen käsittely.

Tietoihin perustuva testaus

Vaikka avainsanavetoinen testaus on hieno graafisen käyttöliittymän automatisoinnille, dataohjattu testaus on ensimmäinen valinta testattaessa koodia, joka tekee kaikenlaisen laskennan. Jos olet aiemmin kirjoittanut yksikkötestejä, mikä on kaikkein ärsyttävin asia noissa testeissä? Mahdollisuudet ovat, ajattelet tietoja. Testit ovat täynnä tietoja, jotka usein muuttuvat, mikä tekee huollosta painajaisen. Eri yhdistelmien testaaminen vaatii erilaisia ​​tietoja, mikä tekee testeistä todennäköisesti monimutkaisia, ruma petoja.