Disseny i realització de proves de programari

Les proves són necessàries en la fabricació de qualsevol producte industrial i en el desenvolupament de projectes informàtics.

Qui vendria una aspiradora sense estar segur que aspira correctament?

Qui vendria una ràdio digital sense haver comprovat que pot sintonitzar els canals?

De la mateixa manera, una aplicació informàtica no pot arribar a les mans de l'usuari final amb errors, i menys si aquests són visibles i clars com per haver sigut detectats pel desenvolupador. Es donaria la situació de falta de professionalitat i disminuïria la confiança per part dels usuaris, la qual cosa podria portar problemes per a futures oportunitats. Qualsevol membre de l'equip de treball d'un projecte informàtic pot cometre errors. Els errors, a més, es poden donar en qualsevol fase del projecte (anàlisi, disseny, codificació…). Alguns d'aquests errors seran més determinants que d'altres i tindran més o menys implicacions en el desenvolupament futur del projecte.

Les fases de desenvolupament d'un projecte són:

• Presa de requeriments.

• Anàlisi.

• Disseny.

• Desenvolupament.

• Proves.

• Finalització.

• Transferència.

Què és la realització de proves?

La realització de proves és una fase del desenvolupament d'un projecte de programari i és imprescindible realitzar-la abans de finalitzar el projecte i fer la transferència del projecte a l'usuari final.

Només faltaria que el projecte no funcionés tal com vol el client...

Consideracions

• Totes les fases establertes en el desenvolupament del programari són importants. Independentment, hauríem de considerar la fase de proves com una fase molt transcendent i donar-li molta més importància de la que a vegades se li dona.

• La falta o mala execució de qualsevol fase per part de qualsevol membre de l'equip de treball pot provocar que la resta del projecte arrossegui un o diversos errors que seran més o menys determinants per a l'èxit de l'empresa.

Tenint en compte les fases habituals en el desenvolupament de programari (presa de requeriments, anàlisi, disseny, desenvolupament, proves, finalització i transferència), els perfils habituals d'un equip de treball en un projecte de desenvolupament de programari són:

• Cap de projecte.

• Analista.

• Dissenyador.

• Programadors.

• Testejadors.

Possibles errors

Exemple 1:

El cap del projecte planifica malament les hores invertides en el disseny de les interfícies i al final resulta que el dissenyador n'inverteix més del doble.

Què passarà?

→ La repercussió en el projecte només serà a nivell de temps i cost. Pot ser que es pugui compensar en alguna tasca posterior.

Exemple 2:

El creador de la BD ha obviat un camp clau d'una taula principal i la seva vinculació amb una altra taula.

Què passarà?

→ Depèn de quan es detecti l'error pot ser que es pugui solucionar modificant algunes línies de codi o pot ser que calgui refer molta feina i hàgim treballat moltes hores per a res.

Hi ha estudis que demostren que un error no detectat al principi del desenvolupament d'un projecte pot arribar a necessitar 50 vegades més esforços per solucionar-lo que si s'hagués detectat a temps.

Validació

És l'activitat encarregada d'assegurar-se que l'aplicació informàtica obtinguda és la que s'havia determinat inicialment i és la que es volia construir.

La validació confirmarà que l'aplicació funciona tal com el client ha demanat.

El sistema fa el que el client vol?

Verificació

És l'activitat que comprova el funcionament correcte del codi programat. Es comprovarà que tecnològicament l'aplicació informàtica s'hagi desenvolupat de forma correcta.

El sistema fa el que ha de fer?

Consideracions

• Aquests conceptes estan directament relacionats amb les proves que verifiquen formalment la correcció d'una aplicació informàtica.

• Al llarg del projecte de desenvolupament del programari el sistema necessita ser verificat i validat en cada pas del procés, partint de la verificació i validació del pas anterior i establint la documentació adequada per poder tornar a validar i verificar en el pas següent.

En la següent imatge es poden observar les diferències entre el que demana l'usuari, el que es programa i el que es lliura a l'usuari, que al final és el que s'utilitzarà.

Classificació de les proves

• Proves unitàries: Es realitzen en el moment d'acabar cada mòdul.

• Proves de caixa negra.

• Proves de caixa blanca.

• Revisions.

Proves d'integració: Es realitzen en finalitzar tots els mòduls, quan es volen integrar.

• Proves d'integració ascendents.

• Proves d'integració descendents.

• Proves d'integració combinades.

• Proves d'integració de big bang.

Proves de càrrega: Es realitzen quan l'aplicació ja està acabada i integrada, i es posa en funcionament fent una càrrega de dades reals.

Proves d'acceptació: Si el client ja té l'aplicació i és ell mateix qui fa les proves.

Proves del sistema: Si es realitzen per validar la integració del programari en el sistema existent de l'usuari (rendiment/robustesa/resistència/seguretat/usabilitat).

Proves unitàries

Proves de caixa negra

• Fan la comprovació del funcionament d'un mòdul per mitjà de la seva interfície sense entrar a analitzar el funcionament intern.

• En cap moment s'està avaluant o accedint al codi. Només es poden veure les respostes de la funció per a múltiples opcions donades. Per comprovar si el mòdul comprova correctament s'hauran de fer proves introduint:

• Dades correctes.

• Dades errònies.

• Dades equivalents.

• Valors extrems superiors i inferiors.

Tècniques per establir el joc de proves:

• Classes d'equivalència. Triar casos de prova per a cada tipus o conjunts de dades d'entrada i sortida.

• Anàlisi dels valors límit.

• Estudi d'errors típics.

• Maneig de les interfícies gràfiques (finestres, botons, icones, etc…).

Avantatges:

• Són independents del llenguatge. Per tant, són vàlides per a tots els mètodes de programació utilitzats.

Proves de caixa blanca

Es fixen en com s'ha implementat una determinada codificació d'un mòdul o una aplicació. En aquestes proves s'examinen els detalls interns d'implementació del codi.

Per poder examinar l'interior del mòdul s'hauran de verificar aspectes com:

• Sentències, condicions, bucles, etc…

• Estructura del codi.

• Optimització del codi.

Tècniques per establir el joc de proves.

• Cobertura de flux de control. Es trobaria el diagrama de flux de control fent el camí invers al que es fa quan es programa i garanteix que, com a mínim, es passi una vegada per cada camí del programa. A partir del diagrama de flux s'haurien d'anar provant totes les possibilitats.

• Camí simple.

• Condicions.

• Bucles simples.

• Bucles niats.

Avantatges

• Si es segueixen tots els suggeriments per dissenyar els casos de prova per a cada element (camí simple, condicions, etc…) del codi programat s'aconseguirà un mínim de garanties d'eficàcia.

Revisions

Es basen en la inspecció directa del codi, ja sigui per mòduls o de manera completa. A diferència de les anteriors no posa a prova el codi en temps d'execució. Les revisions també són importants amb tasques vinculades al control de qualitat, validació i verificacions del sistema.

Es fa una revisió del codi de manera sistematitzada i seguint unes normes. En general ho fa el mateix programador.

Tècniques grupals:

• Reunions: La revisió la fan els mateixos desenvolupadors.

• Canals externs: La revisió la fan revisors experts.

• Inspeccions: La revisió la fan els desenvolupadors i revisors externs guiats per un moderador.

Avantatges.

• Documentació del codi.

• Separació de les interfícies gràfiques d'usuaris i la implementació del codi.

• Simplificació de la integració entre mòduls ja que serà menys probable que hi hagi errors en els mòduls independents.

Proves d'integració

Ascendents

Aquestes proves comencen combinant en grups les unitats o mòduls per anar provant-los. Es van provant diferents agrupacions per nivells i així successivament fins a arribar a integrar tots els nivells.

Per arribar a aquest objectiu es necessita dissenyar programes impulsors o controladors de proves que permetin simular el comportament dels mòduls superiors.

Aquests haurien de ser fàcils de construir perquè només tenen la mateixa interfície però no fan la mateixa funció.

La seva finalitat és poder executar el mòdul o grups de mòduls que s'estan provant.

Descendents

En primer lloc es proven els mòduls del nivell superior i després es van integrant els components de la capa o nivell inferior i així successivament.

En aquests casos, és necessari dissenyar mòduls ficticis, simuladors de proves que emulen el comportament i tenen la mateixa interfície que els reals. Són bastant més difícils de construir perquè necessitem fer la interfície i la funció de cada mòdul.

Combinada

Aquestes proves combinen la integració ascendent i descendent. Els mòduls individuals es proven tant amb els controladors com amb ficticis i després es van provant les capes inferiors i superiors substituint el controlador i ficticis pels mòduls que ja s'han provat. Habitualment en la integració combinada en els nivells superiors es fa ús d'una estratègia descendent i en els inferiors s'aplica una estratègia ascendent.

Big bang

En primer lloc es proven tots els mètodes individualment i després s'integren tots els components o mòduls del sistema i es fan les proves.

Tot i que és una estratègia bastant simple d'aplicar, té el desavantatge que quan es descobreix un error és molt difícil de localitzar i corregir.

Proves de càrrega

Objectius

Comprovar el rendiment i la integritat de l'aplicació acabada amb dades reals. Es tracta de simular l'entorn de programació de l'aplicació. Per curar-nos en salut i minimitzar possibles errors en la fase d'acceptació, quan el producte ha de ser utilitzat per un gran nombre de clients o usuaris finals es solen utilitzar les tècniques següents.

Proves alfa

Consisteixen a convidar els clients a provar el sistema en un entorn de desenvolupament. Pel fet d'estar en un entorn controlat, el client sempre té el suport d'un expert per ajudar-lo a utilitzar el sistema o analitzar resultats.

Proves beta

Es desenvolupen després de les anteriors en l'entorn del client. El client es troba sol amb el producte i tracta de trobar errors per informar els desenvolupadors.

Proves d'acceptació

Obtenir l'aprovació del client sobre la qualitat de funcionament del sistema desenvolupat i provat.

Proves del sistema

L'objectiu és validar l'aplicació quan ja l'ha acceptada l'usuari i integrat amb la resta del seu sistema.

Tipus de prova

• Proves de rendiment.

• Proves de resistència.

• Proves de robustesa.

• Proves de seguretat.

• Proves d'usabilitat.

• Proves d'instal·lació.

Proves de regressió

L'objectiu és detectar possibles nous errors o problemes que puguin sorgir en introduir canvis o millores en el programari. Vindrien a ser les típiques versions de la mateixa aplicació.

Proves de fum

Descriu la validació dels canvis de codi en el programari abans que els canvis en el codi es baixin a la documentació del projecte. Per això, abans d'executar les proves de fum es sol fer una revisió del codi.

Casos de prova

Els casos de prova defineixen com es duran a terme les proves, especificant entre d'altres:

el tipus de proves, les entrades de les proves, els resultats esperats o les condicions sota les quals s'haurien de desenvolupar.

Els casos de prova també segueixen un cicle de vida clàssic:

• Definició dels casos de prova.

• Creació dels casos de prova.

• Selecció dels valors per als tests.

• Execució dels casos de prova.

• Comparació dels resultats obtinguts amb els resultats esperats.

Procediments de prova

Els procediments de prova especifiquen com es podran dur a terme els casos de prova o part d'aquests de forma independent o de forma conjunta, establint les relacions entre ells i l'ordre en què s'hauran d'atendre.