PRUEBAS DEL SOFTWARE

INTRODUCCIN
Una de las caractersticas tpicas del desarrollo de software es la realizacin de
controles peridicos, normalmente coinciden con la terminacin de cada una de
las etapas, del producto o los documentos, estos controles pretenden hacer una
evaluacin de la calidad de los productos generados para poder detectar posibles
defectos. Sin embargo, todo producto software independientemente de estas
revisiones debe ser probado mediante su ejecucin controlada antes de la entrada
en produccin. Estas ejecuciones o ensayos de funcionamiento se denominan
pruebas.
Cuando se desarrolla software, dentro del ciclo de vida se ha establecido
formalmente que la prueba es una actividad fundamental dentro de cada una de
las etapas del proceso de desarrollo de software, porque a partir de la prueba se
determina la calidad de los productos implementados.
Desde hace mucho tiempo, la prueba ha sido un tema muy importante en la
ingeniera de software, por eso se presenta una revisin tcnica sobre la prueba
de software, abordando fundamentalmente los enfoques propuestos para probar
software construido bajo un enfoque funcional, orientado a objetos y basado en
componentes.
Las pruebas constituyen un mtodo de verificacin y validacin de software
cuando ya est en forma de cdigo ejecutable. Donde la verificacin se define
como el proceso de evaluacin de un sistema o de uno de sus componentes para
determinar si los productos satisfacen las condiciones impuestas al comienzo de
dicha fase, y la validacin hace referencia al proceso de evaluacin de un sistema
o de uno de sus componentes durante o al final del proceso de desarrollo para
determinar si satisface los requisitos especificados.

LA PRUEBA DEL SOFTWARE

La prueba es una actividad fundamental en los procesos de desarrollo de software
que permite al desarrollador determinar si el producto generado satisface las
especificaciones que han sido establecidas en el diseo, tambin las pruebas
permiten detectar la presencia de errores que pueden generar salidas o
comportamientos inapropiados durante su ejecucin.
De acuerdo a la IEEE, el concepto de prueba se define como una actividad en la
cual un sistema o componente es ejecutado bajo condiciones especficas, se
observan o almacenan los resultados y se realiza una evaluacin de algn aspecto
del sistema o componente. Para Myers el probar es el proceso de ejecutar un

programa con el fin de encontrar errores. Al hablar de condiciones especficas, se

supone una especie de ambiente de operacin de la prueba para el cual deben
existir determinados valores para las entradas y las salidas, as como tambin
ciertas condiciones que delimitan a dicho ambiente de operacin, formalmente
esto es conocido como Caso de Prueba.
El objetivo de las pruebas es la deteccin de errores o fallas y defectos en el
software, esta es una actividad a posteriori, para la deteccin de problemas en el
software y su rectificacin. La mayora de los estudios revelan que los mejores
programadores tienen cierta medida de defectos por cada 1.000 lneas de cdigo,
estos defectos no son por negligencia sino que en su aparicin influyen mltiples
factores como la mala comunicacin entre los miembros del equipo que da lugar a
malentendidos en los requisitos pedidos.
Por todo lo anterior el descubrimiento de un defecto significa un xito para la
mejora de la calidad del software, por eso las recomendaciones de G. J. Myers
para las pruebas son las siguientes:
1. Cada caso de prueba debe definir el resultado de salida esperado. Este
resultado esperado es el que se compara con el realmente obtenido de la
ejecucin en la prueba. Las discrepancias entre ambos se consideran sntomas de
un posible defecto en el software.
2. El programador debe evitar probar sus propios programas. Lo ideal sera
que probara el software el peor enemigo de quien lo ha construido, ya que as se
asegurara una bsqueda implacable de cualquier error cometido.
3. Se debe inspeccionar el resultado de cada prueba para descubrir posibles
sntomas de defectos. Lamentablemente es frecuente pasar por alto sntomas
bastante claros. Esto invalida todo el esfuerzo realizado en la planificacin, diseo
y ejecucin de pruebas.
4. Al generar casos de prueba, se deben incluir datos de entrada vlidos y
esperados, as como, datos no validos e inesperados.
5. Las pruebas se centran en dos objetivos. Probar si el software no hace lo
que debe, y probar si el software hace lo que no debe (provoca efectos
secundarios adversos).
6. Se deben evitar los casos no documentados, ni diseados con cuidado.
Ya que se debe probar una y otra vez el software hasta que queda libre de
defectos. No documentar o guardar los casos significa repetir constantemente el
diseo de casos de prueba.
7. No deben hacerse planes de prueba suponiendo que no hay defectos en
los programas y dedicando pocos recursos a las pruebas. Hay que asumir
que siempre hay defectos y hay que detectarlos.

8. La experiencia indica que donde hay un defecto hay otros. Es decir que la
probabilidad de descubrir nuevos defectos en una parte del software es
proporcional al nmero de defectos ya descubierto.
9. Las pruebas son una tarea ms creativa que el desarrollo de software. No
existen tcnicas rutinarias para el diseo de pruebas y hay que recurrir al ingenio
para alcanzar un buen nivel de deteccin de defectos con los recursos disponibles.

De acuerdo a estas recomendaciones la filosofa ms adecuada para realizar las

pruebas consiste en planificarlas y disearlas de forma sistemtica para poder
detectar el mximo nmero y variedad de defectos con el mnimo consumo de
tiempo y esfuerzo. Donde un buen caso de prueba es aquel que tiene una gran
probabilidad de encontrar un defecto no descubierto an, ya que el xito de una
prueba consiste en detectar un defecto no encontrado antes. La prueba de
software se realiza con el propsito de encontrar algo que difiera de las
especificaciones planteadas para el producto o bien, para detectar la presencia de
situaciones que pudieran generar resultados inapropiados.
En la siguiente tabla se muestran los objetivos, los principios, las caractersticas y
los atributos principales que deben tener las pruebas:
Tabla 1. Objetivos, Principios, y Caractersticas de los Atributos de la Prueba

Objetivos de las
pruebas

La prueba es un proceso de ejecucin de un programa con la

intencin de descubrir un error.
Un buen caso de prueba es aquel que tiene alta probabilidad de
mostrar un error no descubierto hasta entonces.
Una prueba tiene xito si se descubre un error.
Principios de las Hacer un seguimiento de las pruebas hasta los requisitos del
Pruebas
cliente
Plantear y disear las pruebas antes de generar ningn cdigo
El 80% de todos los errores se centran en solo en el 20% de los
mdulos
Empezar las pruebas en mdulos individuales y avanzar hasta
probar el sistema entero.
No son posibles las pruebas exhaustivas
Deben realizarse por un equipo independiente al equipo de
desarrollo
Caractersticas
Operatividad
de un software Objetividad
fcil de probar
Controlabilidad
Capacidad de descomposicin
Simplicidad
Estabilidad
Facilidad de comprensin
Atributos de una Ms alta probabilidad de encontrar un error.

buena prueba

No debe ser redundante

No debera ser ni demasiado sencilla ni demasiado compleja

TCNICAS DE DISEO DE CASOS DE PRUEBA

El objetivo de las tcnicas de diseo de casos de prueba es el de conseguir una
confianza aceptable en que se detectarn los defectos existentes sin consumir una
cantidad excesiva de recursos, por eso todas las pruebas debe moverse en un
equilibrio entre la disponibilidad de recursos y la confianza que aportan los casos
para descubrir los defectos existentes. La idea fundamental para el diseo de
casos de prueba consiste en la eleccin de algunas posibilidades de
funcionamiento del software que por sus caractersticas, se consideren
representativas del resto. As si no se detectan defectos en el software al ejecutar
dichos casos, se puede tener un cierto nivel de confianza en que el programa no
tiene defectos, la dificultad es saber elegir los casos que se deben ejecutar.
Pruebas de caja blanca: Las pruebas de caja blanca enfocan su atencin a los
detalles procedimentales del software, por eso la implementacin de estas
pruebas depender de la disponibilidad de cdigo fuente. Este tipo de pruebas,
permiten generar casos para ejercitar y validar los caminos de cada mdulo, las
condiciones lgicas, los bucles y sus lmites, as como tambin para las
estructuras de datos.
Las pruebas inician con la observacin de que un programa difcilmente puede
considerarse como probado por completo si su cdigo contiene partes que nunca
han sido ejecutadas. Este mtodo analiza la estructura lgica del programa y, para
cada alternativa que puede presentarse, los datos de prueba ideados conducirn a
ella. Se procura escoger los que verifiquen cada posibilidad en las proposiciones
CASE, las clusulas de cada proposicin IF y la condicin de terminacin de cada
ciclo.

Figura 1. Prueba de Caja Blanca

En un programa complejo este mtodo es imprctico, pero en un producto o

mdulo pequeo es un excelente medio de prueba y depuracin. Un buen criterio

de prueba para proyectos extensos consiste en aplicar los mtodos a cada mdulo
pequeo conforme se escriba posteriormente se usan esos datos en las secciones
ms amplias del programa una vez terminadas.
Las pruebas de caja blanca se conocen como pruebas de caja de cristal o pruebas
estructurales.
La siguiente tabla muestra algunas de las pruebas ms significativas dentro de
este enfoque:
Tabla 2. Pruebas de Caja Blanca

Prueba
Prueba de caminos

Definicin
En este tipo de prueba se realiza un anlisis sobre una
representacin grfica de un programa denominada grafo de
control. En el grafo los nodos representan bloques de
instrucciones de un programa y los flujos de ejecucin para
dichas instrucciones se representan por medio de aristas. A
partir del grafo se identifica un conjunto bsico de caminos de
ejecucin sobre el que se realiza pruebas con el propsito de
ejercitar el flujo de ejecucin de los caminos en una unidad.
Prueba
de Teniendo en cuenta un grafo de control, se genera casos de
condiciones
prueba para elementos individuales de expresiones lgicas, de
esta forma se pretende probar cada condicin con todas sus
posibles alternativas.
Prueba de ciclos
Donde a partir del grafo de control, pueden generarse casos de
prueba para las iteraciones definidas en los programas con el
propsito de verificar si se realizan de forma correcta.
Prueba de definicin Estas pruebas son realizadas con el objetivo de encontrar
de datos
posibles contradicciones o redundancias en la definicin de los
datos utilizados en el software, para eso se realiza un anlisis
del comportamiento de cada uno de los datos o cada una de los
flujos de ejecucin.

Pruebas de caja negra: Las pruebas de caja negra tambin conocidas como
pruebas funcionales o de comportamiento concentran la atencin en generar
casos de prueba que permitan ejercitar los requisitos funcionales de un programa.
Este tipo de pruebas como se concentran en su funcionalidad, mucho del trabajo
se realiza interactuando con la interfaz del software. Los c asos de prueba
generados en este enfoque, se disean a partir de valores entrada y salida y de
esta forma se determina la validez de una salida para un conjunto de entradas
proporcionadas.
Los datos de prueba se escogen atendiendo a las especificaciones del problema
con el fin de verificar que el programa corra bien. Dentro de los criterios mnimos
de gua para elegir los datos de prueba estn los siguientes: Valores Fciles, El
programa se depurar con datos de fcil comprobacin; Valores tpicos realistas,

se ensayar un programa con datos seleccionados para que representen como se

aplicar, donde los datos deben ser sencillos, de modo que los resultados sean
verificables en forma manual; Valores extremos o Valores ilegales, Cuando en
un programa entra basura, su salida habr de ser un mensaje de error adecuado,
por eso es preferible que el programa ofrezca indicacin de errores en la entrada y
que realice clculos que sigan siendo factibles luego de desechar la entrada
equivocada.

Figura 2: Prueba de Caja Negra

Las pruebas de caja negra permiten detectar errores como funciones incorrectas o
ausentes, errores en estructuras de datos, errores de rendimiento, errores de
interfaz, y errores de inicializacin y terminacin, entre otros. Con la aplicacin de
esa tcnica se obtiene un conjunto de pruebas que reduce el nmero de casos de
pruebas y dicen algo sobre la presencia o ausencia de errores, algunas de las
pruebas ms conocidas se muestran en la siguiente tabla:
Tabla 3. Pruebas de Caja Negra

Prueba
Particin equivalente

Definicin
En esta tcnica la idea sta en dividir los valores vlidos y no
vlidos para entradas y salidas en un nmero reducido de
particiones de tal manera que el comportamiento del software
sea el mismo para cualquier valor contenido en una particin
particular, esto permite reducir la cantidad de casos de prueba
generados en el proceso.
Anlisis
de
los Esta tcnica se enfoca en la generacin de casos de prueba de
valores lmite
los valores limites bajo la consideracin de que existe una
tendencia a fallar precisamente cuando el software trabaja con
valores extremos de la variable de entrada. Generalmente los
valores establecidos para generar los casos de prueba son el
mnimo, valores un poco arriba del mnimo, valor mximo y
valores un poco arriba del mximo.
Pruebas segn la Este tipo de prueba la generacin de casos se realiza a partir de
experiencia
(error la intuicin y la experiencia, donde se redacta una lista de

guessing)

Tablas de decisin

posibles fallas o de las posibles situaciones en las cuales suele

ocurrir algn problema y as desarrollar casos de prueba
basados en la informacin contenida en estas listas.
Este tipo de prueba permite describir el comportamiento de un
programa a partir de un conjunto de acciones que este realiza
cuando se opera bajo determinadas condiciones, estas
condiciones pueden ser interpretadas como entradas de un
programa y las acciones como las salidas producidas. Para ello
se pueden utilizar conectores lgicos y (AND), o (OR) y no
(NOT). Al incluir aspectos lgicos este tipo de prueba se hace
ms rigurosa ya que permite transformar una especificacin en
lenguaje natural en una especificacin ms formal.

ESTRATEGIAS DE APLICACIN DE PRUEBAS DEL SOFTWARE

Una estrategia de prueba integra las tcnicas de diseo de casos de prueba en un
conjunto de pasos bien planeados que dan como resultado la correcta
construccin del software, donde la estrategia proporciona una gua para los
desarrolladores del software, para la organizacin de control de calidad y para el
cliente. La estrategia de software incorpora la planificacin de la prueba, el diseo
de casos de prueba, la ejecucin de pruebas y la agrupacin, y evaluacin de los
datos resultantes.
Prueba de unidad
La prueba de unidad centra el proceso de verificacin en la menor unidad del
diseo del software, donde se prueban los caminos de control importantes con el
fin de descubrir errores dentro del mbito de un mdulo o funcin. La complejidad
relativa de las pruebas y errores descubiertos se encuentra limitada por los
lineamientos establecidos por la prueba de software realizada. Se prueba la
Interfaz del mdulo para asegurar que la informacin fluye en forma adecuada
hacia y desde la unidad del programa; se analizan las estructuras de datos para
asegurar que los datos mantienen su integridad durante los pasos de ejecucin del
algoritmo; se prueba las condiciones lmite para asegurar que el mdulo funciona
correctamente dentro de los lmites establecidos por el procesamiento; se activan
los caminos bsicos de la estructura de control con el fin de asegurar de que las
sentencias del mdulo se ejecutan una sola vez; y finalmente se prueban todos los
caminos de manejo de errores.
La siguiente tabla muestra la lista de comprobaciones propuesta por Myers para
la prueba de interfaces:

Tabla 4: Lista de comprobaciones para la prueba de interfaces

Lista de comprobaciones Es igual el nmero de parmetros de entrada al nmero

para
la
prueba
de de argumentos?
interfaces de un mdulo
Coinciden las caractersticas (atributos) de los
parmetros con los argumentos?
Coinciden el sistema de unidades de los parmetros
con el de los argumentos?
Son correctos el nmero, atributos y el orden de los
argumentos de las funciones incorporadas?
Existen referencias o parmetros que no estn
asociados con el punto de entrada actual?
Entran slo argumentos alterados?
Son consistentes las definiciones de variables globales
entre mdulos?
Se pasan las restricciones como argumentos?
Cuando un mdulo tenga Son correctos los atributos de los archivos?
operaciones bsicas de
Entrada/Salida externa, se Son correctas las sentencias de apertura?
deben llevar a cabo Coinciden las especificaciones de formato con las
pruebas adicionales
sentencias de Entrada/Salida?
Coincide el tamao del buffer con el tamao del
registro?
Se abren los archivos antes de usarlos?
Se tienen en cuenta las condiciones de fin de archivo?
Se manejan errores de Entrada/Salida?
Hay algn error textual en la informacin de salida?

Los casos de prueba se disean para descubrir errores tales como: Tipificacin
impropia o inconsistente, Inicializacin o valores implcitos errneos, Nombres de
variables incorrectos, Tipos de datos inconsistentes, Desbordamiento o errores en
el direccionamiento de memoria. Tambin se disean casos de prueba para
detectar errores causados por clculos incorrectos o flujos de control inapropiados
tales como: Procedencia aritmtica incorrecta mal aplicada, Operaciones de modo
mixto, Inicializaciones incorrectas, Falta de precisin, Representacin incorrecta
de una expresin.
Los casos de prueba deben descubrir errores como: Comparaciones entre tipos de
datos distintos, Operadores lgicos o de procedencia incorrecta, Terminacin de
ciclos inapropiada o inexistente, Falta de salida cuando se encuentra una iteracin
mal aplicada, Variables internas a un ciclo modificadas en forma inadecuada.
Entre los errores que deben comprobarse estn: La condicin de error hace que
intervenga el sistema antes que el mecanismo de errores, Descripcin ilegible del
error, El error sealado no corresponde con el error encontrado, La descripcin del
error no proporciona suficiente informacin para ayudar en la localizacin de la
causa del error.

La prueba de los lmites es la ltima etapa de la prueba de unidad y quiz la ms

importante, generalmente los errores de condiciones lmite aparecen cuando se
procesa el elemento n-simo de un arreglo n-dimensional, cuando se hace la isima repeticin de un ciclo de x pasos o cuando se llega a los valores mximo
mnimo permitidos.
La estrategia de planificacin y aplicacin de las pruebas pretende integrar el
diseo de los casos de prueba en una serie de pasos coordinados a travs de la
creacin de distintos niveles de prueba, con diferentes objetivos. Donde permite la
coordinacin del personal de desarrollo y del cliente, gracias a la definicin de los
papeles que desempea cada uno y la forma de llevarlos a cabo.
En general, la estrategia de pruebas comienza a nivel de mdulo, una vez
terminadas, progresan hacia la integracin del sistema completo y su instalacin, y
culminan cuando el cliente acepta el producto y se pasa a su explotacin
inmediata. Se comienza en la prueba de cada mdulo, que normalmente la realiza
el propio personal de desarrollo en su entorno; con el esquema del diseo del
software, los mdulos probados se integran para comprobar sus interfaces en el
trabajo conjunto; luego el software totalmente ensamblado se prueba como un
conjunto de pruebas para comprobar si cumple o no los requisitos funcionales
como los de rendimientos, seguridad, etc.; posteriormente el software ya validado
se integra con el resto del sistema para probar su funcionamiento conjunto; y
finalmente el producto final se pasa a la prueba de aceptacin para que el usuario
compruebe en su propio entorno de explotacin si lo acepta como est o no.
Pruebas de integracin
Las pruebas de integracin estn ligadas a la forma de integrar los distintos
componentes del software hasta contar con el producto total que debe entregarse,
implican una progresin ordenada de pruebas que parte desde los componentes y
que culmina en el sistema completo, el objetivo fundamental es probar las
interfaces entre componentes o mdulos.
La prueba de Integracin es una tcnica sistemtica para construir la estructura
del programa y al mismo tiempo se llevan a cabo pruebas para detectar errores
asociados con la interaccin, el propsito es tomar los mdulos probados en
unidad y estructurar un programa que est de acuerdo con lo que dicta el diseo.
Una vez que los mdulos funcionen por separado y hayan pasado la prueba de
unidad es necesario realizar las pruebas para ver cmo funcionan juntos todos los
mdulos, es aqu donde pueden surgir problemas en la unin de los mdulos. Los
problemas ms frecuentes son que los datos se pueden perder en una interfaz, un
mdulo puede tener un efecto adverso sobre otro mdulo, las funciones al
combinarse pueden producir el objetivo no deseado, las estructuras de datos
globales pueden presentar problemas, entre otros.
Existen 2 tipos de integracin: La primera es la no incremental, donde se intenta
elaborar software en mdulos grandes, en otros casos un slo mdulo, pero en

ellos es ms difcil aislar los errores y cuando alguno de ellos es corregido produce
otros errores; la segunda es de tipo incremental en donde se desarrollan mdulos
pequeos y funcionales que hacen que los errores sean ms fciles de aislar y
corregir, es ms probable que se puedan probar completamente las interfaces y
aplicar un enfoque de prueba sistemtico.
Integracin Incremental Ascendente: El proceso empieza combinando primero
los mdulos de ms bajo nivel en grupos que realizan alguna sub-funcin
especfica, donde se busca reducir el nmero de pasos de integracin. Luego se
describe para cada grupo un mdulo impulsor o conductor, que es un mdulo que
permite simular la llamada a los mdulos, introducir los datos de prueba a travs
de los parmetros de llamada y recoger los resultados a travs de los de salida.
Posteriormente, se prueba cada grupo empleando su impulsor y por ltimo se
eliminan los mdulos impulsores de cada grupo y se sustituyen por los mdulos
del nivel superior de la jerarqua.
Integracin Incremental Descendente: La integracin incremental descendente
comienza con el mdulo de control principal y va incorporando mdulos
subordinados progresivamente. No existe un procedimiento general para
determinar cul de los mdulos subordinados posibles es mejor incorporar
primero, es decir, no se puede dar una regla general que permita determinar la
secuencia ptima de incorporacin de mdulos. Hay que estudiar en cada caso
cul es el mejor orden de incorporacin para minimizar el esfuerzo o para lograr
una mejor organizacin.
La siguiente figura muestra la integracin incremental descendente

Figura 3. Integracin Incremental Descendente

Las etapas fundamentales de la integracin descendente son las siguientes: El

mdulo raz es el primero, se escriben mdulos ficticios para simular la presencia
de los subordinados ausentes que sern llamados por el mdulo raz; una vez
probado el mdulo raz se sustituye uno de los subordinados ficticios por el
mdulo correspondiente segn el orden elegido, se incorporan ficticios para
recoger las llamadas del ltimo incorporado; se ejecutan las correspondientes
pruebas cada vez que se incorpora un mdulo nuevo; al terminar cada prueba, se
sustituye un ficticio por su correspondiente real.
Integracin no incremental: En este tipo de integracin cada mdulo requiere de
los siguientes elementos para ser probado: Un mdulo impulsor, que transmite o
impulsa los datos de prueba al mdulo y muestra los resultados de dichos casos
de prueba; uno o ms mdulos ficticios que simulan la funcin de cada mdulo
subordinado llamado por el mdulo que se va a probar; Despus de probar cada
mdulo por separado, se ensamblan todos ellos de una sola vez para formar el
programa completo y probarlo en conjunto. La integracin no incremental es el
nico caso en el que las pruebas de unidad y las de integracin estn totalmente
separadas.
Prueba de aceptacin
El objetivo de esta prueba es comprobar si el producto est listo para ser
implantado para el uso operativo en el entorno del usuario, si la prueba del
sistema determin la capacidad real del sistema y permiti a la organizacin de
desarrollo tener confianza en que estaba listo para su funcionamiento, la prueba
de aceptacin es la prueba planificada y organizada formalmente para determinar
si se cumplen los requisitos de aceptacin marcados por el cliente. Las
caractersticas principales de esta prueba son las siguientes: Participacin del
usuario, se enfoca hacia la prueba de los requisitos de usuario especificados, es la
fase final del proceso para crear una confianza en que el producto es el apropiado
para su uso en explotacin.
Las recomendaciones generales que pueden darse para la prueba de aceptacin
son las siguientes: Debe contarse con criterios de aceptacin previamente
aprobados por el usuario, No hay que olvidar validar tambin la documentacin y
los procedimientos de uso, las pruebas se deben realizar en el entorno en el que
se utilizar el sistema. Si se trata de un sistema contratado, la prueba se realiza
bajo control de la organizacin de desarrollo en el entorno real de trabajo
ayudando al usuario (prueba alfa). En el caso de productos de inters general, se
entregan versiones (versiones beta) a usuarios de confianza, sin control directo,
que informarn de la opinin que les merece la aplicacin.
Prueba de validacin y verificacin
La verificacin es un conjunto de actividades que aseguran que el software
implementa correctamente una funcin especfica, y la validacin se refiere a un

conjunto diferente de actividades que aseguran que el software construido se

ajusta a los requisitos y necesidades del cliente. La definicin de estos dos
conceptos envuelve lo que se conoce como calidad del software, en donde los
mtodos de anlisis, de diseo y de implementacin actan para mejorar la
calidad al proporcionar tcnicas continuas y resultados predecibles. Las revisiones
tcnicas formales de inspeccin ayudan a asegurar la calidad la calidad de los
productos, a lo largo del proceso la medicin y el control se aplican sobre cada
elemento de una configuracin del software.
Es importante mencionar que la validacin y verificacin abarcan un amplio rango
de la calidad del software que incluyen revisiones tcnicas formales, auditoras de
configuracin y calidad, supervisin de rendimiento, simulacin, estudio de
viabilidad, revisin de la documentacin, revisin de la base de datos, anlisis de
algoritmos, pruebas de desarrollo, prueba de calificacin y prueba de instalacin.
La prueba de validacin se logra cuando las expectativas razonables del cliente se
cumplen, en donde incluyen la especificacin de requisitos, documentos en donde
se describen los atributos del software visibles para el usuario, esta informacin
forma la base del enfoque a la prueba de validacin. El procedimiento de prueba
estar diseado para asegurar que se satisfacen los requisitos funcionales, que se
alcanzan todos los requisitos de rendimiento, que la documentacin es correcta y
que se alcanzan otros requisitos tales como portabilidad, compatibilidad,
recuperacin de errores, facilidad de mantenimiento, entre otros.
Prueba del sistema
La prueba del sistema es el proceso de prueba de un sistema integrado de
hardware y software para comprobar si cumple los requisitos especificados, es
decir, el cumplimiento de todos los requisitos funcionales del producto software
completo en un entorno de sistema, El funcionamiento y rendimiento en las
interfaces hardware, software, de usuario y de operador, la adecuacin de la
documentacin de usuario, la ejecucin y rendimiento en condiciones lmite y de
sobrecarga.
Los casos para la prueba del sistema tienen tres fuentes principales para su
diseo:

Casos basados en los requisitos gracias a tcnicas de caja negra aplicadas

a las especificaciones

Casos necesarios para probar el rendimiento del sistema y de su capacidad

funcional (pruebas de volumen de datos, de lmites de procesamiento, etc.)

Casos basados en el diseo de alto nivel aplicando tcnicas de c aja blanca

aplicadas a los flujos de datos de alto nivel (por ejemplo, de los diagramas
de flujo de datos).

La prueba del sistema tiene la finalidad de verificar que se hayan integrado

correctamente cada uno de los elementos del sistema, existen diferentes tipos de
pruebas del sistema, algunas de ellas son las siguientes:
Prueba de Recuperacin: La prueba de recuperacin se hace al sistema
forzando a que produzca fallas de software de muchas maneras y verificando que
la recuperacin se lleve a cabo, ya sea automticamente o manual, tomando en
cuenta los recursos que se requieran para efectuar la recuperacin.
Prueba de Seguridad: Esta prueba intenta verificar la aplicacin de los
mecanismos de proteccin incorporados en el sistema, donde se realizan pruebas
de intrusin tratando de violar la seguridad del sistema, intentando obtener las
claves de acceso por cualquier medio externo, bloqueando el sistema, negacin
de servicio, o curiosear los datos pblicos para encontrar una clave de acceso al
sistema.
Prueba de Resistencia: Esta prueba est diseada para enfrentar a los
programas en situaciones anormales, es decir, ejecutar el sistema en forma que
demande recursos en cantidad, frecuencia o volmenes anormales. El encargado
de la prueba debe intentar colapsar el sistema y para lograrlo se puede tomar en
consideracin lo siguiente: Disear pruebas especiales que generen 10 o ms
interrupciones por segundo; incrementar las frecuencias de datos de entrada en
un orden de magnitud con el fin de comprobar cmo responden las funciones de
entrada; ejecutar casos de prueba que requieran al mximo de memoria o de
espacio en disco; disear casos de prueba que produzcan excesivas bsquedas
de datos almacenados en disco.
Depuracin
La depuracin aparece como resultado de una prueba efectiva, es decir, cuando
en un caso de prueba se encuentra un error, la depuracin es el proceso que
resulta en la eliminacin de un error. Se debe tomar en cuenta que la depuracin
no es una tcnica de prueba, aunque siempre se da como consecuencia de la
prueba. El proceso de depuracin comienza en los casos de prueba, se evalan
los resultados y resulta una falta de correspondencia entre los esperados y los
reales, el proceso de depuracin intenta hacer corresponder el sistema con una
causa, llevando as a la correccin del error.

Figura 4. Depuracin de errores

La depuracin tiene como objetivo principal encontrar y corregir la causa de un

error en el software.
Existen 3 enfoques que se pueden proponer en la depuracin:

La categora de depuracin "eliminacin de causas" se manifiesta mediante

induccin o deduccin. Los datos relacionados con la ocurrencia del error
se organizan para llegar a las posibles causas; se desarrolla una lista de las
causas y se llevan a cabo las pruebas para eliminar cada una.
La categora de depuracin por "fuerza bruta" es la categora
probablemente la ms comn y la menos eficiente en el momento de aislar
la causa del error del software en donde se confa que en algn lugar de la
gran cantidad de informacin producida nos puede llevar finalmente al xito,
lo ms frecuente es que se desperdicie tiempo y esfuerzo.
La vuelta atrs es el enfoque ms normal para la depuracin, que se puede
usar con gran xito en programas pequeos. Partiendo de donde se detecta
el error hacia atrs en el cdigo fuente hasta llegar a la posicin del error.
PRUEBA DE SOFTWARE PARA OBJETOS

El software construido a partir del modelo orientado a objetos tambin requiere ser
sometido a pruebas con el propsito de garantizar su calidad. En trminos
generales, se puede decir que los dos enfoques ms representativos en materia
de pruebas, de caja blanca y de caja negra, son aplicables al software orientado a
objetos en cierta medida. Sin embargo, existen algunas caractersticas del
software orientado a objetos que generan problemas adicionales no cubiertos por
las tcnicas tradicionales de prueba.

Mtodos de prueba de software orientado a objetos.

Muchas de las generalidades de los mtodos de prueba tradicionales han sido
adaptadas considerando las caractersticas del modelo orientado a objetos, c on el
propsito de que puedan ser aplicables en este nuevo contexto. Actualmente,
existen muy pocas investigaciones sobre el estudio de prueba de software
orientado a objetos; ya que el rea de prueba de software es bastante compleja y
dentro de este marco de objetos existe una carencia de mtodos robustos para
garantizar la realizacin de las pruebas de forma eficaz. En este panorama se
presenta el estado actual en cuanto a prueba de software orientado a objetos en
trminos del nivel de prueba.
Pruebas de unidad
En el software orientado a objetos la menor unidad a considerar para realizar una
prueba es la clase. La prueba de clases en el mbito de software Orientado a
Objetos es equivalente a la prueba de unidad realizada al software tradicional.
Esta prueba est fundamentalmente dirigida a las operaciones encapsuladas por
la clase, as como al estado y comportamiento del objeto que se implementa en
ella. El nfasis de la prueba de unidad es verificar que esta pequea unidad
trabaje correctamente en forma aislada, antes de proceder a integrarla en el
sistema.
Los mtodos contenidos en una clase pueden ser muchos y una operacin en
particular de ese conjunto, a consecuencia de la herencia, puede existir como
parte de varias clases diferentes. Por lo tanto el significado de prueba de unidad
cambia en muchos sentidos y es importante disearla bajo ciertas
consideraciones.
Se han propuesto estrategias para llevar a cabo las pruebas de unidad
considerando aspectos como el orden en que los mtodos son sometidos a la
prueba, el orden en que una jerarqua de clases puede ser probada, ejercitar el
flujo de datos o bien el anlisis del estado del objeto.
Los aspectos que deben considerarse para construir casos de prueba para una
clase deben verificar que esta proporcione los servicios que promete, que
responda correctamente a las condiciones esperadas y, ms an, ante las
inesperadas. Aspectos adicionales pueden el verificar si la clase contiene y
permite disponer de todas las funciones asociadas a ella o que cada mtodo de la
clase ejecute su responsabilidad especificada. Algunas de las tcnicas ms
populares para realizar pruebas de unidad se muestran en la siguiente tabla:

Tabla 5. Pruebas de Unidad de Software Orientado a Objetos

Prueba
Pruebas estructurales

Definicin
Si se tiene la disponibilidad de cdigo fuente, pueden
realizarse pruebas estructurales a las unidades sometidas
a la prueba. Las acciones de esta actividad pueden
disearse con el propsito de ejercitar todas las rutas del
cdigo, las condiciones establecidas o bien las ciclos
definidos en el programa.
Prueba de valores limite
Mediante esta tcnica se prueba la unidad bajo situaciones
inusuales o extremas, con el propsito verificar cmo son
manejadas por el software. Para ello, los casos de prueba
suministrados son diseados considerando valores
frontera, es decir los valores mnimo y mximo que la
unidad puede aceptar, as como tambin aquellos valores
cercanos a las fronteras identificadas.
Prueba
basada
en Para esta tcnica, se generarn casos de prueba para un
estados
contexto en donde una clase se modela como una
mquina de estados con secuencias de transiciones, con
esto se pretende analizar el estado de los objetos de
acuerdo a su comportamiento. Una vez que se ha
establecido un modelo de estados con base en los
atributos del objeto, se consideran en la prueba los
mtodos necesarios para poder observar los cambios de
estado. La aplicacin de esta tcnica permite observar
alguna de las siguientes situaciones: se produce un
cambio a un estado correcto, se produce cambio a un
estado incorrecto, no hay cambio de estado, se produce
un estado indefinido correcto o bin, se produce un estado
indefinido incorrecto.
Prueba incremental
La prueba incremental dirige su atencin a las subclases
generadas como consecuencia de la herencia, siendo la
clase padre una clase previamente probada. Aunque
existen situaciones en las que ste tipo de pruebas se
descarta, se pueden identificar algunas en las que no
estaran de ms: cuando se han agregado o modificado
propiedades y/o mtodos, cuando existen propiedades y
mtodos que se han heredado y no se han alterado, pero
que realizan algn tipo de interaccin con elementos
nuevos o modificados.

Pruebas de integracin.
Cuando se aplican pruebas de integracin al software orientado a objetos, se
pretende demostrar que las unidades que ya han sido sometidas a un proceso de
prueba y funcionan correctamente, lo hacen de igual forma cuando interactan y
se integran con otras unidades del sistema. Prcticamente, el trabajo de esta
prueba se concentra en la interaccin de mtodos en diferentes unidades.

Existe una coincidencia en los dos enfoques para realizar este tipo de pruebas: el
basado en hilos y el basado en uso. En el primero, pretende que todas las clases
respondan a sencillas entradas externas, provenientes de otra unidad. De esta
forma, se realizan casos de prueba para cada clase en la unidad, con lo cual un
hilo de este conjunto se ejercita. En el enfoque basado en uso, se realizan
pruebas para clases las cuales usan servicios de otras clases. En la siguiente
tabla se presentan algunos mtodos para realizar pruebas de integracin:
Tabla 6. Pruebas de Integracin de Software Orientado a Objetos

Prueba
Mtodo de Caminos
de Mensajes

Definicin
Este mtodo se concentra principalmente en probar aquellos
caminos que se generan por un evento de entrada y terminan
con un evento de salida
El
mtodo
de En este mtodo se prueban las clases por pares, donde una
Overbek
hace el papel de cliente y otra el de servidor, establecindose
para estas dos conjuntos de pruebas. El primer conjunto, son
pruebas orientadas a verificar si los mensajes de entrada y de
salida generados son correctos; es decir si se usa
correctamente cualquier clase servidora y si todas las
secuencias de operaciones son correctas. En el segundo
conjunto se verifica adems de lo anterior, si la clase cliente
siempre satisface las precondiciones de la clase servidora, as
como tambin si satisface las salidas esperadas por la clase
servidora.
El mtodo de Kung
Este mtodo emplea una estrategia de ingeniera en reversa
sobre el cdigo de las unidades con el propsito de generar un
diagrama de relaciones entre objetos. A partir de este diagrama
se propone un orden para las pruebas que minimiza el uso de
cabos. El diagrama se convierte en un grafo acclico, que
puede contener varios clsteres de objetos y los ordenan
topolgicamente. Su mtodo involucra las etapas de pruebas
de unidad y de integracin y puede usarse tambin para
pruebas de regresin.

Pruebas de sistema.
Las pruebas de unidad se concentran en verificar si las funcionalidades descritas
en las especificaciones o en los requisitos iniciales corresponden a las que se
presentan en el producto final. En esta rea, al igual que la de pruebas de
integracin, se han generado pocos trabajos, por lo que se emplean muchos de
los mtodos tradicionales.

Tabla 7. Pruebas de Sistema de Software Orientado a Objetos

Prueba
Prueba de funcin

Pruebas de aceptacin

Prueba bajo stress

Definicin
La prueba de funcin comnmente es llevada a cabo por
el grupo de personas que desarrollaron el producto. Este
enfoque se orienta a confirmar que la aplicacin alcanza
los requerimientos y la funcionalidad especificadas por el
usuario
En este tipo de pruebas, versiones que an no han sido
liberadas en el mercado, son ofrecidas a ciertos grupos de
usuarios con el propsito de que las utilicen. El propsito
de sto es que los usuarios reporten defectos que
pudieran presentarse.
Para realizar esta prueba, el sistema somete a condiciones
extremas de trabajo, como pueden ser un alto volumen de
transacciones o un gran nmero de usuarios. Aplicando
este enfoque, se puede verificar si el sistema se comporta
como se espera an ante este tipo de escenarios.