Introducción al testing de

software
Empecemos 2

• Escribe un conjunto de tests para la siguiente situación:

• 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), isósceles (2 lados iguales) y
escaleno (todos los lados son distintos).
Y seguimos 3

• Determina el conjunto de pruebas es adecuado para cubrir las

siguientes situaciones:
1. Un test para un triángulo escaleno válido.
1. Nota: Un test con entrada (1,2,3) o (2,5,10) no es validos
2. Un test para un triángulo equilátero válido.
3. Un test para un triángulo isósceles válido.
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.
Y mas situaciones a probar 4
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.
11. Un test con entrada (0, 0, 0).
12. Un test que incluya al menos un valor no entero (Por ej. 2.5).
13. Un test que indique un número incorrecto de valores (Por ej. dos valores
en lugar de tres).
Para cada test se ha especificado la salida esperada.
¿Esto es Testing de software? 5

• 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
Testing de software 6

• El 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.

El Testing consiste en ejecutar un programa con la intención

de encontrar errores.
Testing de software 7

• 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
(devuelva un valor inesperado, produzca una excepción no prevista,
etc).
• La calidad del software es el grado con el que un sistema, componente
o proceso cumple los requerimientos especificados y las necesidades o
expectativas del cliente o usuario. (IEEE, Std. 610-1990).
• Concordancia del software producido con los requerimientos
explícitamente establecidos, con los estándares de desarrollo prefijados
y con los requerimientos implícitos no establecidos formalmente, que
desea el usuario. (Pressman, 1998)
Definición de testing por niveles 8

• 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: El Testing es una disciplina mental que ayuda a que los
profesionales desarrollen software con más calidad.
Nivel 0: No hay diferencia entre testing y
debugging 9

• 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.
Nivel 1: El propósito de testing es mostrar
corrección 10

• Desgraciadamente, la corrección es imposible de conseguir.

• Si no detectamos fallos, ¿tenemos buen software o malos tests?
Nivel 2: El propósito de testing es mostrar
que el software no funciona 11

• El propósito es mostrar fallos.

• Buscar fallos es una actividad con negatividad.
• Enfrenta a los tester con los desarrolladores.
• ¿Qué ocurre si no hay fallos?
Nivel 3: El propósito de testing no es probar nada
específico, sino reducir los riesgos asociados con la 12
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.
Nivel 4: El Testing es una disciplina mental que
ayuda a que los profesionales desarrollen software 13
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.
Nociones a tener en cuenta a la hora de
testear 14

• Una parte necesaria a la hora de definir un test consiste en

proporcionar el resultado esperado.
• Por tanto, cada test debe tener dos componentes:
• 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 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.
Nociones a tener en cuenta a la hora de
testear 15

• La organización que desarrolla un programa no debería testear sus

propios programas.
• El proceso de testing se puede llegar a ver como responsable de
no completar el producto a tiempo y aumentar su costo.
• 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.
Nociones a tener en cuenta a la hora de
testear 16

• 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.
• 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.
¿Por qué testeamos el
17
software?
Faults, errors y failures 18

• 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.
Ejemplo 19

• 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.
El término bug 20

• 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

“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)
Ciclo de vida de los errores 21

Incidente

Fallo Casualidad Defecto

¿Algún problema en el software?
Robot Cirujano 22
Fallos espectaculares en software 23

• Noviembre de 2000 –
National Cancer Institute,
Ciudad de Panamá.
• El software de Multidata Systems
International, una empresa de
EE.UU, no calculó la dosis
correcta de radiación para los
pacientes sometidos a
radioterapia. Ocho personas
murieron
Fallos espectaculares en software 24

• El avión de China Airlines

A300 se estrello por un error
de software el 26 Abril de
1994, matando 264 personas.
Fallos espectaculares en software 25

• 8 de julio 1962 –
Mariner
• Un error en el software
de la sonda Mariner I
hace que el cohete se
desvíe de su trayectoria
cayendo sobre el
Océano Atlántico.
Fallos espectaculares en software 26

• 1982 – Gasoducto soviético.

• Una serie de acciones de
espionaje por parte de la CIA
para controlar el gaseoducto
transiberiano acabo instalando
un bug que provocó la mayor
explosión no nuclear de la
historia.
Fallos espectaculares en software 27

• 1985-1987 – Acelerador
médico Therac-25.
• Un error en el tratamiento de
radiación del dispositivo
proporcionó dosis letales de
radiación en varios centros
médicos. 3 personas murieron y
muchas otras se vieron
afectadas.
Fallos espectaculares en software 28

• 1988 – El gusano de Morris y

el desbordamiento de búfer.
• El primer gusano de Internet
(el Gusano de Morris) infectó
entre 2.000 y 6.000 ordenadores
en menos de un día,
aprovechando un
desbordamiento de buffer.
Fallos espectaculares en software 29

• 1988-1996 – El generador
de números aleatorios de
Kerberos.
• Los autores del sistema de
seguridad de
Kerberos cometieron un error
en el generador de números
aleatorios y durante ocho años
fue posible entrar en cualquier
ordenador que lo utilizara.
Fallos espectaculares en software 30

• 15 de enero 1990 – AT & T

caída de la red.
• Bug que colapsó 114
ordenadores, que se reiniciaban
cada seis segundos, dejando a
60.000 personas sin servicio
durante 9 horas
Fallos espectaculares en software 31

• 1993 – División en coma

flotante del Intel Pentium.
• Los procesadores fallaban en las
divisiones en coma flotante.
Intel tuvo que sustituir entre 3 y
5 millones de procesadores, 475
millones de dólares de pérdidas.
Fallos espectaculares en software 32

• 1995/1996 – El ping de la
muerte.
• Que hacía posible colgar
ordenadores enviando un ping
mal formado.
• El problema afecto a Macintosh y
Unix, pero los peor parados
fueron los Windows que al
recibir el ping mostraban
la “pantalla azul de la muerte”
Fallos espectaculares en software 33

• Noviembre de 2000 –
National Cancer Institute,
Ciudad de Panamá.
• El software de Multidata Systems
International, una empresa de
EE.UU, no calculó la dosis
correcta de radiación para los
pacientes sometidos a
radioterapia. Ocho personas
murieron
Fallos espectaculares en software 34

• El Mars lander de la NASA. Septiembre

de 1999, se estrelló debido a un fault
(defecto) al integrar unidades.
 Fallos espectaculares en software 35

• Apagón Noreste de Norteamérica (2003): Se

apagaron 508 generadores y 256 centrales
eléctricas, afectó a 10 millones en Ontario,
Canadá.Afectó a 40 millones en 8 estados de
USA. Se perdieron U$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.
 Fallos espectaculares en software 36

• En diciembre de 2006, una oferta BOGO

(Buy One Get One) de Amazon.com dió
lugar a un descuento doble.
Fallos espectaculares en software 37

• 04 de junio 1996 – Ariane 5

Vuelo 501.
• En la reutilización del software
del Ariane 4 para el Arian 5 se
obvió que había hardware
diferente, lo que provocó que el
cohete estallara. Uno de los
errores considerados más caros
de la historia.
• La pérdida costo U$ 500
millones.
Un poco mas del fallo de Ariane 5 38

• T0 - T0 + 36s : normal
• Dentro de SRI 2:
• BH (Bias Horizontal) > 215
• Conversión de dobles a entero (BH)
FALLA!
• El manejo de excepción SRI → provoca
un choque entre SRI 2 y 1
• OBC estaba desorientado
• ángulo > 20°, grandes limitaciones
aerodinámicas refuerzos que separan...
• T0 + 39s: autodestrucción
• costo: € 500M
Un poco mas del fallo de Ariane 5 ¿Por qué
paso? 39

• No es un error de programación
• Conversión mal realizada = Decisión de diseño (~1980)
• No es un error de diseño
• Justificado contra la trayectoria de Ariane 4 y las restricciones de RT
• Problema con las pruebas de integración
• Teóricamente detectable.
• Espacio de prueba vs. recursos limitados
• Además, ¡SRI inútil en esta etapa del vuelo!
• Reutilización de un componente con una restricción oculta
• Precondición : abs(BH) < 32768.0
• Válido para Ariane 4, pero ya no para Ariane 5
• Cohete más potente
Un poco mas del fallo de Ariane 5 ¿Qué
aprendimos? 40

• Test! Test! Test!

• Test! Even when the code is reused.
• When reuse, ensure the assumptions are still valid.
• When write reusable code, document the assumptions.
• Write fail-safe code.
• Do not propagate errors.
Fallos espectaculares en software 41

• 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.
• Pérdidas enormes debidas a fallos en aplicaciones web:
• Servicios financieros: U$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 2007 Symantec concluyó que la mayoría de las vulnerabilidades del
software se deben a software con fallos.
El precio de no testear 42

• 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
costo aumenta.
• Planificar el testing para después de finalizar el desarrollo es
prohibitivamente caro.
Costos de fallas 43

Implementación

Prueba

Codificación

Diseño

Requerimientos
Economia y Pruebas 44
• La realización de tareas de pruebas
conlleva un costo asociado que puede
inducir a tomar decisiones de no
realizarlas.
• No realizarlas también conlleva un
costo asociado.

• El problema es determinar cuál de

estos costos es mayor.
• Presuponemos que debemos tener
menores costos, menores tiempos de
desarrollo y mayor satisfacción del
cliente.
Software Verification and Validation for Practitioners and Managers, Second
Edition, Steven R. Rakitin, Artech House, 2001.
Reflexión 45

Carencia Problema
Herramientas
Herramienta Falta de productividad

Metodología Proceso caótico e

irrepetible
Recursos Humanos Falta de productividad
Capacitados
RRHH
Metodología
Capacitados
Una visión 46

• El software lo desarrollan las personas, y éstas comenten errores;

no se puede prevenir completamente la introducción de éstos
defectos, pero si se puede trabajar para localizarlos
especialmente los mas críticos.
• Decisiones de pruebas deberían basarse en satisfacción del
cliente. Este es el objetivo último.
• Mayor parte de los defectos se concentran en las etapas
tempranas del proceso de desarrollo y el costo de corrección
aumenta a medida que permanece no detectado.
• Los defectos mas costosos son aquellos que no se detectan.
Factores de éxito 47

• Ejecución modesta es tener un proceso con pocas piezas móviles, y las

partes están automatizados y simplificados.
• Experiencia en gestión de proyectos es la aplicación de conocimientos,
habilidades y técnicas a las actividades del proyecto con el fin de
satisfacer o superar las expectativas de las partes interesadas y producir
valor para la organización.
• Claros objetivos de negocio es la comprensión de todos los interesados y
participantes en el objetivo comercial para la ejecución del proyecto.
• Objetivos claros de negocios también podrían significar que el proyecto
se alinea con los objetivos y la estrategia de la organización.
Factores de éxito 48

• Apoyo Ejecutivo: Proporcionar tanto apoyo financiero y emocional.

• Madure emocional: Conjunto de comportamientos básicos de la forma de
trabajar en equipo.
• Participación del usuario: Los usuarios están involucrados en el proyecto de
toma de decisiones y la recopilación de información de procesos. Esto también
incluye comentarios de los usuarios, los requisitos de revisión, investigación
básica, desarrollo de prototipos, y otras herramientas de creación de consenso.
• La optimización es un medio estructurado de eficacia empresarial.
• El personal cualificado son personas que entienden el negocio y la tecnología.
• Un personal cualificado es altamente competentes en la ejecución de los
requisitos del proyecto y entregar del proyecto o producto.
Calidad 49

• Se puede concebir la calidad como

• Un valor:
• Es la cualidad del producto de satisfacer las necesidades del usuario
• El cumplimiento de atributos de calidad
Calidad según el punto de vista 50

• Usuario
• Satisfacer sus necesidades/expectativas
• Facilidades de aprendizaje y uso
• No presentar inconvenientes en lo que respecta a
• Frecuencia e impacto de fallas
• Tiempo medio de recuperación de fallas
Calidad según el punto de vista 51

• Desarrollador
• Cantidad y tipo de faltas
• Facilidad de entender
• Bajo impacto de las modificaciones
• Para el negocio
• Retorno de la inversión
Conclusión: ¿Por qué testeamos el software? 52

• El objetivo del testeador debe ser eliminar los fallos (faults) lo

antes posible.
• Incrementa la calidad.
• Reduce el costo.
• Mantiene/incrementa la satisfacción del cliente.
Validación y verificación (según IEEE) 53

• 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.
• El Testing se considera habitualmente una actividad de validación.
VyV 54

• Verificación:
• ¿Estamos construyendo el producto correctamente?
• ¿El software está de acuerdo con su especificación?
• Busca comprobar que el sistema cumple con los requerimientos.
• Validación:
• ¿Estamos construyendo el producto correcto?
• ¿El software cumple las expectativas del cliente?
• Busca comprobar que el software hace lo que el usuario espera.
Verificación 55

• Verificación
• Conjunto de actividades que aseguran que el software implementa
correctamente una función específica
• Intenta asegurar que el producto se construyó correctamente
• Cumple con las especificaciones
• Estática y Dinámica (testing)
Validación 56

• Validación
• Actividades que buscan asegurar si el software construido se ajusta a los
requisitos del cliente
• Intenta asegurar que se construyó el producto correcto
• Cumple con los requerimientos
¿Qué verificamos y validamos? 57

• Todas las cualidades relevantes del sistema deben ser verificadas:

• corrección: la implementación se comporta de acuerdo con las
especificaciones;
• portabilidad,
• modificabilidad,
• performance.
• etc.
¿Qué verificamos y validamos? 58

• La verificación debe realizarse por distintas personas durante

distintas etapas del desarrollo del software;
• La gente del equipo de desarrollo podría realizar esto.
¿Qué resultados tenemos después de la V y V? 59

• Después de hacer una serie de pruebas de verificación no se llega

a una conclusión tajante:
• “el producto está bueno y lo ponemos en comercialización”;
• “el producto está malo y debemos desecharlo”.
• Más bien se llega a tener una idea conceptual de la calidad del
software.
¿Qué resultados tenemos después de la V y V? 60

• Supuestos sobre la verificación de software:

• la presencia de defectos no puede evitarse en grandes sistemas de
software,
• a veces, algunos defectos pueden tolerarse,
• la corrección es relativa y difícil de evaluar.
¿Qué hacemos y cuando? 61
¿Por qué probamos? 62

• Para poner a prueba un programa puede usarse para mostrar la

presencia de errores, pero nunca para mostrar su ausencia.
• La construcción de software es un proceso colaborativo en el cual
intervienen actores que:
• Negocian expectativas en un contexto determinado
• Cometen errores
• El producto les sugiere nuevas ideas para construir
¿Para qué hacemos pruebas? 63

• Detectar incidentes, defectos, errores

• Evaluar la calidad de un producto
• Ayudar a la gerencia a tomar decisiones
• Verificar interoperabilidad
• Verificar la conformidad con estándares
• Minimizar los riesgos
¿Qué es la prueba de software? 64

• Es una investigación técnica orientada a proporcionar información

sobre la calidad de un producto de software para un actor o
usuario.
• Es una actividad cognitiva, no mecánica. Cem Karner
• Según Dijkstra: La prueba de un programa puede mostrar la
presencia de defectos, no la ausencia. Meyer afirma, las pruebas
son infinitas, y el objetivo es la búsqueda de errores.
• Boris Beizer afirma “Cualquier método que se use para prevenir o
encontrar bugs deja como residuo los más sutiles, contra los que
ese método no es efectivo”.
Planificación del proceso 65
Verificación de componentes

Verificación de Verificación de
unidades módulos

Validación

Verificación de Verificación de
sub-sistemas sistemas

Verificación de integración
Planificación del proceso de corregir errores 66

Diseñar la
Localizar el Corregir el Volver a
corrección
error error verificar
del error
A trabajar 67

• Para trabajar en clase: TP El robot asesino

• Para entregar: TP nro. 1