Introducción al testing de software

Presentación del tema: "Introducción al testing de software"— Transcripción de la presentación:

1 Introducción al testing de software
Manuel Núñez Especificación, Validación y Testing Estas transparencias están basadas en las desarrolladas por Ammann & Offutt como acompañamiento de su libro Introduction to Software Testing (2nd Edition)

2 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Un pequeño ejercicio Escribe un conjunto de tests para testear, de forma apropiada, un programa tal que: Dados 3 valores enteros, que representan la longitud de los lados de un triángulo, determine si el triángulo es escaleno, isósceles o equilátero Recordatorio: equilátero (3 lados iguales), isosceles (2 lados iguales) y escaleno (todos los lados son distintos). Por ahora, supondremos que un test es una tupla de valores (uno para cada parámetro) y el valor esperado. Por ejemplo, in=(7, 4, 8) & out= “escaleno”. ¿Qué es un test? Tenéis cinco minutos….. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

3 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Un pequeño ejercicio Determina si tu conjunto de tests es adecuado para cubrir las siguientes situaciones: Un test para un triángulo escaleno válido. Nota: Un test con entrada (1,2,3) o (2,5,10) no sería válido!! Un test para un triángulo equilátero válido. Un test para un triángulo isosceles válido. Al menos tres tests que representen triángulos isósceles válidos donde se han permutado los dos lados iguales (por ejemplo, (3,3,4), (3,4,3) y (4,3,3). Un test con un lado igual a cero. Un test con un lado negativo. que no sea equilátero!! Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

4 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Un pequeño ejercicio Determina si tu conjunto de tests es adecuado para cubrir las siguientes situaciones: Un test con tres valores enteros positivos tales que la suma de dos de ellos sea igual al tercero. Por ejemplo, si el programa dijera que (1,2,3) es escaleno, el programa estaría mal. Al menos tres tests que representen las tres permutaciones del caso anterior. Por ejemplo, (1,2,3), (1,3,2) y (3,1,2). Un test con tres valores enteros positivos tales que la suma de dos de ellos es menor que el tercero. Al menos tres tests que representen las tres permutaciones del caso anterior. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

5 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Un pequeño ejercicio Determina si tu conjunto de tests es adecuado para cubrir las siguientes situaciones: Un test con entrada (0, 0, 0). ¿Qué salida debemos obtener? Un test que incluya al menos un valor no entero (e.g. 2.5). Un test que indique un número incorrecto de valores (e.g. dos valores en lugar de tres). Para cada test se ha especificado la salida esperada. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

6 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Un pequeño ejercicio Nota importante: Este conjunto de tests NO garantiza que se encuentren todos los errores en el programa. Los tests que se encuadran en las primeras 13 categorías representan errores que han ocurrido en distintas versiones del programa. Un proceso de testing adecuado para este programa debería mostrar, al menos, estos errores. Sin embargo, programadores profesionales con experiencia han identificado, en media, solo 7.8 de los 14 apartados. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

7 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Testing de software Ante esta perspectiva, podría parecer que testear un programa real es imposible. ¡No es para tanto! Aunque pueda parecer desalentador, realizar un testeo adecuado del software es una parte necesaria, y realizable, en el desarrollo de software. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

8 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Testing de software La mayoría de los programadores comienzan con una definición falsa del término: Testing es el proceso consistente en demostrar que no hay errores. El propósito del testing es mostrar que un programa lleva a cabo sus funcionalidades correctamente. Testing es el proceso de establecer una cierta confianza en que el programa hace lo que se supone que debe hacer. Estas definiciones no son adecuadas para describir el proceso de testing. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

9 Testing de software Testing debe aumentar la calidad y fiabilidad del programa. Aumentar la fiabilidad significa que debemos encontrar y corregir errores. Al comenzar a testear un programa hay que empezar asumiendo que el programa contiene errores y testearlo con el objetivo de encontrar los más posibles. Daremos, un poco más adelante, una definición todavía más redonda Testing consiste en ejecutar un programa con la intención de encontrar errores. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

10 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Testing de software Si nuestro objetivo es demostrar que un programa no tiene errores, entonces tenderemos a seleccionar tests que tengan una probabilidad baja de causar que el programa falle. Si nuestro objetivo es demostrar que un programa tiene errores, entonces tenderemos a seleccionar tests que tengan una probabilidad alta de encontrar errores. Obviamente, la segunda aproximación será más útil que la primera. Testing consiste en ejecutar un programa con la intención de encontrar errores. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

11 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Testing de software Demostrar que no hay errores en un programa es, virtualmente, imposible, incluso para programas triviales. Si nos quedamos con una definición en la que testing se asocia con el proceso de descubrir errores entonces conseguimos que el testing sea una tarea realizable. ¡¡Warning!! Daremos una definición todavía más adecuada, y actual, del término testing. Testing consiste en ejecutar un programa con la intención de encontrar errores. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

12 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Testing de software Incluso los programas que hacen lo que se supone que deben hacer pueden tener errores. Hay errores si un programa hace algo que se supone que no debe hacer. Incluso aunque pudiéramos demostrar que el programa distingue correctamente entre triángulos escalenos, isósceles y equiláteros, el programa fallaría si, por ejemplo, dice que (1,2,3) representa un triángulo escaleno o que (0,0,0) representa un triángulo equilátero. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

13 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Testing de software En resumen: Tenemos, en principio, una versión del testing como un proceso destructivo consistente en encontrar errores (cuya presencia es asumida) en un programa. La aplicación de un test es exitosa si hace que el programa falle (e.g. devuelva un valor inesperado, produzca una excepción no prevista, etc). Pero como ya hemos dicho, esta definición puede ser matizada y mejorada si consideramos una definición del término basada en nivel de pensamiento. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

14 Definición de testing por niveles
Nivel 0: No hay diferencia entre testing y debugging. Nivel 1: El propósito de testing es mostrar corrección. Nivel 2: El propósito de testing es mostrar que el software no funciona. Nivel 3: El propósito de testing no es probar nada específico, sino reducir los riesgos asociados con la utilización del software. Nivel 4: Testing es una disciplina mental que ayuda a que los profesionales desarrollen software con más calidad. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

15 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Nivel 0 de pensamiento No hay diferencia entre testing y debugging. Testing es lo mismo que debugging. No se distingue entre comportamiento incorrecto y errores en el programa. No ayuda a desarrollar software fiable y/o seguro. Esto es lo que se enseña, habitualmente, en grados de Informática que no tienen un curso específico de testing. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

16 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Nivel 1 de pensamiento El propósito de testing es mostrar corrección. Desgraciadamente, la corrección es imposible de conseguir. Si no detectamos fallos, ¿tenemos buen software o malos tests? Esto es lo que, habitualmente, esperan los ingenieros que diseñan hardware. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

17 Nivel 2 de pensamiento El propósito de testing es mostrar que el software no funciona. El propósito es mostrar fallos. Buscar fallos es una actividad con negatividad. Enfrenta a los testeadores con los desarrolladores. ¿Qué ocurre si no hay fallos? Esto es lo que describe a la mayoría de las compañías de software. ¿Podemos pasar a una visión de equipo? Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

18 Nivel 3 de pensamiento El propósito de testing no es probar nada específico, sino reducir los riesgos asociados con la utilización del software. El testing solo puede mostrar la presencia de fallos. Siempre que usamos un software debemos asumir un cierto riesgo. Este riesgo puede ser pequeño y sus consecuencias irrelevantes. Sin embargo, este riesgo también puede ser grande y tener consecuencias catastróficas. Testeadores y desarrolladores deben cooperar para reducir riesgos. Esto es lo que describe a unas pocas compañías “avanzadas”. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

19 Nivel 4 de pensamiento Testing es una disciplina mental que ayuda a que los profesionales desarrollen software con más calidad. El testing es solo un método para aumentar la calidad. Los ingenieros testeadores pueden llegar a liderar proyectos. La principal responsabilidad es medir y mejorar la calidad del software. Su experiencia debería ayudar a los desarrolladores. Esta es la forma “tradicional” en otras ingenierías. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

20 Nociones a tener en cuenta a la hora de testear
Una parte necesaria a la hora de definir un test consiste en proporcionar el resultado esperado. Por tanto, cada test debe tener dos componentes (más adelante veremos que es un poco más complejo): Una enumeración de los valores de los inputs del programa. Una definición precisa del output correcto para esos valores de los inputs. Un programador debería evitar testear sus propios programas. Normalmente no estamos preparados (psicológicamente) para buscar errores en nuestro propio trabajo. En particular, el programa puede tener errores debido a que el programador no ha comprendido el enunciado del problema o su especificación. ¡¡Warning!! Esto está cambiando con la aparición de las metodologías ágiles. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

21 Nociones a tener en cuenta a la hora de testear
La organización que desarrolla un programa no debería testear sus propios programas. El argumento es similar al anterior. Además, el proceso de testing se puede llegar a ver como responsable de no completar el producto a tiempo y aumentar su coste. Estudia detalladamente los resultados de cada test. Hay errores que aparecen en tests que no se percibieron en tests que se habían aplicado con anterioridad. Los test se deben diseñar tanto para cubrir inputs válidos y esperados como para llevar valores inválidos o inesperados. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

22 Nociones a tener en cuenta a la hora de testear
Testear un programa para ver si no hace lo que se supone que debe hacer es solo la mitad del proceso; la otra mitad consiste en ver si el programa hace algo que no debería hacer. Por ejemplo, en el problema del triángulo, al recibir (1,2,5) debería decir que son valores inválidos para un triángulo. Evita utilizar tests desechables. Si tenemos que testear el programa de nuevo entonces tenemos que reinventar los tests. El retesting de un programa no suele ser tan riguroso como la primera vez de forma que si una modificación causa un error en una funcionalidad anterior del programa, es fácil que el error no se detecte. Guardar tests y ejecutarlos tras cambios en otras componentes del programa se conoce como regression testing. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

23 Nociones a tener en cuenta a la hora de testear
No planees un proceso de testing asumiendo que no encontrarás errores. La probabilidad de encontrar más errores en una componente es proporcional al número de errores que ya se han encontrado en esa componente. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

24 ¿Por qué testeamos el software?
Manuel Núñez Especificación, Validación y Testing

25 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Testing en el siglo XXI El mercado del software actual es: Mucho más grande. Más competitivo. Tiene más usuarios. Tenemos software empotrado para controlar: Aviones. Sistemas de control de tráfico aéreo. Naves espaciales. Relojes. Hornos. Mandos a distancia. Reproductores de DVD. Mandos de garage. Teléfonos móviles. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

26 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Testing en el siglo XXI Las metodologías de desarrollo ágiles ponen una presión adicional a los testeadores. Los programadores deben realizar testing unitario (unit testing) sin haber recibido ni entrenamiento ni formación. Los tests son fundamentales para comprobar los requisitos funcionales (¿qué hace el sistema). Pero, ¿Quién escribe estos tests? Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

27 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Software es ubicuo Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

28 Faults, errors & failures
Estos tres conceptos son fundamentales (veremos más detalladamente la relación entre ellos y como impactan en las tareas de testing). Software Fault (defecto): Un defecto estático en el software. Software Error (error): Un estado interno incorrecto que es la manifestación de un defecto. Software Failure (fallo): Comportamiento externo incorrecto con respecto a los requisitos o descripción del comportamiento esperado. Los defectos en el software son comparables a los errores de diseño en el hardware. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

29 Faults, errors & failures: Ejemplo
La mayoría de los problemas médicos provienen o de ataques externos (bacterias, virus) o de la degradación natural debida al envejecimiento. Un paciente le enumera al médico un lista de síntomas. Failures. El médico intenta diagnosticar la causa de la dolencia. Fault. El médico puede buscar condiciones anómalas internas (presión arterial alta, arritmias, bacterias en el torrente sanguíneo). Errors. Software faults estaban allí desde el principio y no “aparecen” cuando una componente se “gasta”. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

30 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Otro ejemplo Fault: La búsqueda debería empezar en 0, no en 1 public static int numZero (int [ ] arr) { // Effects: If arr is null throw NullPointerException // else return the number of occurrences of 0 in arr int count = 0; for (int i = 1; i < arr.length; i++) { if (arr [ i ] == 0) count++; } return count; Test 1 [ 2, 7, 0 ] Esperado: 1 Observado: 1 Error: i es 1, no 0, en la primera iteración Failure: ninguno Test 2 [ 0, 2, 7 ] Esperado: 1 Observado: 0 Error: i es 1, no 0 El error se propaga a la variable count Failure: count vale 0 en el return Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

31 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
El término bug BUG Bug se usa informalmente. Algunas veces se interpreta como fault, otras veces como error y otras veces como failure. De hecho, la mayoría de las veces, el que usa el término ni siquiera sabe lo que significa! En esta asignatura, intentaremos utilizar términos con significado preciso, así que “It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise—this thing gives out and [it is] then that 'Bugs'—as such little faults and difficulties are called—show themselves and months of intense watching, study and labor are requisite. . .” – Thomas Edison (1878) Seguro que todos conocéis como apareció el término bug. ¿Algún voluntario? Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

32 Fallos espectaculares en software
El Mars lander de la NASA. Septiembre de 1999, se estrelló debido a un fault (defecto) al integrar unidades. THERAC-25 (máquina de radioterapia). Testing deficiente de safety-critical software puede costar vidas: 3 pacientes murieron. Necesitamos que nuestro software sea fiable (dependable). Testing es una forma de evaluar la fiabilidad de un sistema. Diseño de THERAC-25 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

33 Fallos espectaculares en software
Explosión del Ariane 5. Millones de $ perdidos. Intel’s Pentium FDIV fault. Auténtica pesadilla para la compañía. Ariane 5: error al manipular excepciones: forzó la autodestrucción del primer. Una conversion de 64-bit a 16-bit costó unos $370 millones. Necesitamos que nuestro software sea fiable (dependable). Testing es una forma de evaluar la fiabilidad de un sistema. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

34 Apagón Noreste de Norteamérica (2003)
Se apagaron 508 generadores y 256 centrales elétricas. Afectó a 10 millones en Ontario, Canadá. Afectó a 40 millones en 8 estados de USA. Se perdieron $ El sistema de alarma del sistema de gestión energética falló debido a un error de software y los operadores no fueron informados de la sobrecarga del sistema. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

35 Fallos costosos de software
El informe del NIST (National Institute of Standards and Technology) “The Economic Impacts of Inadequate Infrastructure for Software Testing” (2002) afirmaba: Procesos inadecuados de testing le cuestan a USA entre $22 y $59 miles de millones al año. Mejores aplicaciones podrían reducir esta cifra a la mitad. ¡Las pérdidas monetarias a nivel mundial debidas a software deficiente son realmente asombrosas! Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

36 Fallos costosos de software
Pérdidas enormes debidas a fallos en aplicaciones web: Servicios financieros: $6.5 millones por hora (solo en USA). Aplicaciones dependientes de compras con tarjeta de crédito: $2.4 millones por hora (de nuevo, considerando solo USA). En diciembre de 2006, una oferta BOGO (Buy One Get One) de amazon.com dio lugar a un descuento doble. En 2007 Symantec concluyó que la mayoría de las vulnerabilidades del software se deben a software con fallos. ¡Las pérdidas monetarias a nivel mundial debidas a software deficiente son realmente asombrosas! Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

37 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Testing en el siglo XXI Cada vez hay mas software safety-critical y en tiempo-real. El software empotrado es ubicuo… mirad en vuestros bolsillos (¡y quitad el volumen!). Las aplicaciones empresariales tienen programas más grandes y más usuarios. Paradójicamente, el software gratuito aumenta nuestras expectativas! Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

38 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
Testing en el siglo XXI La seguridad está en la actualidad asociada con fallos de software. Un software seguro es un software fiable. La web ofrece una nueva plataforma de implantación. Muy competitiva y disponible para muchos usuarios. Las aplicaciones web apps están distribuidas y deben ser muy fiables. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

39 Por tanto… Software testing es cada vez más importante.
A esta pregunta ya hemos respondido Software testing es cada vez más importante. Se nos plantean al menos dos preguntas. ¿Qué intentamos hacer cuando testeamos? ¿Cuáles son nuestros objetivos a la hora de testear? Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

40 Validación y verificación (IEEE)
Complementando al término testing conviene conocer, y distinguir adeduadamente entre ellos, estos dos términos. Validación: El proceso de evaluar el software al final de su desarrollo para garantizar conformidad con respecto al uso deseado. Verificación: El proceso de decidir si el producto, en una determinada fase del ciclo de desarrollo del software, cumple los requisitos establecidos durante la fase anterior. Testing se considera habitualmente una actividad de validación. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

41 Objetivos tácticos. ¿Por qué usamos un test?
Si no sabes por qué aplicas un cierto test entonces ¡no será muy útil! Los objetivos de test y los requisitos deben estar bien documentados. ¿Qué niveles de cobertura tienes en mente? Veremos bastante sobre cobertura, no os preocupéis. ¿Cuánto testing es suficiente? Objetivo común: gastar el presupuesto… testear hasta el último día… Esta aproximación se suele llamar “criterio de fecha”. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

42 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
¿Por qué usamos un test? Si no empiezas a planear cada test cuando se definen los requisitos funcionales entonces no sabrás por qué estás aplicando un cierto test. 1980: “El software será sencillo de mantener”. ¿Qué umbral tenemos para los requisitos de fiabilidad? ¿Qué hecho intenta evaluar cada test? El equipo que define los requisitos necesita testeadores. Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

43 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)
El precio de no testear Testing es la actividad más cara (al menos el 50% del presupuesto) y que más tiempo conlleva durante el desarrollo de software. Pero no testear es todavía más caro. Si no nos esforzamos en hacer testing al principio, entonces el coste aumenta. Planificar el testing para después de finalizar el desarrollo es prohibitivamente caro. Encargados de proyecto poco responsables podrían decir: “Testing es demasiado caro.” Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

44 El precio de testear tarde
60 50 40 30 20 10 Asumimos $1000 por fallo, 100 fallos $250K $360K Origen del fallo (%) Detección del fallo (%) Coste unitario de arreglar el fallo (X) $20K $100K $13K $6K 28-Oct-2010, at GTAC, added the animation to demonstrate increasing the number of faults found early, thereby decreasing the number of faults found late, and finally saving money. Lots of it! This animation is fairly complicated … must practice first!! Requisitos Diseño Prog / Test unitario Test de Integración Test de sistema Post-Deployment Software Engineering Institute; Carnegie Mellon University; Handbook CMU/SEI-96-HB-002 Especificación, Validación y Testing (M. G. Merayo y M. Núñez)

45 Conclusión: ¿Por qué testeamos el software?
El objetivo del testeador debe ser eliminar los fallos (faults) lo antes posible. Incrementa la calidad. Reduce el coste. Mantiene/incrementa la satisfacción del cliente. ¿Por qué? Especificación, Validación y Testing (M. G. Merayo y M. Núñez)