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)
 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).
¿Qué es un test?
Tenéis cinco minutos…..
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”.

ESPECIFICACIÓN, VALIDACIÓN Y TESTING (M. G. MERAYO Y M. NÚÑEZ) 2

 Un pequeño ejercicio
Determina si tu conjunto de tests es adecuado para cubrir las siguientes
situaciones:
1. 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!!
2. Un test para un triángulo equilátero válido.
3. Un test para un triángulo isosceles válido. que no sea equilátero!!
4. 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).
5. Un test con un lado igual a cero.
6. Un test con un lado negativo.

ESPECIFICACIÓN, VALIDACIÓN Y TESTING (M. G. MERAYO Y M. NÚÑEZ) 3

 Un pequeño ejercicio
Determina si tu conjunto de tests es adecuado para cubrir las siguientes
situaciones:
7. 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.
8. Al menos tres tests que representen las tres permutaciones del caso
anterior. Por ejemplo, (1,2,3), (1,3,2) y (3,1,2).
9. Un test con tres valores enteros positivos tales que la suma de dos de
ellos es menor que el tercero.
10. 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) 4

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

ESPECIFICACIÓN, VALIDACIÓN Y TESTING (M. G. MERAYO Y M. NÚÑEZ) 5

 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) 6

Testing de software
Ante esta perspectiva, podría parecer que testear un programareal 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) 7

 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) 8

 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) 9

 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) 10

 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, Testing consiste en ejecutar
del término testing. un programa con la intención
de encontrar errores.

ESPECIFICACIÓN, VALIDACIÓN Y TESTING (M. G. MERAYO Y M. NÚÑEZ) 11

 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) 12

 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) 13

 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) 14

 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) 15

Nivel 1 de pensamiento
El propósito de testing es mostrar corrección.

Desgraciadamente, la corrección esimposible 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) 16
 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) 17
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) 18
 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) 19

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
¡¡Warning!! (psicológicamente) para buscar
Esto está
errores en nuestro propio trabajo.
cambiando con la aparición
En particular, elde
programa puede tener errores
las metodologías ágiles.debido a que el
programador no ha comprendido el enunciado del problema o su
especificación.
ESPECIFICACIÓN, VALIDACIÓN Y TESTING (M. G. MERAYO Y M. NÚÑEZ) 20
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) 21

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) 22
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) 23

¿Por qué testeamos el
software?

MANUEL NÚÑEZ
ESPECIFICACIÓN, VALIDACIÓN Y TESTING
 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. ◦ Mandos a distancia.
◦ Sistemas de control de tráfico aéreo. ◦ Reproductores de DVD.
◦ Naves espaciales. ◦ Mandos de garage.
◦ Relojes. ◦ Teléfonos móviles.
◦ Hornos.

ESPECIFICACIÓN, VALIDACIÓN Y TESTING (M. G. MERAYO Y M. NÚÑEZ) 25

 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) 26

 Software es ubicuo

ESPECIFICACIÓN, VALIDACIÓN Y TESTING (M. G. MERAYO Y M. NÚÑEZ) 27

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) 28
 Faults, errors & failures: Ejemplo
Un paciente le enumera al médico un lista de La mayoría de los
síntomas. problemas médicos
◦ Failures. provienen o de ataques
externos (bacterias,
virus) o de la
El médico intenta diagnosticar la causa de la
dolencia. degradación natural
◦ Fault. debida al
envejecimiento.

El médico puede buscar condiciones anómalas Software faults estaban

internas (presión arterial alta, arritmias, allí desde el principio y
bacterias en el torrente sanguíneo). no “aparecen” cuando
◦ Errors. una componente se
“gasta”.
ESPECIFICACIÓN, VALIDACIÓN Y TESTING (M. G. MERAYO Y M. NÚÑEZ) 29
 Fault: La búsqueda

Otro ejemplo debería empezar en 0,

no en 1

public static int numZero (int [ ] arr) Test 1

{ // Effects: If arr is null throw NullPointerException [ 2, 7, 0 ]
// else return the number of occurrences of 0 in arr Esperado: 1
int count = 0; Observado: 1
for (int i = 1; i < arr.length; i++)
{ Error: i es 1, no 0, en Test 2
if (arr [ i ] == 0) la primera iteración [ 0, 2, 7 ]
{ Failure: ninguno Esperado: 1
count++; Observado: 0
}
} Error: i es 1, no 0
return count; 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) 30

 BUG
El término 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
Seguro que todos conocéis thing gives out and [it is] then that 'Bugs'—
como apareció el término as such little faults and difficulties are
called—show themselves and months of
bug. ¿Algún voluntario? intense watching, study and labor are
requisite. . .” – Thomas Edison (1878)

ESPECIFICACIÓN, VALIDACIÓN Y TESTING (M. G. MERAYO Y M. NÚÑEZ) 31

 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). Diseño de THERAC-25
Testing es una forma de evaluar la
fiabilidad de un sistema.
ESPECIFICACIÓN, VALIDACIÓN Y TESTING (M. G. MERAYO Y M. NÚÑEZ) 32
 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
Necesitamos que nuestro software sea a 16-bit costó unos
fiable (dependable). $370 millones.
Testing es una forma de evaluar la
fiabilidad de un sistema.
ESPECIFICACIÓN, VALIDACIÓN Y TESTING (M. G. MERAYO Y M. NÚÑEZ) 33
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
$6.000.000.000.

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) 34

 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) 35
 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) 36
 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) 37

 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) 38

 A esta pregunta ya
Por tanto… hemos respondido

Software testing es cada vez más importante.

Se nos plantean al menos dos preguntas.

¿Qué intentamos ¿Cuáles son

hacer cuando nuestros objetivos a
testeamos? la hora de testear?
ESPECIFICACIÓN, VALIDACIÓN Y TESTING (M. G. MERAYO Y M. NÚÑEZ) 39
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) 40

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) 41

 ¿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 demantener”.

¿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) 42

 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.
Encargados de proyecto poco responsables podrían
decir: “Testing es demasiado caro.”
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.

ESPECIFICACIÓN, VALIDACIÓN Y TESTING (M. G. MERAYO Y M. NÚÑEZ) 43

60
El precio de testear tarde
Asumimos $1000 por fallo, 100 fallos
50
40
Origen del fallo (%)
30
Detección del fallo (%)
20
Coste unitario de
10
arreglar el fallo (X)
0

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) 44

 Conclusión: ¿Por qué testeamos
el software?
El objetivo del Incrementa la calidad.
testeador debe
ser eliminar los Reduce el coste.
fallos (faults) lo
antes posible. Mantiene/incrementa la
satisfacción del cliente.

¿Por qué?

ESPECIFICACIÓN, VALIDACIÓN Y TESTING (M. G. MERAYO Y M. NÚÑEZ) 45