Entorns de desenvolupament - TEMA 03 - PDF

Entorns de Desenvolupament TEMA 03 – PART I Disseny i realització de proves de programari 1. Introducció 2. Les proves en el cicle de vida d’un projecte 3. Procediments, tipus i casos de proves 3.1. Planificació de les proves ...

Entorns de Desenvolupament TEMA 03 – PART I Disseny i realització de proves de programari 1. Introducció 2. Les proves en el cicle de vida d’un projecte 3. Procediments, tipus i casos de proves 3.1. Planificació de les 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 1. Introducció Les proves són necessàries en la fabricació de qualsevol producte industrial i, de forma anàloga, en el desenvolupament de projectes informàtics. Una aplicació informàtica no pot arribar a les mans d’un usuari final amb errades, i menys si aquestes són prou visibles i clares com per haver estat detectades pels desenvolupadors. Es donaria una situació de manca de professionalitat i reduiria la confiança per part dels usuaris, que podria minvar oportunitats futures. Quan cal dur a terme les proves? Què cal provar? Totes les fases establertes en el desenvolupament del programari són importants. La manca o mala execució d’alguna d’elles pot provocar que la resta del projecte arrossegue un o diversos errors que seran determinants per al seu l’èxit. Com més prompte es detecte un error, menys costós serà de solucionar. També seran molt importants les proves que es duran a terme una vegada el projecte estiga finalitzat. És per això que la fase de proves del desenvolupament d’un projecte de programari es considera bàsica abans de fer la transferència del projecte a l’usuari final. Qui donaria un cotxe per construït i finalitzat si en intentar arrencar-lo no funcionara? Qualsevol membre de l’equip de treball d’un projecte informàtic pot cometre errades. Les errades, a més, es podran donar a qualsevol de les fases del projecte (anàlisi, disseny, codificació, etc.). Algunes d’aquestes errades 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ó i transferència. Per exemple, un cap de projecte, a l’hora de planificar les tasques de l’equip, estipula el disseny de les interfícies en 4 hores de feina per a un únic dissenyador. Si, una Tema 03 Disseny i realització de proves de programari – Part I Pàgina 2/10  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 vegada executada aquesta tasca del projecte, la durada ha estat de 8 hores i s’han necessitat dos dissenyadors, la repercussió en el desenvolupament del projecte serà una desviació en temps i en cost, que potser es podrà compensar utilitzant menys recursos o menys temps en alguna tasca posterior. En canvi, si l’errada ha sigut del dissenyador de la base de dades, que ha obviat un camp clau d’una taula principal i la seua vinculació amb una segona taula, aquesta pot ser molt més determinant en les tasques posteriors. Si es creen les interfícies a partir d’aquesta base de dades errònia i es comença a desenvolupar el programari sense identificar l’errada, és possible que al cap d’unes quantes tasques es detecte l’errada i que, per tant, calga tornar al punt d’inici per solucionar-la. Un error no detectat a l’inici del desenvolupament d’un projecte pot arribar a necessitar cinquanta vegades més esforços per ser solucionat que si és detectat a temps. En un projecte de desenvolupament de programari està estipulat que es dedica entre un 20% i un 40% del cost de tot el projecte a la fase de proves. Amb aquesta dada ens podem adonar de la importància de les proves dins un projecte. Els resultats de les proves podran influir en la percepció que tindrà el client final en relació amb el producte (programari) lliurat i la seua qualitat. Precisament, és l’objectiu d’aquestes proves: l’avaluació de la qualitat del programari desenvolupat durant tot el seu cicle de vida, validant que fa el que ha de fer i que ho fa tal com es va dissenyar, a partir dels requeriments. Tema 03 Disseny i realització de proves de programari – Part I Pàgina 3/10  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 2. Les proves en el cicle de vida d’un projecte A cada una de les fases del cicle de vida d’un projecte, caldrà que el treball dut a terme siga validat i verificat. En l’esquema de la figura.1 podem veure com encaixen les proves en el cicle de vida del programari. Figura 1. Cicle de vida en V: fases de prova Alhora que s’avança en el desenvolupament del programari es van planificant les proves que es faran a cada fase del projecte. Aquesta planificació es concretarà en un pla de proves que s’aplicarà a cada producte desenvolupat. Quan es detecten errors en un producte s’ha de tornar a la fase anterior per depurar-lo i corregir-lo; això s’indica amb les fletxes de tornada de la part esquerra de la figura.  Els depuradors (debuggers) són unes aplicacions o eines permeten l’execució controlada d’un programa o un codi, seguint el comandament executat i localitzant els errors (bugs) que puguen contenir. Tema 03 Disseny i realització de proves de programari – Part I Pàgina 4/10  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 Hi ha eines CASE que ajuden a dur a terme aquests processos de prova; concretament, es coneixen com a depuradors els encarregats de depurar errors en els programes. Com es pot observar a la figura.1, el procés de verificació cobrirà les fases de disseny i implementació del producte. Les persones implicades en la seua execució seran els desenvolupadors o programadors i l’enginyer de proves. Els desenvolupadors faran proves sobre el codi i els diferents mòduls que l’integren, i l’enginyer, sobre el disseny del sistema. Validació és el terme que es fa servir per avaluar positivament si el producte desenvolupat compleix els requisits establerts en l’anàlisi. Les persones encarregades de fer les proves de validació són els enginyers de proves. La verificació del programari garanteix que "s’ha creat bé" i confirma que el producte, tal com es disposa, compleix els plans dels desenvolupadors. La validació del programari assegura que "s’ha creat el que es demanava" i confirma que el producte, tal com es disposa, compleix l'ús i els objectius previstos del client. Finalment, el client ha de donar el vistiplau al producte, raó per la qual es faran les proves d’acceptació en funció de les condicions que es van signar al principi del contracte. 3. Procediments, tipus i casos de proves En cada una de les fases d’un projecte s’haurà de dedicar un temps considerable a desenvolupar les tasques i els procediments referents a les proves. És per això que alguns autors consideren que els procediments relacionats amb les proves són com un xicotet projecte englobat dins el projecte de desenvolupament. Tema 03 Disseny i realització de proves de programari – Part I Pàgina 5/10  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 Aquest projecte de proves requerirà d’una planificació, un disseny del pla de proves, una execució de les mateixes i una avaluació dels resultats, per tal d’analitzar els errors i poder aplicar les accions necessàries. A la figura.2 es mostra un esquema amb els procediments que caldrà dur a terme i la documentació que s’haurà d’adjuntar. Aquest esquema servirà com a índex per a aquest apartat. Figura 2. Procés de proves L’esquema s’inicia amb una planificació de les proves, que té com a punt de partida l’anàlisi funcional, diagrames de casos d’ús… del producte a desenvolupar. En la planificació s’estimaran els recursos necessaris per a l’elaboració de les proves i la posterior validació del programari, i s’obtindrà un pla de proves com a eixida. Tema 03 Disseny i realització de proves de programari – Part I Pàgina 6/10  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 Partint del pla de proves i del codi font que s’haja desenvolupat, es durà a terme el disseny de les proves identificant quin tipus de proves s’efectuarà per a cada una de les funcionalitats, i s’obtindran, com a eixida, els casos de prova i procediments. A partir d’aquest moment, es crea un bucle on s’executaran les proves, s’avaluaran els resultats de les proves efectuades detectant els errors, es depurarà el codi aplicant les correccions pertinents i es tornaran a executar les proves. En finalitzar el bucle, es farà l’anàlisi de l’estadística d’errors. Aquesta anàlisi permetrà fer prediccions de la fiabilitat del programari, així com detectar les causes més habituals d’error, amb la qual cosa es podran millorar els processos de desenvolupament. 3.1 Planificació de les proves La planificació de les proves és una tasca que cal anar desenvolupant al llarg de totes les fases del projecte informàtic. No cal esperar la fase de programació per crear aquest pla de proves; a la fase d’anàlisi i a la fase de disseny ja es tenen prou dades per tal de poder començar a establir les primeres línies del pla de proves. És important tenir present que, com més prompte es detecte una errada al projecte informàtic, més fàcil serà contrarestar i solucionar aquest error. El cost de la resolució d’un problema creix exponencialment a mesura que avancen les fases del projecte en les quals es detecte. Però, com succeeix en molts aspectes de la vida, una cosa és la teoria i una altra de molt diferent la realitat. En moltes consultories especialitzades en desenvolupament del programari, així com en altres empreses més xicotetes o, fins i tot, per part de programadors independents que creen el seu propi programari, es consideren les proves com un procés que es tracta al final del projecte, una vegada la major part del codi ha estat desenvolupat. Tema 03 Disseny i realització de proves de programari – Part I Pàgina 7/10  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 planificació de les proves té com a objectiu arribar a la creació d’un pla d’actuació que es referisca a quan i com es duran a terme les proves. Però per a això cal dur a terme una anàlisi minuciosa del sistema i dels seus elements. El pla de proves ha de contenir totes les funcions, les estratègies, les tècniques i els membres de l’equip de treball implicats. Una bona guia inicial per determinar què contindrà un bon pla de proves es pot obtenir de la normativa IEEE 829-2008 “Standard for Software and System Test Documentation”. Aquest estàndard estableix com haurà de ser la documentació i els procediments que s’utilitzaran en les diferents etapes de les proves del programari. Més endavant aquest document va ser substituït per l’estàndard ISO/IEC/IEEE 29119: Enginyeria de programari i sistemes: proves de programari, que consisteix en una sèrie de cinc estàndards internacionals per a les proves de programari. El seu objectiu era unificar i integrar la literatura normativa sobre les proves que oferien diferents creadors d’estàndards. Part 1: Conceptes i definicions (2013) Part 2: Model de processos de prova (2013) Part 3: Documentació de la prova (2013) Part 4: Tècniques de prova (2015) Part 5: Proves dirigides per paraules clau (2016) En general, alguns dels continguts que ha de tenir el pla de proves són: Identificador del pla de proves. És l’identificador que s’assignarà al pla de proves. És important per poder identificar fàcilment quin abast té el pla de proves. Per exemple, si es volen verificar les interfícies i procediments relacionats amb la gestió de clients, el seu pla de proves es podria dir PlaClients. Descripció del pla de proves. Defineix l’abast del pla de proves, el tipus de prova i les seues propietats, així com els elements del programari que es volen provar. Tema 03 Disseny i realització de proves de programari – Part I Pàgina 8/10  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 Elements del programari a provar. Determina els elements del programari que s’han de tenir en compte en el pla de proves, així com les condicions mínimes que s’han de complir per dur-ho terme. Elements del programari que no s’han de provar. També és important definir els elements que no s’hauran de tenir en compte al pla de proves. Estratègia del pla de proves. Defineix la tècnica a utilitzar en el disseny dels casos de prova, com per exemple la tècnica de caixa blanca o de caixa negra, així com les eines que s’utilitzaran o, fins i tot, el grau d’automatització de les proves. Definició de la configuració del pla de proves. Defineix les circumstàncies sota les quals el pla de proves podrà ser alterat, finalitzat, suspès o repetit. Quan s’efectuen les proves, s’haurà de determinar quin és el punt que provoca que se suspenguen, ja que no tindria molt de sentit continuar provant el programari quan aquest es troba en un estat inestable. Una vegada els errors han sigut corregits, es podrà continuar efectuant les proves; és possible que s’inicien des del principi del pla o des d’una determinada prova. Finalment, es podrà determinar la finalització de les proves si aquestes han superat un determinat llindar. Documents a lliurar. Defineix els documents que cal lliurar durant el pla de proves i en finalitzar-lo. Aquesta documentació ha de contenir la informació referent a l’èxit o fracàs de les proves executades amb tot tipus de detall. Alguns d’aquests documents poden ser: resultats dels casos de proves, especificació de les proves, subplans de proves… Tasques especials. Defineix les taques necessàries per preparar i executar les proves. Però hi ha algunes tasques que tindran un caràcter especial, per la seua importància o per la seua dependència amb d’altres. Per a aquest tipus de tasques, serà necessari efectuar una planificació més detallada i determinar sota quines condicions es duran a terme. Tema 03 Disseny i realització de proves de programari – Part I Pàgina 9/10  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 Recursos. Per a cada tasca definida dins el pla de proves, s’haurà d’assignar un o diversos recursos, que seran els encarregats de dur-la a terme. Responsables i Responsabilitats. Es defineix el responsable de cadascuna de les tasques previstes en el pla. Calendari del pla de proves. En el calendari queden descrites les tasques que s’hauran d’executar, indicant les seues dependències, els responsables, les dates d’actuació i la durada, així com les fites del pla de proves. Una eina molt utilitzada per representar aquest calendari del pla de proves és el Diagrama de Gantt. Un error típic és tractar la planificació de proves com una activitat puntual, limitada al període de temps en què s’elabora una llista d’accions per ser desenvolupades durant els propers dies, mesos… La planificació és un procés continu i no puntual; per tant, cal treballar-lo al llarg de tot el projecte, i per a això és necessari: ➔ Gestionar els canvis: no és d’estranyar que, al llarg del cicle de vida del projecte, i amb major probabilitat quan més llarga és la seua durada, es presenten canvis en l’abast del projecte. Serà necessari adaptar el pla de proves a les noves especificacions. ➔ Gestionar els riscos: un risc es podria definir com un conjunt de situacions que poden provocar un impediment o retard en el pla de proves. Els riscos s’hauran d’identificar al més prompte possible i analitzar la probabilitat que hi ha que succeïsquen, tot aplicant mesures preventives, si es considera oportú, o disposar d’un pla de contingència en cas que el risc sorgira. Es pot afirmar que tota planificació ha de ser viva i s’ha d’anar revisant i controlant de forma periòdica. En cas de desviació, s’han d’analitzar les causes que l’han provocat i com afecta a la resta dels projectes. Tema 03 Disseny i realització de proves de programari – Part I Pàgina 10/10  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  Entorns de Desenvolupament TEMA 03 – PART III 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 Proves unitàries: enfocament funcional o proves de caixa negra L’enfocament estructural o les proves de caixa blanca, dins les proves unitàries, serveix per analitzar el codi en totes les seues estructures, en tots els seus camins del programari. Però existeix un altre tipus de proves que es basa en un enfocament més funcional, anomenades proves de caixa negra.  Les proves de caixa negra proven la funcionalitat del programa, per al qual es dissenyen casos de prova que comproven les especificacions del programa. Les tècniques de prova de caixa negra pretenen trobar errors en funcions incorrectes o absents, errors d’interfície, errors de rendiment, inicialització i finalització. Se centra en les funcions i en les seues entrades i eixides. A la figura.1 es pot observar un esquema de l’estructura que tenen les proves de caixa blanca. Figura 1. Estructura de les proves de caixa negra Tema 03 Disseny i realització de proves de programari – Part III Pàgina 2/23  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 Caldrà escollir amb compte els casos de prova, de manera que siguen tan pocs com siga possible per tal que la prova es puga executar en un temps raonable i, al mateix temps, que cobrisquen la varietat d’entrades i eixides més àmplia possible. Per aconseguir-ho, s’han dissenyat diferents tècniques: A. Classes d’equivalència: es tracta de determinar els diferents tipus d’entrada i eixida, agrupar-los i escollir casos de prova per a cada tipus o conjunt de dades d’entrada i eixida. B. Anàlisi dels valors límit: estudien els valors inicials i finals, ja que estadísticament s’ha demostrat que tenen més tendència a detectar errors. C. Estudi d’errors típics: l’experiència diu que hi ha una sèrie d’errors que s’acostumen a repetir en molts programes; per això, es tractaria de dissenyar casos de prova que provocaren les situacions típiques d’aquest tipus d’errors. D. Maneig d’interfície gràfica: per provar el funcionament de les interfícies gràfiques, s’han de dissenyar casos de prova que permeten descobrir errors en el maneig de finestres, botons, icones, etc. E. Dades aleatòries: es tracta d’utilitzar una eina que automatitze les proves i que genere d’una manera aleatòria els casos de prova. Aquesta tècnica no optimitza l’elecció dels casos de prova, però si es fa durant prou temps amb moltes dades, podrà arribar a fer una prova prou completa. Aquesta tècnica es podria utilitzar com a complementària a les anteriors o en casos en què no siga possible aplicar-ne cap altra. Un avantatge de les proves de caixa negra és que són independents del llenguatge o paradigma de programació utilitzat, de manera que són vàlides tant per a programació estructurada com per a programació orientada a objectes. Tema 03 Disseny i realització de proves de programari – Part III Pàgina 3/23  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. Classes d’equivalència S’han de dissenyar els casos de prova de manera que proven la major funcionalitat possible del programa, però que no incloguen massa valors. Per on començar? Quins valors s’han d’escollir? Cal seguir els passos següents: 1. Identificar les condicions, restriccions o continguts de les entrades i les eixides. 2. Identificar, a partir de les condicions, les classes d’equivalència de les entrades i les eixides. Per identificar-ne les classes, el mètode proposa algunes recomanacions: ◦ Cada element de classe ha de ser tractat de la mateixa manera pel programa, però cada classe ha de ser tractada de manera diferent en relació amb una altra classe. Això assegura que n’hi ha prou de provar algun element d’una classe per comprovar que el programa funciona correctament per a aquesta classe, i també garanteix que cobrim diferents tipus de dades d’entrada amb cadascuna de les classes. ◦ Les classes han de recollir tant dades vàlides com errònies, ja que el programa ha d’estar preparat i no bloquejar-se sota cap circumstància. ◦ Si s’especifica un rang de valors per a les dades d’entrada, per exemple, si s’admet del 10 al 50, es crearà una classe vàlida (10 ≤ X ≤ 50) i dues classes no vàlides, una per als valors superiors (X > 50) i l’altra per als inferiors (X < 10). ◦ Si s’especifica un valor vàlid d’entrada i d’altres de no vàlids, per exemple, si l’entrada comença amb majúscula, es crea una classe vàlida (amb la primera lletra majúscula) i una altra de no vàlida (amb la primera lletra minúscula). ◦ Si s’especifica una quantitat de valors d’entrada, per exemple, si s’han d’introduir tres nombres seguits, es crearà una classe vàlida (amb tres valors) i dues de no vàlides (una amb menys de dos valors i l’altra amb més de tres Tema 03 Disseny i realització de proves de programari – Part III Pàgina 4/23  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 valors). ◦ Si hi ha un conjunt de dades d’entrada concretes vàlides, es generarà una classe per cada valor vàlid (per exemple, si l’entrada ha de ser roig, taronja, verd, es generaran tres classes) i una altra per un valor no vàlid (per exemple, blau). ◦ Si no s’han recollit ja amb les classes anteriors, s’ha de seleccionar una classe per cada possible classe de resultat. 3. Crear els casos de prova a partir de les classes d’equivalència detectades. Per a això s’han de seguir els passos següents: ◦ Escollir un valor que represente cada classe d’equivalència. ◦ Dissenyar casos de prova que incloguen els valors de totes les classes d’equivalència identificades. L’experiència prèvia de l’equip de proves pot ajudar a escollir els casos que més probabilitats tenen de trobar errors. Per exemple, es volen definir les proves de caixa negra per a una funció que retorna el nom del mes a partir del seu valor numèric. String nom; nom = NomDelMes(3); El valor del nom serà Març. Caldrà identificar tres classes d’equivalències, com es pot observar a la figura.2:..., -02, -01, 00 valors invàlids 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12 valors vàlids 13, 14, 15,... valors invàlids. Tema 03 Disseny i realització de proves de programari – Part III Pàgina 5/23  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 Figura 2. Exemple de caixa negra B,C. Anàlisi de valors límit i errors típics Hi ha tècniques que serveixen per seleccionar millor les classes d’equivalència. Una és l’anàlisi dels valors límit. S’ha pogut demostrar que els casos de prova que se centren en els valors límit produeixen un millor resultat per a la detecció de defectes. D’aquesta manera, en escollir l’element representatiu de la classe d’equivalència, en lloc d’agafar-ne un qualsevol, s’escullen els valors al límit i, si es considera oportú, un valor intermedi. A més a més, també s’intenta que els valors a l’entrada provoquen valors límit als resultats. A l’hora d’escollir els representants de cada classe se seguiran les recomanacions següents: Tema 03 Disseny i realització de proves de programari – Part III Pàgina 6/23  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 En els rangs de valors, agafar els extrems del rang i el valor intermedi. Si s’especifiquen una sèrie de valors, agafar el superior, l’inferior, l’anterior a l’inferior i el posterior al superior. Si el resultat es mou en un determinat rang, hem d’escollir dades a l’entrada per provocar les eixides mínima, màxima i un valor intermedi. Si el programa tria una llista o taula, agafar l’element primer, l’últim i l’intermedi. També es pot aprofitar l’experiència prèvia. Hi ha una sèrie d’errors que es repeteixen molt en els programes, i podria ser una bona estratègia utilitzar casos de prova que se centren a buscar aquests errors. D’aquesta manera, es millorarà l’elecció dels representants de les classes d’equivalència: El valor zero sol provocar errors, per exemple, una divisió per zero bloqueja el programa. Si es té la possibilitat d’introduir zeros a l’entrada, s’ha d’escollir en els casos de prova. Quan s’ha d’introduir una llista de valors, caldrà centrar-se en la possibilitat de no introduir cap valor, o introduir-ne un. S’ha de pensar que l’usuari pot introduir entrades que no són normals, per això és recomanable posar-se en el pitjor cas. Els desbordaments de memòria són habituals, per això s’ha de provar d’introduir valors tan grans com siga possible. Exemple de prova de caixa negra Tot seguit es mostra un exemple de prova de caixa negra. S’ha de dur a terme el procés de prova del següent procediment: Funció Buscar (DNI as string, vectMatricula de Matricules) retorna Matricula Tema 03 Disseny i realització de proves de programari – Part III Pàgina 7/23  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 En concret, en aquesta funció se li proporciona un string que representa el DNI de l’alumne, i un vector anomenat vectMatricula que emmagatzema les matrícules dels alumnes. La funció busca en el vector vectMatricula la matrícula de l’alumne. La funció retorna la matrícula de l’alumne si la troba o una matrícula buida si no la troba. Per tal de simplificar el joc de proves, el nombre de matrícules que admet la funció Buscar és 10. Per a la variable DNI hem de tenir en consideració que està formada de huit xifres numèriques i una lletra (en aquest exercici no es valida el valor de la lletra): 00000001A Prova vàlida. Null Prova invàlida, el DNI no té valor. 00000001 Prova invàlida, el DNI té un format incorrecte, falta la lletra. 00000001AA Prova invàlida, el DNI té un format incorrecte. AAAAAAAAA Prova invàlida, el DNI té un format incorrecte. Pel vector vectMatricula hem de tenir en consideració que pot contenir de 0 a 10 matrícules: []. Prova vàlida, vector buit. [matrícula1]. Prova vàlida, vector amb una matrícula. [matrícula1, matrícula2, matrícula3, … matrícula10]. Prova vàlida, vector amb un nombre de matrícules entre 0 i 10. [matrícula1, matrícula2, matrícula3, … matrícula10, matrícula11]. Prova invàlida, vector amb un nombre de matrícules superior a 10. Per a l'eixida: Tema 03 Disseny i realització de proves de programari – Part III Pàgina 8/23  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 Alumne.DNI = DNI. Prova vàlida. Classe amb les dades d’un alumne. Classe buida. Prova vàlida. S’ha buscat el DNI d’una persona que no és alumne. Alumne.DNI DNI. Prova invàlida. Classe amb les dades d’un altre alumne. Classe buida. Prova invàlida. S’ha buscat el DNI d’un alumne i no s’ha trobat. D. Ús d’interfície gràfica No només s’ha de parlar d’entrades de textos, també cal tenir en compte els entorns gràfics on es duen a terme les entrades de valors o on es visualitzen els resultats. Actualment, la majoria de programes solen interactuar amb l’usuari fent ús de sistemes gràfics que cada vegada són més complexos, amb la qual cosa es poden generar errors. Les proves d’interfície gràfica d’usuari han d’incloure: Proves sobre finestres: icones de tancar, minimitzar… Proves sobre menús i ús de ratolí. Proves d’entrada de dades: quadre de textos, llistes desplegables… Proves de documentació i ajuda del programa. Altres. A la figura.3 es mostra una finestra que controla l’accés al sistema de matriculació dels alumnes mitjançant la introducció d’un nom d’usuari i una clau (password). El sistema comprova si hi ha un compte amb el nom i clau especificat i, si és així, es dóna permís per entrar. Si hi ha un compte amb aquest nom i la clau és incorrecta, permet tornar a introduir la clau fins a un màxim de tres vegades. Tema 03 Disseny i realització de proves de programari – Part III Pàgina 9/23  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 Figura 3. Pantalla per al control d’entrada de l’identificador de l’alumne i de la clau per poder efectuar la matrícula Tot seguit es mostren alguns dels casos de prova que es podrien utilitzar amb aquest programa: Cas de prova 1: ➔ Entrada: usuari correcte i contrasenya correcta. Prémer botó d’accedir al sistema. ➔ Condicions d’execució: en la taula existeix aquest usuari amb la contrasenya i amb un intent fallat (nombre inferior a 3). ➔ Resultat esperat: donar accés al sistema i reflectir que el nombre d’intents per a l’usuari correcte és zero en la taula USUARI (compte, contrasenya, nre. Intents). Cas de prova 2: ➔ Entrada: usuari incorrecte i contrasenya correcta. Prémer botó d’accedir al sistema. ➔ Condicions d’execució: en la taula no existeix aquest usuari amb aquesta contrasenya. ➔ Resultat esperat: no donar accés al sistema. Tema 03 Disseny i realització de proves de programari – Part III Pàgina 10/23  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 Cas de prova 3: ➔ Entrada: usuari correcte i contrasenya incorrecta. Prémer botó d’accedir al sistema. ➔ Condicions d’execució: en la taula existeix aquest usuari però no amb aquesta contrasenya. ➔ Resultat esperat: no donar accés al sistema. Proves d’integració Són suficients les proves que es fan a cada part d’una aplicació per assegurar-nos que s’ha validat el funcionament del programari? La resposta és no; és necessari validar també els diferents mòduls combinats. Una vegada s’han provat els components individuals del programa i s’ha garantit que no contenen errors, caldrà integrar-los per tal de crear un sistema complet que també haurà de ser provat. Aquest és el nivell de les proves d’integració.  Un objectiu important de les proves d’integració és localitzar errors en les interfícies entre les diferents unitats. A més, les proves d’integració serveixen per validar que les parts de codi que ja han estat provades de forma independent continuen funcionant correctament en ser integrades. Els elements no s’integren tots al mateix temps, sinó que s’utilitzen diferents estratègies d’integració incremental, que, bàsicament, consisteixen en el que es mostra en el flux de la figura.4. Tema 03 Disseny i realització de proves de programari – Part III Pàgina 11/23  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 Figura 4. Esquema d’integració incremental Amb aquest procés es facilita la localització de l’error quan es produïsca, perquè se sap quins són els últims mòduls que s’han integrat i quan s’ha produït l’error. L’organització clàssica dels mòduls és una estructura jeràrquica organitzada per nivells: a la part alta hi haurà el mòdul o mòduls principals (a vegades denominats pares), que fan crides a mòduls subordinats de nivell inferior (fills), i així successivament cada nivell utilitzarà mòduls de nivell inferior fins arribar als mòduls terminals. Els mòduls superiors seran els més propers a l’usuari, és a dir, inclouen la interfície d’usuari (entorn gràfic, menús, ajudes…), i els mòduls inferiors són els més propers a l’estructura física de l’aplicació (bases de dades, maquinari…). Existeixen diferents estratègies de desenvolupament de proves d’integració, com són les proves d’integració ascendent i les proves d’integració incrementals descendents. Prova d’integració ascendent Aquesta estratègia de desenvolupament de les proves d’integració començarà pels mòduls finals, els mòduls de més baix nivell, agrupant-los per les seues Tema 03 Disseny i realització de proves de programari – Part III Pàgina 12/23  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 funcionalitats. Es crearà un mòdul impulsor que anirà efectuant crides als diferents mòduls a partir de les precondicions indicades i recollint els resultats de cada crida a cada funció. A mesura que els resultats d’aquestes proves vagen eixint positius, s’anirà escalant per l’arbre de jerarquies amb el mòdul impulsor cap als altres mòduls, fent les crides pertinents de forma recursiva. La darrera prova serà una crida al programari sencer amb els valors d’entrada reals (analitzant els valors també reals de eixida). A continuació, es descriu el procés seguit per un sistema d’informació que té una estructura com la que es mostra en la figura.5: Figura 5. Esquema de proves d’integració ascendents A la figura.6 es pot observar la primera fase de les proves d’integració ascendents. Tema 03 Disseny i realització de proves de programari – Part III Pàgina 13/23  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 Cada mòdul ha de ser provat per separat, per això s’ha de construir un mòdul impulsor independent per provar cada mòdul. Figura 6. Integració incremental ascendent, fase 1 La figura.7 mostra la següent fase, una vegada finalitzades les proves sobre els mòduls de nivell més baix, els mòduls (07, 08, 12, 13, 14 i 11). El següent pas és continuar amb els mòduls del següent nivell. Però això implica crear nous mòduls impulsors (04, 09, 10 i 06), que s’aplicaran a aquests mòduls, els quals s’integraran amb els mòduls de nivell més baix anteriorment provats (07, 08, 12, 13, 14 i 11). Figura 7. Integració incremental ascendent, fase 2 La figura.8 mostra un nivell més de l’estratègia, arribant als mòduls 02, 05 i 03. Tema 03 Disseny i realització de proves de programari – Part III Pàgina 14/23  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 Figura 8. Integració incremental ascendent, fase 3 A la figura.9 es veu la integració dels mòduls 04 i 05 amb el mòdul 02, per al qual s’haurà de crear l’impulsor 02, que cridarà a aquest mòdul. Tema 03 Disseny i realització de proves de programari – Part III Pàgina 15/23  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 Figura 9. Integració incremental ascendent, fase 4 A la figura.10 es veu com s’arriba al final d’aquest exemple d’integració incremental ascendent, fins al mòdul 01, que integra els mòduls 02 i 03. També caldrà crear un impulsor 01 per a la crida d’aquest mòdul. Figura 10. Integració incremental ascendent, fase 5 Adaptant l’exemple que es va tractant en els punts anteriors a les proves d’integració, si es volgueren efectuar les proves del procés de matriculació dels alumnes en un centre universitari, es podria començar pels mòduls que fan canvis en la base de dades on s’emmagatzema la informació. Una vegada que cada un d’aquests mòduls funciona correctament, s’inicien les proves dels mòduls de nivell superior, que bàsicament Tema 03 Disseny i realització de proves de programari – Part III Pàgina 16/23  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 fan crides a aquests mòduls de nivell més baix (mòduls que podrien tenir la lògica de negoci). De forma progressiva, s’aniran incorporant nous mòduls fins a provar tot el sistema. Avantatges de la integració incremental ascendent Els avantatges són els següents: Ordre adequat: primer s’avaluen els mòduls inferiors, que són els que acostumen a tenir el processament més complex, se’n solucionen els errors, i després es nodreix de dades la resta del sistema. Més senzillesa: les entrades per a les proves són més fàcils de crear, ja que els mòduls inferiors solen tenir funcions més específiques. Millor observació dels resultats de les proves : com que es comença pels mòduls inferiors, és més fàcil l’observació dels resultats de les proves. Desavantatges de la integració incremental ascendent Entre els desavantatges, cal destacar: Anàlisi parcial: fins que no es fa la crida al darrer mòdul no es valida el sistema com a tal. Alt temps de dedicació: caldrà dedicar molt de temps a implementar cada mòdul impulsor, que poden arribar a ser molts. Prova d’integració incremental descendent Aquesta estratègia de desenvolupament de les proves d’integració començarà pel mòdul de control principal (el més important, el de més nivell). Una vegada validat, Tema 03 Disseny i realització de proves de programari – Part III Pàgina 17/23  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 s’aniran integrant els altres mòduls que en depenen de forma progressiva, sense seguir una estratègia concreta, només tenint en compte que el nou mòdul incorporat a les proves tindrà ja validats tots els mòduls que el referencien. En funció del tipus de mòduls i del tipus de projecte, s’escollirà una seqüència o una altra a l’hora d’anar integrant mòduls, analitzant el problema concret. Les etapes de la integració descendent són: Se selecciona el mòdul més important, el de major nivell. Aquest mòdul farà d’impulsor. Caldrà escriure altres mòduls ficticis que simulen els mòduls que cridarà el principal. A mesura que es van integrant mòduls, caldrà provar-los independentment i de forma conjunta amb els altres mòduls ja provats. Una vegada s’ha finalitzat la prova, se substitueix el mòdul fictici creat pel real que s’ha integrat. Aleshores caldrà escriure els mòduls ficticis subordinats que es necessiten per a la prova del nou mòdul incorporat. Els mòduls subordinats al mòdul de control principal es van incorporant a l'estructura, bé de forma primer en profunditat, o bé de forma primer en amplària.  Integració primer en profunditat: (Depth-first) integra tots els mòduls d'un camí de control principal de l'estructura. Figura 11. Esquema de prova Tema 03 Disseny i realització de proves de programari – Part III Pàgina 18/23  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 Per exemple, si es tria el camí de l'esquerra s'integraran primer els mòduls M01, M02 i M04. A continuació, s'integrarà M05, després M03 i finalment M06  Integració primer en amplada (Breadth-First): incorpora tots els mòduls directament subordinats a cada nivell, movent-se per l'estructura de forma horitzontal. Per exemple: Els primers mòduls que s'integren són M01, M02 i M03. A continuació, M04, M05, i finalment M06. Si hi ha algun mòdul que encara no s’ha implementat, però és necessari per a provar la integració d’altres mòduls, s’utilitzen stubs, que són mòduls de "mentida" o ficticis que imiten el comportament de mòduls encara no implementats (implementen la seua interfície). Anem a veure tot seguit l’exemple de proves d’integració descendent en profunditat de l’esquema de la figura 11 pas a pas. En primer lloc s’ha de provar el mòdul de més alt nivell (Mòdul 01), i els mòduls inferiors s’han de simular amb mòduls ficticis (stubs). Figura 12. Prova d’integració incremental descendent del mòdul 01 Com que la integració és descendent en profunditat, si la prova del mòdul 01ha sigut satisfactòria, se seguira provant el Mòdul 02, incorporant els stubs necessaris per suplantar els que encara no s’han implementat (o provat). Tema 03 Disseny i realització de proves de programari – Part III Pàgina 19/23  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 Figura 12. Prova d’integració incremental descendent del mòdul 02 Després continuarem pel Mòdul 04. Figura 13. Prova d’integració incremental descendent del mòdul 04 Tema 03 Disseny i realització de proves de programari – Part III Pàgina 20/23  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 Continuarem pel Mòdul 05. Figura 14. Prova d’integració incremental descendent del mòdul 05 Seguirem pel Mòdul 03. Figura 14. Prova d’integració incremental descendent del mòdul 03 Tema 03 Disseny i realització de proves de programari – Part III Pàgina 21/23  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 I finalitzarem amb el Mòdul 06, amb el que ja tindrem tot l’esquema comprovat Figura 15. Prova d’integració incremental descendent del mòdul 06 Avantatges de la integració descendent Els avantatges són els següents: Identificació de l’estructura: permet veure l’estructura del sistema des d’un principi, facilitant l’elaboració de demostracions del seu funcionament. Disseny descendent: primer es defineixen les interfícies dels diferents subsistemes per després seguir amb les funcions específiques de cada un per separat. Detecció més ràpida dels errors que es troben als mòduls superiors pel fet de detectar-se en una etapa inicial. Desavantatges de la integració descendent Entre els desavantatges, destaquen: Tema 03 Disseny i realització de proves de programari – Part III Pàgina 22/23  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 Cost molt elevat: caldrà implementar molts mòduls addicionals per oferir els mòduls ficticis a fi d’anar efectuant les proves. Alta dificultat: en voler fer una distribució de les proves del més genèric al més detallat, les dades que s’hauran d’utilitzar són difícils d’aconseguir, ja que són els mòduls de nivell més baix els que tindran els detalls. Tema 03 Disseny i realització de proves de programari – Part III Pàgina 23/23  Entorns de Desenvolupament TEMA 03 – PART IV Disseny i realització de proves de programari 3. Procediments, tipus i casos de proves 3.2. Disseny de les proves. Tipus de proves 3.3. Execució de les proves 3.4. Finalització: avaluació i anàlisi d’errors 3.5. Depuració del codi font  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 Proves de càrrega i acceptació El pas següent, una vegada fetes les proves unitàries i les proves d’integració, serà dur a terme primer les proves de càrrega i, posteriorment, les proves d’acceptació.  Les proves de càrrega són proves que tenen com a objectiu comprovar el rendiment i la integritat de l’aplicació ja acabada amb dades reals. Es tracta de simular l’entorn d’explotació de l’aplicació. Amb les proves anteriors (unitàries i d’integració) quedaria provada l’aplicació a escala de “laboratori”. Però també es necessita comprovar la resposta de l’aplicació en situacions reals, i fins i tot, en situacions de sobrecàrrega, tant a escala de rendiment com de descontrol de dades. Per exemple, una aplicació lenta pot ser poc operativa i no útil per a l’usuari. Després de les proves de càrrega, es troben les proves d’acceptació. Aquestes proves les fa el client o usuari final de l’aplicació desenvolupada. Són bàsicament proves funcionals, sobre el sistema complet, i busquen una cobertura de l’especificació de requisits i del manual de l’usuari. Aquestes proves no es fan durant el desenvolupament, ja que seria impresentable de cara al client, sinó una vegada passades totes les proves anteriors per part del desenvolupador o l’equip de tests.  L’objectiu de la prova d’acceptació és obtenir l’aprovació del client sobre la qualitat de funcionament del sistema desenvolupat i provat. Els programadors acostumen a obtenir sorpreses en les proves d’acceptació, ja que és la primera vegada que es troben amb el programa finalitzat. Tema 03 Disseny i realització de proves de programari – Part IV Pàgina 2/12  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 L’experiència demostra que, encara després del procés més detallat de proves per part del desenvolupador i l’equip de treball, queden una sèrie d’errors que només apareixen quan el client posa en funcionament l’aplicació o el sistema desenvolupat. Siga com siga, el client sempre té la raó. Per aquest motiu, molts desenvolupadors exerciten unes tècniques denominades proves alfa i proves beta.  Les proves alfa consisteixen a convidar el client que vinga a l’entorn de desenvolupament a provar el sistema. Es treballa en un entorn controlat i el client sempre té un expert a mà per ajudar-lo a usar el sistema i per analitzar els resultats.  Les proves beta vénen després de les proves alfa, i es desenvolupen en l’entorn del client, un entorn que és fora de control per al desenvolupador i l’equip de treball. Ací el client es queda sol amb el producte i tracta de trobar els errors, dels quals informarà el desenvolupador. Les proves alfa i beta són habituals en productes que es vendran a molts clients o que utilitzaran molts usuaris. Alguns dels compradors potencials es presten a aquestes proves, siga per anar entrenant el seu personal amb temps, o en compensació d’algun avantatge econòmic (millor preu sobre el producte acabat, dret a manteniment gratuït, a noves versions…). L’experiència mostra que aquestes pràctiques són molt eficaces. En un entorn de desenvolupament de programari tenen sentit quan l’aplicació o sistema per desenvolupar el farà servir un gran nombre d’usuaris finals (empreses grans amb diferents departaments que hauran d’utilitzar aquesta nova eina). Tema 03 Disseny i realització de proves de programari – Part IV Pàgina 3/12  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 de sistema i de seguretat Les proves de sistema són aquelles proves que es duran a terme una vegada finalitzades les proves unitàries (cada mòdul per separat), les proves d’integració dels mòduls, les proves de càrrega i les proves d’acceptació per part de l’usuari. Temporalment, es troben en una situació en la qual l’usuari ha pogut verificar l’aplicació desenvolupada duent a terme les proves d’acceptació. Posteriorment, l’aplicació s’ha integrat al seu nou entorn de treball.  Les proves de sistema serviran per validar l’aplicació una vegada aquesta haja estat integrada amb la resta del sistema de l’usuari. Encara que l’aplicació ja haja estat validada de forma independent, a les proves de sistema es durà a terme una segona validació amb l’aplicació ja integrada en el seu entorn de treball real. A continuació s’enumeren alguns tipus de proves per desenvolupar durant les proves del sistema: Proves de rendiment: valoraran els temps de resposta de la nova aplicació, l’espai que ocuparà en disc, el flux de dades que generarà a través d’un canal de comunicació. Proves de resistència: valoraran la resistència de l’aplicació per a determinades situacions del sistema. Proves de robustesa: valoraran la capacitat de l’aplicació per suportar diverses entrades no correctes. Proves de seguretat: ajudaran a determinar els nivells de permisos dels usuaris, les operacions que podran dur a terme i les d’accés al sistema i a les dades. Proves d’usabilitat: determinaran la qualitat de l’experiència d’un usuari en la manera d’interactuar amb el sistema. Proves d’instal·lació: indicaran les operacions d’arrencada i d’actualització dels Tema 03 Disseny i realització de proves de programari – Part IV Pàgina 4/12  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 programaris. Les proves de sistema aglutinen moltes altres proves que tindran diversos objectius: ➔ Observar si l’aplicació fa les funcions que ha de fer i si el nou sistema es comporta com ho hauria de fer. ➔ Observar els temps de resposta per a les diferents proves de rendiment, volum i sobrecàrrega. ➔ Observar la disponibilitat de les dades en el moment de recuperació d’una errada (a la vegada que la correcció). ➔ Observar la usabilitat. ➔ Observar la instal·lació (assistents, operadors d’arrencada de l’aplicació, actualitzacions del programari…). ➔ Observar l’entorn una vegada l’aplicació està funcionant a ple rendiment (comunicacions, interaccions amb altres sistemes…). ➔ Observar el funcionament de tot el sistema a partir de les proves globals fetes. ➔ Observar la seguretat (el control d’accés i intrusions…). Les proves a escala global del sistema s’han anat produint a mesura que es tenien funcionalitats perfectament acabades. És el cas, per exemple, de provar el funcionament correcte del desenvolupament d’una partida en un joc, o la navegació correcta per les diferents pantalles dels menús.  Les proves de validació permeten comprovar si, efectivament, es compleixen els requisits proposats pel nostre sistema. Tema 03 Disseny i realització de proves de programari – Part IV Pàgina 5/12  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 de regressió i proves de fum  Les proves de regressió intenten detectar possibles nous errors o problemes que puguen aparéixer en haver introduït canvis o millores en el programari. Aquests canvis poden haver estat introduïts per solucionar algun problema detectat en la revisió del programari arran d’una prova unitària, d’integració o de sistema. Aquests canvis poden solucionar un problema però provocar-ne d’altres, sense haver-ho previst, en altres llocs del programari. És per aquesta raó que cal dur a terme les proves de regressió en finalitzar la resta de proves. Un control no convenient dels canvis de versions, o una falta de consideració cap a altres mòduls o parts del programari, poden ser causes dels problemes per detectar en les proves de regressió. Es pot automatitzar la detecció d’aquest tipus d’errors amb l’ajuda d’eines específiques. L’automatització és complementària a la resta de proves, però en facilitarà la repetibilitat. El problema que es pot derivar de l’automatització de les proves de regressió és que demanaran un manteniment complex. El terme proves de fum sorgeix a partir de la fabricació de maquinari. Si després de reparar un component de maquinari, aquest “no treu fum”, és que funcionarà correctament.  Les proves “de fum” són proves preliminars per revelar simples fallades suficientment greus com, per exemple, rebutjar un llançament del programari. Són una execució ràpida que se centra en la funcionalitat crítica per garantir que l’aplicació puga realitzar funcions bàsiques. Una prova de fum pot fer front a preguntes bàsiques com "funciona el programa?", Tema 03 Disseny i realització de proves de programari – Part IV Pàgina 6/12  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 "s'obre la interfície d'usuari?" o "fer clic al botó principal fa alguna cosa?" Les proves de fum són superficials (es fa en minuts), mentre que les de regressió treballen en profunditat tots els aspectes del programa (dura hores). 3.3 Execució de les proves Després de la planificació dels procediments de proves i del disseny dels casos de proves, el següent pas serà el procés d’execució. Aquests procés està representat en el diagrama de flux de la figura.1. L’execució de les proves comportarà seguir els passos següents: 1. Execució de les proves. 2. Comprovació de si s’ha produït algun error en l’execució de les proves. 3. Si no hi ha hagut cap error: ◦ Es verifica la finalització de les proves. ◦ Es valida si calen proves addicionals. ➔ Si es necessiten proves addicionals, cal validar que no existisquen condicions anormals. Si hi ha condicions anormals, es finalitza el procés de proves fent una avaluació del mateix procés; si no, caldrà depurar les proves. ➔ Si no es necessiten proves addicionals, es durà a terme una finalització del procés de proves fent una avaluació del mateix procés. 4. En el cas d’haver trobat errors en l’execució de les proves, s’haurà de veure si aquests errors han estat deguts a: ◦ Un defecte del programari. En aquest cas, l’execució de les proves ha complert el seu objectiu i caldrà depurar el codi de programació, localitzar el o els errors i solucionar-ho per tornar al punt inicial, en què es tornaran a executar les proves i es tornarà a validar si el canvi efectuat ha tingut èxit. ◦ Un defecte del disseny de les proves. En aquest cas, caldrà revisar les proves que s’han executat, depurant-les, localitzant el o els errors i solucionar-ho, per Tema 03 Disseny i realització de proves de programari – Part IV Pàgina 7/12  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 tenir unes proves correctes, sense errors, preparades per tornar al punt inicial i tornar a executar-les. Figura 1. Execució de les proves Una execució de les proves exitosa no és aquella que troba errors coste el que coste ni aquella que només avalua dues o tres possibilitats, sinó que és aquella que acompleix el que s’ha planificat al pla de proves i que garanteix que allò dissenyat siga el que es valida. Tema 03 Disseny i realització de proves de programari – Part IV Pàgina 8/12  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.4 Finalització: avaluació i anàlisi d’errors El darrer pas dels procediments de proves serà la finalització del procés. Per poder donar-lo per tancat de forma exitosa, caldrà efectuar una avaluació i una anàlisi dels errors localitzats, tractats, corregits i re-avaluats. Si no es pot donar per finalitzat el procés de proves, caldrà dur a terme una replanificació del procés de proves per establir noves depuracions i noves proves, planificant-les i dissenyant-les de nou.  En el cas d’haver de refer els procediments de proves, és molt important la creació de nous casos de proves i no només la readaptació dels ja existents. Si es creen nous casos de proves, s’estarà redissenyant els procediments de proves sobre el mateix codi font; si s’intenten readaptar els ja existents o modificar el codi, es corre el risc de fer que el codi font siga el que s’estiga adaptant als casos de proves. Finalment, és convenient escriure un informe que ajude a emmagatzemar l’experiència que s’ha recollit al llarg del procediment de proves. Aquesta informació serà molt important per a futurs projectes, ja que ajudarà a no tornar a repetir els mateixos errors detectats. L’informe haurà de donar resposta a ítems com els que s’indiquen a continuació: Quantitat de casos de prova generats. Quantitat d’errors detectats a cada fase del projecte. Temps i recursos dedicats als procediments de proves. Tipus de proves dutes a terme. Tipus de proves que més errors han detectat. Nivell de qualitat del programari. Mòduls on més errors s’han detectat. Errors que han arribat fins als usuaris finals. Nombre de casos de prova erronis detectats. Tema 03 Disseny i realització de proves de programari – Part IV Pàgina 9/12  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.5 Depuració del codi font Les proves que s’efectuen sobre tot un projecte informàtic amb tots els processos involucrats (planificació, disseny, execució i avaluació) ajudaran a la detecció i correcció d’errors, intentant trobar-los al més aviat possible en el desenvolupament del projecte. Una tècnica molt important per a l’execució de les proves i, en general, per als programadors, és la depuració del codi font.  La depuració del codi font consisteix a anar executant pas a pas el codi font, observant els estats intermedis de les variables i les dades implicades per facilitar la correcció d’errors. Els procediments que estan vinculats a la depuració del codi font són: Identificar la casuística per poder reproduir l’error. Diagnosticar el problema. Solucionar l’error atacant el problema. Verificar la correcció de l’error i verificar que no s’han introduït nous errors a la resta del programari. La depuració del codi és una eina molt útil si se sap localitzar el mòdul o la part del codi font on es troba un determinat error. Si l’error és difícil de reproduir serà molt complicat trobar una solució per solucionar-lo. Per això, acotant-lo dintre del codi, es pot anar localitzant, fent proves per arribar a les circumstàncies que el reprodueixen. Caldrà anar amb compte amb les solucions aplicades quan es fa servir la tècnica de la depuració del codi. Moltes vegades una modificació en el codi per solucionar un problema pot generar un altre error que estiga relacionat o que no tinga res a veure. Caldrà tornar a confirmar la correcta execució del codi una vegada finalitzada la correcció. La depuració de codi permet la creació d’un punt en el codi font fins al qual el Tema 03 Disseny i realització de proves de programari – Part IV Pàgina 10/12  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 programari serà executat de forma directa. Quan l’execució haja arribat a aquest punt de ruptura (breakpoint), es podrà avançar en l’execució del codi pas a pas fins a trobar l’error que es busca. Una altra forma de dur a terme la depuració de codi és anar enrere, des del punt de l’error, fins a trobar el causant. Aquesta tàctica es fa servir en casos més complexos i no és tan habitual, però serà molt útil en el cas de no tenir detectada la ubicació de l’error, que pot trobar-se ocult en alguna part del codi font. En aquests casos, a partir del lloc on es genera l’error, es durà a terme un recorregut cap enrere, anant pas a pas en sentit invers. Una eina que ajuda a la depuració del codi font és la utilització de fitxers anomenats registres (logs). Aquests fitxers, habitualment de text, enregistren tota la informació vinculada a l’execució d’un programari amb l’objectiu que el programador puga fer una revisió pas a pas de com ha evolucionat aquesta execució i localitzar errors o mals funcionaments.  La depuració del codi és molt útil també en l’execució de les proves d’integració, de sistema i d’acceptació. Eclipse proporciona un entorn de depuració que facilita la detecció d’errors, permetent seguir el codi pas a pas i consultar els valors que van prenent les dades. Tema 03 Disseny i realització de proves de programari – Part IV Pàgina 11/12  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 Figura 2. Eclipse: perspectiva de depuració Tema 03 Disseny i realització de proves de programari – Part IV Pàgina 12/12