Caracas, 04 de Junio de 2013

TCNICAS DE PRUEBA DEL SOFTWARE

1.- Fundamentos de las pruebas del software
Las pruebas del software son un elemento crtico para la
garanta de calidad del software y representa una revisin final de las
especificaciones, del diseo y de la codificacin. La creciente
percepcin del software como un elemento del sistema y la
importancia de los costos asociados a un fallo del propio sistema,
estn motivando la creacin de pruebas minuciosas y bien
planificadas. No es raro que una organizacin de desarrollo de
software emplee entre el 30 y el 40 por ciento del esfuerzo total de
un proyecto en las pruebas. En casos extremos, las pruebas del
software para actividades crticas (por ejemplo, control de trfico
areo, control de reactores nucleares) puede costar de tres a cinco
veces ms que el resto de los pasos de la ingeniera del software
juntos!

Qu es? Una vez generado el cdigo fuente, el software debe ser

probado para descubrir y corregir el mximo de errores posibles
antes de su entrega al cliente. Para lo cual es necesario crear una
serie de casos de prueba que tenga una alta capacidad y probabilidad
para encontrar errores. Eso se consigue con las tcnicas de prueba
del software, que facilitan una gua sistemtica para disear pruebas
que: 1.- Comprueben la lgica interna de los componentes de
software y 2.- Verifiquen los dominios de entrada y salida del
programa para descubrir errores en la funcionalidad, Comportamiento
y rendimiento.

Quin lo hace? Durante las primeras etapas de las pruebas, es el

ingeniero de software quin realiza todas las pruebas. Sin embargo,
en lo que se profundiza el proceso de prueba los especialistas de
prueba se van incorporando.

Por Qu es importante? Las revisiones y otras actividades

descubren errores, pero no son suficientes. Cada vez que el programa
se ejecuta el cliente lo est probando. Con el objetivo de encontrar el
mayor nmero posible de errores, las pruebas deben conducirse
sistemticamente y los casos de prueba deben definirse utilizando las
tcnicas de prueba.

Cules son los pasos? El software debe comprobarse desde dos

perspectivas diferentes: 1.- La lgica interna del programa se
comprueba utilizando tcnicas de diseo de casos de prueba de

<<caja blanca>>. Los requisitos del software se comprueban

utilizando tcnicas
de diseo de casos de prueba de <<caja
negra>>. En ambos casos se propone encontrar el mayor nmero de
errores con la menor cantidad de esfuerzo y tiempo.

Cul es el producto obtenido? Se define y se documenta un

conjunto de casos de prueba, diseados para comprobar la lgica
interna y los requisitos externos. Se determinan los resultados
esperados y se guardan los resultados obtenidos.

Cmo puedo estar seguro que lo he hecho correctamente?

Cuando se comienza la prueba se debe cambiar el punto de vista, se
intenta romper con firmeza el software. Hay que disear casos de
prueba de una forma disciplinada y revisar que los casos de prueba
abarcan todo lo desarrollado.
Las pruebas son uno de los pasos de la ingeniera de software
que se puede ver (al menos psicolgicamente) como destructivo ms
que constructivo.

1.1.- Objetivos de las pruebas.Normas que pueden servir acertadamente como objetivos de las
pruebas:
1. La prueba es el proceso de ejecucin de un programa con la
intencin de descubrir un error.
2. Las pruebas deberan planificarse mucho antes de que
empiecen. La planificacin de las pueden empezar tan pronto
como est completo el modelo de requisitos. La definicin
detallada de los casos de prueba puede empezar tan pronto
como el modelo de diseo se ha consolidado. Por tanto, se
pueden planificar y disear todas las pruebas antes de generar
ningn cdigo.
3. El principio de Pareto es aplicable a la prueba del software.
Dicho de manera sencilla, el principio de Pareto implica que al
80 por 100 de todos los errores descubiertos durante las
pruebas se les puede hacer un seguimiento hasta un 20 por
100 de todos los mdulos del programa. El problema, por
supuesto, es aislar estos mdulos sospechosos y probarlos
concienzudamente.
4. Las pruebas deberan empezar por lo pequeo y progresar
hacia lo grande. Las primeras pruebas planeadas y
ejecutadas se centran generalmente en mdulos individuales
del programa. A medida que avanzan las pruebas, desplazan su
punto de mira en un intento de encontrar errores en grupos
integrados de mdulos y finalmente en el sistema entero
5.
No son posibles las pruebas exhaustivas. El nmero de
permutaciones de caminos para incluso un programa de

tamao moderado es excepcionalmente grande. Por este

motivo, es imposible ejecutar todas las combinaciones de
caminos durante las pruebas. Es posible, sin embargo, cubrir
adecuadamente la lgica del programa y asegurarse de que se
han aplicado todas las condiciones en el diseo a nivel de
componente.
6. Para ser ms eficaces, las pruebas deberan ser realizadas por
un equipo independiente. Por ms eficaces queremos
referirnos a pruebas con la ms alta probabilidad de encontrar
errores (el objetivo principal de las pruebas). Por las razones
que se expusieron anteriormente, el ingeniero del software que
cre el sistema no es el ms adecuado para llevar a cabo las
pruebas para el software.

1.2.- Facilidad de prueba.En circunstancias ideales, un ingeniero del software disea un

programa de computadora, un sistema o un producto con la facilidad
de prueba en mente. Esto permite a los encargados de las pruebas
disear casos de prueba ms fcilmente.
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 qu se
puede hacer para hacerlo ms sencillo. A veces los programadores
estn dispuestos a hacer cosas que faciliten el proceso de prueba y
una lista de comprobacin de posibles puntos de diseo,
caractersticas, etc., puede ser til a la hora de negociar con ellos.
A veces, la facilidad de prueba se usa para indicar
adecuadamente que un conjunto particular de pruebas va a cubrir un
producto.
La siguiente lista de comprobacin proporciona un conjunto de
caractersticas que llevan a un software fcil de probar:
1.2.1.-Operatividad. Cuanto mejor funcione, ms eficientemente se
puede probar
El sistema tiene pocos errores (los errores aaden sobrecarga
de anlisis y de generacin de informes al proceso de prueba).
Ningn error bloquea la ejecucin de las pruebas
El producto evoluciona en fases funcionales (permite
simultanear el desarrollo y las pruebas).
1.2.2.- Observabilidad. Lo que ves 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 (por ejemplo, registros de transaccin).
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.
Se informa automticamente de los errores internos.
El cdigo fuente es accesible.

1.2.3.- Controlabilidad. Cuanto mejor podamos controlar el software,

ms 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.
1.2.4.-Capacidad de descomposicin. Controlando el mbito de las
pruebas, podemos aislar ms rpidamente los problemas y llevar a
cabo mejores pruebas de regresin.
El
sistema
software
est
construido
con
mdulos
independientes.
Los
mdulos
del
software
se
pueden
probar
independientemente
1.2.5.- Simplicidad. Cuanto menos haya que probar, ms rpidamente
podremos probarlo.
Simplicidad
funcional
(por
ejemplo,
el
conjunto
de
caractersticas es el mnimo necesario para cumplir los
requisitos).
Simplicidad estructural (por ejemplo, la arquitectura es
modularizada para limitar la propagacin de fallas).
Simplicidad del cdigo (por ejemplo, se adopta un estndar de
cdigo para facilitar la inspeccin y el mantenimiento).
1.2.6.- 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 fallas.
1.2.7.- Facilidad de comprensin. Cuanta ms informacin tengamos,
ms 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 cambias del diseo.
La documentacin tcnica es instantneamente accesible.
La documentacin tcnica est bien organizada.
La documentacin tcnica es especfica y detallada.
La documentacin tcnica es exacta.

Los atributos antes sugeridos (Bach) los puede emplear el

ingeniero del software para desarrollar una configuracin del software
(por ejemplo, programas, datos y documentos) que pueda probarse.
Atributos de una buena prueba:
1. Una buena prueba tiene una alta probabilidad de encontrar un
error. Para alcanzar este objetivo, el responsable de la prueba
debe entender el software e intentar desarrollar una imagen
mental de cmo podra fallar el software.
2. Una buena prueba no debe ser redundante. El tiempo y los
recursos para las pruebas son limitados. No hay motivo para
realizar una prueba que tiene el mismo propsito que otra.
3. Una buena prueba debera ser la mejor de la cosecha. En un
grupo de pruebas que tienen propsito similar, las limitaciones
de tiempo y recursos pueden abogar por la ejecucin de slo
un subconjunto de estas pruebas. En tales casos, se debera
emplear la prueba que tenga la ms alta probabilidad de
descubrir una clase entera de errores.
4. Una buena prueba no debera ser ni demasiado sencilla ni
demasiado compleja.
Recordando el objetivo de las pruebas, debemos disear pruebas
que tengan la mayor probabilidad de encontrar el mayor nmero de
errores con la mnima cantidad de esfuerzo y tiempo posible.
Cualquier producto de ingeniera (y de muchos otros campos)
puede probarse de una de estas dos formas: (1) conociendo la
funcin especfica para la que fue diseado el producto, se pueden
llevar a cabo pruebas que demuestren que cada funcin es
completamente operativa y, al mismo, tiempo buscando errores en
cada funcin; y
(2) conociendo el funcionamiento del producto, se pueden
desarrollar pruebas que aseguren que todas las piezas encajan, o
sea, que la operacin interna se ajusta a las especificaciones y que
todos los componentes internos se han comprobado de forma
adecuada. El primer enfoque de prueba se denomina prueba de caja
negra y el segundo, prueba de caja blanca.

Cuando se considera el software de computadora, la prueba de

caja negra se refiere a las pruebas que se llevan a cabo sobre la
interfaz del software. O sea, los casos de prueba pretenden
demostrar que las funciones del software son operativas, que la
entrada se acepta de forma adecuada y que se produce un resultado
correcto, as como que la integridad de la informacin externa (por
ejemplo, archivos de datos) se mantiene.

2.- PRUEBAS DE CAJA BLANCA.La prueba de caja blanca del software 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.
Una prueba de caja blanca muy profunda nos llevara a tener
programas cien por ciento correctos. Todo lo que tenemos que
hacer es definir todos los caminos lgicos, desarrollar casos de
prueba que los ejerciten y evaluar los resultados, es decir, generar
casos de prueba que ejerciten exhaustivamente la lgica del
programa. Desgraciadamente, la prueba exhaustiva presenta ciertos
problemas logsticos. Incluso para pequeos programas, el nmero de
caminos lgicos posibles puede ser enorme.
La prueba de caja blanca, sin embargo, no se debe desechar
como impracticable. Se pueden elegir y ejercitar una serie de
caminos lgicos importantes. Se pueden comprobar las estructuras de
datos ms importantes para verificar su validez. Se pueden combinar
los atributos de la prueba de caja blanca as como los de caja negra,
para llegar a un mtodo que valide la interfaz del software y asegure
selectivamente que el funcionamiento interno del software es
correcto.
Mediante los mtodos de prueba de caja blanca, el ingeniero del
software puede obtener casos de prueba que (1) garanticen que se
ejercita por lo menos una vez todos los caminos independientes de
cada mdulo; (2) ejerciten todas las decisiones lgicas en sus
vertientes verdadera y falsa; (3) ejecuten todos los bucles en sus
lmites y con sus lmites operacionales; y (4) ejerciten las estructuras
internas de datos para asegurar su validez.
La prueba de caja blanca, denominada a veces prueba de caja
de cristal es un mtodo de diseo de casos de prueba que usa la
estructura de control del diseo procedimental para obtener los casos
de prueba.
2.1 Tipos de prueba de caja blanca.
2.1.1 La prueba del camino bsico.
La prueba del camino bsico es una tcnica de prueba de caja
blanca propuesta inicialmente por Tom McCabe [MCC76]. 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 programa.
2.1.2 La prueba de la estructura de control.
2.1.2.1 Prueba 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. Una condicin
simple es una variable lgica o una expresin relacional,
posiblemente precedida con un operador NOT
2.1.2.2 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. La
primera, que la cobertura de la prueba de una condicin es sencilla.
La segunda, que la cobertura de la prueba de las condiciones de un
programa da una orientacin para generar pruebas adicionales del
programa. El propsito de la prueba de condiciones es detectar, no
slo los errores en las condiciones de un programa, sino tambin
otros errores en dicho programa.
2.1.2.3 Prueba del 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.
2.1.2.4 Prueba de bucles: Los bucles son la piedra angular de la
inmensa mayora de los algoritmos implementados en software. Y sin
embargo, les prestamos normalmente poca atencin cuando llevamos
a cabo las pruebas del software.
3.- PRUEBAS DE CAJA NEGRA.Las pruebas de caja negra, tambin denominada prueba de
comportamiento, se centran en los requisitos funcionales del
software. O sea, la prueba de caja negra 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 no es una alternativa a las tcnicas de prueba
de caja blanca. Ms bien se trata de un enfoque complementario que
intenta descubrir diferentes tipos de errores que los mtodos de caja
blanca, no encuentran. 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 bases de datos externas, (4) errores de rendimiento y
(5) errores de inicializacin y de terminacin.
Las pruebas se disean para responder a las siguientes
preguntas:

Cmo se prueba la validez funcional?

Cmo se prueba el rendimiento y el comportamiento del
sistema?
Qu clases de entrada compondrn unos buenos casos de
prueba?
Es el sistema particularmente sensible a ciertos valores de
entrada?
De qu forma estn aislados los lmites de una clase de datos?
Qu volmenes y niveles de datos tolerar el sistema?
Qu efectos sobre la operacin del sistema tendrn
combinaciones especficas de datos?
Mediante las tcnicas de prueba de caja negra se obtiene un
conjunto de casos de prueba que satisfacen los siguientes criterios
[MYE79]: (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 y (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.
3.1.- Tipos de pruebas de caja negra.
3.1.1 Mtodos de prueba basados en grafos: El primer paso en
la prueba de caja negra es entender los objetos que se modelan en el
software y las relaciones que conectan a estos objetos. Una vez que
se ha llevado a cabo esto, el siguiente paso es definir una serie de
pruebas que verifiquen que todos los objetos tienen entre ellos las
relaciones esperadas. Dicho de otra manera, la prueba del software
empieza creando un grafo de objetos importantes y sus relaciones, y
despus diseando una serie de pruebas que cubran el grafo de
manera que se ejerciten todos los objetos y sus relaciones para
descubrir los errores.
3.1.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. Un caso de prueba ideal descubre de forma inmediata una
clase de errores (por ejemplo, proceso incorrecto de todos los datos
de carcter) que, de otro modo, requeriran la ejecucin de muchos
casos antes de detectar el error genrico. La particin equivalente se
dirige a la definicin de casos de prueba que descubran clases de
errores, reduciendo as el nmero total de casos de prueba que hay
que desarrollar.
3.1.3 Anlisis de valores lmite (AVI). El anlisis de valores
lmite nos lleva a una eleccin de casos de prueba que ejerciten los
valores lmite. El anlisis de valores lmite es una tcnica de diseo de
casos de prueba que complementa a la particin equivalente. En
lugar de seleccionar cualquier elemento de una clase de equivalencia,
el AVL lleva a la eleccin de casos de prueba en los extremos de la

clase. En lugar de centrarse solamente en las condiciones de entrada,

el AVL obtiene casos de prueba tambin para el campo de salida
3.1.4 Prueba de comparacin. 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 (por
ejemplo, la particin equivalente).
3.1.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. El mtodo de prueba de la tabla ortogonal es
particularmente til al encontrar errores asociados con fallas
localizadas -una categora de error asociada con defectos de la lgica
dentro de un componente software-.
4.- ESRATEGIAS DE PRUEBA DEL SOFTWARE
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. La
estrategia proporciona un mapa que describe los pasos que hay que
llevar a cabo como parte de la prueba, cundo se deben planificar y
realizar esos pasos, y cunto esfuerzo, tiempo y recursos se van a
requerir. Por tanto, cualquier estrategia de prueba debe incorporar la
planificacin de la prueba, el diseo de casos de prueba, la ejecucin
de las pruebas y la agrupacin y evaluacin de los datos resultantes.
Una estrategia de prueba del software debe ser suficientemente
flexible para promover la creatividad y la adaptabilidad necesarias
para adecuar la prueba a todos los grandes sistemas basados en
software. Al mismo tiempo, la estrategia debe ser suficientemente
rgida para promover un seguimiento razonable de la planificacin y la
gestin a medida que progresa el proyecto.
Las pruebas son un conjunto de actividades que se pueden
planificar por adelantado y llevar a cabo sistemticamente. Por esta
razn, se debe definir en el proceso de la 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.
Se han propuesto varias estrategias de prueba del del software
en distintos libros. Todas proporcionan al ingeniero del software una
plantilla para la prueba y todas tienen las siguientes caractersticas
generales: 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 (para grandes proyectos) un grupo independiente de
pruebas. La prueba y la depuracin son actividades diferentes, pero la
depuracin se debe incluir en cualquier estrategia de prueba.

Verificacin y validacin
La prueba del software es un elemento de un tema msamplio
que, a menudo, es conocido como verificacin y validacin (VSrV). La
verificacin se refiere al conjunto de actividades que aseguran que el
software implementa correctamente una funcin especfica. La
validacin se refiere a un conjunto diferente de actividades que
aseguran que el software construido se ajusta a los requisitos del
cliente.

La calidad se incorpora en el software durante el

proceso de ingeniera del software. La aplicacin adecuada
de los mtodos y de las herramientas, las revisiones
tcnicas formales efectivas y una slida gestin y medicin,
conducen a la calidad, que se confirma durante las pruebas.
La prueba, en el contexto de la ingeniera del software,
realmente es una serie de cuatro pasos que se llevan a cabo
secuencialmente. Esos pasos se muestran en la Figura 4.1.
Inicialmente, la prueba se centra en cada mdulo individualmente,
asegurando que funcionan adecuadamente como una unidad. De ah
el nombre de prueba de unidad. La prueba de unidad hace un uso
intensivo de las tcnicas de prueba de caja blanca, ejercitando
caminos especficos de la estructura de control del mdulo para
asegurar un alcance completo y una deteccin mxima de errores. A
continuacin, se deben ensamblar o integrar los mdulos para formar
el paquete de software completo. La prueba de integracin se dirige a
todos los aspectos asociados con el doble problema de verificacin y
de construccin del programa. Durante la integracin, las tcnicas
que ms prevalecen son las de diseo de casos de prueba de caja
negra, aunque se pueden llevar a cabo algunas pruebas de caja
blanca con el fin de asegurar que se cubren los principales caminos
de control. Despus de que el software se ha integrado (construido),
se dirigen un conjunto de pruebas de alto nivel. Se deben comprobar
los criterios de validacin (establecidos durante el anlisis de
requisitos). La prueba de validacin proporciona una seguridad
final de que el software satisface todos los requisitos funcionales, de
comportamiento y de rendimiento. Durante la validacin se usan
exclusivamente tcnicas de prueba de caja negra.

Direccin de las pruebas