CAPITULO 3

ESTRATEGIAS DE PRUEBA DEL

SOFTWARE

Un enfoque estratégico para las pruebas del software

Por Julio C. Alsina

Ingeniería de Software
 Un Enfoque Estratégico para Pruebas

Propuestas:
Para realizar pruebas efectivas un equipo de Sw.debe efectuar RTF y
efectivas. Esto eliminará muchos errores antes de las pruebas.
La prueba comienza a nivel de componentes y trabaja “hacia fuera”,
hacia la integración de todo el sistema de computo.
Diferentes técnicas de prueba son apropiadas en diferentes momentos
La prueba la dirige el desarrollador del software y un grupo
independiente de pruebas (proyectos grandes)
La prueba y la depuración son actividades diferentes, pero la depuración
debe incluirse en cualquier estrategia de prueba.
Una estrategia de prueba debe incluir “pruebas de bajo nivel”(a nivel de
código) y de “alto nivel” (funciones del sistema)

Ingeniería de Software
 Quien prueba el Software?

Desarrollador Pruebas independientes

Entiende el sistema pero Debe aprender acerca del
probará “suavemente” y está sistema, pero intentará
guiado por la “entrega” romperlo y está guiado por la
calidad

Si el Ing.Sw. no encuentra los errores ¡ El cliente si lo hará !...

Ingeniería de Software
 Afirmaciones Incorrectas

 El responsable del desarrollo no debería participar

en el proceso de pruebas

 El software debe ponerse a salvo de extraños que

lo prueben

 Quienes aplican las pruebas sólo deben participar

en el proyecto cuando vayan a darse los primeros
pasos de esas pruebas

Ingeniería de Software
 Estrategia de Pruebas
Pruebas de Unidad Pruebas de Integración

Codigo Diseño

Ing.de Sistema Requisitos

Pruebas de Pruebas de
Sistema Validación

Ingeniería de Software
 Estrategia de Prueba de Sw Orientadas a Objetos

CLASE 1 CLASE 2 CLASE 3

Atributos ...… Atributos + Atributos

Operaciones Operaciones Operaciones

Pruebas … Pruebas de Regresión

… Por último se prueba el sistema como un todo para asegurarse

de que se descubran errores en los requisitos
Ingeniería de Software
 Criterios para Completar la Prueba

Cuando
terminamos
las pruebas ?

“… Nunca se termina de aplicar una prueba”

… Cada vez que el cliente o el usuario ejecutan el programa de

computadora, este se esta probando.
Ingeniería de Software
 Pruebas de Unidad

Módulo
a ser
probado

Resultados
Ingeniero de
Software Casos de
Prueba

Ingeniería de Software
 Pruebas de Unidad

Módulo
a ser
probado Interfase
(flujo de informacion hacia adentro/afuera del programa)
Estructuras locales de datos
(datos locales mantíenen integridad durante la ejecucion del programa)
Condiciones de límites
(modulo opera ok en los limites establecidos p/restrigir procesamiento)
Caminos independientes
(asegurar que todos los caminos se ejecutan por lo menos una vez)

Caminos de manejo de errores

(los errores probables tienen buen tratamiento y finalizacion adecuada)

Casos de prueba

Ingeniería de Software
 Que deben descubrir los casos de prueba?

 Comparaciones entre diferentes tipos de datos.

 Operadores lógicos o precedencia de estos aplicada
incorrectamente.
 Expectativa de igualdad cuando los errores de
precisión son improbables
 Comparación incorrecta de variables.
 Terminación inapropiada de o inexistente de bucles.
 Falla de salida en iteración divergente
 Variables de bucle modificadas de manera inapropiada

Ingeniería de Software
 Manejo Correcto de Errores

Debe tener cuidado de no cometer las sigtes. fallas:

 La descripción del error es ininteligible.

 El error indicado no corresponde al encontrado.
 La condición de error causa la intervención del S.O.
antes de que se dispare el manejo de errores.
 El procesamiento de la condición de excepción es
incorrecto.
 La descripción del error no proporciona información
suficiente para ayudar a localizar la causa del error.
Ingeniería de Software
 Ambiente de Pruebas de Unidad

Controlador
Interfase
Estructuras locales de datos

Módulo Condiciones de límites

Caminos independientes
Caminos de manejo de errores

Resguardo Resguardo

Casos de Prueba

Resultados
Ingeniería de Software
 Controladores y Resguardos

 Un Controlador no es más que un “programa principal” que

acepta los datos del caso de prueba, pasa estos datos al
componente que se está probando e imprime los resultados.
 Los Resguardos sirven para reemplazar módulos
subordinados al componente que habrá de probarse (o
llamados por éste). Los resguardos usan la interfaz del modulo
subordinado, realizan una mínima manipulación de datos,
proporcionan verificación de la entrada y devuelven el control
al módulo en prueba.
“Representan sobrecarga de trabajo pues requieren construirse para
realizar las pruebas, pero no se entregan con el producto final”

Ingeniería de Software
 Estrategias de Pruebas de Integración

Opciones:
• el enfoque “big bang”
• una estrategia de construcción incremental

Ingeniería de Software
 Pruebas de Integración

 Enfoque “big bang” implica combinar todos los

componentes, probando el programa como un todo, lo
cual puede generar caos al detectar múltiples errores
que dificultan la corrección, debido a su extensión.
 La “integración incremental” sugiere construir y
probar en pequeños incrementos, en los cuales resulta
más fácil aislar y corregir errores, llegandose
finalmente a probar la totalidad de los componentes y
sus interfaces.

Ingeniería de Software
 Integración de Arriba-Abajo

A El módulo mas alto es probado con

resguardos

B F G

Los resguardos son reemplazados uno a

C la vez, “primero en profundidad” o
“primero en anchura”

A medida que nuevos módulos se integran,

D E algunos sub-grupos de pruebas se realizan
nuevamente

Ingeniería de Software
 Integración de Abajo-Arriba

B F G

Los controladores son reemplazados una

a la vez, “el mas profundo primero”
C

Los módulos de trabajo están

D E
integrados y agrupados

Grupo
Ingeniería de Software
 Pruebas de Sandwich

A
Los módulos más altos son
probados con resguardos

B F G

Los módulos de trabajo están

D E integrados y agrupados

Grupo
Ingeniería de Software
 Prueba de Regresion

“Cada vez que se agrega un nuevo modulo como parte de una

prueba de integración, el software cambia”
“… ejecutar nuevamente el mismo subconjunto de
pruebas que ya se han aplicado para asegurarse de que
los cambios no han propagado efectos indeseables”
El conjunto de pruebas de regresión contiene 3 casos dif. de prueba:
• Muestra representativa de pruebas que ejercerán todas las func.del Sw
• Pruebas adicionales centradas en las funciones afectadas por el cambio
• Pruebas centradas en los componentes del Sw.que cambiaron

A medida que avanza la prueba de integración, la cantidad de

pruebas de regresión llega a volverse muy grande!!
Ingeniería de Software
 Estrategias de Prueba para Software OO

• Al pensar en el Sw.OO cambia el concepto de unidad. Cada

clase e instancia de una clase (objeto) empaqueta atributos y
operaciones.
• Sin embargo las unidades de prueba mas pequeñas son las
operaciones dentro de la clase. Una clase puede contener varias
operaciones y una operación puede existir en varias clases dif.
• No es posible probar una sola operación en forma aislada,
sino como parte de una clase.
• A diferencia de la prueba de unidad del Sw. Convencional
que se centra en el detalle algoritmico de un modulo, la prueba
de clase para Sw.OO se orienta a las operaciones que
encapsula y en el comportamiento de estado de la clase.
Ingeniería de Software
 Prueba de Integracion en el Contexto OO

• El Sw.OO no tiene una estrategia de control jerárquico. Por

tanto no tiene sentido estrategias de integr.Ascend/Descend.

•Hay dos estrategias dif. para la prueba de Integr. de Sist.OO:

 Prueba basada en subprocesos: conjunto de clases requerido
para responder a una entrada o un evento del sistema. Cada
subproceso se integra y valida individualmente.
 Prueba basada en el uso: se empieza la construcción del
sistema con las pruebas de clases independientes. Luego se
prueba la siguiente capa de clases llamadas dependientes,
usadas por las clases independientes. Se sigue esta secuencia
de capas de prueba de clases dependientes hasta construir todo
el sistema.
Ingeniería de Software
 Pruebas de Alto Orden

Prueba de Validación
Prueba Alfa y Beta

Pruebas de Sistema

Otras pruebas especializadas

Ingeniería de Software
 Pruebas de Validacion

• Empiezan al culminar las pruebas de integración. En este

nivel desaparece la distinción entre Sw. convencional y
orientado a objetos.
• La validación del Sw.se logra mediante una serie de pruebas
que demuestran que se cumple con los requisitos.
• Luego de dirigir cada caso de prueba de validación, existirá
una de dos condiciones posibles:
 La característica de funcionamiento o desempeño cumple
con la especificación y se le acepta
 Se descubre una desviación de la especificación y se
crea una lista de deficiencias. La corrección de las
deficiencias debe ser negociada con el cliente.
Ingeniería de Software
 Pruebas Alfa y Beta

• Son conducidas por el usuario final, no por los Ing.Sw.

• Pueden ir desde una prueba de manejo informal hasta una
serie de pruebas planeadas y ejecutadas sistemáticamente.
 Pruebas Alfa: se aplican en el lugar de trabajo del
desarrollador. Se realizan en un entorno controlado. El
desarrollador “mira sobre el hombro” de los usuarios y
registra los errores y los problemas de uso.
 Pruebas Beta: se aplican en el lugar de trabajo de los
usuarios finales. Por lo general el desarrollador no esta.
Es una aplicación en vivo del Sw. en un entorno no
controlado por el desarrollador. El usuario registra todos
los problemas encontrados y los informa al
desarrollador.
Ingeniería de Software
 Pruebas de Sistema
• Su propósito principal es ejercitar profundamente el sistema.
 Pruebas de Recuperación: obliga al Sw. A fallar de varias maneras
y a verificar que la recuperacion se realice apropiadamente.
Considerar Re-inicializacion, Respaldo, Recup.Datos, NuevoArranque.
 Pruebas de Seguridad: prueba que los mecanismos de proteccion
integrados en el sistema realmente lo protejan de irrupciones
inapropiadas (hackers por razones de diversión, empleados
disgustados por venganza o busqueda ilícita de ganancias) .
 Pruebas de Resistencia: ejecuta un sistema de tal manera que
requiera una cantidad , una frecuencia o un volumen anormal de
recursos. En esencia, se tratará de sobrecargar el programa. Se
propone confrontar el programa con situaciones anormales.
 Pruebas de Desempeño: esta diseñada para probar el desempeño
del Sw.en tiempo de ejecución dentro del contexto de un sistema
integrado. Solamente cuando estén totalmente integrados todos los
elementos del sistema, será posible asegurar el verdadero
desempeño del sistema. Con frecuencia suelen integrarse con
pruebas de resistencia y suelen requerir instrumentación de Sw y
Hw.
Ingeniería de Software
 Depuración: un proceso de diagnóstico

Cuando un caso de prueba descubre un error, la depuración es

la acción que lo elimina!!
Ingeniería de Software
 El proceso de depuración

Ejecución de Casos
Casos de prueba

Pruebas Adicionales Resultados

Sospechas de Causas
Pruebas de Regresión
Correcciones
Depuración
Causas Identificadas

Ingeniería de Software
 Esfuerzo de Depuración

Tiempo requerido
para diagnosticar el
síntoma y
Tiempo requerido determinar la causa
para corregir el error
y conducir pruebas de
regresión

Ingeniería de Software
 Síntomas y Causas

Síntoma y causa pueden estar

separados geográficamente

El síntoma puede desaparecer cuando

se arregla otro problema
El sintoma podria deberse a un error
humano dificil de localizar
La causa puede deberse a un error
de sistema o de compilador
Síntoma La causa puede deberse a supuestos
Causa que todos creen
El síntoma puede ser intermitente

Ingeniería de Software
 Consecuencias de los Errores

infeccioso
Daño

catastrófico
extremo
serio
disturbios
leve
suave

Tipo de Bug

Categorías de errores: errores de función, errores de

sistema, errores de datos, errores de código, errores de
diseño, de documentación, violaciones estándar, etc.

Ingeniería de Software
 Técnicas de Depuración

Fuerza bruta / pruebas

Volver atrás

Eliminación de Causa
- Inducción o Deducción

Ingeniería de Software
 Técnicas de Depuración

•Fuerza Bruta: método mas común y menos eficiente para aislar la causa
de un error. Se hace descarga de memoria, se invocan señales en tiempo de
ejecución, etc. En algún lugar del pantano de información producida se
espera encontrar una pista que pueda conducir a la causa del error.
•Rastreo hacia Atrás: empezando en el lugar donde se descubre el
síntoma, se recorre hacia atrás el código fuente hasta hallar el sitio de la
causa. Al aumentar las líneas de código, este método se vuelve
inmanejable.
•Eliminación de Causa: los datos relacionados con el error se organizan p/
aislar las causas posibles. Elabora una hipótesis de causa y se aprovechan
los datos mencionados para probar o desechar la hipótesis. Se elabora una
lista de causas posibles y con pruebas se busca eliminar cada una de ellas.
•Depuración Automatizada: se cuenta con una amplia variedad de
compiladores de depuración, ayudas dinámicas para la depuración
(trazadores), generadores automáticos de casos de prueba y herramientas de
correlación de referencias cruzadas. Sin embargo, las herramientas no son
un sustituto de la evaluación cuidadosa basada en un modelo de diseño
completo y un código fuente claro.
¡Cuando todo lo demás falle, pida ayuda!
Ingeniería de Software
 Depuración: Conclusiones

• Piense acerca del síntoma que está viendo

• Utilice herramientas (por ej. Depurador
dinámico) para tener mayor detalle
• Si está perdido, consiga ayuda
• Esté absolutamente seguro de realizar
pruebas de regresión cuando se “arregla” el
bug.

Ingeniería de Software