CAPITULO 2

Técnicas de Prueba del Software

Fundamentos de las pruebas del software

Por Julio C. Alsina

Ingeniería de Software
 Pruebas de Software

Probar es el proceso de ejercitar un programa

con el objetivo específico de encontrar
errores antes de entregarlo al usuario final

Ingeniería de Software
 Caracteristicas para la Facilidad de
Pruebas de Software
• Operabilidad – cuanto mejor funcione, con mayor eficacia
podrá probarse
• Observación – lo que se ve es lo que se prueba, los estados
y las variables pueden consultarse durante la ejecución,
identificando salidas inconsistentes
• Controlabilidad – el grado al cual la prueba puede ser
automatizada y optimizada
• Descomponibilidad – el SW se construye con modulos
independientes que tambien se prueban independientemente
• Simplicidad – reducir arquitecturas complejas y lógicas
para simplificar las pruebas
• Estabilidad – a menos cambios, menos alteracion en pruebas
• Comprensión – del diseño de arq.y dependencia de
componentes internos y externos

Ingeniería de Software
 Características de una Buena Prueba

• Una buena prueba tiene una elevada probabilidad

de encontrar un error. El responsable de aplicar la
prueba debe comprender correctamente el Sw
• Una buena prueba no es redundante. Los recursos
son limitados y no hay razón para realizar una
prueba que tenga el mismo propósito que otra
• Una buena prueba debe ser “la mejor de su clase”.
Usar aquella que tiene la mayor probabilidad de
descubrir un tipo completo de errores
• Una buena prueba no debe ser ni muy simple ni
demasiado compleja. Cada prueba debe ejecutarse
por separado

Ingeniería de Software
 Qué muestran las pruebas

errors
Errores
Conformidad de
requirements requerimientos
conformance

Rendimiento
performance

anIndicador de
indication
of quality
calidad

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

Ingeniería de Software
 Pruebas exhaustivas

loop < 20 X
Existen 1014 caminos
posibles! Si ejecutamos
una prueba cada
milisegundo, tomaría
años probar este
programa!!!
Ingeniería de Software
 Pruebas selectivas

Camino seleccionado
Selected path

loop < 20 X

Ingeniería de Software
 Pruebas de Software

Mé todos de Mé todos de
Caja Blanca Caja Negra

Mé todos

Estrategias
Basado en un exámen del detalle
procedimental. Prueba las rutas
lógicas del SW y la colaboración
entre componentes
Se aplican sobre la interfaz del
SW. Examina el aspecto
funcional sin analizar estructura
lógica interna

Ingeniería de Software
 Diseño del caso de
prueba

OBJETIVO Descubrir errores

CRITERIO De una manera completa

LIMITACIONES
En mínimo tiempo y esfuerzo

Ingeniería de Software
 Pruebas de Caja
Blanca
… nuestros objetivos son:
• Asegurar que todas las
declaraciones y condiciones han
sido ejectuadas por lo menos una
vez
• Ejercitar lado verdadero y falso
de todas las decisiones
• Ejecutar todos los bucles en sus
limites y dentro de limites operac.
• Ejercitar estructuras de datos
internos para asegurar su validez

Ingeniería de Software
 Por qué cubrir?

• Errores lógicos e interpretaciones incorrectas

son inversamente proporcionales a la
probabilidad de ejecución de un camino
• A menudo creemos que un camino
probablemente no será ejecutado; de hecho, la
realidad es que a menudo es intuitivo
• Los errores tipográficos son al azar; es
probable que un camino no probado contendrá
algunos

Ingeniería de Software
 Prueba de Camino de
Base
Primero, calculamos la complejidad
ciclomática:
Nro. de decisiones simples + 1
O
Nro. de áreas incluídas + 1
En ese caso, V(G) = 4
Complejidad Ciclomatica: es una métrica de Sw
que proporciona una medida cuantitativa de la
complejidad lógica de un programa

Ingeniería de Software
 Complejidad Ciclomática

Un número de estudios de la industria han indicado

que cuanto mas alto el V(G), mas alta será la
probabilidad de errores.

Módulos

V(G)

Los módulos en este rango son mas propensos a los

errores

Ingeniería de Software
 Prueba de Camino de Base
Para continuar, derivamos los
caminos independientes:
1

Dado que V(G) = 4, hay cuatro

2 caminos

4
3
Camino 1: 1,2,3,6,7,8
5 6 Camino 2: 1,2,3,5,7,8
Camino 3: 1,2,4,7,8
Camino 4: 1,2,4,7,2,4,…7,8
7
Finalmente, derivamos los casos de prueba
8
para ejercitar estos caminos garantizando que
se ejecuta cada instrucc.al menos una vez.
Ingeniería de Software
 Prueba de Camino de
Base

• No es necesario un diagrama de
flujo, pero el diagrama ayudará
cuando se tracen los caminos de
programa
• Contar cada prueba lógica simple,
componer pruebas de 2 o mas
• Prueba de camino de base debería
aplicarse a los módulos críticos

Ingeniería de Software
 Pruebas de Estructuras de Control

• Prueba de Condición: intenta ejercitar las

condiciones lógicas contenidas en un modulo
de programa.
• Prueba de Flujo de Datos: selecciona rutas de
prueba de un programa de acuerdo a ubicación
de las definiciones y uso de variables del
programa.
• Prueba de Bucles: se concentra en la validez
de la construccion de los bucles o ciclos.

Ingeniería de Software
 Pruebas de Bucles

Bucle
Simple
Bucle
Anidado
Bucles
Concatenados Bucles no
estructurados
Ingeniería de Software
 Pruebas de Bucles: Bucles Simples

Condiciones Simples

3. Saltar el bucle completo

4. Solo uno pasa a través del bucle
5. Dos pasan a través del bucle
6. m pasa a través del bucle m < n
7. (n-1), n y (n+1) pasan a través del bucle

donde n es el número máximo de pasadas aceptables

Ingeniería de Software
 Pruebas de Bucles: Bucles Anidados

Bucles Anidados
2. Comenzar en el bucle mas interno. Poner todos los demás bucles
externos a sus mínimos valores de iteración.
3. Probar el mínimo + 1, el valor típico, máximo + 1 y el máximo para
el bucle mas interior, mientras se mantienen los bucles externos a
sus mínimos valores
4. Descartar un bucle y volver al como en el paso 2, manteniendo todos
los otros bucles en sus valores típicos. Continuar este paso hasta que
el bucle mas externo haya sido probado

Bucles Concatenados
Si los bucles son independientes de otro, entonces tratarlos como un
bucle simple, de lo contrario, tratarlos como bucles anidados.
Por ejemplo: el valor final del contador del bucle 1 es utilizado para
inicializar el bucle 2

Ingeniería de Software
 Prueba de la Caja Negra

… nuestro
Requerimientos
objetivo es:
• Derivar conjuntos
de condiciones de
Salida entrada que
ejercitarán por
completo todos los
requisitos
Entrada Eventos funcionales de un
programa

Ingeniería de Software
 Partición Equivalente

Consultas Formatos Entradas Entrada

de FK
usuario Picos de de por
datos
ratón salida pantalla

… divide el dominio de entrada del programa en clases de datos a

partir de los cuales pueden derivarse casos de prueba
Ingeniería de Software
Ejemplo de Clases de Equivalencia

Datos Válidos
• Comandos proveídos por el usuario
• Respuestas a pedidos del sistema
• Nombres de Archivo
• Datos computacionales
 Parámetros Físicos
 Valores de Límites
 Valores de inicialización
• Formato de datos de salida
• Respuestas a mensajes de error
• Datos gráficos (por ej. Picos de ratón)

Datos Inválidos
•Datos fuera de los límites del programa
•Datos físicamente imposibles
•El valor correcto dado en un lugar incorrecto

Ingeniería de Software
 Análisis de Valor Límite

“Alto % de los errores se presentan en límites de entrada”

Consultas Formatos Entradas Entrada

de FK
usuario Picos de de por
datos
ratón salida pantalla

Dominio de
Dominio de Entrada Salida

Ingeniería de Software
 Otras Técnicas de Caja Negra

• Métodos de Adivinamiento de
Errores
• Técnicas de Tablas de Decisión
• Graficamiento causa-efecto

Ingeniería de Software
 Pruebas de Entornos Especializados

Pruebas de Interfaces Graficas de Usuario (GUI)

 Han crecido en su complejidad. Debido a que muchas de las GUI
modernas tienen aspecto y modo de uso similares, es posible derivar
una serie de pruebas estándar. Existen herramientas para prueba GUI
Prueba de Arquitecturas Cliente/Servidor
 La naturaleza distribuida, el desempeño relacionado con el proceso
de transacción, posibilidad de variadas plataformas de Hw,
complejidad de la comunicación de red; son aspectos a considerar.
Pruebas de la Documentación y Funciones de Ayuda
 Errores de documentación y ayuda al usuario son devastadores para
la aceptación del Sw, si no coinciden entre sí
Pruebas de Sistemas de Tiempo Real
 Se deben probar el manejo de eventos, la temporización de los datos
y el paralelismo entre procesos que manejan los datos.

Ingeniería de Software
Pruebas de Software - Resumen

Ingeniería de Software
 Métodos de Pruebas Orientadas a Objetos

CLASE

Atributos

Operaciones

… probar un Sistema OO en diferentes niveles para descubrir

errores que ocurren a medida que las clases colaboran entre si
Ingeniería de Software
 Implicaciones del Concepto Orientado a Objetos

• Debido a que los atributos y las operaciones están encapsulados, las

operaciones de prueba fuera de la clase suelen ser improductivas
• La herencia plantea desafíos adicionales debido a que cada nuevo
contexto de uso requiere una nueva prueba
• Es posible usar el conjunto de casos de prueba derivado de la
superclase cuando se prueba la subclase
• Sin embargo si ésta se emplea en un contexto completamente nuevo,
los casos de prueba de la superclase no serán aplicables y será
necesario diseñar nuevas pruebas
• Los métodos de prueba de Caja Blanca pueden ser aplicados a las
operaciones definidas de una clase
• Los métodos de prueba de Caja Negra son tan apropiados para los
sistemas OO como los que se desarrollan para métodos
convencionales

Ingeniería de Software
 Pruebas Orientadas a Objetos

• Prueba basada en fallas: el responsable busca aspectos

de la implementación del sistema que generen defectos.
Esto requiere diseñar casos de prueba que revisen el
diseño o el código. Pueden encontrarse 3 tipos de fallas:
resultado inesperado, operación incorrecta e invocación
incorrecta.
• Prueba basada en escenarios: se concentra en lo que
hace el usuario, no el producto. Debe capturar las tareas
que el usuario tiene que realizar y luego aplicarlas junto
con sus variantes, como pruebas.

Ingeniería de Software
 Pruebas Aplicables a Nivel de Clase

• Prueba Aleatoria a Nivel de Clase: definir el historial de

comportamiento mínimo de una instancia de la clase. Ej.
Clase CUENTA, abrir.configurar.depositar.retirar.cerrar
Es posible generar al azar varias secuencias diferentes de
operaciones. Ejercitar cada una de ellas.
• Prueba de Partición al Nivel de Clase: ejercita la clase
de manera parecida a la Partición Equivalente. Pueden
ser: Basada en Estado (ordena las operaciones de clase
basada en su capacidad para cambiar el estado de la
clase), Basada en Atributos (ordena las operaciones de
clase basada en los atributos que utilizan) y Basada en
Categorías (ordena las operaciones de clase en base a la
función genérica que cada una realiza).
Ingeniería de Software
 Pruebas de Interclase

La prueba de colaboración entre clases se lleva a cabo al

aplicar métodos aleatorios y de partición, además de
pruebas basadas en el escenario y de comportamiento

• Prueba de Clases Múltiples: generar varios casos de

prueba aleatorios de clases múltiples en base a la lista de
operaciones de clase, a la clase colaboradora, los
mensajes que transmiten y las operaciones invocadas por
estos.
• Prueba Derivadas de Modelos de Comportamiento: el
diagrama de estado de una clase ayuda a derivar una
secuencia de pruebas que revisa el comportamiento
dinámico de la clase y aquellas que colaboran con ella.
Ingeniería de Software
 Resumen

• El objetivo del diseño de casos de prueba consiste en

derivar conjuntos de prueba que tenga la mayor
probabilidad de descubrir errores en el software
• Las pruebas de Caja Blanca se concentran en la
estructura de control del programa
• Las pruebas de Caja Negra validan requisitos funcionales
sin importar el funcionamiento interno del programa
• Los métodos de prueba de Entornos Especializados
abarcan una amplia serie de opciones de software y áreas
de aplicación.
• Aunque el objetivo general de la Prueba OO es idéntico a
la del Sw. Convencional las tácticas difieren un poco.

Ingeniería de Software