ED_Tema03_Part_II PDF

Entorns de Desenvolupament TEMA 03 – PART II Disseny i realització de proves de programari 3. Procediments, tipus i casos de proves 3.2. Disseny de les proves. Tipus de proves  Curs E...

Entorns de Desenvolupament TEMA 03 – PART II Disseny i realització de proves de programari 3. Procediments, tipus i casos de proves 3.2. Disseny de les proves. Tipus de proves  Curs Entorns de Desenvolupament 24/25 1r CFGS DAM I E S D R. L L U Í S S I M A R R O 3.2 Disseny de les proves. Tipus de proves El disseny de les proves és el pas següent després d’haver dut a terme el pla de proves. Aquest disseny consistirà a establir els casos de prova, identificant, en cada cas, el tipus de prova que s’haurà d’efectuar. Existeixen molts tipus de proves: Estructurals o de caixa blanca Funcionals o de caixa negra D’integració De càrrega i acceptació De sistema i de seguretat De regressió i de fum Casos de prova i procediments A partir del pla de proves s’hauran especificat les parts de codi a tractar, en quin ordre caldrà fer les proves, qui les farà i molta informació més. Ara només falta entrar en detall, especificant el cas de prova per a cada una de les proves que cal fer.  Un cas de prova defineix com es portaran 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’hauran de desenvolupar. Els casos de proves tenen un objectiu molt marcat: identificar els errors que hi ha al programari per tal que aquests no arriben a l’usuari final. Aquests errors poden trobar- se com a defectes en la interfície d’usuari, en l’execució d’estructures de dades o un determinat requisit funcional. Tema 03 Disseny i realització de proves de programari – Part II Pàgina 2/14  Curs Entorns de Desenvolupament 24/25 1r CFGS DAM I E S D R. L L U Í S S I M A R R O A l’hora de dissenyar els casos de prova, no només s’ha de validar que l’aplicació fa el que s’espera davant entrades correctes, sinó que també s’ha de validar que tinga un comportament estable davant entrades no esperades, tot informant de l’error. Per desenvolupar i executar els casos de prova en un projecte informàtic, podem identificar dos enfocaments: Proves de caixa negra: El seu objectiu és validar que el codi compleix la funcionalitat definida. Proves de caixa blanca: Se centren en la implementació dels programes per escollir els casos de prova. En l’exemple que es mostra a continuació, s’ha implementat en Java un cas de prova que valida el cost d’una matricula. El mètode CasProva_CostMatricula calcularà el preu que haurà de pagar un alumne per matricular-se en diverses assignatures. La prova valida que el càlcul de l’operació coincidisca amb el resultat esperat, fent ús de la instrucció assertTrue. public static final int PREU_CREDIT = 100; //constant public void CasProva_CostMatricula(){ try { int credits = 0; float preu = 0; credits = CreditsAssignatura ("Sistemes informàtics"); //12 crèdits credits += CreditsAssignatura ("Programació"); //15 crèdits credits += CreditsAssignatura ("Accés a dades"); //12 crèdits preu = credits * PREU_CREDIT; //funció de la biblioteca Java JUnit, per fer tests de programari assertTrue (preu==3900); } catch (Exception e) { fail ("S’ha produït un error: el preu no és correcte"); //JUnit } } Tema 03 Disseny i realització de proves de programari – Part II Pàgina 3/14  Curs Entorns de Desenvolupament 24/25 1r CFGS DAM I E S D R. L L U Í S S I M A R R O D’aquesta manera, podem observar que els casos de prova ens permeten validar l’aplicació que s’està desenvolupant, sent necessari tenir accessible la documentació generada en l’anàlisi funcional i l’anàlisi tècnica, així com en el disseny (casos d’ús, diagrames de seqüència…). Els casos de prova 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. Cada cas de prova haurà de ser independent dels altres, tindrà un començament i un final molt marcat i haurà d’emmagatzemar tota la informació referent a la seua definició, creació, execució i validació final. Tot seguit s’indiquen algunes informacions que hauria de contemplar qualsevol cas de prova: ➔ Identificador del cas de prova. ➔ Mòdul o funció a provar. ➔ Descripció del cas de prova detallat. ➔ Entorn que s’haurà de complir abans de l’execució del cas de prova. ➔ Dades necessàries per al cas, especificant els seus valors. ➔ Tasques que executarà el pla de proves i la seua seqüència. ➔ Resultat esperat. ➔ Resultat obtingut. ➔ Observacions o comentaris després de l’execució. ➔ Responsable del cas de prova. ➔ Data d’execució. ➔ Estat (finalitzat, pendent, en procés). Tot cas de prova està associat, com a mínim, a un procediment de prova. Tema 03 Disseny i realització de proves de programari – Part II Pàgina 4/14  Curs Entorns de Desenvolupament 24/25 1r CFGS DAM I E S D R. L L U Í S S I M A R R O  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. Per exemple, es pot dissenyar un procediment de prova per inserir una nova assignatura en la matrícula d’un alumne; s’elaboren tots els passos necessaris de forma consecutiva per tal d’actualitzar la matrícula de l’alumne. No obstant això, l’assignatura pot ser obligatòria, optativa, amb unes incompatibilitats…; per tant, pel que fa al procediment de prova d’inserir la matrícula serà necessari associar un grup de casos de prova responsables de les diverses entrades de l’usuari. Figura 1. Casos de proves i procediments Tema 03 Disseny i realització de proves de programari – Part II Pàgina 5/14  Curs Entorns de Desenvolupament 24/25 1r CFGS DAM I E S D R. L L U Í S S I M A R R O A la figura.1 es pot observar un esquema explicatiu de les proves, des de la creació del pla de proves fins a la seua execució. Per a cada part del projecte caldrà crear un disseny de les proves, a partir del qual s’especificaran els casos de prova i els procediments de prova, que estan estretament lligats. Després dels procediments de prova, el darrer pas serà la seua execució. Tipus de proves Existeixen molts tipus de proves que han de cobrir les especificacions d’un projecte informàtic a través dels procediments i dels casos de prova. A continuació es presenta un resum d’aquests tipus de proves: A. Tipus de proves unitàries. Tenen les característiques següents: Són el tipus de proves de més baix nivell. Es duen a terme a mesura que es va desenvolupant el projecte. Les efectuen els mateixos programadors. Tenen com a objectiu la detecció d’errors en les dades, en els algorismes i en la lògica d’aquests. Les proves unitàries es podran dur a terme segons un enfocament estructural o segons un enfocament funcional. El mètode utilitzat en aquest tipus de proves és el de la caixa blanca o el de caixa negra. B. Tipus de proves funcionals. D’aquestes proves cal destacar: Són les encarregades de detectar els errors en la implementació dels requeriments d’usuari. Les duran a terme els verificadors i els analistes, és a dir, persones diferents a aquelles que han programat el codi. S’efectuen durant el desenvolupament del projecte. El tipus de mètode utilitzat és el funcional. Tema 03 Disseny i realització de proves de programari – Part II Pàgina 6/14  Curs Entorns de Desenvolupament 24/25 1r CFGS DAM I E S D R. L L U Í S S I M A R R O C. Tipus de proves d’integració. Les seues característiques són les següents: Es duran a terme posteriorment a les proves unitàries. També les efectuen els mateixos programadors. Es duen a terme durant el desenvolupament del projecte. S’encarreguen de detectar errors de les interfícies i en les relacions entre els components. El mètode utilitzat és el de caixa blanca, el de disseny descendent i el de bottom-up. D. Tipus de proves de sistemes. En destaca: La seua finalitat és detectar errors en l’assoliment dels requeriments. Les duran a terme els verificadors i els analistes, és a dir, persones diferents a aquelles que han programat el codi. S’efectuen en una fase de desenvolupament del programari. El tipus de mètode utilitzat és el funcional. E. Tipus de proves d’acceptació. Els aspectes més importants d’aquestes proves són els següents: El seu objectiu és la validació o acceptació de l’aplicació per part dels usuaris. És per això que les duran a terme els verificadors i els analistes, però també els clients, que seran els usuaris finals de les aplicacions. Aquestes proves es duran a terme una vegada finalitzada la fase de desenvolupament, i és possible fer-ho en la fase prèvia a la finalització i a la transferència o en la fase de producció, mentre els usuaris ja utilitzen l’aplicació. El tipus de mètode utilitzat també és el funcional. Tema 03 Disseny i realització de proves de programari – Part II Pàgina 7/14  Curs Entorns de Desenvolupament 24/25 1r CFGS DAM I E S D R. L L U Í S S I M A R R O Proves unitàries: enfocament estructural o de caixa blanca Les proves unitàries, també conegudes com a proves de components, són les proves que es faran a més baix nivell, sobre els mòduls o components més xicotets del codi font del projecte informàtic. Aquestes proves poden desenvolupar-se sota dos enfocaments: L’enfocament estructural (o proves de caixa blanca) és la part de les proves unitàries encarregades de l’estructura interna del codi font, des de qual s’analitzen tots els possibles camins. L’enfocament funcional (o proves de caixa negra) és la part de les proves unitàries encarregades del funcionament correcte de les funcionalitats del programari.  Les proves de caixa blanca se centren en la implementació dels programes per escollir els casos de prova. L’ideal seria cercar casos de prova que recorregueren tots els camins possibles del flux de control del programa. Aquestes proves se centren en l’estructura interna del programa, tot analitzant els camins d’execució. Figura 2. Estructura de les proves de caixa blanca Tema 03 Disseny i realització de proves de programari – Part II Pàgina 8/14  Curs Entorns de Desenvolupament 24/25 1r CFGS DAM I E S D R. L L U Í S S I M A R R O A la figura.2 es pot observar un esquema de l’estructura que tenen les proves de caixa blanca. A partir d’unes condicions d’entrada al mòdul o part de codi cal validar que, anant per la bifurcació que es vaja, s’obtindran les condicions desitjades d’eixida. Les proves de caixa blanca permetran recórrer tots els possibles camins del codi i veure què succeeix en cada cas possible. Es provarà què ocorre amb les condicions i els bucles que s’executen. Les proves es duran a terme amb dades que garantisquen que han tingut lloc totes les combinacions possibles. Per decidir quins valors hauran de prendre aquestes dades és necessari saber com s’ha desenvolupat el codi, procurant que no quede cap racó sense revisar. Partint del fet que les proves exhaustives són impracticables, ja que la quantitat de combinacions és excessiu, es dissenyen estratègies que oferisquen una seguretat acceptable per descobrir errors. Els mètodes que es veuran dintre de les proves de caixa blanca són el de cobertura de flux de control i el de complexitat ciclomàtica. Cobertura de flux de control El mètode de cobertura de flux de control consisteix a utilitzar l’estructura de control del programa per obtenir els casos de prova, que són dissenyats de manera que garantisquen que almenys es passa una vegada per cada camí del programa. Una possible tècnica per portar a terme aquest mètode consisteix a obtenir un diagrama de flux de control que represente el codi i provar tots els camins simples, totes les condicions i tots els bucles del programa. Es pot observar un exemple de diagrama de flux a la figura.3. Pot ser impossible cobrir-ne el 100% si el programa és molt complex, però podem tenir un mínim de garanties d’eficàcia si seguim els suggeriments per dissenyar els casos de prova fixant-nos en aquests elements: Tema 03 Disseny i realització de proves de programari – Part II Pàgina 9/14  Curs Entorns de Desenvolupament 24/25 1r CFGS DAM I E S D R. L L U Í S S I M A R R O ➔ Camí simple: s’ha de dissenyar un cas de prova per a cada camí independent, de manera que execute almenys una vegada cada sentència. Per a això és necessari determinar els possibles camins independents i preparar prou casos de prova per recórrer tots els camins. ➔ Condicions: s’han de dissenyar prou casos de prova per a totes les condicions del programa que s’avaluen a cert/fals. Si les condicions són múltiples, s’hauran de dividir en expressions simples (una per a cada operand lògic o comparació), de manera que s’ha de provar que es complisca o no cada part de cada condició. ➔ Bucles: s’han de dissenyar els casos de prova de manera que s’intente executar un bucle en diferents situacions límit. Per tal d’explicar el funcionament de les proves unitàries de caixa blanca es planteja l’exemple següent: public float LlistatAssignatures(ArrayList assignatures) { int comptador= 0; Iterator iter = assignatures.iterator(); while (iter.hasNext()) { Assignatura element = (Assignatura) iter.next(); if (element.getDisponible() == true) { System.out.println(element.getNom()); comptador = comptador + 1 } } return comptador; } Tema 03 Disseny i realització de proves de programari – Part II Pàgina 10/14  Curs Entorns de Desenvolupament 24/25 1r CFGS DAM I E S D R. L L U Í S S I M A R R O La funció LlistatAssignatures mostra, per pantalla, les assignatures que estan disponibles per tal que els alumnes es puguen matricular, i retorna un valor numèric corresponent al nombre d’assignatures disponibles. En la figura.3 es representen gràficament els nodes de la funció, cosa que facilita el càlcul de la complexitat ciclomàtica. Figura 3. Diagrama de flux del llistat d’assignatures. Tema 03 Disseny i realització de proves de programari – Part II Pàgina 11/14  Curs Entorns de Desenvolupament 24/25 1r CFGS DAM I E S D R. L L U Í S S I M A R R O Complexitat ciclomàtica L’estratègia de cobertura de flux de control requereix dissenyar casos de prova suficients per recórrer tota la lògica del programa. Es pot saber quants casos de prova cal crear i executar? Com es calcula? El matemàtic Thomas J. McCabe va anomenar complexitat ciclomàtica (CC) al nombre de camins independents d’un diagrama de flux, i va proposar la fórmula següent per calcular-la: Complexitat ciclomàtica = nombre de branques – nombre de nodes + 2 Aquest valor determina el nombre de proves que s’han de realitzar perquè s’execute cada sentència almenys una vegada. La complexitat ciclomàtica del graf de l’exemple anterior, el de la figura.3, proporciona el nombre màxim de camins linealment independents. Els nodes que intervenen són 1, 2, 3, 4, 5, 6 i 7, i les branques són les línies que uneixen els nodes, que són un total de 8. complexitat ciclomàtica CC = 8 – 7 + 2 = 3 Això significa que s’hauran de dissenyar tres casos de prova. Així, els tres recorreguts que s’haurien de tenir en compte són: Camí 1: 1 – 2 – 3 – 4 – 5 – 6 – 2 - 7 Camí 2: 1 – 2 – 3 – 4 – 6 – 2 - 7 Camí 3: 1 – 2 – 7 Tema 03 Disseny i realització de proves de programari – Part II Pàgina 12/14  Curs Entorns de Desenvolupament 24/25 1r CFGS DAM I E S D R. L L U Í S S I M A R R O Restarà generar les proves per recórrer els camins anteriors. A la figura.4 es mostren els valors del vector d’assignatures. Hi ha tres camins a recórrer. Per a cadascun d’ells serà necessari un vector amb unes característiques concretes: Per recórrer el camí 1 serà necessari un vector d’assignatures que continga com a mínim una assignatura que estiga disponible. Per recórrer el camí 2 serà necessari un vector d’assignatures que continga com a mínim una assignatura que no estiga disponible. Per recórrer el camí 3 serà necessari un vector d’assignatures buit. Figura 4. Valors del vector d’assignatures Tema 03 Disseny i realització de proves de programari – Part II Pàgina 13/14  Curs Entorns de Desenvolupament 24/25 1r CFGS DAM I E S D R. L L U Í S S I M A R R O D’aquesta manera, el resultats de les proves serien: Entrada (Assignatures1) ◦ Eixida esperada: 1 ◦ Eixida real: 1 ◦ Camí seguit: 1. Entrada (Assignatures2) ◦ Eixida esperada: 1 ◦ Eixida real: 1 ◦ Camí seguit: 2. Entrada (Assignatures3) ◦ Eixida esperada: 0 ◦ Eixida real: 0 ◦ Camí seguit: 3. Una vegada executat el joc de prova de caixa blanca, es pot afirmar que han estat superades satisfactòriament. Tema 03 Disseny i realització de proves de programari – Part II Pàgina 14/14