getting started with fitnesse collaboration tool
Ara el món es mou cap a Àgil. La retroalimentació primerenca i contínua és imperial per a qualsevol equip de scrum. Com que el món està canviant, també cal canviar la mentalitat dels verificadors.
En lloc de 'trobar errors, trencar programari, mesurar els requisits', els provadors ara estan pensant a 'oferir la qualitat, al principi, provar sense la interfície d'usuari o provar fins i tot abans que la interfície d'usuari estigui disponible'.
Ara també es requereix que els provadors responguin als canvis i, per tant, és important sortir de la tècnica de proves de la caixa negra i no esperar fins que es desenvolupi la IU; en el seu lloc, comenceu a provar també els lliuraments intermedis.
Què aprendreu:
millor lloc de descàrrega de música per a Android
- Però perquè?
- Què és FitNesse?
- Per què he d’utilitzar FitNesse?
- Llavors, què puc crear?
- Descàrrega i configuració de FitNesse:
- Exemple FitNesse: el que cal provar:
- Escrivint la prova a FitNesse:
- Algunes idees sobre els estils de fixació / taula:
- Recomanació:
- Conclusió
- Lectura recomanada
Però perquè?
'ARA, AQUESTA PERSPECTIVA ÉS MOLT ÀGIL'.
Sempre que construïm programari, les capes més baixes de proves es mantenen a nivell d’unitat / component. Les proves de la unitat les realitza l’equip de desenvolupament. Aquestes proves unitàries estan molt orientades a la tecnologia i, principalment, estan escrites en el mateix idioma amb el sistema que es prova.
Aquestes proves unitàries s’escriuen amb “ X unitat ”Eina de prova. Al món de les proves ho diem si la nostra prova unitària és sòlida com la roca , els defectes s’identifiquen molt abans i les proves per sobre de la capa de proves unitàries es fan fàcils en un entorn estable. I quan parlem a Agile, diem que si un equip domina l’art del TDD (Test Driven Development), les proves de nivell de la unitat proporcionen els comentaris més ràpids.
La capa per sobre de la capa d’unitat / component és la capa de proves d’acceptació que duu a terme l’empresa. Són proves funcionals que tenen més cobertura que les proves unitàries i que sovint són executades pels no desenvolupadors. Aquestes proves posen a prova la capa darrere de la capa de presentació o les API. Aquestes API o mètodes en provar-se proporcionen una retroalimentació ràpida i quan es desenvolupa la interfície gràfica d’usuari, es proven la majoria de les funcionalitats.
FitNesse és un exemple d'aquesta capa de proves automàtiques d'acceptació.
Què és FitNesse?
FitNesse és 'Un wiki independent completament integrat i un marc de proves d'acceptació'. És el servidor web wiki de codi obert. Wiki- perquè permet crear les vostres pròpies pàgines web en les quals es creen taules de prova. Aquestes taules de prova no són res més que el dades de prova .
La seva intenció és donar suport a un estil àgil d’acceptació i prova de regressió de la caixa negra. També és una eina de col·laboració perquè els verificadors col·laboren amb els desenvolupadors per preparar el conjunt de proves.
Per què he d’utilitzar FitNesse?
L’equip de proves Agile pot utilitzar FitNesse per preparar vestits de prova que posaran a prova els mètodes del codi. FitNesse és anàleg a Junit d’una manera que també prova els mètodes, però és diferent de Junit perquè les proves tenen la forma de taules senzilles que poden ser utilitzades tant per desenvolupadors com per no desenvolupadors.
Avantatges:
- Retroalimentació primerenca mitjançant l’execució de les proves d’acceptació automatitzades amb la freqüència que calgui.
- Els resultats de les proves són deterministes perquè es destaquen en vermell o verd.
- Les dades de les proves es poden dissenyar per adaptar-se a les necessitats de qualitat.
- Les proves s’escriuen en un llenguatge senzill i fàcil d’entendre ja que s’escriuen en forma de taula.
- Aquestes taules es defineixen en termes d’entrada i sortides esperades.
- Veure tot Funcions de FitNesse aquí.
Llavors, què puc crear?
A FitNesse, podeu crear Tests i Suite. Els termes són molt els mateixos que s’utilitzen al món de les proves. Les proves són de guió únic i el vestit és una col·lecció / grup de proves. Quan creeu i executeu un vestit, l'avantatge és que s'executen totes les proves d'aquest vestit. Per tant, necessiteu una planificació adequada per organitzar les proves amb un vestit.
Descàrrega i configuració de FitNesse:
=> Per descarregar FitNesse, Clica aquí
(Nota: Feu clic a qualsevol imatge per ampliar-la)
Baixeu-vos la versió més recent de fitnesse-standalone.jar i deseu-la a la vostra unitat local.
Obriu un indicador d’ordres i executeu el fitxer jar. Per facilitat, he creat un fitxer per lots:
Un cop executat el fitxer jar, s'inicia FitNesse com es mostra a continuació: (feu clic a la imatge per ampliar-la)
Per obrir FitNesse, obriu el navegador i escriviu: http: // localhost: . En aquest cas, el número de port és 2222.
La pàgina rebuda es mostra a continuació: (feu clic a la imatge per ampliar-la)
Així doncs, aquí, si podeu veure el menú desplegable Proves, podem crear una 'pàgina de Suite' i una 'pàgina de prova'. Quan creeu una suite, s'executaran tots els scripts de prova dins d'aquesta suite.
A títol explicatiu, estic prenent un exemple de Test Page.
Exemple FitNesse: el que cal provar:
A hores d’ara, estem provant un programa de calculadores senzill que es mostra a continuació.
Aquí teniu el codi a Java, que té 4 mètodes:
- addició ()
- menys ()
- multiplicar ()
- divideix ()
(Consulteu que FitNesse funciona amb qualsevol idioma que trieu. Per a una explicació, he utilitzat java)
Aquest codi al món FitNesse s’anomena “Fixture”.
Els accessoris no són res més que el codi de mostra - o bé un enllaç entre FitNesse i l'aplicació sotmesa a prova. Per tant, sempre que vulguem provar un mètode, hem d’escriure un dispositiu i aquest dispositiu l’invocarà i provarà el mètode.
Per tant, el codi 'Fixture' per al nostre exemple és el següent:
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); } } El codi en eclipsi es mostra com: (feu clic a la imatge per ampliar-la)
Necessitaríem el fitxer de classe, així que assegureu-vos que el compileu.
Escrivint la prova a FitNesse:
Pas 1) Tornem al navegador on tenim la pàgina principal de FitNesse.
A la pàgina inicial, feu clic a 'Pàgina de prova', introduïu el nom de la prova i feu clic al botó 'Desa'. En el nostre cas, és 'Calculadora'
Pas 2) Al vostre URL, afegiu el nom de la prova amb un punt '.' Operador.
M'agrada: http: // localhost: 2222 / FrontPage.Calculator
Pas 3) Feu clic al botó Edita i introduïu les línies que es mostren a continuació
Aquí teniu les línies introduïdes:
! defineix TEST_SYSTEM {slim}
! ruta F: Eclipse TestFitness bin
! | Calculadora |
| primer | segon | addició? | menys? | multiplicar? | dividir? |
| 4 | 2 | 6 | 2 | 8 | 2.0 |
com veure un fitxer .dat
| 10 | 5 | 15 | 5 | 50 | 2.0 |
| 10 | 10 | 20 | 0 | 100 | 1.0 |
Anem a entendre les línies una per una.
a) La primera línia diu que FitNesse utilitzarà el sistema de prova SLIM.
( PRIM - Significa el mètode d’invocació de llista simple. En dir el sistema de prova SLIM, FitNesse fa tot el processament de la taula. SLIM té SLIM Runner i SLIM Executer. SLIM Runner divideix les pàgines de la prova en instruccions senzilles i aquestes instruccions es passen a SLIM Executer, que dirigeix el codi del dispositiu per trucar al sistema en proves).
b) La segona línia defineix la ubicació del fitxer de classe. En aquest cas, es compila el codi java i el fitxer de classe es manté a la ubicació 'ruta F: Eclipse TestFitness bin'
c) La tercera línia indica el nom de la classe. En el nostre cas és 'Calculadora'
d) Ara arriba la quarta línia:
Les dues primeres columnes| primer | segon |són els paràmetres o les entrades del mètode Java.
Les 4 columnes següents, seguides de '?'addició? | menys? | multiplicar? | dividir? | són els mètodes de la classe java. Aquests mètodes retornaran un valor que es compararia amb els valors esperats.
és) Les línies:
| 4 | 2 | 6 | 2 | 8 | 2.0 |
| 10 | 5 | 15 | 5 | 50 | 2.0 |
| 10 | 10 | 20 | 0 | 100 | 1.0 |
Són els casos de prova o hauria de dir Dades de prova per al nostre mètode.
La primera línia:
| primer | segon | addició? | menys? | multiplicar? | dividir? |
| 4 | 2 | 6 | 2 | 8 | 2.0 |
Prendrà 4 com a primer paràmetre i 2 com a segon paràmetre i passarà aquests dos valors al mètode d'addició de la classe java. El mètode s'executarà i retornarà un valor. Aquest valor retornat es compararà amb el valor esperat escrit a la secció 'addició?' el qual és| 6 |
De la mateixa manera, FitNesse passarà els dos primers paràmetres en menys? Mètode de la classe java i retorna un valor. Aquest valor es compararà amb el valor esperat en contra | 2 |
De la mateixa manera, multiplicar? i dividir? funcionarà prenent els valors del primer i segon paràmetre i retorna el valor que es compara amb| 8 | 2.0 |respectivament
De la mateixa manera, s’executen les 2 files següents (o hauria de dir els casos de prova).
| 10 | 5 | 15 | 5 | 50 | 2.0 |
| 10 | 10 | 20 | 0 | 100 | 1.0 |
Pas 4) Un cop hàgiu editat les proves, feu clic al botó Desa i la vostra pàgina tindrà el següent aspecte:
Pas 5) Per executar les proves, feu clic al botó Prova i obtindrem el resultat de la manera següent: (feu clic a la imatge per ampliar-la)
Per a la primera fila (que és el nostre primer cas de prova), el color verd posa de manifest que els valors, retornats del mètode addició (), menys (), multiplicar () i dividir () coincideixen amb el que s’espera, és a dir, 6, 2 , 8 i 2.0 respectivament. De la mateixa manera, per a la segona fila (que és el segon cas de prova) tots els valors retornats dels mètodes coincideixen.
Pas 6) Ara, per demostrar-ho, permeteu-me canviar alguns dels valors esperats per altres valors (els valors són incorrectes, però ho he fet a propòsit per obtenir explicacions)
A hores d’ara tinc:
- S'ha canviat el valor esperat d'addició () per al primer cas de prova per ser 7
- S'ha canviat el valor esperat de minus () per al segon cas de prova
- S'ha canviat el valor esperat de divide () per al tercer cas de prova.
Pas 7) Feu la prova fent clic al botó 'Prova'. Les proves anteriors haurien de fallar. (feu clic a la imatge per ampliar-la)
El color vermell ressalta que aquestes proves van fallar.
Algunes idees sobre els estils de fixació / taula:
Hem vist que a FitNesse les proves s’executen executant files en una taula. Per tant, per executar diferents tipus de proves (o hauria de dir que provar diferents tipus de mètodes), hauríem d’utilitzar diferents tipus de taules. Utilitzem amb freqüència els estils de fixació / taula següents:
- Fixació de columna - s'utilitza més àmpliament (i s'utilitza a l'exemple anterior). Aquí les files de dades representen diferents conjunts d’entrada i la seva sortida esperada.
- Fixacions de fileres - S'utilitza per provar consultes que retornen un conjunt de valors.
- Fixtures d'acció - S'utilitza per executar proves per a una seqüència d'esdeveniments. Aquests esdeveniments poden ser com fer clic en un botó, comprovar els valors
Recomanació:
He intentat demostrar els conceptes perquè puguem començar a explorar més sobre FitNesse. També cal canviar la mentalitat del comprovador i ampliar-la. Hem de deixar de restringir-nos a mirar dins del codi. Jo sento; en última instància, estem provant el codi, per què no intentem veure el codi i provar-lo de tant en tant?
Comenceu a intensificar les vostres habilitats de programació i feu èmfasi més a construir la lògica i, més aviat, a aprendre la sintaxi. Quan hàgiu experimentat bé els conceptes de programació i tingueu pràctica en implementar-lo, explorar FitNesse serà més fàcil.
Conclusió
La prova en àgil es presenta en 4 sabors:
- Proves d'unitats automatitzades: mitjançant Junit
- Prova de verificació d’acceptació automatitzada: mitjançant FitNesse
- Proves automàtiques de IU / regressió: mitjançant Selenium o QTP
- Proves manuals
Hem d'intentar empènyer al màxim les nostres proves a la unitat i a la capa d'acceptació . Fins ara hem intentat mantenir la majoria de les proves de la capa d’interfície d’usuari mitjançant eines com QTP i Selenium, però el desavantatge és que aquestes funcionalitats no es podrien provar si no es desenvolupa la interfície d’usuari. En el moment en què trobeu un defecte, els desenvolupadors han passat a desenvolupar algunes altres funcions.
D'altra banda, si podem provar les API poc després d'haver estat escrites, els desenvolupadors poden solucionar-les a l'instant. Això també comportaria menys esforç quan provem la GUI. Com que es proven totes les funcionalitats, provar la interfície gràfica d’usuari es fa fàcil.
Amb Agile, la mentalitat dels verificadors també necessita un canvi i han de sortir del conjunt de proves de rutina i ara hauríeu de mirar el codi i provar d’identificar defectes, fins i tot la interfície d’usuari no està disponible.
Sobre l'autor: Aquest és un article de Shilpa C. Roy, membre de l'equip de STH. Ha estat treballant en el camp de proves de programari durant els darrers 9 anys en dominis com ara publicitat a Internet, banca d’inversions i telecomunicacions.
Feu-nos saber les vostres consultes als comentaris següents.
Lectura recomanada
- Els desenvolupadors no són bons verificadors. Què dius?
- Eina útil d’anotació i captura de pantalla gratuïta per als verificadors: revisió de qSnap
- Top 10 de les eines de revisió de codi més populars per a desenvolupadors i verificadors
- Revisió WebLOAD: Introducció a l'eina de proves de càrrega de WebLOAD
- Top 15 d'eines de prova SOA per a provadors
- Com mantenir la motivació viva als provadors de programari?
- Revisió de l'eina de gestió de proves TestLodge
- Habilitat suau per als provadors: com millorar la capacitat de comunicació