estrategia de prueba

7/16/2019 Estrategia de Prueba

http://slidepdf.com/reader/full/estrategia-de-prueba 1/34

ESTRATEGIAS DE PRUEBA DEL SW



• 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



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



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.



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?”



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.



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

Dirección della prueba

Codificación

Diseño

Requisitos

Prueba de

unidad

Prueba deIntegración

Etapas de prueba del SW



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?’



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.



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



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 .



¿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.



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.



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.



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



EJEMPLO.

M1

M2 M3 M4

M5 M6 M7

M8

M3 M4

M6M6

M3

M7

M4

M7

Integración descendente



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.



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.



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.



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 ).



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.



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



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.



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.



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.



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)



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.



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.



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).



EL PROCESO DE DEPURACIÓN



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



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



BIBLIOGRAFIA

Fairley R. Ingenier í a de Software .

Pressman, R.S. Ingenier í a del Software.Un enfoque pr áctico .

estrategia de prueba

Documents