ESTRATEGIAS DE PRUEBA DEL SW

Introduccin
Un enfoque estratgico
Aspectos estratgicos de un software
Prueba de unidad
Prueba de integracin
Prueba de Validacin
Prueba del sistema
El arte de la depuracin
CONTENIDO
Integra las tcnicas de diseo de casos
de prueba en una serie de pasos bien
planificados que dan como resultado
una correcta construccin del software.

Tambin describe un mapa con los
pasos que hay que llevar acabo como
parte de la prueba, cuando se debe
planificar y realizar esos pasos, cuanto
esfuerzo, tiempo y recursos se van a
requerir.
ESTRATEGIAS DE PRUEBA DEL SW
UN ENFOQUE ESTRATGICO PARA
LAS PRUEBAS DEL SW
Las pruebas comienzan a nivel de modulo y
trabajan hacia fuera.
Segn el momento son apropiadas diferentes
tcnicas de prueba.
La prueba la lleva acabo el responsable del
desarrollo del SW.
La prueba y la depuracin son actividades
diferentes, pero la depuracin se debe incluir en
cualquier estrategia de prueba.
VERIFICACIN Y VALIDACIN (V &V)
La verificacin se refiere al conjunto de
actividades que asegura que el software
implementa adecuadamente una funcin
especfica.
La validacin se refiere a un conjunto diferente de
actividades que aseguran que el software
construido se ajusta a lo requerimientos del
cliente.

Bohem, lo define de otra forma:
Verificacin Estamos construyendo el producto
correctamente?
Validacin Estamos construyendo el producto
correcto?
ORGANIZACIN PARA LAS PRUEBAS
DEL SW
No es correcto:

El responsable del desarrollo no debera entrar
en la prueba.

El SW debe ser puesto a salvo de personas que
puedan probarlo de forma despiadada.

Los encargados de la prueba solo aparecen
cuando comienzan las etapas de la prueba.




UNA ESTRATEGIA DE
PRUEBA DEL SW
La prueba en el contexto de espiral
Desde el punto de vista procedimental
UNA ESTRATEGIA DE PRUEBA DEL SW
Pruebas de
alto nivel
Direccin del
la prueba
Codificacin

Diseo

Requisitos

Prueba de
unidad


Prueba de
Integracin


Etapas de prueba del SW
CRITERIOS PARA COMPLETAR
LA PRUEBA
Cada vez que se tratan de las pruebas del SW
surgen unas preguntas clsicas:
Cundo hemos terminado la prueba?
Cmo sabemos que hemos probado lo suficiente?
Una respuesta a la La prueba nuca termina ya que el
responsable carga o pasa el problema al cliente
Otra respuesta algo cnica es Se termina la prueba
cuando se agota el tiempo o el dinero disponible para
cada efecto
Cuando debemos probar?
ASPECTOS ESTRATGICOS
Ton Gilb, plantea que se deban abordar los
siguientes puntos si se desea implementar con
xito una estrategia de prueba del SW:
Especificar los requisitos del producto de
manera cuantificable mucho antes que
comiencen las pruebas.
Establecer los objetivos de la prueba de
manera explicita.
Comprender que usuarios van a manejar el SW
y desarrollar un perfil para cada categora de
usuario.
Desarrollar un plan de prueba que haga hincapi
en la prueba de ciclo rpido.
Construir un SW robusto diseado para probarse
as mismo.
Usar revisiones tcnicas formales y efectivas
como filtro antes de la prueba.
Llevar acabo revisiones tcnicas formales para
evaluar la estrategia de prueba y los propios
casos de prueba.
Desarrollar un enfoque de manera continua al
proceso de prueba. Debera medirse la estrategia
de prueba.
ASPECTOS ESTRATGICOS
PRUEBA DE UNIDAD.
La prueba de unidad centra el proceso de
verificacin en la menor unidad del diseo del
software(Mdulo). Aqu se prueban los caminos de
control importantes, con el fin de descubrir errores
dentro del mbito de un mdulo.

QU ERRORES SON LOS MS COMUNES
DURANTE LA PRUEBA DE UNIDAD :

1. Procedencia aritmtica incorrecta mal aplicada
2. Operaciones de modo mezcladas.
3. Inicializaciones incorrectas.
4. Falta de precisin.
5. Representacin incorrecta de una expresin.

PRUEBA DE INTEGRACIN.
Si todos funcionan bien
Por qu dudar de que no funcionen todos juntos?

La prueba de Integracin es una tcnica sistemtica
para construir la estructura del programa mientras
que al mismo tiempo, se llevan a cabo pruebas
para detectar errores asociados con la interaccin.
TIPOS DE INTEGRACIN.
La primera es no incremental big bang. Se
combinan todos los mdulos por anticipado, se
prueba todo el producto.
La segunda es una integracin incremental en donde
se desarrollan mdulos pequeos y funcionales que
hacen que los errores sean ms fcil de aislar y
corregir.
INTEGRACIN DESCENDENTE.
Es una estrategia de integracin incremental a la
construccin de la estructura de programas, en cual se
integran los mdulos movindose en direccin hacia
abajo por la jerarqua de control comenzando con el
mdulo principal .

Los mdulos subordinados al mdulo de control
principal se incorpora en la estructura, de forma
primero-en-profundidad, primero-en-anchura
EJEMPLO.
M1
M2 M3 M4
M5 M6 M7
M8
M3 M4
M6 M6
M3
M7
M4
M7
Integracin descendente
INTEGRACIN ASCENDENTE.
Es un modelo de integracin no incremental, en
donde la construccin del diseo empieza de los
mdulos atmicos (es decir, mdulos de los niveles
mas bajos de la estructura del programa). Dado que
los mdulos se integran de abajo hacia arriba, el
proceso requerido de los mdulos subordinados
siempre est disponible y elimina la
necesidad de resguardos.
LA PRUEBA DE REGRESIN.
Cada vez que se aade un nuevo modulo como
parte de una prueba de integracin el software
cambia.
La prueba de regresin es volver a ejecutar
un subconjunto de pruebas que se han llevado a
cabo anteriormente para asegurarse de que los
cambios no han propagado efectos colaterales no
deseados.
PRUEBA DE HUMO
La prueba de humo es un mtodo de prueba de
integracin que es comnmente utilizada cuando se
ha desarrollado un software empaquetado. Es
diseado como una mecanismo para proyectos
crticos por tiempos, permitiendo que el equipo de
software valore su proyecto sobre una base slida.
COMENTARIOS DE LA PRUEBA
La desventaja de la integracin descendente es la
necesidad de resguardos. La principal desventaja de
la integracin ascendente es que el el
programa como entidad no existe hasta que se haya
aadido el ultimo mdulo.
La seleccin de una estrategia de integracin
depende de las caractersticas del software y, a
veces de la planificacin del proyecto, en algunos de
los casos se puede usar un enfoque
combinado(denominado pruebas Sndwich).
La validacin puede definirse de muchas formas,
pero una simple definicin es que la validacin se
consigue cuando el software funciona de acuerdo
con las expectativas razonables del cliente.
PRUEBA DE VALIDACIN.
La prueba alfa se lleva a cabo, por un cliente, en el
lugar de desarrollo. Se usa el software de forma
natural con el desarrollador como observador del
usuario y registrando los errores y los problemas de
uso. Las pruebas alfa se llevan a cabo en un entorno
controlado.

La prueba beta se lleva a cabo por los usuarios finales
del software en los lugares de trabajo de los clientes.
A diferencia de la prueba alfa, el desarrollador no est
presente normalmente. As, la prueba beta es una
aplicacin en vivo del software en un entorno que
no puede ser controlado por el desarrollador.
CRITERIOS DE LA PRUEBA DE
VALIDACIN
Un problema tpico es la delegacin de culpabilidad, esto
ocurre cuando se descubre un error y cada uno de los
creadores de cada elemento del sistema echa la culpa del
problema a los otros. Se debe anticipar a los posibles
problemas y:
1.disear caminos de manejo de errores que prueben toda la
informacin procedente de los elementos del sistema;
2.llevar a cabo una serie de pruebas que simulen la
presencia de datos en mal estado o de otros posibles
errores en la interfaz del software;
3.registrar los resultados de las pruebas como evidencia
en el caso de que se le seale con el dedo;
4.participar en la planificacin y el diseo de pruebas del
sistema para asegurarse de que el software se prueba de
forma adecuada.
PRUEBA DEL SISTEMA.
La prueba de recuperacin es una prueba del sistema
que fuerza el fallo del software de muchas formas y
verifica que la recuperacin se lleva a cabo
apropiadamente. Si la recuperacin es automtica hay
que evaluar la correccin de la inicializacin, de los
mecanismos de recuperacin del estado del sistema, de
la recuperacin de datos y del proceso de re-arranque.
Si la recuperacin requiere la intervencin humana,
hay que evaluar los tiempos medios de reparacin
(TMR) para determinar si estn dentro de unos lmites
aceptables.
PRUEBA DE RECUPERACIN.
Este acceso al sistema incluye un amplio rango de
actividades: piratas informticos que intentan entrar en
los sistemas por deporte, empleados disgustados que
intentan penetrar por venganza e individuos deshonestos
que intentan penetrar para obtener ganancias personales
ilcitas.
La prueba de seguridad intenta verificar que los
mecanismos de proteccin incorporados en el sistema lo
protegern, de hecho, de accesos impropios.
PRUEBA DE SEGURIDAD.
La prueba de resistencia ejecuta un sistema de forma que
demande recursos en cantidad, frecuencia o volmenes
anormales. Por ejemplo:
1.incrementar las frecuencias de datos de entrada en un orden
de magnitud con el fin de comprobar cmo responden las
funciones de entrada;
2.disear pruebas especiales que generen diez, interrupciones
por segundo, cuando las normales son una o dos;
3.ejecutar casos de prueba que requieran el mximo de memoria
o de otros recursos;
4.disear casos de prueba que puedan dar problemas en un
sistema operativo virtual
PRUEBA DE RESISTENCIA (STRESS)
La prueba de rendimiento est diseada para probar el
rendimiento del software en tiempo de ejecucin
dentro del contexto de un sistema integrado.

La prueba de rendimiento se da durante todos los
pasos del proces de la prueba. Incluso al nivel de
unidad, se debe asegurar el rendimiento de los mdulos
individuales a medida que se llevan a cabo las pruebas
de caja blanca. Sin embargo, hasta que no estn
completamente integrados todos los elementos del
sistema no se puede asegurar realmente el rendimiento
del sistema.
PRUEBA DE RENDIMIENTO.
La depuracin ocurre como consecuencia de una prueba
efectiva. Es decir, cuando un caso de prueba descubre
un error, la depuracin es el proceso que provoca la
eliminacin del error.

Aunque la depuracin puede y debe ser un proceso
ordenado, sigue teniendo mucho de arte. Un ingeniero
del software, al evaluar los resultados de una prueba, se
encuentra frecuentemente con una indicacin
sintomtica de un problema en el software. Es decir,
la manifestacin externa de un error, y la causa interna
del error pueden no estar relacionadas de una forma
obvia. El proceso mental, apenas comprendido, que
conecta un sntoma con una causa es la depuracin.
EL ARTE DE LA DEPURACIN.
La depuracin no es una prueba, pero siempre ocurre como
consecuencia de la prueba. El proceso de depuracin siempre
tiene uno de los dos resultados siguientes:

1. se encuentra la causa, se corrige y se elimina;
2. o no se encuentra la causa.

En este ltimo caso, la persona que realiza la depuracin debe
sospechar la causa, disear un caso de prueba que ayude a
confirmar sus sospechas y el trabajo vuelve hacia atrs a la
correccin del error de una forma iterativa.
Durante la depuracin encontramos errores que van desde lo
ligeramente inesperado (por ejemplo, un formato de salida
incorrecto) hasta lo catastrfico (por ejemplo, el sistema falla,
producindose serios daos econmicos o fsicos).
EL PROCESO DE DEPURACIN
Desafortunadamente, todo parece indicar que la
habilidad en la depuracin es un rasgo innato del ser
humano. A ciertas personas se les da bien y a otras
no. Aunque las manifestaciones experimentales de la
depuracin estn abiertas a muchas
interpretaciones, se han detectado grandes
variaciones en la destreza para la depuracin de
distintos programadores con el mismo bagaje de
formacin y de experiencia.

CONSIDERACIONES PSICOLGICAS
ENFOQUES DE LA DEPURACIN.
Depuracin por fuerza bruta es la ms comn y menos eficiente
a la hora de aislar la causa del error en el software. Aplicamos la
depuracin por fuerza bruta cuando todo lo dems falla.
La vuelta atrs es un enfoque ms normal porque se puede usar
con xito para pequeos programas. Partiendo del lugar donde
se descubre el sntoma, se recorre hacia atrs el cdigo fuente
hasta que se llega a la posicin de error. Pero a medida que
aumenta el nmero de lneas del cdigo, el nmero de posibles
caminos de vuelta se hace difcilmente manejable.
la depuracin eliminacin de causas se manifiesta mediante
induccin o deduccin e introduce el concepto de particin
binaria. Los datos relacionados con la ocurrencia del error se
organizan para aislar las posibles causas. Se llega a una
hiptesis de causa y se usan los datos anteriores para probar
o revocar la hiptesis
BIBLIOGRAFIA
Fairley R. Ingeniera de Software.

Pressman, R.S. Ingeniera del Software.
Un enfoque prctico.