TÉCNICAS DE PRUEBAS DE SOFTWARE
Profesora: Luisana Parejo Integrantes: Leoar!s Fern"n#e$ %os& A' (en#o$a )anessa (ar*ue$
Cumaná, Abril del 2016
+,u& son -as Prue.as #e Soft/are0
Las Las prueb pruebas as son son básic básicame ament nte e un conju conjunt nto o de activ activida idades des dentr dentro o del del desarrollo de software. Dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualuier momento de dic!o proceso de desarrollo. "#isten distintos modelos de desarrollo de software, as$ como modelos de pruebas. A cada uno uno corre corresp spond onde e un nivel nivel distin distinto to de involu involucr crami amient ento o en las activ activida idade des s de desarrollo. %n proceso de pruebas formal, está compuesto, cuando menos por las si&uientes ' t$picas etapas( 1. )lan )lanea eaci* ci*n n de prue pruebas bas.. 2. Dise Dise+o +o de de prue prueba bas. s. . imple implemen menta taci* ci*n n de prueb pruebas. as. -. "valuac "valuaci*n i*n de de criter criterios ios de de salida salida.. '. Cierr Cierre e del del proce proceso so..
1' PP-an anea ea2i 2i3n 3n #e #e Prue Prue.a .as' s' "s la etapa en donde se ejecutan las primeras actividades correspondientes al proceso de pruebas pruebas tiene como resultado resultado un entre&able denominado denominado plan de pruebas pruebas el cual cual debe debe estar estar conform conformado ado en cuando cuando menos por aspectos aspectos tales tales como( •
determina a ue funciona funcionalida lidades des del producto producto /o A-2an2e #e -a 4rue.a: determin software serán probadas durante el transcurso de la prueba. "ste listado de func funcion ionali alida dades des a proba probarr se e#trae e#trae con base base a un análi análisis sis de ries& ries&os os realiado de manera previa, ue tienen en cuenta variables tales como el impacto ue podr$a ocasionar la falla de una funcionalidad funcionalidad la probabilidad de falla falla de una funcionali funcionalidad. dad. )roducto )roducto de este este análisis, análisis, se cuenta cuenta con informaci*n adicional ue permite determinar además del alcance detallado
del proceso de pruebas, la prioridad con la ue las funcionalidades deben probarse la profundidad de las pruebas. •
Ti4os #e Prue.a: en este punto se debe determinar u tipos de pruebas reuerir$a el producto. o todos los productos de software reuieren la aplicaci*n de todos los tipos de pruebas ue e#isten, por esta ra*n, es estrictamente necesario ue el l$der de pruebas se plantee pre&untas ue le permitan determinar u tipos de prueba son aplicables al proecto en evaluaci*n. Los posibles tipos de prueba a aplicar son( pruebas de stress, pruebas de rendimiento, pruebas de car&a, pruebas funcionales, pruebas de usabilidad, pruebas de re&resi*n, entre otros.
•
Estrategia #e Prue.as: teniendo en cuenta ue no es viable probar con base a todas las posibles combinaciones de datos, es necesario determinar a travs de un análisis de ries&os sobre ue funcionalidades debemos centrar nuestra atenci*n. Adicionalmente, Adicionalmente, una buena estrate&ia de pruebas debe indicar los niveles de pruebas 3ciclos4 3ciclos4 ue aplicaremos aplicaremos la intensidad o profundidad profundidad a aplicar para cada nivel nivel de pruebas definido. definido. "n este punto tamb tambi in n es impo import rtan ante te defi defini nirr los los crit criter erio ios s de entr entrad ada a sali salida da para para cada ciclo de pruebas a ejecutar.
•
Criterios #e Sa-i#a: entre las partes involucradas en el proceso, se define de manera formal, formal, bajo u condiciones condiciones se puede considera considerarr ue una actividad actividad de pruebas fue finaliada. finaliada. Los criterios de salida salida se deben definir para cada cada nivel de pruebas pruebas a ejecutar. ejecutar. Al&unos Al&unos ejemplos ejemplos de criterios criterios de salida ue pueden ser utiliados son( porcentaje de funcionalidades funcionalidades de alto ries ries&o &o prob probad adas as con con #it #ito, o, n5me n5mero ro defe defect ctos os cr$t cr$tic icos os /o /o mao maore res s aceptados, etc.
•
Otros as4e2tos: tal como se realia en cualuier plan de proecto, se debe incluir una estimaci*n de tiempos, los roles /o recursos ue !arán parte del proceso, la preparaci*n del entorno de pruebas, crono&rama base, etc.
5' Di Dise se6o 6o #e Pr Prue ue.a .as' s' %na ve elaborad elaborado o aproba aprobado do el plan de pruebas, pruebas, el euipo euipo de trabajo trabajo debe debe inici iniciar ar el análi análisis sis de toda toda la docu documen menta taci ci*n *n e#ist e#isten ente te con con resp respec ecto to al sistema, con el objeto de iniciar el dise+o de los casos de prueba. Los entre&ables claves para para iniciar este dise+o dise+o pueden ser( casos casos de uso, !istorias !istorias de de usuario, usuario, aruitec aruitectura tura del sistema, sistema, dise+os dise+os,, manuales manuales de usuario usuario 3si e#isten4 e#isten4,, manuale manuales s tcnicos 3si e#isten4. e#isten4. "l dise+o dise+o de los los casos, debe considerar considerar la elaboraci*n elaboraci*n de casos casos positiv positivos os ne&ativ ne&ativos. os. Los casos casos de prueba prueba ne&ativ ne&ativos os permiten permiten validar validar c*mo c*mo se compo comport rta a el siste sistema ma ante ante situa situaci cione ones s at$pic at$picas as permi permite te verif verifica icarr la robus robuste te del del siste sistema, ma, atrib atributo uto ue ue consti constitu tue e unos unos de los reu reueri erimie mient ntos os no funciona funcionales les indispens indispensabl able e para para cualui cualuier er software. software. )or 5ltimo, 5ltimo, es necesario necesario definir cuáles cuáles son los datos de de prueba necesarios necesarios para la ejecuci*n ejecuci*n de los los casos de prueba dise+ados.
7' I4 I4-e -eent enta2i a2i3n 3n ! Eje2u2i3 Eje2u2i3n n #e Prue.as' Prue.as' La ejecuci*n de pruebas debe iniciar con la creaci*n de los datos de prueba necesarios para ejecutar los casos de prueba dise+ados. La ejecuci*n de estos casos, puede puede realiarse de manera manera manual o automatiada automatiada en cualuiera cualuiera de los casos, casos, cuando cuando se detecte detecte un fallo en el sistema, sistema, este debe debe ser document documentado ado re&istrado en una !erramienta ue permita &estionar los defectos 37u& 8rac9er4. %na ve el defecto !a sido corre&ido por la firma desarrolladora en su respectivo proceso de depuraci*n, es necesario realiar un re:test ue permita confirmar ue el defect defecto o fue fue soluc solucion ionad ado o de manera manera e#ito e#itosa. sa. )or 5ltim 5ltimo, o, es indis indispe pensa nsable ble ejecut ejecutar ar un ciclo ciclo de re&r re&resi esi*n *n ue ue nos nos permi permita ta &aran &aranti tiar ar,, ue los defe defecto ctos s corre&idos en el proceso de depuraci*n de la firma, no !aan desencadenado otros tipos de defectos en el sistema.
8' E9a-ua2i3n #e Criterios #e Sa-i#a' Los criterios de salida son necesarios para determinar si es posible dar por finaliado un ciclo de pruebas. )ara esto, es conveniente definir una serie de mtricas ue permitirán al finaliar un proceso de pruebas, comparar los resultados obtenidos contra las mtricas definidas, s$ los resultados obtenidos no superan la mtricas definidas, no es posible continuar con el si&uiente ciclo de pruebas. "#isten varios tipos de criterios de salida dentro de los cuales se pueden mencionar(
cubrimiento
de
funcionalidades
en
&eneral,
cubrimiento
de
funcionalidades cr$ticas para el sistema, 5mero de defectos cr$ticos maores detectados, etc. 8ambin es importante aclarar ue el proceso de pruebas puede ser suspendido /o paraliado, debido entre otros, a aspectos relacionados con el presupuesto la calidad m$nima del sistema reuerida para el inicio formal de pruebas.
' Cierre #e- 4ro2eso' Durante este periodo de cierre el cual !ist*ricamente se !a comprobado ue se le destina mu poco tiempo en la planeaci*n, se deben cerrar las incidencias reportadas, se debe verificar si los entre&ables planeados !an sido entre&ados aprobados, se deben finaliar aprobar los documentos de soporte de prueba, analiar las lecciones aprendidas para aplicar en futuros proectos, etc.
Ti4os #e 4rue.as #e soft/are' A continuaci*n se describen las principales tipos pruebas ue se pueden realiar a cualuier tipo de software(
Prue.a Unitaria' 1' O.jeti9o #e -a Prue.a' ;e focalia en ejecutar cada m*dulo 3o unidad minima a ser probada, ej < una clase4 lo ue provee un mejor modo de manejar la inte&raci*n de las unidades en componentes maores. 7usca ase&urar ue el c*di&o funciona de acuerdo con las especificaciones ue el m*dulo l*&ico es válido.
5' Des2ri42i3n #e -a Prue.a'
•
)articionar los m*dulos en pruebas en unidades l*&icas fáciles de probar.
•
)or cada unidad !a ue definir los casos de prueba 3pruebas de caja blanca4.
•
)ara esto los casos de prueba deben dise+arse de forma tal ue se recorran todos los caminos de ejecuci*n posibles dentro del c*di&o bajo prueba por lo tanto el dise+ador debe construirlos con acceso al c*di&o fuente de la unidad a probar.
•
Los aspectos a considerar son los si&uientes( =utinas de e#cepci*n, =utinas de error, >anejo de parámetros, ?alidaciones, ?alores válidos, ?alores l$mites, =an&os, >ensajes posibles.
7' T&2ni2a' •
Comparar el resultado esperado con el resultado obtenido.
•
;i e#isten errores, reportarlos.
8' Criterio #e Co4-etitu#' •
8odas las pruebas planeadas !an sido ejecutadas.
•
8odos los defectos ue se identificaron !an sido tenidos en cuenta.
' Consi#era2iones Es4e2ia-es' )ara la elaboraci*n de pruebas unitarias en java se puede utilliar el @%8 CAC8%;.
Prue.a #e Integra2i3n' 1' O.jeti9o #e -a Prue.a'
•
dentificar errores introducidos por la combinaci*n de pro&ramas probados
•
unitariamente. Determina c*mo la base de datos de prueba será car&ada. ?erificar ue las interfaces entre las entidades e#ternas 3usuarios4 las
•
• •
aplicaciones funcionan correctamente. ?erificar ue las especificaciones de dise+o sean alcanadas. Determina el enfoue para avanar desde un nivel de inte&raci*n de las componentes al si&uiente.
5' Des2ri42i3n #e -a Prue.a'
•
Describe c*mo verificar ue las interfaces entre las componentes de
• •
software funcionan correctamente. Determina c*mo la base de datos de prueba será car&ada. Determina el enfoue para avanar desde un nivel de inte&raci*n de las
•
componentes al si&uiente. Decide u acciones tomar cuando se descubren problemas.
7' T&2ni2a'
)or cada Caso de )rueba ejecutado( • •
Comparar el resultado esperado con el resultado obtenido. %tiliar la tcnica top:down. ;e empiea con los m*dulos de nivel superior, se verifica ue los m*dulos de nivel superior llaman a los de nivel inferior
•
de manera correcta, con los parámetros correctos. %tiliar la tcnica down:top. ;e empiea con los m*dulos de nivel inferior, se verifica ue los m*dulos de nivel inferior llaman a los de nivel superior de manera correcta, con los parámetros correctos.
8' Criterio #e Co4-etitu#' •
8odas las pruebas planeadas !an sido ejecutadas.
•
8odos los defectos ue se identificaron !an sido tenidos en cuenta.
' Consi#era2iones Es4e2ia-es' in&una.
Prue.a #e Regresi3n' 1' O.jeti9o #e -a Prue.a' Determinar si los cambios recientes en una parte de la aplicaci*n tienen efecto adverso en otras partes.
5' Des2ri42i3n #e -a Prue.a' "n esta prueba se vuelve a probar el sistema a la lu de los cambios realiados durante el debu&&in&, mantenimiento o desarrollo de la nueva versi*n del sistema buscando efectos adversos en otras partes.
7' T&2ni2a'
•
La prueba de re&resi*n es una nueva corrida de casos de prueba previos.
•
;e reuiere de pol$ticas para ser creada la prueba de re&resi*n decidir u casos de prueba incluir, para probar eficientemente.
•
La prueba de re&resi*n es un buen candidato para automatiaci*n. Desde ue estas pruebas se repiten una otra ve, las !erramientas para minimiar el esfuero del trabajo son 5tiles.
•
La prueba de viejas funcionalidades es más importante ue la de nuevas funcionalidades.
•
Auellos casos de uso 3 los casos de prueba asociados4 ue descubren defectos tempranamente deben ser incluidos en la prueba de re&resi*n.
8' Criterio #e Co4-etitu#'
•
8odas las pruebas planeadas !an sido ejecutadas.
•
8odos los defectos ue se identificaron !an sido tenidos en cuenta.
' Consi#era2iones Es4e2ia-es' in&una.
Prue.as #e ;uo ' 1' O.jeti9o #e Prue.a' Los objetivos son los si&uientes( •
Detectar los errores en realeases tempranos de manera fácil.
•
)robar el sistema constantemente.
Barantiar poco esfuero en la inte&raci*n final del sistema.
•
Ase&urar los resultados de las pruebas unitarias.
•
;e reducen los ries&os a baja calidad.
•
5' Des2ri42i3n #e -a Prue.a' 8oma ste nombre debido a ue su objetivo es probar el sistema constantemente buscando ue saue !umo o falle. "n al&unos proectos este tipo de prueba va junto con las pruebas funcionales. )ermite detectar problemas ue por lo re&ular no son detectados en las pruebas normales. Al&unas veces, si las )ruebas ocurren tarde en el ciclo de desarrollo está será una forma de &arantiar el buen desarrollo. Las pruebas de !umo NO SON e#!austivas, pero van de e#tremo a e#tremo de la aplicaci*n.
7' T&2ni2a'
•
=ealiar una inte&raci*n de todo el sistema cada cierto periodo 3se
•
recomienda un d$a, má#imo una semana4. =ealiar los casos de prueba asi&nados a los casos de uso finaliados ese
•
d$a más los realiados en d$as anteriores. 7uscar eficientemente errores.
8' Criterio #e Co4-etitu#'
• •
8odas las pruebas planeadas !an sido ejecutadas. 8odos los defectos ue se identifcaron !an sido tenidos en cuenta.
' Consi#era2iones Es4e2ia-es' Cuando se encuentre un error en el release correspondiente al periodo ele&ido para !acer las inte&raciones del sistema, se detiente el desarrollo !asta ue el error es corre&ido. "ste tipo de pruebas es 5til en la pro&ramaci*n e#trema 3 extremme programming 4 de sistemas complejos.
"s 5til el uso de pro&ramas de prueba automáticas ue se encar&uen de probar os casos de prueba a ejecutados en realeases anteriores.
Prue.as #e- Sistea' 1'
O.jeti9o #e -a Prue.a' Ase&urar la apropiada nave&aci*n dentro del sistema, in&reso de datos, procesamiento recuperaci*n.
5'
Des2ri42i3n #e -a Prue.a' Las pruebas del sistema deben enfocarse en reuisitos ue puedan ser tomados directamente de casos de uso re&las funciones de ne&ocios. "l objetivo de estas pruebas es verificar el in&reso, procesamiento recuperaci*n apropiado de datos, la implementaci*n apropiada de las re&las de ne&ocios. "ste tipo de pruebas se basan en tcnicas de caja ne&ra, sto es, verificar el sistema 3 sus procesos internos4, la interacci*n con las aplicaciones ue lo usan via B% analiar las salidas o resultados. "n esta prueba se determina u pruebas de ;istema 3usabilidad, volumen, desempe+o, etc.4 ase&urarán ue la aplicaci*n alcanará sus objetivos de ne&ocio.
La prueba de ;istema inclue( • • • • • • • • •
)rueba funcionalidad. )rueba de %sabilidad. )rueba de )erformance. )rueba de Documentaci*n )rocedimientos. )rueba de ;e&uridad Controles. )rueba de ?olumen. )rueba de "sfuero 3;tress4. )rueba de recuperaci*n. )rueba de m5ltiples sitios. )ara sistemas web se recomienda especialmente realiar m$nimo el
si&uiente &rupo de pruebas de sistema( • • • •
Eumo. %sabilidad. )erformance. Funcionalidad. )ara capitaliar el trabajo !asta a!ora completado, los casos de prueba de
las pruebas previas realiadas pueden frecuentemente ser reor&aniados re!usados durante la prueba de sistema. o obstante, deben ser desarrollados casos de prueba adicionales para auellos aspectos del sistema, tales como documentaci*n, procedimientos desempe+o ue no !an sido probados durante la prueba unitaria de inte&raci*n. La prueba de sistema es compleja porue intenta validar un n5mero de caracter$sticas al mismo tiempo, a diferencia de otras pruebas ue s*lo se centran en uno o dos aspectos del sistema al mismo tiempo.
7'
T&2ni2a' "jecute cada caso de uso, flujo básico o funci*n utiliando datos válidos e inválidos, para verificar ue(
•
Los resultados esperados ocurren cuando se utilia un dato válido.
•
Los mensajes de error o de advertencia aparecen en el momento adecuado, cuando se utilia un dato inválido.
•
Cada re&la de ne&ocios es aplicada adecuadamente.
8' Criterio #e Co4-etitu#'
•
8odas las pruebas planeadas !an sido ejecutadas.
•
8odos los defectos ue se identifcaron !an sido tenidos en cuenta.
' Consi#era2iones Es4e2ia-es'
•
dentifiue o describa auellos aspectos 3internos o e#ternos4 ue impactan la implementaci*n ejecuci*n de las pruebas del ;istema.
Prue.as #e Dese4e6o' 1'
O.jeti9o #e -a Prue.a'
?alidar el tiempo de respuesta para las transacciones o funciones de ne&ocios bajo las si&uientes dos condiciones( • •
?olumen normal anticipado ?olumen má#imo anticipado.
5'
Des2ri42i3n #e -a Prue.a'
Las pruebas de desempe+o miden tiempos de respuesta, $ndices de procesamiento de transacciones otros reuisitos sensibles al tiempo. "l objetivo de las pruebas de desempe+o es verificar validar los reuisitos de desempe+o ue se !an especificado 3en este caso, el desempe+o ofrecido por el proponente4.
Las pruebas de desempe+o usualmente se ejecutan varias veces, utiliando en cada una, car&a diferente en el sistema. La prueba inicial debe ser ejecutada con una car&a similar a la esperada en el sistema. %na se&unda prueba debe !acerse utiliando una car&a má#ima. Adicionalmente, las pruebas de desempe+o pueden ser utiliadas para perfilar refinar el desempe+o del sistema como una funci*n de condiciones tales como car&a o confi&uraciones de !ardware. Las principales actividades son( • •
Comparar el desempe+o del sistema actual con los reuisitos. )oner a punto el sistema para mejorar las mtricas de desempe+o proectar la capacidad futura de car&a del sistema. Los objetivos de nivel de servicio definidos deben &uiar la prueba de
performance. Al&unas caracter$sticas ue afectan el desempe+o son( • • • • • • • • •
"rrores l*&icos. )rocesamiento ineficiente. Dise+o pobre( muc!as interfases, instrucciones entradas/salidas. Cuellos de botella en discos, C)% * canales de entrada/salida. ;alidas del sistema. 8iempos de respuesta. Capacidad de almacenamiento. 8asa de entrada/salida de datos. 5mero de transacciones ue pueden ser manejadas simultáneamente.
Las pruebas de desempe+o utilian las tcnicas de caja blanca caja ne&ra.
7'
T&2ni2a'
•
%tilice los procedimientos de prueba desarrollados para las pruebas del modelo del ne&ocio 3)ruebas del ;istema4.
•
>odifiue arc!ivos de datos 3para incrementar el n5mero de transacciones4 o los scripts para incrementar el n5mero de veces ue ocurre cada
•
transacci*n. Los scripts deben ser ejecutados en una máuina deben ser repetidos con
m5ltiples
clientes 3virtuales o
actuales4. 3?er
consideraciones
especiales4.
8'
Criterio #e Co4-etitu#'
•
%n %suario / %na 8ransaccion. ;e completaron las pruebas sin nin&una
•
falla dentro del tiempo esperado o reuerido por transacci*n. >5ltiples transacciones, m5ltiples usuarios. ;e completaron las pruebas de los scripts sin nin&una falla dentro del tiempo esperado.
' Consi#era2iones Es4e2ia-es' %nas pruebas de desempe+o inte&rales incluen tener una car&a en bac9&round en el servidor. Ea varios mtodos ue pueden ser utiliados para !acer sto( •
8ransacciones diri&idas directamente al servidor, usualmente en forma de
•
sentencias ;GL.H Creaci*n de usuarios virtuales para simular muc!os clientes 3usualmente varios cientos4. ;e utilian !erramientas de "mulaci*n de 8erminales =emotas para obtener esta car&a. "sta tcnica tambin puede ser utiliada
•
para car&ar de tráfico la red. %se m5ltiples clientes f$sicos, cada uno corriendo los scripts de prueba.
Las pruebas de desempe+o deben ser ejecutadas en una máuina dedicada o en un tiempo dedicado. "sto permite control total medidas precisas. La 7ase de datos utiliada para pruebas de desempe+o debe ser de un tama+o real o proporcionalmente más &rande ue la dise+ada.
Prue.as #e Carga' 1'
O.jeti9o #e -a Prue.a' ?erificar el tiempo de respuesta del sistema para transacciones o casos de uso de ne&ocios, bajo diferentes condiciones de car&a.
5'
Des2ri42i3n #e -a Prue.a' Las pruebas de car&a miden la capacidad del sistema para continuar funcionando apropiadamente bajo diferentes condiciones de car&a. La meta de las pruebas de car&a es determinar ase&urar ue el sistema funciona apropiadamente a5n más allá de la car&a de trabajo má#ima esperada. Adicionalmente, las pruebas de car&a eval5an las caracter$sticas de desempe+o 3tiempos de respuesta, tasas de transacciones otros aspectos sensibles al tiempo4.
7'
T&2ni2a'
• •
%se los scripts desarrolladas para )ruebas del e&ocio. >odifiue arc!ivos de datos 3para incrementar el n5mero de transacciones o veces ue cada transacci*n ocurre4.
8'
Criterio #e Co4-etitu#'
•
>5ltiples transacciones, m5ltiples usuarios. ;e completaron las pruebas de los scripts sin nin&una falla dentro del tiempo esperado.
'
Consi#era2iones Es4e2ia-es'
•
Las pruebas de car&a deben ser ejecutadas en una máuina dedicada o en
•
un tiempo dedicado. "sto permite control total medidas precisas. La 7ase de datos utiliada para pruebas de desempe+o debe ser de un tama+o real o proporcionalmente más &rande ue la dise+ada.
Prue.as #e Stress' '
O.jeti9o #e -a Prue.a' ?erificar ue el sistema funciona apropiadamente sin errores, bajo estas condiciones de stress(
•
>emoria baja o no disponible en el servidor. >á#imo n5mero de clientes conectados o simulados 3actuales o f$sicamente
•
posibles4 >5ltiples usuarios desempe+ando la misma transacci*n con los mismos
•
datos. "l peor caso de volumen de transacciones 3ver pruebas de desempe+o4.
•
I8A;( La meta de las pruebas de stress tambin es identificar documentar las condiciones bajo las cuales el sistema FALLA.
'
Des2ri42i3n #e -a Prue.a'
Las pruebas de stress se proponen encontrar errores debidos a recursos bajos o completitud de recursos. )oca memoria o espacio en disco puede revelar defectos en el sistema ue no son aparentes bajo condiciones normales. Itros defectos pueden resultar de incluir recursos compartidos, como bloueos de base de datos o anc!o de banda de la red. Las pruebas de stress identifican la car&a má#ima ue el sistema puede manejar. "l objetivo de esta prueba es investi&ar el comportamiento del sistema bajo condiciones ue sobrecar&an sus recursos. o debe confundirse con las pruebas de volumen( un esfuero &rande es un pico de volumen de datos ue se presenta en un corto per$odo de tiempo. )uesto ue la prueba de esfuero involucra un elemento de tiempo, no resulta aplicable a muc!os pro&ramas, por ejemplo a un compilador o a una rutina de pa&os. "s aplicable, sin embar&o, a pro&ramas ue trabajan bajo car&as variables, interactivos, de tiempo real de control de proceso. Aunue muc!as pruebas de esfuero representan condiciones ue el pro&rama encontrará realmente durante su utiliaci*n, muc!as otras serán en verdad situaciones ue nunca ocurrirán en la realidad. "sto no implica, sin embar&o, ue estas pruebas no sean 5tiles. ;i se detectan errores durante estas condiciones imposibles, la prueba es valiosa porue es de esperar ue los mismos errores puedan presentarse en situaciones reales, al&o menos e#i&entes.
'
T&2ni2a'
• •
%se los scripts utiliados en las pruebas de desempe+o. )ara probar recursos limitados, las pruebas se deben correr en un servidor con confi&uraci*n reducida 3o limitada4.
•
)ara las pruebas de stress restantes, deben utiliarse m5ltiples clientes, a sea corriendo los mismos scripts o scripts complementarios para producir el peor caso de volumen de transacciones.
'
Criterio #e Co4-etitu#' 8odas las pruebas planeadas !an sido ejecutadas e#cedidas sin ue el sistema falle. 3 I si las condiciones en ue el sistema falle ocurren por fuera de las condiciones especificadas4.
'
Consi#era2iones Es4e2ia-es'
•
)roducir stress en la red puede reuerir !erramientas de red para
•
sobrecar&arla de tráfico. "l espacio en disco utiliado para el sistema debe ser reducido temporalmente para limitar el espacio disponible para el crecimiento de la
•
7ase de datos. ;incroniaci*n de varios clientes accediendo simultáneamente los mismos re&istros .
Prue.as #e )o-u&n' '
O.jeti9o #e -a Prue.a' ?erificar ue la aplicaci*n funciona adecuadamente bajo los si&uientes escenarios de volumen(
•
>á#imo 3actual o f$sicamente posible4 n5mero de clientes conectados 3o simulados4, todos ejecutando la misma funci*n 3peor caso de desempe+o4
•
por un per$odo e#tendido. >á#imo tama+o de base de datos 3actual o escalado4 m5ltiples consultas ejecutadas simultáneamente
'
Des2ri42i3n #e -a Prue.a' Las pruebas de volumen !acen referencia a &randes cantidades de datos para determinar los l$mites en ue se causa ue el ;istema falle. 8ambin identifican la car&a má#ima o volumen ue el sistema puede manejar en un per$odo dado. )or ejemplo, si el sistema está procesando un conjunto de re&istros de 7ase de datos para &enerar un reporte, una prueba de volumen podr$a usar una 7ase de datos de prueba &rande verificar ue el sistema se comporta normalmente produce el reporte correctamente. "l objetivo de esta prueba es someter al sistema a &randes vol5menes de datos para determinar si el mismo puede manejar el volumen de datos especificado en sus reuisitos. Al&unos ejemplos de escenarios de prueba de vol5menes( •
%n compilador puede ser alimentado por un pro&rama para compilar ue
•
sea absurdamente &rande. %n editor de ne#os puede recibir un pro&rama ue conten&a miles de
•
m*dulos. %n simulador de circuito electr*nico puede recibir un circuito dise+ado con miles de componentes. )uesto ue obviamente, la prueba de volumen es una prueba costosa, tanto
en tiempo de máuina como en personal, se debe tratar de no e#ceder los l$mites. ;in embar&o, todo pro&rama deber$a ser e#puesto, al menos, a al&unas pruebas de volumen.
'
T&2ni2a'
• •
%tilice los scripts dise+ados para las pruebas de desempe+o. Deben usarse m5ltiples clientes, a sea corriendo las mismas pruebas o pruebas complementarias para producir el peor caso de volumen 3ver
•
pruebas de stress4 por un per$odo e#tendido. ;e utilia un tama+o má#imo de 7ase de datos. 3actual, escalado o con datos
representativos4
m5ltiples
clientes
para
correr
consultas
simultáneamente para per$odos e#tendidos.
'
Criterio #e Co4-etitu#' 8odas las pruebas planeadas !an sido ejecutadas
los
l$mites
especificados en el sistema se !an conse&uido o e#cedido sin ue el sistema falle.
'
Consi#era2iones Es4e2ia-es' JGu per$odo de tiempo deber$a considerarse como aceptable para condiciones de volumen altoK.
Prue.as #e Re2u4era2i3n ! To-eran2ia #e fa--as' O.jeti9o #e -a Prue.a' ?erificar ue los procesos de recuperaci*n 3manual o automática4 restauran apropiadamente la 7ase de datos, aplicaciones sistemas, los llevan a un estado conocido o deseado. Los si&uientes tipos de condiciones deben incluirse en la prueba(
• • • • •
• •
nterrupci*n de electricidad en el cliente. nterrupci*n de electricidad en el servidor. nterrupci*n en la comunicaci*n !acia el servidor 3ca$das de red4. nterrupci*n en la comunicaci*n con los controladores de disco. Ciclos incompletos 3procesos de consultas interrumpidos, procesos de sincroniaci*n de datos interrumpidos4. Llaves o apuntadores de base de datos inválidos. "lementos corruptos o inválidos en la base de datos.
Des2ri42i3n #e -a Prue.a' "stas pruebas ase&uran ue una aplicaci*n o sistema se recupere de una variedad de anomal$as de !ardware, software o red con prdidas de datos o fallas de inte&ridad. Las pruebas de tolerancia a fallas ase&uran ue, para auellos sistemas ue deben mantenerse corriendo, cuando una condici*n de falla ocurre, los sistemas alternos o de respaldo pueden tomar control del sistema sin prdida de datos o transacciones. Las pruebas de recuperaci*n son contrarias a las pruebas en ue la aplicaci*n o sistema es e#puesto a condiciones e#tremas 3o condiciones simuladas4, tales como fallas en dispositivos en entrada/salida o llaves o apuntadores inválidos de base de datos. Los procesos de recuperaci*n se invocan la aplicaci*n es monitoreada /o inspeccionada para verificar ue stos mecanismos se !an ejecutado en forma apropiada. "l objetivo de esta prueba es determinar la !abilidad del sistema para recuperarse de una falla de !ardware o software. "sta prueba eval5a las caracter$sticas de contin&encia construidas en el sistema para procesar interrupciones para volver a puntos espec$ficos en el ciclo de procesamiento del sistema. La recuperaci*n debe ser considerada en el proceso de dise+o. "rrores de pro&ramaci*n o de datos pueden ser incorporados e# profeso en un sistema para determinar si se puede recuperar de ellos. Las fallas de euipo 3por ejemplo
errores de paridad en memoria, errores en dispositivos de entrada/salida4 pueden ser simuladas.
T&2ni2a' ;e deben utiliar las pruebas creadas para la Funcionalidad del sistema )rocesos de e&ocios para crear una serie de transacciones. %na ve se alcana el punto inicial de las pruebas de recuperaci*n, se deben realiar o simular las si&uientes acciones(
•
nterrupci*n de electricidad en el cliente. nterrupci*n de electricidad en el servidor( simular o iniciar procedimientos
•
de prdida de ener&$a para el servidor. nterrupci*n de la comunicaci*n en la red. 3desconectar f$sicamente los
•
cables o apa&ar los !ubs o routers4 nterrupci*n de la comunicaci*n con los controladores de disco( simular o
•
eliminar f$sicamente la comunicaci*n con uno o mas controladores o dispositivos. %na ve se realian estas acciones, se deben ejecutar series de transacciones, lue&o, una ve alcanado el se&undo punto de pruebas, se deben invocar los procedimientos de recuperaci*n. Las pruebas para ciclos incompletos utilian la misma tcnica ue se describe arriba, e#cepto ue los procesos de 7ase de datos deban ser abortados o terminados prematuramente. Las pruebas para estas condiciones reuieren ue se lle&ue a un estado conocido previamente en la 7ase de datos. Al&unos campos, apuntadores llaves deben ser modificados manualmente, valindose de las !erramientas ue ofreca la ;;)D. Las transacciones adicionales deben ser ejecutadas utiliando las pruebas para Funcionalidad de la aplicaci*n para )rocesos de e&ocios.
Criterio #e Co4-etitu#' "n todos los casos mencionados, la 7ase de datos, aplicaci*n otros sistemas deben retornar a un estado conocido deseado, una ve se completan los procedimientos de recuperaci*n. "ste estado podr$a incluir ue el da+o de datos se limite solamente a los campos, llaves o apuntadores ue se sabe ue fueron alterados, reportes indicando los procesos o transacciones ue no fueron completadas debido a las interrupciones producidas.
'
Consi#era2iones Es4e2ia-es'
•
Las pruebas de recuperaci*n pueden lle&ar a ser molestas. Los procedimientos para desconectar cables o simular prdida de electricidad pueden ser poco factibles o deseables. )odr$an lle&ar a reuerirse mtodos
•
alternativos, como !erramientas de dia&n*stico. ;e reuiere la participaci*n de personal de la red, administradores de la
•
base de datos del sistema. "stas pruebas deben ser ejecutadas en !oras no laborables o en máuinas aisladas.
Prue.as #e (?-ti4-es Sitios' O.jeti9o #e -a Prue.a'
Detectar fallas en confi&uraciones comunicaciones de datos entre m5ltiples sitios.
Des2ri42i3n #e -a Prue.a'
"l prop*sito de esta prueba es evaluar el correcto funcionamiento del sistema o subsistema en m5ltiples instalaciones.
T&2ni2a'
=ealiar casos de prueba ue verifiuen m$nimo lo si&uiente( •
• • • • •
Consistencia de las opciones de confi&uraci*n para el sistema a travs de los sitios. "mpauetamiento del sistema para m5ltiples instalaciones. ;incroniaci*n de datos entre sitios. Comunicaci*n de datos entre sistemas en diferentes sitios. =ompimiento de funciones de sistema a travs de los sitios. Consistencia de controles se&uridad a travs de los sitios.
Criterio #e Co4-etitu#'
• •
8odas las pruebas planeadas !an sido ejecutadas. 8odos los defectos ue se identificaron !an sido tenidos en cuenta.
Consi#era2iones Es4e2ia-es' in&una.
Prue.a #e Co4ati.i-i#a# ! Con9ersi3n' O.jeti9o #e -a Prue.a' 7uscar problemas de compatibilidad conversi*n en los sistemas.
Des2ri42i3n #e -a Prue.a' "l prop*sito es demostrar ue los objetivos de compatibilidad no !an sido lo&rados ue los procedimientos de conversi*n no funcionan. La maor$a de los pro&ramas ue se desarrollan no son completamente nuevos con frecuencia son reemplaos de partes deficientes, a sea de sistemas de procesamiento de datos, o sistemas manuales. Como tales, los pro&ramas tienen a menudo objetivos espec$ficos con respecto a su compatibilidad a sus procedimientos de conversi*n con el sistema e#istente.
T&2ni2a' Desarrollar casos de prueba ue permitan detectar deficiencias con( • •
Compatibilidad entre pro&ramas Conversi*n de datos
Criterio #e Co4-etitu#'
• •
8odas las pruebas planeadas !an sido ejecutadas. 8odos los defectos ue se identificaron !an sido tenidos en cuenta.
Consi#era2iones Es4e2ia-es' in&una.
Prue.as #e Integri#a# #e Datos ! Base #e Datos' O.jeti9o #e -a Prue.a' Ase&urar ue los mtodos de acceso procesos funcionan adecuadamente sin ocasionar corrupci*n de datos.
Des2ri42i3n #e -a Prue.a' La 7ase de datos los procesos de 7ase de datos deben ser probados como sistemas separados del proecto . "stos sistemas deber$an ser probados sin usar interfaces de usuario 3como las interfaces de datos4. ;e necesita realiar investi&aci*n adicional en el D7>; para identificar las !erramientas tcnicas ue podr$an e#istir para soportar las pruebas identificadas más adelante.
T&2ni2a'
•
nvoue cada mtodo de acceso proceso de la 7ase de datos, utiliando
•
en cada uno datos válidos e inválidos. Analice la 7ase de datos, para ase&urar ue los datos !an sido &rabados apropiadamente, ue todos los eventos de 7ase de datos se ejecutaron en forma correcta revise los datos retornados en diferentes consultas.
Criterio #e Co4-etitu#' 8odos los mtodos de acceso procesos de la 7ase de datos funcionan como fueron dise+ados sin corrupci*n de datos
Consi#era2iones Es4e2ia-es'
•
Las pruebas pueden reuerir un ambiente de D7>; o controladores para
•
in&resar o modificar datos directamente en la 7ase de datos. ;e debe utiliar un conjunto peue+o de datos para incrementar la
•
visibilidad de cualuier evento anormal o inesperado. Los procesos pueden ser invocados manualmente.
Prue.as #e Seguri#a# ! Contro- #e A22eso' O.jeti9o #e -a Prue.a'
•
ivel de se&uridad de la aplicaci*n( ?erifica ue un actor solo pueda
•
acceder a las funciones datos ue su usuario tiene permitido. ivel de ;e&uridad del ;istema( ?erificar ue solo los actores con acceso al sistema a la aplicaci*n están !abilitados para accederla.
Des2ri42i3n #e -a Prue.a' Las pruebas de se&uridad control de acceso se centran en dos áreas claves de se&uridad( •
;e&uridad del sistema, incluendo acceso a datos o Funciones de ne&ocios
•
;e&uridad del sistema, incluendo in&resos accesos remotos al sistema. Las pruebas de se&uridad de la aplicaci*n &arantian ue, con base en la
se&uridad deseada, los usuarios están restrin&idos a funciones espec$ficas o su acceso está limitado 5nicamente a los datos ue está autoriado a acceder. )or ejemplo, cada usuario puede estar autoriado a crear nuevas cuentas, pero s*lo los administradores pueden borrarlas. ;i e#iste se&uridad a nivel de datos, la prueba &arantia ue un usuario t$pico 1 puede ver toda la informaci*n de
clientes, incluendo datos financieros sin embar&o, el usuario 2 solamente puede ver los datos institucionales del mismo cliente. Las pruebas de se&uridad del sistema &arantian ue solamente auellos usuarios autoriados a acceder al sistema son capaces de ejecutar las funciones del sistema a travs de los mecanismos apropiados. Debido a la creciente preocupaci*n de la sociedad por la privacidad de la informaci*n, muc!os pro&ramas tienen objetivos espec$ficos de se&uridad. "l objetivo de esta prueba es evaluar el funcionamiento correcto de los controles de se&uridad del sistema para ase&urar la inte&ridad confidencialidad de los datos. "l foco principal es probar la vulnerabilidad del sistema frente a accesos o manipulaciones no autoriadas. %na manera de encontrar esos casos de prueba es estudiar problemas conocidos de se&uridad en sistemas similares tratar de mostrar la e#istencia de problemas parecidos en el sistema ue se e#amina. Al&unas consideraciones de prueba son( • •
• • •
Controles de acceso f$sico. Acceso a estructuras de datos espec$ficas a travs de los pro&ramas de aplicaci*n. ;e&uridad en sitios remotos. "#istencia de datos confidenciales en reportes pantallas. Controles manuales, incluendo auellos para autoriaci*n aprobaci*n, formularios, documentaci*n numerada, transmisi*n de datos, balances
•
conversi*n de datos. Controles automáticos, incluendo auellos para edici*n de datos, c!eueo de máuinas, errores del operador, acceso a datos elementales arc!ivos, acceso a funciones, auditor$a, entre otros.
T&2ni2a'
•
Funciones / ;e&uridad de Datos( dentificar cada tipo de usuario las
•
funciones datos a los ue se debe autoriar. Crear pruebas para cada tipo de usuario verificar cada permiso, creando
•
transacciones espec$ficas para cada tipo de usuario. >odificar tipos de usuarios volver a ejecutar las pruebas. "n cada caso, verificar si los datos o funciones adicionales uedan correctamente
•
permitidos o dene&ados. Acceso al sistema 3ver consideraciones especiales4
Criterio #e Co4-etitu#' )ara cada tipo de usuario conocido, las funciones datos apropiados todas las transacciones funcionan como se esperaba.
'
Consi#era2iones Es4e2ia-es'
"l acceso al sistema debe ser revisado discutido con los administradores de la red /o del sistema. "sta prueba puede no ser reuerida como tal, sino como una funci*n de los administradores de red o del sistema .
Prue.as #e )a-i#a2i3n a Sisteas a -a (e#i#a' Prue.as #e- Ci2-o #e- Nego2io' O.jeti9o #e -a Prue.a' Ase&urar ue el sistema funciona de acuerdo con el modelo de ne&ocios emulando todos los eventos en el tiempo en funci*n del tiempo.
Des2ri42i3n #e -a Prue.a' Las pruebas del ciclo de ne&ocio deber$an emular las actividades ejecutadas en el a travs del tiempo. Deber$a identificarse un periodo, como por ejemplo un a+o, las transacciones actividades ue podr$an ocurrir durante un periodo de un a+o deber$an ejecutarse. ncluendo todos los ciclos eventos diarios, semanales mensuales ue sean datos sensitivos, como las a&endas.
T&2ni2a' "jecute cada caso de uso, flujo básico o funci*n utiliando datos válidos e inválidos, para verificar ue( •
ncremente el n5mero de veces en ue una funci*n es ejecutada para
•
simular diferentes usuarios sobre un periodo especificado 8odas las fec!as o funciones ue involucren tiempos serán probadas con
•
datos válidos e inválidos de fec!as o periodos de tiempo. 8odas las funciones ocurren en un periodo de tiempo serán ejecutadas en
•
el tiempo apropiado. Los resultados esperados ocurren cuando los datos válidos son usados. Los mensajes de error o de advertencia aparecen en el momento
•
adecuado, cuando se utilia un dato inválido. Cada re&la de ne&ocios es aplicada adecuadamente.
•
Criterio #e Co4-etitu#'
• •
8odas las pruebas planeadas !an sido ejecutadas. 8odos los defectos ue se identificaron !an sido tenidos en cuenta.
Consi#era2iones Es4e2ia-es' •
Las fec!as eventos del sistema pueden reuerir actividades especiales de
•
soporte. ;e reuiere un modelo de ne&ocios para identificar reuisitos procedimientos de prueba apropiados.
Prue.as @UI <@ra4i2a- User Interfa2e>' O.jeti9o #e -a Prue.a' ?erifica lo si&uiente( •
La nave&aci*n a travs de los objetos de la prueba reflejan las funcionalidades del ne&ocio reuisitos, se realia una nave&aci*n ventana por ventana, usando los modos de acceso 3tabuladores, movimientos del
•
mouse, teclas rápidas, etc4 Los objetos de la ventana caracter$sticas, tales como men5s, medidas, posiciones, estados focos se verifican conforme a los estándares.
Des2ri42i3n #e -a Prue.a' La prueba de interfa de usuario verifica la interacci*n del usuario con el software. "l objetivo es ase&urar ue la interfa tiene apropiada nave&aci*n a travs de las diferentes funcionalidades. Adicionalmente, las pruebas de interfa ase&uran ue los objetos de la interfa a ser probada se encuentra dentro de los estandares de la industria.
T&2ni2a' )ruebas de crear / modificar cada ventana para verificar la adecuada nave&aci*n estado de los objetos.
Criterio #e Co4-etitu#' Cada ventana ele&ida será totalmente verificada comparada con similares en el mercado lo&rando una buena aceptaci*n dentro del estándar.
Consi#era2iones Es4e2ia-es' in&una.
Prue.as #e Configura2i3n' O.jeti9o #e -a Prue.a' ?alidar verificar ue el cliente del sistema funciona apropiadamente en las estaciones de trabajo recomendadas.
Des2ri42i3n #e -a Prue.a' "stas
pruebas
verifican
la
operaci*n
del
sistema
en
diferentes
confi&uraciones de !ardware software. "n la maor$a de los ambientes de producci*n, las especificaciones para las estaciones de trabajo, euipos de red servidores pueden variar. Las estaciones pueden tener diferentes versiones de software instaladas 3;istemas Iperativos, Drivers, etc4 en cualuier momento, pueden lle&ar a utiliarse diferentes combinaciones. Con frecuencia, el n5mero de confi&uraciones posibles es demasiado &rande para intentar una prueba de cada una de ellas, pero el pro&rama debe probarse al menos con cada tipo de dispositivo con las confi&uraciones m$nima má#ima posibles.
T&2ni2a'
• •
%se los scripts para nte&raci*n )ruebas del ;istema. nclua la apertura o cierre de varias aplicaciones >icrosoft, como "#cel ord 3o al&un tipo de software similar a la ue se esta probando 4 como
•
una parte de la prueba, a sea al comieno o en al&5n momento intermedio. "jecute al&unas transacciones para simular actividades cotidianas del
•
usuario, dentro fuera de las aplicaciones ue interact5an con la 7ase. =epita estos pasos, minimiando la cantidad de memoria convencional disponible en los clientes.
Criterio #e Co4-etitu#' )ara cada combinaci*n de aplicaciones ue interact5an con la 7ase de datos a probar, las transacciones deben ser ejecutadas sin fallas.
Consi#era2iones Es4e2ia-es'
•
JGu aplicaciones están disponibles para los clientesK JGu aplicaciones se utilian normalmenteK JGu tipos de datos manejan estas aplicacionesK 3ej. %na lar&a !oja de
•
cálculo, o un documento de 100 pá&. "n ord.4 Los sistemas, software de red, servidores, bases de datos tambin deben
• •
ser incluidas como parte de estas pruebas.
Prue.a #e Esti-o' O.jeti9o #e -a Prue.a'
Comprobar ue la aplicaci*n si&ue los estándares de estilo propios del cliente.
Des2ri42i3n #e -a Prue.a' ;e entienden como tales el formato de las ventanas, colores corporativos, tipos de letra etc.
T&2ni2a'
•
;e realia una nave&aci*n por la aplicaci*n verificando si se cumplen con
•
los estándares de B% del cliente. ?alidar objetos &ráficos contra el manual de estilos del cliente.
Criterio #e Co4-etitu#'
• •
8odas las pruebas planeadas !an sido ejecutadas. 8odos los defectos ue se identificaron !an sido tenidos en cuenta.
Consi#era2iones Es4e2ia-es' ;olicitar al cliente el manual de estilos, en caso de no e#istir, !acer un levantamiento preliminar de este con base en la informaci*n corporativa e#istente.
Prue.as #e A2e4ta2i3n' O.jeti9o #e -a Prue.a'
Determinaci*n por parte del cliente de la aceptaci*n o rec!ao del sistema desarrollado.
Des2ri42i3n #e -a Prue.a' La prueba de aceptaci*n es ejecutada antes de ue la aplicaci*n sea instalada dentro de un ambiente de producci*n. La prueba de aceptaci*n es &eneralmente desarrollada ejecutada por el cliente o un especialista de la aplicaci*n es conducida a determinar como el sistema satisface sus criterios de aceptaci*n validando los reuisitos ue !an sido levantados para el desarrollo, incluendo a documentaci*n procesos de ne&ocio. 7asado en esta prueba el cliente determina si acepta o rec!aa el sistema "stas pruebas están destinadas a probar ue el producto está listo para el uso operativo. ;uelen ser un subconjunto de las )ruebas de ;istema. ;irve para ue el usuario pueda validar si el producto final se ajusta a los reuisitos fijados, es decir, si el producto está listo para ser implantado para el uso operativo en el entorno del usuario. "sta prueba es complementada por la prueba de estilo.
T&2ni2a' =ealiaci*n de los documentos de planes de prueba de aceptaci*n especificaci*n de los mismos, basados en los criterios de aceptaci*n del cliente. Los casos prueba de aceptaci*n !an de ser planificados, or&aniados formaliados de manera ue se determine el cumplimiento de los reuisitos del sistema. )ara la realiaci*n de estas pruebas se necesita disponer de los si&uientes documentos( •
"specificaci*n de reuisitos del sistema.
• •
>anual de usuario. >anual de administrador.
=ealiar )ruebas de estilo
Criterio #e Co4-etitu#'
• •
8odas las pruebas planeadas !an sido ejecutadas. 8odos los defectos ue se identificaron !an sido tenidos en cuenta.
Consi#era2iones Es4e2ia-es' Las )ruebas de Aceptaci*n se suelen realiar en un entorno de pre: producci*n.
Prue.a #e Insta-a2i3n' O.jeti9o #e -a Prue.a'
?erificar validar ue el sistema se instala apropiadamente en cada cliente, bajo las si&uientes condiciones( •
nstalaciones nuevas, nuevas máuinas a las ue nunca se les !a instalado
•
el sistema. Actualiar máuinas previamente instaladas con el sistema. nstalar versiones viejas en máuinas previamente instaladas con el
•
sistema.
Des2ri42i3n #e -a Prue.a'
Las pruebas de instalaci*n tienen dos prop*sitos. "l primero es ase&urar ue el sistema puede ser instalado en todas las confi&uraciones posibles, tales como
nuevas
instalaciones,
actualiaciones,
instalaciones
completas
o
personaliadas, bajo condiciones normales o anormales estas 5ltimas incluen insuficiente espacio en disco, falta de privile&ios para al&unas tareas, etc. "l se&undo prop*sito es verificar ue, una ve instalado, el sistema opera correctamente. "sto usualmente implica correr un n5mero si&nificativo de pruebas de Funcionalidad.
T&2ni2a'
• •
Dise+ar sripts para validar las condiciones de la máuina a instalar . =ealiar la instalaci*n
Criterio #e Co4-etitu#' Las transacciones de la aplicaci*n se ejecutan sin fallas.
Consi#era2iones Es4e2ia-es' JGu transacciones del sistema se deben seleccionar para realiar una prueba confiable de ue el sistema !a sido instalado e#itosamente no !ace falta nin&5n componente del sistemaK
Prue.as Fun2iona-es' 1'
O.jeti9o #e -a Prue.a'
;e ase&ura la trabajo apropiado de los reuisitos funcionales, incluendo la nave&aci*n, entrada de datos, procesamiento obtenci*n de resultados
Des2ri42i3n #e -a Prue.a' Las pruebas Funcionales deben enfocarse en los reuisitos funcionales, las pruebas pueden estar basadas directamente en los Casos de %so 3o funciones de ne&ocio4, las re&las del ne&ocio. Las metas de estas pruebas son( • •
?erificar la apropiada aceptaci*n de datos, ?erificar el procesamiento recuperaci*n la implementaci*n adecuada de las re&las del ne&ocio. "ste tipo de pruebas están basadas en tcnicas de caja ne&ra, ue es,
verificar la aplicaci*n 3 sus procesos internos4 mediante la interacci*n con la aplicaci*n v$a B% analiar la salida 3resultados4. Lo ue se identifica a continuaci*n es un dise+o preliminar de las pruebas recomendadas para cada aplicaci*n.
7' T&2ni2a' ;e ejecuta cada caso de uso, flujo de caso de uso, o funci*n, usando datos válidos e inválidos, para verificar lo si&uiente(
•
Gue los resultados esperados ocurran cuando se usen datos válidos. Gue sean desple&ados los mensajes apropiados de error precauci*n
•
cuando se usan datos inválidos. Gue se apliue apropiadamente cada re&la de ne&ocio.
•
8' Criterio #e Co4-etitu#'
• •
8odas las pruebas planeadas !an sido ejecutadas. 8odos los defectos ue se identificaron !an sido tenidos en cuenta.
'
Consi#era2iones Es4e2ia-es'
dentifiue o describa auellos aspectos 3internos o e#ternos4 ue impactan la implementaci*n ejecuci*n de las pruebas de funcionalidad.
Prue.as #e Do2uenta2i3n ! Pro2e#iiento' 1'
O.jeti9o #e -a Prue.a'
"valuar la documentaci*n del usuario.
5'
Des2ri42i3n #e -a Prue.a'
"valuar la e#actitud claridad de la documentaci*n del usuario para determinar si el manual de procedimientos trabajará correctamente como una parte inte&ral del sistema. >uc!os defectos son identificados cuando un probador competente c!euea totalmente los manuales documentaci*n del usuario. >uc!os pro&ramas son parte de sistemas maores, no completamente automatiados, ue
contienen procedimientos realiados por
operadores.
Cualuier procedimiento !umano, tal como los ue llevan a cabo el operador, el administrador de la base de datos, o el usuario de terminal, debe ser probado durante la prueba de sistemas.
T&2ni2a' =evisar la documentaci*n del proecto contra las funcionalidades del sistema su confi&uraci*n f$sica.
Criterio #e Co4-etitu#'
• •
8odas las pruebas planeadas !an sido ejecutadas. 8odos los defectos ue se identificaron !an sido tenidos en cuenta.
'
Consi#era2iones Es4e2ia-es'
in&una.
Prue.a #e Usa.i-i#a#' O.jeti9o #e -a Prue.a' Determinar la usabilidad del sistema.
Des2ri42i3n #e -a Prue.a' Determina cuán bien el usuario podrá usar entender la aplicaci*n. dentifica las áreas de dise+o ue !acen al sistema de dif$cil uso para el usuario. La prueba de usabilidad detecta
problemas
relacionados con
conveniencia practicidad del sistema desde el punto de vista del usuario.
la
T&2ni2a' ?erificar ue la aplicaci*n no presenta los si&uientes problemas de usabilidad t$picos(
• • •
"l sistema es demasiado complejo dif$cil de usar. "s dif$cil instalar entender el sistema. La recuperaci*n de errores es pobre los mensajes de error no tienen
•
si&nificado. La sinta#is de los comandos es dif$cil de aprender recordar. "l sistema obli&a al usuario a recordar formatos secuencias fijas. Los procedimientos no son simples ni obvios. "l sistema no tiene instrucciones de auda por computadora tiene
•
manuales pobres. Los dia&ramas, pantallas, reportes &ráficos son de calidad apariencia
•
pobre. "l sistema carece de !erramientas de construcci*n adecuadas reuiere
•
m5ltiples comandos. La l*&ica conveniencia de los botones, switc!es, displas mensajes de
• • •
auda deben ser testeados. 3La prueba de usabilidad puede ser conducida por un &rupo separado si es posible. ;e deben crear casos de prueba para comprobar ue se puede operar en el sistema de forma adecuada.
Criterio #e Co4-etitu#'
• •
8odas las pruebas planeadas !an sido ejecutadas. 8odos los defectos ue se identificaron !an sido tenidos en cuenta.
Consi#era2iones Es4e2ia-es' in&una.
Prue.as #e Ca4o' O.jeti9o #e -a Prue.a' Correr el sistema en el ambiente real para encontrar errores validar el producto contra sus especificaciones ori&inales.
Des2ri42i3n #e -a Prue.a' =ealiar un subconjunto válido de pruebas de sistema.
T&2ni2a' Determinar ue pruebas de sistema serán corridas para validar el sistema en producci*n.
Criterio #e Co4-etitu#'
• •
8odas las pruebas planeadas !an sido ejecutadas. 8odos los defectos ue se identificaron !an sido tenidos en cuenta.
Consi#era2iones Es4e2ia-es' in&una.
Prue.as #e )a-i#a2i3n a A4-i2a2iones @en&ri2as' Prue.as A-fa' O.jeti9o #e -a Prue.a' )rueba de aceptaci*n para detectar errores en el sistema bajo un ambiente controlado.
Des2ri42i3n #e -a Prue.a' La verificaci*n involucra la ejecuci*n de partes o todo del sistema en ambientes simulados, con el fin de encontrar errores. La retroalimentaci*n de esta fase produce cambios en el software para resolver los errores fallas ue se descubren.
T&2ni2a' =ealiar las pruebas de sistema bajo las si&uientes caracter$sticas( • •
;e llevan a cabo en el lu&ar en donde fue desarrollado el sw, "n un ambiente controlado, en el cual el desarrollador está presente.
;e selecciona un &rupo de usuarios para el alp!a test se les pide trabajen con el sistema como parte de las pruebas.
Criterio #e Co4-etitu#'
• •
8odas las pruebas planeadas !an sido ejecutadas. 8odos los defectos ue se identificaron !an sido tenidos en cuenta.
Consi#era2iones Es4e2ia-es' in&una.
Prue.as Beta' O.jeti9o #e -a Prue.a' =ealiar la validaci*n del sistema por parte del usuario.
Des2ri42i3n #e -a Prue.a' )rueba de aceptaci*n donde La validaci*n 3o pruebas beta4 involucra el uso del software en un ambiente real.
T&2ni2a' ;e selecciona un &rupo de usuarios ue ponen a trabajar el sistema en un ambiente real. %san el sistema en sus actividades cotidianas, procesan transacciones producen salidas normales del sistema. Las transacciones personas ue usan el sistema son reales trabajan en su área de trabajo real. "l desarrollador no esta presente. Los usuarios están advertidos de ue están usando un sistema ue puede fallar. Los usuarios realian pruebas a su antojo realiando uso de la aplicaci*n.
Criterio #e Co4-etitu#'
