1

Estrategia, tcnicas y mtodos de prueba clsicos....................................................2

1.1
Un enfoque estratgico para las pruebas del software.......................................2
1.1.1
Verificacin y validacin (V&V)..............................................................3
1.1.2
Organizacin para las pruebas del software..............................................3
1.1.3
Una estrategia de prueba del software.......................................................3
1.1.4
Criterios para completar la prueba............................................................4
1.2
Aspectos estratgicos.........................................................................................4
1.3
Prueba de unidad...............................................................................................4
1.3.1
Consideraciones sobre la prueba de unidad...............................................4
1.3.2
Procedimientos de Prueba de unidad.........................................................5
1.4
Prueba de integracin........................................................................................5
1.4.1
Integracin descendente............................................................................5
1.4.2
Integracin ascendente..............................................................................6
1.4.3
Prueba de regresin...................................................................................6
1.4.4
Prueba de humo.........................................................................................6
1.4.5
Comentarios sobre la prueba de integracin.............................................6
1.5
Prueba de validacin..........................................................................................7
1.5.1
Criterios para la prueba de validacin.......................................................7
1.5.2
Revisin de la configuracin.....................................................................7
1.5.3
Pruebas alfa y beta.....................................................................................7
1.6
Prueba del sistema.............................................................................................7
1.6.1
Prueba de recuperacin..............................................................................7
1.6.2
Prueba de seguridad...................................................................................7
1.6.3
Prueba de resistencia (Stress)....................................................................8
1.6.4
Prueba de rendimiento...............................................................................8
1.7
Fundamentos de las pruebas del software.........................................................8
1.7.1
Objetivo de las pruebas.............................................................................8
1.7.2
Principios de las pruebas...........................................................................8
1.7.3
Facilidad de prueba....................................................................................9
1.8
Diseo de casos de prueba...............................................................................10
1.9
Prueba de Caja Blanca.....................................................................................10
1.10 Prueba del Camino Bsico...............................................................................10
1.10.1
Notacin del grafo de flujo......................................................................10
1.10.2
Complejidad ciclomtica.........................................................................11
1.10.3
Obtencin de casos de pruebas................................................................11
1.10.4
Matrices de grafos...................................................................................12
1.11 Prueba de la estructura de control...................................................................12
1.11.1
Prueba de condicin................................................................................12
1.11.2
Prueba de flujo de datos..........................................................................13
1.11.3
Prueba de bucles......................................................................................13
1.12 Prueba de Caja Negra......................................................................................14
1.12.1
Mtodos de prueba basados en grafos.....................................................14
1.12.2
Particin equivalente...............................................................................14
1.12.3
Anlisis de valores lmite........................................................................15
1.12.4
Prueba de comparacin............................................................................15
1.12.5
Prueba de la tabla ortogonal....................................................................15
1.13 Prueba de Entornos Especializados, Arquitecturas y Aplicaciones.................15
1.13.1
Prueba de interfaces grficas de usuario (IGUs).....................................15
1.13.2
Pruebas de arquitectura cliente / servidor................................................15
1.13.3
Pruebas de la documentacin y facilidades de ayuda..............................15

1.13.4
Prueba de sistemas de tiempo-real..........................................................15
2
Pruebas orientadas a objetos................................................................................16
2.1
Ampliando la visin de las pruebas.................................................................16
2.2
Pruebas de los Modelos de AOO y DOO........................................................16
2.2.1
Exactitud de los modelos AOO y DOO...................................................16
2.2.2
Consistencia de los modelos AOO y DOO..............................................16
2.3
Estrategias de Prueba Orientadas a Objetos....................................................17
2.3.1
Las pruebas de unidad en el contexto de la OO......................................17
2.3.2
Las pruebas de integracin en el contexto OO........................................17
2.3.3
Pruebas de validacin en un contexto OO...............................................17
2.4
Diseo de Casos de Prueba para software OO................................................17
2.4.1
Implicaciones de los conceptos de OO al diseo de casos de prueba.....18
2.4.2
Aplicabilidad de los mtodos convencionales de diseo de casos de
prueba 18
2.4.3
Pruebas basadas en errores......................................................................18
2.4.4
El impacto de la programacin OO en las pruebas.................................18
2.4.5
Casos de prueba y jerarqua de clases.....................................................18
2.4.6
Diseo de pruebas basadas en el escenario.............................................18
2.4.7
Las estructuras de pruebas superficiales y profundas..............................19
2.5
Mtodos de Prueba aplicables a nivel de Clases.............................................19
2.5.1
La verificacin al azar para clases OO....................................................19
2.5.2
Prueba de particin al nivel de clases......................................................19
2.6
Diseo de Casos de prueba Interclase.............................................................19
2.6.1
Prueba de mltiples clases.......................................................................19
2.6.2
Prueba derivada de los modelos de comportamiento..............................20
3
Pruebas de entornos especializados.....................................................................20
4
Patrones de prueba...............................................................................................20
5
Documentacin de pruebas..................................................................................20
5.1
Plan de pruebas..............................................................................................20

1 Estrategia, tcnicas y mtodos de prueba clsicos.

Una estrategia de prueba del software integra las tcnicas de diseo de casos de
prueba en una serie de pasos bien planificados que dan como resultado una
correcta construccin del software.

1.1

Un enfoque estratgico para las pruebas del software

Las pruebas son un conjunto de actividades que se pueden planificar por

adelantado y llevar a cabo sistemticamente. Se debe definir en el proceso de
ingeniera del software una plantilla para las pruebas del software: un conjunto de
pasos en los que podamos situar los mtodos especficos de diseo de casos de
prueba:
Plantilla para la prueba:
Las pruebas comienzan a nivel de mdulo y trabajan "hacia fuera", hacia la
integracin de todo el sistema basado en computadora

Segn el momento, son apropiadas diferentes tcnicas de prueba.

La prueba la lleva a cabo el responsable del desarrollo del software y un
grupo independiente de pruebas.
La prueba y la depuracin son actividades diferentes, pero la depuracin se
debe incluir en cualquier estrategia de prueba.

1.1.1 Verificacin y validacin (V&V)

Verificaci n : se refiere al conjunto de actividades que aseguran que el

software implementa correctamente una funcin especfica.
Validaci n: se refiere a un conjunto diferente de actividades que aseguran
que el software construido se ajusta a los requisitos del cliente.

La verificacin y la validacin abarcan una amplia lista de actividades de SQA

(garanta de calidad del software) que incluyen:
1. revisiones tcnicas formales
2. auditorias de calidad y de configuracin
3. monitorizacin de rendimientos
3. simulacin
4. estudios de factibilidad
5. revisin de la documentacin
6. revisin de la base de datos
7. anlisis de algoritmos
8. pruebas de desarrollo
9. pruebas de validacin
10. pruebas de instalacin
La calidad se incorpora en el software durante el proceso de ingeniera del software.
La calidad se confirma durante las pruebas.

1.1.2 Organizacin para las pruebas del software

Desde un punto de vista psicolgico, el anlisis y el diseo del software son tareas
constructivas.
Cuando comienza la prueba, aparece una sutil, aunque firma intencin de "romper"
lo que el ingeniero a construido.
El responsable del desarrollo del software siempre es responsable de probar las
unidades individuales (mdulos) del programa, asegurndose de que cada una lleve
a cabo la funcin para la que fue diseada. Solo una vez que la arquitectura del
software est completa entra en juego un grupo independiente de prueba.
Grupo independiente de prueba (GIP) : Una prueba independiente elimina el
conflicto de intereses.

1.1.3 Una estrategia de prueba del software

El proceso de ingeniera del software se puede ver como una espiral. Inicialmente,
la ingeniera de sistemas define el papel del software y conduce al anlisis de los
requisitos del software, donde se establece el dominio de informacin, la funcin, el
comportamiento, el rendimiento, las restricciones y los criterios de validacin del
software.
Tambin se puede ver la estrategia para la prueba del software en el contexto de la
espiral:

La prueba de unidad , comienza en el vrtice de la espiral y se centra en

cada unidad del software, tal como est implementada en cdigo fuente.
La prueba de inte graci n , donde el foco de atencin es el diseo y la
construccin de la arquitectura del software.
La prueba de validaci n , donde se validan los requisitos del software,
comparndolos con el sistema que ha sido construido. El software satisface
todos los requisitos funcionales, de comportamiento y de rendimiento.
La prueba del sistema , en la que se prueban como un todo el software y
otros elementos. Cada elemento encaja de forma adecuada y que se alcanza
la funcionalidad y el rendimiento del sistema total.

1.1.4 Criterios para completar la prueba

"La prueba nunca termina, ya que el responsable del desarrollo del software carga
o pasa el problema al cliente"
"Se termina la prueba cuando se agota el tiempo o el dinero disponible a tal efecto"
Mediante el modelado estadstico y la teora de fiabilidad del software, se pueden
desarrollar modelos de fallos del software.
Modelo logartmico de Poisson de tiempo de ejecucin:
F(t) = (1/p) * ln[(l 0 pt+1)]
F(t) es nmero acumulado de fallos que se espera.
l0 es la intensidad de fallos inicial del software al principio de la prueba.
p es la reduccin exponencial de intensidad de fallo a medida que se encuentran los
errores y se van haciendo las correcciones.

1.2

Aspectos estratgicos

Implementar con xito una estrategia de prueba del software:

Establecer los requisitos del producto de manera cuantificable mucho antes
de que comiencen las pruebas
Establecer los objetivos de la prueba de manera explicita
Comprender que usuarios van a manejar el software y desarrollar un perfil
para cada categora de usuario
Desarrollar un plan de prueba que haga hincapi en la "prueba de ciclo
rpido".
Construir un software "robusto" diseado para probarse a si mismo.
Usar revisiones tcnicas formales efectivas como filtro antes de la prueba.
Llevar a cabo revisiones tcnicas formales para evaluar la estrategia de
prueba y los propios casos de prueba
Desarrollar un enfoque de mejora continua al proceso de prueba. Debera
medirse la estrategia de prueba

1.3

Prueba de unidad

La prueba de unidad centra el proceso de verificacin en la menor unidad del diseo

del software: el componente software o mdulo.

1.3.1 Consideraciones sobre la prueba de unidad.

1. Se prueba la interfaz del mdulo
2. Se examinan las estructuras de datos locales
3. Se prueban las condiciones lmite

4. Se ejercitan todos los caminos independientes

5. Se prueban todos los caminos de manejo de errores.
Antes de iniciar cualquier otra prueba es preciso probar el flujo de datos de la
interfaz del mdulo.
Se deben disear casos de prueba para detectar errores debidos a clculos
incorrectos comparaciones incorrectas o flujos de control inapropiados.
La prueba de lmites es la ltima tarea del paso de la prueba de unidad.

1.3.2 Procedimientos de Prueba de unidad

Un controlador no es ms que un "programa principal" que acepta los datos del
caso de prueba, pasa estos datos al mdulo e imprime los resultados importantes.
Los controladores y resguardos son una sobrecarga de trabajo.

1.4

Prueba de integracin

La prueba de integracin es una tcnica sistemtica para construir una estructura

del programa mientras que, al mismo tiempo, se lleva a cabo pruebas para detectar
errores asociados con la interaccin.
La integracin incremental es la anttesis del enfoque del "big bang". El programa
se construye y se prueba en pequeos fragmentos en los que los errores son mas
fciles de aislar y corregir, es mas probable que se puedan probar completamente
las interfaces y se puede aplicar un enfoque de prueba sistemtica.

1.4.1 Integracin descendente

La prueba de integracin descendente es un planteamiento incremental a la
construccin de la estructura de programas. Se integran mdulos movindose hacia
abajo por la jerarqua de control, comenzando por el mdulo de control principal
(programa principal).
La integracin primero-en-profundidad integra todos los mdulos de un camino de
control principal de la estructura.
La integracin primero-en-anchura incorpora todos los mdulos directamente
subordinados a cada nivel, movindose por la estructura de forma horizontal.
El proceso de integracin se realiza en una serie de cinco pasos:
1. Se usa el mdulo de control principal como controlador de la prueba,
disponiendo de resguardos para todos los mdulos directamente
subordinados al mdulo de control principal.
2. Dependiendo del enfoque de integracin se van sustituyendo uno a uno los
resguardos subordinados por los mdulos reales.
3. Se llevan a cabo las pruebas cada vez que se integra un nuevo mdulo real
4. Tras terminar cada conjunto de pruebas, se reemplaza otro resguardo con el
mdulo real.
5. Se hace la prueba de regresin para asegurarse de que no se han
introducido errores nuevos.
En una estructura de programa bien fabricada, la toma de decisiones se da en los
niveles superiores de la jerarqua y, por lo tanto, se encuentran errores antes.

1.4.2 Integracin ascendente

Empieza la construccin y la prueba con los mdulos atmicos y se elimina la
necesidad de resguardos.
Se puede implementar una estrategia de integracin ascendente mediante los
siguientes 4 pasos:
1. Se combinan los mdulos de bajo nivel en grupos que realicen una
subfusin especfica del software.
2. Se escribe un controlador para coordinar la entrada y la salida de los casos
de prueba.
3. Se prueba el grupo.
4. Se eliminan los controladores y se combinan los grupos movindose hacia
arriba por la estructura del programa.

1.4.3 Prueba de regresin

Cada vez que se aade un nuevo modulo como parte de una prueba de integracin,
el software cambia. Se establecen nuevos caminos de flujo de datos, pueden ocurrir
nuevas E/S y se invoca una nueva lgica de control.
La prueba de regresin es volver a ejecutar un subconjunto de pruebas que se han
llevado a cabo anteriormente para asegurarse de que los cambios no han
propagado efectos colaterales no deseados.
La prueba de regresin es la actividad que ayuda a asegurar que los cambios no
introducen un comportamiento no deseado o errores adicionales.

1.4.4 Prueba de humo

La prueba de humo es un mtodo de prueba de integracin que es comnmente
utilizada cuando se ha desarrollado un producto de software "empaquetado".
Actividad es de la prueba de humo:
1. Los componentes software que han sido traducidos a cdigo se integran en
una "construccin". Una construccin incluye ficheros de datos, libreras,
mdulos reutilizables y componentes de ingeniera que se requieren para
implementar una o ms funciones del producto.
2. Se disea una serie de pruebas para descubrir errores que impiden a la
construccin realizar su funcin adecuadamente. El objetivo ser descubrir
errores "bloqueantes" que tengan mayor probabilidad de impedir al proyecto
de software el cumplimiento de su planificacin.
3. Es habitual en la prueba de humo que la construccin se integre con otras
construcciones y que se aplique una prueba de humo al producto completo.
La integracin pude hacerse bien de forma descendente (top-down) o
ascendente (bottom-up).

1.4.5 Comentarios sobre la prueba de integracin

Un modulo crtico es aquel que tiene una o ms de las siguientes caractersticas:
Est dirigido a varios requisitos del software
Tiene un mayor nivel de control
Es complejo o propenso a errores
Tiene unos requisitos de rendimiento muy definidos

1.5

Prueba de validacin

La validacin puede definirse de muchas formas, pero una simple definicin es que
la validacin se consigue cuando el software funciona de acuerdo con las
expectativas razonables del cliente, las cuales estn definidas en la Especificacin
de Requisitos del Software.

1.5.1 Criterios para la prueba de validacin

Una vez que se procede con cada caso de prueba de validacin, puede darse una de
las dos condiciones siguientes:
1. Las caractersticas de funcionamiento o de rendimiento estn de acuerdo
con las especificaciones y son aceptables.
2. Se descubre una desviacin de las especificaciones y se crea una lista de
deficiencias.

1.5.2 Revisin de la configuracin

La intencin de la revisin es asegurarse de que todos los elementos de la
configuracin del software se han desarrollado apropiadamente, se han catalogado
y estn suficientemente detallados para soportar la fase de mantenimiento durante
el ciclo de vida del software, a veces se denomina auditoria.

1.5.3 Pruebas alfa y beta

Cuando se construye software a medida para un cliente, se llevan a cabo una serie
de pruebas de aceptacin para permitir que el cliente valide todos los requisitos.

1.6

La prueba alfa : se lleva a cabo, por el cliente, en el lugar de desarrollo. Se

usa el software de forma natural con el desarrollador como observador del
usuario y registrando los errores y problemas de uso. Las pruebas alfa se
llevan a cabo en un entorno controlado.
La prueba beta : se lleva a cabo por los usuarios finales del software en los
lugares de trabajo de los clientes. La prueba beta es una aplicacin "en vivo"
del software en un entorno que no puede ser controlado por el desarrollador.
El cliente registra todos los problemas que encuentra durante la prueba beta
e informa a intervalos regulares al desarrollador.

Prueba del sistema

Un problema tpico de la prueba del sistema es la "delegacin de culpabilidad".

1.6.1 Prueba de recuperacin

La prueba de recuperacin es una prueba del sistema que fuerza al fallo del
software de muchas formas y verifica que la recuperacin se lleva a cabo
apropiadamente.

1.6.2 Prueba de seguridad

La prueba de seguridad intenta verificar que los mecanismos de proteccin
incorporados en el sistema lo protegern, de hecho, de accesos impropios. Con el
tiempo y recursos suficientes, una buena prueba de seguridad terminar por

acceder al sistema, el objetivo es hacer que el coste de la entrada ilegal sea mayor
que el valor de la informacin contenida.

1.6.3 Prueba de resistencia (Stress)

Las pruebas de resistencia estn diseadas para enfrentar a los programas con
situaciones anormales.
La prueba de resistencia ejecuta un sistema de forma que demande recursos en
cantidad, frecuencia o volmenes anormales.
Una variante de la prueba de resistencia es una tcnica denominada prueba de
sensibilidad. La prueba de sensibilidad intenta descubrir combinaciones de datos
dentro de una clase de entrada vlida que pueda producir inestabilidad o un
proceso incorrecto.

1.6.4 Prueba de rendimiento

La prueba de rendimiento esta diseada para probar el rendimiento del software en
tiempo de ejecucin dentro del contexto de un sistema integrado. Las pruebas de
rendimiento, a menudo, van emparejadas con las pruebas de resistencia, y
frecuentemente, requieren instrumentacin tanto del software como de hardware.

1.7

Fundamentos de las pruebas del software

El ingeniero crea una seria de casos de prueba que intentan "demoler" el software
construido. De hecho, las pruebas son uno de los pasos de la ingeniera del
software que se puede ver como destructivo en lugar de constructivo.

1.7.1 Objetivo de las pruebas

Objetivos:
1. La prueba es el proceso de ejecucin de un programa con la intencin de
descubrir un error.
2. Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar
un error no descubierto hasta entonces
3. Una prueba tiene xito si descubre un error no detectado hasta entonces.

1.7.2 Principios de las pruebas

A todas las pruebas se les debera poder hacer un seguimiento hasta los
requisitos del cliente
Las pruebas deberan planificarse mucho antes de que empiecen
El principio de Pareto es aplicable a la prueba del software
Las pruebas deberan empezar por lo "pequeo" y progresar hacia lo
"grande".
No son posibles las pruebas exhaustivas
Para ser eficaces, las pruebas deberan ser realizadas por un equipo
independiente

1.7.3 Facilidad de prueba

La facilidad de prueba del software es simplemente la facilidad con la que se puede
probar un programa de computadora. Como la prueba es tan profundamente difcil,
merece la pena saber que se puede hacer para hacerlo mas sencillo.
Operatividad : cuando mejor funcione, mas eficientemente se puede probar.
El sistema tiene pocos errores
Ningn error bloquea la ejecucin de las pruebas
El producto evoluciona en fases funcionales
Observabilidad : lo que se ve es lo que pruebas
Se genera una salida distinta para cada entrada
Los estados y variables del sistema estn visibles o se pueden consultar
durante la ejecucin
Los estados y variables anteriores del sistema estn visibles o se pueden
consultar
Todos los factores que afectan a los resultados estn visibles
Un resultado incorrecto se identifica fcilmente
Los errores internos se detectan automticamente a travs de mecanismos
de auto-comprobacin
El cdigo fuente es accesible
Controlabilidad : cuando mejor podamos controlar el software, mas se puede
automatizar y optimizar
Todos los resultados posibles se pueden generar a travs de alguna
combinacin de entrada
Todo el cdigo es ejecutable a travs de alguna combinacin de entrada
El ingeniero de pruebas puede controlar directamente los estados y las
variables del hardware y del software
Los formatos de las entradas y los resultados son consistentes y
estructurados
Las pruebas pueden especificarse, automatizarse y reproducirse
convenientemente.
Capacidad de descomposici n: controlando el mbito de las pruebas, podemos
aislar ms rpidamente los problemas y llevar a cabo mejores pruebas de
regresin.
El sistema de software est construido con mdulos independientes
Los mdulos del software se pueden probar independientemente
Simplicidad : cuando menos haya que probar, mas rpidamente podremos probarlo
Simplicidad funcional
Simplicidad estructural
Simplicidad de cdigo
Estabilidad : cuanto menos cambios, menos interrupciones a las pruebas
Los cambios del software son infrecuentes
Los cambios del software estn controlados
Los cambios del software no invalidan las pruebas existentes
El software se recupera bien de los fallos
Facilidad de comprensi n: cuanta mas informacin tengamos, mas inteligentes
sern las pruebas.
El diseo se ha entendido perfectamente
Las dependencias entre los componentes internos, externos y compartidos
se han entendido perfectamente
Se han comunicado los cambios del diseo
La documentacin tcnica es instantneamente accesible
La documentacin tcnica esta bien organizada
La documentacin tcnica es especifica y detallada
La documentacin tcnica es exacta

Atributos de una "buena" prueba:

1. Una buena prueba tiene una alta probabilidad de encontrar un error
2. Una buena prueba no debe ser redundante. El tiempo y los recursos para las
pruebas son limitados
3. Una buena prueba debera ser "la mejor de la cosecha"
4. Una buena prueba no debera ser ni demasiado sencilla, ni demasiado
compleja. En general, cada prueba debera realizarse separadamente

1.8

Diseo de casos de prueba

El producto debe probarse de 2 formas:

conociendo la funcione especfica para la que fue diseado el producto. La
prueba de "Caja Negra" se refiere a las pruebas que se llevan a cabo sobre
la interfaz del software. Los casos de prueba pretenden demostrar que las
funciones del software son operativas, que la entrada se aceptar de forma
adecuada y que se produce un resultado correcto, as como que la integridad
de la informacin externa se mantiene
Conociendo el funcionamiento del producto. La prueba de Caja Blanca
(funcin) se basa en el minucioso examen de los detalles procedimentales.
Se comprueban los caminos lgicos del software proponiendo casos de
prueba que ejerciten conjuntos especficos de condiciones y/o bucles. Se
puede examinar el "estado del programa" en varios puntos para determinar
si el estado real coincide con el esperado o mencionado.

1.9

Prueba de Caja Blanca

Es un mtodo de diseo de casos de prueba que usa la estructura de control del

diseo procedimental para obtener los casos de prueba:
1. Que garanticen que se ejercita por lo menos una vez todos los caminos
independientes de cada mdulo
2. Que se ejerciten todas las decisiones lgicas en sus vertientes verdadera y
falsa
3. Que se ejecuten todos los bucles en sus lmites y con sus lmites
operacionales
4. Que se ejerciten las estructuras internas de datos para asegurar su validez

1.10 Prueba del Camino Bsico

La prueba del camino bsico es una tcnica de prueba de caja blanca. El mtodo
del camino bsico permite al diseador de casos de prueba obtener una medida de
la complejidad lgica de un diseo procedimental y usar esa medida como gua
para la definicin de un conjunto bsico de caminos de ejecucin. Los casos de
prueba obtenidos del conjunto bsico garantizan que durante la prueba se ejecuta
por lo menos una vez cada sentencia del problema.

1.10.1

Notacin del grafo de flujo

El grafo de flujo representa el flujo de control lgico mediante la siguiente notacin:

Cada crculo, denominado nodo del grafo de flujo, representa una o mas sentencias
procedimentales.
Las flechas del grafo de flujo, denominadas aristas enlaces, representan flujo de
control y son anlogas a las flechas del diagrama de flujo.
Las reas delimitadas por aristas y nodos se denominan regiones. Cuando
contabilizamos las regiones incluimos el rea exterior del grafo, contando como otra
regin ms.
Cada nodo que contiene una condicin se denomina nodo predicado y est
caracterizado porque dos o ms aristas emergen de l.

1.10.2

Complejidad ciclomtica

La complejidad ciclomtica es una mtrica del software que proporciona una

medicin cuantitativa de la complejidad lgica de un programa. El valor calculado
como complejidad ciclomtica define el numero de Caminos Independientes del
conjunto bsico de un programa y nos da un lmite superior para el nmero de
pruebas que se deben realizar para asegurar que se ejecuta cada sentencia al
menos una vez.
Un camino independiente es cualquier camino del programa que introduce, por lo
menos, un nuevo conjunto de sentencias de proceso o una nueva condicin.
La complejidad se puede calcular de 3 formas:
1. El nmero de regiones del grafo coincide con la complejidad ciclomtica
2. La complejidad ciclomtica, V(G), de un grafo de flujo G se define como:
a. V(G) = A - N + 2 (donde N son los nodos y A las reas)
3. La complejidad ciclomtica, V(G), de un grafo de flujo G se tambin define
como:
a. V(G) = P + 1 (donde P son los nodos predicados)

1.10.3

Obtencin de casos de pruebas

El mtodo de prueba de camino bsico se puede aplicar a un diseo procedimental

detallado o a un cdigo fuente. En esta seccin, presentaremos la prueba del
camino bsico como una serie de pasos:
1. Usando el diseo o el cdigo como base, dibujamos el correspondiente grafo
de flujo
2. Determinamos la complejidad ciclomtica del grafo de flujo correspondiente
3. Determinamos un conjunto bsico de caminos linealmente independientes
4. Preparamos los casos de prueba que forzarn la ejecucin de cada camino
del conjunto bsico

Es importante darse cuenta de que algunos caminos independientes no se pueden

probar de forma aislada.

1.10.4

Matrices de grafos

Una matriz de grafo es una matriz cuadrada cuyo tamao es igual al nmero de
nodos del grafo de flujo. Cada fila y cada columna corresponde a un nodo especfico
y las entradas de la matriz corresponden a las conexiones entre los nodos.
Aadiendo un peso al enlace a cada entrada de la matriz, la matriz de grafo se
puede convertir en una potente herramienta para la evaluacin de la estructura de
control de programa durante la prueba. En su forma ms sencilla, el peso de enlace
es 1 0. Otras propiedades ms interesantes:
La probabilidad de que un enlace sea ejecutado
El tiempo de procesamiento asociado al recorrido de un enlace
La memoria requerida durante el recorrido de un enlace
Los recursos requeridos durante el recorrido de un enlace.

1.11 Prueba de la estructura de control

La tcnica de prueba del camino bsico es una de las muchas tcnicas para la
prueba de la estructura de control.

1.11.1Prueba de condicin
La prueba de condicin es un mtodo de diseo de casos de prueba que ejercita las
condiciones lgicas contenidas en el mdulo de un programa.
A una condicin sin expresiones relacionadas se al denomina Expresin lgica.
Si una condicin es incorrecta, entonces es incorrecto al menos un componente de
la condicin. As, los tipos de errores de una condicin pueden ser los siguientes:
Error en operador lgico
Error en parntesis lgico
Error en operador relacional
Error en expresin aritmtica
El mtodo de la prueba de condiciones se centra en la prueba de cada una de las
condiciones del programa. Las estrategias de prueba de condiciones tienen,
generalmente, dos ventajas:
1. La cobertura de la prueba de una condicin es sencilla
2. La cobertura de la prueba de las condiciones de un programa da una
orientacin para generar pruebas adicionales del programa
Estrategias de prueba de condiciones:
1. La prueba de ramificaciones
2. La prueba del dominio
3. BRO (prueba del operador relacional y de ramificaciones): garantiza la
deteccin de errores de operadores relacionales y de ramificaciones en una
condicin dada, en la que todas las variables lgicas y operadores
relacionales de la condicin aparecen slo una vez y no tienen variables en
comn.

1.11.2Prueba de flujo de datos

El mtodo de prueba de flujo de datos selecciona caminos de prueba de un
programa de acuerdo con la ubicacin de las definiciones y los usos de las
variables del programa.
Para una sentencia con S como nmero de sentencia:
DEF(S) = {X | la sentencia S contiene una definicin de X}
USO(S) = {X | la sentencia S contiene un uso de X}

1.11.3Prueba de bucles
La prueba de bucles es una tcnica de prueba de caja blanca que se centra
exclusivamente en la validez de las construcciones de bucles:
Bucles simples
Bucles concatenados
Bucles anidados
Bucles no estructurados

Bucles simples : a los bucles simples se les debe aplicar el siguiente conjunto de
pruebas, donde n es el nmero mximo de pasos permitidos por el bucle:
1. pasar por alto totalmente el bucle
2. pasar una sola vez por el bucle
3. pasar 2 veces por el bucle
4. hacer m pasos por el bucle con m < n
5. hacer n - 1 , n y n + 1 pasos por el bucle
Bucles anidados:
1. Comenzar por el bucle ms interior. Establecer o configurar los dems
bucles con sus valores mnimos.
2. Llevar a cabo las pruebas de bucles simples para el bucle ms interior,
mientras se mantienen los parmetros de iteracin de los bucles externos en
sus valores mnimos. Aadir otras pruebas para valores fuera de rango o
excluidos.
3. Progresar hacia fuera, llevando a cabo pruebas para el siguiente bucle, pero
manteniendo todos los bucles externos en sus valores mnimos y los dems
bucles anidados en sus valores "tpicos"
4. Continuar hasta que se hayan probado todos los bucles
Bucles concatenados : Los bucles concatenados se pueden probar mediante el
enfoque anteriormente definido para bucles simples.
Bucles no estructurados: se deben redisear para que se ajusten a las
construcciones de programacin estructurada.

1.12 Prueba de Caja Negra

Las pruebas de caja negra, tambin denominadas prueba de comportamiento, se
centran en los requisitos funcionales del software. Permite al ingeniero del software
obtener conjuntos de condiciones de entrada que ejerciten completamente todos
los requisitos funcionales de un programa. La prueba de caja negra intenta
encontrar errores de las siguientes categoras:
1. Funciones incorrectas o ausentes
2. Errores de interfaz
3. Errores en estructuras de datos o en accesos a base de datos externas
4. Errores de rendimiento
5. Errores de inicializacin y terminacin
Tiende a aplicarse durante las fases posteriores de la prueba, ya que la prueba de
caja negra ignora intencionalmente la estructura de control, centra su atencin en
el campo de la informacin
Casos de prueba:
1. Casos de prueba que reducen, en un coeficiente que es mayor que uno, el
nmero de casos de prueba adicionales que se deben disear para alcanzar
una prueba razonable.
2. Casos de prueba que nos dicen algo sobre la presencia o ausencia de clases
de errores en lugar de errores asociados solamente con la prueba que
estamos realizando.

1.12.1

Mtodos de prueba basados en grafos

Modelado del flujo de transaccin
Modelado de estado finito
Modelado del flujo de datos
Modelado de planificacin

Las pruebas basadas en grafos empiezan con la definicin de todos los nodos y
peso de nodos.
Una vez que se han identificado los nodos, se deberan establecer los enlaces y los
pesos de enlaces.
Cada relacin es estudiada separadamente, de manera que se puedan obtener
casos de prueba.

1.12.2

Particin equivalente

La particin equivalente es un mtodo de prueba de caja negra que divide el campo

de entrada de un programa en clases de datos de los que se pueden derivar casos
de prueba.
Una clase de equivalencia representa un conjunto de estados vlidos o no vlidos
para condiciones de entrada.
Las clases de equivalencia se pueden definir segn:
1. Se una condicin de entrada especifica un rango, se define una clase de
equivalencia vlida y dos no vlidas.
2. Si una condicin de entrada requiere un valor especfico, se define una clase
de equivalencia vlida y dos no vlidas.
3. Si una condicin de entrada especifica un miembro de un conjunto, se define
una clase de equivalencia vlida y una no vlida.
4. Si una condicin de entrada es lgica, se define una clase de equivalencia
vlida y una no vlida.

1.12.3

Anlisis de valores lmite

El anlisis de valores lmite es una tcnica de diseo de casos de prueba que

complementa a la particin equivalente.

1.12.4

Prueba de comparacin

Hay situaciones en las que la fiabilidad del software es algo absolutamente crtico.
En este tipo de aplicaciones, a menudo se utiliza hardware y software redundante
para minimizar la posibilidad de error.
Cuando se han producido mltiples implementaciones de la misma especificacin, a
cada versin del software se le proporciona como entrada los casos de prueba
diseados mediante alguna otra tcnica de caja negra.

1.12.5

Prueba de la tabla ortogonal

La prueba de la tabla ortogonal puede aplicarse a problemas en que el dominio de

entrada es relativamente pequeo pero demasiado grande para posibilitar pruebas
exhaustivas. Es til al encontrar errores asociados con fallos localizados. La tabla
ortogonal L9 tiene un "propiedad de equilibrio". Es decir, los casos de prueba
estn "uniformemente dispersos en el dominio de prueba".

1.13 Prueba de Entornos Especializados, Arquitecturas y

Aplicaciones
1.13.1

Prueba de interfaces grficas de usuario (IGUs)

Los grafos de modelado de estado finito pueden ser utilizados para realizar pruebas
que vayan dirigidas sobre datos especficos y programas objeto que sean relevantes
para las IGUs.

1.13.2

Pruebas de arquitectura cliente / servidor

1.13.3

Pruebas de la documentacin y facilidades de ayuda

Los errores en la documentacin pueden ser tan destructivos para la aceptacin del
programa, como los errores en los datos o en el cdigo fuente

1.13.4

Prueba de sistemas de tiempo-real

Estrategia de 4 pasos:
1. Prueba de tareas : el primer paso de la prueba de sistemas de tiempo real
consiste en probar cada tarea independientemente.
2. Pruebas de comportamiento : utilizando modelos del sistema creados con
herramientas CASE, es posible simular el comportamiento del sistema en
tiempo real y examinar su comportamiento como consecuencia de sucesos
externos.
3. Prueba intertareas : una vez que se han aislado los errores en las tareas
individuales y en el comportamiento del sistema, la prueba se dirige hacia
los errores relativos al tiempo.
4. Prueba del sistema : el software y el hardware estn integrados, por lo que
se lleva a cabo una serie de pruebas completas del sistema para intentar
descubrir errores en la interfaz software / hardware.

2
2.1

Pruebas orientadas a objetos.

Ampliando la visin de las pruebas

Una mala interpretacin de la definicin de la clase puede conducir a relaciones de

clases incorrectas o irrelevantes.
Durante las etapas finales de su desarrollo, los modelos de AOO y de DOO
proporcionan informacin substancial acerca de la estructura y comportamiento del
sistema.
Todos los modelos orientados a objetos deben ser probados, para asegurar la
exactitud, compresin y consistencia, dentro de la sintaxis, semntica y pragmtica
del modelo.

2.2

Pruebas de los Modelos de AOO y DOO

2.2.1 Exactitud de los modelos AOO y DOO

La exactitud sintctica se juzga en el uso apropiado de las simbologas; cada
modelo se revisa para asegurarse de que se han mantenido las convenciones
propias del modelo.
Las relaciones entre clases (conexiones de instancia) se evalan para determinar si
reflejan con exactitud conexiones del mundo real.

2.2.2 Consistencia de los modelos AOO y DOO

Debe juzgarse "considerando las relaciones entre entidades dentro del modelo".
Para evaluar la consistencia, se debe examinar cada clase y sus conexiones a otras
clases. Un modelo clase-responsabilidad-colaboracin (CRC), y un diagrama
objeto-relacin pueden utilizarse para facilitar esta actividad.
Cada tarjeta CRC muestra el nombre de la clase, sus responsabilidades
(operaciones) y sus colaboradores (otras clases a las que se envan mensajes y de
las cuales depende para el cumplimiento de sus responsabilidades)
El modelo de objeto-relacin proporciona una representacin grfica de las
conexiones entre clases. Toda esta informacin se puede obtener del modelo de
AOO.
Para evaluar el modelo de clases, se recomienda los siguientes pasos:
1. Revisar el modelo CRC y el modelo objeto-relacin. Realizar un control
cruzado, para asegurarse de que todas las colaboraciones implicadas en el
modelo AOO hayan sido representadas adecuadamente.
2. Inspeccionar la descripcin de cada tarjeta CRC, para determinar si alguna
responsabilidad delegada es parte de la definicin del colaborador.
3. Invertir la conexin para asegurarse de que colaborador que solicita un
servicio recibe las peticiones de una fuente razonable.
4. Utilizando las conexiones invertidas, ya examinadas en el paso 3,
determinar si otras clases se requieren y si las responsabilidades se han
repartido adecuadamente entre las clases.
5. Determine si las responsabilidades muy solicitadas, deben combinarse en
una sola responsabilidad.

6. Se aplican iterativamente los pasos 1 a 5 para cada clase y durante cada

evolucin del modelo de AOO.

2.3

Estrategias de Prueba Orientadas a Objetos

2.3.1 Las pruebas de unidad en el contexto de la OO

En vez de probar un mdulo individual, la unidad mas pequea comprobable es la
clase u objeto encapsulado.
No se puede probar mas de una operacin a la vez, pero si como parte de una
clase.
La prueba de clases para el software OO se conduce mediante operaciones
encapsuladas por la clase y el comportamiento de la clase.

2.3.2 Las pruebas de integracin en el contexto OO

Las pruebas basadas en hilos , se integran el conjunto de clases requeridas,

para responder una entrada o suceso al sistema. Cada hilo se integra y
prueba individualmente. Las pruebas de regresin se aplican para asegurar
que no ocurran efectos colaterales.
La prueba basada en el uso , comienza la construccin del sistema probando
aquellas clases, que utilizan muy pocas clases servidoras. Despus de que
las clases independientes se prueban, esta secuencia de prueba por capas
de clases dependientes contina hasta que se construye el sistema
completo.
La prueba de agrupamiento es una fase en las pruebas de integracin de
software OO. Aqu, un agrupamiento de clases colaboradores se prueban
diseando los casos de prueba, que intenta relevar errores en las
colaboraciones.

2.3.3 Pruebas de validacin en un contexto OO

Los casos de uso proporcionan un escenario, que tiene una gran similitud de
errores con los relevados en los requisitos de interaccin del usuario. Los mtodos
de prueba convencionales de caja negra pueden usarse para realizar pruebas de
validacin.

2.4

Diseo de Casos de Prueba para software OO

1. Cada caso de prueba debe ser identificado separadamente, y explcitamente

asociado con la clase a probar.
2. Debe declararse el propsito de la prueba
3. Debe desarrollarse un alista de pasos a seguir, como consecuencia de la
prueba, pero adems debe contener:
a. Definicin de una lista de estados, especficos para el objeto a probar
b. Una lista de mensajes y operaciones, que se ejercitarn como
consecuencia de las pruebas
c. Una lista de excepciones, que pueden ocurrir conforme el objeto se
comprueba
d. Una lista de condiciones externas
e. Informacin adicional

La prueba OO se enfoca en las secuencias de operaciones de diseo apropiadas

para probar los estados de una clase.

2.4.1 Implicaciones de los conceptos de OO al diseo de casos de

prueba
La clase es el objetivo del diseo de casos de prueba. La encapsulacin puede
dificultar un poco la obtencin de esta informacin.
La herencia tambin conduce a retos adicionales para el diseador de casos de
prueba.

2.4.2 Aplicabilidad de los mtodos convencionales de diseo de

casos de prueba
Los mtodos de "caja blanca" pueden aplicarse a las operaciones definidas para una
clase.
Los mtodos de prueba de "caja negra" son tan apropiados para los sistemas OO,
como los son para los sistemas desarrollados utilizando mtodos convencionales de
ingeniera del software.

2.4.3 Pruebas basadas en errores

Disear pruebas que tengan una alta probabilidad de revelar fallos.
Las pruebas de integracin buscan fallos probables en operaciones o mensajes de
conexin. Hay 3 tipos de fallos en este contexto:
Resultados inesperados
Uso incorrecto de operaciones / mensajes
Invocaciones incorrectas
Las pruebas de integracin se aplican tanto a atributos como a operaciones.

2.4.4 El impacto de la programacin OO en las pruebas

Cuando se invoca una operacin es difcil decir exactamente que cdigo se ejecuta.
Probar las operaciones de clases es anlogo a probar cdigo que toma a un
parmetro de la funcin y luego la invoca.
Los errores de integracin se vuelven ms probables.

2.4.5 Casos de prueba y jerarqua de clases

Las entradas de las pruebas deben ser apropiadas para las clases base y derivada,
pero los resultados esperados pueden diferir en la clase derivada.

2.4.6 Diseo de pruebas basadas en el escenario

Cuando ocurren errores asociados con especificaciones errneas, el producto no
realiza lo que el cliente desea.
Los errores asociados con la interaccin de subsistemas ocurren cuando el
comportamiento de un subsistema crea circunstancias que causan que el otro
subsistema falle.
Las pruebas basadas en el escenario se concentran en lo que el usuario hace.
Los escenarios revelan errores de iteracin.
Las pruebas basadas en el escenario tienden a validar subsistemas en una prueba

sencilla.

2.4.7 Las estructuras de pruebas superficiales y profundas

La estructura superficial se refiere a la estructura visible al exterior de un programa
OO. Esto es, la estructura que es inmediatamente obvia al usuario final.
En una interfaz basada en objetos, el verificador debe usar la lista de todos los
objetos, como una lista de control de pruebas.
El diseo de representaciones de jerarquas de clases proporciona una visin de la
estructura de herencia. La estructura jerrquica se utiliza en la verificacin basada
en errores.

2.5

Mtodos de Prueba aplicables a nivel de Clases

La prueba "en pequeo", se enfoca en una sola clase y los mtodos encapsulados
por ella. La verificacin y particin al azar son mtodos que pueden usarse para
ejercitar a una clase durante la prueba OO.

2.5.1 La verificacin al azar para clases OO

2.5.2 Prueba de particin al nivel de clases
Las entradas y salidas se clasifican, y los casos de prueba se disean, para validar
cada categora.

La particin basada en estados clasifica las operaciones de clase basada en

su habilidad de cambiar el estado de la clase.
La particin basada en atributos clasifica las operaciones de la clase en los
atributos que ellas usan.
La particin basada en categoras clasifica las operaciones de la clase
basadas en la funcin genrica que cada una lleva a cabo.

Las operaciones se dividen en 3 particiones:

1. Operaciones que utilizan (atributo)
2. Operaciones que modifican (atributo)
3. Operaciones que no utilizan o modifican (atributo)

2.6

Diseo de Casos de prueba Interclase

El diseo de casos de prueba se vuelve mas complicado cuando la integracin del

sistema OO comienza.

2.6.1 Prueba de mltiples clases

Generar casos de prueba aleatorios para mltiples clases:
1. Para cada clase cliente, utilice la lista de operaciones de clase, para generar
una serie de secuencias de pruebas al azar
2. Para cada mensaje que se genere, determine la clase colaboradora y la
operacin correspondiente en el objeto servidor
3. Para cada operacin en el objeto servidor (invocada por mensajes enviados
por el objeto cliente), determinar los mensajes que transmite
4. Para cada uno de los mensajes, determine el siguiente nivel de operaciones
que son invocadas, e incorpore stas a la secuencia de pruebas.

2.6.2 Prueba derivada de los modelos de comportamiento

El DTE (diagrama de transicin de estados) para una clase puede usarse para
ayudar a derivar una secuencia de pruebas, que ejercitarn el comportamiento
dinmico de la clase.
Las pruebas a disearse deben alcanzar una cobertura de todos los estados.
El modelo de estados puede ser recorrido "primero a lo ancho". En este contexto,
primero a lo ancho implica que un caso de prueba valida una sola transicin y
despus, cuando se va a verificar una nueva transicin, se utilizan slo las
transiciones previamente verificadas.

Pruebas de entornos especializados.

Patrones de prueba.

Documentacin de pruebas.

Como en toda fase, todos los elementos preparados para las pruebas y los
resultados de las mismas deben ser documentados y adjuntados a cada versin
correspondiente de los productos de las fases anteriores. Esta forma de proceder
evitar la repeticin de pruebas y facilitar la preparacin de nuevas pruebas a
partir de otras anteriores.

5.1

Plan de pruebas

Son un conjunto de actividades que pretenden demostrar que el producto cumple

con lo estipulado en el contrato. En el plan de pruebas se especifica:

Identificador del plan: debera ser una palabra que lo identificase con su
alcance. Debe incluir adems la versin y fecha.
Alcance: tipo de prueba y propiedades del software a ser probado.
Items a probar: configuracin a probar y condiciones que se deben satisfacer
para ello.
Estrategia: tcnica y herramientas que se van a utilizar. Hay que indicar el
nmero mnimo de casos de prueba que se van a realizar y el grado de
automatizacin tanto en la generacin de casos de prueba como en la
ejecucin
Categorizacin de la configuracin: condiciones bajo las cuales el plan debe
ser:

Suspendido: Si se presentan demasiados defectos o fallos.

Repetido.
Dador por terminado. Si se cumple el nmero mnimo de casos de
prueba.
Documentacin: Segn el estndar IEEE 829-1983 hay que producir los
siguientes documentos:
o Plan de prueba.
o Especificacin de los requerimientos para el diseo de los casos de
prueba.
o Casos de prueba. Para cada uno se especifican: el procedimiento de
prueba y descripcin del tem a probar.
o Bitcoras de pruebas.
o Informe de incidentes de prueba.
o Resumen de pruebas.
Procedimientos especiales: grafo de las tareas necesarias para preparar y
ejecutar las pruebas, as como habilidades necesarias.
Recursos: pueden ser muy variados
o Caractersticas de hardware y software.
o Software necesario para hacer las pruebas.
o El software bajo prueba.
o Configuracin del software de apoyo.
o Recursos humanos necesarios para el proceso.
o Requerimientos especiales: actualizacin de licencias, espacio de
oficina, tiempo de mquina, seguridad, etc.
Calendario: hitos del proceso y grafo de dependencias.
Riesgos: riesgos del plan, acciones para mitigarlos y planes de contingencia.
Responsables: lista de personas y tareas asignadas. Existen cuatro tipos de
pruebas que deben superarse
o Pruebas funcionales: se realizan con los datos de entrada normales
en el uso diario del sistema. Se comprueban sobre todo valores en
los lmites de las variables y un poco ms all de los lmites. Tambin
algunos valores especiales.
o Pruebas de desempeo: miden el rendimiento del sistema: tiempos
de respuesta, utilizacin de la memoria, trfico generado en las
comunicaciones, etc. Estas pruebas nos van a indicar dnde estn los
cuellos de botella del sistema.
o Pruebas de tensin: se trata de sobrepasar los lmites de tolerancia
del sistema de varias maneras, por ejemplo: conectar ms usuarios al
sistema de los permitidos, si se tienen que gestionar x mega-bits por
segundo de una lnea de comunicaciones probar a aumentar a x + 1,
etc.
o Pruebas estructurales: es un anlisis de la lgica interna de un
programa.
o
o
o