Está en la página 1de 15

Eduardo Ramirez

ITESHU
Pruebas de Software
Contenido
Tipos de prueba
Los 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
El proceso de pruebas del software tiene dos objetivos:
1. emostrar al desarrollador ! al cliente "ue el software satisface sus re"uerimientos.
#ara el software a medida$ si%nifica "ue debe &aber al menos una prueba para
cada re"uerimiento del sistema ! del usuario.
#ara software %en'rico$ si%nifica "ue debe &aber pruebas para todas las
caracter(sticas del sistema "ue se incorporar)n en la entre%a del producto.
Este objetivo conduce a las pruebas de validaci*n +, se espera "ue el sistema
funcione correctamente usando un conjunto determinado de casos de prueba "ue reflejan
el uso esperado de a"u'l.
-. escubrir defectos en el software: "ue su comportamiento es incorrecto$ no deseable o
no cumple su especificaci*n.
.a prueba de defectos est) relacionada con la eliminaci*n de todos los
comportamientos no deseables.
#rueba Unitaria
/bjetivo de la #rueba:
Se focaliza en ejecutar cada m*dulo 0o unidad minima a ser probada$ ej + una clase1 lo
"ue provee un mejor modo de manejar la inte%raci*n de las unidades en componentes
ma!ores.
2usca ase%urar "ue el c*di%o funciona de acuerdo con las especificaciones ! "ue el
m*dulo l*%ico es v)lido.
escripci*n de la #rueba:
3 #articionar los m*dulos en pruebas en unidades l*%icas f)ciles de probar.
3 #or cada unidad &a! "ue definir los casos de prueba 0pruebas de caja blanca1.
3 #ara esto los casos de prueba deben dise4arse de forma tal "ue se recorran todos
los caminos de ejecuci*n posibles dentro del c*di%o bajo prueba5 por lo tanto el dise4ador
debe construirlos con acceso al c*di%o fuente de la unidad a probar.
3 .os aspectos a considerar son los si%uientes: Rutinas de e6cepci*n$ Rutinas de
error$ 7anejo de par)metros$ 8alidaciones$ 8alores v)lidos$ 8alores l(mites$ Ran%os$
7ensajes posibles.
#rueba de Inte%raci*n
/bjetivo de la #rueba: Identificar errores introducidos por la combinaci*n de
pro%ramas probados unitariamente.
etermina c*mo la base de datos de prueba ser) car%ada.
8erificar "ue las interfaces entre las entidades e6ternas 0usuarios1 ! las aplicaciones
funcionan correctamente.
8erificar "ue las especificaciones de dise4o sean alcanzadas.
etermina el enfo"ue para avanzar desde un nivel de inte%raci*n de las componentes al
si%uiente.
escripci*n de la #rueba:
3escribe c*mo verificar "ue las interfaces entre las componentes de software funcionan
correctamente.
3etermina c*mo la base de datos de prueba ser) car%ada.
3etermina el enfo"ue para avanzar desde un nivel de inte%raci*n de las componentes al
si%uiente.
3ecide "u' acciones tomar cuando se descubren problemas.
#or cada 9aso de #rueba ejecutado:
3 9omparar el resultado esperado con el resultado obtenido.
#rueba de Re%resi*n
/bjetivo de la #rueba:
eterminar si los cambios recientes en una parte de la aplicaci*n tienen efecto
adverso en otras partes.
escripci*n de la #rueba:
En esta prueba se vuelve a probar el sistema a la luz de los cambios realizados
durante el debu%%in%$ mantenimiento o desarrollo de la nueva versi*n del sistema
buscando efectos adversos en otras partes.
#ruebas de Humo 0Smo:e Testin% o ;d Hoc1
/bjetivo de la #rueba: .os objetivos son los si%uientes:
3 etectar los errores en realeases tempranos ! de manera f)cil
3 #robar el sistema constantemente
3 <arantizar poco esfuerzo en la inte%raci*n final del sistema
3 ;se%urar los resultados de las pruebas unitarias
3 Se reducen los ries%os ! a baja calidad.
escripci*n de la #rueba: Toma 'ste nombre debido a "ue su objetivo es probar el
sistema constantemente buscando "ue sa"ue =&umo> o falle. En al%unos pro!ectos 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. ;l%unas veces$ si las #ruebas
ocurren tarde en el ciclo de desarrollo est) ser) una forma de %arantizar el buen
desarrollo.
.as pruebas de &umo ?/ S/? e6&austivas$ pero van de e6tremo a e6tremo de la
aplicaci*n.
#ruebas del Sistema
/bjetivo de la #rueba:
;se%urar la apropiada nave%aci*n dentro del sistema$ in%reso de datos$
procesamiento ! recuperaci*n.
escripci*n de la #rueba:
.as pruebas del sistema deben enfocarse en re"uisitos "ue puedan ser tomados
directamente de casos de uso ! re%las ! funciones de ne%ocios. El 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. Este tipo de pruebas se basan en
t'cnicas de caja ne%ra$ 'sto es$ verificar el sistema 0! sus procesos internos1$ la
interacci*n con las aplicaciones "ue lo usan via <UI ! analizar las salidas o resultados.
En esta prueba se determina "u' pruebas de Sistema 0usabilidad$ volumen$ desempe4o$
etc.1 ase%urar)n "ue la aplicaci*n alcanzar) sus objetivos de ne%ocio.
.a prueba de Sistema inclu!e:
#rueba funcionalidad
#rueba de Usabilidad
#rueba de #erformance
#rueba de ocumentaci*n ! #rocedimientos
#rueba de Se%uridad ! 9ontroles
#rueba de 8olumen
#rueba de Esfuerzo 0Stress1
#rueba de recuperaci*n
#rueba de m@ltiples sitios
#ara sistemas web se recomienda especialmente realizar m(nimo el si%uiente %rupo de
pruebas de sistema:
3Humo.
3Usabilidad
3#erformance
3Auncionalidad
#ara capitalizar el trabajo &asta a&ora completado$ los casos de prueba de las pruebas
previas realizadas pueden frecuentemente ser reor%anizados ! re&usados durante la
prueba de sistema. ?o obstante$ deben ser desarrollados casos de prueba adicionales
para a"uellos aspectos del sistema$ tales como documentaci*n$ procedimientos !
desempe4o "ue no &an sido probados durante la prueba unitaria ! de inte%raci*n.
.a prueba de sistema es compleja por"ue intenta validar un n@mero 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.
#ruebas de esempe4o
/bjetivo de la #rueba: 8alidar el tiempo de respuesta para las transacciones o
funciones de ne%ocios bajo las si%uientes dos condiciones:
3 8olumen normal anticipado
3 8olumen m)6imo anticipado.
escripci*n de la #rueba:
.as pruebas de desempe4o miden tiempos de respuesta$ (ndices de
procesamiento de transacciones ! otros re"uisitos sensibles al tiempo. El objetivo de las
pruebas de desempe4o es verificar ! validar los re"uisitos de desempe4o "ue se &an
especificado 0en este caso$ el desempe4o ofrecido por el proponente1.
.as pruebas de desempe4o usualmente se ejecutan varias veces$ utilizando en cada una$
car%a diferente en el sistema. .a prueba inicial debe ser ejecutada con una car%a similar a
la esperada en el sistema. Una se%unda prueba debe &acerse utilizando una car%a
m)6ima.
;dicionalmente$ las pruebas de desempe4o pueden ser utilizadas para perfilar ! refinar el
desempe4o del sistema como una funci*n de condiciones tales como car%a o
confi%uraciones de &ardware
.as principales actividades son:
3 9omparar el desempe4o del sistema actual con los re"uisitos$
3 #oner a punto el sistema para mejorar las m'tricas de desempe4o ! pro!ectar la
capacidad futura de car%a del sistema.
.os objetivos de nivel de servicio definidos deben %uiar la prueba de performance.
;l%unas caracter(sticas "ue afectan el desempe4o son:
3 Errores l*%icos
3 #rocesamiento ineficiente
3 ise4o pobre: muc&as interfases$ instrucciones ! entradasBsalidas.
3 9uellos de botella en discos$ 9#U * canales de entradaBsalida
3 Salidas del sistema
3 Tiempos de respuesta
3 9apacidad de almacenamiento
3 Tasa de entradaBsalida de datos
3 ?@mero de transacciones "ue pueden ser manejadas simult)neamente.
.as pruebas de desempe4o utilizan las t'cnicas de caja blanca ! caja ne%ra.
#ruebas de 9ar%a
/bjetivo de la #rueba:
8erificar el tiempo de respuesta del sistema para transacciones o casos de uso de
ne%ocios$ bajo diferentes condiciones de car%a.
escripci*n de la #rueba:
.as pruebas de car%a miden la capacidad del sistema para continuar funcionando
apropiadamente bajo diferentes condiciones de car%a.
.a meta de las pruebas de car%a es determinar ! ase%urar "ue el sistema funciona
apropiadamente a@n m)s all) de la car%a de trabajo m)6ima esperada. ;dicionalmente$
las pruebas de car%a eval@an las caracter(sticas de desempe4o 0tiempos de respuesta$
tasas de transacciones ! otros aspectos sensibles al tiempo1.
#ruebas de Stress
/bjetivo de la #rueba:
8erificar "ue el sistema funciona apropiadamente ! sin errores$ bajo estas
condiciones de stress:
3 7emoria baja o no disponible en el servidor.
3 7)6imo n@mero de clientes conectados o simulados 0actuales o
f(sicamente posibles1
3 7@ltiples usuarios desempe4ando la misma transacci*n con los mismos
datos.
3 El peor caso de volumen de transacciones 0ver pruebas de desempe4o1.
?/T;S: .a meta de las pruebas de stress tambi'n es identificar ! documentar las
condiciones bajo las cuales el sistema A;..;.
escripci*n de la #rueba:
.as 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. /tros defectos pueden resultar
de incluir recursos compartidos$ como blo"ueos de base de datos o anc&o de banda de la
red. .as pruebas de stress identifican la car%a m)6ima "ue el sistema puede manejar.
El 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
esfuerzo %rande es un pico de volumen de datos "ue se presenta en un corto per(odo de
tiempo.
#uesto "ue la prueba de esfuerzo 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.
Es aplicable$ sin embar%o$ a pro%ramas "ue trabajan bajo car%as variables$ interactivos$
de tiempo real ! de control de proceso.
;un"ue muc&as pruebas de esfuerzo representan condiciones "ue el pro%rama
encontrar) realmente durante su utilizaci*n$ muc&as otras ser)n en verdad situaciones
"ue nunca ocurrir)n en la realidad. Esto no implica$ sin embar%o$ "ue estas pruebas no
sean @tiles.
Si se detectan errores durante estas condiciones =imposibles>$ la prueba es valiosa
por"ue es de esperar "ue los mismos errores puedan presentarse en situaciones reales$
al%o menos e6i%entes.
#ruebas de 8olumen
/bjetivo de la #rueba:
38erificar "ue la aplicaci*n funciona adecuadamente bajo los si%uientes escenarios
de volumen:
o 7)6imo 0actual o f(sicamente posible1 n@mero de clientes conectados 0o
simulados1$ todos ejecutando la misma funci*n 0peor caso de desempe4o1 por un
per(odo e6tendido.
o 7)6imo tama4o de base de datos 0actual o escalado1 ! m@ltiples consultas
ejecutadas simult)neamente
escripci*n de la #rueba:
.as pruebas de volumen &acen referencia a %randes cantidades de datos para
determinar los l(mites en "ue se causa "ue el Sistema falle. Tambi'n identifican la car%a
m)6ima 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 2ase de datos para %enerar un
reporte$ una prueba de volumen podr(a usar una 2ase de datos de prueba %rande !
verificar "ue el sistema se comporta normalmente ! produce el reporte correctamente.
El objetivo de esta prueba es someter al sistema a %randes vol@menes de datos para
determinar si el mismo puede manejar el volumen de datos especificado en sus re"uisitos.
;l%unos ejemplos de escenarios de prueba de vol@menes:
3Un compilador puede ser alimentado por un pro%rama para compilar "ue sea
absurdamente %rande.
3Un editor de ne6os puede recibir un pro%rama "ue conten%a miles de m*dulos.
3Un simulador de circuito electr*nico puede recibir un circuito dise4ado 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 e6ceder los l(mites. Sin embar%o$ todo
pro%rama deber(a ser e6puesto$ al menos$ a al%unas pruebas de volumen.
#ruebas de Recuperaci*n ! Tolerancia a fallas
/bjetivo de la #rueba:
8erificar "ue los procesos de recuperaci*n 0manual o autom)tica1 restauran
apropiadamente la 2ase de datos$ aplicaciones ! sistemas$ ! los llevan a un estado
conocido o deseado. .os si%uientes tipos de condiciones deben incluirse en la prueba:
3Interrupci*n de electricidad en el cliente.
3Interrupci*n de electricidad en el servidor
3Interrupci*n en la comunicaci*n &acia el servidor 0ca(das de red1
3Interrupci*n en la comunicaci*n con los controladores de disco.
39iclos incompletos 0procesos de consultas interrumpidos$ procesos de
sincronizaci*n de datos interrumpidos1
3.laves o apuntadores de base de datos inv)lidos
3Elementos corruptos o inv)lidos en la base de datos.
escripci*n de la #rueba:
Estas pruebas ase%uran "ue una aplicaci*n o sistema se recupere de una
variedad de anomal(as de &ardware$ software o red con p'rdidas de datos o fallas de
inte%ridad.
.as pruebas de tolerancia a fallas ase%uran "ue$ para a"uellos sistemas "ue deben
mantenerse corriendo$ cuando una condici*n de falla ocurre$ los sistemas alternos o de
respaldo pueden tomar control del sistema sin p'rdida de datos o transacciones.
.as pruebas de recuperaci*n son contrarias a las pruebas en "ue la aplicaci*n o sistema
es e6puesto a condiciones e6tremas 0o condiciones simuladas1$ tales como fallas en
dispositivos en entradaBsalida o llaves o apuntadores inv)lidos de base de datos. .os
procesos de recuperaci*n se invocan ! la aplicaci*n es monitoreada !Bo inspeccionada
para verificar "ue 'stos mecanismos se &an ejecutado en forma apropiada.
El objetivo de esta prueba es determinar la &abilidad del sistema para recuperarse de una
falla de &ardware o software. Esta prueba eval@a 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. .a recuperaci*n debe ser considerada en el
proceso de dise4o. Errores de pro%ramaci*n o de datos pueden ser incorporados e6
profeso en un sistema para determinar si se puede recuperar de ellos. .as fallas de
e"uipo 0por ejemplo errores de paridad en memoria$ errores en dispositivos de
entradaBsalida1 pueden ser simuladas.
#rueba de 9ompatibilidad ! 9onversi*n
/bjetivo de la #rueba:
2uscar problemas de compatibilidad ! conversi*n en los sistemas.
escripci*n de la #rueba:
El prop*sito es demostrar "ue los objetivos de compatibilidad no &an sido lo%rados
! "ue los procedimientos de conversi*n no funcionan.
.a ma!or(a de los pro%ramas "ue se desarrollan no son completamente nuevos5 con
frecuencia son reemplazos de partes deficientes$ !a sea de sistemas de procesamiento
de datos$ o sistemas manuales.
9omo tales$ los pro%ramas tienen a menudo objetivos espec(ficos con respecto a su
compatibilidad ! a sus procedimientos de conversi*n con el sistema e6istente.
#ruebas de <UI
/bjetivo de la #rueba: 8erifica lo si%uiente:
3 .a nave%aci*n a trav's de los objetos de la prueba reflejan las
funcionalidades del ne%ocio ! re"uisitos$ se realiza una nave%aci*n ventana por ventana$
usando los modos de acceso 0tabuladores$ movimientos del mouse$ teclas r)pidas$ etc1
3 .os objetos de la ventana ! caracter(sticas$ tales como men@s$ medidas$
posiciones$ estados ! focos se verifican conforme a los est)ndares.
escripci*n de la #rueba:
.a prueba de interfaz de usuario verifica la interacci*n del usuario con el software.
El objetivo es ase%urar "ue la interfaz tiene apropiada nave%aci*n a trav's de las
diferentes funcionalidades. ;dicionalmente$ las pruebas de interfaz ase%uran "ue los
objetos de la interfaz a ser probada se encuentra dentro de los estandares de la industria
#rueba de Instalaci*n
/bjetivo de la #rueba: 8erificar ! validar "ue el sistema se instala apropiadamente
en cada cliente$ bajo las si%uientes condiciones:
3Instalaciones nuevas$ nuevas m)"uinas a las "ue nunca se les &a instalado el
sistema.
3;ctualizar m)"uinas previamente instaladas con el sistema.
3Instalar versiones viejas en m)"uinas previamente instaladas con el sistema.
escripci*n de la #rueba:
.as pruebas de instalaci*n tienen dos prop*sitos. El primero es ase%urar "ue el
sistema puede ser instalado en todas las confi%uraciones posibles$ tales como nuevas
instalaciones$ actualizaciones$ instalaciones completas o personalizadas$ ! bajo
condiciones normales o anormales5 estas @ltimas inclu!en insuficiente espacio en disco$
falta de privile%ios para al%unas tareas$ etc.
El se%undo prop*sito es verificar "ue$ una vez instalado$ el sistema opera correctamente.
Esto usualmente implica correr un n@mero si%nificativo de pruebas de Auncionalidad.
#ruebas Auncionales
/bjetivo de la #rueba:
Se ase%ura la trabajo apropiado de los re"uisitos funcionales$ inclu!endo la
nave%aci*n$ entrada de datos$ procesamiento ! obtenci*n de resultados
escripci*n de la #rueba:
.as pruebas Auncionales deben enfocarse en los re"uisitos funcionales$ las
pruebas pueden estar basadas directamente en los 9asos de Uso 0o funciones de
ne%ocio1$ ! las re%las del ne%ocio. .as metas de estas pruebas son:
3 8erificar la apropiada aceptaci*n de datos$
3 8erificar el procesamiento ! recuperaci*n ! la implementaci*n adecuada de
las re%las del ne%ocio.
Este tipo de pruebas est)n basadas en t'cnicas de caja ne%ra$ "ue es$ verificar la
aplicaci*n 0! sus procesos internos1 mediante la interacci*n con la aplicaci*n v(a <UI !
analizar la salida 0resultados1. .o "ue se identifica a continuaci*n es un dise4o preliminar
de las pruebas recomendadas para cada aplicaci*n.