Tecnicas De Pruebas

INDICE

UNIDAD 4: METODOS CONVENCIONALES DE LA INGENIERIA DE SOTWARE 1

4.4 METODOS DE PRUEBA DEL SOFTWARE 1

4.4.1 FUNDAMENTOS DE LAS PRUEBAS DE SOFTWARE 1

4.4.1.1 DIRECTRICES DE LA PRUEBA 1

4.4.1.2 PRINCIPIOS DE LA PRUEBA 1

4.4.1.3 FACILIDAD DE LA PRUEBA 1

4.4.1.4 CLASES DE PRUEBAS 2

4.4.2 PRUEBAS DE CAJA BLANCA 2

4.4.2.1 PRUEBA DEL CAMINO BASICO 2

A. MATRICES DE GRAFO 3

4.4.2.2 PRUEBA DE LA ESTRUCTURA DE CONTROL 4

A. PRUEBA DE CONDICION 4

A. PRUEBA DE BUCLES 4

4.4.3 PRUEBAS DE CAJA NEGRA 5

4.4.3.1 PRUEBAS BASADAS EN GRAFOS 6

4.4.3.2 PARTICION EQUIVALENTE 6

4.4.3.3 ANALISIS DE VALORES LIMITE 7

4.4.3.4 PRUEBA DE COMPARACION 7

4.4.4 PRUEBA DE ENTORNOS ESPECIALIZADOS 7

4.4.4.1 PRUEBA DE INTERFACES GRAFICAS DE USUARIO 7

4.4.4.2 PRUEBA DE ARQUITECTURA CLIENTE / SERVIDOR 7

4.4.4.3 PRUEBA DE DOCUMENTACIÓN Y AYUDA 8

4.4.4.4 PRUEBA DE SISTEMAS EN TIEMPO REAL 8

4.4.2 ESTRATEGIA DE PRUEBA DEL SOFTWARE 8

4.4.5.1 ORGANIZACIÓN DE LA PRUEBA DEL SOFTWARE 9

4.4.2.2 CRITERIOS PARA COMPLETAR LA PRUEBA DEL SOFTWARE 10

4.4.2.3 ASPECTOS ESTRATÉGICOS PREVIOS 10

4.4.2.4 PRUEBA DE UNIDAD 10

4.4.2.5 PRUEBA DE INTEGRACION 11

A. INTEGRACIÓN DESCENDENTE 11

B. INTEGRACIÓN ASCENDENTE 12

C. PRUEBA DE REGRESION 12

d. SUGERENCIAS GENERALES PARA LA APLICACIÓN DE LA PRUEBA DE INTEGRACION 13

4.4.2.6 PRUEBA DE VALIDACION 13

A. PRUEBAS ALFA Y BETA 13

4.4.2.7 PRUEBA DEL SISTEMA 13

A. PRUEBA DE RECUPERACION 14

B. PRUEBA DE SEGURIDAD 14

C. PRUEBA DE RESISTENCIA 14

D. PRUEBA DE RENDIMIENTO 14

e. ESTRATEGIA DE DESARROLLO DE LA PRUEBA DE SISTEMA 14

4.4.2.8 DOCUMENTACION DE LA PRUEBA 14

4.4.2.9 EL ARTE DE LA DEPURACION 15

A. FUERZA BRUTA 15

b. VUELTA ATRAS 16

C. ELIMINACION DE CAUSAS 16

D. RECOMENDACIONES ADICIONALES 16

4.5 IMPLANTACION (CONVERSIÓN) 16

4.5 PRODUCCION 17

4.6 MANTENIMIENTO 17

UNIDAD 4: METODOS CONVENCIONALES DE LA INGENIERIA DE SOTWARE

4.4 METODOS DE PRUEBA DEL SOFTWARE

La prueba del software es un elemento crucial para garantizar la calidad de un software y permite validar las especificaciones, el diseño y de la programación. Con esto en mente, en esta sección del documento se busca detallar de la mejor forma los métodos y estrategias de prueba de software que pueden aplicarse, razón por la cual la misma se basa en los capítulos 16 y 17 “Métodos de prueba del software” y “Estrategias de prueba del software” del libro “Ingeniería del Software: Un enfoque práctico”, 4ta. Edición, de Roger S. Pressman, al presentar estos un compendio de conceptos, conocimientos y elementos claros y concisos.

4.4.1 FUNDAMENTOS DE LAS PRUEBAS DE SOFTWARE

Las pruebas de software se fundamentan en cuatro elementos que serán detallados a continuación:

• Las directrices a seguir;

• Los principios a ser considerados;

• Su facilidad; y,

• Las clases de pruebas.

4.4.1.1 DIRECTRICES DE LA PRUEBA

• Proceso de ejecución de un programa con la intención de descubrir un error;

• Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces; y,

• Una prueba tiene éxito si descubre un error no detectado hasta entonces.

Sin embargo de esto, “la prueba no puede asegurar la ausencia de defectos, solo puede demostrar que existen defectos de software” .

4.4.1.2 PRINCIPIOS DE LA PRUEBA

• A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del cliente;

• Las pruebas deberían planificarse mucho antes de que empiecen (la planificación puede comenzar al final de la fase de análisis y la definición de casos de prueba al final de la fase de diseño);

• El principio de Pareto es aplicable a la prueba de software (80% de los errores descubiertos durante las pruebas surgen al hacer un seguimiento de solo el 20% de todos los módulos del programa);

• Las pruebas deberían empezar por lo pequeño y progresar hacia lo grande;

• No son posibles las pruebas exhaustivas; y,

• Para ser más efectivas, las pruebas deberían ser conducidas por un equipo independiente.

4.4.1.3 FACILIDAD DE LA PRUEBA

Un software debe ser diseñado con “facilidad para hacer pruebas” en mente, es decir, que permita ser probado más fácilmente, para esto, Roger Pressman recomienda considerar los siguientes parámetros determinados por James Bach:

• Operatividad: Cuanto mejor funcione el software, más eficientemente se puede probar;

• Observabilidad: Lo que se ve es lo que se prueba;

• Controlabilidad: Cuanto mejor se pueda controlar el software, más se puede automatizar y optimizar;

• Capacidad de descomposición: Si se controla el alcance de las pruebas, se puede aislar más rápidamente los problemas y llevar a cabo mejores pruebas de regresión;

• Simplicidad: Cuanto menos haya que probar, más rápidamente podremos probarlo;

• Estabilidad: Cuanto menos cambios, menos interrupciones a las pruebas; y,

• Facilidad de la comprensión: Cuanta más información tengamos, más inteligentes serán las pruebas.

Además, según Kaner, Falk y Nguyen una buena prueba debe tener los siguientes atributos:

• Alta probabilidad de encontrar un error;

• Falta de redundancia;

• Ser la mejor de todas las propuestas; y,

• No debería ser ni demasiado sencilla ni demasiado compleja.

4.4.1.4 CLASES DE PRUEBAS

El diseño de caso de pruebas se basa en los tipos de prueba existentes, que básicamente son dos:

• Pruebas de caja blanca; y,

• Pruebas de caja negra

En las dos secciones siguientes hablaremos de las características de las mismas y los tipos específicos de pruebas existentes.

4.4.2 PRUEBAS DE CAJA BLANCA

Las pruebas de caja blanca constituyen un minucioso examen de los detalles procedimentales, usando la estructura de control del diseño procedimental para crear casos de pruebas con lo cual:

• Se garantiza que se recorra por lo menos una vez los caminos independientes de

...