Pruebas del software parte 2

Presentación del tema: "Pruebas del software parte 2"— Transcripción de la presentación:

1 Pruebas del software parte 2
Laura Patricia Pinto Prieto Pruebas del software parte 2

2 Diseño de casos de prueba
Prueba de caja negra :Conociendo la función específica para la que fue diseñado el producto, se pueden llevar a cabo pruebas que demuestren que cada función es completamente operativa y, al mismo, tiempo buscando errores en cada función; Prueba de caja blanca : Conociendo el funcionamiento del producto, se pueden desarrollar pruebas que aseguren que «todas las piezas encajan», o sea, que la operación interna se ajusta a las especificaciones y que todos los componentes internos se han comprobado de forma adecuada.

3 Diseño de casos de prueba. Enfoques principales
fig. p.398 (Piattini et al. 96). Profesor: Juan Antonio López Quesada Pruebas de Software (Piattini et al. 96)

4 Diseño de casos de prueba. Comparación de los Enfoques principales
a) Enfoque estructural o de caja blanca (transparente): se centra en la estructura interna del programa para elegir los casos de prueba la prueba exhaustiva consistiría en probar todos los posibles caminos de ejecución nº caminos lógicos  ( buscar los más importantes) b) Enfoque funcional o de caja negra: para derivar los casos, se estudia la especificación de las funciones, la entrada y la salida. No son excluyentes. * En (Pressman 98) p. 305 hay un ejemplo de lo impracticable que es usar caja blanca de forma exhaustiva: Programa en C de 100 líneas con 2 bucles, de 1 a 20 iteraciones máximo dentro del bucle interior, 4 if-then-else => 1014 caminos posibles * Otro ejemplo (Myers 79): prog. de 50 líneas con 25 IF en serie: nº total de caminos: 250 = 33,5 millones de secuencias potenciales. Profesor: Juan Antonio López Quesada Pruebas de Software

5 Prueba de caja Negra Las pruebas de caja negra, también denominada prueba de comportamiento, se centran en los requisitos funcionales del software. O sea, la prueba de caja negra permite al ingeniero del software obtener conjuntos de condiciones de entrada que ejerciten completamente todos los requisitos funcionales de un programa. La prueba de caja negra intenta encontrar errores de las siguientes categorías: (1) funciones incorrectas o ausentes, (2) errores de interfaz, (3) errores en estructuras de datos o en accesos a bases de datos externas, (4) errores de rendimiento y (5) errores de inicialización y de terminación. Con este tipo de prueba se usa la estructura de control del diseño procedimental (o el programa directamente) para conseguir los casos de prueba. Profesor: Juan Antonio López Quesada Pruebas de Software

6 Preguntas ¿Cómo se prueba la validez funcional?
¿Cómo se prueba el rendimiento y el comportamiento del sistema? ¿Qué clases de entrada compondrán unos buenos casos de prueba? ¿Es el sistema particularmente sensible a ciertos valores de entrada? ¿De qué forma están aislados los límites de una clase de datos? ¿Qué volúmenes y niveles de datos tolerará el sistema? ¿Qué efectos sobre la operación del sistema tendrán combinaciones específicas de datos?

7 Partición equivalente La partición equivalente es un método de prueba de caja negra que divide el campo de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba. Las clases de equivalencia se pueden definir de acuerdo con las siguientes directrices: 1. Si una condición de entrada especifica un rango, se define una clase de equivalencia válida y dos no válidas. 2. Si una condición de entrada requiere un valor específico, se define una clase de equivalencia válida y dos no válidas. 3. Si una condición de entrada especifica un miembro de un conjunto, se define una clase de equivalencia válida y una no válida. 4. Si una condición de entrada es lógica, se define una clase de equivalencia válida y una no válida.

8 Análisis de valores límite
Por razones que no están del todo claras, los errores tienden a darse más en los límites del campo de entrada que en el «centro». Por ello, se ha desarrollado el análisis de valores límites (AVL) como técnica de prueba. El análisis de valores límite nos lleva a una elección de casos de prueba que ejerciten los valores límite.

9 Las directrices de AVL 1. Si una condición de entrada especifica un rango delimitado por los valores a y b, se deben diseñar casos de prueba para los valores a y b, y para los valores justo por debajo y justo por encima de a y b, respectivamente. 2. Si una condición de entrada especifica un número de valores, se deben desarrollar casos de prueba que ejerciten los valores máximo y mínimo. También se deben probar los valores justo por encima y justo por debajo del máximo y del mínimo. 3. Aplicar las directrices 1 y 2 a las condiciones de salida. Por ejemplo, supongamos que se requiere una tabla de «temperatura / presión» como salida de un programa de análisis de ingeniería. Se deben diseñar casos de prueba que creen un informe de salida que produzca el máximo (y el mínimo) número permitido de entradas en la tabla. 4. Si las estructuras de datos internas tienen límites preestablecidos (por ejemplo, una matriz que tenga un límite definido de 100 entradas), hay que asegurarse de diseñar un caso de prueba que ejercite la estructura de datos en sus límites.

10 Prueba de comparación Hay situaciones (por ejemplo, aviónica de aeronaves, control de planta nuclear) en las que la fiabilidad del software es algo absolutamente crítico. En ese tipo de aplicaciones, a menudo se utiliza hardware y software redundante para minimizar la posibilidad de error. Cuando se desarrolla software redundante, varios equipos de ingeniería del software separados desarrollan versiones independientes de una aplicación, usando las mismas especificaciones. En esas situaciones, se deben probar todas las versiones con los mismos datos de prueba, para asegurar que todas proporcionan una salida idéntica. Luego, se ejecutan todas las versiones en paralelo y se hace una comparación en tiempo real de los resultados, para garantizar la consistencia.

11 Pruebas de entornos especializados, arquitecturas y aplicaciones
Prueba de interfaces gráficas de usuario Prueba de arquitectura cliente/servidor Prueba de sistemas de tiempo-real Prueba de la documentación y facilidades de ayuda : La prueba de la documentación se puede enfocar en dos fases. La primera fase, la revisión e inspección , examina el documento para comprobar la claridad editorial. La segunda fase, la prueba en vivo, utiliza la documentación junto al uso del programa real

12 ESTRATEGIAS DE PRUEBA DEL SW

13 UN ENFOQUE ESTRATÉGICO PARA LAS PRUEBAS DEL SW
Las pruebas comienzan a nivel de modulo y trabajan 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 en cualquier estrategia de prueba.

14 EL ARTE DE LA DEPURACIÓN.
La depuración ocurre como consecuencia de una prueba efectiva. Es decir, cuando un caso de prueba descubre un error, la depuración es el proceso que provoca la eliminación del error. Aunque la depuración 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 indicación «sintomática» de un problema en el software. Es decir, la manifestación 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 síntoma con una causa es la depuración.

15 La depuración no es una prueba, pero siempre ocurre como consecuencia de la prueba. El proceso de depuración siempre tiene uno de los dos resultados siguientes: se encuentra la causa, se corrige y se elimina; o no se encuentra la causa. En este último caso, la persona que realiza la depuración debe sospechar la causa, diseñar un caso de prueba que ayude a confirmar sus sospechas y el trabajo vuelve hacia atrás a la corrección del error de una forma iterativa. Durante la depuración encontramos errores que van desde lo ligeramente inesperado (por ejemplo, un formato de salida incorrecto) hasta lo catastrófico (por ejemplo, el sistema falla, produciéndose serios daños económicos o físicos).

16 EL PROCESO DE DEPURACIÓN

17 VERIFICACIÓN Y VALIDACIÓN (V &V)
La verificación se refiere al conjunto de actividades que asegura que el software implementa adecuadamente una función específica. La validación 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: Verificación “¿Estamos construyendo el producto correctamente?” Validación “¿Estamos construyendo el producto correcto?”

18 UNA ESTRATEGIA DE PRUEBA DEL SW
La prueba en el contexto de espiral

19 UNA ESTRATEGIA DE PRUEBA DEL SW
Desde el punto de vista procedimental Pruebas de alto nivel Dirección del la prueba Codificación Diseño Requisitos Prueba de unidad Prueba de Integración Etapas de prueba del SW

20 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? ‘¿Cuando debemos probar?’ 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”

21 ASPECTOS ESTRATÉGICOS
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 categoría de usuario.

22 PRUEBA DE UNIDAD. La prueba de unidad centra el proceso de verificación en la menor unidad del diseño del software(Módulo). Aquí se prueban los caminos de control importantes, con el fin de descubrir errores dentro del ámbito de un módulo.

23 ¿QUÉ ERRORES SON LOS MÁS COMUNES DURANTE LA PRUEBA DE UNIDAD :
Procedencia aritmética incorrecta mal aplicada Operaciones de modo mezcladas. Inicializaciones incorrectas. Falta de precisión. Representación incorrecta de una expresión.

24 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ática para construir la estructura del programa mientras que al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interacción.

25 TIPOS DE INTEGRACIÓN. La primera es no incremental “big bang”. Se combinan todos los módulos por anticipado, se prueba todo el producto. La segunda es una integración incremental en donde se desarrollan módulos pequeños y funcionales que hacen que los errores sean más fácil de aislar y corregir.

26 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 a cabo anteriormente para asegurarse de que los cambios no han propagado efectos colaterales no deseados.

27 COMENTARIOS DE LA PRUEBA
La desventaja de la integración descendente es la necesidad 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ón depende de las características del software y, a veces de la planificación del proyecto, en algunos de los casos se puede usar un enfoque combinado(denominado pruebas Sándwich).

28 PRUEBA DE VALIDACIÓN. 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 acuerdo con las expectativas razonables del cliente.

29 CRITERIOS DE LA PRUEBA DE VALIDACIÓN
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 aplicación «en vivo» del software en un entorno que no puede ser controlado por el desarrollador.

30 PRUEBA DE RECUPERACIÓN.
La prueba de recuperación es una prueba del sistema que fuerza el fallo del software de muchas formas y verifica que la recuperación se lleva a cabo apropiadamente. Si la recuperación es automática hay que evaluar la corrección de la inicialización, de los mecanismos de recuperación del estado del sistema, de la 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ímites aceptables.

31 PRUEBA DE SEGURIDAD. Este acceso al sistema incluye un amplio rango de actividades: «piratas informáticos» que intentan entrar en los sistemas por deporte, emplea­dos disgustados que intentan penetrar por venganza e individuos deshonestos que intentan penetrar para obtener ganancias personales ilícitas. La prueba de seguridad intenta verificar que los mecanismos de protección incorporados en el sistema lo protegerán, de hecho, de accesos impropios.

32 PRUEBA DE RESISTENCIA (STRESS)
La prueba de resistencia ejecuta un sistema de forma que demande recursos en cantidad, frecuencia o volúmenes anormales. Por ejemplo: incrementar las frecuencias de datos de entrada en un orden de magnitud con el fin de comprobar cómo responden las funciones de entrada; diseñar pruebas especiales que generen diez, interrupciones por segundo, cuando las normales son una o dos; ejecutar casos de prueba que requieran el máximo de memoria o de otros recursos; diseñar casos de prueba que puedan dar problemas en un sistema operativo virtual

33 PRUEBA DE RENDIMIENTO. La prueba de rendimiento está diseñada para probar el rendimiento del software en tiempo de ejecución dentro del contexto de un sistema integrado. .

34 BIBLIOGRAFIA Fairley R. Ingeniería de Software.
Pressman, R.S. Ingeniería del Software. Un enfoque práctico.