Pruebas del Software l l Dinmica En cada

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

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

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

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

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 ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 5

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

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. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 7

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

Datos de prueba y casos de prueba l l Los datos de prueba son entradas que permiten probar el sistema 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. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 9

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

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

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

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

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

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

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

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

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

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

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

Particionamiento de equivalencia l l 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. 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. Estas clases se denominan particiones de equivalencia. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 21

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

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

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

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

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

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

Prueba de trayectorias (ruteo) l l l El objetivo de las pruebas de trayectoria es asegurarse que las diferentes instrucciones se ejecutan correctamente 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 Las instrucciones condiciones se escriben junto a los nodos en el gráfico ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 28

Diagrama de flujo para una rutina de búsqueda binaria

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

Pruebas de integración l l l Una vez que se han probado los componentes individuales del programa, deben integrarse para formar un sistema parcial o completo. 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. Estas pruebas se desarrollan a partir de la especificación del sistema. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 31

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

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

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

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 ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 35

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

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

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

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

Pruebas de interfaces entre componentes l 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. Esta forma es muy importante en el desarrollo OO cuando se reutilizan objetos y clases ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 40

Tipos de interfaces l l Interfaces de parámetros • Datos pasados de un procedimiento a otro 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 ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 41

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

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

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

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

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

Temas clave l l Es más importante probar las partes del sistema que se utilizan más frecuentemente que las partes que raramente se utilizan. 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. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 47

Temas clave l l 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. Las pruebas de caja negra están basadas en la especificación del sistema (lo que debería hacer) La finalidad de los datos de prueba es encontrar errores de funcionamiento. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 48