getting started with fitnesse collaboration tool
Nu bevæger verden sig til Agile. Tidlig og kontinuerlig feedback er vigtig for ethvert scrumteam. Fordi verden ændrer sig, skal testers tankegang også ændres.
I stedet for 'at finde fejl, bryde software, måle krav', overvejer testere nu at 'levere kvaliteten, lige ved første gang, test uden brugergrænsefladen eller test, selv før brugergrænsefladen er tilgængelig'.
Det er nu også nødvendigt, at testere reagerer på ændringer, og det er derfor vigtigt at komme ud af testteknikken i sort boks og ikke vente, indtil brugergrænsefladen er udviklet; I stedet skal du også teste de mellemliggende leverancer.
Hvad du vil lære:
hvordan man installerer en .jar-fil
- Men hvorfor?
- Hvad er FitNesse?
- Hvorfor skal jeg bruge FitNesse?
- Så hvad alt kan jeg oprette?
- Download og konfiguration af FitNesse:
- FitNesse-eksempel - De ting, der skal testes:
- Skrivning af din test i FitNesse:
- Nogle indsigter i Fixture / Table styles:
- Henstilling:
- Konklusion
- Anbefalet læsning
Men hvorfor?
“NU ER DETTE MEGET AGIL PERSPEKTIV”.
Når vi bygger software, holdes de laveste testlag på enhed / komponentniveau. Enhedstest udføres af udviklingsteamet. Disse enhedstest er meget teknologiorienteret og for det meste skrevet på det samme sprog med det testede system er skrevet.
Disse enhedstest er skrevet med “ X-enhed ”Testværktøj. Vi siger det i testverdenen hvis vores enhedstest er solid defekter blev identificeret meget tidligere, og testningen over enhedstestlaget bliver let i et stabilt miljø. Og når vi taler i Agile, siger vi, at hvis et hold mestrer kunsten TDD (Test Driven Development), giver test på enhedsniveau den hurtigste feedback.
Laget over enheds- / komponentlaget er Acceptance tests-laget, der udføres virksomheden. Disse er funktionelle tests, der har mere dækning end enhedstestene og udføres oftest af ikke-udviklere. Disse test tester laget bag præsentationslaget eller API'erne. Disse API'er eller metoder, når de testes, giver hurtig feedback, og når GUI er udviklet, testes de fleste af funktionaliteterne.
FitNesse er et eksempel på dette automatiserede accepttestlag.
Hvad er FitNesse?
FitNesse er 'En fuldt integreret standalone wiki og accept test test ramme'. Det er wiki-webserveren med open source. Wiki- fordi det gør det muligt at oprette dine egne websider, hvor testtabeller oprettes. Disse testtabeller er intet andet end testdata .
Dens hensigt er at understøtte smidig stil med sort boks accept og regressionstest. Det er også et samarbejdsværktøj, fordi testere samarbejder med udviklere for at forberede testpakken.
Hvorfor skal jeg bruge FitNesse?
Agilt testteam kan bruge FitNesse til at forberede testdragter, der vil teste metoderne i koden. FitNesse er analog med Junit på en måde, at det også tester metoderne, men det er anderledes end Junit, fordi testene er i form af enkle tabeller, der kan bruges af både udviklere og ikke-udviklere.
Fordele:
- Tidlig feedback ved at udføre de automatiserede acceptstest så ofte som nødvendigt.
- Testresultater er deterministiske, fordi de er fremhævet i enten rød eller grøn.
- Testdata kan designes, så de passer til kvalitetsbehovet.
- Testene er skrevet på simpelt sprog og lette at forstå, da de er skrevet i tabelform.
- Disse tabeller er defineret i form af input og forventede output.
- Se alt FitNesse har her.
Så hvad alt kan jeg oprette?
I FitNesse kan du oprette test og suite. Udtrykkene er meget de samme som i testverdenen. Test er enkelt script og dragt er samling / gruppe af tests. Når du opretter en dragt og udfører den, er fordelen, at alle testene i den dragt udføres. Så du har brug for en ordentlig planlægning for at arrangere dine tests i en jakkesæt.
Download og konfiguration af FitNesse:
=> For at downloade FitNesse, Klik her
(Bemærk: Klik på et hvilket som helst billede for at forstørre det)
Download den nyeste version af fitnesse-standalone.jar, og gem den på dit lokale drev.
Åbn en kommandoprompt, og udfør jar-filen. For nemheds skyld har jeg oprettet en batchfil:
Når jar-filen er udført, startes FitNesse som vist nedenfor: (klik på billedet for at se det større)
For at åbne FitNesse skal du åbne din browser og skrive: http: // localhost: . I dette tilfælde er portnummeret 2222.
Den modtagne side er vist nedenfor: (klik på billedet for at se det større)
Så her, hvis du kan se rullemenuen Tests, kan vi oprette en 'Suite-side' såvel som en 'Test Page'. Når du opretter en suite, udføres alle testskripterne i den suite.
Af forklaringsformål tager jeg et eksempel på testsiden.
FitNesse-eksempel - De ting, der skal testes:
Fra nu af tester vi et simpelt lommeregnerprogram vist nedenfor.
Her er koden i java, som har 4 metoder:
- tilføjelse ()
- minus ()
- formere sig ()
- del ()
(Se venligst at FitNesse fungerer med ethvert sprog, du vælger. For forklaring har jeg brugt java)
Denne kode i FitNesse-verdenen kaldes 'Fixture'.
Armaturer er intet andet end prøvekoden - eller et link mellem FitNesse og den applikation, der testes. Så når vi vil teste en metode, skal vi skrive en armatur, og denne armatur påberåber sig og tester metoden.
Så 'Fixture' -koden for vores eksempel er som følger:
publicclass Calculator { privateint first,second; publicvoid setFirst(int first) { this.first=first; } publicvoid setSecond(int second) { this.second=second; } publicint addition() { return (first+second); } publicint minus() { return (first-second); } publicint multiply() { return (first*second); } publicfloatdivide() { return (first/second); } }
Koden i formørkelse vises som: (klik på billedet for at se det større)
Vi har brug for klassefilen, så sørg for at kompilere den.
Skrivning af din test i FitNesse:
Trin 1) Lad os gå tilbage til browseren, hvor vi har FitNesse-forsiden.
På forsiden skal du klikke på “Testside”, indtaste navnet på testen og klikke på knappen “Gem”. I vores tilfælde er det 'Lommeregner'
Trin 2) I din URL skal du tilføje navnet på din test med prikken '.' Operatør.
Synes godt om: http: // localhost: 2222 / FrontPage.Calculator
Trin # 3) Klik på knappen Rediger, og indtast linjerne vist nedenfor
Her er de indtastede linjer:
! definer TEST_SYSTEM {slim}
sti F: Eclipse TestFitness bin
! | Lommeregner |
| første | andet | tilføjelse? | minus? | gang? | divider? |
| 4 | 2 | 6 | 2 | 8 | 2.0 |
| 10 | 5 | 15 | 5 | 50 | 2.0 |
| 10 | 10 | 20 | 0 | 100 | 1.0 |
Lad os forstå linjerne en efter en.
til) Den første linje siger FitNesse at bruge SLIM testsystem.
( SLIM - Står for Simple List Invocation Method. Ved at sige SLIM testsystem udføres al tabelbehandling af FitNesse. SLIM har SLIM Runner og SLIM Executer. SLIM Runner opdeler testsiderne i enkle instruktioner, og disse instruktioner sendes til SLIM Executer, som dirigerer fixturekoden til at kalde systemet under test)
b) Den anden linje definerer placeringen af klassefilen. I dette tilfælde kompileres java-koden, og klassefilen opbevares på stedet “sti F: Eclipse TestFitness bin'
c) Den tredje linje angiver navnet på klassen. I vores tilfælde er det “Lommeregner'
d) Nu kommer den fjerde linje:
De to første kolonner| første | andet |er parametrene eller inputene til java-metoden.
De næste 4 kolonner efterfulgt af “?”tilføjelse? | minus? | gang? | divider? | er metoderne i java-klassen. Disse metoder returnerer en værdi, der vil blive sammenlignet med de forventede værdier.
er) Linjerne:
| 4 | 2 | 6 | 2 | 8 | 2.0 |
| 10 | 5 | 15 | 5 | 50 | 2.0 |
| 10 | 10 | 20 | 0 | 100 | 1.0 |
Er testcases, eller skal jeg sige Testdata for vores metode.
Den første linje:
| første | andet | tilføjelse? | minus? | gang? | divider? |
| 4 | 2 | 6 | 2 | 8 | 2.0 |
Vil tage 4 som den første parameter og 2 som den anden parameter og videregive disse to værdier i tilføjelsesmetoden til java-klassen. Metoden udføres og returnerer en værdi. Denne returnerede værdi sammenlignes med den forventede værdi skrevet under 'tilføjelsen?' som er| 6 |
På samme måde vil FitNesse passere de første 2 parametre i minus? Metode til java-klassen og returnerer en værdi. Denne værdi sammenlignes med den forventede værdi | 2 |
hvad er forskellen mellem port forwarding og port triggering
På samme måde multiplicere? og dele? fungerer ved at tage værdierne for den første og anden parameter og returnerer værdi, som sammenlignes med| 8 | 2.0 |henholdsvis
På samme måde udføres nedenstående 2 rækker (eller jeg skulle sige testsagerne).
| 10 | 5 | 15 | 5 | 50 | 2.0 |
| 10 | 10 | 20 | 0 | 100 | 1.0 |
Trin # 4) Når du har redigeret dine tests, skal du klikke på knappen Gem, og din side vil se ud:
Trin # 5) For at køre testene, klik på knappen Test, og vi får resultatet som følger: (klik på billedet for at se det større)
For den første række (som er vores første testtilfælde) fremhæver den grønne farve, at værdierne, der returneres fra metoden tilføjelse (), minus (), multiplicer () og del () svarer til det forventede, dvs. 6, 2 Henholdsvis 8 og 2,0. På samme måde matcher alle de værdier, der returneres fra metoderne, for anden række (som er den anden testtilfælde).
Trin # 6) Lad mig nu ændre nogle få af de forventede værdier til andre værdier (værdierne er forkerte, men jeg har gjort det målrettet til forklaring)
Fra nu af har jeg:
- Ændrede den forventede værdi for tilføjelse () for første testtilfælde til at være 7
- Ændrede den forventede værdi for minus () for den anden testtilfælde
- Ændrede den forventede værdi for deling () for den tredje testtilfælde.
Trin # 7) Kør testen ved at klikke på “Test” -knappen. Ovenstående tests skulle mislykkes. (klik på billedet for at se det større)
Den røde farve fremhæver, at disse tests mislykkedes.
Nogle indsigter i Fixture / Table styles:
Vi har set, at testene i FitNesse udføres ved at udføre rækker i en tabel. Derfor for at udføre forskellige slags tests (eller jeg skulle sige for at teste forskellige slags metoder), ville vi have brug for forskellige slags tabeller. Vi bruger nedenstående Fixture / tabel stilarter oftest:
- Kolonne Fixture - er mest udbredt (og bruges i ovenstående eksempel). Her repræsenterer datarækkerne forskellige sæt input og dets forventede output.
- Række inventar - Det bruges til at teste forespørgsler, der returnerer nogle sæt værdier.
- Action-inventar - Det bruges til at køre tests for en række begivenheder. Disse begivenheder kan være som at klikke på en knap og kontrollere værdier
Henstilling:
Jeg har forsøgt at demonstrere koncepterne, så vi kan begynde at udforske mere på FitNesse. Testers tankegang skal også ændres og skal udvides. Vi er nødt til at stoppe med at begrænse os selv til at se inde i koden. Jeg føler; i sidste ende tester vi koden, så hvorfor prøver vi ikke at se koden og teste der og da?
Begynd at skærpe dine programmeringsfærdigheder og læg mere vægt på at opbygge logikken og snarere at lære syntaks. Når du er fortrolig med programmeringskoncepter og har praksis med at implementere det, bliver det lettere at udforske FitNesse.
Konklusion
Test i smidige kommer i 4 varianter:
- Automatiseret enhedstest - Ved hjælp af Junit
- Automatiseret acceptbekræftelsestest - Ved hjælp af FitNesse
- Automatiske UI / regressionstest - ved hjælp af Selenium eller QTP
- Manuel test
Vi skal prøve at skubbe maksimalt ud af vores test i enheden og acceptlaget . Indtil nu har vi forsøgt at beholde det meste af vores test for UI-laget ved hjælp af værktøjer som QTP og Selen, men ulempen her er, at disse funktionaliteter ikke kunne testes, medmindre UI er udviklet. På det tidspunkt, hvor du finder en defekt, er udviklerne flyttet ind i en anden funktionsudvikling.
På den anden side, hvis vi kan teste API'erne hurtigt efter at det er skrevet, kan udviklere rette det med det samme. Dette ville også resultere i mindre indsats, når vi tester GUI. Da alle funktionaliteterne er testet, bliver det let at teste GUI.
Med Agile har testers tankegang også brug for en ændring, og de er nødt til at komme ud af deres rutinemæssige testtest, og nu skal du se på koden og prøve at identificere mangler, selv UI er ikke tilgængelig.
Om forfatteren: Dette er en gæsteartikel af STH-teammedlem Shilpa C. Roy. Hun arbejder inden for softwaretest i de sidste 9+ år inden for domæner som internetannoncering, Investment Banking og Telecom.
Fortæl os dine spørgsmål i kommentarerne nedenfor.
Anbefalet læsning
- Udviklere er ikke gode testere. Hvad sagde du?
- Nyttigt gratis skærmoptagelses- og kommentatorværktøj til testerne - qSnap Review
- Top 10 mest populære kodevurderingsværktøjer til udviklere og testere
- WebLOAD Review - Kom godt i gang med WebLOAD Load Testing Tool
- Top 15 SOA-testværktøjer til testere
- Hvordan holder jeg motivationen levende i softwaretestere?
- TestLodge Test Management Tool Review
- Blød dygtighed for testere: Sådan forbedres kommunikationsevnen