Post on 30-Oct-2015
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 1/34
ESTRATEGIAS DE PRUEBA DEL SW
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 2/34
• Introducción• Un enfoque estratégico• Aspectos estratégicos de un software• Prueba de unidad• Prueba de integración• Prueba de Validación• Prueba del sistema• El arte de la depuración
CONTENIDO
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 3/34
Integra las técnicas de diseño de casosde prueba en una serie de pasos bien
planificados que dan como resultadouna correcta construcción del software.
También describe un mapa con los
pasos que hay que llevar acabo comoparte de la prueba, cuando se debeplanificar y realizar esos pasos, cuantoesfuerzo, tiempo y recursos se van arequerir.
ESTRATEGIAS DE PRUEBA DEL SW
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 4/34
UN ENFOQUE ESTRATÉGICO PARALAS PRUEBAS DEL SW
Las pruebas comienzan a nivel de modulo ytrabajan hacia fuera.
Según el momento son apropiadas diferentes
técnicas de prueba. La prueba la lleva acabo el responsable del
desarrollo del SW. La prueba y la depuración son actividades
diferentes, pero la depuración se debe incluir encualquier estrategia de prueba.
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 5/34
VERIFICACIÓN Y VALIDACIÓN (V &V) La verificación se refiere al conjunto de
actividades que asegura que el softwareimplementa adecuadamente una funciónespecífica.
La validación se refiere a un conjunto diferente deactividades que aseguran que el softwareconstruido se ajusta a lo requerimientos delcliente.
Bohem, lo define de otra forma: Verificación “¿Estamos construyendo el producto
correctamente?” Validación “¿Estamos construyendo el producto
correcto?”
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 6/34
ORGANIZACIÓN PARA LAS PRUEBAS
DEL SW
No es correcto:
El responsable del desarrollo no debería entrar
en la prueba.
El SW debe ser puesto a salvo de personas quepuedan probarlo de forma despiadada.
Los encargados de la prueba solo aparecencuando comienzan las etapas de la prueba.
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 7/34
UNA ESTRATEGIA DE
PRUEBA DEL SW
La prueba en el contexto de espiral
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 8/34
Desde el punto de vista procedimental
UNA ESTRATEGIA DE PRUEBA DEL SW
Pruebas de
alto nivel
Dirección della prueba
Codificación
Diseño
Requisitos
Prueba de
unidad
Prueba deIntegración
Etapas de prueba del SW
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 9/34
CRITERIOS PARA COMPLETAR
LA PRUEBA Cada vez que se tratan de las pruebas del SW
surgen unas preguntas clásicas:¿Cuándo hemos terminado la prueba?¿Cómo 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 cínica es “Se termina la prueba cuando se agota el tiempo o el dinero disponible para
cada efecto ”
‘¿Cuando debemos probar?’
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 10/34
ASPECTOS ESTRATÉGICOS
Ton Gilb, plantea que se deban abordar lossiguientes 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 categoría de usuario.
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 11/34
Desarrollar un plan de prueba que haga hincapié en la prueba de ciclo rápido.
Construir un SW robusto diseñado para probarse
así mismo. Usar revisiones técnicas formales y efectivas como filtro antes de la prueba.
Llevar acabo revisiones técnicas formales para evaluar la estrategia de prueba y los propios casos de prueba.
Desarrollar un enfoque de manera continua al proceso de prueba. Debería medirse la estrategia de prueba.
ASPECTOS ESTRATÉGICOS
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 12/34
PRUEBA DE UNIDAD.
La prueba de unidad centra el proceso deverificación en la menor unidad del diseño delsoftware(Módulo). Aquí se prueban los caminos decontrol importantes, con el fin de descubrir errores dentro del ámbito de un módulo .
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 13/34
¿QUÉ ERRORES SON LOS MÁS COMUNES
DURANTE LA PRUEBA DE UNIDAD :
1. Procedencia aritmética incorrecta mal aplicada2. Operaciones de modo mezcladas.3. Inicializaciones incorrectas.4. Falta de precisión.5. Representación incorrecta de una expresión.
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 14/34
PRUEBA DE INTEGRACIÓN.
“Si todos funcionan bien ¿Por qué dudar de que no funcionen todos juntos?”
La prueba de Integración es una técnica sistemáticapara construir la estructura del programa mientrasque al mismo tiempo, se llevan a cabo pruebas
para detectar errores asociados con la interacción.
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 15/34
TIPOS DE INTEGRACIÓN.
La primera es no incremental “big bang” . Secombinan todos los módulos por anticipado, se
prueba todo el producto.La segunda es una integración incremental en dondese desarrollan módulos pequeños y funcionales quehacen que los errores sean más fácil de aislar ycorregir.
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 16/34
INTEGRACIÓN DESCENDENTE.
Es una estrategia de integración incremental a laconstrucción de la estructura de programas, en cual se
integran los módulos moviéndose en dirección haciaabajo por la jerarquía de control comenzando con elmódulo principal .
Los módulos subordinados al módulo de controlprincipal se incorpora en la estructura, de forma primero-en-profundidad , ó primero-en-anchura
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 17/34
EJEMPLO.
M1
M2 M3 M4
M5 M6 M7
M8
M3 M4
M6M6
M3
M7
M4
M7
Integración descendente
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 18/34
INTEGRACIÓN ASCENDENTE.
Es un modelo de integración no incremental, endonde la construcción del diseño empiez a de los
módulos atómicos (es decir, módulos de los nivelesmas bajos de la estructura del programa). Dado quelos módulos se integran de abajo hacia arriba , elproceso requerido de los módulos subordinadossiempre está disponible y elimina la
necesidad de resguardos.
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 19/34
LA PRUEBA DE REGRESIÓN.
Cada vez que se añade un nuevo modulo como
parte de una prueba de integración el software cambia . La prueba de regresión es volver a ejecutar
un subconjunto de pruebas que se han llevado acabo anteriormente para asegurarse de que loscambios no han propagado efectos colaterales nodeseados.
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 20/34
PRUEBA DE HUMO
La prueba de humo es un método de prueba de
integración que es comúnmente utilizada cuando seha desarrollado un software “empaquetado ”. Esdiseñado como una mecanismo para proyectoscríticos por tiempos, permitiendo que el equipo desoftware valore su proyecto sobre una base sólida.
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 21/34
COMENTARIOS DE LA PRUEBA
La desventaja de la integración descendente es lanecesidad de resguardos. La principal desventaja de
la integración ascendente es que el “el programa como entidad no existe hasta que se haya añadido el ultimo módulo”. La selección de una estrategia de integracióndepende de las características del software y, aveces de la planificación del proyecto , en algunos delos casos se puede usar un enfoquecombinado(denominado pruebas Sándwich ).
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 22/34
La validación puede definirse de muchas formas,pero una simple definición es que la validación se
consigue cuando el software funciona de acuerdocon las expectativas razonables del cliente.
PRUEBA DE VALIDACIÓN.
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 23/34
La prueba alfa se lleva a cabo, por un cliente, en ellugar de desarrollo. Se usa el software de formanatural con el desarrollador como observador delusuario y registrando los errores y los problemas de
uso. Las pruebas alfa se llevan a cabo en un entornocontrolado.
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 unaaplicación «en vivo» del software en un entorno queno puede ser controlado por el desarrollador.
CRITERIOS DE LA PRUEBA DE VALIDACIÓN
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 24/34
Un problema típico es la «delegación de culpabilidad » , estoocurre cuando se descubre un error y cada uno de loscreadores de cada elemento del sistema echa la culpa delproblema a los otros. Se debe anticipar a los posiblesproblemas y:1.diseñar caminos de manejo de errores que prueben toda la
información 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 posibleserrores en la interfaz del software;
3.registrar los resultados de las pruebas como «evidencia » en el caso de que se le señale con el dedo;
4.participar en la planificación y el diseño de pruebas delsistema para asegurarse de que el software se prueba deforma adecuada.
PRUEBA DEL SISTEMA.
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 25/34
La prueba de recuperación es una prueba del sistemaque fuerza el fallo del software de muchas formas yverifica que la recuperación se lleva a cabo
apropiadamente. Si la recuperación es automática hayque evaluar la corrección de la inicialización, de losmecanismos de recuperación del estado del sistema, dela recuperación de datos y del proceso de re-arranque.Si la recuperación requiere la intervención humana,hay que evaluar los tiempos medios de reparación(TMR) para determinar si están dentro de unos límitesaceptables.
PRUEBA DE RECUPERACIÓN.
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 26/34
Este acceso al sistema incluye un amplio rango deactividades: «piratas informáticos» que intentan entrar enlos sistemas por deporte, empleados disgustados queintentan penetrar por venganza e individuos deshonestosque intentan penetrar para obtener ganancias personalesilícitas.La prueba de seguridad intenta verificar que los
mecanismos de protección incorporados en el sistema loprotegerán, de hecho, de accesos impropios.
PRUEBA DE SEGURIDAD.
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 27/34
La prueba de resistencia ejecuta un sistema de forma quedemande recursos en cantidad, frecuencia o volúmenesanormales. Por ejemplo:
1.incrementar las frecuencias de datos de entrada en un ordende magnitud con el fin de comprobar cómo responden lasfunciones de entrada;
2.diseñar pruebas especiales que generen diez, interrupcionespor segundo, cuando las normales son una o dos;
3.ejecutar casos de prueba que requieran el máximo de memoriao de otros recursos;
4.diseñar casos de prueba que puedan dar problemas en unsistema operativo virtual
PRUEBA DE RESISTENCIA (STRESS)
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 28/34
La prueba de rendimiento está diseñada para probar elrendimiento del software en tiempo de ejecucióndentro del contexto de un sistema integrado.
La prueba de rendimiento se da durante todos lospasos del procesó de la prueba. Incluso al nivel deunidad, se debe asegurar el rendimiento de los módulosindividuales a medida que se llevan a cabo las pruebas
de caja blanca. Sin embargo, hasta que no estáncompletamente integrados todos los elementos delsistema no se puede asegurar realmente el rendimientodel sistema.
PRUEBA DE RENDIMIENTO.
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 29/34
La depuración ocurre como consecuencia de una pruebaefectiva. Es decir, cuando un caso de prueba descubreun error, la depuración es el proceso que provoca laeliminación del error.
Aunque la depuración puede y debe ser un procesoordenado, sigue teniendo mucho de arte. Un ingenierodel software, al evaluar los resultados de una prueba, seencuentra frecuentemente con una indicación
«sintomática» de un problema en el software. Es decir,la manifestación externa de un error, y la causa internadel error pueden no estar relacionadas de una formaobvia. El proceso mental, apenas comprendido, queconecta un síntoma con una causa es la depuración.
EL ARTE DE LA DEPURACIÓN.
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 30/34
La depuración no es una prueba , pero siempre ocurre comoconsecuencia de la prueba. El proceso de depuración siempretiene 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 depuración debesospechar la causa, diseñar un caso de prueba que ayude a
confirmar sus sospechas y el trabajo vuelve hacia atrás a lacorrección del error de una forma iterativa.Durante la depuración encontramos errores que van desde loligeramente inesperado (por ejemplo, un formato de salidaincorrecto) hasta lo catastrófico (por ejemplo, el sistema falla,produciéndose serios daños económicos o físicos).
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 31/34
EL PROCESO DE DEPURACIÓN
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 32/34
Desafortunadamente, todo parece indicar que lahabilidad en la depuración es un rasgo innato del serhumano. A ciertas personas se les da bien y a otras
no. Aunque las manifestaciones experimentales de ladepuración están abiertas a muchasinterpretaciones, se han detectado grandesvariaciones en la destreza para la depuración dedistintos programadores con el mismo bagaje deformación y de experiencia.
CONSIDERACIONES PSICOLÓGICAS
7/16/2019 Estrategia de Prueba
http://slidepdf.com/reader/full/estrategia-de-prueba 33/34
ENFOQUES DE LA DEPURACIÓN.
Depuración por fuerza bruta es la más común y menos eficientea la hora de aislar la causa del error en el software. Aplicamos ladepuración por fuerza bruta cuando todo lo demás falla.La vuelta atrás es un enfoque más normal porque se puede usar
con éxito para pequeños programas. Partiendo del lugar dondese descubre el síntoma, se recorre hacia atrás el código fuentehasta que se llega a la posición de error. Pero a medida queaumenta el número de líneas del código, el número de posiblescaminos de vuelta se hace difícilmente manejable.la depuración eliminación de causas se manifiesta mediante
inducción o deducción e introduce el concepto de particiónbinaria. Los datos relacionados con la ocurrencia del error seorganizan para aislar las posibles causas. Se llega a una«hipótesis de causa» y se usan los datos anteriores para probaro revocar la hipótesis
BIBLIOGRAFIA