TIPOS DE PRUEBAS DE SOFTWARE

A continuacin se describen las principales tipos pruebas que se pueden realizar a cualquier
tipo de software. Cada prueba contendr como mnimo a siguiente informacin:
- Objetivo de la prueba
- Descripcin de la prueba
- Tcnica
- Criterio de Completitud
- Consideraciones Especiales
Prueba Unitaria
Objetivo de la Prueba: Se focaliza en ejecutar cada mdulo (o unidad
mnima a ser probada ej ! una clase" lo que pro#ee
un mejor modo de manejar la integracin de las
unidades en componentes ma$ores.
%usca asegurar que el cdigo funciona de acuerdo
con las especificaciones $ que el mdulo lgico es
#lido.
Descripcin de la Prueba: &articionar los mdulos en pruebas en
unidades lgicas fciles de probar.
&or cada unidad 'a$ que definir los casos de
prueba (pruebas de caja blanca".
&ara esto los casos de prueba deben
dise(arse de forma tal que se recorran todos
los caminos de ejecucin posibles dentro del
cdigo bajo prueba) por lo tanto el dise(ador
debe construirlos con acceso al cdigo fuente
de la unidad a probar.
*os aspectos a considerar son los siguientes:
+utinas de e,cepcin +utinas de error
-anejo de parmetros .alidaciones .alores
#lidos .alores lmites +angos -ensajes
posibles.
T!cnica: Comparar el resultado esperado con el
resultado obtenido.
Si e,isten errores reportarlos.
"riterio de "o#pletitud: /odas las pruebas planeadas 'an sido
ejecutadas.
/odos los defectos que se identificaron 'an
sido tenidos en cuenta.
"onsideraciones Especiales: &ara la elaboracin de pruebas unitarias en
ja#a se puede utillizar el 0123/ $ CAC/1S.
Prueba de Inte$racin
Objetivo de la Prueba: 3dentificar errores introducidos por la
combinacin de programas probados
unitariamente.
4etermina cmo la base de datos de prueba ser
cargada.
.erificar que las interfaces entre las entidades
e,ternas (usuarios" $ las aplicaciones funcionan
correctamente.
.erificar que las especificaciones de dise(o sean
alcanzadas.
4etermina el enfoque para a#anzar desde un
ni#el de integracin de las componentes al
siguiente.
Descripcin de la Prueba: 5 4escribe cmo #erificar que las interfaces entre
las componentes de software funcionan
correctamente.
5 4etermina cmo la base de datos de prueba ser
cargada.
5 4etermina el enfoque para a#anzar desde un
ni#el de integracin de las componentes al
siguiente.
5 4ecide qu6 acciones tomar cuando se descubren
problemas.
&or cada Caso de &rueba ejecutado:
Comparar el resultado esperado con el
resultado obtenido.
T!cnica: 1tilizar la t6cnica top7down. Se empieza con
los mdulos de ni#el superior $ se #erifica
que los mdulos de ni#el superior llaman a
los de ni#el inferior de manera correcta con
los parmetros correctos.
1tilizar la t6cnica down7top. Se empieza con
los mdulos de ni#el inferior $ se #erifica que
los mdulos de ni#el inferior llaman a los de
ni#el superior de manera correcta con los
parmetros correctos.
"riterio de "o#pletitud: /odas las pruebas planeadas 'an sido
ejecutadas.
/odos los defectos que se identificaron 'an
sido tenidos en cuenta.
"onsideraciones Especiales: 2inguna
Prueba de Re$resin
Objetivo de la Prueba: 4eterminar si los cambios recientes en una parte de
la aplicacin tienen efecto ad#erso en otras partes.
Descripcin de la Prueba: 8n esta prueba se #uel#e a probar el sistema a la luz
de los cambios realizados durante el debugging
mantenimiento o desarrollo de la nue#a #ersin del
sistema buscando efectos ad#ersos en otras partes.
T!cnica: *a prueba de regresin es una nue#a corrida de
casos de prueba pre#ios.
Se requiere de polticas para ser creada la
prueba de regresin $ decidir qu6 casos de
prueba incluir para probar eficientemente.
*a prueba de regresin es un buen candidato
para automatizacin. 4esde que estas pruebas
se repiten una $ otra #ez las 'erramientas para
minimizar el esfuerzo del trabajo son 9tiles.
*a prueba de #iejas funcionalidades es ms
importante que la de nue#as funcionalidades.
Aquellos casos de uso ($ los casos de prueba
asociados" que descubren defectos
tempranamente deben ser incluidos en la prueba
de regresin.
Criterio de Completitud: /odas las pruebas planeadas 'an sido
ejecutadas.
/odos los defectos que se identificaron 'an sido
tenidos en cuenta.
"onsideraciones Especiales: 2inguna.
Pruebas de %u#o &S#o'eTestin$ o Ad %oc(
Objetivo de la Prueba: *os objeti#os son los siguientes:
4etectar los errores en realeases tempranos $ de
manera fcil
&robar el sistema constantemente
:arantizar poco esfuerzo en la integracin final del
sistema
Asegurar los resultados de las pruebas unitarias
Se reducen los riesgos $ a baja calidad.
Descripcin de la Prueba: /oma 6ste nombre debido a que su objeti#o es
probar el sistema constantemente buscando que
saque ;'umo< o falle. 8n algunos pro$ectos este tipo
de prueba #a junto con las pruebas funcionales.
&ermite detectar problemas que por lo regular no son
detectados en las pruebas normales. Algunas #eces
si las &ruebas ocurren tarde en el ciclo de desarrollo
est ser una forma de garantizar el buen desarrollo.
*as pruebas de 'umo NO SONe,'austi#as pero #an
de e,tremo a e,tremo de la aplicacin.
T!cnica: =. +ealizar una integracin de todo el sistema
cada cierto periodo (se recomienda un da
m,imo una semana"
>. +ealizar los casos de prueba asignados a los
casos de uso finalizados ese da ms los
realizados en das anteriores
?. %uscar eficientemente errores
"riterio de "o#pletitud: /odas las pruebas planeadas 'an sido ejecutadas.
/odos los defectos que se identifcaron 'an sido
tenidos en cuenta.
"onsideraciones Especiales: Cuando se encuentre un error en el release
correspondiente al periodo elegido para 'acer las
integraciones del sistema se detiente el desarrollo
'asta que el error es corregido.
8ste tipo de pruebas es 9til en la programacin
e,trema (extremmeprogramming" $ de sistemas
complejos.
8s 9til el uso de programas de prueba automticas
que se encarguen de probar os casos de prueba $a
ejecutados en realeases anteriores.
Pruebas del Siste#a
Objetivo de la Prueba: Asegurar la apropiada na#egacin dentro del
sistema ingreso de datos procesamiento $
recuperacin.
Descripcin de la Prueba: *as pruebas del sistema deben enfocarse en
requisitos que puedan ser tomados directamente de
casos de uso $ reglas $ funciones de negocios. 8l
objeti#o de estas pruebas es #erificar el ingreso
procesamiento $ recuperacin apropiado de datos $
la implementacin apropiada de las reglas de
negocios. 8ste tipo de pruebas se basan en t6cnicas
de caja negra 6sto es #erificar el sistema ($ sus
procesos internos" la interaccin con las
aplicaciones que lo usan #ia :13 $ analizar las
salidas o resultados.
8n esta prueba se determina qu6 pruebas de
Sistema (usabilidad #olumen desempe(o etc."
asegurarn que la aplicacin alcanzar sus objeti#os
de negocio.
*a prueba de Sistema inclu$e:
&rueba funcionalidad
&rueba de 1sabilidad
&rueba de &erformance
&rueba de 4ocumentacin $ &rocedimientos
&rueba de Seguridad $ Controles
&rueba de .olumen
&rueba de 8sfuerzo (Stress"
&rueba de recuperacin
&rueba de m9ltiples sitios
&ara sistemas web se recomienda especialmente
realizar mnimo el siguiente grupo de pruebas de
sistema:
@ Aumo.
@ 1sabilidad
@ &erformance
@ Buncionalidad
&ara capitalizar el trabajo 'asta a'ora completado
los casos de prueba de las pruebas pre#ias
realizadas pueden frecuentemente ser reorganizados
$ re'usados durante la prueba de sistema. 2o
obstante deben ser desarrollados casos de prueba
adicionales para aquellos aspectos del sistema tales
como documentacin procedimientos $ desempe(o
que no 'an sido probados durante la prueba unitaria
$ de integracin.
*a prueba de sistema es compleja porque intenta
#alidar un n9mero de caractersticas al mismo
tiempo a diferencia de otras pruebas que slo se
centran en uno o dos aspectos del sistema al mismo
tiempo.
T!cnica: 8jecute cada caso de uso flujo bsico o funcin
utilizando datos #lidos e in#lidos para #erificar
que:
@ *os resultados esperados ocurren cuando se
utiliza un dato #lido.
@ *os mensajes de error o de ad#ertencia
aparecen en el momento adecuado cuando
se utiliza un dato in#lido.
@ Cada regla de negocios es aplicada
adecuadamente.
"riterio de "o#pletitud: /odas las pruebas planeadas 'an sido
ejecutadas.
/odos los defectos que se identifcaron 'an
sido tenidos en cuenta.
"onsideraciones Especiales: 3dentifique o describa aquellos aspectos
(internos o e,ternos" que impactan la
implementacin $ ejecucin de las pruebas
del Sistema
Pruebas de Dese#pe)o
Objetivo de la Prueba: .alidar el tiempo de respuesta para las transacciones
o funciones de negocios bajo las siguientes dos
condiciones:
.olumen normal anticipado
.olumen m,imo anticipado.
Descripcin de la Prueba: *as pruebas de desempe(o miden tiempos de
respuesta ndices de procesamiento de
transacciones $ otros requisitos sensibles al tiempo.
8l objeti#o de las pruebas de desempe(o es #erificar
$ #alidar los requisitos de desempe(o que se 'an
especificado (en este caso el desempe(o ofrecido
por el proponente".
*as pruebas de desempe(o usualmente se ejecutan
#arias #eces utilizando en cada una carga diferente
en el sistema. *a prueba inicial debe ser ejecutada
con una carga similar a la esperada en el sistema.
1na segunda prueba debe 'acerse utilizando una
carga m,ima.
Adicionalmente las pruebas de desempe(o pueden
ser utilizadas para perfilar $ refinar el desempe(o del
sistema como una funcin de condiciones tales como
carga o configuraciones de 'ardware
*as principales acti#idades son:
Comparar el desempe(o del sistema actual
con los requisitos
&oner a punto el sistema para mejorar las
m6tricas de desempe(o $ pro$ectar la
capacidad futura de carga del sistema.
*os objeti#os de ni#el de ser#icio definidos deben
guiar la prueba de performance. Algunas
caractersticas que afectan el desempe(o son:
8rrores lgicos
&rocesamiento ineficiente
4ise(o pobre: muc'as interfases
instrucciones $ entradasCsalidas.
Cuellos de botella en discos C&1 canales
de entradaCsalida
Salidas del sistema
/iempos de respuesta
Capacidad de almacenamiento
/asa de entradaCsalida de datos
29mero de transacciones que pueden ser
manejadas simultneamente.
*as pruebas de desempe(o utilizan las t6cnicas de
caja blanca $ caja negra.
T!cnica: 1tilice los procedimientos de prueba
desarrollados para las pruebas del modelo
del negocio (&ruebas del Sistema".5
-odifique arc'i#os de datos (para
incrementar el n9mero de transacciones" o
los scripts para incrementar el n9mero de
#eces que ocurre cada transaccin.5
*os scripts deben ser ejecutados en una
mquina $ deben ser repetidos con m9ltiples
clientes (#irtuales o actuales". (.er
consideraciones especiales".
"riterio de "o#pletitud: 1n 1suario C 1na /ransaccion. Se
completaron las pruebas sin ninguna falla $
dentro del tiempo esperado o requerido por
transaccin.
-9ltiples transacciones m9ltiples usuarios.
Se completaron las pruebas de los scripts sin
ninguna falla $ dentro del tiempo esperado.
"onsideraciones Especiales: @ 1nas pruebas de desempe(o integrales inclu$en
tener una carga en bacDground en el ser#idor.
Aa$ #arios m6todos que pueden ser utilizados
para 'acer 6sto:
o /ransacciones dirigidas directamente al
ser#idor usualmente en forma de
sentencias SE*.5
o Creacin de usuarios #irtuales para simular
muc'os clientes (usualmente #arios
cientos". Se utilizan 'erramientas de
8mulacin de /erminales +emotas para
obtener esta carga. 8sta t6cnica tambi6n
puede ser utilizada para cargar de trfico
la red.
o 1se m9ltiples clientes fsicos cada uno
corriendo los scripts de prueba.
@ *as pruebas de desempe(o deben ser ejecutadas
en una mquina dedicada o en un tiempo
dedicado. 8sto permite control total $ medidas
precisas.
@ *a %ase de datos utilizada para pruebas de
desempe(o debe ser de un tama(o real o
proporcionalmente ms grande que la dise(ada.
Pruebas de "ar$a
Objetivo de la Prueba: .erificar el tiempo de respuesta del sistema para
transacciones o casos de uso de negocios bajo
diferentes condiciones de carga.
Descripcin de la Prueba: *as pruebas de carga miden la capacidad del
sistema para continuar funcionando apropiadamente
bajo diferentes condiciones de carga.
*a meta de las pruebas de carga es determinar $
asegurar que el sistema funciona apropiadamente
a9n ms all de la carga de trabajo m,ima
esperada. Adicionalmente las pruebas de carga
e#al9an las caractersticas de desempe(o (tiempos
de respuesta tasas de transacciones $ otros
aspectos sensibles al tiempo".
T!cnica: 1se los scripts desarrolladas para &ruebas
del 2egocio.
-odifique arc'i#os de datos (para
incrementar el n9mero de transacciones o
#eces que cada transaccin ocurre".
"riterio de "o#pletitud: -9ltiples transacciones m9ltiples usuarios.
Se completaron las pruebas de los scripts sin
ninguna falla $ dentro del tiempo esperado.
"onsideraciones Especiales: *as pruebas de carga deben ser ejecutadas
en una mquina dedicada o en un tiempo
dedicado. 8sto permite control total $
medidas precisas.5
*a %ase de datos utilizada para pruebas de
desempe(o debe ser de un tama(o real o
proporcionalmente ms grande que la
dise(ada.
Pruebas de Stress
Objetivo de la Prueba: .erificar que el sistema funciona apropiadamente $
sin errores bajo estas condiciones de stress:
-emoria baja o no disponible en el ser#idor.
-,imo n9mero de clientes conectados o
simulados (actuales o fsicamente posibles"
-9ltiples usuarios desempe(ando la misma
transaccin con los mismos datos.
8l peor caso de #olumen de transacciones
(#er pruebas de desempe(o".
2F/AS: *a meta de las pruebas de stress
tambi6n es identificar $ documentar las
condiciones bajo las cuales el sistema BA**A.
Descripcin de la Prueba: *as pruebas de stress se proponen encontrar errores
debidos a recursos bajos o completitud de recursos.
&oca memoria o espacio en disco puede re#elar
defectos en el sistema que no son aparentes bajo
condiciones normales. Ftros defectos pueden
resultar de incluir recursos compartidos como
bloqueos de base de datos o anc'o de banda de la
red. *as pruebas de stress identifican la carga
m,ima que el sistema puede manejar.
8l objeti#o de esta prueba es in#estigar el
comportamiento del sistema bajo condiciones que
sobrecargan sus recursos. 2o debe confundirse con
las pruebas de #olumen: un esfuerzo grande es un
pico de #olumen de datos que se presenta en un
corto perodo de tiempo.
&uesto que la prueba de esfuerzo in#olucra un
elemento de tiempo no resulta aplicable a muc'os
programas por ejemplo a un compilador o a una
rutina de pagos.
8s aplicable sin embargo a programas que trabajan
bajo cargas #ariables interacti#os de tiempo real $
de control de proceso.
Aunque muc'as pruebas de esfuerzo representan
condiciones que el programa encontrar realmente
durante su utilizacin muc'as otras sern en #erdad
situaciones que nunca ocurrirn en la realidad. 8sto
no implica sin embargo que estas pruebas no sean
9tiles.
Si se detectan errores durante estas condiciones
;imposibles< la prueba es #aliosa porque es de
esperar que los mismos errores puedan presentarse
en situaciones reales algo menos e,igentes.
T!cnica: 1se los scripts utilizados en las pruebas de
desempe(o.
&ara probar recursos limitados las pruebas
se deben correr en un ser#idor con
configuracin reducida (o limitada".
&ara las pruebas de stress restantes deben
utilizarse m9ltiples clientes $a sea corriendo
los mismos scripts o scripts complementarios
para producir el peor caso de #olumen de
transacciones.
"riterio de "o#pletitud: /odas las pruebas planeadas 'an sido ejecutadas $
e,cedidas sin que el sistema falle. ( F si las
condiciones en que el sistema falle ocurren por fuera
de las condiciones especificadas".
"onsideraciones Especiales: @ &roducir stress en la red puede requerir
'erramientas de red para sobrecargarla de
trfico.
@ 8l espacio en disco utilizado para el sistema debe
ser reducido temporalmente para limitar el
espacio disponible para el crecimiento de la %ase
de datos.
@ Sincronizacin de #arios clientes accediendo
simultneamente los mismos registros.
Pruebas de *olu#en
Objetivo de la Prueba: @ .erificar que la aplicacin funciona
adecuadamente bajo los siguientes escenarios
de #olumen:
o -,imo (actual o fsicamente posible"
n9mero de clientes conectados (o
simulados" todos ejecutando la misma
funcin (peor caso de desempe(o" por un
perodo e,tendido.
o -,imo tama(o de base de datos (actual o
escalado" $ m9ltiples consultas
ejecutadas simultneamente
Descripcin de la Prueba: *as pruebas de #olumen 'acen referencia a grandes
cantidades de datos para determinar los lmites en
que se causa que el Sistema falle. /ambi6n
identifican la carga m,ima o #olumen que el
sistema puede manejar en un perodo dado. &or
ejemplo si el sistema est procesando un conjunto
de registros de %ase de datos para generar un
reporte una prueba de #olumen podra usar una
%ase de datos de prueba grande $ #erificar que el
sistema se comporta normalmente $ produce el
reporte correctamente.
8l objeti#o de esta prueba es someter al sistema a
grandes #ol9menes de datos para determinar si el
mismo puede manejar el #olumen de datos
especificado en sus requisitos.
Algunos ejemplos de escenarios de prueba de
#ol9menes:
@ 1n compilador puede ser alimentado por un
programa para compilar que sea absurdamente
grande.
@ 1n editor de ne,os puede recibir un programa que
contenga miles de mdulos.
@ 1n simulador de circuito electrnico puede recibir
un circuito dise(ado con miles de componentes.
&uesto que ob#iamente la prueba de #olumen es
una prueba costosa tanto en tiempo de mquina
como en personal se debe tratar de no e,ceder los
lmites. Sin embargo todo programa debera ser
e,puesto al menos a algunas pruebas de #olumen.
T!cnica: @ 1tilice los scripts dise(ados para las pruebas de
desempe(o.
@ 4eben usarse m9ltiples clientes $a sea corriendo
las mismas pruebas o pruebas complementarias
para producir el peor caso de #olumen (#er
pruebas de stress" por un perodo e,tendido.
@ Se utiliza un tama(o m,imo de %ase de datos.
(actual escalado o con datos representati#os" $
m9ltiples clientes para correr consultas
simultneamente para perodos e,tendidos.
"riterio de "o#pletitud: /odas las pruebas planeadas 'an sido ejecutadas $
los lmites especificados en el sistema se 'an
conseguido o e,cedido sin que el sistema falle.
"onsideraciones Especiales: Eu6 perodo de tiempo debera considerarse
como aceptable para condiciones de #olumen
altoG
Pruebas de Recuperacin + Tolerancia a ,allas
Objetivo de la Prueba: .erificar que los procesos de recuperacin (manual o
automtica" restauran apropiadamente la %ase de
datos aplicaciones $ sistemas $ los lle#an a un
estado conocido o deseado. *os siguientes tipos de
condiciones deben incluirse en la prueba:
@ 3nterrupcin de electricidad en el cliente.
@ 3nterrupcin de electricidad en el ser#idor
@ 3nterrupcin en la comunicacin 'acia el ser#idor
(cadas de red"
@ 3nterrupcin en la comunicacin con los
controladores de disco.
@ Ciclos incompletos (procesos de consultas
interrumpidos procesos de sincronizacin de
datos interrumpidos"
@ *la#es o apuntadores de base de datos in#lidos
@ 8lementos corruptos o in#lidos en la base de
datos.
Descripcin de la Prueba: 8stas pruebas aseguran que una aplicacin o
sistema se recupere de una #ariedad de anomalas
de 'ardware software o red con p6rdidas de datos o
fallas de integridad.
*as pruebas de tolerancia a fallas aseguran que
para aquellos sistemas que deben mantenerse
corriendo cuando una condicin de falla ocurre los
sistemas alternos o de respaldo pueden tomar
control del sistema sin p6rdida de datos o
transacciones.
*as pruebas de recuperacin son contrarias a las
pruebas en que la aplicacin o sistema es e,puesto
a condiciones e,tremas (o condiciones simuladas"
tales como fallas en dispositi#os en entradaCsalida o
lla#es o apuntadores in#lidos de base de datos. *os
procesos de recuperacin se in#ocan $ la aplicacin
es monitoreada $Co inspeccionada para #erificar que
6stos mecanismos se 'an ejecutado en forma
apropiada.
8l objeti#o de esta prueba es determinar la 'abilidad
del sistema para recuperarse de una falla de
'ardware o software. 8sta prueba e#al9a las
caractersticas de contingencia construidas en el
sistema para procesar interrupciones $ para #ol#er a
puntos especficos en el ciclo de procesamiento del
sistema. *a recuperacin debe ser considerada en el
proceso de dise(o. 8rrores de programacin o de
datos pueden ser incorporados e, profeso en un
sistema para determinar si se puede recuperar de
ellos. *as fallas de equipo (por ejemplo errores de
paridad en memoria errores en dispositi#os de
entradaCsalida" pueden ser simuladas.
T!cnica: Se deben utilizar las pruebas creadas para la
Buncionalidad del sistema $ &rocesos de 2egocios
para crear una serie de transacciones. 1na #ez se
alcanza el punto inicial de las pruebas de
recuperacin se deben realizar o simular las
siguientes acciones:
3nterrupcin de electricidad en el cliente.
3nterrupcin de electricidad en el ser#idor: simular o
iniciar procedimientos de p6rdida de energa para
el ser#idor.
3nterrupcin de la comunicacin en la red.
(desconectar fsicamente los cables o apagar los
'ubs o routers"
3nterrupcin de la comunicacin con los
controladores de disco: simular o eliminar
fsicamente la comunicacin con uno o mas
controladores o dispositi#os.
1na #ez se realizan estas acciones se deben
ejecutar series de transacciones $ luego una #ez
alcanzado el segundo punto de pruebas se deben
in#ocar los procedimientos de recuperacin.
*as pruebas para ciclos incompletos utilizan la
misma t6cnica que se describe arriba e,cepto que
los procesos de %ase de datos deban ser abortados
o terminados prematuramente.
*as pruebas para estas condiciones requieren que
se llegue a un estado conocido pre#iamente en la
%ase de datos. Algunos campos apuntadores $
lla#es deben ser modificados manualmente
#ali6ndose de las 'erramientas que ofrezca la SS&4.
*as transacciones adicionales deben ser ejecutadas
utilizando las pruebas para Buncionalidad de la
aplicacin $ para &rocesos de 2egocios.
"riterio de "o#pletitud: 8n todos los casos mencionados la %ase de datos
aplicacin $ otros sistemas deben retornar a un
estado conocido $ deseado una #ez se completan
los procedimientos de recuperacin. 8ste estado
podra incluir que el da(o de datos se limite
solamente a los campos lla#es o apuntadores que
se sabe que fueron alterados $ reportes indicando
los procesos o transacciones que no fueron
completadas debido a las interrupciones producidas.
"onsideraciones Especiales: @ *as pruebas de recuperacin pueden llegar a ser
molestas. *os procedimientos para desconectar
cables o simular p6rdida de electricidad pueden
ser poco factibles o deseables. &odran llegar a
requerirse m6todos alternati#os como
'erramientas de diagnstico.
@ Se requiere la participacin de personal de la red
administradores de la base de datos $ del
sistema.
@ 8stas pruebas deben ser ejecutadas en 'oras no
laborables o en mquinas aisladas.
Prueba de -.ltiples Sitios
Objetivo de la Prueba: 4etectar fallas en configuraciones $ comunicaciones
de datos entre m9ltiples sitios.
Descripcin de la Prueba: 8l propsito de esta prueba es e#aluar el correcto
funcionamiento del sistema o subsistema en
m9ltiples instalaciones.
T!cnica: +ealizar casos de prueba que #erifiquen mnimo lo
siguiente:
=. Consistencia de las opciones de
configuracin para el sistema a tra#6s de los
sitios
>. 8mpaquetamiento del sistema para m9ltiples
instalaciones
?. Sincronizacin de datos entre sitios
H. Comunicacin de datos entre sistemas en
diferentes sitios
I. +ompimiento de funciones de sistema a
tra#6s de los sitios.
J. Consistencia de controles $ seguridad a
tra#6s de los sitios
"riterio de "o#pletitud: /odas las pruebas planeadas 'an sido
ejecutadas.
/odos los defectos que se identificaron 'an
sido tenidos en cuenta.
"onsideraciones Especiales: 2inguna
Prueba de "o#patibilidad + "onversin
Objetivo de la Prueba: %uscar problemas de compatibilidad $ con#ersin en
los sistemas.
Descripcin de la Prueba: 8l propsito es demostrar que los objeti#os de
compatibilidad no 'an sido logrados $ que los
procedimientos de con#ersin no funcionan.
*a ma$ora de los programas que se desarrollan no
son completamente nue#os) con frecuencia son
reemplazos de partes deficientes $a sea de
sistemas de procesamiento de datos o sistemas
manuales.
Como tales los programas tienen a menudo
objeti#os especficos con respecto a su
compatibilidad $ a sus procedimientos de con#ersin
con el sistema e,istente.
T!cnica: 4esarrollar casos de prueba que permitan detectar
deficiencias con:
@ Compatibilidad entre programas
@ Con#ersin de datos
"riterio de "o#pletitud: /odas las pruebas planeadas 'an sido
ejecutadas.
/odos los defectos que se identificaron 'an
sido tenidos en cuenta.
"onsideraciones Especiales: 2inguna
Pruebas de Inte$ridad de Datos + Base de Datos
Objetivo de la Prueba: Asegurar que los m6todos de acceso $ procesos
funcionan adecuadamente $ sin ocasionar corrupcin
de datos.
Descripcin de la Prueba: *a %ase de datos $ los procesos de %ase de datos
deben ser probados como sistemas separados del
pro$ecto . 8stos sistemas deberan ser probados sin
usar interfaces de usuario (como las interfaces de
datos". Se necesita realizar in#estigacin adicional
en el 4%-S para identificar las 'erramientas $
t6cnicas que podran e,istir para soportar las
pruebas identificadas ms adelante.
T!cnica: 3n#oque cada m6todo de acceso $ proceso de la
%ase de datos utilizando en cada uno datos
#lidos e in#lidos.
Analice la %ase de datos para asegurar que los
datos 'an sido grabados apropiadamente que
todos los e#entos de %ase de datos se
ejecutaron en forma correcta $ re#ise los datos
retornados en diferentes consultas.
"riterio de "o#pletitud: /odos los m6todos de acceso $ procesos de la %ase
de datos funcionan como fueron dise(ados $ sin
corrupcin de datos.
"onsideraciones Especiales: *as pruebas pueden requerir un ambiente de
4%-S o controladores para ingresar o
modificar datos directamente en la %ase de
datos.
Se debe utilizar un conjunto peque(o de
datos para incrementar la #isibilidad de
cualquier e#ento anormal o inesperado.
*os procesos pueden ser in#ocados
manualmente.
Pruebas de Se$uridad + "ontrol de Acceso
Objetivo de la Prueba: 2i#el de seguridad de la aplicacin: .erifica que un
actor solo pueda acceder a las funciones $ datos que
su usuario tiene permitido.
2i#el de Seguridad del Sistema: .erificar que solo los
actores con acceso al sistema $ a la aplicacin estn
'abilitados para accederla.
Descripcin de la Prueba: *as pruebas de seguridad $ control de acceso se
centran en dos reas cla#es de seguridad:
Seguridad del sistema inclu$endo acceso a
datos o Bunciones de negocios $
Seguridad del sistema inclu$endo ingresos $
accesos remotos al sistema.
*as pruebas de seguridad de la aplicacin garantizan
que con base en la seguridad deseada los usuarios
estn restringidos a funciones especficas o su
acceso est limitado 9nicamente a los datos que
est autorizado a acceder. &or ejemplo cada usuario
puede estar autorizado a crear nue#as cuentas pero
slo los administradores pueden borrarlas. Si e,iste
seguridad a ni#el de datos la prueba garantiza que
un usuario ;tpico< = puede #er toda la informacin de
clientes inclu$endo datos financieros) sin embargo
el usuario > solamente puede #er los datos
institucionales del mismo cliente.
*as pruebas de seguridad del sistema garantizan
que solamente aquellos usuarios autorizados a
acceder al sistema son capaces de ejecutar las
funciones del sistema a tra#6s de los mecanismos
apropiados.
4ebido a la creciente preocupacin de la sociedad
por la pri#acidad de la informacin muc'os
programas tienen objeti#os especficos de seguridad.
8l objeti#o de esta prueba es e#aluar el
funcionamiento correcto de los controles de
seguridad del sistema para asegurar la integridad $
confidencialidad de los datos. 8l foco principal es
probar la #ulnerabilidad del sistema frente a accesos
o manipulaciones no autorizadas. 1na manera de
encontrar esos casos de prueba es estudiar
problemas conocidos de seguridad en sistemas
similares $ tratar de mostrar la e,istencia de
problemas parecidos en el sistema que se e,amina.
Algunas consideraciones de prueba son:
Controles de acceso fsico
Acceso a estructuras de datos especficas a
tra#6s de los programas de aplicacin.
Seguridad en sitios remotos
8,istencia de datos confidenciales en
reportes $ pantallas
Controles manuales inclu$endo aquellos
para autorizacin $ aprobacin formularios
documentacin numerada transmisin de
datos balances $ con#ersin de datos.
Controles automticos inclu$endo aquellos
para edicin de datos c'equeo de mquinas
errores del operador acceso a datos
elementales $ arc'i#os acceso a funciones
auditora entre otros.
T!cnica: @ Bunciones C Seguridad de 4atos: 3dentificar cada
tipo de usuario $ las funciones $ datos a los que
se debe autorizar.
@ Crear pruebas para cada tipo de usuario $ #erificar
cada permiso creando transacciones especficas
para cada tipo de usuario.
@ -odificar tipos de usuarios $ #ol#er a ejecutar las
pruebas. 8n cada caso #erificar si los datos o
funciones adicionales quedan correctamente
permitidos o denegados.
@ Acceso al sistema (#er consideraciones
especiales".
"riterio de "o#pletitud: &ara cada tipo de usuario conocido las funciones $
datos apropiados $ todas las transacciones
funcionan como se esperaba.
"onsideraciones Especiales: 8l acceso al sistema debe ser re#isado $ discutido
con los administradores de la red $Co del sistema.
8sta prueba puede no ser requerida como tal sino
como una funcin de los administradores de red o
del sistema.
PRUEBAS DE *A/IDA"I01 A SISTE-AS A /A -EDIDA
Pruebas del "iclo del 1e$ocio
Objetivo de la Prueba: Asegurar que el sistema funciona de acuerdo con el
modelo de negocios emulando todos los e#entos en
el tiempo $ en funcin del tiempo.
Descripcin de la Prueba: *as pruebas del ciclo de negocio deberan emular las
acti#idades ejecutadas en el a tra#6s del tiempo.
4ebera identificarse un periodo como por ejemplo
un a(o $ las transacciones $ acti#idades que
podran ocurrir durante un periodo de un a(o
deberan ejecutarse. 3nclu$endo todos los ciclos $
e#entos diarios semanales $ mensuales que sean
datos sensiti#os como las agendas.
T!cnica: 8jecute cada caso de uso flujo bsico o funcin
utilizando datos #lidos e in#lidos para #erificar
que:
@ 3ncremente el n9mero de #eces en que una
funcin es ejecutada para simular diferentes
usuarios sobre un periodo especificado
@ /odas las fec'as o funciones que in#olucren
tiempos sern probadas con datos #lidos e
in#lidos de fec'as o periodos de tiempo.
@ /odas las funciones ocurren en un periodo de
tiempo sern ejecutadas en el tiempo apropiado.
@ *os resultados esperados ocurren cuando los
datos #lidos son usados.
@ *os mensajes de error o de ad#ertencia aparecen
en el momento adecuado cuando se utiliza un
dato in#lido.
@ Cada regla de negocios es aplicada
adecuadamente.
"riterio de "o#pletitud: @ /odas las pruebas planeadas 'an sido ejecutadas.
@ /odos los defectos que se identificaron 'an sido
tenidos en cuenta.
"onsideraciones Especiales: @ *as fec'as $ e#entos del sistema pueden requerir
acti#idades especiales de soporte.
@ Se requiere un modelo de negocios para identificar
requisitos $ procedimientos de prueba
apropiados.
Pruebas de 2UI
Objetivo de la Prueba: .erifica lo siguiente:
*a na#egacin a tra#6s de los objetos de la
prueba reflejan las funcionalidades del
negocio $ requisitos se realiza una
na#egacin #entana por #entana usando los
modos de acceso (tabuladores mo#imientos
del mouse teclas rpidas etc"
*os objetos de la #entana $ caractersticas
tales como men9s medidas posiciones
estados $ focos se #erifican conforme a los
estndares.
Descripcin de la Prueba: *a prueba de interfaz de usuario #erifica la
interaccin del usuario con el software. 8l objeti#o es
asegurar que la interfaz tiene apropiada na#egacin
a tra#6s de las diferentes funcionalidades.
Adicionalmente las pruebas de interfaz aseguran
que los objetos de la interfaz a ser probada se
encuentra dentro de los estandares de la industria
T!cnica: &ruebas de crear C modificar cada #entana para
#erificar la adecuada na#egacin $ estado de los
objetos.
"riterio de "o#pletitud: Cada #entana elegida ser totalmente #erificada $
comparada con similares en el mercado logrando
una buena aceptacin dentro del estndar.
"onsideraciones Especiales: 2inguna
Pruebas de "on,i$uracin
Objetivo de la Prueba: .alidar $ #erificar que el cliente del sistema funciona
apropiadamente en las estaciones de trabajo
recomendadas.
Descripcin de la Prueba: 8stas pruebas #erifican la operacin del sistema en
diferentes configuraciones de 'ardware $ software.
8n la ma$ora de los ambientes de produccin las
especificaciones para las estaciones de trabajo
equipos de red $ ser#idores pueden #ariar. *as
estaciones pueden tener diferentes #ersiones de
software instaladas (Sistemas Fperati#os 4ri#ers
etc" $ en cualquier momento pueden llegar a
utilizarse diferentes combinaciones.
Con frecuencia el n9mero de configuraciones
posibles es demasiado grande para intentar una
prueba de cada una de ellas pero el programa debe
probarse al menos con cada tipo de dispositi#o $ con
las configuraciones mnima $ m,ima posibles.
T!cnica: @ 1se los scripts para 3ntegracin $ &ruebas del
Sistema.
@ 3nclu$a la apertura o cierre de #arias aplicaciones
-icrosoft como 8,cel $ Kord (o algun tipo de
software similar a la que se esta probando "
como una parte de la prueba $a sea al comienzo
o en alg9n momento intermedio.
@ 8jecute algunas transacciones para simular
acti#idades cotidianas del usuario dentro $ fuera
de las aplicaciones que interact9an con la %ase.
@ +epita estos pasos minimizando la cantidad de
memoria con#encional disponible en los clientes.
"riterio de "o#pletitud: &ara cada combinacin de aplicaciones que
interact9an con la %ase de datos a probar las
transacciones deben ser ejecutadas sin fallas.
"onsideraciones Especiales: @ Eu6 aplicaciones estn disponibles para los
clientesG
@ Eu6 aplicaciones se utilizan normalmenteG
@ Eu6 tipos de datos manejan estas aplicacionesG
(ej. 1na larga 'oja de clculo o un documento de
=LL pg. 8n Kord."
@ *os sistemas software de red ser#idores bases
de datos tambi6n deben ser incluidas como parte
de estas pruebas.
Prueba de Estilo
Objetivo de la Prueba: Comprobar que la aplicacin sigue los estndares de
estilo propios del cliente.
Descripcin de la Prueba: Se entienden como tales el formato de las #entanas
colores corporati#os tipos de letra etc.
T!cnica: @ Se realiza una na#egacin por la aplicacin
#erificando si se cumplen con los estndares
de :13 del cliente.
@ .alidar objetos grficos contra el manual de
estilos del cliente.
"riterio de "o#pletitud: @ /odas las pruebas planeadas 'an sido
ejecutadas.
@ /odos los defectos que se identificaron 'an
sido tenidos en cuenta.
"onsideraciones Especiales: Solicitar al cliente el manual de estilos en
caso de no e,istir 'acer un le#antamiento
preliminar de este con base en la informacin
corporati#a e,istente.
Prueba de Aceptacin
Objetivo de la Prueba: 4eterminacin por parte del cliente de la aceptacin
o rec'azo del sistema desarrollado.
Descripcin de la Prueba: *a prueba de aceptacin es ejecutada antes de que
la aplicacin sea instalada dentro de un ambiente de
produccin. *a prueba de aceptacin es
generalmente desarrollada $ ejecutada por el cliente
o un especialista de la aplicacin $ es conducida a
determinar como el sistema satisface sus criterios de
aceptacin #alidando los requisitos que 'an sido
le#antados para el desarrollo inclu$endo a
documentacin $ procesos de negocio.
%asado en esta prueba el cliente determina si acepta
o rec'aza el sistema
8stas pruebas estn destinadas a probar que el
producto est listo para el uso operati#o. Suelen ser
un subconjunto de las &ruebas de Sistema.
Sir#e para que el usuario pueda #alidar si el producto
final se ajusta a los requisitos fijados es decir si el
producto est listo para ser implantado para el uso
operati#o en el entorno del usuario.
8sta prueba es complementada por la prueba de
estilo.
T!cnica: +ealizacin de los documentos de planes de prueba
de aceptacin $ especificacin de los mismos
basados en los criterios de aceptacin del cliente.
*os casos prueba de aceptacin 'an de ser
planificados organizados $ formalizados de manera
que se determine el cumplimiento de los requisitos
del sistema. &ara la realizacin de estas pruebas se
necesita disponer de los siguientes documentos:
8specificacin de requisitos del sistema.
-anual de usuario.
-anual de administrador.
+ealizar &ruebas de estilo
"riterio de "o#pletitud: @ /odas las pruebas planeadas 'an sido
ejecutadas.
@ /odos los defectos que se identificaron 'an
sido tenidos en cuenta.
"onsideraciones Especiales: *as &ruebas de Aceptacin se suelen realizar en un
entorno de pre7produccin.
Prueba de Instalacin
Objetivo de la Prueba: .erificar $ #alidar que el sistema se instala
apropiadamente en cada cliente bajo las siguientes
condiciones:
@ 3nstalaciones nue#as nue#as mquinas a las que
nunca se les 'a instalado el sistema.
@ Actualizar mquinas pre#iamente instaladas con el
sistema.
@ 3nstalar #ersiones #iejas en mquinas pre#iamente
instaladas con el sistema.
Descripcin de la Prueba: *as pruebas de instalacin tienen dos propsitos. 8l
primero es asegurar que el sistema puede ser
instalado en todas las configuraciones posibles tales
como nue#as instalaciones actualizaciones
instalaciones completas o personalizadas $ bajo
condiciones normales o anormales) estas 9ltimas
inclu$en insuficiente espacio en disco falta de
pri#ilegios para algunas tareas etc.
8l segundo propsito es #erificar que una #ez
instalado el sistema opera correctamente. 8sto
usualmente implica correr un n9mero significati#o de
pruebas de Buncionalidad.
T!cnica: @ 4ise(ar sripts para #alidar las condiciones de la
mquina a instalar .
@ +ealizar la instalacin
"riterio de "o#pletitud: *as transacciones de la aplicacin se ejecutan sin
fallas.
"onsideraciones Especiales: @ Eu6 transacciones del sistema se deben
seleccionar para realizar una prueba confiable de
que el sistema 'a sido instalado e,itosamente $
no 'ace falta ning9n componente del sistemaG
Pruebas Funcionales
Objetivo de la Prueba: Se asegura el trabajo apropiado de los requisitos
funcionales inclu$endo la na#egacin entrada de
datos procesamiento $ obtencin de resultados
Descripcin de la Prueba: *as pruebas Buncionales deben enfocarse en los
requisitos funcionales las pruebas pueden estar
basadas directamente en los Casos de 1so (o
funciones de negocio" $ las reglas del negocio. *as
metas de estas pruebas son:
.erificar la apropiada aceptacin de datos
.erificar el procesamiento $ recuperacin $ la
implementacin adecuada de las reglas del
negocio.
8ste tipo de pruebas estn basadas en t6cnicas de
caja negra que es #erificar la aplicacin ($ sus
procesos internos" mediante la interaccin con la
aplicacin #a :13 $ analizar la salida (resultados".
*o que se identifica a continuacin es un dise(o
preliminar de las pruebas recomendadas para cada
aplicacin.
T!cnica: Se ejecuta cada caso de uso flujo de caso de uso o
funcin usando datos #lidos e in#lidos para
#erificar lo siguiente:
Eue los resultados esperados ocurran
cuando se usen datos #lidos.
Eue sean desplegados los mensajes
apropiados de error $ precaucin cuando se
usan datos in#lidos.
Eue se aplique apropiadamente cada regla
de negocio.
"riterio de "o#pletitud: /odas las pruebas planeadas 'an sido
ejecutadas.
/odos los defectos que se identificaron 'an
sido tenidos en cuenta.
"onsideraciones Especiales: 3dentifique o describa aquellos aspectos (internos o
e,ternos" que impactan la implementacin $
ejecucin de las pruebas de funcionalidad.
Prueba de Docu#entacin 3 Procedi#iento
Objetivo de la Prueba: 8#aluar la documentacin del usuario
Descripcin de la Prueba: 8#aluar la e,actitud $ claridad de la documentacin
del usuario $ para determinar si el manual de
procedimientos trabajar correctamente como una
parte integral del sistema.
-uc'os defectos son identificados cuando un
probador competente c'equea totalmente los
manuales $ documentacin del usuario.
-uc'os programas son parte de sistemas ma$ores
no completamente automatizados que contienen
procedimientos realizados por operadores. Cualquier
procedimiento 'umano tal como los que lle#an 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!cnica: +e#isar la documentacin del pro$ecto contra las
funcionalidades del sistema $ su configuracin fsica.
"riterio de "o#pletitud: /odas las pruebas planeadas 'an sido
ejecutadas.
/odos los defectos que se identificaron 'an
sido tenidos en cuenta.
"onsideraciones Especiales: 2inguna.
Prueba de Usabilidad
Objetivo de la Prueba: 4eterminar la usabilidad del sistema.
Descripcin de la Prueba: 4etermina cun bien el usuario podr usar $
entender la aplicacin. 3dentifica las reas de dise(o
que 'acen al sistema de difcil uso para el usuario.
*a prueba de usabilidad detecta problemas
relacionados con la con#eniencia $ practicidad del
sistema desde el punto de #ista del usuario.
T!cnica: .erificar que la aplicacin no presenta los siguientes
problemas de usabilidad tpicos:
8l sistema es demasiado complejo $ difcil de
usar.
8s difcil instalar $ entender el sistema
*a recuperacin de errores es pobre $ los
mensajes de error no tienen significado
*a sinta,is de los comandos es difcil de
aprender $ recordar
8l sistema obliga al usuario a recordar
formatos $ secuencias fijas
*os procedimientos no son simples ni ob#ios
8l sistema no tiene instrucciones de a$uda
por computadora $ tiene manuales pobres.
*os diagramas pantallas reportes $ grficos
son de calidad $ apariencia pobre
8l sistema carece de 'erramientas de
construccin adecuadas $ requiere m9ltiples
comandos
*a lgica $ con#eniencia de los botones
switc'es displa$s $ mensajes de a$uda
deben ser testeados. (*a prueba de
usabilidad puede ser conducida por un grupo
separado si es posible.
Se deben crear casos de prueba para comprobar
que se puede operar en el sistema de forma
adecuada.
"riterio de "o#pletitud: /odas las pruebas planeadas 'an sido
ejecutadas.
/odos los defectos que se identificaron 'an
sido tenidos en cuenta.
"onsideraciones Especiales: 2inguna
Prueba de "a#po
Objetivo de la Prueba: Correr el sistema en el ambiente real para encontrar
errores $ #alidar el producto contra sus
especificaciones originales.
Descripcin de la Prueba: +ealizar un subconjunto #lido de pruebas de
sistema.
T!cnica: 4eterminar que pruebas de sistema sern corridas
para #alidar el sistema en produccin.
"riterio de "o#pletitud: /odas las pruebas planeadas 'an sido
ejecutadas.
/odos los defectos que se identificaron 'an
sido tenidos en cuenta.
"onsideraciones Especiales: 2inguna
PRUEBAS DE *A/IDA"I01 A AP/I"A"IO1ES 2E14RI"AS
Pruebas Al,a
Objetivo de la Prueba: &rueba de aceptacin para detectar errores en el
sistema bajo un ambiente controlado.
Descripcin de la Prueba: *a #erificacin in#olucra la ejecucin de partes o todo
del sistema en ambientes simulados con el fin de
encontrar errores.
*a retroalimentacin de esta fase produce cambios
en el software para resol#er los errores $ fallas que
se descubren.
T!cnica: +ealizar las pruebas de sistema bajo las siguientes
caractersticas:
se lle#an a cabo en el lugar en donde fue
desarrollado el sw
en un ambiente controlado en el cual el
desarrollador est presente.
Se selecciona un grupo de usuarios para el alp'a
test $ se les pide trabajen con el sistema como parte
de las pruebas.
"riterio de "o#pletitud: /odas las pruebas planeadas 'an sido
ejecutadas.
/odos los defectos que se identificaron 'an
sido tenidos en cuenta.
"onsideraciones Especiales: 2inguna
Pruebas Beta
Objetivo de la Prueba: +ealizar la #alidacin del sistema por parte del
usuario.
Descripcin de la Prueba: &rueba de aceptacin donde *a #alidacin (o
pruebas beta" in#olucra el uso del software en un
ambiente real.
T!cnica: Se selecciona un grupo de usuarios que ponen a
trabajar el sistema en un ambiente real. 1san el
sistema en sus acti#idades cotidianas procesan
transacciones $ producen salidas normales del
sistema.
*as transacciones $ personas que usan el sistema
son reales $ trabajan en su rea de trabajo real.
8l desarrollador no esta presente.
*os usuarios estn ad#ertidos de que estn usando
un sistema que puede fallar.
*os usuarios realizan pruebas a su antojo realizando
uso de la aplicacin.
"riterio de "o#pletitud: Se establece un periodo de pruebas beta en el que
los errores detectados no sean de carcter crtico
para el sistema.
"onsideraciones Especiales: Se deben considerar mecanismos de comunicacin
entre los desarrolladores $ los usuarios de manera
que los errores detectados puedan ser corregidos.
Pruebas de "aja Blanca
*as pruebas de caja blanca (tambi6n conocidas como pruebas de caja de cristal o
pruebas estructurales" se centran en los detalles procedimentales del software por lo
que su dise(o est fuertemente ligado al cdigo fuente. 8l testeador escoge distintos
#alores de entrada para e,aminar cada uno de los posibles flujos de ejecucin del
programa $ cerciorarse de que se de#uel#en los #alores de salida adecuados.
Al estar basadas en una implementacin concreta si 6sta se modifica por regla
general las pruebas tambi6n debern redise(arse.
Aunque las pruebas de caja blanca son aplicables a #arios ni#eles Munidad
integracin $ sistemaM 'abitualmente se aplican a las unidades de software. Su
cometido es comprobar los flujos de ejecucin dentro de cada unidad (funcin clase
mdulo etc." pero tambi6n pueden testear los flujos entre unidades durante la
integracin e incluso entre subsistemas durante las pruebas de sistema.
A pesar de que este enfoque permite dise(ar pruebas que cubran una amplia #ariedad
de casos de prueba podra pasar por alto partes incompletas de la especificacin o
requisitos faltantes pese a garantizar la prueba e,'austi#a de todos los flujos de
ejecucin del cdigo analizado.
*as principales t6cnicas de dise(o de pruebas de caja blanca son:
&ruebas de flujo de control
&ruebas de flujo de datos
&ruebas de bifurcacin (branchtesting"
&ruebas de caminos bsicos
"aja 1e$ra &siste#as(
8n teora de sistemas $ fsica se denomina caja ne$ra a aquel elemento que es
estudiado desde el punto de #ista de las entradas que recibe $ las salidas o
respuestas que produce sin tener en cuenta su funcionamiento interno. 8n otras
palabras de una caja negra nos interesar su forma de interactuar con el medio que le
rodea (en ocasiones otros elementos que tambi6n podran ser cajas negras"
entendiendo 5u! es lo 5ue 6ace pero sin dar importancia a c#o lo 6ace. &or tanto
de una caja negra deben estar mu$ bien definidas sus entradas $ salidas es decir su
interfaz) en cambio no se precisa definir ni conocer los detalles internos de su
funcionamiento.