Pirmasis bandymas buvo sukurtas naudojant „FitNesse“

Per pastaruosius kelerius metus dirbau visuose testavimo procesuose, naudodamas serverio „JavaScript“, „Perl“, PHP, „Struts“, „Swing“ ir modeliu pagrįstas architektūras. Visi projektai skyrėsi, tačiau visi turėjo tam tikrų bendrumų: terminai vėlavo, o projektams kilo sunkumų įgyvendinant tai, ką užsakovas tikrai reikia.

Kiekvienam projektui buvo keliami kažkokie reikalavimai, kai kurie buvo labai išsamūs, kiti - tik kelių puslapių. Šiems reikalavimams paprastai buvo atlikti trys etapai:

• Jie buvo parašyti (arba užsakovo, arba rangovo) ir gavo tam tikrą oficialų sutikimą
• Testuotojai bandė dirbti su reikalavimais ir nustatė, kad jie daugiau ar mažiau nepakankami
• Projektas pateko į priėmimo testavimo etapą, ir klientas staiga prisiminė įvairius dalykus, kuriuos programinei įrangai reikėjo atlikti papildomai / kitaip

Paskutinis etapas paskatino pokyčius, dėl kurių buvo praleisti terminai, o tai sukėlė stresą kūrėjams, o tai savo ruožtu sukėlė daugiau klaidų. Klaidų skaičius pradėjo sparčiai didėti, o bendra sistemos kokybė suprastėjo. Skamba pažįstamai?

Apsvarstykime, kas nutiko aukščiau aprašytuose projektuose: klientas, kūrėjas ir testuotojas neveikė kartu; jie perdavė reikalavimus, tačiau kiekvienas vaidmuo turėjo skirtingus poreikius. Be to, kūrėjai dažniausiai sukūrė tam tikrus automatizuotus testus, o bandytojai bandė automatizuoti ir kai kuriuos testus. Paprastai jie negalėjo derinti bandymų ir daugelis daiktų buvo tikrinami du kartus, o kiti (dažniausiai kietosios dalys) - visai ne. Ir klientas nematė jokių bandymų. Šiame straipsnyje aprašomas būdas išspręsti šias problemas derinant reikalavimus su automatizuotais bandymais.

Įveskite „FitNesse“

„FitNesse“ yra „wiki“ su keliomis papildomomis funkcijomis, suaktyvinančiomis „JUnit“ testus. Jei šie bandymai derinami su reikalavimais, jie yra konkretūs pavyzdžiai, todėl reikalavimai tampa dar aiškesni. Be to, bandymo duomenys yra logiškai sutvarkyti. Tačiau svarbiausias dalykas naudojant „FitNesse“ yra idėja už tai reiškia, kad reikalavimai pasirodo (iš dalies) parašyti kaip testai, todėl juos galima patikrinti ir todėl patikrinti, ar jie įvykdyti.

Naudojant „FitNesse“, kūrimo procesas gali atrodyti taip: Reikalavimų inžinierius reikalavimus rašo „FitNesse“ (vietoj „Word“). Jis stengiasi kuo labiau įtraukti klientą, tačiau to paprastai neįmanoma pasiekti kasdien. Testuotojas pakartotinai žvilgčioja į dokumentą ir nuo pat pirmos dienos užduoda sunkius klausimus. Kadangi testuotojas galvoja kitaip, jis nemąsto: "Ką veiks programinė įranga?" bet "Kas gali būti ne taip? Kaip aš galiu tai sugadinti?" Kūrėjas mąsto labiau kaip reikalavimų inžinierius; jis nori žinoti: "Ką turi daryti programinė įranga?"

Testuotojas savo testus pradeda rašyti anksti, kai reikalavimai dar net nėra įvykdyti. Ir jis juos įrašo į reikalavimus. Testai tampa ne tik reikalavimų, bet ir reikalavimų peržiūros / priėmimo proceso dalimi, kuris turi keletą svarbių pranašumų:

• Klientas taip pat gali pagalvoti apie testus. Paprastai ji net įsitraukia į jų kūrimą (galite nustebti, kaip jai tai gali būti smagu).
• Specifikacija tampa daug detalesnė ir tikslesnė, nes testai paprastai yra tikslesni nei paprastas tekstas.
• Anksti pagalvojus apie tikrus scenarijus, pateikiant bandymų duomenis ir apskaičiuojant pavyzdžius, programinė įranga yra kur kas aiškesnė - kaip prototipas, tik su daugiau funkcijų.

Galiausiai reikalavimai perduodami kūrėjui. Jam dabar yra lengvesnis darbas, nes specifikacija rečiau keičiasi ir dėl visų pateiktų pavyzdžių. Pažvelkime, kaip šis procesas palengvina kūrėjo darbą.

Pirmiausia įgyvendinkite testą

Paprastai sunkiausia pradėti testus pirmiausia yra tai, kad niekas nenori praleisti tiek daug laiko rašydamas testus, tik tada rasdamas būdą, kaip priversti juos dirbti. Naudodamasis aukščiau aprašytu procesu, kūrėjas gauna funkcinius testus kaip savo sutarties dalį. Jo užduotys keičiasi iš „Sukurkite norimą daiktą ir jūs atliksite, kol ištirsiu jūsų darbą ir atliksiu pakeitimus“ į „Padarykite, kad šie testai veiktų ir jūs atliksite“. Dabar visi geriau supranta, ką daryti, kada bus baigti darbai ir kur yra projektas.

Ne visi šie bandymai bus automatizuoti ir ne visi bus vienetiniai. Testus paprastai skirstome į šias kategorijas (išsami informacija bus toliau):

• Duomenimis pagrįsti bandymai, kuriuos reikia įgyvendinti kaip vieneto testus. Skaičiavimai yra tipiškas pavyzdys.
• Pagal raktinius žodžius pagrįsti testai, kurie automatizuoja programų naudojimą. Tai yra sistemos bandymai, kuriems atlikti reikalinga programa. Spustelėjami mygtukai, įvedami duomenys ir tikrinami gautuose puslapiuose / ekranuose yra tam tikros vertės. Testų komanda paprastai vykdo šiuos testus, tačiau kai kurie kūrėjai taip pat naudojasi jais.
• Rankiniai bandymai. Šie bandymai yra arba per brangūs automatizuoti, ir galimos klaidos nėra pakankamai rimtos, arba yra tokios esminės (pradinis puslapis nerodomas), kad jų pažeidimas būtų pastebėtas vienu metu.

Kai 2004 m. Pirmą kartą skaičiau apie „FitNesse“, nusijuokiau ir sakiau, kad tai niekada neveiks. Idėja surašyti testus į wiki, kurie juos automatiškai pavertė testais, atrodė pernelyg absurdiška. Pasirodė, aš klydau. „FitNesse“ iš tikrųjų yra tokia paprasta, kokia atrodo.

Šis paprastumas prasideda nuo diegimo. Tiesiog atsisiųskite visą „FitNesse“ platinimą ir išpakuokite. Šioje diskusijoje manau, kad jūs išpakavote paskirstymą C: \ fitnesse.

Paleiskite „FitNesse“ paleisdami paleisti.šikšnosparnis (paleisti.sh Linux sistemoje) scenarijus C: \ fitnesse. Pagal numatytuosius nustatymus „FitNesse“ valdo žiniatinklio serverį 80 prievade, tačiau pridėdami galite nurodyti kitą prievadą, tarkime, 81 -p 81 į pirmąją paketinio failo eilutę. Tai viskas, ko reikia; dabar galite pasiekti „FitNesse“ adresu // localhost: 81.

Šiame straipsnyje „Windows“ naudoju „FitNesse“ „Java“ versiją. Tačiau pavyzdžiai gali būti naudojami ir kitoms versijoms („Python“, .Net) bei platformoms.

Kai kurie testai

„FitNesse“ internetinėje dokumentacijoje pateikiami keli paprasti pavyzdžiai (palyginami su liūdnai pagarsėjusiu „JUnit“ pinigų pavyzdžiu), kad galėtumėte pradėti. Jie puikiai mokosi naudotis „FitNesse“, tačiau nėra pakankamai sudėtingi, kad įtikintų kai kuriuos skeptikus. Todėl naudosiu realaus pasaulio pavyzdį iš vieno savo naujausių projektų. Aš gerokai supaprastinau problemą, o kodas, paimtas ne tiesiogiai iš projekto, buvo parašytas iliustraciniais tikslais. Vis dėlto šis pavyzdys turėtų būti pakankamai sudėtingas, kad būtų galima parodyti „FitNesse“ paprastumo galią.

Tarkime, kad mes dirbame projekte, kuriame įgyvendinama sudėtinga „Java“ pagrindu sukurta programinė įranga didelei draudimo bendrovei. Gaminiu bus tvarkomas visas įmonės verslas, įskaitant klientų ir sutarčių valdymą bei mokėjimus. Pavyzdžiui, apžvelgsime nedidelę šios programos dalį.

Šveicarijoje tėvai turi teisę gauti vieną vaiko pašalpą kiekvienam vaikui. Jie gauna šią pašalpą tik esant tam tikroms aplinkybėms ir jos dydis skiriasi. Toliau pateikiama supaprastinta šio reikalavimo versija. Pradėsime nuo „tradicinių“ reikalavimų ir vėliau juos perkelsime į „FitNesse“.

Yra keletas vaiko pašalpos etapų. Ieškinys pradedamas skaičiuoti pirmą vaiko gimimo mėnesio dieną ir baigiasi paskutinę mėnesio dieną, kai vaikas pasiekia amžiaus ribą, baigia pameistrystę ar miršta.

Sulaukus 12 metų, reikalavimas padidinamas iki 190 CHF (oficialus Šveicarijos valiutos simbolis) nuo pirmos mėnesio gimimo dienos.

Tėvų įdarbinimas visą ir ne visą darbo dieną sukelia skirtingas pretenzijas, kaip aprašyta 1 paveiksle.

Dabartinė užimtumo norma apskaičiuojama pagal aktyvias darbo sutartis. Sutartis turi galioti, o jei nustatoma pabaigos data, ji turi būti nurodyta „aktyvavimo laikotarpyje“. 2 paveiksle parodyta, kiek pinigų turi tėvai, atsižvelgiant į vaiko amžių.

Šias išmokas reglamentuojančios taisyklės keičiamos kas dvejus metus.

Per pirmąjį svarstymą specifikacija gali skambėti tiksliai, o kūrėjas turėtų turėti galimybę ją lengvai įgyvendinti. Bet ar tikrai esame tikri dėl ribinių sąlygų? Kaip mes išbandytume šiuos reikalavimus?

Scenarijai gali būti didelė pagalba ieškant išimčių ir ribinių sąlygų, nes jie yra geras būdas privesti domenų ekspertus kalbėti apie verslą.

Scenarijai

Daugumoje projektų reikalavimų inžinierius pateikia specifikaciją kūrėjui, kuris išnagrinėja reikalavimus, užduoda keletą klausimų ir pradeda kurti / koduoti / testuoti. Vėliau kūrėjas perduoda programinę įrangą bandymų komandai ir, atlikęs tam tikrus pakeitimus bei pataisymus, perduoda ją klientui (kuris greičiausiai sugalvos kai kurias išimtis, kurioms reikalingi pakeitimai). Perkėlus tekstą į „FitNesse“, šis procesas nebus pakeistas; tačiau pridedant pavyzdžių, scenarijų ir testų bus.

Scenarijai yra ypač naudingi norint gauti kamuolį rutulio bandymo metu. Toliau pateikiami keli pavyzdžiai. Atsakymas į klausimą, kiek kiekvienam turi būti mokama vaiko pašalpa, labai paaiškins:

• Marija yra viena iš tėvų. Ji turi du sūnus (2 metų Bobą ir 15 metų Peterį) ir dirba ne visą darbo dieną (20 valandų per savaitę) sekretore.
• Marija netenka darbo. Vėliau ji dirba 10 valandų per savaitę parduotuvės padėjėja ir dar 5 valandas aukle.
• Paulius ir Lara turi dukrą (Liza, 17 m.), Kuri turi fizinių problemų, ir sūnų (Frankas, 18 m.), Kuris dar studijuoja universitete.

Tiesiog kalbėjimas per šiuos scenarijus turėtų padėti testavimo procesui. Vykdant juos rankiniu būdu programinėje įrangoje, neabejotinai bus keletas laisvų galų. Manote, kad mes negalime to padaryti, nes dar neturime prototipo? Kodėl gi ne?

Raktiniais žodžiais pagrįstas testavimas

Raktiniais žodžiais pagrįstas bandymas gali būti naudojamas modeliuojant prototipą. „FitNesse“ leidžia mums apibrėžti raktiniais žodžiais pagrįstus testus (daugiau informacijos žr. „Visiškai duomenimis pagrįstas automatinis testavimas“). Net neturint programinės įrangos, pagal kurią (automatiškai) būtų galima atlikti bandymus, raktiniais žodžiais paremti testai labai padės.

3 paveiksle parodyta, kaip gali atrodyti raktiniu žodžiu pagrįstas testas. Pirmame stulpelyje pateikiami „FitNesse“ raktiniai žodžiai. Antrame stulpelyje pateikiami „Java“ klasės metodai (mes juos rašome ir jie turi laikytis „Java“ metodų pavadinimams nustatytų apribojimų). Trečiasis stulpelis rodo duomenis, įvestus į metodą iš antrojo stulpelio. Paskutinė eilutė parodo, kaip gali atrodyti nepavykęs testas (išlaikyti testai yra žali). Kaip matote, gana lengva sužinoti, kas nutiko ne taip.

Tokius testus lengva ir net smagu sukurti. Testuotojai, neturintys programavimo įgūdžių, gali juos sukurti, o klientas gali juos perskaityti (po trumpos įžangos).

Tokiu būdu testų apibrėžimas šalia reikalavimo turi keletą svarbių pranašumų, palyginti su tradiciniu bandymų atvejų apibrėžimu, net ir be automatikos:

• Kontekstas yra ranka pasiekiamas. Pats bandomasis atvejis gali būti parašytas atliekant kuo mažiau darbo ir vis dar tikslus.
• Jei reikalavimas pasikeis, yra didelė tikimybė, kad ir testas pasikeis (nelabai tikėtina, kai naudojamos kelios priemonės).
• Testą galima atlikti iškart, kad būtų parodyta, ką reikia pataisyti, kad šis naujas / pakeistas reikalavimas veiktų.

Testavimui automatizuoti sukuriamas plonas programinės įrangos sluoksnis, kuris yra deleguojamas tikram testo kodui. Šie testai yra ypač naudingi automatizuojant GUI testus rankiniu būdu. Sukūriau testavimo sistemą, pagrįstą HTTPUnit, skirtą tinklalapių testavimui automatizuoti.

Štai „FitNesse“ automatiškai vykdomas kodas:

paketas stephanwiesner.javaworld;
importo tinkamumas.ColumnFixture;
public class ChildAllowanceFixture prailgina ColumnFixture {public void personButton () {System.out.println ("paspaudus asmens mygtuką"); } public void securityNumber (int numeris) {System.out.println ("saugumo numerio įvedimas" + numeris); } public int childAllowance () {System.out.println ("vaiko pašalpos apskaičiavimas"); grįžti 190; } [...]} 

Testų rezultatus galima išnagrinėti ir „FitNesse“ (žr. 4 pav.), O tai labai padeda derinant. Skirtingai nei „JUnit“, kur atgrasoma rašyti derinimo pranešimus, manau, kad jie yra būtini dirbant su automatizuotais žiniatinklio testais.

Testuojant žiniatinklio programą, klaidos puslapiai įtraukiami į „FitNesse“ puslapį ir rodomi, todėl derinimas yra daug lengvesnis nei darbas su žurnalo failais.

Duomenimis pagrįstas testavimas

Nors raktiniais žodžiais pagrįstas testavimas yra tinkamas GUI automatizavimui, duomenimis pagrįstas testavimas yra pirmasis pasirinkimas testuojant kodą, atliekant bet kokio pobūdžio skaičiavimus. Jei anksčiau esate rašęs vieneto testus, kas labiausiai erzina tuos testus? Tikėtina, kad galvojate apie duomenis. Jūsų testai bus pilni duomenų, kurie dažnai keičiasi, todėl priežiūra yra košmaras. Norint išbandyti skirtingus derinius, reikalingi skirtingi duomenys, tikriausiai bandymai taps sudėtingi, negražūs žvėrys.