Pruebas

Algoritmos para la solución de

problemas

Semana 7
 Agenda

• Errores de software

• ¿Por qué probar?

• Conceptos generales
• Tipos de pruebas
 Errores de software

• Pérdida de datos Gitlab (2018)

• “Ver como” de Facebook (2018)
• Apagón de amazon (2017)
• Cambios en las cuentas de ahorro en
un Banco local (2013)
• Millas Lan (2010)
 ¿Por qué probar?

• Para evitar defectos

• Para evitar fallos
• Para evitar sobrecostos
• Para evitar trabajo innecesario
 Conceptos generales

• Error
Equivocación cometida por un programador
• Defecto
Es el resultado de una deficiencia o error durante la construcción de
un software
• Fallo
Incapacidad del software (o una de sus partes) para realizar sus
funciones especificadas.
 Relación entre error, defecto y fallo

Error (del
programador)

Defecto (en el
software)

Fallo (el sistema

no se comporta
según lo
especificado)

Efectos negativos
 Algunos errores típicos

• División entre cero

• Bucles infinitos
• Desbordamiento por tipo de dato
• Bloqueo mutuo
• Desbordamiento de arreglo
 Verificación- Validación

• Verificación
Proceso de análisis y revisión de que el software cumple los
objetivos establecidos desde un principio.
• Validación
Proceso de evaluación del software para determinar si cumple lo
esperado por el cliente.
 Inspección - Prueba

• Inspección
Proceso en el que se revisa el código para encontrar defectos.
• Prueba
Proceso en el que se busca demostrar que el sistema hace lo que
debe hacer, localizando errores y/o anomalías.
 ¿Cuándo se inspecciona y cuándo se prueba?

• Se inspecciona durante el proceso de construcción de software.

• Se prueba cuando se tiene un entregable funcional o cuando se
tienen prototipos.
 ¿Quién debe hacer las pruebas?

• Equipo de desarrollo
-Es menos costoso
-Conocen qué deben probar
Puede haber un sesgo al probar
• Equipo de pruebas
-Es más costoso
-Se puede hacer en paralelo junto con la construcción
-Es más objetivo
 Depuración (debugging)

• Útil para eliminar los bugs encontrados

• El conjunto de datos de entrada y de salida sirven para brindar
soluciones.
• Lo realiza el equipo de desarrollo.
• Debe estar contemplado en el cronograma.
“Las pruebas solo pueden
demostrar la presencia de
errores, más no su ausencia.”

(Dijkstra et al., 1972)

Tipos de pruebas

Tomado de https://www.h2kinfosys.com/blog/software-testing-classification/
Tipos de pruebas

Tomado de https://www.h2kinfosys.com/blog/software-testing-classification/
 Pruebas de caja blanca vs Pruebas de caja negra

• Caja blanca
-Se analiza como el procedimiento va pasando parte por parte
- Se puede hacer a distintos niveles (granularidad)
• Caja negra
-Sólo enfocarse en entradas VS salidas esperadas
- Se ve el componente/módulo sin el detalle interno.
Tipos de pruebas

Tomado de https://www.h2kinfosys.com/blog/software-testing-classification/
 Pruebas unitarias

Se debe probar el objeto (o módulo) por completo.

 Pruebas de componentes

Se enfocan en el uso de las interfaces entre los componentes. Además,

se pone a prueba la arquitectura del sistema.
Tipos de pruebas

Tomado de https://www.h2kinfosys.com/blog/software-testing-classification/
 Pruebas de integración

Se prueba el sistema en su totalidad.

• TopDown
Se va probando la funcionalidad desde el módulo principal hasta los módulos
inferiores.
• BottomUp
Se prueban los módulos de menor jerarquía primero. Luego se van probando los que
de mayor jerarquía
• Sandwich
Combinación de TopDown & BottomUp.
• BigBang
Se prueban los módulos individuales y luego se junta todo
Tipos de pruebas

Tomado de https://www.h2kinfosys.com/blog/software-testing-classification/
 Pruebas de aceptación del usuario

Pruebas para determinar que ya se puede pasar el sistema a

producción
• Pruebas Alfa

Se trabaja con un sistema que aún está en desarrollo, junto con el equipo.
• Pruebas Beta
Se permite el uso libre de usuarios al sistema para que experimenten
 Casos de prueba

• Ejecución de un método bajo unas condiciones particulares (valores

de los parámetros + estado de la clase)
• El resultado permite determinar si, para este caso particular, la clase
se ha comportado acorde a su especificación.
• En general el número de posibles casos de prueba es muy alto
(muchas veces infinito) .
• Objetivo de la prueba de clases:
• Encontrar el mayor número de defectos posible utilizando un número
“pequeño” de casos de prueba.
 Bibliografía

• https://dzone.com/articles/the-biggest-software-failures-in-recent-
years
• Material de clases del curso de Sistemas de información 2 de la
PUCP
Gracias.