class: center, middle, inverse # Proves de programari (Testing) ### Introducció --- # Error de programari (Bug) - Resultat d'una fallada durant el procés de creació de programari. - Pot presentar-se en qualsevol de les etapes del cicle de vida del programari - Els més evidents es donen en l'etapa de desenvolupament i programació --- # Altres exemples ficticis de disseny - En una aplicació de gestió de treballadors posar el segon cognom obligatori. - En una aplicació de pagaments de zona blava, no permetre que un usuari tingui més d'un cotxe --- # Disseny i realització de proves de programari - 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. - La realització de proves ens permet eliminar completament els errors? --- # Bugs famosos - 1947 - Ordinador Harvard Mark II - Es troba una arna dins la màquina - Origen de la paraula bug? .fullscreen-bottom[] --- # Bugs famosos - Efecte 2000 - Un any es guarda amb dues xifres. - Any 2038 - Un any es guarda com a segons des de el 1 de gener de 1970 ??? 2038 -> rango de números entre -2 147 483 648 y 2 147 483 647 (-2^31 y 2^31-1) --- # Bugs famosos .right-image[] - Mars Climate Orbiter - 1998 - Es va destruir a mart amb un error d'uns 100km. - Errors d'ús entre sistema mètric i imperial --- # Bugs famosos .right-image[] - Explosio Ariane 5 - 7 bilions de dòlars - Conversió de numero que perdia dígits (16 bits vs 64 bits) ??? # Ariane 5 Specifically a 64 bit floating point number relating to the horizontal velocity of the rocket with respect to the platform was converted to a 16 bit signed integer. The number was larger than 32,767, the largest integer storeable in a 16 bit signed integer, and thus the conversion failed. --- # Programari sense errors? - No podem provar tots els casos - La realització de proves ens permet una reducció del risc. - Com més extens siguin les proves més podrem reduir el risc. --- # Impacte d'un error - Freqüència - Problemàtica que genera l'error --- # Classificació de les proves ## Segons la realització - Automàtics - Permeten poder realitzar-los constantment - Manuals --- # Classificació de les proves ## Segons coneixement del sistema - Caixa negra - Caixa blanca --- # Classificació de les proves ## Segons finalitat i marc - Unitàries - Funcionals - Integració - Proves de sistemes - Proves d'acceptació - Proves de carrega --- # Unitàries - 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. --- # Funcionals - 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 --- # Integració - 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 --- # Proves de sistemes - La seva 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. --- # Proves d'acceptació - 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 fan servir l'aplicació. --- # Proves de càrrega - 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ó. --- # Cas de prova (test case) - Un conjunt de condicions o variables, valors, precondicions, resultats esperats i postcondicions, sota les que un enginyer de proves (tester) determina si una aplicació o un sistema de software està funcionant correctament o no. - Els casos de prova escrits s'acostumen a agrupar en jocs de proves. --- # Desenvolupament guiat per proves - Test-driven development (TDD) - Pràctica d'enginyeria del software - Escriure primer les proves (Test-First Programming) - Després escriure el codi que passi les proves. --- # Passos - Fer cicles dels passos següents - Escriure un test per la següent funcionalitat - Escriure una funció que passi el test - Refactorizar l'antic i el nou codi mantenint una correcte estructura. --- # Tests automàtics - la part positiva - Redueix riscos - Reducció del temps de realitzar les proves - Reduir els riscos en les modificacions --- # Tests automàtics - la part negativa - Molts programadors no els veuen necessaris - Incrementa el temps de desenvolupament inicial - La recompensa és a llarg termini --- # Bibliografia i Urls - https://ca.wikipedia.org/wiki/Error_de_programari - https://www.bbvaopenmind.com/en/the-5-most-infamous-software-bugs-in-history/ - https://en.wikipedia.org/wiki/Year_2038_problem