Temario III Testing in the Large

Transcripción

1 Temario III Testing in the Large 1ra Parte Verificación y Validación de Software UNS 1 Contenidos Testing de Integración Testing de Sistema Testing de Regresión Verificación y Validación de Software UNS 2

2 Testing In the Large Lectura Ghezzi, C., et.al. Fundamentals of Software Engineering. Prentice Hall, [Cap. 6] White Lee, General Overview of Software Testing. Artículos Scuola estiva Software Testing Metodi e Tecniche, Italia, Visaggio Giuseppe, System and Acceptance Testing. Artículos Scuola estiva Software Testing Metodi e Tecniche, Italia, Verificación y Validación de Software UNS 3 Testing de Integración (1) Se enfoca en verificar que la interacción entre unidades y sus interfaces que se suponen correctas (ya testeadas), es correcta Los casos de test son específicamente seleccionados para testear las interfaces en lugar de la funcionalidad de las unidades. Cerca del 40 % de los errores se relacionan a problemas de interfaces e integración. Descubrirlos temprano reduce costos de corrección. Los desarrolladores son mejores para hacer este test. Conocen muy bien las interfaces. Un tester de funcionalidad está muy motivado para eliminar sistemáticamente los errores de interfaces. Verificación y Validación de Software UNS 4

3 Testing de Integración (2) Estrategias de Integración Test Big-Bang: Cada unidad es testeada por separado, y luego simplemente se las integra a todas a la vez y se testea el todo. Puede ser muy efectivo para ahorrar tiempo en el proceso de Testing de Integración. Sin embargo, si los casos de test y sus resultados no están bien registrados, el proceso completo será muy complicado perjudicando el objetivo del Testing de Integración. Verificación y Validación de Software UNS 5 Testing de Integración (2) Estrategias de Integración Test incremental: Testing Bottom-up: las unidades se mezclan y testean de abajo hacia arriba en el grafo de llamadas. Primero las unidades terminales aisladas. Se usan unidades driver para llamar a las unidades de nivel inferior. Luego se reemplazan los drivers por unidades del siguiente nivel, y se prosigue igual. Testing Top-down: comienza desde el tope y utiliza unidades stub para simular a las que éste llamaría. Luego se reemplazan los stubs por las unidades reales y se continua de la misma forma hacia las unidades terminales. Verificación y Validación de Software UNS 6

4 Testing de Integración (3) Integración Bottom Up vs. Integración Top Down Verificación y Validación de Software UNS 7 Testing de Integración (4) Integración Bottom-Up 1ra Fase: se definen drivers para módulos atómicos Test de Unidad de E, F, G y D Verificación y Validación de Software UNS 8

5 Testing de Integración (5) Integración Bottom-Up 2da Fase 3ra Fase Test de Unidad de E Test de Integración de B con E Verificación y Validación de Software UNS 9 Testing de Integración (6) Integración Top Down 1ra Fase 2da Fase Test de Unidad de A Test de Unidad de B Test de Integración de A con B Verificación y Validación de Software UNS 10

6 Testing de Integración (7) Top Down: Permite tener una visión preliminar del sistema (similar a prototipo evolutivo) Seguimiento más fácil Más Aceptación Bottom Up: Módulos críticos en el nivel inferior Planeamiento de la programación Variaciones en Enfoques Top Down/Bottom Up Diseñar, Codificar y Verificar un nivel por vez Enfoque Zig Zag. Finalizar el Diseño antes de codificar Enfoques Mixtos Verificación y Validación de Software UNS 11 Testing de Integración (8) Errores a ser detectados: De Interpretación: el comportamiento esperado por el usuario de un módulo no coincide con su funcionalidad (a) Función errónea: la funcionalidad suministrada por el módulo B (llamado) no es la requerida por la especificación de A (b) Función extra: algunas funciones de B no son requeridas por A (c) Función perdida: existen algunos parámetros de Ahacia B que están fuera del dominio de B Verificación y Validación de Software UNS 12

7 Testing de Integración (9) Llamada Errónea: la instrucción call se coloca en un lugar equivocado en el módulo llamador. Tiene tres posibles faults: (a) Instrucción de llamada extra: la instrucción está en un camino equivocado (b) Ubicación equivocada: la instrucción está en el lugar equivocado del camino correcto (c) Instrucción perdida: falta la instrucción Error de Interfaz: la interfaz estándar tiene errores Ej., parámetros en orden incorrecto, errores en tipos, etc. Verificación y Validación de Software UNS 13 Testing de Integración (10) Puntos clave para la Integración: Conectar de a poco las partes más complejas, para identificar más fácil las causas de errores Minimizar la necesidad de programas auxiliares (drivers/stubs), para ahorrar esfuerzo de programación Puntos clave para Testing de Integración Aplicar el criterio de Condiciones Límite Probar todos los parámetros de punteros con nulos Diseñar tests que hagan fallar al componente En el caso de memoria compartida, cambiar la secuencia de acceso a los datos Usar testing de estrés en interfaces de mensajes En interfaces de mensajes, cambiar el orden Verificación y Validación de Software UNS 14

8 Testing de Sistema (1) Su objetivo es chequear que la colección de elementos constituyentes como un todo, se comporte apropiadamente (asumiendo que sus componentes ya lo hacen individualmente). Implica realizar varios tipos de tests: Funcionalidades Performance Seguridad Stress Robustez Configuración Confiabilidad Verificación y Validación de Software UNS 15 Testing de Sistema (2) Funcionalidades: Se verifica que cada una de las funciones especificadas en el documento de Requerimientos estén cubiertas y ejecuten correctamente. Performance: test de cualidades que no pueden definirse a nivel de módulo, sino que dependenden del sistema global Puede medirse en términos de tiempo de respuesta o utilización y probarlo bajo diferentes combinaciones Rendimiento del peor caso Rendimiento Promedio Verificación y Validación de Software UNS 16

9 Testing de Sistema (3) Seguridad: se aplican tests ordinarios para confirmar que la seguridad del sistema no está comprometida. Configuración: Probar bajo diferentes combinaciones de hardware y software. Conexiones físicas con las que interactúa el sistema, pueden ser reemplazadas por diferentes razones. Ejemplos: SO Placas de video Sistemas administradores de ventanas Sistemas gestores de BD, o versiones de la misma BD Verificación y Validación de Software UNS 17 Testing de Sistema (4) Robustez: testear el sistema bajo condiciones inesperadas (comandos erróneos, fallas de energía). Stress: Situaciones de recursos saturados. Intenta romper el sistema. Condiciones limites, distorsión del orden de procesamiento, aumenta las acciones simultaneas, etc. Testing de carga (sistemas de transacciones): simular el efecto de muchos usuarios utilizando el sistema en forma concurrente Testing de volúmen (sistemas batch): Simular la entrada de grandes volumenes de datos Verificación y Validación de Software UNS 18

10 Testing de Sistema (5) Confiabilidad: Medición de la probabilidad de ocurrencias de fallas. Relacionado a Tolerancia a Fallas Permite medir Disponibilidad AF(t) : promedio de la cantidad total de fallas FI(t) : cantidad de fallas por unidad de tiempo MTTF : tiempo medio entre fallas (sistema disponible) Verificación y Validación de Software UNS 19 Testing de Sistema (6) Usabilidad: El sistema se escribe e implementa para ser usado. La USABILIDAD se define en cómo de apropiado, funcional y efectiva es la interacción con el usuario Problemas: Cada usuario es diferente y posee sus propias necesidades. Verificación y Validación de Software UNS 20

11 Testing de Sistema (7) Usabilidad: Debemos hacer un sistema para cada usuario? Rechazo a un sistema por estar acostumbrado a otro tipo de sistema o interface (ej. DTI) Los requerimientos de usabilidad son generalmente pobres y difíciles de describir lo que lleva a un testeo también pobre. En general no se puede realizar este test hasta muy tarde en el ciclo de vida del software (en la ejecución del testing de aceptación) En esta etapa un error o cambio puede ser muy caro Verificación y Validación de Software UNS 21 Testing de Sistema (8) Usabilidad: Testeo la Interface de Usuario (UI) Todo sistema posee una UI Las interfaces han cambiado mucho en el trascurso de los últimos años Ahora poseemos interfaces de usuario (GUI) sofisticadas Llegaremos a hablarle a nuestro sistema? Es lo que quieren los usuarios? Verificación y Validación de Software UNS 22

12 Testing de Sistema (9) Usabilidad: Verificación y Validación de Software UNS 23 Testing de Aceptación (1) Implica Validación del Sistema. Realizado por el usuario final o cliente para verificar conformidad con el producto desarrollado. Esta basado en los requerimientos del usuario Esta dirigido a demostrar que el sistema cumple con los requerimientos solicitados Verificación y Validación de Software UNS 24

13 Testing de Aceptación (2) Verificación y Validación de Software UNS 25 Testing de Aceptación (3) El sistema no posee toda la funcionalidad Posee funciones centrales y está capacitado para recibir entradas y generar las salidas No está pensado para que esté en funcionamiento Se realiza con algunos representantes del cliente Se realiza en el entorno de la empresa que desarrolla el software También lo realizan los desarrolladores Verificación y Validación de Software UNS 26

14 Testing de Aceptación (4) Se realiza directamente por los usuarios finales en su entorno El proceso de entregar una versión beta a los usuarios se llama beta release Al sistema en esta etapa se lo denomina como prototipo, acceso temprano, preview, etc. Verificación y Validación de Software UNS 27 Testing de Aceptación (5) Es una versión del software con potencial para ser un producto final Esta listo para salir, a no ser que se encuentren fallas fatales El producto debería poseer toda su funcionalidad Verificación y Validación de Software UNS 28

15 Testing de Aceptación (6) Es el sistema en su producción final Casi idéntico a la versión anterior, pero las fallas (bugs) de último minuto fueron resueltas Se considera estable y relativamente libre de errores Posee la calidad suficiente para su amplia distribución y uso por usuarios finales Verificación y Validación de Software UNS 29 Testing de Aceptación (7) Beta Testers: Compañías los contratan para testear sus productos en casa (free lance). Deben reproducir el entorno de los usuarios. Trabajan sobre un producto por horas, repitiendo las mismas acciones para intentar encontrar las fallas. Beta Testers GNU: para software libre, que donan su tiempo. Free Beta Trials: oportunidad de probar nuevos productos antes de llegar al mercado. Testing gratuito y posicionamiento temprano en el mercado. Verificación y Validación de Software UNS 30

16 Testing de Regresión (1) Se define como la repetición selectiva de un conjunto de test o TS (test suite) previamente ejercitado sobre un sistema o unidad, para comprobar que las modificaciones no hayan causado efectos laterales [SWEBOK04] Se realiza para ver si un sistema modificado funciona al menos tan mal como antes de la modificación Se deben volver a ejecutar, en lo posible, todos los test ya hechos, cada vez que se modifican los requerimientos, test, plataformas, etc. Se intenta establecer una base mínima de corrección y para evitar que el proceso se descontrole. Verificación y Validación de Software UNS 31 Testing de Regresión (2) Regresión Progresiva: Surge cuando la especificación es modificada Si surgen nuevas mejoras o nuevos requerimientos de datos la especificación debe modificarse Nuevos módulos van a ser agregados al sistema Se debe testear la especificación modificada contra el programa modificado Verificación y Validación de Software UNS 32

17 Testing de Regresión (3) Regresión Correctiva: No cambia la especificación Sólo cambian algunas instrucciones y posiblemente algunas decisiones de diseño Muchos casos de test en el plan de testeo anterior van a seguir siendo válidos Pero otros no seguirán siendo válidos Verificación y Validación de Software UNS 33 Testing de Regresión (4) Casos de test reusables (R t ): Incluyen ambos tipos de casos de test (correctiva y progresiva) Testean las partes no modificadas de la especificación y su correspondiente programa no modificado No necesitan ser reejecutados ya que obtendrán los mismos resultados que antes Verificación y Validación de Software UNS 34

18 Testing de Regresión (5) Casos de test retesteables (T t ): Otra vez incluyen ambos tipos de test Deben repetirse porque el programa que es testeado cambió Aunque la especificación no lo hizo. Verificación y Validación de Software UNS 35 Testing de Regresión (6) Casos de test obsoletos (O t ): Aquellos test que deben ser descartados porque ya no siguen siendo válidos por los cambios en la especificación Aquellos test sobre los programas que ya no controlan las estructuras deseadas debido a los cambios en los mismos Verificación y Validación de Software UNS 36

19 Testing de Regresión (7) Se debe introducir un nuevo plan de test: Casos estructurales nuevos (S t ) Casos basados en la estructura que incrementen el cubrimiento estructural de un programa Casos nuevos para la especificación (N t ) Incluye solo los casos de test basados en la especificación Testean el nuevo código generado a partir de la parte modificada de una especificación Verificación y Validación de Software UNS 37