La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 1 Pruebas del Software l Dinámica: l En cada uno de los objetos que se te presentan,

Presentaciones similares


Presentación del tema: "©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 1 Pruebas del Software l Dinámica: l En cada uno de los objetos que se te presentan,"— Transcripción de la presentación:

1 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 1 Pruebas del Software l Dinámica: l En cada uno de los objetos que se te presentan, indique como lo probarían ? l Sus pruebas realizadas l Sus conclusiones

2 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 2

3 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 3

4 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 4 Para todos….

5 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 5 Pruebas del software l Existen dos fases de pruebas claramente diferenciables: Pruebas del componente, realizadas por el desarrollador del software. (pruebas de funcionamiento de los componentes claramente identificables) Pruebas de integración, realizadas por un equipo de pruebas independiente. (integración de componentes en subsistemas o sistemas completos

6 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 6 Fases de prueba Pruebas del componente Pruebas de integración Desarrollador de software Equipo de pruebas independiente

7 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 7 Pruebas del software l Desde una perspectiva de pruebas los sistemas OO difieren de los orientados a funciones porque: En los orientados a funciones existe una distinción entre las unidades básicas del programa (funciones) y las colecciones de éstas (módulos). En los sistemas OO no existe esta distinción. A menudo no existe una jerarquía clara de objetos.

8 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 8 Pruebas de defectos l El objetivo de estas pruebas es encontrar defectos en el software l Una prueba de defectos exitosa es aquella que logra que el software se comporte de una manera incorrecta l Las pruebas muestran la presencia no la ausencia de defectos

9 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 9 l Los datos de prueba son entradas que permiten probar el sistema l Los casos de prueba son entradas para probar el sistema y la predicción de las salidas que deberían ocurrir si el funcionamiento del sistema está de acuerdo a las especificaciones. Datos de prueba y casos de prueba

10 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 10 El proceso de pruebas de defectos Diseñar casos de prueba Preparar datos de prueba Ejecutar programas Comparar resul- tados con casos Informe prueba Resultados prueba Datos prueba Casos de prueba

11 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 11

12 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 12 Ejemplo: l Se deben probar todas las funciones del sistema que se acceden a través de menús l Se deben probar las combinaciones de funciones (formato a un texto) l Cuando el usuario introduce la entrada, todas las funciones deben probarse tanto con las entradas correctas como las incorrectas.

13 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 13

14 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 14

15 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 15

16 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 16

17 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 17

18 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 18 Prueba de caja negra l Se analizan las entradas y las salidas del sistemas sin analizar qué ocurre dentro de él l Los casos de prueba están basados en la especificación del sistema l La planificación de la prueba se puede empezar al inicio del proceso de desarrollo de software

19 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 19 Prueba de caja negra Entradas que causan salidas anormales Salidas que revelan la presencia de defectos

20 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 20 Ejemplo:

21 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 21 Particionamiento de equivalencia l Los datos de entrada y los resultados de salida a menudo caen en diferentes clases. Por ejemplo: números positivos, números negativos, cadenas con caracteres en blanco, etc. l El sistema tiende a comportarse en forma equivalente para cada una de estas clases. Por este motivo resulta útil identificar dichas clases al momento de probar. l Estas clases se denominan particiones de equivalencia.

22 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 22 Particiones de equivalencia

23 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 23 l Las entradas al sistema se dividen en sets de equivalencia l Ejemplo: Si una entrada es un entero 5-digit entre and , las particiones de equivalencia son l Por lo tanto se deben escoger los conjuntos de prueba entre estos límites: 00000, 09999, , , Particiones de equivalencia

24 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 24 Particiones de equivalencia Número de valores de entrada Valores de entrada

25 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 25 l Algunas veces llamadas pruebas de caja blanca o de caja transparente l Se definen a partir del conocimiento que se tiene de la estructura interna del sistema l El objetivo es que se ejecuten todas las instrucciones del programa Pruebas estructurales

26 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 26 Prueba de Caja Blanca Datos de prueba Salidas de prueba Código del componente Deriva en Pruebas

27 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 27 Ejemplo:

28 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 28 Prueba de trayectorias (ruteo) l El objetivo de las pruebas de trayectoria es asegurarse que las diferentes instrucciones se ejecutan correctamente l El punto de partida es un flujo gráfico del programa que muestre los nodos representativos de las decisiones que va tomando el programa. Los arcos representan el flujo de control l Las instrucciones con condiciones se escriben junto a los nodos en el gráfico

29 Diagrama de flujo para una rutina de búsqueda binaria

30 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 30 l 1, 2, 3, 8, 9 l 1, 2, 3, 4, 6, 7, 2 l 1, 2, 3, 4, 5, 7, 2 l 1, 2, 3, 4, 6, 7, 2, 8, 9 l Los casos de prueba deberían asegurarse que se ejecutan todas las trayectorias l Un analizador dinámico podría utilizarse para saber las trayectorias efectivamente ejecutadas Las trayectorias independientes (sin vuelta atrás) son:

31 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 31 Pruebas de integración l Una vez que se han probado los componentes individuales del programa, deben integrarse para formar un sistema parcial o completo. l Este proceso de integración comprende la construcción del sistema y probar el sistema resultante con respecto a los problemas que surjan de las interacciones de los componentes. l Estas pruebas se desarrollan a partir de la especificación del sistema.

32 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 32 Pruebas de integración l La principal dificultad es detectar el origen del problema cuando la prueba ha entregado una salida anómala. l ¿ Dónde está el error ? ¿ El el subprograma A ? ¿ En el B ? ¿ En ambos ?¿ En el traspaso de parámetros ? l Si no existe un diseño claro es muy difícil encontrarlo. Además los programadores se echan la culpa entre sí.

33 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 33 Pruebas de integración: Integración incremental l No se arma el sistema completo sino parte por parte, las que se van probando. l Al ser un sistema más simple, es más fácil de encontrar el origen de los errores. l En el ejemplo las pruebas T1, T2 y T3 se aplican al sistema compuesto por los módulos A y B. Si hay errores, se corrigen. l Se integra el módulo C y se repite T1, T2 y T3.

34 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 34 Pruebas de integración: Integración incremental

35 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 35 Pruebas de integración: Pruebas ascendentes y descendentes. l Pruebas descendentes Empiezan con el sistema de alto nivel y se va llegando a los niveles inferiores (más detalle) l Pruebas ascendentes Integran componentes individuales en niveles hasta que es completado el sistema l En la práctica se suele combinar ambos tipos de prueba

36 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 36 Top-down testing

37 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 37 Bottom-up testing

38 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 38 l Se realizan cuando se han integrado todos los componentes del sistema l Cada módulo o subsistema tiene una interfaz definida que es llamada por otros componentes del programa l El objetivo es detectar los errores producidos al integrar estas interfaces Pruebas de interfaces entre componentes

39 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 39 Pruebas de interfaces entre componentes

40 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 40 l Las flechas en los límites de los cuadros significan que los casos de prueba no se aplican a los componentes individuales sino al subsistema creado mediante la integración de estos componentes. l Esta forma es muy importante en el desarrollo OO cuando se reutilizan objetos y clases Pruebas de interfaces entre componentes

41 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 41 Tipos de interfaces l Interfaces de parámetros Datos pasados de un procedimiento a otro l Interfaces de memoria compartida Bloques de memoria que son compartidos entre componentes l Interfaces de procedimientos Los subsistemas encapsulan un conjunto de procedimientos que son llamados por otros subsistemas l Interfaces de paso de mensajes Los subsistemas solicitan servicios a otros subsistemas

42 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 42 Pruebas de stress (presión) l Sistemas bien diseñados y construidos fallan en situaciones límite (muchos usuarios, muchos datos en las tablas, etc.). l Estas fallas suelen ser catastróficas porque ocurren cuando hay mucho usuarios y procesos ejecutándose l El objetivo de estas pruebas es determinar hasta que límite el sistema puede funcionar sin colapsar

43 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 43

44 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 44 Bancos de pruebas l Son herramientas desarrolladas especialmente para hacer pruebas l Muchos bancos de prueba están abiertos para configurarlos debido a que normalmente hay que configurarlos a situaciones específicas l A veces existen dificultades para integrarlas debido a que el sistema a probar no está bien diseñado para interactuar con estas herramientas

45 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 45 Bancos de prueba

46 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 46 l Linux.com ha publicado una interesante nota acerca de catorce útiles consejos que harán la vida más fácil a quienes desean probar programas y aplicaciones libres. Lee a continuación para conocer los detalles. l Utiliza la más reciente versión del equipamiento lógico que estás probando. l Verifica si hay actualizaciones antes de reportar un error. l Incluye suficiente información en tu reporte de modo que el problema pueda ser reproducido con facilidad. l Evita disculparte por tu idioma. l Utiliza los sistemas de reporte de errores si están disponibles (Bugzilla). l Si es posible, escribe pruebas automatizadas. l Si es posible, utiliza el código que estás probando bajo condiciones de vida real. l Utiliza las herramientas de reporte de fallas (ejemplo: Bugbuddy). l Conviene familiarizarse con las herramientas que serán utilizadas para compilar, ligar y probar el código. l si es posible, es conveniente mantener un entorno separado para pruebas. l Conserva revisiones anteriores del código para rastrear los errores cuando aparezcan. l Describe tan completo como sea posible las condiciones que llevan a la falla. l Tus impresiones como usuario novicio son críticas, reporta todo lo que veas. l Se paciente con los desarrolladores. l Fuente: Linux.com.Linux.com

47 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 47 Temas clave l Es más importante probar las partes del sistema que se utilizan más frecuentemente que las partes que raramente se utilizan. l Las particiones de equivalencia son una forma de generar casos de prueba. Dependen de encontrar particiones en los conjuntos de datos de entrada y salida y ejecutar el programa con valores de estas particiones. A menudo el valor más útil es uno límite.

48 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 48 Temas clave l Las pruebas estructurales analizan un programa para determinar las trayectorias y utilizan este análisis para escoger los datos de prueba que sean más útiles. l Las pruebas de caja negra están basadas en la especificación del sistema (lo que debería hacer) l La finalidad de los datos de prueba es encontrar errores de funcionamiento.


Descargar ppt "©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20Slide 1 Pruebas del Software l Dinámica: l En cada uno de los objetos que se te presentan,"

Presentaciones similares


Anuncios Google