Pruebas del Software Dinámica: En cada uno de los objetos que se te presentan, indique como lo probarían ? Sus pruebas realizadas Sus conclusiones

Para todos….

Pruebas del software 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

Fases de prueba Pruebas de integración Pruebas del componente Desarrollador de software Equipo de pruebas independiente

Pruebas del software 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.

Pruebas de defectos 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

Datos de prueba y casos de prueba 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.

El proceso de pruebas de defectos Casos de prueba Datos prueba Resultados prueba Informe prueba Comparar resul- tados con casos Diseñar casos de prueba Preparar datos de prueba Ejecutar programas

Ejemplo: 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.

Prueba de caja negra 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

Prueba de caja negra Entradas que causan salidas anormales Salidas que revelan la presencia de defectos

Ejemplo:

Particionamiento de equivalencia 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.

Particiones de equivalencia

Particiones de equivalencia 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

Particiones de equivalencia Número de valores de entrada Valores de entrada

Pruebas estructurales 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

Prueba de Caja Blanca Datos de prueba Código del componente Pruebas Deriva en Código del componente Salidas de prueba

Ejemplo:

Prueba de trayectorias (ruteo) 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 con condiciones se escriben junto a los nodos en el gráfico

Diagrama de flujo para una rutina de búsqueda binaria

Las trayectorias independientes (sin vuelta atrás) son: 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

Pruebas de integración 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.

Pruebas de integración 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í.

Pruebas de integración: Integración incremental 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 T1, T2 y T3 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 T1, T2 y T3.

Pruebas de integración: Integración incremental

Pruebas de integración: Pruebas ascendentes y descendentes. Pruebas descendentes Empiezan con el sistema de alto nivel y se va llegando a los niveles inferiores (más detalle) Pruebas ascendentes Integran componentes individuales en niveles hasta que es completado el sistema En la práctica se suele combinar ambos tipos de prueba

Top-down testing

Bottom-up testing

Pruebas de interfaces entre componentes 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

Pruebas de interfaces entre componentes

Pruebas de interfaces entre componentes 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

Tipos de interfaces Interfaces de parámetros Datos pasados de un procedimiento a otro Interfaces de memoria compartida Bloques de memoria que son compartidos entre componentes Interfaces de procedimientos Los subsistemas encapsulan un conjunto de procedimientos que son llamados por otros subsistemas Interfaces de paso de mensajes Los subsistemas solicitan servicios a otros subsistemas

Pruebas de stress (presión) 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

Bancos de pruebas 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

Bancos de prueba

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.

Temas clave 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.

Temas clave 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.