TEMA3

Contenido
1.Planificacindelaspruebas...............................................................................................................3
2.Tiposdeprueba.................................................................................................................................4
2.1.Funcionales.................................................................................................................................5
2.2.Estructurales...............................................................................................................................6
2.3.Regresin....................................................................................................................................7
3.Procedimientosycasosdeprueba....................................................................................................9
4.Herramientasdedepuracin...........................................................................................................10
4.1.Puntosderuptura.....................................................................................................................10
4.2.Tiposdeejecucin.....................................................................................................................11
4.3.Examinadoresdevariables.......................................................................................................11
INICIODELADEPURACIN...........................................................................................................12
LADEPURACIN............................................................................................................................12
5.Validaciones.....................................................................................................................................15
6.Pruebasdecdigo............................................................................................................................16
6.1.Cubrimiento..............................................................................................................................16
6.2.Valoreslmite............................................................................................................................17
6.3.Clasesdeequivalencia..............................................................................................................18
7.Normasdecalidad...........................................................................................................................19
8.Pruebasunitarias.............................................................................................................................21
8.1.HerramientasparaJava............................................................................................................22
8.2.Herramientasparaotroslenguajes...........................................................................................23
9.Automatizacindelaprueba...........................................................................................................24
UsodeJUNITenNetBeans................................................................................................................24
INTRODUCCIN.............................................................................................................................24
INICIODEJUNIT.............................................................................................................................24
CASOSDEPRUEBA.........................................................................................................................25
10.Documentacindelaprueba.........................................................................................................28
AnexoI.NormaISO/IEC29119............................................................................................................29

[DISEOYREALIZACINDE
PRUEBAS]
JosLuisComesaaCabeza2011/2012
EntornosdeDesarrollodelcursodeDesarrollodeAplicacionesWeb

Tema3

DesarrollodeAplicacionesWeb

DAW

Diseoyrealizacindepruebas

DISEOYREALIZACINDEPRUEBAS.
Caso prctico
Situacin
BK programacin se encuentra desarrollando la primera versin de la aplicacin de gestin hotelera.
Ada, la supervisora de proyectos de BK Programacin, se rene con Juan y Mara para empezar a
planificar el diseo y realizacin de pruebas sobre la aplicacin,
Ana se va a encargar, de ir probando los distintas partes de la aplicacin que se van desarrollando.
Para ello usar casos de prueba diseados por Juan, y evaluar los resultados.
Juan evaluar los resultados de las pruebas realizadas por Ana, y en su caso, realizar las
modificaciones necesarias en el proyecto.

1.Planificacindelaspruebas.
Caso prctico
Todos en la empresa estn inmersos en el desarrollo de la aplicacin de gestin hotelera. Para
garantizar la correccin del desarrollo, Ada propone establecer la planificacin de las pruebas. Por
qu hay que probar el software? Es necesario seguir un orden concreto en la realizacin de
pruebas? Qu pruebas se realizan?

Durantetodoelprocesodedesarrollodesoftware,desdelafasedediseo,enlaimplementaciny
una vez desarrollada la aplicacin, es necesario realizar un conjunto de pruebas (Proceso que permite
verificaryrevelarlacalidaddeunproductosoftware.Seutilizanparaidentificarposiblesfallosdeimplementacin,calidadousabilidadde
unprograma),quepermitanverificarqueelsoftwarequeseestcreando,escorrectoycumpleconlas

especificacionesimpuestaporelusuario.
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
incorrectaespecificacindelosobjetivos,erroresproducidosduranteelprocesodediseoyerrores
queaparecenenlafasededesarrollo.
Mediantelarealizacindepruebassesoftware,sevanarealizarlastareasdeverificacin(Procesoporel
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
estconstruyendocorrectamente.Lavalidacineselprocesode
evaluacin del sistema o de uno de sus componentes, para
determinarsisatisfacelosrequisitosespecificados.
Parallevaracaboelprocesodepruebas,demaneraeficiente,es
necesario implementar una estrategia de pruebas. Siguiendo el
ModeloenEspiral(Modelodeciclodevidadeciclodevidadelsoftware,enelque
las actividades se conforman en una espiral. Cada bucle o iteracin representa un conjunto de actividades), las pruebas
empezaranconlapruebadeunidad,dondeseanalizaraelcdigoimplementadoyseguiramosenla
pruebadeintegracin,dondeseprestanatencinaldiseoylaconstruccindelaarquitecturadel
software. El siguiente paso sera la prueba de validacin, donde se comprueba que el sistema
construidocumpleconloestablecidoenelanlisisderequisitosdesoftware.Finalmentesealcanza
lapruebadesistemaqueverificaelfuncionamientototaldelsoftwareyotroselementosdelsistema.

Tema3

DesarrollodeAplicacionesWeb

2.Tiposdeprueba.
Caso prctico
Juan y Mara estn implementando la mayor parte de la aplicacin. Es correcto lo realizado hasta
ahora? Cmo se prueba los valores devueltos por una funcin o mtodo? Es posible seguir la
ejecucin de un programa, y ver si toma los caminos diseados?

No existe una clasificacin oficial o formal, sobre los diversos tipos de pruebas de software. En la
ingenieradelsoftware,nosencontramoscondosenfoquesfundamentales:

PruebadelaCajaNegra(BlackBoxTesting):cuandouna
aplicacin es probada usando su interfaz externa, sin
preocuparnosdelaimplementacindelamisma.Aqulo
fundamental es comprobar que los resultados de la
ejecucin de la aplicacin, son los esperados, en funcin de
lasentradasquerecibe.
PruebadelaCajaBlanca(WhiteBoxTesting):enestecaso,se
prueba la aplicacin desde dentro, usando su lgica de
aplicacin.

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
entradasadecuadasquedeberrecibirlaaplicacin,ascomolassalidasquelescorrespondan,pero
noseconoceelprocesomedianteelcuallaaplicacinobtieneesosresultados.
En contraposicin a lo anterior, una prueba de Caja Blanca, va a analizar y probar directamente el
cdigodelaaplicacin.Comosederivadeloanterior,parallevaracabounapruebadeCajaBlanca,
es necesario un conocimiento especfico del cdigo, para poder analizar los resultados de las
pruebas.

Pruebasdeunidad

Pruebasdecarga

Pruebadeestrs

Pruebade
estabilidad
Pruebasdepicos

Tiposdepruebasdesoftware
Conellasevaaprobarelcorrectofuncionamientodeunmdulodecdigo
Esteeseltipomssencillodepruebasderendimiento.Unapruebadecarga
serealizageneralmenteparaobservarelcomportamientodeunaaplicacin
bajounacantidaddepeticionesesperada.
Esta carga puede ser el nmero esperado de usuarios concurrentes
utilizandolaaplicacinyquerealizanunnmeroespecficodetransacciones
duranteeltiempoqueduralacarga.Estapruebapuedemostrarlostiempos
de respuesta de todas las transacciones importantes de la aplicacin. Si la
base de datos, el servidor de aplicaciones, etc tambin se monitorizan,
entoncesestapruebapuedemostrarelcuellodebotellaenlaaplicacin.
Esta prueba se utiliza normalmente para romper la aplicacin. Se va
doblandoelnmerodeusuariosqueseagreganalaaplicacinyseejecuta
unapruebadecargahastaqueserompe.Estetipodepruebaserealizapara
determinarlasolidezdelaaplicacinenlosmomentosdecargaextremay
ayuda a los administradores para determinar si la aplicacin rendir lo
suficienteencasodequelacargarealsuperealacargaesperada.
Esta prueba normalmente se hace para determinar si la aplicacin puede
aguantar una carga esperada continuada. Generalmente esta prueba se
realizaparadeterminarsihayalgunafugadememoriaenlaaplicacin
La prueba de picos, como el nombre sugiere, trata de observar el
comportamientodelsistemavariandoelnmerodeusuarios,tantocuando
bajan,comocuandotienecambiosdrsticosensucarga.

DAW

Diseoyrealizacindepruebas

Estapruebaserecomiendaquesearealizadaconunsoftwareautomatizado
que permita realizar cambios en el nmero de usuarios mientras que los
administradoresllevanunregistrodelosvaloresasermonitorizados
Elenfoqueestructuralodecajablancasecentraenlaestructurainternadel
Pruebaestructural
programa(analizaloscaminosdeejecucin).
Elenfoquefuncionalodecajanegrasecentraenlasfunciones,entradasy
Pruebafuncional
salidasquerecibeyproduceunmduloofuncinconcreta.
El enfoque aleatorio consiste en utilizar modelos (en muchas ocasiones
Pruebasaleatorias estadsticos)querepresentenlasposiblesentradasalprogramaparacreara
partirdeellosloscasosdeprueba.
Soncualquiertipodepruebasdesoftwarequeintentandescubrirlascausas
de nuevos errores, carencias de funcionalidad, o divergencias funcionales
con respecto al comportamiento esperado del software, inducidos por
Pruebasderegresin cambios recientemente realizados en partes de la aplicacin que
anteriormentealcitadocambionoeranpropensasaestetipodeerror.Esto
implica que el error tratado se produce como consecuencia inesperada del
citadocambioenelprograma.

Reflexiona
Resulta habitual, que en una empresa de desarrollo de software se gaste el 40 por ciento del
esfuerzodedesarrolloenlapruebaPorquestanimportantelaprueba?Qutiposdeerroresse
intentansolucionarconlaspruebas?
Laspruebassonmuyimportantes,yaquepermitendescubrirerroresenunprograma,fallosenlaimplementacin,calidado
usabilidaddelsoftware,ayudandoagarantizarlacalidad.
Con las pruebas se intenta verificar que cada componente que se ha diseado, ya sea un mtodo, funcin, mdulo, etc.
realizalafuncinparalaquesehadiseado.Tambinseintentacomprobar,queexistencondicionesenlasquetodoslos
caminosdeunaaplicacinlleganaejecutarse.

2.1.Funcionales.
Estamosantepruebasdelacajanegra.Setratadeprobar,silassalidasquedevuelvelaaplicacin,o
partedeella,sonlasesperadas,enfuncindelosparmetrosdeentradaquelepasemos.Nonos
interesalaimplementacindelsoftware,solosirealizalasfuncionesqueseesperandel.
Las pruebas funcionales siguen el enfoque de las pruebas de Caja Negra. Comprenderan aquellas
actividades cuyo objetivo sea verificar una accin especfica o funcional dentro del cdigo de una
aplicacin. Las pruebas funcionales intentaran responder a las preguntas puede el usuario hacer
esto?ofuncionaestautilidaddelaaplicacin?
Suprincipalcometido,vaaconsistir,encomprobarelcorrectofuncionamientodeloscomponentes
delaaplicacininformtica.Pararealizarestetipodepruebas,sedebenanalizarlasentradasylas
salidasdecadacomponente,verificandoqueelresultadoeselesperado.Solosevanaconsiderarlas
entradasysalidasdelsistema,sinpreocuparnosporlaestructurainternadelmismo.
Si por ejemplo, estamos implementando una aplicacin que realiza un determinado clculo
cientfico, en el enfoque de las pruebas funcionales, solo nos interesa verificar que ante una
determinada entrada a ese programa el resultado de la ejecucin del mismo devuelve como
resultado los datos esperados. Este tipo de prueba, no considerara, en ningn caso, el cdigo
desarrollado,nielalgoritmo(Conjuntoordenadodepasosaseguirparalaresolucindeunproblema),nilaeficiencia,ni
sihaypartesdelcdigoinnecesarias,etc.
Dentrodelaspruebasfuncionales,podemosindicartrestiposdepruebas:

Tema3

DesarrollodeAplicacionesWeb

Particiones equivalentes: La idea de este tipo de pruebas funcionales, es considerar el

menor nmero posible de casos de pruebas, para ello, cada caso de prueba tiene que
abarcar el mayor nmero posible de entradas diferentes. Lo que se pretende, es crear un
conjuntodeclasesdeequivalencia,dondelapruebadeunvalorrepresentativodelamisma,
en cuanto a la verificacin de errores, sera extrapolable al que se conseguira probando
cualquiervalordelaclase.
Anlisisdevaloreslmite:Enestecaso,alahoradeimplementaruncasodeprueba,sevan
a elegir como valores de entrada, aquellos que se encuentra en el lmite de las clases de
equivalencia.
Pruebas aleatorias:Consisteengenerarentradasaleatoriasparalaaplicacinquehayque
probar.Sesuelenutilizargeneradoresdeprueba,quesoncapacesdecrearunvolumende
casosdepruebaalazar,conlosqueseralimentadalaaplicacin.Estatipodepruebas,se
suelen utilizar en aplicaciones que no sean interactivas, ya que es muy difcil generar las
secuenciasdeentradaadecuadasdeprueba,paraentornosinteractivos.

Existen otros tipos de pruebas funcionales, aunque todas comparten un mismo objetivo, y es
comprobar, solo actuando en la interfaz de la aplicacin, que los resultados que produce son los
correctosenfuncindelasentradasqueseleintroducenparaprobarlos.

2.2.Estructurales.
Ya hemos visto que las pruebas funcionales se centran en
resultados,enloquelaaplicacinhace,peronoencmolohace.
Para ver cmo el programa se va ejecutando, y as comprobar su
correccin,seutilizanlaspruebasestructurales,quesefijanenlos
caminosquesepuedenrecorrer:
Las pruebas estructurales son el conjunto de pruebas de la Caja
Blanca. Con este tipo de pruebas, se pretende verificar la
estructura interna de cada componente de la aplicacin, independientemente de la funcionalidad
establecida para el mismo. Este tipo de pruebas, no pretenden comprobar la correccin de los
resultadosproducidosporlosdistintoscomponentes,sufuncinescomprobarquesevanaejecutar
todaslainstruccionesdelprograma,quenohaycdigonousado,comprobarqueloscaminoslgicos
delprogramasevanarecorrer,etc.
Estetipodepruebas,sebasanenunoscriteriosdecoberturalgica,cuyocumplimientodeterminala
mayoromenorseguridadenladeteccindeerrores.Loscriteriosdecoberturaquesesiguenson:

Cobertura de sentencias: se han de generar casos de pruebas suficientes para que cada
instruccindelprogramaseaejecutada,almenos,unavez.
Cobertura de decisiones: se trata de crear los suficientes casos de prueba para que cada
opcinresultadodeunapruebalgicadelprograma,seevalealmenosunavezaciertoy
otraafalso.
Cobertura de condiciones: se trata de crear los suficientes casos de prueba para que cada
elementodeunacondicin,seevalealmenosunavezafalsoyotraaverdadero.
Cobertura de condiciones y decisiones: consiste en cumplir simultneamente las dos
anteriores.
Cobertura de caminos: es el criterio ms importante. Establece que se debe ejecutar al
menos una vez cada secuencia de sentencias encadenadas, desde la sentencia inicial del
programa,hastasusentenciafinal.Laejecucindeesteconjuntodesentencias,seconoce
comocamino.Comoelnmerodecaminosquepuedetenerunaaplicacin,puedesermuy

DAW

Diseoyrealizacindepruebas

grande, para realizar esta prueba, se reduce el nmero a lo que se conoce como camino
prueba.
Cobertura del camino de prueba: Se pueden realizar dos variantes, una indica que cada
buclesedebeejecutarslounavez,yaquehacerlomsvecesnoaumentalaefectividadde
lapruebayotraquerecomiendaquesepruebecadabucletresveces:laprimerasinentrar
ensuinterior,otraejecutndolounavezyotramsejecutndolodosveces.

Autoevaluacin
En las pruebas de caja negra:
Es necesario conocer el cdigo fuente del programa, para realizar las pruebas.
Se comprueba que todos los caminos del programa, se pueden recorrer, al menos una vez.
Se comprueba que los resultados de una aplicacin, son los esperados para las entradas
que se le han proporcionado.
Es incompatible con la prueba de caja blanca.

2.3.Regresin.
Durante el proceso de prueba,
tendremos xito si detectamos un
posible fallo o error. La consecuencia
directa de ese descubrimiento, supone
lamodificacindelcomponentedonde
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
conanterioridad.
Elobjetivodelaspruebasderegresin,escomprobarqueloscambiossobreuncomponentedeuna
aplicacin,nointroduceuncomportamientonodeseadooerroresadicionalesenotroscomponentes
nomodificados.
9 Laspruebasderegresinsedebenllevaracabocadavezquesehaceuncambioenelsistema,
tanto para corregir un error, como para realizar una mejora. No es suficiente probar slo los
componentesmodificadosoaadidos,olasfuncionesqueenellosserealizan,sinoquetambin
esnecesariocontrolarquelasmodificacionesnoproduzcanefectosnegativossobreelmismou
otroscomponentes.
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
funcionacorrectamenteunavezrealizadosloscambios.
Enuncontextomsamplio,laspruebasdesoftwareconxito,sonaquellasquedancomoresultado
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,tantodelprograma,deladocumentacinydelosdatosquelosoportan.Lapruebade
regresineslaquenosayudaaasegurarqueestoscambiosnointroducenuncomportamientono

Tema3

DesarrollodeAplicacionesWeb

deseado o errores adicionales. La prueba de regresin se puede hacer manualmente, volviendo a

realizarunsubconjuntodetodosloscasosdepruebaoutilizandoherramientasautomticas.
Elconjuntodepruebasderegresincontienetresclasesdiferentesdeclasesdeprueba:
9 Unamuestrarepresentativadepruebasqueejercitetodaslasfuncionesdelsoftware;
9 Pruebas adicionales que se centran en las funciones del software que se van a ver
probablementeafectadasporelcambio;
9 Pruebasquesecentranenloscomponentesdelsoftwarequehancambiado.
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
principalesdelprograma.Noesprcticonieficientevolveraejecutarcadapruebadecadafuncin
delprogramadespusdeuncambio.

Autoevaluacin
La prueba de regresin:
Se realiza una vez finalizado cada mdulo (Cada parte, con una funcionalidad concreta, en que se divide una
del sistema a desarrollar.

aplicacin)

Solo utiliza el enfoque de la caja negra.

Se realiza cuando se produce una modificacin, debido a la deteccin de algn error, en la
fase de prueba.
Es incompatible con la prueba de caja blanca.

DAW

Diseoyrealizacindepruebas

3.Procedimientosycasosdeprueba.
Caso prctico

En BK, ya tienen el proyecto bastante avanzado. Ahora llega una parte clave: definir las partes del
sistemaquesevanaprobaryestablecerloscasosdepruebapararealizarla.Anavaaparticipar,pero
cuandosehabladeprocedimientos(Igual que las funciones, pero al ejecutarse no devuelven ningn valor)ycasosde
prueba,sesienteperdida.Aellalevaatocarejecutarloscasosdeprueba.
SegnelIEEE,uncasodepruebaesunconjuntodeentradas,condicionesdeejecucinyresultados
esperados, desarrollados para un objetivo particular, como, por ejemplo, ejercitar un camino
concretodeunprogramaoverificarelcumplimientodeundeterminadorequisito,incluyendotoda
ladocumentacinasociada.
Dada la complejidad de las aplicaciones informticas, que se desarrollan en la actualidad, es
prcticamenteimposible,probartodaslascombinacionesquesepuedendardentrodeunprograma
oentreunprogramaylasaplicacionesquepuedeninteractuarconl.Porestemotivo,eneldiseo
deloscasosdeprueba,siempreesnecesarioasegurarqueconellosseobtieneunnivelaceptablede
probabilidaddequesedetectarnloserroresexistentes.
Las pruebas deben buscar un compromiso entre la cantidad de recursos que se consumirn en el
procesodeprueba,ylaprobabilidadobtenidadequesedetectenloserroresexistentes.
Existenvariosprocedimientosparaeldiseodeloscasosdeprueba:
9 Enfoquefuncionalodecajanegra.Enestetipodeprueba,noscentramosenqueelprograma,
o parte del programa que estamos probando, recibe un entrada de forma adecuada y se
produceunasalidacorrecta,ascomoquelaintegridaddelainformacinexternasemantiene.
Lapruebanoverificaelproceso,sololosresultados.
9 Enfoque estructural o caja blanca. En este tipo de pruebas, debemos centrar en la
implementacininternadelprograma.Setratadecomprobarquelaoperacininternaseajusta
a las especificaciones. En esta prueba, se deberan de probar todos los caminos que puede
seguirlaejecucindelprograma.
9 Enfoque aleatorio. A partir de modelos obtenidos estadsticamente, se elaboran casos de
pruebaquepruebenlasentradasdelprograma.

Tema3

DesarrollodeAplicacionesWeb

4.Herramientasdedepuracin.
Caso prctico
Juan y Mara tiene muchas lneas de cdigo implementadas. Como programadores de la aplicacin,
juegan un papel decisivo en la fase de pruebas. Al realizar este proyecto utilizando un entorno de
desarrollo integrado (NetBeans), cuenta con una herramienta fundamental, el depurador.

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,inspeccindevariables,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
verificarelcdigogenerado,ayudndonosarealizarpruebastantoestructuralescomofuncionales.
Duranteelprocesodedesarrollodesoftware,sepuedenproducirdostiposdeerrores:erroresde
compilacin oerroreslgicos.CuandosedesarrollaunaaplicacinenunIDE,yaseaVisualStudio,
EclipseoNetbeans,sialescribirunasentencia,olvidamosun";",hacemosreferenciaaunavariable
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
programadoranocorrijaeseerror.
Elotrotipodeerroressonlgicos,comnmentellamadosbugs,estosnoevitanqueelprogramase
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,quenoseanlosesperadosopuedenprovocarqueelprogramatermineantesdetiempoo
noterminenunca.
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
localizaryeliminarloserroreslgicos.Unprogramadebecompilarseconxitoparapoderutilizarlo
en el depurador. El depurador nos permita analizar todo el programa, mientras ste se ejecuta.
Permitesuspenderlaejecucindeunprograma,examinaryestablecerlosvaloresdelasvariables,
comprobar los valores devueltos por un determinado mtodo, el resultado de una comparacin
lgicaorelacional,etc.

Autoevaluacin
Qu concepto est relacionado con la prueba de caja negra?
Es la principal herramienta de validacin.
Se pueden comprobar los valores que van tomando las variables
Se comprueba que todos los caminos del programa, se pueden recorrer, al menos una vez.
Es incompatible con la prueba de caja blanca.
Con las pruebas de caja negra no se depura el programa, se comprueba que devuelve los valores esperados en funcin de las entradas
introducidas.

4.1.Puntosderuptura.
Dentro del men de depuracin, nos encontramos con la
opcininsertarpuntoderuptura(breakpoint).Seselecciona
lalneadecdigodondequeremosqueelprogramasepare,

10

DAW

Diseoyrealizacindepruebas

para a partir de ella, inspeccionar variables, o realizar una ejecucin paso a paso, para verificar la
correccindelcdigo
Durantelapruebadeunprograma,puedeserinteresantelaverificacindedeterminadaspartesdel
cdigo.Nonosinteresaprobartodoelprograma,yaquehemosdelimitadoelpuntoconcretodonde
inspeccionar.Paraello,utilizamoslospuntosderuptura.
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,einiciadaladepuracin,elprogramaaevaluarseejecutarahastalalneamarcadaconel
punto de ruptura. En ese momento, se pueden realizar diferentes labores, por un lado, se pueden
examinarlasvariables,ycomprobarquelosvaloresquetienenasignadossoncorrectos,osepueden
iniciarunadepuracinpasoapaso,eircomprobandoelcaminoquetomaelprogramaapartirdel
punto de ruptura. Una vez realiza la comprobacin, podemos abortar el programa, o continuar la
ejecucinnormaldelmismo.
Dentrodeunaaplicacin,sepuedeninsertarvariospuntosderuptura,ysepuedeneliminarconla
mismafacilidadconlaqueseinsertan.

4.2.Tiposdeejecucin.
Parapoderdepurarun programa,podemosejecutarelprogramadediferentesformas,demanera
queenfuncindelproblemaquequeramossolucionar,nosresultemssencillounmtodouotro.
Nosencontramosconlosiguientestipodeejecucin:pasoapasoporinstruccin,pasoapasopor
procedimiento, ejecucin hasta una instruccin, ejecucin de un programa hasta el final del
programa,
9 Algunasvecesesnecesarioejecutarunprogramalneaporlnea,parabuscarycorregirerrores
lgicos.Elavancepasoapasoalolargodeunapartedelprogramapuedeayudarnosaverificar
queelcdigodeunmtodoseejecuteenformacorrecta.
9 El paso a paso por procedimientos, nos permite introducir los parmetro que queremos a un
mtodoofuncindenuestroprograma,peroenvezdeejecutarinstruccinporinstruccinese
mtodo,nosdevuelvesuresultado.Estil,cuandohemoscomprobadoqueunprocedimiento
funciona correctamente, y no nos interese volver a depurarlo, slo nos interesa el valor que
devuelve.
9 En la ejecucin hasta una instruccin, el depurador ejecuta el programa, y se detiene en la
instruccindondeseencuentraelcursor,apartirdeesepunto,podemoshacerunadepuracin
pasoapasooporprocedimiento.
9 Enlaejecucindeunprogramahastaelfinaldelprograma,ejecutamoslasinstruccionesdeun
programahastaelfinal,sindetenernosenlasinstruccionesintermedias.
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 elIDENetBeans,dentrodel men dedepuracin,podemos seleccionar losmodosdeejecucin

especificados, y algunos ms. El objetivo es poder examinar todas las partes que se consideren
necesarias,demanerarpida,sencillaylosmsclaraposible.

4.3.Examinadoresdevariables.

11

Tema3

DesarrollodeAplicacionesWeb

Duranteelprocesodeimplementacinypruebadesoftware,unadelasmanerasmscomunesde
comprobar que la aplicacin funciona de manera adecuada, es comprobar que las variables vayan
tomandolosvaloresadecuadosencadamomento.
Los examinadores de variables, forman uno de los elementos ms importantes del proceso de
depuracindeunprograma.Iniciadoelprocesodedepuracin,normalmenteconlaejecucinpasoa
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
deteccindeerrores.
EnelcasodelentornodedesarrolloNetBeans,nos
encontramos con un panel llamado Ventana de
Inspeccin.Enlaventanadeinspeccin,sepueden
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
variablesenlaventanadeinspeccin.
Como podemos apreciar, en una ejecucin paso a
paso, el programa llega a una funcin de nombre
potencia.Estafuncintienedefinidatresvariables.
Alolargodelaejecucindelbucle,vemoscomola
variable result, van cambiando de valor. Si con
valoresdeentradaparalosqueconocemoselresultado,lafuncinnodevuelveelvaloresperado,
"Examinandolasvariables"podremosencontrarlainstruccinincorrecta.
Los depuradores son programas que permiten analizar de manera exhaustiva y en paso a paso, lo
quepasadentrodelcdigodeunprograma.Graciasalosdepuradoresesfcilprobarlasaplicaciones
paraencontrarlosposibleserrores,analizandosuscausasyposiblessoluciones.
EnelcasodelIDENetBeans,queeselqueutilizamosenelejemplo,estasutilidadesestnintegradas
enelentornodedesarrollo
INICIODELADEPURACIN
ParaconocerlasopcionesmshabitualesdedepuracinenNetBeans,vamosadepurarunpequeo
programa. Este programa dispone de una clase Vector, que implementa algunos mtodos, como
insertaryordenar.
Parainiciarladepuracindelprograma,enelmenprincipal,seleccionamosDepurar.
Comohemosindicado,elobjetivodeladepuracinesladeteccindeerroresenlaaplicacin.Para
encontrarlosposibleserrores,ocomprobarelbuendiseodeunaaplicacin,debemosnavegarpor
elcdigodiseado.Podemosanalizarelcdigodevariasformas:
Pasoapaso:encuyocasovamosairejecutandoinstruccinporinstruccin,todoelcdigo.
Ejecutar hasta el cursor: El cursor tendr el foco en una determinada instruccin. El depurador
ejecutarelprogramaysepararcuandollegueaesainstruccin.Estoestil,siyahemosanalizado
partedelcdigoynonosinteresavolveradepurarlo,ganandotiempo.
LADEPURACIN

12

DAW

Diseoyrealizacindepruebas

Unaveziniciadaladepuracin(pasoapasooejecutarhastaelcursor),podemosdecidirdetenerla
depuracin,continuarla,oejecutarelprogramahastaelfinal.
PodemoselegirEntrarenelsiguientemtodo,siqueremosanalizarlo,oseguirconlaejecucinpaso
apasoconlateclaF7.
Sielmtodoencuestin,nonecesitadepuracinpodemosContinuarEjecucinopulsarF8,conesto
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
queremosseguirlaejecucinnormal,oseguirhastaelsiguientepuntoderupturaContinuar.
Otrasopcionesdeldepuradorson:
Consulta de la pila (stack) para comprobar las
funcionesqueestnsiendollamadas.
Insercindepuntosdeinterrupcin,paraindicarla
lnea de cdigo que queremos analizar con el
depurador
Evaluarexpresin,quenossirveparacomprobarlos
valoresquetomadichaexpresin.
Sihacemosunadepuracinpasoapaso,vamosair
instruccin por instruccin. Esto nos ayuda a
comprobarqueloscaminosquehemosdiseadoenelcdigosepuedenrecorrer.
Comovemosenelejemplo,hayunbuclequeserepite75veces,si
depuramos paso a paso, la ejecucin del mtodo v.insertar(),
deberamos realizarla 75 veces. En general, se entra una vez en el
mtodo,yserealizaladepuracin.
Para pasar a otra parte de cdigo que s queramos depurar, podemos
colocarelcursorenlainstruccinencuestin,ypulsamosEjecutarhasta
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
quenosinterese,opulsamosenlaparteizquierdadelaventana.
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
depurarunapartedecdigoapartirdeesepuntoderuptura.
Lalneaverde,meindicalainstruccinporlaquevaanalizandoeldepurador.Enlaimagen,tambin
podemosobservarlaventanadevariables.Estaventanaseutilizaendepuracinparainspeccionarel
valorquevantomandoalolargodelaejecucin.
Ennuestroejemplodepuramosunmtododeordenacindeunarray,vemoslosvaloresquetoman
lasvariablesi,jytemp,ascomoeltipoalqueestndefinidas.
Enlaimagen,vemoscomopodemosevaluarlasexpresiones
quequeremos.Enestecasoestamosevaluandolosvalores
quetomanlasvariablesi,jytemp,ytambincomprobamos

13

Tema3

DesarrollodeAplicacionesWeb

los valores almacenados en el vector. Si durante la depuracin comprobamos que la aplicacin no

haceaquelloquedebiera,podemoscambiarla.Sihemosdepurado,yconsideramosquelaaplicacin
funciona,podemospasaraprobarla.Paraello,diseamoscasosdepruebaenJunitylosaplicamos

Autoevaluacin
Qu afirmacin sobre depuracin es incorrecta?
En la depuracin, podemos inspeccionar las instrucciones que va ejecutando el programa.
No es posible conocer los valores que toman las variables definidas dentro de un mtodo.
Solo podemos insertar un punto de ruptura en la depuracin
En depuracin podemos insertar tantos puntos de ruptura como queremos, y que la depuracin vaya saltando de uno a otro.

14

DAW

Diseoyrealizacindepruebas

5.Validaciones.
Caso prctico
Durante todo el proceso de desarrollo, existe una permanente comunicacin entre Ada y su equipo,
con representantes de la empresa a la que va destinado el proyecto. Ana y Juan van a asistir a la
siguiente reunin, donde se va a mostrar a los representantes de la empresa, las fases de proyectos
ya implementadas. Ser la primera reunin de validacin del proyecto.

Enelprocesodevalidacin,intervienedemaneradecisivaelcliente.Hayquetenerencuenta,que
estamosdesarrollandounaaplicacinparaterceros,yquesonestoslosquedecidensilaaplicacin
seajustaalosrequerimientosestablecidosenelanlisis.
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).

Lavalidacindelsoftwareseconsiguemedianteunaseriedepruebasdecajanegraquedemuestran
laconformidadconlosrequisitos.Unplandepruebatrazalaclasedepruebasquesehandellevara
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
diseadosparaasegurarquesesatisfacentodoslosrequisitosfuncionales,quesealcanzantodoslos
requisitos de rendimiento, que las documentaciones son correctas e inteligible y que se alcanzan
otrosrequisitos,comoportabilidad(Capacidad de un programa para ser ejecutado en cualquier arquitectura fsica de un
equipo),compatibilidad,recuperacindeerrores,facilidaddemantenimientoetc.
Cuandoseprocedeconcadacasodepruebadevalidacin,puededarseunadelasdoscondiciones
siguientes:
9 Lascaractersticasdefuncionamientoorendimientoestndeacuerdoconlasespecificacionesy
sonaceptableso
9 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
antesdelaterminacinplanificada.

15

Tema3

DesarrollodeAplicacionesWeb

6.Pruebasdecdigo.
Caso prctico
Juan y Mara prueban cada parte de cdigo que estn implementando. Algunos mtodos requieren
una comprobacin de su estructura interna, en otros, valdra con probar los resultados que devuelven.
Antonio se pregunta en qu consiste cada prueba, y como se lleva a cabo en la prctica.

Lapruebaconsisteenlaejecucindeunprogramaconelobjetivodeencontrarerrores.Elprograma
o parte de l, se va a ejecutar bajo unas condiciones previamente especificadas, para una vez
observadoslosresultados,estosseanregistradosyevaluados.
Parallevaracabolaspruebas,esnecesariodefinirunaseriedecasosdeprueba,quevanaserun
conjunto de entradas, de condiciones de ejecucin y resultados esperados, desarrollados para un
objetivoparticular.
Paraeldiseodecasosdeprueba,sesuelenutilizartresenfoquesprincipales:
9 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
aplicamosconelcubrimiento.
9 Enfoquefuncionalodecajanegra.Esteenfoquesecentraenlasfunciones,entradasysalidas.
Seaplicanlosvaloreslmiteylasclasesdeequivalencia.
9 Enfoque aleatorio, que consiste en utilizar modelos que represente las posibles entradas al
programa,paracrearapartirdeellosloscasosdeprueba.Enestapruebaseintentasimularla
entradahabitualquevaarecibirelprograma,paraellosecreandatosentradaenlasecuenciay
con la frecuencia en que podran aparecer. Para ello se utilizan generadores automticos de
casosdeprueba.

Parasaberms
Puedes visitar la siguiente pgina web, donde se detallan los tipos de pruebas que suelen
haceralsoftwareylafuncindecadauna.
Pruebasdesoftwarehttp://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema09.pdf
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.

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

Estetipodeprueba,esdecajablanca,yaquenosvamosacentrarenelcdigodenuestraaplicacin.
Conestetipodeprueba,loquesepretende,escomprobarque
todaslasfunciones,sentencias,decisiones,ycondiciones,sevan
aejecutar.
Porejemplo

16

DAW

Diseoyrealizacindepruebas

Considerandoqueestafuncinformapartedeunprogramamayor,seconsideralosiguiente:
9 Sidurantelaejecucindelprograma,lafuncinesllamada,almenosunavez,elcubrimientode
lafuncinessatisfecho.
9 Elcubrimientodesentenciasparaestafuncin,sersatisfechosiesinvocada,porejemplocomo
prueba(1,1),yaqueenestacaso,cadalneadelafuncinseejecuta,incluidaz=x;
9 Siinvocamosalafuncinconprueba(1,1)yprueba(0,1),sesatisfarelcubrimientodedecisin.
En el primer caso, la if condicin va a ser verdadera, seva a ejecutar z=x, pero en el segundo
caso,no.
9 El cubrimiento de condicin puede satisfacerse si probamos con prueba(1,1), prueba(1,0) y
prueba(0,0).Enlosdosprimeroscasos(x<0)seevalaaverdadmientrasqueeneltercero,se
evalaafalso.Almismotiempo,elprimercasohace(y>0)verdad,mientraseltercerolohace
falso.
Existenotraseriedecriterios,paracomprobarelcubrimiento.
9 Secuencialinealdecdigoysalto.
9 JJPathCubrimiento.
9 Cubrimientodeentradaysalida.
Existenherramientascomercialesytambindesoftwarelibre,quepermitenrealizarlapruebasde
cubrimiento,entreellas,paraJava,nosencontramosconClover.

6.2.Valoreslmite.
En el cdigo Java adjunto, aparecen dos funciones que reciben el
parmetrox.Enlafuncin1,elparmetroesdetiporealyenlafuncin2,
elparmetroesdetipoentero.
Comoseaprecia,elcdigodelasdosfuncioneseselmismo,sinembargo,
loscasosdepruebaconvaloreslmitevaaserdiferente.
Laexperienciahademostradoqueloscasosdepruebaqueobtienenuna
mayorprobabilidaddexito,sonaquellosquetrabajanconvaloreslmite.
Esta tcnica, se suele utilizar como complementaria de las particiones equivalentes, pero se
diferencia,enquesesuelenseleccionar,nounconjuntodevalores,sinounospocos,enellmitedel
rangodevaloresaceptadoporelcomponenteaprobar.
Cuandohayqueseleccionarunvalorpararealizarunaprueba,seescogeaquellosqueestnsituados
justoenellmitedelosvaloresadmitidos.
Por ejemplo, supongamos que queremos probar el resultado de la ejecucin de una funcin, que
recibeunparmetrox:
9 Sielparmetroxdeentradatienequesermayorestrictoque5,yelvaloresreal,losvalores
lmitepuedenser4,99y5,01.
9 Si el parmetro de entrada x est comprendido entre 4 y +4, suponiendo que son valores
enteros,losvaloreslmitesern5,4,3,3,4y5.

Autoevaluacin
Si en un bucle while la condicin es while (x>5 && x < 10), siendo x un valor single, sera
valores lmite
4 y 11

17

Tema3

DesarrollodeAplicacionesWeb

4,99 y 11
4,99 y 9,99.

6.3.Clasesdeequivalencia.
Lasclasesdeequivalencia,esuntipodepruebafuncional,endondecadacasodeprueba,pretende
cubrirelmayornmerodeentradasposible.
El dominio de valores de entrada, se divide en nmero finito de clases de equivalencia. Como la
entradaestdivididaenunconjuntodeclasesdeequivalencia,lapruebadeunvalorrepresentativo
de cada clase, permite suponer que el resultado que se obtiene con l, ser el mismo que con
cualquierotrovalordelaclase.
Cadaclasedeequivalenciadebecumplir:
9 Si un parmetro de entrada debe estar comprendido entre un determinado rango, hay tres
clasesdeequivalencia:pordebajo,enyporencima.
9 Siunaentradarequiereunvalorentrelosdeunconjunto,aparecendosclasedeequivalencia:
enelconjuntoofueradel.
9 Siunaentradaesbooleana,haydosclases:sono.
9 Losmismoscriteriosseaplicanalassalidasesperadas:hayqueintentargenerarresultadosen
todasycadaunadelasclases.
Enesteejemplo,lasclasesdeequivalenciaseran:
1. Pordebajo:x<=0
2. En:x>0yx<100
3. Porencima:x>=100
ylosrespectivoscasosdeprueba,podranser:
1. Pordebajo:x=0
2. En:x=50
3. Porencima:x=100

18

DAW

Diseoyrealizacindepruebas

7.Normasdecalidad.
Caso prctico
Las aplicaciones que desarrolla BK Programacin, se caracterizan por cumplir todos los estndares
de calidad de la industria. Como no poda ser de otro modo, a la hora de realizar las pruebas, tambin
van a seguir los estndares ms actuales del mercado. Ada se va a encargar de supervisar el
cumplimiento de los estndares ms actuales.

Losestndaresquesehanvenidoutilizandoenlafasedepruebadesoftwareson:
9 EstndaresBSI
BS79251,Pruebasdesoftware.Parte1.Vocabulario.
BS79252,Pruebasdesoftware.Parte2.Pruebasdeloscomponentessoftware.
9 EstndaresIEEEdepruebasdesoftware.:
IEEEestndar829,Documentacindelapruebadesoftware.
IEEEestndar1008,Pruebasdeunidad
OtrosestndaresISO/IEC12207,15289
9 Otrosestndaressectoriales
Sinembargo,estosestndaresnocubrendeterminadasfacetasdelafasedepruebas,comosonla
organizacin el proceso y gestin de las pruebas, presentan pocas pruebas funcionales y no
funcionalesetc.Anteestaproblemtica,laindustriahadesarrolladolanormaISO/IEC29119.
La norma ISO/IEC 29119 de prueba de software, pretende unificar en una nica norma, todos los
estndares,deformaqueproporcionevocabulario,procesos,documentacinytcnicasparacubrir
todo el ciclo de vida del software. Desde estrategias de prueba para la organizacin y polticas de
prueba, prueba de proyecto al anlisis de casos de prueba, diseo, ejecucin e informe. Con este
estndar,sepodrrealizarcualquierpruebaparacualquierproyectodedesarrolloomantenimiento
desoftware.

Debesconocer
NormaISO/IEC29119.
LanormaISO/IEC29119lacomponelassiguientespartes:
9 Parte1.Conceptosyvocabulario:
Introduccinalaprueba.
Pruebasbasadasenriesgo.
Fasesdeprueba(unidad,integracin,sistema,validacin)ytiposdeprueba(esttica,
dinmica,nofuncional,).
Pruebaendiferentesciclosdevidadelsoftware.
Rolesyresponsabilidadesenlaprueba.
Mtricasymedidas.
9 Parte2.Procesosdeprueba:
Polticadelaorganizacin.
Gestindelproyectodeprueba.
Procesosdepruebaesttica.
Procesosdepruebadinmica.
9 Parte3.Documentacin
Contenido.
Plantilla.
9 Parte4.Tcnicasdeprueba:
Descripcinyejemplos.
Estticas:revisiones,inspecciones,etc.

19

Tema3

DesarrollodeAplicacionesWeb

Dinmicas: Caja negra, caja blanca, Tcnicas de prueba no funcional (Seguridad,

rendimiento,usabilidad,etc).

Parasaberms
Enelsiguienteenlacepodrsvisitarlapginainternacional,dondesedetallanlasnormasa
seguir,porlaspruebasdesoftware:
Normasparalapruebadesoftwarehttp://softwaretestingstandard.org/
Autoevaluacin
Qu norma de calidad intenta unificar los estndares para pruebas de software?
BS 7925-1.
IEEE 1008.
ISO/IEC 29119.

20

DAW

Diseoyrealizacindepruebas

8.Pruebasunitarias.
Caso prctico
Antonio est un poco confuso. La aplicacin que estn diseando Juan y Mara es ya de cierta
envergadura y se pregunta por la labor ingente que queda, solo para probar todos los componentes
de la aplicacin. Mara le tranquiliza y le comenta que los Entornos de Desarrollo actuales, incorporan
herramientas que realizan las pruebas de cada mtodo, de forma automtica.

Las pruebas unitarias, o prueba de la unidad, tienen por

objetivoprobarelcorrectofuncionamientodeun mdulo
de cdigo. El fin que se persigue, es que cada mdulo
funcionacorrectamenteporseparado.
Posteriormente, con la prueba de integracin, se podr
asegurarelcorrectofuncionamientodelsistema.
Una unidad es la parte de la aplicacin ms pequea que
sepuedeprobar.Enprogramacinprocedural,unaunidad
puede ser una funcin o procedimiento, En programacin orientada a objetos, una unidad es
normalmenteunmtodo.
Con las pruebas unitarias se debe probar todas las funciones o mtodos no triviales de forma que
cadacasodepruebaseaindependientedelresto.
Eneldiseodeloscasosdepruebasunitarias,habrquetenerencuentalossiguientesrequisitos:
9 Automatizable:nodeberarequerirseunaintervencinmanual.
9 Completas:debencubrirlamayorcantidaddecdigo.
9 RepetiblesoReutilizables:nosedebencrearpruebasqueslopuedanserejecutadasunasola
vez.
9 Independientes:laejecucindeunapruebanodebeafectaralaejecucindeotra.
9 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
individualessoncorrectas.Laspruebasindividualesnosproporcionancincoventajasbsicas:
1. Fomentanelcambio:Laspruebasunitariasfacilitanqueelprogramadorcambieelcdigopara
mejorarsuestructura,puestoquepermitenhacerpruebassobreloscambiosyasasegurarsede
quelosnuevoscambiosnohanintroducidoerrores.
2. Simplificalaintegracin:Puestoquepermitenllegaralafasedeintegracinconungradoalto
deseguridaddequeelcdigoestfuncionandocorrectamente.
3. Documenta el cdigo: Las propias pruebas son documentacin del cdigo puesto que ah se
puedevercmoutilizarlo.
4. Separacindelainterfazylaimplementacin:Dadoquelanicainteraccinentreloscasosde
prueba y las unidades bajo prueba son las interfaces de estas ltimas, se puede cambiar
cualquieradelosdossinafectaralotro.
5. Los errores estn ms acotados y son ms fciles de localizar: dado que tenemos pruebas
unitariasquepuedendesenmascararlos.

21

Tema3

DesarrollodeAplicacionesWeb

8.1.HerramientasparaJava.
Entrelasherramientasquenospodemosencontrarenelmercado,parapoderrealizarlaspruebas,
lasmsdestacadasseran:
9 Jtiger:
FrameworkdepruebasunitariasparaJava(1.5).
Esdecdigoabierto.
CapacidadparaexportarinformesenHTML,XMLotextoplano.
EsposibleejecutarcasosdepruebadeJunitmedianteunplugin.
Posee una completa variedad de aserciones como la comprobacin de cumplimiento del
contratoenunmtodo.
Los metadatos (Conjunto de datos que se utilizan para describir otros datos) de los casos de prueba son
especificadoscomoanotacionesdellenguajeJava
IncluyeunatareadeAntparaautomatizarlaspruebas.
Documentacin muy completa en JavaDoc, y una pgina web con toda la informacin
necesariaparacomprendersuuso,yutilizarloconIDEcomoEclipse.
ElFramework(Estructuraconceptualytecnolgicadesoportedefinida,normalmenteconmdulosdesoftwareconcretos,
conbaseenlacualotroproyectodesoftwarepuedeserorganizadoydesarrollado)incluyepruebasunitariassobre
smismo.
9 TestNG:
EstainspiradoenJUnityNUnit.
Est diseado para cubrir todo tipo de pruebas, no solo las unitarias, sino tambin las
funcionales,lasdeintegracin...
UtilizalasanotacionesdeJava1.5(desdemuchoantesqueJunit).
EscompatibleconpruebasdeJunit.
Soporteparaelpasodeparmetrosalosmtodosdepruebas.
Permiteladistribucindepruebasenmaquinasesclavas.
Soportadoporgranvariedaddeplugins(Eclipse,NetBeans,IDEA...)
Losclasesdepruebasno necesitanimplementarninguna interfazniextenderningunaotra
clase.
Unavezcompiladaslapruebas,estassepuedeninvocardesdelalineadecomandosconuna
tareadeAntoconunficheroXML.
Losmtodosdepruebaseorganizanengrupos(unmtodopuedeperteneceraunoovarios
grupos).
9 Junit:
FrameworkdepruebasunitariascreadoporErichGammayKentBeck.
Esunaherramientadecdigoabierto.
Multituddedocumentacinyejemplosenlaweb.
SehaconvertidoenelestndardehechoparalaspruebasunitariasenJava.
SoportadoporlamayoradelosIDEcomoeclipseoNetbeans.
EsunaimplementacindelaarquitecturaxUnitparalosframeworksdepruebasunitarias.
PoseeunacomunidadmuchomayorqueelrestodelosframeworksdepruebasenJava.
Soportamltiplestiposdeaserciones.
Desdelaversin4utilizalasanotacionesdelJDK1.5deJava.
PosibilidaddecrearinformesenHTML.
OrganizacindelaspruebasenSuitesdepruebas.
EslaherramientadepruebasmsextendidaparaellenguajeJava.
LosentornosdedesarrolloparaJava,NetBeansyEclipse,incorporanunpluginparaJunit.

22

DAW

Diseoyrealizacindepruebas

8.2.Herramientasparaotroslenguajes.
En la actualidad, nos encontramos con un amplio conjunto de herramientas destinadas a la
automatizacindelprueba,paralamayoradeloslenguajesdeprogramacinmsextendidosenla
actualidad.ExistenherramientasparaC++,paraPHP,FoxPro,etc.
Cabedestacarlassiguientesherramientas:
9 CppUnit:
FrameworkdepruebasunitariasparaellenguajeC++.
Esunaherramientalibre.
ExistediversosentornosgrficosparalaejecucindepruebascomoQtTestRunner.
EsposibleintegrarloconmltiplesentornosdedesarrollocomoEclipse.
BasadoeneldiseodexUnit.
9 Nunit:
Frameworkdepruebasunitariasparalaplataforma.NET.
Esunaherramientadecdigoabierto.
TambinestbasadoenxUnit.
DisponedediversasexpansionescomoNunit.FormsoNunit.ASP.Junit
9 SimpleTest:EntornodepruebasparaaplicacionesrealizadasenPHP.
9 PHPUnit:frameworkpararealizarpruebasunitariasenPHP.
9 FoxUnit:frameworkOpenSourcedepruebasunitariasparaMicrosoftVisualFoxPro
9 MOQ:Frameworkparalacreacindinmicadeobjetossimuladores(mocks).

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

23

Tema3

DesarrollodeAplicacionesWeb

9.Automatizacindelaprueba.
Caso prctico
Juan est realizando pruebas de la unidad, es decir, comprueba el correcto funcionamiento de los
mtodos que ha implantado. Para ello, utiliza las herramienta de prueba incorporadas en el entorno
de desarrollo. En sucaso, ya que est utilizando NetBeans, se decanta por Junit. Ana est muy
interesada en conocer esta herramienta, que ayuda notablemente en el proceso de pruebas

Laspruebasdesoftwaresonparteesencialdelciclo
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,quepermitenautomatizarlaspruebas.
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,
paracadaclasediseadaennuestraaplicacin.Unavezcreadalasclasesdeprueba,establecemos
losmtodosquequeremosprobar,yparaellodiseamoscasosdeprueba.Loscriteriosdecreacin
decasosdeprueba,puedensermuydiversos,ydependerndeloquequeramosprobar.
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
(imagenanterior).Enfuncindelosresultados,deberemosono,modificarelcdigo.

UsodeJUNITenNetBeans
INTRODUCCIN
Losentornosdedesarrollomsextendidos,queseutilizanparaimplementaraplicacionesJava,tales
comoNetBeansoEclipse,incorporanunpluginparatrabajarconJunit
JunitnosvaaservirpararealizarpruebasunitariasdeclasesescritasenJava,dentrodeunentorno
depruebas.Esunframeworkconmuypocasclasesfcildeaprenderydeutilizar.
Unavezquehemosdiseadonuestraaplicacin,ylahemosdepurado,procedemosaprobarla.Enel
casodelejemplo,disponemosdeunaclase,denombrecVector,dondesehandefinidounaseriede
mtodos.
Elobjetivovaasereldiseoyejecucindealgunoscasosdeprueba.
INICIODEJUNIT
Para iniciar Junit, seleccionada en la ventana de proyectos la clase a probar, abrimos el men
contextualyseleccionamosHerramientas>CrearpruebasJunit.
NosapareceunformulariodondenosdaaelegirentreJUnit3.xyJUnit4.x.Sonlasdosversionesde
JUnitdisponiblesenNetBeans6.9.1.Ennuestrocaso,elegimosJUnit3.x.
Puesto que vamos a probar la clase CVector, por convenio es recomendable llamar a la clase de
prueba CVectorTest. Esta clase se va a insertar en un nuevo paquete de nuestro proyecto,
denominadoPaquetedeprueba.

24

DAW

Diseoyrealizacindepruebas

Comoseapreciaenelformulario,JUnitvaagenerarlosmtodos
queaparecenseleccionados.Ennuestrocasolovamosadejartal
cual,aunqueluefovanasermodificadosenelcdigo.
Al pulsar el botn Aceptar nos aparecen un nueva clase de
nombre CVectorTest, que contiene los mtodos que estaban
seleccionados en el formulario
anterior, con un cdigo prototipo. Es
enesecdigoenelqueelprogramadorcrearsuscasosdeprueba.
El diseo de los casos de prueba, requiere que se establezcan criterios
que garanticen que esa prueba tiene muchas probabilidades de
encontraralgnerrornodetectadohastaelmomento.
CASOSDEPRUEBA
Enprimerlugar,vamosaverlafuncindelosInicializadoresyFinalizadores.ElmtodoSetUpyel
mtodotearDown,seutilizanparainicializaryfinalizarlascondicionesdeprueba,comopuedeserla
creacindeunobjeto,inicializacindevariables,etc.Enalgunoscasos,noesnecesarioutilizarestos
mtodos,perosiempresesuelenincluir.
El mtodo setUp 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
necesarioparainicializaralgunasvariablesantesdeiniciarlaprueba.
ElmtodotearDownesunmtodofinalizadordeprueba,yseejecutardespusdecadatestenla
claseprueba.Unmtodofinalizadornoesnecesarioparaejecutarlaspruebas,perosinecesitamos
unfinalizadorparalimpiaralgndatoquefuerequeridoenlaejecucindeloscasosdeprueba.
Ensegundolugar,esnecesarioconocerlasaserciones.LosmtodoassertXXX(),seutilizanparahacer
las pruebas. Estos mtodos, permiten comprobar si la salida del mtodo que se est probando,
concuerdaconlosvaloresesperados.Lasprincipalesson:
AssertTrue()

evalaunaexpresinbooleana.Lapruebapasasielvalordelaexpresinestrue.

assertFalse() evalaunaexpresinbooleana.Lapruebapasasielvalordelaexpresinesfalse.
AssertNull()

verificaquelareferenciaaunobjetoesnula.

assertNotNull()verificaquelareferenciaaunobjetoesnonula.
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
mismoobjeto.
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
diferentesopertenecenaobjetosdistintos.
assertEquals() Seusaparacomprobarigualdadaniveldecontenidos.Laigualdetiposprimitivosse
comparausando==,laigualentreobjetossecomparaconelmtodoequals().Lapruebapasasilos
valoresdelosargumentossoniguales.
fails()
causaquelapruebafalleinmediatamente.Sepuedeusarcuandolapruebaindicaun
errorocuandoseesperaqueelmtodoqueseestprobandollameaunaexcepcin.

25

Tema3

DesarrollodeAplicacionesWeb

En este punto, nos disponemos a disear los mtodos que necesitemos para los casos de prueba.
Ejemplosdecasosdepruebapuedenser:
public void test_posicion (int pos){
vectorTest.insertar(3);
vectorTest.insertar(5);
try{
assertTrue (vectorTest.posicion(7)==1);
}catch (Exception e){
fail(El mtodo test_posicion no funciona);
}
}
/**
* Test del mtodo ordenar_vector, de la clase CVector. Si ordena bien,
comparacin entre el
* vector vOrdenado y prueba, debe ser cierta y la prueba un xito
*/
public void test_ordenar_vector(){
int [] vOrdenado = {7,36,45,52,85};
int [] prueba = new int[5];
try{
vectorTest.insertar(36);
vectorTest.insertar(85);
vectorTest.insertar(45);
vectorTest.insertar(52);
vectorTest.insertar(7);
vectorTest.ordenar_vector();
for (int i=0;i<5;i++)
prueba[i]=vectorTest.posicion(i);
assertEquals(vOrdenado,prueba);
}catch (Exception e){
fail(El mtodo vector _lleno no funciona);
}
}
/**
* Test del mtodo vector_lleno(), de la clase cVector. Debera devolver true, al
* insertar 100 elementos
*/
public void test_vector_lleno(){
try{
for(int i=0;i<100;i++)
vectorTest.insertar(i);
assertTrue(vectorTest.vector_lleno());
}
catch(Exception e){
fail(El mtodo vector_lleno no funciona);
}
}

Estostresmtodosintentanprobaralgunosmtodosdelaclase
CVector. Para ello, teniendo seleccionado el proyecto,
accederemosalmencontextualypulsamoslaopcinProbar.
Como se puede comprobar, la prueba sobre el mtodo
vector_lleno ha sido un xito, pero ha fallado la prueba sobre
ordenar_vector. Con esta informacin, debemos comprobar que
el caso de prueba est diseado, en cuyo caso, lo que se ha
encontradoesunerroreneldiseodelmtodoordenar_vector,y
hay que redisearlo. La ventaja de utilizar herramientas
automatizadas, es que se facilita la regresin, ya que tenemos
diseado el caso de prueba para el mtodo, as que una vez

26

la

DAW

Diseoyrealizacindepruebas

rediseado,podemosvolveraprobarloconelmismocasodeprueba.

Parasaberms
Enelsiguienteenlacenosencontramosconunejempocompletodepruebadelaunidadcon
NetBeans
CreacindeCasosdePruebaenNetBeansconJunit
http://netbeans.org/kb/docs/java/junit-intro.html#Exercise_21

27

Tema3

DesarrollodeAplicacionesWeb

10.Documentacindelaprueba.
Caso prctico
BK Programacin, al igual que en todas la fase de diseo de un sistema, en la fase de prueba realiza
la documentacin. Ada, como coordinadora, le pide a Ana que ayuda a realizar la documentacin de
la prueba, y le pide que se repase la metodologa Mtrica v.3 y ayude a Mara y a Juan en la labor de
documentacin.

Comoenotrasetapasytareasdeldesarrollodeaplicaciones,ladocumentacindelaspruebasesun
requisito indispensable para su correcta realizacin. Unas pruebas bien documentadas podrn
tambinservircomobasedeconocimientoparafuturastareasdecomprobacin.
Lasmetodologasactuales,comoMtricav.3(MetodologadePlanificacin,DesarrolloyMantenimientodesistemasde
informacin.Mtricav3sepuedeusarlibremente,conlanicarestriccindecitarlafuentedesupropiedadintelectual,queeselMinisterio
dePresidencia),proponenqueladocumentacindelafasedepruebassebasenenlosestndaresANSI/

IEEEsobreverificacinyvalidacindesoftware.
EnpropsitodelosestndaresANSI/IEEEesdescribirunconjuntodedocumentosparalaspruebas
de software. Un documento de pruebas estndar puede facilitar la comunicacin entre
desarrolladores al suministrar un marco de referencia comn. La definicin de un documento
estndardepruebapuedeservirparacomprobarquesehadesarrolladotodoelprocesodeprueba
desoftware.
Losdocumentosquesevanagenerarson:
9 PlandePruebas:Alprincipiosedesarrollarunaplanificacingeneral,quequedarreflejadaen
el"PlandePruebas".ElplandepruebasseiniciaelprocesodeAnlisisdelSistema.
9 Especificacindeldiseodepruebas.Delaampliacinydetalledelplandepruebas,surgeel
documento"Especificacindeldiseodepruebas".
9 Especificacin de un caso de prueba. Los casos de prueba se concretan a partir de la
especificacindeldiseodepruebas.
9 Especificacin de procedimiento de prueba. Una vez especificado un caso de prueba, ser
precisodetallarelmodoenquevanaserejecutadoscadaunodeloscasosdeprueba,siendo
recogidoeneldocumento"Especificacindelprocedimientodeprueba".
9 Registro de pruebas. En el "Registro de pruebas" se registrarn los sucesos que tengan lugar
durantelaspruebas.
9 Informedeincidentedepruebas.Paracadaincidente,defectodetectado,solicituddemejora,
etc,seelaborarun"informedeincidentedepruebas".
9 Informe sumario de pruebas. Finalmente un "Informe sumario de pruebas" resumir las
actividadesdepruebavinculadasaunoomsespecificacionesdediseodepruebas.

Parasaberms
En el siguiente enlace podrs visitar la pgina de Ministerio de Poltica Territorial y
AdministracinPblica,dedicadaaMtricav.3
Mtricav.3
http://administracionelectronica.gob.es/?_nfpb=true&_pageLabel=P60085901274201580632
&langPae=es
Autoevaluacin
La documentacin de la prueba:
Es una labor voluntaria que se puede realizar al final del proceso de pruebas
Cada equipo de pruebas decide qu documenta y cmo.
En Espaa se usa Mtrica v.3

28

DAW

Diseoyrealizacindepruebas

AnexoI.NormaISO/IEC29119.
LanormaISO/IEC29119secomponedelassiguientespartes:

Parte1.Conceptosyvocabulario:
o Introduccinalaprueba.
o Pruebasbasadasenriesgo.
o Fases de prueba (unidad, integracin, sistema, validacin) y tipos de prueba
(esttica,dinmica,nofuncional,).
o Pruebaendiferentesciclosdevidadelsoftware.
o Rolesyresponsabilidadesenlaprueba.
o Mtricasymedidas.
Parte2.Procesosdeprueba:
o Polticadelaorganizacin.
o Gestindelproyectodeprueba.
o Procesosdepruebaesttica.
o Procesosdepruebadinmica.
Parte3.Documentacin
o Contenido.
o Plantilla.
Parte4.Tcnicasdeprueba:
o Descripcinyejemplos.
o Estticas:revisiones,inspecciones,etc.
o Dinmicas: Caja negra, caja blanca, Tcnicas de prueba no funcional (Seguridad,
rendimiento,usabilidad,etc).

29