Content uploaded by Edgar Serna M.
Author content
All content in this area was uploaded by Edgar Serna M.
Content may be subject to copyright.
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