ADMS - Tema 5

ANLISIS,DISEOYMANTENIMIENTODEL
SOFTWARE
TEMA5:FASESDEPRUEBAS
DAVIDRODRGUEZHERNNDEZ
FECHADEREVISIN:11Marzo2008
ZAMORA(CURSO2007/2008)
david.rgh@gmail.com
ANLISIS,DISEOYMANTENIMIENTODELSOFTWARE
2
Notaimportante:
EstedocumentonopretendereemplazaralmaterialpropuestoporlaUNEDparalaasignaturaAnlisis,
DiseoyMantenimientodelSoftware.
Su finalidad es presentardeuna forma esquematizada los contenidos de la asignatura, parafacilitarel
estudio de la misma. Es conveniente disponer de la bibliografa propuesta por la Universidad para su
estudiocompleto.
Elpresentedocumentoslorecogeelresumendeltemarioenellibrobase.Ellectordebepreocuparse
dedisponertambindelaguadelaasignaturaylaadenda,dondeseamplanloscontenidos.
Cualquier sugerencia,comentario o correccin sobre este documento, envelo a david.rgh@gmail.com
parapoderrealizarloscambiosnecesarios.
DavidRguez.Hdez.
Alumnode2cicloIngenieraInformtica(UNED)
3
UNENFOQUEESTRATGICOPARALAPRUEBADELSOFTWARE
Laspruebasdebenserplanificadasconantelacin,paraloquehayquedefinirunaplantilla.Aunquehay
variasestrategias,todascoincidenenlosiguiente:
Serealizanrevisionestcnicasformalesyefectivas.
Secomienzaaniveldecomponentesysecontinahacialaintegracindelconjunto.
Endiferentesmomentospuedenserapropiadasdistintastcnicasdeprueba.
La dirige el desarrollador del software o un grupo independiente de pruebas (para proyectos
grandes).
Laspruebasincluyenladepuracin,aunquesonactividadesdistintas.
Debehabertantopruebasdebajonivelcomodealtonivel.
Verificacinyvalidacin
Laverficacinconsisteencomprobarqueelsoftwareestimplementandocorrectamenteunafuncin,
mientras que la validacin consiste en comprobar que se corresponde con las necesidades del cliente.
Esto, conocido como VyV, contiene como parte suya las pruebas del software. VyV abarca un amplio
conjuntodeactividades.
Laspruebaspermitendescubrirerrores,peronosonunagarantacompletadelacalidaddelsoftware.
stadebeincorporarsealolargodetodoelproceso.
Organizacinparalaspruebasdelsoftware
Uno de los principales problemas que surgen son los intereses. A los desarrolladores les interesa
mostrar que el software est libre de errores. El desarrollador puede ver la prueba como algo
destructivoparasuideadelsoftware,algoqueeliminaralaideadeunsoftwarelibredeerrores.
El ingeniero puede desarrollar pruebas que no encuentren los errores, pero por norma general, si el
ingenieronolosencuentraelclientesquelohar.Sinembargo,esincorrectoqueelingenieronodeba
participarenlaspruebas,quenosedebadejarprobaraunextraoniquelosencargadosdelaspruebas
nodebanparticiparantesdelaspruebas.
El desarrollador debe hacer las pruebas individuales para cada componente que desarrolle. Muchas
veces tambin deber hacer las pruebas de integracin. Una vez que la arquitectura del software est
completa,entrarenjuegoungrupoindependientedeprueba(GIP).Estegruposeencargadedetectar
yeliminarloserroresqueseproducencasiinevitablementecuandosedejaqueelconstructorpruebesu
propiacreacin.
EldesarrolladordebecolaborarjuntoalGIPpararealizarpruebasexhaustivas.
4
Estrategiadepruebaparaarquitecturasconvencionalesdelsoftware
Enlaespiraldelapgina387puedeverselaestrategiadepruebas.Enellasecomienzadesdefuerayse
realizanlasdistintasfasesdeldesarrollo.Unavezllegadosalcdigo,serecorredenuevolaespiralhacia
fuerapasandoporlasdistintaspruebas.
Lapruebadeunidadaseguraunacoberturacompletayunadeteccinmximadeerrores.Trasella,los
componentes se ensamblan y se realizan las pruebas de integracin, que engloba los aspectos
relacionadosconlaverificacinylaconstruccindelsoftware.
Unavezconstruido elsoftware,secomienzancon laspruebasdealtonivel.Seevalanloscriteriosde
validacindelprograma,queaseguraqueelprogramacumplaconlosrequisitos.
Porltimo,serealizanlaspruebasdelsistema.Secombinaelsoftwareconotroselementos(hardware,
BBDD...)ysecompruebaquefuncionecorrectamente.
Estrategiadepruebadelsoftwareparaarquitecturasorientadasaobjetos
En estas arquitecturas, la prueba de unidad pierde parte de su significado, y las estrategias de
integracincambiandeformarelevante.Aligualqueenlasarquitecturasconvencionales,secomienza
probandodedentroafuera,perolaspruebaspequeascambiandeserunmduloindividualaseruna
claseconatributosyoperacionesquerequierecolaboracinycomunicacin.
Sevanejecutandopruebasderegresinquepermitendetectarerroresproducidosporlacomunicacin
ycolaboracinentreclasesoalosefectoscolateralesdeaadirnuevasclases..
Criteriosparacompletarlaprueba
Un dilema tpico consiste en establecer un punto en el que las pruebas se consideren terminadas. Las
pruebasrealmentenoterminan.Cuandounclienteusaelprograma,esotambinesunaprueba.
Se propone emplear mtodos estadsticos para establecer cundo se ha llegado al punto en el que las
probabilidadesdequeelprogramafuncionesonaltas.
ASPECTOSESTRATGICOS
Serecomiendanlossiguientespuntospararealizarconxitolaspruebasdelsoftware:
Especificar los requisitos de forma cuantificable mucho antes de las pruebas. Las pruebas no
solodetectanerrores.Tambinmidenlacalidaddeotrosrequisitos,comolaportabilidadentre
plataformas.Estosrequisitosnodebenserambiguos.
Establecer explcitamente los objetivos de la prueba. El plan de prueba debe tener, por
ejemplo, su efectividad y cobertura, el tiempo medio de falla, coste de encontrar y corregir
defectos,frecuenciadelasfallasrestantesylashorasdetrabajoporpruebaderegresin.
5
Desarrollar un plan de prueba que destaque la prueba de ciclo rpido. Las pruebas de ciclo
rpido proporcionan una retroalimentacin que permite controlar los grados de calidad y las
estrategiasdeprueba.
Construir un software robusto que se pruebe a s mismo. El softwaredebe poderdiagnosticar
ciertasclasesdeerroreseincluirpruebasautomatizadasyderegresin.
Usar tcnicas formales y efectivas. Por ejemplo, las revisiones reducen el esfuerzo que se
dedicarposteriormentealaspruebas.
Realizar revisiones tcnicas formales. Esto posibilita descubrir inconsistencias, omisiones y
erroresevidentesenelenfoquedelaprueba,loqueahorratiempoymejoralacalidad.
Desarrollarunenfoquedemejoracontnuaparaelprocesodeprueba.Laestrategiadeprueba
debe ser medida. Esta informacin obtenida se puede usar como parte de un enfoque
estadsticodecontroldelprocesoparalapruebadelsoftware.
ESTRATEGIASDEPRUEBAPARAELSOFTWARECONVENCIONAL
Generalmente no se debe esperar a tener la construccin completa para probarla, y los equipos
tampocohacenpruebasadiario.Laeleccinsueleseruntrminomedio,conunenfoqueincremental
delaspruebas.Secomienzaconpruebasdeunidad,despusserealizanlasdeintegraciny,porltimo,
sobreelsistemaconstruido.Ahoraveremosunoporunotodoslostiposdeprueba:
Pruebadeunidad
Verifica un componente o mdulo de software. Se prueban caminos de control para detectar los
errores.
Consideraciones
Se examinan las estructuras de datos locales (conservar la consistencia), se analiza cada camino
independiente,sepruebanloslmitesquesehanestablecidopararestringirelprocesoyloscaminosde
manejo de errores. Tambin se prueba la interfaz del mdulo (entradas y salidas), esto es lo primero
quesedebeprobar.
Paraprobarlasrutasdeejecucin,sediseancasosdeprueba.Puedendarseerrorescomoaritmticos
por mala precedencia, operaciones mezcladas, incializacin incorrecta, falta de precisin y
representacin simblica incorrecta de una expresin. Los casos de prueba deben descubrir errores
comocomparacionesentrediferentestiposdedatos,operadoreslgicosodeprecedenciaincorrectos,
expectativas de igualdad cuando hay errores de precisin, comparacin incorrecta de variables,
terminacin inapropiada de los bucles (o inexistente), falla en la salida cuando se encuentra una
iteracindivergenteyvariablesdebuclemodificadasinapropiadamente.
Lapruebadelmitesesunadelasmsimportantes.Esdecir,escomnencontrarseerrorescuandose
procesa elprograma fuera de los lmites establecidos(dar la iteracini+1 enunbucle de i iteraciones,
porejemplo).
6
Deben comprobarse asimismo el manejo de las condiciones de error (enfoque antierror), como por
ejemplo, una divisin por 0 en datos introducidos por el usuario. Se debe tener en cuenta que la
descripcin del error no sea ininteligible, que se corresponda al error encontrado, que la condicin de
error no provoque la intervencin del SO, que se procese de forma adecuada y que la descripcin
proporcionelainformacinsuficiente.
Procedimientosdepruebadeunidad
Las pruebas de unidad suelen considerarse como el paso adyacente a la codificacin. Cada caso de
prueba diseado debe corresponderse con un conjunto de resultados esperados. Los componentes no
sonprogramasindependientes,porloqueserequiereunsoftwarecontrolador,queaceptalosdatosde
loscasosdeuso,lospasaalcomponente,eimprimelos resultados.Porotraparte,losresguardosson
programasquereemplazanalosmdulossuboordinadosalmduloqueseestprobando.Enlapgina
394sepuedeverunesquemaquelosmuestra.
Elusodecontroladoresyresguardossuponeunasobrecarga,yaquehayqueprogramarlosperonose
entregan con el producto final. Cuanto ms alta sea la cohesin del componente, ms sencilla ser su
prueba.
Pruebadeintegracin
Aunque los mdulos funcionen bien independientemente, puede haber problemas al integrarlos unos
conotros.Estosproblemasyerroresseintentandetectarmediantelaspruebasdeintegracin.
Hay una tendencia a realizar la integracin de forma brusca, cuando es preferible hacerla de forma
incremental.
Integracindescendente
Enestaintegracin,losmdulosseintegranaldescenderporlajerarquadecontrol,empezandoconel
mdulo de control principal. Los mdulos subordinados se pueden incorporar a la estructura de dos
formas:
Primeroenprofundidad:Integratodoslosmdulosdeunarutadecontrolprincipalcompleta
trasotra.
Primeroenanchura:Vaincorporandolosmdulosporniveles.
Enlapgina396puedenverselos5pasosparalaintegracindemdulos.
Aunque esta estrategia no parece complicada, pueden surgir problemas de logstica, como tener que
procesarnivelesinferioresparapoderprobarlossuperiores.Sepuedeoptarporretrasarmuchasdelas
pruebas hasta qe se reemplacen los resguardos con los mdulos reales, con lo que se pierde cierto
control sobre la correspondencia entre las pruebas especficas y la incorporacin de mdulos
especficos.
Tambin puede optarse por desarrollar resguardos que realicen funciones limitadas que simulen los
mdulosrealesointegrarelsoftwaredelaparteinferiordelajerarquahaciaarriba.Elprimerodelos
dospuedeaumentardeformaimportantelasobrecargadetrabajosegnsevuelvanmscomplejoslos
resguardos.Elsegundoseconocecomopruebaascendenteylaveremosahora.
7
Integracinascendente
Aqu se empieza la construccin y pruebas con mdulos atmicos. De esta forma, no se necesitan los
resguardos.Enapgina397sepuedenencontrarlospasosdelaestrategiadeintegracinascendente.
Pruebaderegresin
Alagregarnuevosmdulos,loqueantesfuncionababienpuedefallar.Realizarelmismosubconjuntode
pruebasqueantesparaasegurarnosdeestosedenominapruebaderegresin.Esdecir,laspruebasde
regresincompruebansiloscambiosenunprogramaintroducencomportamientosnodeseados.
Elconjuntodecasosdepruebaderegresintiene3clasesdecasosdeprueba:
Unamuestrarepresentativadepruebasqueejercerntodaslasfuncionesdelsoftware.
Pruebas adicionales que se concentran en las funciones del software que presumiblemente el
cambioafectara.
Pruebasqueseconcentranenloscomponentesdelsoftwarequehancambiado.
Amedidaqueseconstruyeelsoftware,elconjuntodepruebasderegresinaumentamucho.
Pruebadehumo
Estas pruebas permiten marcar el ritmo en proyectos con tiempo crtico. Las pruebas sirven para
exponer errores que impediran que la construccin de los componentes del software ejecuten
correctamente su funcin. Las construcciones se van integrando unas con otras y diariamente se
realizanpruebasdehumo.
Hacerlodeformadiariapermiteirconociendoelavancedelaspruebasdeintegracin.Proporcionalos
siguientesbeneficios:
Seminimizaelriesgoenlaintegracin.Estoesposiblegraciasaqueserealizandiariamente.
Se mejora la calidad del producto final. Es posible descubrir con estas pruebas errores
funcionales, arquitectnicos y a nivel de componentes, lo que permitira corregirlos con
prontitud.
Se simplifican el diagnstico y la correccin de errores. Los errores no descubiertos en estas
pruebasprobablementeseancausadenuevosincrementosdelsoftware.
Elprogresoesmsfcildeevaluar,porlacontinuidaddelaspruebas.
Opcionesestratgicas
Las pruebas de integracin ascendentes y descendentes tienen sus ventajas e inconvenientes (por lo
general,loqueparaunosonventajas,paraelotrosoninconvenientes).Elegirunauotradependerdel
proyectoencuestinodesucalendario.
Incluso puede optarse por una combinacin de ambos (prueba sandwich), usando pruebas
descendentesparalosnivelessuperioresdelaestructuradelprogramaypruebasascendentesparalos
nivelessubordinados.
Hayqueidentificarlosmduloscrticos,quetienealgunadelassiguientescaractersticas:
8
Atiendevariosrequisitosdelsoftware.
Tieneunaltogradodecontrol(nivelaltoenlaestructura).
Escomplejoopropensoaerrores.
Tienerequisitosdedesempeobiendefinidos.
Estos mdulos han de probarse lo antes posible y las pruebas de regresin se deben concentrar en el
funcionamientodeestosmdulos.
Documentacindelapruebadeintegracin
La Especificacin de la prueba es un documento que incluye el plan general para la integracin del
software y una descripcin de pruebas especficas. La prueba se divide en fases y construcciones que
atienden caractersticas especficas del funcionamiento y el comportamiento del software. Vase un
ejemploenlapgina401.
Debenaplicarselossiguientescriteriosparatodaslasfases:
Integridaddelainterfaz:Cadavezqueseincorporeunmdulohayqueporbarlasinterfaces.
Validezfuncional:Serealizanpruebasparadescubrirerroresfuncionales.
Contenido de la informacin: Se aplican pruebas para descubrir errores asociados con
estructurasdedatoslocalesoglobales.
Desempeo:Serealizanpruebasparaverificarloslmitesdedesempeoestablecidosdurante
eldiseodelsoftware.
Elplandepruebahadeatenderfechas,entornodelaspruebas,recursos...
9
ESTRATEGIASDEPRUEBAPARASOFTWAREORIENTADOAOBJETOS
Lanaturalezadeestesoftwareobligaaciertoscambiosdeestrategia.
Pruebadeunidadenelcontextoorientadoaobjetos
Cada clase e instancia empaqueta atributos y operaciones. Cambia el sentido de unidad. Las unidades
ms pequeas son las operaciones, aunque el eje de las pruebas suele ser la clase encapsulada. No se
puedeprobarunaoperacinaisladamente,sinocomopartedeunaclase.
Si tenemos, por ejemplo, una superclase y varias clases heredadas, una operacin X puede diferir en
cadaunadeellas,porloquesedebeprobarparacadacontexto.
Pruebadeintegracinenelcontextoorientadoaobjetos
Aqu no hay mtodo ascendente o descendente, ya que el OO (orientado a objetos) no tiene una
estrategiadecontrolclaramentejerrquica.Tenemosdosestrategiasposibles:
Pruebabasadaensubprocesos:Conjuntodeclasesnecesarioparaunarespuestaoeventodel
programa. Se prueba ntegramente por cada subproceso. La prueba de regresin se usa para
asegurarlainexistenciadeefectoscolaterales.
Prueba basada en el uso: Primero se prueban las clases independientes (usan pocas o
ningunaclasedeservidor)yluegolasclasesdependientes(stasusanlasprimeras).
En este contexto, con los controladores se prueban operaciones al nivel ms bajo y grupos completos
de clases o para reemplazar la interfaz de usuario. Los resguardos se usan en situaciones en que se
requierelacolaboracinentreclases,peroenlaquenoestntodaslasnecesariasimplementadas.
Tambintenemoslapruebadegrupo,quebuscaerroresenlascolaboracionesentreclases.
10
PRUEBASDEVALIDACIN
Siguen a las pruebas de integracin. Aqu no se diferencia entre el software convencional y el OO. La
validacin comprueba que el software satisfaga las expectativas razonables del cliente. Estas
expectativas se definen en la Especificacin de Requisitos de Software, en la seccin de Criterios de
Validacin.
Criteriosdelapruebadevalidacin
Pararealizarlaspruebasserequiereunplandeprueba,queespecifiquelaspruebasqueserealizarny
suprocedimiento.
Una vez se dirige cada caso de prueba de validacin, puede pasar que la caracterstica cumpla la
especificacin, o que se desve de ella (para lo cual se crea una lista de deficiencias). Esta desviacin
suelerequerirunarenegociacinconelcliente.
Revisindelaconfiguracin
Se usa para asegurar que todos los elementos de la configuracin del software se han desarrollado
correctamente,estncatalogadosytieneneldetallesuficienteparareforzarlafasedelciclodevidadel
software.Estarevisinseconocecomoaudiora.
Pruebasalfaybeta
Cuando se desarrolla un software personalizado, se suele realizar una serie de pruebas de aceptacin,
que permite que el cliente valide los requisitos. Estas pruebas las dirige el usuario final, no el
desarrollador. Estas pruebas pueden durar semanas o meses y pueden incluir pruebas de manejo o
pruebasplaneadas.
Ensoftwareorientadoaunpblicomsamplio,estonosepuedehacer.Paraestotenemoslaspruebas
alfaybeta.Laspruebasalfalasmanejanlosusuariosfinales,perobajolasupervisindeldesarrollador,
queanotalasincidencias.Laspruebasbetatambinlasmanejanlosusuariosfinales,peronormalmente
en su entorno de trabajo sin la supervisin del desarrollador y es el usuario quien debe registrar los
problemasparainformardeellos.
11
PRUEBASDELSISTEMA
El software slo es una parte de un sistema ms amplio. Esto queda ms all del propio desarrollo de
software,intervienehardware,personas,informacin...
Pruebaderecuperacin
Sefuerzaalsoftwareafallardedistintasformasyseverificaqueserecuperedeunaformaadecuada.
Esta recuperacin puede ser automtica, con lo que se chequea la reinicializacin, los mecanismos de
respaldo del sistema, la recuperacin dedatos y elnuevo arranque; omanual, con lo que se evala el
tiempomediodereparacinporpartedeloshumanos,paraversiesuntiempoaceptable.
Pruebadeseguridad
Un sistema puede ser ilegalmente accedido, por diferentes motivos (dinero, venganzas, intereses...).
Estapruebaevalasilosmecanismosdeproteccindelsistemafuncionencorrectamente.Recurdese
quelosataquesnosiempresonfrontales...puedenvenirdesdedentrodelapropiaempresa.
Elejecutordelapruebapuederealizarladelaformaquequiera(alfinyalcabo,nopodemossaberde
antemanocmoserelataquereal).
Pruebaderesistencia
Analiza el lmite al que es capaz de llegar el sistema (frecuencias de interrupciones altas, volumen de
datosexcesivo...)antesdefallar.Enresumen...setratadeforzarelsistemaparaverhastadndepuede
aguantar.
Pruebadedesempeo
El software no debe slo ejecutar bien sus funciones... debe ejecutarlas dentro de unos lmites
aceptables(tiempodeejecucin,usoderecursos...).
12
FUNDAMENTOSDELASPRUEBASDELSOFTWARE
Laspruebasdebenmostrarlassiguientescaractersticas:
Facilidad de prueba: El software ha de ser fcil de probar. Las siguientes caractersticas
permitendichafacilidad.
Operatividad:Cuantomejorfuncioneunsoftware,msfcilessernlaspruebas.
Observabilidad: El cdigo fuente ha de ser accesible y sus entradas y salidas deben ser
claramentevisibles.
Controlabilidad:Elingenierodepruebasdebepodercontrolarelsoftwareysusestados.
Capacidadparadescomponer:Cuandosecontrolaelalcancedelapruebas,losproblemasse
puedenaislarmsfcilmente.
Simplicidad: Las pruebas sern ms rpidas cuanto menos haya que probar. Podemos tener
una simplicidad funcional (mnimas caractersticas), una simplicidad estructural (arquitectura
enmdulos)yunasimplicidaddecdigo(estndardecodificacin).
Estabilidad:Cuantomenoscambioshaya,menosalteracionesaparecernenlaspruebas.
Facilidad de comprensin: Cuanta ms informacin se tenga sobre la arquitectura,
componentes,documentacin...mejorseharnlaspruebas.
Caractersticasdelaprueba:Tenemoslossiguientesatributos:
o Las buenas pruebas tienen gran probabilidad de encontrar un error. Deben disearse
pruebasparatodoslostiposdefallos.
o Nosonredundantes.Haytiempoyrecursoslimitados,nodebenredundar.
o Es la mejor de su clase. Cuando haya que seleccionar pruebas (porque no haya
tiempoorecursos)hadeseleccionarselamejor.
o Noesnidemasiadosimplenidemasiadocompleja.Cadapruebahadeejecutarsepor
separado.
13
PRUEBASDECAJANEGRAYCAJABLANCA
Haydosformasderealizarpruebas:conociendolafuncindeformaquesepuedaprobarqueseejecute
correctamente, o comprobando el funcionamiento interno del producto. Lo primero se llama pruebas
decajanegrayalosegundopruebasdecajablanca.
Lasdecajanegraseaplicanalainterfazdelsoftware(examinaunaspectofuncionalconpocarelacin
con la arquitectura del sistema). Las de caja blanca prueba las rutas lgicas del software y la
colaboracinentrecomponentes.
Aunque la prueba de caja blanca podra parecer ser la idnea para asegurar el buen funcionamiento,
realizarlaexhaustivamenteimplicaraproblemasdelogstica.
14
PRUEBASDECAJABLANCA
Tambin denominada prueba de cristal. Usa la estructura de control descrita como parte del diseo a
nivel de componentes para derivar los casos de prueba. Estos casos garantizan que todas las rutas
independientesdentrodelmdulosehanejercitadoporlomenosunavez,ejercitanlosladosverdadero
y falso de todas las decisiones lgicas, ejecutan todos los bucles en sus lmites y dentro de sus lmites
operacionalesyejercitanestruucturasdedatosinternosparaasegurarsuvalidez.
15
PRUEBADELARUTABSICA
Es una tcnica de prueba de caja blanca. Permite obtener una medida de complejidad lgica de un
diseo procedimental y usar dicha medida como gua para definir un conjunto bsico de rutas de
ejecucin.
Notacindegrficadeflujo
Describe un flujo de control lgico mediante la notacin de la figura 14.1 (pgina 424). En esa misma
pgina,enlafigura14.2,sepuedeverundiagramadeflujoysucorrespondienteengrficadeflujo.
Rutasindependientesdelprograma
Estasrutassonaquellasqueingresaalmenosunnuevoconjuntodeinstruccionesdeprocesamientoo
unanuevacondicin.Enlasgrficas,deberecorreralmenosunaaristaquenosehayarecorridoantes
(vaseelejemplodelapgina425).
Para saber cuntas rutas hay que buscar, hay que calcular la complejidad ciclomtica, que es una
mtricadesoftwarequeproporcionaunamedidacuantitativadelacomplejidadlgicadeunprograma.
En las pruebas, define el nmero de rutas independientes en el conjunto bsico de un programa y
proporcionaunlmitesuperiorparaelnmerodepruebasquedebenaplicarseparaasegurarquetodas
lasintruccionessehayanejecutadosporlomenosunavez.
Estacomplejidadpuedecalcularsede3formas:
Elnmeroderegionescorrespondealacomplejidadciclomtica.
2 V(G) es la complejidad ciclomtica de la grfica G. E es el nmero de
aristasyNelnmerodenodosdelagrficadeflujo.
) ( + = N E G V
1 ) PeselnmerodenodospredicadoenlagrficadeflujoG. ( + = P G V
Sepuedeverunejemplodelclculoenlapgina426.
Derivacindecasosdeprueba
Paraderivarelconjuntobsicotenemoslossiguientespasos:
1. Sedibujalagrficadeflujo:Apartirdeldiseoodelcdigo.Enlafigura14.4y14.5(pginas
428y429)puedeverselatransformacindeuncdigo.
2. DeterminarV(G)delagrfica:Utilizandoalgunadelasformasquehemosdescritoantes.
3. Determinar un conjunto bsico de rutas linealmente independientes: Hay tantas como
indiqueelV(G)calculado.
16
4. Preparar los casos de prueba que forzarn la ejecucin de cada ruta en el conjunto bsico:
Cuandosecompletantodosloscasos,hayqueasegurarsedequetodaslasinstruccionessehan
ejecutadoalmenosunavez.
Matricesdegrficas
Se trata de una matriz cuadrada cuyo tamao es el nmero de nodos de la grfica de flujo. Las filas y
columnas son los nodos y el contenido de la matriz son las conexiones entre ellos. Los nodos se
representanconnmerosylasaristasconletras.
Alamatrizseaadeunpesodeenlace,deformaqueseconvierteenunaherramientaparaevaluarla
estructuradecontroldelprogramadurantelaprueba.Elpesodeenlaceindicasihayconexin(1)ono
lahay(0),peropuedetenerinformacinadicional,comolaprobabilidaddequeseejecutelaarista,el
tiempo de procesamiento gastado durante el recorrido a un enlace, la memoria requerida durante el
recorridoolosrecursosrequeridosduranteelmismo.
17
PRUEBASDELAESTRUCTURADECONTROL
Estaspruebasensanchanlacoberturadelaspruebasymejoranlacalidaddelapruebadecajablanca.
Pruebadecondicin
Ejercita las condiciones lgicas de un mdulo. Una condicin simple es una variable booleana o una
expresinrelacional(igualdad,desigualdad,mayor,mayoroigual,menor,menoroigual).Unacondicin
compuestaunevariassimplesmediante&,|o.Silacondicinnotieneexpresionesrelacionalesesuna
expresinbooleana.
Pruebadelflujodedatos
Seleccionarutasdepruebaenunprogramadeacuerdoconlasubicacionesdelasdefinicionesylosusos
delasvariablesenelprograma.
Se dice que la definicin de una variable en una instruccin est viva en otra, si existe una ruta entre
ambasinstruccionesenlaquenohayaningunaotradefinicindelavariable.
Una cadena definicinuso (DU) es un conjunto [X,I,I]. En I est la definicin de X, en I su uso y la
definicindeXdeIestvivaenI.
Cada cadena DU debera cubrirse al menos una vez (estrategia de prueba DU). Pero esto no garantiza
que se cubran todas las cadenas (por ejemplo, en una cadena ifthenelse en que then no tenga
ningunadefinicindevariableyelsenoexista,nosegarantizaqueelseestcubiertaporlaprueba
DU).
Pruebadebucles
Esunatcnicadepruebadecajablanca.Validalaconstruccindebucles.Enlapgina432podemosver
las4clasesdebuclesquenospodemosencontrar.
Buclessimples:Sepruebaaomitirelbucle,darunsolopaso,dar2pasos,darmpasos(menor
quen)ydarn=1,n,n+1pasosporelbucle.
Bucles anidados: Se inicia en el bucle ms interno. A dicho bucle se le aplican las pruebas
simplesanteriores,manteniendolosvaloresmnimosparalosexternos.Sevanextendiendolas
pruebas a otros ms externos, pero todos aquellos que sean an ms externos debe
mantenersealmnimo.Secontinamientrasnosepruebentodoslosbucles.
Buclesconcatenados:Silosbuclessonindependientes(elcontadordeunonoesvalorinicial
del otro) seusan las pruebas simples para cadauno.Encaso contrario,se aplican laspruebas
parabuclesanidados.
Bucles no estructurados: Conviene redisearse estos bucles para usar las construcciones de
programacinestructurada.
18
PRUEBADECAJANEGRA
Tambinsellamanpruebasdecomportamiento.Compruebanlosrequisitosfuncionalesdelprograma.
Buscanerroresenfuncionesincorrectasofaltantes,erroresdeinterfaz,erroresenestructurasdedatos
oaccesoaBBDD,erroresdecomportamientoodesempeoyerroresdeinicializacinytrmino.
Estaspruebassuelenaplicarseenlasltimasetapasdelaprueba,yaquenoatiendenalaarquitectura
delprograma.
Conestastcnicassederivancasosdepruebaquesatisfacenloscriterios:casosdepruebaquereducen
ycasosdepruenaqueindicanalgoacercadelapresenciaoausenciadeclasesdeerrores,enlugardeun
errorasociadosloconlapruebaespecficaalamano.
Mtodosgrficosdeprueba
Hay que comprender los objetos del software y sus relaciones. Despus, hay que definir la serie de
pruebasquepermitanprobarquelosobjetostenganlasrelacionesentresesperadas.
Para ello, se crea una grfica. Los nodos representan objetos y los enlaces, la relacin entre ellos.
Tambin hay pesos de nodo, que son las propiedades de un nodo; y pesos de enlace, que describen
algunascaractersticasdeunenlace.
Enlapgina435podemosverunejemplo.Podemostenerenlacesdirectos(larelacinsemueveenuna
sola direccin) y enlaces bidireccionales (o paralelos) (la relacin se mueve en ambas direcciones).
Laseelejemplodelapgina435.
Podemosvercomoejemplolossiguientesmtodosdepruebasdecomportamientoqueusengrficas:
Modelado del flujo de transaccin: Los nodos son pasos de alguna transaccin. Se usa un
diagramadeflujodedatosparaayudaracrearlagrfica.
Modelado de estado finito: Los nodos son los estados observables en un software (ej:
pantallas)ylasrelacionessonlospasosparairdeunoaotro.Seusandiagramasdeestadopara
crearlagrfica.
Modelado del flujo de datos: Los nodos son objetos de datos y los enlaces, las
transformacionesparatraducirdeunobjetoaotro.
Modeladorelacionadoconeltiempo:losnodossonobjetosdeprogramaylosenlacessonlas
conexionessecuencialesentreesosobjetos.
Particinequivalente
Esunmtododepruebadecajanegraquedivideeldominiodeentradadeclasesdedatosapartirde
lascualespuedenderivarsecasosdeprueba.Seintentadefiniruncasodepruebaquedescubraciertas
clasesdeerrores,reduciendoaselnmerototaldecasosdepruebaquehandedesarrollarse.
Existe una clase de equivalencia si es posible enlazar un conjunto de objetos mediante relaciones
simtricas, transitivas y reflexivas. Esta clase representa un conjunto de estados vlidos y no vlidos
19
paralascondicionesdeentrada(estacondicinpuedeserunvalornumrico,unrango,unconjuntode
valoresrelacionadosounacondicinbooleana).Segnlascondiciones,puedeser:
Siesunrango,hayunaclasedeequivalenciavlidaydosnovlidas.
Siesunvalorespecfico,sedefineunaclasevlidaydosnovlidas.
Siesunmiembrodeunconjunto,hayunaclasevlidayotranovlida.
Siesbooleana,hayunaclasevlidayotranovlida.
Anlisisdevaloreslmite(AVL)
Llevaaunaseleccindecasosquepruebalosvaloreslmiteycomplementalaparticinequivalente.
Silacondicindeentradaespecificaunrangoentreayb,loscasosdepruebasediseancon
esosvalores,ademsdelosqueseencuentranapenasarribayabajodeellos.
Siespecificadiversosvalores,loscasosdepruebaejercitanlosnmerosmximoymnimoysus
inmediatosporarribayporabajo.
Se aplican las dos anteriores directirces a las condiciones de salida. Por ejemplo, una
comparacin entre dos datos como salida ha de derivar en casos de prueba que produzca el
nmeromximoymnimopermisibleparalasalida.
Silaestructurainternatienelmitesprescritos(ej:tamaodeunamatriz),ejercitarloslmites.
Pruebadetablaortogonal
Sielconjuntodeparmetrosysusvaloresesreducido,sepuedeprobarexhaustivamente,peroesoya
nosepuedehacersegncrecenlosparmetros.
La prueba de tabla ortogonal se aplica en dominios de entrada relativamente pequeos pero
demasiado grandes para una prueba exhaustiva. La tabla ortogonal tiene una propiedad de equilibrio
(loscasosdepruebaestanuniformementedistribuidosportodoeldominiodelaprueba).
Vaseelejemplodelaspginas439440.
20
MTODOSDEPRUEBASORIENTADASAOBJETOS
LossistemasOOhayqueprobarlosendistintosnivelesparadescubrirerroresquepuedansurgircuando
lasclasescolaboranentresylossubsistemas.
Unavezgeneradoelcdigo,lapruebaseempiezaporlopequeo,ejercitandolasoperacionesdeclase
yseobservanposibleserroresenlascolaboraciones.Alintegrarselasclases,seaplicalapruebabasada
enelusoylosenfoquesbasadosenfallas.Porltimo,seutilizanloscasosdeusoparadescubrirerrores
devalidacindelsoftware.
Implicacionesdelconceptoorientadoaobjetoseneldiseodecasosdeprueba
Lapropiedaddeencapsulamientopuedeserunobstculoalahoradeobtenerlainformacindelestado
de un objeto al hacer las pruebas, a no ser que se proporcionen operaciones que recuperen dicha
informacin.
Adems, la herencia (tanto simple como mltiple) complica las pruebas, ya que cada nuevo contexto
debe ser probado nuevamente (a no ser que las clases heredades se usen en el mismo dominio del
problemaquelasuperclase).
Aplicabilidaddemtodosconvencionalesdediseodecasosdeprueba
Aunque los casos de prueba de caja blanca son aplicables a las operaciones definidas en una clase,
mucha gente argumenta que el esfuerzo aplicado a la prueba de caja blanca podra redirigirse mejor
paraprobarunniveldeclase.
Los mtodos de prueba de caja negra son apropiados tanto para sistemas OO como para sistemas
convencionales.
Pruebabasadaenfallas
Se disean pruebas con altas probabilidades de encontrar fallas. Si los modelos de anlisis y diseo
arrojan luz sobre lo que tal vez est mal, entonces la prueba basada en fallas encontrar una gran
cantidaddeerroresconpocoesfuerzo.Perosiseconsideraunafallacomopocoprobable,esmsfcil
queseescape.
La prueba de integracin busca fallas en las llamadas a operaciones o en conexiones entre mensajes.
Puede haber tres tipos de fallas: resultado inesperado, operacin o mensaje incorrecto e invocacin
incorrecta.Esta prueba se aplica a los atributos y operaciones. Los errores se buscan en el cdigoque
llama,noelcdigollamado.
Casosdepruebayjerarquadeclases
Supongamos una clase padre y otra hija que hereda dos operaciones. Una de las operaciones se
redefine(polimorfismo),mientrasquelaotrapermaneceigual.Eslgicopensarquehayqueprobarla
que se ha redefinido, ya que el contexto es distinto... pero... y la otra? Si la otra operacin llama en
21
algn momento a la operacin redefinida, entonces puede haber errores al tener que manejar un
comportamiento nuevo. En tal caso, hay que probar tambin dicha funcin invariante. Si no hubiese
llamadas,estapruebaadicionalserainnecesaria.
Pruebabasadaenescenarios
Se concentra en lo que hace el usuario, no el producto. Es decir, se capturan las tareas que el usuario
debe hacer y se aplican (junto con sus variantes) como pruebas. Esto permite descubrir los errores de
interaccin.
Loscasosdepruebashandesermscomplejosyrealistasquelosdelaspruebasbasadasenfallas,ya
que estas pruebas no se limitan a un slo subsistema, sino que ejercitan varios en una sola prueba.
Vanselosejemplosenlaspginas445y446
Estructurasdesuperficieydefondoenpruebas
La estructura de superficie es la estructura que se puede ver externamente al programa (lo que ve el
usuariofinal).Eldiseodecasosdepruebaqueejercitenlaestructuradesuperficiedebeusarobjetosy
operacionescomopistasqueconduzcanatareasomitidas.
LaestructuradefondorepresentalosdetallestcnicosdeunprogramaOO(secomprendealexaminar
eldiseooelcdigo(oambos)).Estapruebaejercitadependencias,comportamientosymecanismosde
comunicacinestablecidoscomopartedelmodelodediseoparaelsoftwareOO.
Labasedelapruebadeestructuradefondosonlosmodelosdeanlisisydiseo.
22
MTODOSDEPRUEBAAPLICACBLESALNIVELDECLASE
Veamosunpardemtodosquesepuedenusarparaejercitarunaclase.
Pruebaaleatoriaparaclasesorientadasaobjetos
Dentro de las operaciones de una clase, puede haber restricciones (un operador puede necesitar
ejecutarse antes de poder usar otro distinto). Dentro de las combinaciones legales, se pueden coger
unasalazaryprobarlasparaejercitardistintoshistorialesdeinstanciasdeclase.
Pruebadeparticinalniveldeclase
Esparecidoalaparticinequivalentedelsoftwareconvencional.Seordenanencategorasysedisean
casosdepruebaparacadacategora.Ladivisinpuedeser:
Particinbasadaenelestado:Categorasenbaseasucapacidadparacambiarelestadodela
clase(verejemploenpgina448).
Particinbasada en atributos: Categoras en base a los atributos queutilizan (ejemplo en la
pgina449).
Particinbasadaencategoras:Ordenaencategoraslasoperacionesdeclaseconbaseenla
funcingenricaquerealizacadauna.
23
DISEODECASODEPRUEBADEINTERCLASE
Laspruebassecomplicancuandosecomienzanaintegrarlasclases.
Pruebadeclasesmltiples
Veamoslospasosadecuados:
1. En cada clase cliente se usa la lista de operaciones para generar secuencias de pruebas
aleatorias.Lasoperacionesenviarnmensajesaotrasclasesdelservidor.
2. Encadamensaje,determinarlaclasecolaboradoraylaoperacincorrespondienteenelobjeto
servidor.
3. Encadaoperacindelobjetoservidor,determinarlosmensajesquetransmite.
4. En cada mensaje, determinar el siguiente nivel de operaciones invocadas e incorporarlas a la
secuenciadeprueba.
Vaseelejemplodelapgina450.Laparticindeclasesmltiplesessimilaralasimple.Enelejemplo
mencionado, la clase Banco hace la particin entre los mtodos (operaciones) que sirven a
CajeroAutomaticoylosquesirvenaCajero.
Pruebasderivadasdemodelosdecomportamiento
Estas pruebas revisan el comportamiento dinmico de la clase (y sus colaboradoras).Vase el ejemplo
delapgina451;laspruebasadiseardebencubrirtodoslosestados(laclaseencuesinhadehacer
unatransicinatodoslosestadospermisibles).
El modelo de estado puede recorrerse en primeroenanchura. Esto significa que comienza probando
unanicatransicin.Cadavezquesequieraprobarunanueva,debehacerseusandolasquehansidoya
previamenteprobadas(ejemploenpgina452).
24
PRUEBASDEENTORNOSESPECIALIZADOS:ARQUITECTURASYAPLICACIONES
Todo lo anterior suele aplicarse en todos los entornos, arquitecturas yaplicaciones; pero en ocasiones
necesitaremosdirectricesespeciales.
Pruebasdeinterfacesgrficasdeusuario(GUI)
La creacin de GUI es ms rpida debido a la reutilizacin de componentes. Pero, puesto que se va
complicandoconeltiempo,laspruebassonmsdifcilesderealizar.
La mayora de las GUI funcionan de forma similar, por lo que pueden usarse pruebas estndar; pero
dado el gran nmero de permutaciones posibles en las operaciones de las GUI, la prueba ha de
reducirseusandoherramientasautomatizadas.
Pruebadearquitecturascliente/servidor
Suponeunimportantedesafoparalosquepruebanelsoftware.Sudificultadsebasaendetallescomo
distintas plataformas entre cliente y servidor, requisitos de coordinacin, necesidad de servir a varios
clientes,lacomunicacindelared...
Esta prueba puede darse en 3 niveles: aplicaciones individuales probndose de forma desconectada,
software de cliente y aplicaciones asociadas probadas en conjunto (pero las operaciones de red no se
ejercitan de forma explcita) y probando toda la arquitectura C/S, incluyendo la operacin y el
desempeodelared.
Podemosencontrarlossiguientesenfoquesdeprueba:
Pruebasdefuncionalidaddelaaplicacin:Laaplicacinsepruebadeformaindependiente.
Pruebas de servidor: Funcones decoordinaciny manejo dedatosdel servidor; as como su
tiempoderespuestayprocesamientototaldelosdatos.
PruebasdeBBDD:Exactitudeintegridaddelosdatosalmacenadosenelservidor.Funcinde
archivado. Se examinan las transacciones del cliente para almacenar, modificar y recuperar
datos.
Pruebasdetransaccin:Cadaclasedetransaccionesseprocesadeacuerdoconsusrequisitos.
Pruebas de comunicaciones de red: La comunicacin entre nodos es correcta y su paso de
mensajes,transaccionesytrficoderedrelacionadonotieneerrores.Puedeincluirpruebasde
seguridad.
Pruebadeladocumentacinylasfuncionesdeayuda
Nohayqueolvidarloserroresquepuedenproducirseenladocumentacin.Estoserrorespuedenllegar
asergravesdecaraalaaceptacindelusuario.Laspruebasdeladocumentacindebenserunaparte
significativa.
25
Seabordaendosfases:revisineinspeccinporunaparte(serevisalaclaridadeditorial)ylaprueba
envivo(seemplealadocumentacinjuntoconelprogramareal).
Pruebadesistemasdetiemporeal
Eltiempoesunelementoimportanteenlossistemasactuales.Parahacerlaspruebassedebeteneren
cuenta el manejo de los eventos, la temporizacin de los datos y el paralelismo entre las tareas que
manejanlosprocesos.Losestadosdeunsistemadetiemporealpuedenhacervariarlosresultadosde
unosdatosconcretos(vaseelejemplodelapgina455).
Porsupuesto,tambinhayquetenerencuentalasposiblesfallasdelhardware,aunqueestasfallasson
msdifcilesdesimulardeformarealista.
Sepuedeproponerunaestrategiaconlossiguientescuatropasos:
Prueba de tareas: Hay que probar cada tarea independientemente. Se desarrollan pruebas
convencionales para cada una. Esto permite descubrir errores de lgica y de funcionamiento
(peronodetiemponidecomportamiento).
Prueba de comportamiento: Mediante modelos del sistema (creados con herramientas
automaizadas)sepuedesimularelcomportamientodeunsistemadetiemporealyexaminarlo.
Estopermiteeldiseodecasosdepruebaqueserealizanunavezconstruidoelsoftware.
Pruebaintertareas:Seexaminanloserroresrelacionadosconeltiempo.Sepruebandistintas
tasas de datos y cargas de procesamiento para ver si ocurren errores de sincronizacin
intertareas.Tambinsepruebanlastareasquesecomunicanpormediodelacolademensajes
odelalmacndedatos,paraprobarlostamaosdeestasreas.
Pruebadelsistema:Unavezestnintegradoselsoftwareyelhardware,serealizanpruebas
del sistema, de forma que se pueden descubrir errores en la interfaz software/hardware. Se
comprueba si se asignan y manejan bien las propiedades de interrupcin, si se maneja
correctamente su procesamiento, si el desempeo en los procesamientos cumple con los
requisitosysilosgrandesvolmenesdeinterrupcionescreaproblemas.
26
PATRONESDEPRUEBA
Aligualqueencaptulosanterioresvimospatronesparaelanlisisyeldiseo,haypatronesdeprueba,
quedescribenconstruccionesqueserepitenamedidaquesediseanaplicacionesdistintas.
Proporcionanunadirectriztilparalasactividadesdeprueba,ademsdelossiguientesbeneficios:
1. Proporcionanunaterminologaalosencargadosdelaresolucindelosproblemas.
2. Concentran la atencin en las fuerzas que se encuentran detrs del problema (mejor
comprensinparalasolucin).
3. Estimulanelrazonamientoiterativo.
Son beneficios pequeos, pero importantes. En la pgina 457 pueden verse 3 patrones a modo de
ejemplo.

ADMS - Tema 5

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

ADMS - Tema 5

Cargado por

Copyright:

Formatos disponibles

ANLISIS,DISEOYMANTENIMIENTODEL

También podría gustarte