Professional Documents
Culture Documents
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.
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.
Objetivos de las
pruebas
buena prueba
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,
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
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.
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
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.
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.
Pruebas de aceptacin
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.