9-11-2015

DISEO Y
REALIZACIN
DE PRUEBAS

DISEO Y REALIZACIN DE PRUEBAS

1.- Planificacin de las pruebas.
Durante todo el proceso de desarrollo de software, desde la fase de diseo, en la
implementacin y una vez desarrollada la aplicacin, es necesario realizar un conjunto de
pruebas (Proceso que permite verificar y revelar la calidad de un producto software. Se utilizan para
identificar posibles fallos de implementacin, calidad o usabilidad de un programa), que permitan
verificar que el software que se est creando, es correcto y cumple con las especificaciones impuesta
por el usuario.
En el proceso de desarrollo de software, nos vamos a encontrar con un conjunto de
actividades, donde es muy fcil que se produzca un error humano. Estos errores humanos
pueden ser: una incorrecta especificacin de los objetivos, errores producidos durante el proceso de
diseo y errores que aparecen en la fase de desarrollo.
Mediante la realizacin de pruebas se software, se van a realizar las tareas de verificacin
(Proceso por el que se comprueba que el software cumple los requisitos especificados) y validacin
(Proceso que comprueba si el software hace lo que el usuario deseaba. Tiene que estar verificado)
del software. La verificacin es la comprobacin que un sistema o parte de un sistema, cumple
con las condiciones impuestas. Con la verificacin se comprueba si la aplicacin se est
construyendo correctamente. La validacin es el proceso de evaluacin del sistema o de uno de
sus componentes, para determinar si satisface los requisitos especificados.
Para llevar a cabo el proceso de pruebas, de manera eficiente, es necesario implementar una
estrategia de pruebas. Siguiendo el Modelo en Espiral (Modelo de ciclo de vida de ciclo de vida del
software, en el que las actividades se conforman en una espiral. Cada bucle o iteracin representa
un conjunto de actividades), las pruebas empezaran con la prueba de unidad, donde se analizara el
cdigo implementado y seguiramos en la prueba de integracin, donde se prestan atencin al
diseo y la construccin de la arquitectura del software. El siguiente paso sera la prueba de
validacin, donde se comprueba que el sistema construido cumple con lo establecido en el
anlisis de requisitos de software. Finalmente se alcanza la prueba de sistema que verifica el
funcionamiento total del software y otros elementos del sistema.

2.- Tipos de prueba.

No existe una clasificacin oficial o formal, sobre los diversos tipos de pruebas de software. En
la ingeniera del software, nos encontramos con dos enfoques fundamentales:

Prueba de la Caja Negra (Black Box Testing): cuando una

aplicacin es probada usando su interfaz externa, sin
preocuparnos de la implementacin de la misma. Aqu lo
fundamental es comprobar que los resultados de la ejecucin
de la aplicacin, son los esperados, en funcin de las
entradas que recibe.
Prueba de la Caja Blanca (White Box Testing): en este caso, se
prueba la aplicacin desde dentro, usando su lgica de
aplicacin.
2

Una prueba de tipo Caja Negra se lleva a cabo sin tener que conocer ni la estructura, ni el
funcionamiento interno del sistema. Cuando se realiza este tipo de pruebas, solo se conocen
las entradas adecuadas que deber recibir la aplicacin, as como las salidas que les correspondan,
pero no se conoce el proceso mediante el cual la aplicacin obtiene esos resultados.
En contraposicin a lo anterior, una prueba de Caja Blanca, va a analizar y probar
directamente el cdigo de la aplicacin. Como se deriva de lo anterior, para llevar a cabo una
prueba de Caja Blanca, es necesario un conocimiento especfico del cdigo, para poder analizar los
resultados de las pruebas.
TIPOS DE PRUEBAS DEL SOFTWARE
Pruebas de unidad
Con ella se va a probar el correcto funcionamiento de un mdulo de
cdigo
Pruebas de carga
Pruebas para determinar y validar la respuesta de la aplicacin cuando
es sometida a una carga de usuarios y/o transacciones que se espera
en el ambiente de produccin. Ejemplo: verificar la correcta respuesta
de la aplicacin ante el alta de 100 usuarios en forma simultnea. Se
compara con el volumen esperado. Si la base de datos, el servidor de
aplicaciones, etc tambin se monitorizan, entonces esta prueba puede
mostrar el cuello de botella en la aplicacin
Prueba
de
Estas pruebas se realizan para medir la respuesta de la aplicacin a
rendimiento
distintos volmenes de carga esperados (cantidad de usuarios y/o
peticiones). Ejemplo: velocidad de respuesta al procesar el ingreso de
10, 100 y 1000 usuarios en forma simultnea. Se comprar con el
rendimiento esperado.
Prueba de estrs
Esta prueba se utiliza normalmente para romper la aplicacin. Se va
doblando el nmero de usuarios que se agregan a la aplicacin y se
ejecuta una prueba de carga hasta que se rompe. Son pruebas de carga
o rendimiento, pero superando los lmites esperados en el ambiente de
produccin y/o determinados en las pruebas. Ejemplo: encontrar la
cantidad de usuarios simultneos, en que la aplicacin deja de
responder (cuelgue o time out) en forma correcta a todas las
peticiones.
Pruebas de picos
La prueba de picos, como el nombre sugiere, trata de observar el
comportamiento del sistema variando el nmero de usuarios, tanto
cuando bajan, como cuando tiene cambios drsticos en su carga.
Esta prueba se recomienda que sea realizada con un software
automatizado que permita realizar cambios en el nmero de usuarios
mientras que los administradores llevan un registro de los valores a ser
monitorizados
Prueba estructural
El enfoque estructural o de caja blanca se centra en la estructura
interna del programa (analiza los caminos de ejecucin).
Prueba funcional
El enfoque funcional o de caja negra se centra en las funciones,
entradas y salidas que recibe y produce un mdulo o funcin concreta.
Pruebas
de
El objetivo de las pruebas de regresin es garantizar que ante cualquier
regresin
modificacin al cdigo actual, ya sea por mantenimiento o por la
incorporacin de nueva funcionalidad, no se vea afectada en el resto de
las secciones que integran a la aplicacin.

2.1.- Pruebas de caja blanca o estructurales.

A este tipo de tcnicas se le conoce
tambin como Tcnicas de Caja
Transparente o de Cristal. Este mtodo
se centra en cmo disear los casos de
prueba atendiendo al comportamiento
interno y la estructura del programa. Se
examina as la lgica interna del
programa sin considerar los aspectos de
rendimiento.
El objetivo de la tcnica es disear casos de prueba para que se ejecuten, al menos una vez, todas las
sentencias del programa, y todas las condiciones tanto en su vertiente verdadera como falsa. Como se
ha indicado ya, puede ser impracticable realizar una prueba exhaustiva de todos los caminos de un
programa. Por ello se han definido distintos criterios de cobertura lgica, que permiten decidir qu
sentencias o caminos se deben examinar con los casos de prueba. Estos criterios son:

Cobertura de Sentencias: Se escriben casos de prueba suficientes para que cada sentencia en el
programa se ejecute, al menos, una vez.
Cobertura de Decisin: Se escriben casos de prueba suficientes para que cada decisin en el
programa se ejecute una vez con resultado verdadero y otra con el falso.
Cobertura de Condiciones: Se escriben casos de prueba suficientes para que cada condicin en
una decisin tenga una vez resultado verdadero y otra falso.
Cobertura de Condicin Mltiple: Se escriben casos de prueba suficientes para que todas las
combinaciones posibles de resultados de cada condicin se invoquen al menos una vez.
Cobertura de Caminos: Se escriben casos de prueba suficientes para que se ejecuten todos los
caminos de un programa. Entendiendo camino como una secuencia de sentencias encadenadas
desde la entrada del programa hasta su salida.

2.2.- Pruebas de Caja Negra o Funcionales.

Tambin conocidas como Pruebas de Comportamiento, estas pruebas se basan en la especificacin
del programa o componente a ser probado para elaborar los casos de prueba. El componente se ve
como una Caja Negra cuyo comportamiento slo puede ser determinado estudiando sus entradas y las
salidas obtenidas a partir de ellas. No obstante, como el estudio de todas las posibles entradas y salidas
de un programa sera impracticable se selecciona un conjunto de ellas sobre las que se realizan las
pruebas. Para seleccionar el conjunto de entradas y salidas sobre las que trabajar, hay que tener en
cuenta que en todo programa existe un conjunto de entradas que causan un comportamiento errneo
en nuestro sistema, y como consecuencia producen una serie de salidas que revelan la presencia de
defectos. Entonces, dado que la prueba exhaustiva es imposible, el objetivo final es pues, encontrar una
serie de datos de entrada cuya probabilidad de pertenecer al conjunto de entradas que causan dicho
comportamiento errneo sea lo ms alto posible.

Al igual que ocurra con las tcnicas de Caja Blanca, para confeccionar los casos de prueba de
Caja Negra existen distintos criterios. Algunos de ellos son:
Particiones de Equivalencia.
Anlisis de Valores Lmite.
Mtodos Basados en Grafos.
Pruebas de Comparacin.
Anlisis Causa-Efecto.

2.2.1. Particiones de equivalencia

Este mtodo intenta dividir el dominio de entrada de un programa en un nmero finito de clases
de equivalencia. De tal modo que se pueda asumir razonablemente que una prueba realizada con un
valor representativo de cada clase es equivalente a una prueba realizada con cualquier otro valor de
dicha clase. Esto quiere decir que, si el caso de prueba correspondiente a una clase de equivalencia
detecta un error, el resto de los casos de prueba de dicha clase de equivalencia deben detectar el mismo
error. Y viceversa, si un caso de prueba no ha detectado ningn error, es de esperar que ninguno de los
casos de prueba correspondientes a la misma clase de equivalencia encuentre ningn error.
El diseo de casos de prueba segn esta tcnica consta de dos pasos:
1. Identificar las clases de equivalencia.
2. Identificar los casos de prueba.
1. Identificar las clases de equivalencia.
Una clase de equivalencia representa un conjunto de estados vlidos y no vlidos para las condiciones
de entrada de un programa. Las clases de equivalencia se identifican examinando cada condicin de
entrada (normalmente una frase en la especificacin) y dividindola en dos o ms grupos. Se definen
dos tipos de clases de equivalencia, las clases de equivalencia vlidas, que representan entradas vlidas
al programa, y las clases de equivalencia no vlidas, que representan valores de entrada errneos. Estas
clases se pueden representar en una tabla como la siguiente:
Condicin Externa

Clases de Equivalencia Vlidas

Clases de Equivalencia No Vlidas

Por ejemplo: Entero para identificar el nmero de espectadores de un teatro (en nuestro caso el aforo
es de 200)
Condicin Externa
[0..200]

Clases de Equivalencia Vlidas

Nmeros entre 0 y 200

Clases de Equivalencia No Vlidas

Nmeros menores que 0
Nmeros mayores que 200

2. Identificar los casos de prueba.

Para crear los casos de prueba a partir de las clases de equivalencia se han de seguir los siguientes
pasos:
1. Asignar a cada clase de equivalencia un nmero nico.
2. Hasta que todas las clases de equivalencia hayan sido cubiertas por los casos de prueba, se
tratar de escribir un caso que cubra tantas clases vlidas no incorporadas como sea posible.
3. Hasta que todas las clases de equivalencia no vlidas hayan sido cubiertas por casos de prueba,
escribir un caso para cubrir una nica clase no vlida no cubierta.
Num
1
2
3
4
5
6

2.2.2.

Caso de Prueba
E<0
E=0
E>0
E=200
E<200
E>200

Validez
No vlido
Vlido
Vlido
Vlido
Vlido
No vlido

Representante
-1
0
1
200
199
201

Anlisis de valores lmite

La experiencia muestra que los casos de prueba que exploran las condiciones lmite producen mejor
resultado que aquellos que no lo hacen. Las condicione lmite son aquellas que se hayan en los mrgenes
de la clase de equivalencia, tanto de entrada como de salida. Por ello, se ha desarrollado el anlisis de
valores lmite como tcnica de prueba. Esta tcnica nos lleva a elegir los casos de prueba que ejerciten los
valores lmite.
Por lo tanto, el anlisis de valores lmite complementa la tcnica de particin de equivalencia de manera
que:
En lugar de seleccionar cualquier caso de prueba de las clases vlidas e invlidas, se eligen los
casos de prueba en los extremos.
En lugar de centrase slo en el dominio de entrada, los casos de prueba se disean tambin
considerando el dominio de salida.
Las pautas para desarrollar casos de prueba con esta tcnica son:
Si una condicin de entrada especifica un rango de valores (-l.0 valor +1.0) se deben generar
casos para los extremos del rango (-1.0 y +1.0) y casos no vlidos para situaciones justo ms all
de los extremos (- 1.001 y + 1.001, en el caso en que se admitan 3 decimales).
Si la condicin de entrada especifica un nmero de valores (el fichero de entrada tendr de 1 a
255 registros), hay que escribir casos para los nmeros mximo, mnimo, uno ms del mximo
y uno menos del mnimo de valores (0, 1, 255 y 256 registros).
Si la entrada o salida de un programa es un conjunto ordenado, habr que prestar atencin a los
elementos primero y ltimo del conjunto.
Ejemplo: la capacidad mxima de un teatro es de 200 personas (son unidades completas)
Num
1
2
3

Caso de Prueba
E<0
E=0
E=200

Validez
No vlido
Vlido
Vlido

Representante
-1
0
200
6

E>200

No vlido

201

EJERCICIO 1: Disea casos de prueba identificando las clases de equivalencia y

posteriormente los casos de prueba para un valor entero introducido por el usuario que
represente el nmero de mes [1..31]:
Ejercicio01-Nombre-Apellidos.doc

2.3.- Regresin.
Durante el proceso de prueba, tendremos xito si detectamos un posible fallo o error. La
consecuencia directa de ese descubrimiento, supone la modificacin del componente donde se ha
detectado. Esta modificacin, puede generar errores colaterales, que no existan antes. Como
consecuencia, la modificacin realizada nos obliga a repetir pruebas que hemos realizado con
anterioridad.
El objetivo de las pruebas de regresin, es comprobar que los cambios sobre un componente de una
aplicacin, no introduce un comportamiento no deseado o errores adicionales en otros componentes
no modificados.

Las pruebas de regresin se deben llevar a cabo cada vez que se hace un cambio en el
sistema, tanto para corregir un error, como para realizar una mejora. No es suficiente
probar slo los componentes modificados o aadidos, o las funciones que en ellos se
realizan, sino que tambin es necesario controlar que las modificaciones no produzcan
efectos negativos sobre el mismo u otros componentes.

Normalmente, este tipo de pruebas implica la repeticin de las pruebas que ya se hayan realizado
previamente, con el fin de asegurar que no se introducen errores que puedan comprometer el
funcionamiento de otros componentes que no han sido modificados y confirmar que el sistema
funciona correctamente una vez realizados los cambios.
En un contexto ms amplio, las pruebas de software con xito, son aquellas que dan como resultado
el descubrimiento de errores. Como consecuencia del descubrimiento de errores, se procede a su
correccin, lo que implica la modificacin de algn componente del software que se est
desarrollando, tanto del programa, de la documentacin y de los datos que lo soportan. La prueba de
regresin es la que nos ayuda a asegurar que estos cambios no introducen un comportamiento no
deseado o errores adicionales. La prueba de regresin se puede hacer manualmente, volviendo a
realizar un subconjunto de todos los casos de prueba o utilizando herramientas automticas.
7

El conjunto de pruebas de regresin contiene tres clases diferentes de clases de prueba:

Una muestra representativa de pruebas que ejercite todas las funciones del software;

Pruebas que se centran en los componentes del software que han cambiado.

Pruebas adicionales que se centran en las funciones del software que se van a ver
probablemente afectadas por el cambio;

Para evitar que el nmero de pruebas de regresin crezca demasiado, se deben de disear para
incluir slo aquellas pruebas que traten una o ms clases de errores en cada una de las funciones
principales del programa. No es prctico ni eficiente volver a ejecutar cada prueba de cada funcin
del programa despus de un cambio.

3.- Herramientas de depuracin.

Cada IDE (Integrated Development Environment) incluye herramientas de depuracin como:
inclusin de puntos de ruptura, ejecucin paso a paso de cada instruccin, ejecucin por
procedimiento, inspeccin de variables, etc.

Todo entorno de desarrollo, independientemente de la plataforma, as como del lenguaje de

programacin utilizado, suministra una serie de herramientas de depuracin, que nos permiten
verificar el cdigo generado, ayudndonos a realizar pruebas tanto estructurales como funcionales.
Durante el proceso de desarrollo de software, se pueden producir dos tipos de errores: errores de
compilacin o errores lgicos. Cuando se desarrolla una aplicacin en un IDE, ya sea Visual Studio,
Eclipse o Netbeans, si al escribir una sentencia, olvidamos un ";", hacemos referencia a una variable
inexistente o utilizamos una sentencia incorrecta, se produce un error de compilacin. Cuando
ocurre un error de compilacin, el entorno nos proporciona informacin de donde se produce y
como poder solucionarlo. El programa no puede compilarse hasta que el programador o
programadora no corrija ese error.
El otro tipo de errores son lgicos, comnmente llamados bugs, estos no evitan que el programa se
pueda compilar con xito, ya que no hay errores sintcticos, ni se utilizan variables no declaradas,
etc. Sin embargo, los errores lgicos, pueden provocar que el programa devuelva resultados
errneos, que no sean los esperados o pueden provocar que el programa termine antes de tiempo o
no termine nunca.
Para solucionar este tipo de problemas, los entornos de desarrollo incorporan una herramienta
conocida como depurador. El depurador permite supervisar la ejecucin de los programas, para
localizar y eliminar los errores lgicos. Un programa debe compilarse con xito para poder utilizarlo
en el depurador. El depurador nos permita analizar todo el programa, mientras ste se ejecuta.
Permite suspender la ejecucin de un programa, examinar y establecer los valores de las variables,
comprobar los valores devueltos por un determinado mtodo, el resultado de una comparacin
lgica o relacional, etc.

3.1.- Puntos de ruptura.

Dentro del men de depuracin, nos encontramos con la opcin insertar punto de ruptura
(breakpoint). Se selecciona la lnea de cdigo donde queremos que el programa se pare, para a partir
de ella, inspeccionar variables, o realizar una ejecucin paso a paso, para verificar la correccin del
cdigo.
Durante la prueba de un programa, puede ser interesante la verificacin de determinadas partes del
cdigo. No nos interesa probar todo el programa, ya que hemos delimitado el punto concreto donde
inspeccionar. Para ello, utilizamos los puntos de ruptura.
Los puntos de ruptura son marcadores que pueden establecerse en cualquier lnea de cdigo
ejecutable (no sera vlido un comentario, o una lnea en blanco). Una vez insertado el punto de
ruptura, e iniciada la depuracin, el programa a evaluar se ejecutara hasta la lnea marcada con el
punto de ruptura. En ese momento, se pueden realizar diferentes labores, por un lado, se pueden
examinar las variables, y comprobar que los valores que tienen asignados son correctos, o se pueden
iniciar una depuracin paso a paso, e ir comprobando el camino que toma el programa a partir del
punto de ruptura. Una vez realiza la comprobacin, podemos abortar el programa, o continuar la
ejecucin normal del mismo.
Dentro de una aplicacin, se pueden insertar varios puntos de ruptura, y se pueden eliminar con la
misma facilidad con la que se insertan.

3.2.- Tipos de ejecucin.

Para poder depurar un programa, podemos ejecutar el programa de diferentes formas, de manera
que en funcin del problema que queramos solucionar, nos resulte ms sencillo un mtodo u otro.
Nos encontramos con lo siguientes tipo de ejecucin: paso a paso por instruccin, paso a paso por
procedimiento, ejecucin hasta una instruccin, ejecucin de un programa hasta el final del
programa,

Algunas veces es necesario ejecutar un programa lnea por lnea, para buscar y corregir
errores lgicos. El avance paso a paso a lo largo de una parte del programa puede ayudarnos
a verificar que el cdigo de un mtodo se ejecute en forma correcta.

El paso a paso por procedimientos, nos permite introducir los parmetro que queremos a un
mtodo o funcin de nuestro programa, pero en vez de ejecutar instruccin por instruccin
ese mtodo, nos devuelve su resultado. Es til, cuando hemos comprobado que un
procedimiento funciona correctamente, y no nos interese volver a depurarlo, slo nos
interesa el valor que devuelve.

En la ejecucin hasta una instruccin, el depurador ejecuta el programa, y se detiene en la

instruccin donde se encuentra el cursor, a partir de ese punto, podemos hacer una
depuracin paso a paso o por procedimiento.

En la ejecucin de un programa hasta el final del programa, ejecutamos las instrucciones de

9

un programa hasta el final, sin detenernos en las instrucciones intermedias.

Los distintos modos de ejecucin, se van a ajustar a las necesidades de depuracin que
tengamos en cada momento. Si hemos probada un mtodo, y sabemos que funciona
correctamente, no es necesario realizar una ejecucin paso a paso en l.

En el IDE NetBeans, dentro del men de depuracin, podemos seleccionar los modos de ejecucin
especificados, y algunos ms. El objetivo es poder examinar todas las partes que se consideren
necesarias, de manera rpida, sencilla y los ms clara posible.

3.3.- Examinadores de variables.

Durante el proceso de implementacin y prueba de software, una de las maneras ms comunes de
comprobar que la aplicacin funciona de manera adecuada, es comprobar que las variables vayan
tomando los valores adecuados en cada momento.
Los examinadores de variables, forman uno de los elementos ms importantes del proceso de
depuracin de un programa. Iniciado el proceso de depuracin, normalmente con la ejecucin paso a
paso, el programa avanza instruccin por instruccin. Al mismo tiempo, las distintas variables, van
tomando diferentes valores. Con los examinadores de variables, podemos comprobar los distintos
valores que adquieren las variables, as como su tipo. Esta herramienta es de gran utilidad para la
deteccin de errores.
En el caso del entorno de desarrollo NetBeans, nos
encontramos con un panel llamado Ventana de
Inspeccin. En la ventana de inspeccin, se pueden
ir agregando todas aquellas variables de las que
tengamos inters en inspeccionar su valor.
Conforme el programa se vaya ejecutando,
NetBeans ir mostrando los valores que toman las
variables en la ventana de inspeccin.
Como podemos apreciar, en una ejecucin paso a
paso, el programa llega a una funcin de nombre
potencia. Esta funcin tiene definida tres variables.
A lo largo de la ejecucin del bucle, vemos como la
variable result, van cambiando de valor. Si con
valores de entrada para los que conocemos el resultado, la funcin no devuelve el valor esperado,
"Examinando las variables" podremos encontrar la instruccin incorrecta.
Los depuradores son programas que permiten analizar de manera exhaustiva y en paso a paso, lo
que pasa dentro del cdigo de un programa. Gracias a los depuradores es fcil probar las aplicaciones
para encontrar los posibles errores, analizando sus causas y posibles soluciones.
En el caso del IDE NetBeans, que es el que utilizamos en el ejemplo, estas utilidades estn integradas
en el entorno de desarrollo
INICIO DE LA DEPURACIN
Para conocer las opciones ms habituales de depuracin en NetBeans, vamos a depurar un pequeo
programa. Este programa dispone de una clase Vector, que implementa algunos mtodos, como
insertar y ordenar.
Para iniciar la depuracin del programa, en el men principal, seleccionamos Depurar.
10

Como hemos indicado, el objetivo de la depuracin es la deteccin de errores en la aplicacin. Para

encontrar los posibles errores, o comprobar el buen diseo de una aplicacin, debemos navegar por
el cdigo diseado. Podemos analizar el cdigo de varias formas:
Paso a paso: en cuyo caso vamos a ir ejecutando instruccin por instruccin, todo el cdigo.
Ejecutar hasta el cursor: El cursor tendr el foco en una determinada instruccin. El depurador
ejecutar el programa y se parar cuando llegue a esa instruccin. Esto es til, si ya hemos analizado
parte del cdigo y no nos interesa volver a depurarlo, ganando tiempo.
LA DEPURACIN
Una vez iniciada la depuracin (paso a paso o ejecutar hasta el cursor), podemos decidir detener la
depuracin, continuarla, o ejecutar el programa hasta el final.
Podemos elegir Entrar en el siguiente mtodo, si queremos analizarlo, o seguir con la ejecucin paso
a paso con la tecla F7.
Si el mtodo en cuestin, no necesita depuracin podemos Continuar Ejecucin o pulsar F8, con esto
el mtodo se ejecuta, pero entramos en su cdigo. Si no nos interesa seguir con la depuracin,
podemos seleccionar Finalizar sesin del depurador, si queremos pausar la depuracin Pausa y si
queremos seguir la ejecucin normal, o seguir hasta el siguiente punto de ruptura Continuar.
Otras opciones del depurador son:
Consulta de la pila (stack) para comprobar las
funciones que estn siendo llamadas.
Insercin de puntos de interrupcin, para indicar la
lnea de cdigo que queremos analizar con el
depurador
Evaluar expresin, que nos sirve para comprobar los
valores que toma dicha expresin.
Si hacemos una depuracin paso a paso, vamos a ir
instruccin por instruccin. Esto nos ayuda a
comprobar que los caminos que hemos diseado en el cdigo se pueden recorrer.
Como vemos en el ejemplo, hay un bucle que se repite 75 veces, si
depuramos paso a paso, la ejecucin del mtodo v.insertar(),
deberamos realizarla 75 veces. En general, se entra una vez en el
mtodo, y se realiza la depuracin.
Para pasar a otra parte de cdigo que s queramos depurar, podemos
colocar el cursor en la instruccin en cuestin, y pulsamos Ejecutar hasta
el cursor, o bien, podemos ejecutar y para en el siguiente punto de
ruptura.
Para insertar un punto de ruptura, colocamos el cursor en la instruccin
que nos interese, o pulsamos en la parte izquierda de la ventana.
Nos aparecer la instruccin sealada en rojo. Esto significa, que cuando depuremos,
independientemente del tipo de depuracin, vamos a parar en esa instruccin. Esto es til para
depurar una parte de cdigo a partir de ese punto de ruptura.
11

La lnea verde, me indica la instruccin por la que va analizando el depurador. En la imagen, tambin
podemos observar la ventana de variables. Esta ventana se utiliza en depuracin para inspeccionar el
valor que van tomando a lo largo de la ejecucin.
En nuestro ejemplo depuramos un mtodo de ordenacin de un array, vemos los valores que toman
las variables i, j y temp, as como el tipo al que estn definidas. Podemos evaluar las expresiones que
queramos. En este caso estamos evaluando los valores que toman las variables i, j y temp, y tambin
comprobamos los valores almacenados en el vector. Si durante la depuracin comprobamos que
la aplicacin no hace aquello que debiera, podemos cambiarla. Si hemos depurado, y consideramos
que la aplicacin funciona, podemos pasar a probarla. Para ello, diseamos casos de prueba en Junit y
los aplicamos
EJERCICIO 2: Por fin hemos encontrado trabajo y nuestra primera tarea es realizar el
mantenimiento de un Proyecto. El programador que realiz dicho Proyecto ya no est en la
empresa y tampoco dej ninguna documentacin. Por lo tanto, antes de ponernos con el
mantenimiento es necesario que sepamos que funciones desarrolla el software. As, que
ayudndonos de la herramienta de depuracin tenemos que saber qu realiza el programa.
Se pide que a partir de los programas que os proporcione el profesor:
Averiguar qu hace cada uno de los programas.
Una vez que se sepa lo que hace cada programa, ser necesario
aadir comentarios significativos al cdigo, renombrar variables
con nombres significativos, cambiar los mensajes que se
proporciona a los usuarios finales,. Todo aquello que creais que
facilitar el futuro mantenimiento del programa, para t u otro
compaero.

4.- Validaciones.
En el proceso de validacin, interviene de manera decisiva el cliente. Hay que tener en cuenta, que
estamos desarrollando una aplicacin para terceros, y que son estos los que deciden si la aplicacin
se ajusta a los requerimientos establecidos en el anlisis.
En la validacin intentan descubrir errores, pero desde el punto de vista de los requisitos
(Comportamiento y casos de uso que se esperan que cumpla el software que se est diseando).

La validacin del software se consigue mediante una serie de pruebas de caja negra que demuestran
la conformidad con los requisitos. Un plan de prueba traza la clase de pruebas que se han de llevar a
cabo, y un procedimiento de prueba define los casos de prueba especficos en un intento por
descubrir errores de acuerdo con los requisitos. Tanto el plan como el procedimiento estarn
diseados para asegurar que se satisfacen todos los requisitos funcionales, que se alcanzan todos los
requisitos de rendimiento, que las documentaciones son correctas e inteligible y que se alcanzan
otros requisitos, como portabilidad (Capacidad de un programa para ser ejecutado en cualquier
arquitectura fsica de un equipo), compatibilidad, recuperacin de errores, facilidad de
mantenimiento etc.
Cuando se procede con cada caso de prueba de validacin, puede darse una de las dos condiciones
siguientes:

Las caractersticas de funcionamiento o rendimiento estn de acuerdo con las especificaciones

y son aceptables o

Se descubre una desviacin de las especificaciones y se crea una lista de deficiencias.

Las desviaciones o errores descubiertos en esta fase del proyecto raramente se pueden
corregir antes de la terminacin planificada.
12

5.- Pruebas de cdigo.

La prueba consiste en la ejecucin de un programa con el objetivo de encontrar errores. El programa
o parte de l, se va a ejecutar bajo unas condiciones previamente especificadas, para una vez
observados los resultados, estos sean registrados y evaluados.
Para llevar a cabo las pruebas, es necesario definir una serie de casos de prueba, que van a ser un
conjunto de entradas, de condiciones de ejecucin y resultados esperados, desarrollados para un
objetivo particular.
Para el diseo de casos de prueba, se suelen utilizar tres enfoques principales:

Enfoque estructural o de caja blanca. Este enfoque se centra en la estructura interna del
programa, analizando los caminos de ejecucin. Dentro de nuestro proceso de prueba, lo
aplicamos con el cubrimiento.
Enfoque funcional o de caja negra. Este enfoque se centra en las funciones, entradas y salidas.
Se aplican los valores lmite y las clases de equivalencia.
Enfoque aleatorio, que consiste en utilizar modelos que represente las posibles entradas
al programa, para crear a partir de ellos los casos de prueba. En esta prueba se intenta
simular la entrada habitual que va a recibir el programa, para ello se crean datos entrada en la
secuencia y con la frecuencia en que podran aparecer. Para ello se utilizan generadores
automticos de casos de prueba.

Autoevaluacin
Durante la validacin:
Procedemos a depurar el programa.
Sometemos el cdigo a pruebas de cubrimiento.
Comprobamos que la aplicacin cumple los requerimientos del cliente.
En esta prueba, es el cliente, junto con el equipo de desarrollo, quienes comprueban que lo desarrollado cumple las especificaciones
establecidas.

5.1.- Cubrimiento.
Esta tarea la realiza el programador y consiste en comprobar que los caminos definidos en el
cdigo, se pueden llegar a recorrer.

Este tipo de prueba, es de caja blanca, ya que nos vamos a centrar en el cdigo de nuestra aplicacin.
Con este tipo de prueba, lo que se pretende, es
comprobar que todas las funciones, sentencias,
decisiones, y condiciones, se van a ejecutar.
Por ejemplo:
Considerando que esta funcin forma parte de un
programa mayor, se considera lo siguiente:

Si durante la ejecucin del programa, la funcin es llamada, al menos una vez, el cubrimiento
de la funcin es satisfecho.
El cubrimiento de sentencias para esta funcin, ser satisfecho si es invocada, por ejemplo
como prueba(1,1), ya que en esta caso, cada lnea de la funcin se ejecuta, incluida z=x;
Si invocamos a la funcin con prueba(1,1) y prueba(0,1), se satisfar el cubrimiento de
decisin.
En el primer caso, la if condicin va a ser verdadera, se va a ejecutar z=x, pero en el
13

segundo caso, no.

El cubrimiento de condicin puede satisfacerse si probamos con prueba(1,1), prueba(1,0)

y prueba(0,0). En los dos primeros casos (x<0) se evala a verdad mientras que en el tercero,
se evala a falso. Al mismo tiempo, el primer caso hace (y>0) verdad, mientras el tercero lo
hace falso.
Existen herramientas comerciales y tambin de software libre, que permiten realizar la pruebas de
cubrimiento, entre ellas, para Java, nos encontramos con Clover, Emma, VectorCAST o Cobertura.
Para NetBeans existe el plugin JaCoCoverage: http://plugins.netbeans.org/plugin/48570/tikionejacocoverage

EJERCICIO 3: Descarga el plugin de JaCoCoverage, y realiza un manual sobre su instalacin

y funcionamiento.

Ejercicio01-Nombre-Apellidos.doc

5.2. Valores lmite.

En el cdigo Java adjunto, aparecen dos funciones que reciben el
parmetro x. En la funcin1, el parmetro es de tipo real y en la funcin2,
el parmetro es de tipo entero.
Como se aprecia, el cdigo de las dos funciones es el mismo, sin embargo,
los casos de prueba con valores lmite va a ser diferente.
La experiencia ha demostrado que los casos de prueba que obtienen una mayor
probabilidad de xito, son aquellos que trabajan con valores lmite.
Esta tcnica, se suele utilizar como complementaria de las particiones equivalentes, pero se
diferencia, en que se suelen seleccionar, no un conjunto de valores, sino unos pocos, en el lmite del
rango de valores aceptado por el componente a probar.
Cuando hay que seleccionar un valor para realizar una prueba, se escoge aquellos que estn situados
justo en el lmite de los valores admitidos.
Por ejemplo, supongamos que queremos probar el resultado de la ejecucin de una funcin, que
recibe un parmetro x:

Si el parmetro x de entrada tiene que ser mayor estricto que 5, y el valor es real, los
valores lmite pueden ser 4,99 y 5,01.

Si el parmetro de entrada x est comprendido entre 4 y +4, suponiendo que son

valores enteros, los valores lmite sern 5, 4 ,3,3, 4 y 5.

5.3.- Clases de equivalencia.

Las clases de equivalencia, es un tipo de prueba funcional, en donde cada caso de prueba, pretende
cubrir el mayor nmero de entradas posible.
El dominio de valores de entrada, se divide en nmero finito de clases de equivalencia. Como la
entrada est dividida en un conjunto de clases de equivalencia, la prueba de un valor representativo
de cada clase, permite suponer que el resultado que se obtiene con l, ser el mismo que con
cualquier otro valor de la clase.
Cada clase de equivalencia debe cumplir:
14

Si un parmetro de entrada debe estar comprendido entre un determinado rango, hay

tres clases de equivalencia: por debajo, en y por encima.
Si una entrada requiere un valor entre los de un conjunto, aparecen dos clase de
equivalencia: en el conjunto o fuera de l.
Si una entrada es booleana, hay dos clases: s o no.
Los mismos criterios se aplican a las salidas esperadas: hay que intentar generar resultados
en todas y cada una de las clases.

En este ejemplo, las clases de equivalencia seran:

1. Por debajo: x<=0
2. En: x>0 y x< 100
3. Por encima: x>=100
y los respectivos casos de prueba, podran ser:
1. Por debajo: x=0
2. En: x=50
3. Por encima: x=100

6.- Pruebas unitarias.

Las pruebas unitarias, o prueba de la unidad, tienen por
objetivo probar el correcto funcionamiento de un mdulo
de cdigo. El fin que se persigue, es que cada mdulo
funciona correctamente por separado.
Posteriormente, con la prueba de integracin, se podr
asegurar el correcto funcionamiento del sistema.
Una unidad es la parte de la aplicacin ms pequea que
se puede probar. En programacin procedural, una unidad
puede ser una funcin o procedimiento, En programacin orientada a objetos, una unidad es
normalmente un mtodo.
Con las pruebas unitarias se debe probar todas las funciones o mtodos no triviales de forma que
cada caso de prueba sea independiente del resto.
En el diseo de los casos de pruebas unitarias, habr que tener en cuenta los siguientes requisitos:

Automatizable: no debera requerirse una intervencin manual.

Completas: deben cubrir la mayor cantidad de cdigo.
Repetibles o Reutilizables: no se deben crear pruebas que slo puedan ser ejecutadas una sola
vez.

Independientes: la ejecucin de una prueba no debe afectar a la ejecucin de otra.

Profesionales: las pruebas deben ser consideradas igual que el cdigo, con la misma
profesionalidad, documentacin, etc.
El objetivo de las pruebas unitarias es aislar cada parte del programa y demostrar que las partes
individuales son correctas. Las pruebas individuales nos proporcionan cinco ventajas bsicas:
1. Fomentan el cambio: Las pruebas unitarias facilitan que el programador cambie el cdigo para
mejorar su estructura, puesto que permiten hacer pruebas sobre los cambios y as asegurarse de
que los nuevos cambios no han introducido errores.
2. Simplifica la integracin: Puesto que permiten llegar a la fase de integracin con un grado alto
de seguridad de que el cdigo est funcionando correctamente.
15

3. Documenta el cdigo: Las propias pruebas son documentacin del cdigo puesto que ah se
puede ver cmo utilizarlo.
4. Separacin de la interfaz y la implementacin: Dado que la nica interaccin entre los casos de
prueba y las unidades bajo prueba son las interfaces de estas ltimas, se puede cambiar
cualquiera de los dos sin afectar al otro.
5. Los errores estn ms acotados y son ms fciles de localizar: dado que tenemos pruebas
unitarias que pueden desenmascararlos.

8.1.- Herramientas para Java.

Entre las herramientas que nos podemos encontrar en el mercado, para poder realizar las pruebas,
las ms destacadas seran:
TestNG:
Esta inspirado en JUnit y NUnit.
Est diseado para cubrir todo tipo de pruebas, no solo las unitarias, sino tambin las
funcionales, las de integracin ...
Es compatible con pruebas de Junit.
Soporte para el paso de parmetros a los mtodos de pruebas.
Permite la distribucin de pruebas en maquinas esclavas.
Soportado por gran variedad de plugins (Eclipse, NetBeans, IDEA ...)
Los clases de pruebas no necesitan implementar ninguna interfaz ni extender ninguna otra
clase.
Una vez compiladas la pruebas, estas se pueden invocar desde la linea de comandos con una
tarea de Ant o con un fichero XML.
Los mtodos de prueba se organizan en grupos (un mtodo puede pertenecer a uno o varios
grupos).
Junit:
Framework de pruebas unitarias creado por Erich Gamma y Kent Beck.
Es una herramienta de cdigo abierto.
Multitud de documentacin y ejemplos en la web.
Se ha convertido en el estndar de hecho para las pruebas unitarias en Java.
Soportado por la mayora de los IDE como eclipse o Netbeans.
Es una implementacin de la arquitectura xUnit para los frameworks de pruebas unitarias.
Posee una comunidad mucho mayor que el resto de los frameworks de pruebas en Java.
Soporta mltiples tipos de aserciones.
Desde la versin 4 utiliza las anotaciones del JDK 1.5 de Java.
Posibilidad de crear informes en HTML.
Organizacin de las pruebas en Suites de pruebas.
Es la herramienta de pruebas ms extendida para el lenguaje Java.
Los entornos de desarrollo para Java, NetBeans y Eclipse, incorporan un plugin para Junit.

8.2.- Herramientas para otros lenguajes.

En la actualidad, nos encontramos con un amplio conjunto de herramientas destinadas a la
automatizacin del prueba, para la mayora de los lenguajes de programacin ms extendidos en la
actualidad. Existen herramientas para C++, para PHP, FoxPro, etc.
Cabe destacar las siguientes herramientas:

CppUnit:
Framework de pruebas unitarias para el lenguaje C++.
Es una herramienta libre.
16

Existe diversos entornos grficos para la ejecucin de pruebas como QtTestRunner.

Es posible integrarlo con mltiples entornos de desarrollo como Eclipse.
Basado en el diseo de xUnit.

Nunit:
Framework de pruebas unitarias para la plataforma .NET.
Es una herramienta de cdigo abierto.
Tambin est basado en xUnit.
Dispone de diversas expansiones como Nunit.Forms o Nunit.ASP. Junit
SimpleTest: Entorno de pruebas para aplicaciones realizadas en PHP.
PHPUnit: framework para realizar pruebas unitarias en PHP.
FoxUnit: framework OpenSource de pruebas unitarias para Microsoft Visual FoxPro

Autoevaluacin
Las herramientas de automatizacin de pruebas ms extendida para Java es:
Junit.
FoxUnit.
Simple
Test.

9.- Automatizacin de la prueba.

Las pruebas de software son parte esencial del ciclo de desarrollo. La elaboracin y
mantenimiento de unidad, pueden ayudarnos a asegurar que los los mtodos individuales de
nuestro cdigo, funcionan correctamente. Los entorno de desarrollo, integran frameworks, que
permiten automatizar las pruebas.
En el caso de entornos de desarrollo para Java, como NetBeans y Eclipse, nos encontramos con el
framework JUnit. JUnit es una herramienta de automatizacin de pruebas que nos permite de
manera rpida y sencilla, elaborar pruebas. La herramienta nos permite disear clases de prueba,
para cada clase diseada en nuestra aplicacin. Una vez creada las clases de prueba, establecemos
los mtodos que queremos probar, y para ello diseamos casos de prueba. Los criterios de creacin
de casos de prueba, pueden ser muy diversos, y dependern de lo que queramos probar.
Una vez diseados los casos de prueba, pasamos a probar la aplicacin. La herramienta de
automatizacin, en este caso Junit, nos presentar un informe con los resultados de la prueba
(imagen anterior). En funcin de los resultados, deberemos o no, modificar el cdigo.

Uso de JUNIT en NetBeans

INTRODUCCIN
Los entornos de desarrollo ms extendidos, que se utilizan para implementar aplicaciones Java, tales
como NetBeans o Eclipse, incorporan un plugin para trabajar con Junit

17

Junit nos va a servir para realizar

pruebas unitarias de clases escritas en
Java, dentro de un entorno de pruebas.
Es un framework con muy pocas clases
fcil de aprender y de utilizar.
Una vez que hemos diseado nuestra
aplicacin, y la hemos depurado,
procedemos a probarla. En el caso del
ejemplo, disponemos de una clase, de
nombre Calculadora, donde se han
definido los mtodos que aparecen en la
imagen.
El objetivo va a ser el diseo y ejecucin de algunos casos de prueba.

INICIO DE JUNIT
Para iniciar Junit, seleccionada en la ventana
de proyectos la clase a probar, o el paquete y
seleccionamos Tools Create/Update Test.
Nos aparece una nueva ventana, lo dejamos
todo igual expect que deseleccionamos las
opciones de Generate Test Suites, Test
Initializer , Test Finalizer y pulsamos OK.

Tras pulsar OK, nos

aparecer la siguiente
ventana donde se nos pide
seleccionar la versin de
JUnit, seleccionaremos la
version
JUnit4.x
y
pulsaremos Select.

18

Y en nuestro Proyecto se nos ha creado un nuevo paquete

denominado Test Packages con las mismas clases
originales pero aadiendo al nombre la palabra Test:
CalculandoTest y MainTest.

El diseo de los casos de prueba, requiere que se establezcan criterios que garanticen que esa
prueba tiene muchas probabilidades de encontrar algn error no detectado hasta el momento.

Para ejecutar el test, tenemos que hacer click sobre el Proyecto y

seleccionar Test.
El resultado inicial Test es el siguiente:

Todos los mtodos fallan, por lo tanto ser necesario crearnos unos casos de prueba, vamos a verlo
ms en detalle

CASOS DE PRUEBA
En primer lugar, vamos a ver la funcin de los Inicializadores y Finalizadores. El mtodo SetUp y el
mtodo tearDown, se utilizan para inicializar y finalizar las condiciones de prueba, como puede ser la
creacin de un objeto, inicializacin de variables, etc. En algunos casos, no es necesario utilizar estos
mtodos, pero siempre se suelen incluir.
El mtodo setUpClass es un mtodo de inicializacin de la prueba y se ejecutan antes de cada
caso de prueba, en la clase de prueba. Este mtodo no es necesario para ejecutar pruebas,
pero si es necesario para inicializar algunas variables antes de iniciar la prueba.
El mtodo tearDownClass es un mtodo finalizador de prueba, y se ejecutar despus de cada test
en la clase prueba. Un mtodo finalizador no es necesario para ejecutar las pruebas, pero si
necesitamos un finalizador para limpiar algn dato que fue requerido en la ejecucin de los casos de
prueba.
En segundo lugar, es necesario conocer las aserciones. Los mtodo assertXXX(), se utilizan para hacer
19

las pruebas. Estos mtodos, permiten comprobar si la salida del mtodo que se est probando,
concuerda con los valores esperados. Las principales son:

assertEquals() Se usa para comprobar igualdad a nivel de contenidos. La igual de tipos primitivos
se compara usando ==, la igualdad entre objetos se compara con el mtodo equals(). La prueba
pasa si los valores de los argumentos son iguales.

assertTrue():

assertFalse(): evala una expresin booleana. La prueba pasa si el valor de la expresin es false.

assertNull(): verifica que la referencia a un objeto es nula.

assertNotNull() verifica que la referencia a un objeto es no nula.

assertSame()
compara dos referencias y asegura que los objetos referenciados tienen la
misma direccin de memoria. La prueba pasa si los dos argumentos son el mismo objeto o
pertenecen al mismo objeto.

assertNotSame() Compara dos referencias a objetos y asegura que ambas apuntan a

diferentes direcciones de memoria. La prueba pasa si los dos argumentos suplidos son
objetos diferentes o pertenecen a objetos distintos.

fails()
causa que la prueba falle inmediatamente. Se puede usar cuando la prueba indica un
error o cuando se espera que el mtodo que se est probando llame a una excepcin.

evala una expresin booleana. La prueba pasa si el valor de la expresin es true.

En este punto, nos disponemos a disear los mtodos que necesitemos para los casos de prueba.
Por defecto se nos han creado los siguientes casos de pruebas, y lo primero que tenemos que hacer es
dar valores a las variables, number 1 y number 2 y el resultado esperado de la operacin, en cada uno
de los mtodos test:
double number1 = 0.0;
double number2 = 0.0;
double expResult = 0.0;

20

Vamos a crearnos varios casos de prueba para la division:

21

EJERCICIO 4: Tenemos un array de enteros y nos hemos creado el siguiente programa para obtener
el mayor valor del array:

El programa que se os entrega no tiene ningn error de compilacin pero no sabemos si funciona
correctamente. Disea casos de pruebas y prubalos con Junit.

Ejemplo: Hasta ahora hemos visto ejemplos sencillos de clases de equivalencia y casos de prueba,
vamos a ver un ejemplo ms complejo y real.
Tenemos que implementar la gestin de empleados en una tienda, en especial el Clculo del Salario
Bruto y el Clculo del Salario Neto. El documento de especificacin de requisitos indica lo siguiente al
respecto:
double
El salario base ser 1000 si el empleado es de tipo vendedor, y de 1500
calculaSalarioBruto(
String tipo,
si es de tipo encargado. A esta cantidad se le sumar una prima de 100 si
double ventasMes,
ventasMes es mayor o igual que 1000, y de 200 si fuese al menos de
int horasExtra)
1500. Por ltimo, cada hora extra se pagar a 20 euros. Si tipo de
empleado es null, o ventasMes o horasExtra toman valores negativos el
mtodo lanzar una excepcin.
double
calculaSalarioNeto(
double
salarioBruto)

Si el salario bruto es menor de 1000, no se aplicar ninguna retencin.

Para salarios a partir de 1000, y menores de 1500 se les aplicar un 16%,
y a los salarios a partir de 1500 se les aplicar un 18%. El mtodo nos
devolver salarioBruto * (1-retencion), o excepcion si el salario es menor
que cero.

A partir de dichas especificaciones podemos disear un conjunto de casos de prueba siguiendo mtodos
de las pruebas funcionales:
Mtodo
calculaSalarioBruto
calculaSalarioBruto
calculaSalarioBruto
calculaSalarioBruto
calculaSalarioBruto
calculaSalarioBruto
calculaSalarioBruto
calculaSalarioBruto
calculaSalarioBruto
calculaSalarioBruto
calculaSalarioBruto

Tipo
vendedor
vendedor
vendedor
encargado
encargado
encargado
encargado
encargado
vendedor
vendedor
null

Entrada
Ventas Mes
2000
1500
1499.99
1250
1000
999.9
500
0
-1
1500
1500

Horas
extras
8h
3h
0h
8h
0h
3h
0h
8h
8h
-1h
8h

Salida esperada
1360
1260
1100
1760
1600
1560
1500
1660
Exception
Exception
Exception

Caso de
Prueba
CP1
CP2
CP3
CP4
CP5
CP6
CP7
CP8
CP9
CP10
CP11

22

Algunos de los casos de prueba son:

EJERCICIO 5: Haz los mismo para el otro mtodo

double calculaSalarioNeto(double salarioBruto)

23

10.- Documentacin de la prueba.

Como en otras etapas y tareas del desarrollo de aplicaciones, la documentacin de las pruebas es un
requisito indispensable para su correcta realizacin. Unas pruebas bien documentadas podrn
tambin servir como base de conocimiento para futuras tareas de comprobacin.
Los documentos que se van a generar son:

Plan de Pruebas: Al principio se desarrollar una planificacin general, que quedar

reflejada en el "Plan de Pruebas". El plan de pruebas se inicia el proceso de Anlisis del
Sistema.
Especificacin del diseo de pruebas. De la ampliacin y detalle del plan de pruebas,
surge el documento "Especificacin del diseo de pruebas".
Especificacin de un caso de prueba. Los casos de prueba se concretan a partir de la
especificacin del diseo de pruebas.
Especificacin de procedimiento de prueba. Una vez especificado un caso de
prueba, ser preciso detallar el modo en que van a ser ejecutados cada uno de los casos
de prueba, siendo recogido en el documento "Especificacin del procedimiento de
prueba".
Registro de pruebas. En el "Registro de pruebas" se registrarn los sucesos que tengan
lugar durante las pruebas.
Informe de incidente de pruebas. Para cada incidente, defecto detectado, solicitud de
mejora, etc, se elaborar un "informe de incidente de pruebas".
Informe sumario de pruebas. Finalmente un "Informe sumario de pruebas" resumir
las actividades de prueba vinculadas a uno o ms especificaciones de diseo de pruebas.

24