Content uploaded by Edgar Serna M.
Author content
All content in this area was uploaded by Edgar Serna M. on Aug 12, 2014
Content may be subject to copyright.
Disponible en: http://redalyc.uaemex.mx/src/inicio/ArtPdfRed.jsp?iCve=133115038013
Redalyc
Sistema de Información Científica
Red de Revistas Científicas de América Latina, el Caribe, España y Portugal
Serna Montoya, Edgar; Arango Isaza, Fernando
Análisis crítico a las propuestas para generar casos de prueba desde los casos de uso
para las pruebas funcionales
Avances en Sistemas e Informática, vol. 7, núm. 2, julio, 2010, pp. 105-114
Universidad Nacional de Colombia
Colombia
¿Cómo citar? Número completo Más información del artículo Página de la revista
Avances en Sistemas e Informática
ISSN (Versión impresa): 1657-7663
mprada@unalmed.edu.co;avances@unalmed.ed
u.co
Universidad Nacional de Colombia
Colombia
www.redalyc.org
Proyecto académico sin fines de lucro, desarrollado bajo la iniciativa de acceso abierto
RevistaAvancesenSistemaseInformática,Vol.7No.2,juliode2010ISSN16577663
Análisiscríticoalaspropuestasparagenerarcasosdeprueba
desdeloscasosdeusoparalaspruebasfuncionales
Criticalanalysisofproposalstogeneratetestcasesfromuse
casesforfunctionaltesting
Recibidopararevisión9demayode2010,aceptado4dejuniode2010,versiónfinal28dejuniode2010
Resumen
—El hechodeformalizarsuconocimiento le permite
a la s d isc ip lin a s in ge nie r iles log r a r r e su lta d os p r ed ecib le s.
L amen ta blemen te el con ocimient o ut iliza do en l a In genier ía d e
Softwarepuedeconsider a r sedeunn iveldemad ur ezrelativamente
ba jo; losdesa r r ollad or es se guían porla intuición, la mod a olo
q ue d icta el me rca d o, en l uga r de l os hec hos o d ecla r ac iones
indiscutiblespr opiasde unad isciplinaingenier il. Laspr opuestas
d ep r ueb a d eter min an los dif eren tes cr ite rios p ar a diseñ ar los
casosde pr uebaqueseutilizancomoentr ad asp ar aexamin ar un
siste ma obj eto d eest ud io; lo qu e sign ifica q ue d iseñ ar e ficaz y
eficientementeloscasosd epr uebaesunacond icióndeéxitopara
las pr uebas.Elconocimiento qu e permita seleccionar un método
depr u ebayunconjuntodecasosd epr u eba,debesurgirdeestudios
qu e jus tifiq uen los ben eficiosy la s con diciones d ea plica ción d e
los m ismos . Es te tr ab a jo a n aliza el n ivel d e ma dur ez d el
con ocimien to a cer ca de los métod os de diseñ o d e los cas os de
pr u ebagen er adospar alapruebafuncional,median teuna nálisis
cr ítico de las pr opu estas desa rr ollad as en esta temá tica.
Pa labrasClave
— Ca sos de p ru eb a, cas osd e uso, cu erp o de l
con o cim ien t o, p r u eb a s f un ci on a les , r eq u isi to s f un ci on a les,
verificación, va lid ación.
Abstra ct
—T he f a ct o f for m al izin g t hei r kn owled ge al lows
engineeringd isciplinestoachievepr edictableresults.Regrettably,
theknowledgeusedinSoftwar eEngineer ingcan b econsidered a
relativelylowlevelofmatur ity,developersareguid edbyintuition,
fashionor th edictatesofmarket,r a ther tha nfactsor undisputed
statementsproper toan engineer ingdiscipline.T hetestproposals
det erm ine the d iffer ent cr iter ia t od esign t he test ca sest ha t ar e
usedasimputstoconsiderasystemunderstu dy;whatmean sthat
todesigneffectivelyand efficientlyth etestcasesisacond itionof
su ccess for te stin g. T he k nowled ge t ha t a llows t o select a tes t
methodandasetoftestcases,mu starisefr omstudiesthatjustify
th e b en efit s a n d con d it ion s of t h eir a pp lica t ion . Th is p a p er
Ed gar Ser na Mo ntoya
1 & Fer nando Ara ngo Isaza
2
1.FundaciónUniversitariaLuisAmigó,
2.UniversidadNacionaldeColombiasedeMedellín
edgar.sernamo@amigo.edu.co; farango@unal.edu.co
an al yze st he ma tu rit ylevel of kn owledge a bou t desig n meth ods
oftestcases for functiona l testing through a n cr itical a nalysisof
th e pr oposals develop ed in th is subj ectmat ter.
Keywords
— Bo dy o f kn owl edg e, f un ct ion a l r eq ui r emen ts ,
fu nct iona l testin g, test ca ses, verif ication , valid at ion, u sec ases.
I. I NT RO DU C CI Ó N
L
a pr ueba es la últ ima oport unidad en el proceso de
desarrollodesoftwareparadetectarycorregirsusposibles
anomalíasauncostorazonable,yaquelaformageneralizadade
trabajoutilizadaporlosprofesionaleseneláreaesladeejecutar
lapruebasobreelproducto“terminado”[1];mientrasquela
prácticaenseñaquela pruebadebeser una actividadque se
desarrolladeformaparalelaatodoelprocesodelciclodevida
delproducto[2].“E
smuchomáscarocorregirloserroresque
sedetectancuandoelsistemaseencuentraenoperación
”[3],
porloqueesdeimportanciafundamentalpoderconfiarenque
elconocimientoaplicadosealosuficientementeformalcomo
paraobtenerresultadospredeciblesenelprocesodelaspruebas.
Losmétodosdepruebadeterminandiferentescriteriospara
diseñar loscasosde pruebaque se utilizaráncomoentradas
paraelsistemaenestudio,loquesignificaqueunefectivoy
eficientediseñodeéstoscondicionaeléxitodelaspruebas[4].
Elconocimientoparaseleccionarlosmétodosdepruebadebe
provenirdeestudiosquejustifiquenlosbeneficiosycondiciones
deaplicacióndelosmismos;sinembargo,“
losestudiosformales
y prá cticos de este tipo no abunda n, por lo que es difícil
compararlosmétodosdepruebanotienen unasólidabase
teórica,ydeterminarquévariablesdelosmismossondeinterés
enestosestudios
”[5].
RevistaAvancesenSistemaseInformática,Vol.7No.2,juliode2010ISSN16577663
106
Envistadelaimportanciadecontarconunconocimiento
formaldelaspruebas,enestedocumentoseanalizaelnivelde
madurezdelconocimientoeneláreaydeloscasosdeprueba
generadosparalaspruebasfuncionales.Paratalpropósitose
hace un análisis críti co de algunas de las más importantes
propuestas para gen erar casos de prueba a partir de los
requisitosfuncionalesdelossistemas.Elobjetivoprincipales
recogerelcuerpodeconocimientoacercadelosaspectosque
laspropuestastienenencuentaparadiseñarloscasosdeprueba
ysuniveldemadurez,detalmaneraqueestainformaciónpueda
serútilalosdesarrolladoresparaidentificarlascondicionesde
aplicabilidaddelosdiferentesmétodosyloscasosdeprueba
quegeneran.
Estedocumentoseestructuradelasiguiente forma:enla
sección2sedescribeelenfoquedesdeelcualseseleccionaron
losdiferentesestudios,laspruebasfuncionales;enlasección
3sepresentaelanálisiscríticodeungrupodepropuestaspara
diseñarcasosdepruebadesdeloscasodeusoparalaspruebas
funcionales,centradoenelmétodoqueempleanparadiseñarlos;
enlasección4sedetallanlasconclusionesextraídasdeeste
trabajodeinvestigación;yenla5sesugierenalgunosaspectos
quedeberíanabordarseenfuturosestudios,afindeaumentar
el cu erpo de conocim iento acer ca de los métod os y las
propuestasdediseñode casosdeprueba desde los casosde
usoparalaspruebasfuncionales.
II . L AS P RU EB AS FU NC IO NA LE S
Eltérmino“pruebadesoftware”comprendeunconjuntode
métodos,técnicasyconocimiento,cuyoobjetivoesdeterminar
la calida dde un si stema software mediante el análisis del
resultado de su fun cionamiento. Los métodos de prueba
proporcionandiferentescriteriosparadiseñarelconjuntode
casosdepruebaqueseutilizaránparaprobarelsoftware,yque
permitenagruparlosmétodosenfamilias.Deestamanera,los
métodosquepertenecenalamismafamiliasonsimilaresenlo
querespectaalainformaciónquenecesitanparadiseñarlos
casosdepruebacódigofuenteoespecificacionesoelcómo
se aplican los casos de prueba –flujos de control, flujos de
datos,errorestípicos,etc.Elobjetivodeestedocumentonoes
describirlascaracterísticasdelosmétodosdepruebaodesus
familias, ya que estai nformación puede ser obtenida de la
literaturaclásicarelacionada,porejemploBeizer[6]yMyers
[7],[8];encambio,secentraenladescripciónyeldetalledelas
propuestasutilizadas para diseñarcasosdeprueba desdeel
enfoquedelaspruebasfuncionales.
Lafamiliadelaspruebasfuncionalesproponeunenfoqueen
elquelaespecificacióndelprogramaseutilizaparadiseñarlos
casosdeprueba.Elcomponenteaprobarseconsideracomo
unacajanegra–
BlackBox
,cuyofuncionamientosedetermina
alestudiarlasentradasylassalidasasociadas.Delconjuntode
posi bles entradas del si stema est a famil ia consider a el
subconjuntoformadoporlasentradasquehacenquefuncione
deformaanormal;ylaclaveparadiseñarloscasosdeprueba
consiste en encon trar la s entra das qu e tienen u na alt a
pr obabili dad de p erten ecer a este subc onjun to. Pa ra t al
pr opósi to el m étod o divide las en tradas al sistem a en
subconjuntosdenominadosclasesdeequivalencia,dondecada
elementoquelaconformasecomportademanerasimilar,afin
dequetodosloselementosenellaseanlasentradasquecausen
tantoelfuncionamientonormalcomoelanormaldelsistema.
Losmétodosqueconformanestafamiliadifierenentresíen
cuantoalarigurosidadconlaquecubrenlasclasesdedatos
seleccionados.
II I . PR OP UE STAS PAR ADI SE ÑAR CASO S DE PR UE BADE SDE
LO S C ASO S DE USO PAR A L AS PR UE BAS F UN CI ON ALE S
Laspropuestasanalizadasacontinuaciónnosonlasúnicas
quesehanpromulgadoparadiseñarcasosdepruebadesdelos
casosdeusopara laspruebasfuncionales,la selecciónpara
esteanálisis sehizode aquellas propuestasquecumplieran
conlascaracterísticasdehabersepromulgadoapartirdelaño
2000, y que tuvieran como punto de partida los requisitos
funcionalesdelsoftwareespecificadosencasosdeuso.
3.1Automated test case generation from dynamic models[9]
Lapropuestapartedeuncasodeusodescritoenlenguaje
nat ural y an otado en un a plantil la recomenda da [10]; s e
estructuraendosbloques,enelprimeroserealizalatraducción
deloscasosde usoadiagramasdeestados,esdecir que se
traducendesdeellenguajenaturalaldiagrama;enlapropuesta
seincluyeunresumendelasreglasquedebenaplicarsepara
generardichodiagramadesdeladefinicióndeloscasosdeuso
[11].Enelsegundobloque,apartirdelosdiagramasdeestados
delbloqueanterior,serealizanlassiguientesactividades:1)se
tomanlaspreyposcondicionesdeldiagramaysetraducena
proposicionesconformadasporunidentificadorparacadauna
de ellas; 2) dado que pueden existi r proposiciones que no
depend en de los estad os ni tra nsiciones del diagra ma, es
necesariohacerunaextensiónalaactividadanterior,seanexa
unaproposiciónenlaqueelconjuntodedatosesválido–está
definido,yotraenlaquenoesválido–noestádefinido;3)
sobreelconjuntodeproposicionesextendidassegeneranlas
oper aci ones, proceso que consi ste en un a t radu cción
sistemáticautilizandotécnicasdeinteligenciaartificial;4)se
especificanlosestadosinicialyfinaldelconjuntoresultantede
pr oposiciones con junto d e requisi t os, ad i ccion es y
sustracciones; 5) se define con qué criterio se apli cará la
coberturadelapruebamedianteunprogramadeinteligencia
artificial,quetomalastransicionesdeldiagramadeestadosy
desde su estado in icial ana liza el posible estado fin al; 6)
mediantelaaplicacióndeunalgoritmosetraduceeldiagrama
deestadosallenguajeSTRIPS[12],ysegeneraelconjuntode
Análisiscríticoalaspropuestasparagenerarcasosdepruebadesdeloscasosdeusoparalaspruebasfuncionales
– Serna&Arango
107
casosde prueba;elalgoritmopermitehallar el conjuntode
operacionesquedesdelasprecondicionesobtienenlaspos
condiciones.
El pr oducto fina l de est a propu esta es u n conjun to de
transiciones posibles en eldiagrama de estados expresadas
conoperadores,ylasproposicionesinicialesyfinalesdelmismo.
Lapropuestahaceunaexplicacióndetalladadelprocesode
generación de pruebas que ilustr ad escriptivamen te; puede
aplicarse con cualquier herramienta que soporte STRIPS y
describeclaramentecómoestablecerlacobertura.Noexplica
cómoseextraenlasproposicionesdeldiagramadeestados;no
tieneencuentalasdependenciasdeloscasosdeuso;tratalos
casosdeusodemaneramuyaislada;noautomatizalatraducción
delcasodeusoaldiagramadeestados;enlamedidaquese
incrementalacomplejidaddelosdatostambiénseincrementan
proposicionesyoperaciones;elhechodeexpresarlaspruebas
conproposicionesyoperacionesdificultalaimplementación,
yaqueesnecesariorealizarretrocesosparadescribirlas.
3.2 Boundary Value Analysis [13]
Es una propuesta que selecciona los datos de prueba de
aquelloscuyovalorestáalolargodesuslímites,esdecirque
seleccionalosdatosdelasfronterassuperioreinferiordelvalor
aprobar.Incluyelosvaloresmáximo,mínimo,justodentroy
justofueradeloslímites,losvalorescaracterísticosylosvalores
deerror.Laideaesquesiunsistemafuncionacorrectamente
para estosvalores,funcionará correctamente para todoslos
valor es entr e ellos [1 4]. Tr adicion almen te comienza p or
identificarelincrementodevalormáspequeñoenunacategoría
específicadeequivalencia;esteincrementosellamaelvalor
límitede
épsilon
,yseutilizaparacalcularlosvaloresmáximosy
mínimosentornoaunaclasedeequivalencia.
Lospasosparautilizarlapruebadevaloreslímitesonsimples:
primero se identifican las clases de equivalencia; luego se
identificanloslímitesdecadaclaseyposteriormentesediseñan
loscasosdepruebaparacadavalorlímitemediantelaselección
deunpuntodelafrontera,unpuntojustodebajoyunpunto
justo por encima [15] . “Debajo” y “encima” son términ os
relativosquedependendelasunidadesdevalordelosdatos.
Sedebetenerencuentaqueunpuntojustodebajooencimade
unlímite,puedeestarenotraclasedeequivalencia,porloque
nohayningunarazónpararepetirlaprueba.
Estapropuestareducesignificativamenteelnúmerodecasos
depruebaquesecreanyejecutan;esmásapropiadaparasistemas
enlosquegranpartedelatomadedatosparavaloresdeentrada
estádentroderangosoenconjuntos;esaplicableenlaspruebas
deunidad,deintegración,desistemaydeaceptación;todoloque
requieresonentradasquepuedanserparticionadas,yfronteras
quepuedanseridentificadasconbaseenlosrequisitosfuncionales
delsistema;existemuchadocumentación,ejemplosycasosde
éxitoquelasoportan[16][21].
Laherramientadeaplicaciónesdemasiadocomplicadapara
utilizarynoofreceunaayudaclara;sudependenciadeotras
técn icas, como l a de clases de equivalencia, red uce su
homogen eidad e in dependen cia, ya que el probador d ebe
conocerlastambién.
3.3 Test cases from use cases[22]
Partedelprincipiodequelaspruebassedebendiseñardesde
lasprimerasetapasdelciclodevidadelproducto,ydescribe
cómoutilizarloscasosdeusoenlageneracióndeloscasosde
prueba.Elcasodeusosedefinetextualmenteenlenguajenatural
yenunaplantilla.
Lapropuestaconsisteen:1)generarlosescenariosdeprueba
de los casos de uso, don d e se i dentifican t odas la s
combinacionesposiblesentrelarutaprincipaldeejecucióny
lasalternas,yseenuncianenunatabla;2)identificarelconjunto
de casos de prueba conjunt o de entrad as, condiciones de
ejecu ción y res ultados esperados para cad a uno de los
escenariosycondicionesdeejecución;estainformacióntambién
seenunciaentablasperosinnotaciónoformalismo;3)identificar
elconjuntodevaloresparacadacasodeprueba.
Alfinaldelprocesoelresultadoesunatabla enlaquese
describen,enlenguajenatural,todosloscasosdepruebaque
permitanverificarquelaimplantacióndelcasodeusoescorrecta.
Aunquenoindicaunmodeloformalparapresentarelcasode
uso, sí describe los elementos que debe contener; tampoco
indicacómoseobtienenlosvaloresdelosdatosparaeltercer
paso;esunapropuestasencillaysimpledeaplicar,perolefalta
detalleyrigorenladescripción;ofrecepocaescalabilidadpara
procesosmáscomplejos;debidoaquetrataloscasosdeuso
aisladamente,noesposibleobservarladependenciaentreellos;
el lenguaje natur al en el que está expresada no facilita su
aut omatiza ción; el resultad o de apli carla a casos de uso
complejosesunelevadonúmerodecasosdeprueba;aunque
parte del principio de diseñar los casos de pruebadesde el
comienzodelproyecto,noexplicacómohacerlo;ynodescribe
lasreglassistemáticasquepermitanaplicarlospasos.
3.4 Requirement Base Testing [23], [24], [25]
Propuestaquepartedelconjuntoderequisitosenlenguaje
naturaly,mediantelaaplicacióndedosbloquesdeactividades,
genera los casos de prueba. Como resultado se obtiene un
conjuntodecasosdepruebaexpresadosenlenguajenaturaly
estructuradoenunmodelocausaefectooestadoesperado.
Elprimerbloque,revisiónderequisitos,estádivididoen4
actividades:1)seanalizanlosobjetivosdelsistemaysevalidan
conlosrequisitos;2)aesosrequisitosselesaplicanloscasos
deuso;3)sehaceunarevisiónnodetalladadeambigüedades,
queconsisteen eliminardela descripciónde losrequisitos
todaslas palabras yfrasesambiguas; 4) los integrantesdel
RevistaAvancesenSistemaseInformática,Vol.7No.2,juliode2010ISSN16577663
108
equipodetrabajo,másconocedoresdeldominiodelsistema,
revisanladescripciónresultantehastaelmomento.
Elsegundobloque,generaciónyrevisióndecasosdeprueba,
conllevalarealizaciónde8actividades:1)deladescripciónde
losrequisitossegeneranlosdiagramascausaefecto,queluego
setraducenatablasdedecisiónenlasqueseincluyencausas,
efectos y posi bles combinaci on es; cada conjunto de
combinacionesseconstituyeenunpotencialcasodeprueba;
2)sehaceunaverificacióndeconsistenciadelprocesohastael
momento;3)losingenierosderequisitoshaceunarevisiónde
los casos de prueba generados; 4) los casos de prueba son
revisadosporlosusuarios;5)losdesarrolladoresrevisanlos
casosdeprueba;6)sobreelmodelodeldiseñodelsistemase
revisanloscasosdeprueba;7)lascasosdepruebasonrevisados
sobreelcódigo;8)seejecutanloscasosdeprueba.
Lapropuesta,aunqueextensa,noofreceunadocumentación
adecuada ac erca de los product os que se generan en cada
actividad,loqueimposibilitasuaplicaciónsinelapoyodesu
propiaherramienta;elprocesoparatraducirrequisitosalmodelo
causaefectonoestádocumentado;notieneincluidaninguna
plantilla,nipropuestaformaldealgunapararedactarrequisitos;
laactividadenlacualsehacelarevisióndelasambigüedades
se describe muy pobremente y, debido a que se realiza por
personas, ti ende a n o ser verdader ament e objetiva en su
resultado; la ausencia d e métodos formales imposibilita su
automatiza ción; no se encuentran referencias a casos de
aplica ción ni de éxi to; los ejemplos confunden en vez de
clarificar;seduplicaunprocesoyaqueeldiagramacausaefecto
ylatablascontienenlamismainformación;ladocumentación
delosprocesosdeaplicaciónesmuypobre.
Ofrecelasventajasdecontarconunaherramientadesoporte
y de detal lar cómo se p ueden int egrar l as actividades d e
generacióndecasosdepruebaenunprocesodedesarrollo.
3.5 Use case derived test cases[26]
Estapropuestapartedeuncasodeusodescritoenlenguaje
naturaleindicatodalainformaciónquedebecontenernombre,
descripción,requisitos,preyposcondiciones,flujodeeventos
,yentregaunconjuntodecasosdepruebatambiéndescritos
enlenguajenatural,que definelasaccionesyverificaciones
querealizaenelsistema.Elprocedimientoconsisteenidentificar
loscaminosdeejecución,quesontodosloscaminosposibles,
apartirdelflujodeeventosdecadacasodeuso;posteriormente
cadacaminoidentificadosetransformaenuncasodeprueba
descritoenlenguajenatural.
Noseencuentra una ventaja significativa respectode las
demáspropuestas;notienesuficientedocumentación;ofrece
escalabilidadnula;nodescribeclaramentecómodiferenciarlos
caminos;nodefineconclaridadelmanejodelosrequisitos;no
esposibleseleccionarloscasosdeprueba–noesaplicablea
grandessistemas;notieneunareferenciaciónsuficientemente
ampliaquelasoporte;yladescripciónenlenguajenaturalde
loscasosdeusoimposibilitasuautomatización.
3.6Testing from use cases using path analysis technique[27]
Estapropuestapartedeuncasodeusoquesedescribeen
lenguajenatural,desdeelcualseelaboraundiagramadeflujo
con los pos ibles cam inos que deben ser probad os par a
recorr erlo. Esos camin os deben ser ana lizados para l uego
asignarl es una puntuación de acuerdo a su i mportancia y
frecuencia;estándescritosenlenguajenaturalsinadoptaruna
presentac ión formal izada; los caminos mejor evaluados se
conviertenenloscasosdepruebaaaplicar,representadosen
undiagramadeflujo.Puedeexistirmásdeuncasodeprueba
probandounmismocamino,yaqueesnecesarioañadirlevalores
depruebaacadauno.
Estapropuestanoindicacómodescribirloscasosdeuso,ni
utilizareglasparahacerlo,perosíindicacuáleslainformación
quedebeincluirsealredactarlos;además,elanálisis de los
atributosnoestádemarcadoyesposiblehacerloconcuántos
sedesee,tampocoindicacómorealizarlapuntuacióndelos
mismos;nodetallacómoaplicarloscasosdeprueba,nicuál
seráelposibleresultadoquesealcanceosuestructura.
El proc eso q ue d escribe l a pr opuest a e s sen cil lo y
relativamentefácildeimplementar;laformadecómodescartar
caminos que no aportan a la pr ueba está bien descrita; es
posi ble probar el comporta miento de ca da caso de uso
seleccionadodeformamuycompleta,eincluyeunejemplopaso
apasodeaplicación.Pero,noreferenciaproyectosrealesen
losquesehayaaplicado;elusodeunlenguajenaturalpara
describircasitodoelprocesodapieparaambigüedadesyse
convierteenunproblemaalmomentodeautomatizarlaspruebas;
siuncasodeusoesdependientedeotro,noestádocumentado
comoprobarlo;aunquees una propuestasencilla,es difícil
estructurarlaparaaplicarensistemascomplejos.
3.7 Requirements by contract[28]
La propu esta par te de un diagr ama de casos d eu so en
notación UMLy propone cuatro criterios por medio de los
cualesesposiblerecorrerelmodeloparaobtenerloscasosde
prueba.Seencuentradivididaendosmomentos,enelprimero
sehaceunaextensióndeloscasosdeusoUMLmedianteun
lengu aje de contratos que i ncluye pre y poscondiciones –
expresadasmedianteproposicionesysusparámetros,queen
conjuntopermitenexpresarlasdependenciasexistentesentre
los casos de uso; en el segundo momen to se det alla la
generaciónautomáticadeloscasosdepruebadesdelaextensión
deloscasosdeuso.Comoresultadoseobtieneunmodelode
casos de uso ext endido con contratos expresados como
caminosquerecorrenlaejecucióndelassecuenciasdecasos
deusoquesatisfacenlaspreyposcondiciones,yunconjunto
decasosdepruebaparaverificarlaimplementacióndelmodelo
Análisiscríticoalaspropuestasparagenerarcasosdepruebadesdeloscasosdeusoparalaspruebasfuncionales
– Serna&Arango
109
quegenera.Estemodeloseexpresaenundiagramaquerefleja
el comportamiento del sistem a según los ca sos de uso
diseñados.Elestadodelsistemaserepresentaporcadanodo
delmodelo–determinadoporlasproposiciones,ylasinstancias
serepresentanporcadatransición.
No detalla cómo generar los casos de prueba desde las
instancias por medio delas herramientas de generación de
pru ebas; ad emás, no es p osible des arro llar prueba s que
verifiquenaisladamente el comportamientodecadacasode
uso; los casos de uso se extienden sin respetar el están dar
UML;nohayformadesaberelnúmerodeparámetrosquedebe
utilizarcadacasodeuso,ynoseencuentraunareferenciade
cómoimplementarlaspruebas.
Sufortalezasereflejaenladiversidaddecriteriosdecobertura
ysuherramientaexperimentaldesoporte–delibredescarga;
laspruebassepuedengenerardesdelasecuenciadecasosde
uso;loscontratossonmuyflexiblesparaexpresardependencias
entr e los casos de uso. El m ismo equipo de investigación
publicóuntrabajoenelquedescribencómoaplicarlaenuna
familiadeproductosdesoftware[29].
3.8 Category partition method [30], [31]
Describecómogenerarloscasosdepruebapartiendodelos
casosdeusodeunafamiliadeproductos[32],yextiendela
notación de esos casos de uso mediante una plantilla en
lenguajenatural[10],quecontienelascaracterísticascomunes
alosproductosdelafamilia,lomismoquelospuntosenque
cada prod ucto varía de l os demás. Este pr oceso es un a
adaptacióndelpropuestoporOstrandyBalcer[33]yactualizado
paratrabajarconespecificacionesdefamiliadeproductosque
sepuedenmodelarmediantecasosdeuso.
Elprocesocomienzaconlarepresentacióndeloscasosde
usodelsistema;sedeterminanlosrequisitosfuncionalesylos
rangosdedatosquecadauno podríatomar–lo realizan los
encargadosde laspruebasconbaseen el conocimiento del
sistemaysuexperiencia;sedeterminanlasrestriccionesen
cadaunodelosrangosquegenerenerroresyquereduzcanel
númerodecasosdeprueba;seredactanlasespecificaciones
delaprueba, queesundocumentoen elquesedescribela
plantillaconlainformaciónrecolectadaenlospasosanteriores;
se gen era el cont exto de l a prueba , que con siste en una
combinacióndelosvaloresencontradosenlosrangosdedatos;
setraduceesacombinacióndevaloresaunlenguajeejecutable
ysereúnenaleatoriamenteparaejecutarseenelsistema.
Elresultadofinaldelapropuestaesunconjuntodecasosde
pruebaespecíficoparacadaproductoyelconjuntodecasosde
pruebacomúnparalosproductosdelafamilia.Estoscasosde
pruebasedescribendeformaabstracta,porloquedebenrefinarse
paraobtenercasosdepruebaposiblesdeejecutarenelsistema.
Originalmentefueunapropuestadelosaños80 diseñada
parafamiliasdeproductos,perosuenfoqueymadurezpermite
considerarlaparaaplicaciónenlossistemasdehoy;además,
puedediseñarseparaaplicarensistemasquenopertenecena
unafamiliaespecífica.Aunqueesunapropuestamediantela
cualesposiblegenerarconjuntosdevaloresparalaspruebas,
muchosdelospasospresentanambigüedadensudefinición,
yaquequedansupeditadosalaexperienciayconocimientodel
sistemaporpartedelequipodepruebas,porloquelainformación
acerca de la cobertur ade las pruebas tampoco se ofrece
adecuadamente;no esposiblesuautomatizacióntotal, yno
referenciaunaherramientaquelasoporte.
Lapropuestadescribeunejemploprácticodeaplicación,es
posibleverificarel comportamientodeloscasosdeuso, así
comosudependenciaconotroscasosdeuso;sepuedeaplicar
desdecomienzosdelprocesodelproyecto,ytambiénreduceel
número de casos de pr ueba gen erados a través de las
restriccionesquetieneencuenta.
3.9 Requirements to testing in a natural way [34]
Segúnsusautores,esunanalizadorderequisitosquepuede
serutilizadoparagenerarpruebasdecajablancaycajanegra;
estáconformadapor6actividadesdividasendosbloquesEl
primerbloqueloconforman5actividades:1)seredactanlos
requisitosenlenguajenaturalyenpárrafosestructurados;2)
se hace una identificación de cada frase en los párrafos de
descripción de los casos de uso; 3) desde cada una de las
fra ses se g enera un árbol sintá ctico con sus respect ivas
anotaciones;4)apartirdecadaárbolseobtienelaestructurade
representación del discurso [35], en la que se identifica la
semánticadecadaelementodelárbol;5)serefinaestaestructura
yseeliminanlasambigüedadesexistentes,luegosetraduce
automáticamenteallenguajeMONA[36],conloquesegenera
unamáquinadeestadosfinitos.
Enelsegundobloqueserecorrelamáquinadeestadosfinitos
paragenerarloscasosdeprueba.Seofrecelaposibilidadde
recorrerlamáquinadedistintasformas,porloqueesposible
obtener va rios conjuntos de casos de pr ueba que genera n
explosióndelosmismos.Paraevitarestolapropuestapropone
preguntaralusuarioporlosrequisitoscríticos,yluegoreducir
losrecorridosaellos.
Aunque es una p ropuesta bien document ada, no incluye
ejemplos de las pruebas genera das, ni cómo se recorren y
obtienen las pruebas a partir de la máquina de estados; al
construirelárbolsintácticonoesposibleclarificarentreverbos,
sujetosyotros componentesde las frasesquedescriben los
casos de uso; no explica si es necesario recorrer mediante
pruebastodaslasfrasesdeladescripcióndelcasodeuso.
Suprincipalventajaesserdelaspocasquedetallaunmétodo
paraprocesarrequisitosdescritosenlenguajenatural,loque
permiteautomatizarlageneracióndelaspruebas;aunquenose
encontróuncasoprácticodeaplicación,existenherramientas
libresquepermitenautomatizarpartedelasactividadesy,para
RevistaAvancesenSistemaseInformática,Vol.7No.2,juliode2010ISSN16577663
110
lasotras,existenherramientasdesarrolladasporlosmismos
autores,peroalasquenoesposibleacceder,porloquenofue
posibleverificarsuaplicaciónpráctica
3.10 A model-based approach to improve system testing
of interactive applications [37]
Estapropuestatienesuorigenenlasinvestigacionesdela
empresaSiemens,lascualesrecopilayamplíaRuder[38].Parte
deladocumentaciónenlenguajeformaldeloscasosdeuso,y
como resultado de su aplicación se obtiene el conjunto de
pruebasparalainterfazgráficadelsistema.
Lospasossonlossiguientes:1)semodelaelcomportamiento
delsistemamediante undiagramadeactividadesUMLque
describe el comportamiento in terno de los casos de uso, y
especificalosrequisitosdeprueba–conjuntodeestereotipos
que permiten interpretar cada actividad; estos estereotipos
indicanlapertenenciadelasactividadesdelusuario,delsistema
uotrodiagramadeactividades,yseinterpretanparaconstruir
pruebasejecutablesporelgeneradordepruebas;2)sediseñan
loscasosdepruebamediante
scripts
de prueba,que son la
descripcióndelosdiagramasdeactividadesenlenguajeTSL–
TestSpecificationLanguage[39];luego,medianteTDETest
DevelopmentEnvironment[38]setraducedeTSLaguiones
deprueba,conloqueobtieneunconjuntode
scripts
quepueden
ejecutarse en una herramienta de verificación de interfaces
gráficas;3)luegodeconstruirelconjuntodeguiones,esposible
ejecutarlossobreelsistemaqueseestáprobando,procesoque
refinaymejoralosmismos
scripts
amedidaqueseejecutan.
Estapropuestaesdelas pocasquedescribecómogenerar
pruebasejecutables;utilizalenguajeformalque,unidoaluso
de
scripts
med iante est ereot ipos es calables, facilita su
automatización.Susinconvenientessereflejanenquesecentra
enlainterfazgráfica,imposibilitandosuaplicaciónenotras
interfaces;elprocesodecómoseobtienenlosdiagramasde
actividadesdesdeloscasosdeusonosedetallalosuficiente,
lomismoquecómoseasignalosestereotiposacadaactividad;
noespecificasielprocesodepasarlosdiagramadeactividades
aTSLdebehacersemanualosiesautomatizable;noesclarosi
serequiereunsolodiagramadeactividadesparatodoelproceso
oesnecesariodiseñarunoporcadacasodeuso;losdiagramas
deactividadesdecadacasodeusoaparecenindependientesy
nosedetallaquéhacerconlasrelacionesentreellos;nose
encuentraunaherramientaquepermitaaplicarlapropuestaen
unambientedelaboratorioodeevaluación.
I V. C O NC LU SI ON E S
• Probarunsistemadesdelaópticadelaspruebasfuncionales
esverificarquesehanimplementadobienlosrequisitosde
la especificac ión funcional , por lo qu e éstos deben
constituirseenlabasesobrelaquesediseñanloscasosde
pruebadelsistema.
• Diseñar el modelo del sistema teniendo como base su
especificaciónfuncionalesunatareaenlaqueseconstruye
unmodeloformalosemiformal,quedebeexpresarloque
seesperadelcomportamientodelsistemadeacuerdocon
los datos recogidos en los requisitos. Dado que la base
sobre la que sediseña son los requisitos expresados en
lenguaje n a t u r a l , el proceso no p uede r ealizarse
automáticamen te pero sí sistemát icamente, mediante el
seguimientodepasosyfasesdefinidosconclaridad.
• Luegodel diseño,en laaplicación dela coberturadela
prueba,esnecesarioseleccionaruncriteriomedianteelcual
sepuedangenerarloscasosdepruebaqueposteriormente
seaplicaránaldiseñodelmodelo.Enesteanálisiselcriterio
quetienemásacogidaentrelaspropuestaseseldetodos
losposiblescaminos deejecución;aunque existen otros
criteriosquetambiénsonviablesy,que aligual que los
analizados,puedenrealizarseautomáticamenteutilizando
unaherramientasoftware.
• Otracaracterísticadelaspropuestasanalizadasesquelos
valoresdelosdatosdeentradaalsistemahacenpartedel
procesode prueba, por lo que cualquier propuesta debe
tenerencuentacómogenerarlos.Paraestecasoeseproceso
debedescribirsemásdetalladamente,yaqueladescripción
esmuypobreenlamayoríadelaspropuestas.
• Losresultadosesperadossonunelementoimprescindible
en la descripción de las propuestas de este análisis, y
consiste en poder determinar cuál será la respuesta del
sistema a la ejecución del conjunto de casosde pr ueba
seleccionado;estosresultadosseobtienenluegodeaplicar
automáticamentelaspruebasaunasimulacióndelmodelo
delsistema.Enesteanálisis,unporcentajemuypequeñose
ocupadeestetemayparecenoserlesdeutilidadparadiseñar
elconjuntodecasosdeprueba.
• Elpasofinalenlosprocesodepruebaanalizadoseselde
ejecutarloscasosdepruebasobreelsistemaobjeto,pero
ning una de las p ropues tas ofr ece el d etall e de cómo
generarlo medianteun formalismoquepueda traducirse
fácilmenteacódigo,porelcontrario,lamayoríadescriben
cómotraducirlosalenguajenatural.
V.ASP EC TO S PARA TE NER EN C UE NTA E NT RABA JO S
FUT U R O S
Elanálisisefectuadoalaspropuestasparadiseñarcasosde
pruebaapartirdelaespecificaciónfuncional,sustentalafaltade
untrabajomásprofundoenprocuradehallarunapropuestacon
másintegración,yquedebedesarrollarseapartirdelosiguiente:
Análisiscríticoalaspropuestasparagenerarcasosdepruebadesdeloscasosdeusoparalaspruebasfuncionales
– Serna&Arango
111
• Lospuntoscomunesdelaspropuestasqueseanalizanen
estedocumento,comoson:obtenerunconjuntodecasos
depruebaquedealgunamaneragaranticequeelsistema
cumpleconlasespecificacionesfuncionales;partirdelos
requisitosfuncionales para generar loscasosdeprueba;
utilizarelanálisisdecaminosoestadosposibles;teneren
cuentaque losrequisitosfuncionales necesariamenteno
cum plen requisitos form ales –lenguaje natur al para
comenzar;generarelconjuntodecasosdepruebademanera
automática y sistemática a par tir de los requisitos
funcionales,mediantealgunaherramientasoftware,yvalidar
los requisitos funcionales d esde las pri mera sfa ses del
desarrollo.Estospuntosdebenserlabasedesdelaquese
puedan corregir las falencias en las encontradas y para
potenciarsusfortalezasenelnuevoproyecto.
• Enloquerespectaalmodelodecomportamientodelsistema
sedebeidentificarclaramentecuáleslainformaciónque,
contenidaenlaespecificaciónfuncional,permitagenerarlo
yluegoobtenerloscasosdeprueba.
• Debe diseñarse y describirse una plantilla en la que se
estandariceladescripcióndelosrequisitosfuncionalesen
lenguajenatural,paraloquesepuedepensarenutilizaruna
preexistentecomolaquedescribe[10]oendesarrollarotra.
• Dado que los casos de uso no son fijos, debe detallarse
cuáleselgradoderefinamientonecesarioparagenerarlos
casosdeprueba;mirarporejemploelrefinamientopropuesto
porDustinetal[40].
• Paraobtenerunapropuestamásrobustaesnecesarioincluir,
ademásde losfuncionales,otrotipo de requisitoscomo
losdealmacenamiento;yaquelosvaloresdesalida son
tanimportantesenlarealizacióndelaprueba,conestos
requisitosesposibledarlemayorcoberturayeficaciaalos
casosde prueba.
• Enlaspropuestasanalizadassetrabajaconunúnicomodelo
delsistemaenlageneracióndeloscasosdeuso,loquecrea
dificultadesparaanalizarlasinteraccionesentreéstos;poder
contarconmodelosalternososubmodelosbasadosenun
diagramadeestados,facilitaelanálisisdelcomportamiento
delsistemadesdelaespecificaciónfuncional.
• Otroasuntoimportanteeselrelacionadoconelcriteriode
cobertura,yenespecialeldecómoutilizarlaprioridadde
loscasosde usoal momentodegenerar interaccioneso
secuencias;puedentenerseencuentaalgunaspropuestas
desdelaingenieríaderequisitos,comoladeRobinson[41],
Riebischetal[42]yladeEscalona[43].
• Enloquerespectaalosvaloresdeprueba,debediseñarse
unconjuntodereglasconcretoysistemáticoquepermita
reducirelnúmerodedecisionesquetomanlosprobadores,
alocualayudaráloyaexpuestodeincluirelprocesolos
requisitosdealmacenamiento.
• Elnúmerodepruebasaejecutarporcadaescenarioposible
deaplicaciónesunacuestiónfundamentalcuandosehace
análisisdecaminos,parasolucionarloesconvenientepensar
enunconjuntoconcretodevaloresygenerarunescenario
depruebaporcadacombinaciónposible.
• Esnecesariorecurriraloslenguajesformalesparaexpresar
los escen arios de pru eba, ya que con éstos es posible
generar automáticamente loscasosde prueba; para esta
tareaesconvenienterevisartrabajoscomolosdeClarke
andWing[44],Lamsweerde[45],Juristoetal [46],Clermont
andParnas[47],Beckertetal[48],DassoandFunes[49]y
Kaner[50].Estaformadetrabajopermitirácuantificarel
gradodecoberturadelapruebadeformaautomatizada,lo
quealejalatomadedecisionesdelactorhumano.
• Validarelconjuntodecasosdepruebageneradodebeser
unametaenlanuevapropuesta,porejemplomediantela
coberturadelosrequisitos,silacoberturaesladeseadael
conjuntoesválido.
• Esnecesariocontemplarlaposibilidaddeautomatizarcada
una de las acti vidades en el proceso de generación del
conjuntodecasosdeprueba;estametadebeconsiderarse
prioritariamenteyaqueesunafalenciaquerestacredibilidad
y eficacia a las analizadas. Igualmente importan te es
considerarla posibilidaddegenerar unaherramientade
soportealapropuesta,detalmaneraqueseaposibleaplicarla
atrabajosrealesyensituacionesreales.
RE FER E NC IAS
[1] Kamde,P. M.,Nandavadekar,V.D. andPawar, R. G.,2006.
Valueoftestcasesinsoftwaretesting.ManagementofInnovation
andTechnology,Vol.2, pp.668672.
[2] Leon, D ., Masri, W. and P odgurski A., 2007 .An em pirical
evaluation of testcase filtering techniques based on exercising
comp lex informa tion flow s. IEEE Transa ctions on Softw are
Engineering,Vol.33,No.7,pp.454477.
[3] Lewis,W. E., 2000. Software testing and continuous qu ality
improvement.Florida:CRCPress.657 P.
[4] Sinha,P.andSuriN.1999. Identificationoftestcasesusinga
for mal app roach . Pr oceed ings of the Twe ntyN inth Ann ual
InternationalSymposiumonFaultTolerantComputing.Madison,
Wisconsin, USA,p p.314 321.
[5] Pres sman, R. , 2005 .S oftware e ngineerin g:a pr actitioner ’s
approach.NewYork:McGrawHill.958 P.
[6] Beiz er, B., 19 90. Softwar e testing techn iques. New York:
InternationalThomsonComputer Press.470 P.
[7] Myers, G. J., 1 979. Th ear t ofso ftware testing. N ew York :
Wileyinterscience.255 P.
[8] Myers,G.J .,200 3. Principles offun ctional verification. New
York:Newnes.217P.
[9] Fröhlich,P.andLink,J.,2000.Automatedtestcasegeneration
fromdynamicmodels.LectureNotes in Computer Science,Vol.
1850,pp.472491.
[10] Cockburn,A., 2000.WritingEffectiveusecases. New York:
AddisonWesley.249 P.
RevistaAvancesenSistemaseInformática,Vol.7No.2,juliode2010ISSN16577663
112
[11] Fröhlich,P.andLink,P.,1999.ModelingDynamicBehaviour
Based onUse Cases. 3rd InternationalSoftwareQualityWeek
EuropeQWE. Brussels,Belgium,Paper9A.
[12] Fikes,R.E.andNilsson,N.J.,1971.STRIPS:anewapproach
totheapplicationoftheoremprovingtoproblemsolving.Artificial
Intelligence,Vol.2,No.34,pp.189208.
[13] Hu gge r, J. , 2 001 . Wellpo sedn ess of t he b oun dary v alu e
formulation of a fixed strike Asian option. Jou rnal of
Computationa l and Applied Mathematics, Vol.1 85, No. 2, pp.
460481.
[14] Copeland,L.,2004.Apractitioner’sguidetosoftwaretestdesign.
Londres:ArtechHouse.294 P.
[15] Myers,G.J.,2004.Theartofsoftwaretesting.NewYork:John
Wiley&Sons.255P.
[16] Schroeder,P.J. and Korel,B.,2000.Blackboxtestreduction
usin g inpu toutput analysis. th e 2000 ACM S IGSO FT
InternationalSymposiumonSoftwareTestingandAnalysis.New
York,NY,USA,pp.173177.
[17] McGee,P.andKaner,C.,2004.Experimentswithhighvolume
testautomation.SIGSOFTSoftwareEngineeringNotes,Vol.29,
No.5, pp.13.
[18] Hieron s, R. M., 20 06. Avoidin g coincidental correc tness in
bou nd ary v alu e an alys is. AC M Tr ans act ion s on Sof tw are
EngineeringandMethodology,Vol.15, No.3,pp.227241.
[19] Kris hn an, R ., K rishn a S. M. a nd N andh an , P. S., 200 7.
Combinatorialtesting:learningsfrom ourexperience.SIGSOFT
SoftwareEngineeringNotes,Vol.32,No.3,pp.18.
[20] Tuya, J., Dolado,J .,Su arezCabal, M. J. andde la Riva, C.,
200 8.A controlled experiment on whitebox database testing.
SIGSOFTSoftwareEngineeringNotes,Vol.33, No.1,pp.16.
[21] Masri,W.AbouAssi,R.ElGhali,M.andAlFatairi,N.,2009.
Anempiricalstudyofthefactorsthatreducethe effectivenessof
coveragebasedfaultlocalization.2ndinternationalWorkshopon
DefectsinLargeSoftwareSystems:HeldinConjunctionwiththe
ACM SIGSOFT international Symposium on Software Testing
andAnalysis,New York,NY,USA,pp.15.
[22] Heumann,J.,2002.Generatingtestcasesfromusecases.Journal
ofSoftwareTestingProfessionalsTheRationalEdge,September
Issue,pp. 314.
[23] Mog yorodi , G. E ., 20 01 . Re quire men tsba sed te sting : an
over view. 39th Intern ationa lC onference and Exh ibition on
Technologyof ObjectOriented Languages andSystems. Santa
BarbaraCA,USA,pp. 286295.
[24] Mogyorodi,G.E.2002.Requirementsbasedtesting:ambiguity
reviews. Jour nal ofSof tware Testing Profession als, December
Issue,pp.2124. 2002.
[25] Mogyorodi,G.E.,2003.What is requirementsbasedtesting?
Crosstalk:TheJournalofDefenseSoftwareEngineering,Vol.16,
No.3, pp.1215.
[26] Wood,D.andReis,J.,2002.Usecasederivedtestcases.Software
QualityE ngineering forSoftware TestingAnalysisand Review,
Memories, pp. 235244.
[27] Naresh, A., 2002. Testing from usec ases using patha nalysis
technique.InternationalConferenceOnSoftwareTestingAnalysis
&Review.WashingtonD.C.,USA,pp.237252.
[28] Nebu t, C., Fleurey, F. , Le, T. Y. and Jé zéquel, JM ., 2003 .
Requirements bycontract allowautomated systemtesting. 14th
Intern ational symposium of S oftware Reliability Engine ering,
Memories, pp. 121131.
[29] Nebut, C. Fleurey, F., Le, T. Y. and Jézéqu el,J M.,20 04. A
requirementbased approach to test productfamilies. Frank van
derLinden,Vol.30,No.14,pp.198210.
[30] Bertolino,A. andGn esi, S., 2003. Use Casebasedtesting of
productlines.ACMSIGSOFTSoftwareEngineeringNotes,Vol.
28,No.5,pp.355358.
[31] Bertolino,A.andGnesi,S.,2004.PLUTO:Atestmethodology
forproductfamilies.LectureNotesinComputerScience,Vol.30,
No.14,pp.181197.
[32] Bertolino,A.,Fantechi,A.,Gnesi,S.,Lami,G.andMaccari,A.,
200 2. Use case description of requir ements for product lines.
REPL’02,Essen, Germany,AvayaLabsTech,pp.1218.
[33] Ostrand,T.J. and Balcer,M.J., 1988. Thecategorypartition
method for specifying and generating function al tes ts.
ComunicationsoftheACM,Vol.31,No.6,pp.676686.
[34] Boddu, R. Guo, L.,Mu khopadhyay, S.and Cuk ic, B., 2004.
RETN A:fr om requiremen ts to testing in a natu ralw ay. 12th
IEEEInternationalRequirementsEngineeringConference.Kyoto,
Japan,pp. 262271.
[35] Blac kburn, P. a nd Bos, J., 1 994 . Work ing with disco urse
rep resen tat ion th eory: a n adv ance cour se in c ompu tati onal
semantics.California:StanfordCSLIPublications.254 P.
[36] Henriksen,J.G.,Jensen,J.,Jrgensen,M.,Klarlund,N.,Paige,
R.,Rauhe,T.andSandholm,A.,1995.MONA:Monadicsecond
orderlogininpractice.ToolsandAlgorithmsfortheConstruction
andAnalysis of Systems,Warsaw, Poland,pp. 1019.
[37] Hartmann,J.,Vieira,M.,Foster,H.andRuder,A.,2004.UML
basedtestgenerationandexecution.ProceedingsofWorkshopon
SoftwareTest,AnalysesandVerification.Banff,AB,Canada,pp.
234241.
[38] Ruder, A.,2 004. UMLbased test gen eration and execution.
SiemensCorporateResearchInc.Berlin,Germany,whitepaper.
[39] Balcer, M ., Haslin g,W. an dO stran d, T., 1 990. Auto matic
generation of test scripts from formal test specifications.ACM
SIGSOFTSoftwareEngineeringNotes,Vol.14,No.8,pp.210
218.
[40] Dustin,E.,Rashka,J. and McDiarmid,D.,2002. QualityWeb
systems. NewYork:AddisonWesley.352 p.
[41] Robinson,H.,2000.Intelligenttestautomation.SoftwareTesting
&QualityEngineering,Vol.2,No.5,pp.2432.
[42] Riebisch, M., Philippow, I.and Ilmenau ,M. G. 2003. UM L
basedstatisticaltestcasegeneration.LectureNotesinComputer
Science,Vol.2591,pp.394411.
[43] Escalona,M.J.,2004.Modelosytécnicasparalaespecificación
yel análisisde la navegación en sistemassoftware.TésisPhD.
Departamentodecomputación,lenguajesysistemas.Universidad
deSevilla.España.
[44] Clarke,E.M.andWing,J.M.,1996.Formalmethods:stateof
theartand futuredirections.ACMComputingSurveys,Vol.28,
No.4, pp.626–643.
[45] van Lamsweerde,A., 2000. Formalspecification:a roadmap.
Conference on The Future of Software Engineering. Limerick,
Ireland,pp. 147159.
[46] Juriso,N.,Moreno,A.andVegas,S.,2004.Reviewing25years
oftestingtechniqueexperiments.EmpiricalSoftwareEngineering,
Vol.9,No.12,pp.744.
[47] Clermont,M.andParnas,D.,2005.Usinginformationaboutfunctions
inselectingtestcases.1stInternationalWorkshoponAdvancesinModel
BasedTesting.St.Louis,Missouri,USA,pp.17.
[48] Beckert, B., Hoare,T., Hahnle, R., Smith, D. R., Green, C.,
Análisiscríticoalaspropuestasparagenerarcasosdepruebadesdeloscasosdeusoparalaspruebasfuncionales
– Serna&Arango
113
Ranise,S.,Tinelli,C.,Ball,T.andRajamani,S.K.,2006.Intelligent
system s and f ormal me thods in softw are engin eering. IEEE
IntelligentSystems,Vol.21, No. 6,pp. 7181.
[49] Dasso,A.andFunes,A.,2007.Verification,validationandtesting
insoftwareengineering.NewYork:IdeaGroupPublishing.443P.
[50] Kaner,C.,2003.WhatIsa GoodTestCase?STAREast2003.
Orlando,FL,USA,pp. 7692.
RevistaAvancesenSistemaseInformática,Vol.7No.2,juliode2010ISSN16577663
114