Prueba del camino basico

-Errores

(error) las personas cometen errores cuando codifican, los llamaremos bugs. Pueden ser errores de omisión

-Defectos

(faults or defects) es el resultado de un error. Es la representación de un error (código, narrativas, etc) 

-Falla:

(failure) ocurre cuando se ejecuta un defecto.
Pasa en loaded object code.¿Qué pasa con las omisiones?

-Incidente

(incident) síntoma asociado con una falla 

-Test:

Acto de ejercitar el software con casos de test 

-Casos de test

Elementos que poseen una identidad y están asociados con un comportamiento específico del programa. Tienen también una lista de entradas y salidas
Las técnicas de prueba intentan establecer una guía sistemática para desarrollar pruebas que:
–comprueben la lógica de los componentes
–verifiquen los dominios de entrada y salida del programa
*El SW se prueba desde 2 perspectivas:
–pruebas de caja blanca (lógica interna)
–pruebas de caja negra (requisitos del software)
Las pruebas son un paso “destructivo” 
– Una prueba tiene éxito si se encuentra un error no descubierto 
– Demuestra además como funciona el software de acuerdo con los requisitos 
– Los datos que se relevan en el proceso dan una indicación de la calidad del SW 
– Atención: las pruebas no pueden asegurar la ausencia de defectos!
– Las pruebas deben poder vincularse con los requisitos del cliente 
– Las pruebas deben planificarse antes de que empiecen 
– Deben ir de lo pequeño hacia lo grande 
– No son posibles las pruebas exhaustivas
Pruebas de caja negra (testing funcional)
-Se centran en los requisitos funcionales del software
-Se intentan encontrar defectos:
—Funciones incorrectas o ausentes
—Defectos de interfaz
—Defectos en estructuras de datos 
—Problemas inicialización y terminación
—Problemas de rendimiento
Se diseñan para responder a las siguientes preguntas:
– Cómo se prueba la validez funcional?
– Cómo se prueba el rendimiento y el comportamiento del sistema?
– Qué clases de entrada hacen buenos casos de prueba?
-El programa es considerado como una función
Testing de Valores Límite

Análisis de valores límite

Se focaliza en los límites del espacio de entrada para identificar test cases

Robustness testing

-Es una extensión simple del análisis de valores límites donde también se prueba max+ y min- 
-Fuerza a fijar la atención en el manejo de excepciones

Testing del peor caso

Queremos ver que pasa cuando más de una variable tiene un valor extremo

Testeo de casos especiales

Testeo de clases de equivalencia

Las clases de equivalencia de un conjunto forman una partición del mismo en conjuntos disjuntos tal que su unión es el conjunto original
Se logra el conjunto entero: completitud
Los conjuntos son disjuntos: se evita la redundancia
Los elementos de un conjunto tienen algo en común
Idea: identificar los casos de test usando un elemento de cada clase de equivalencia

Equivalencia débil

Usamos una variable de cada clase de equivalencia en un caso de test

Equivalencia fuerte

Se basa en realizar el producto cartesiano de los subconjuntos de particiones

Pruebas de caja blanca

 
– Las pruebas de caja blanca realizan un examen minucioso de los detalles procedurales 
-Se testean los caminos lógicos del software 
-Problema: es imposible realizar un testeo exhaustivo 
-Importancia: permite testear los caminos lógicos más importantes
Se usa la estructura de control del diseño procedural para derivar los casos de prueba.

Objetivos:

-Garantizar que todos los caminos independientes dentro de un módulo se han seguido 
– Probar todas las deciones lógicas en sus caminos verdadero y falso 
– Ejecutar todos los loops en sus límites 
– Probar las E de D internas
La razón de los DD-paths es que permiten especificar en forma precisa el cubrimiento de los casos de test

Prueba de la condicion

Ejercita las condiciones lógicas requeridas en el módulo de un programa 
– Detectan los errores en las condiciones del programa (en variables, operadores, etc)
-Puede además detectar otros errores

Prueba de bucles

 
– Se centra exclusivamente en la validez de las construcciones de bucles

Testeo del camino base

Permite derivar una medida de la complejidad lógica del diseño procedural y usarla para
Complejidad ciclomática
? Es una métrica del software que cuantifica la
complejidad lógica
? Define el nro de caminos independientes del
conjunto básico de un programa
? Nos da un límite superior del nro de pruebas
? Camino independiente: cualquier camino del
programa que introduce un nuevo conjunto de
sentencias (nuevo nodo) o una nueva condición
(nuevo arco)
Obtención de casos de prueba
? Usando el código como base calculamos
el grafo de flujo
? Determinamos la complejidad ciclomática
del gráfico resultante
? Determinamos el conjunto básico de
caminos independientes
? Preparamos los casos de prueba que
forzarán la ejecución de cada camino del
conjunto básico
Data flow testing
? Se refiere a formas de testeo estructural
que se focalizan en como las variables
reciben valores y como estos valores son
posteriormente usados

Cubrimiento de sentencias:

Todas las sentencias del programa deben ejercitarse

Cubrimiento de decisione:

Todas las decisiones en el control del programa deben ejercitarse al menos una vez por true, y al menos una vez por false

Cubrimiento de condiciones:

Todas las condiciones de todas las decisiones en el control del programa deben ejercitarse al menos una vez por true, y al menos una vez por false

Cubrimiento de caminos:

Todo camino del flujo de control del programa debe ejercitarse al menos una vez