La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Pruebas de Código.

Presentaciones similares


Presentación del tema: "Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Pruebas de Código."— Transcripción de la presentación:

1 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Pruebas de Código

2 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Para el código dado del problema del triángulo, verifique si el programa hace lo correcto. Utilice cualquier técnica que Ud. conozca y considere útil. Ejercicio Verificación de Código

3 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Comparar el código con las especificaciones del diseño interno. Examinar el código contra un checklist específico para el lenguaje. Utilizar herramientas de análisis estático para checar el cumplimiento con los requerimientos de contenido y sintáctico. Actividades de la Verificación de Código

4 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Verificar la correspondencia de términos en el código con el diccionario de datos y la especificación de diseño interna. Buscar por nuevas condiciones límite, posibles cuellos de botella para el rendimientos, y otras consideraciones internas que puedan formar la base para pruebas de validación adicional. Actividades de la Verificación de Código

5 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Checklist para Verificación de Código Errores en la referencia de datos –¿Se hace referencia a una variable no asignada o no inicializada? Errores en la declaración de datos –¿Hay variables con nombres similares? –¿Hay variables con nombres no significativos? Errores de cómputo –¿Es la variable a donde se asigna una expresión, de menor capacidad que la expresión asignada?

6 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Errores en la comparación –¿Son manejadas adecuadamente las reglas de conversión entre datos o variables de tipo inconsistente? Errores en el Flujo de Datos –¿Existe la posibilidad de salir de un ciclo anticipadamente? Checklist para Verificación de Código

7 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Errores en la Interfaz –Si un módulo tienen múltiples puntos de entrada: ¿existe un parámetro que no sea referenciado en el punto de entrada actual? Errores de Entrada/Salida –¿Hay errores gramaticales u ortográficos en el texto de salida del programa? Errores de Portabilidad –¿Cómo están organizados o empaquetados los datos? Checklist para Verificación de Código

8 Validación del Software Introducción Métodos de Caja Negra Métodos de Caja Blanca Actividades de Validación Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández

9 Introducción a la Validación del Software Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández

10 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández (1) Testing se utiliza para mostrar la presencia de errores, pero nunca su ausencia. (2) Uno de los problemas más dificiles de testing es saber cuándo parar. (3) Evite casos de pruebas no planeados, no reutilizables y que se pueden arrojar a la basura, a menos que se esté probando un prototipo que después se va a arrojar a la basura. Axiomas de las Pruebas de Validación

11 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Axiomas de las Pruebas de Validación (4) Una parte necesaria de los casos de prueba es la definición del resultado o salida esperada. Siempre compare cuidadosamente el resultado actual con el esperado para todos los casos de prueba.

12 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández (5) Los casos de prueba deben ser escritos para condiciones de entrada inválidos e inesperados, al igual que para condiciones válidas y esperadas. Inválido se define como una condición que está fuera del conjunto de condiciones válidas, y deberá ser diagnosticado como tal por el programa. Axiomas de las Pruebas de Validación

13 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández (6) Los casos de prueba deben ser escritos para generar condiciones de salida esperadas. Los testers con menos experiencia tienden a pensar desde la perspectiva de las entradas. Los testers con más experiencia determinan las entradas requeridas para generar un conjunto prediseñado de salidas. Asegúrese de incluir la salida Inválida en ese conjunto. Axiomas de las Pruebas de Validación

14 Derechos Reservados, 1999 Juan Antonio Vega Fernández Axiomas de las Pruebas de Validación (7) Con la excepción de las pruebas unitarias y de integración, un programa no deberá ser probado por la persona u organización que lo desarrolló. (8) El número de errores no descubiertos es directamente proporcional al número de errores descubiertos.

15 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández ¿Cómo medimos que tan bien probado fue un producto? ¿En que grado nuestros casos de prueba cubren al producto? ¿Cómo medimos que tan buen trabajo estamos haciendo como testers? Cobertura de Pruebas

16 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Cobertura de Pruebas Un caso de pruebas... –Cubre cierta parte de los requerimientos –Cubre cierta parte de la funcionalidad (Diseño Funcional) –Cubre cierta parte de la lógica interna del programa Lo que se debe hacer es generar suficientes casos de prueba para cubrir todos los puntos de cada nivel.

17 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Caja Negra –Se realizan a partir de las especificaciones del diseño funcional sin importar la estructura interna del programa. –En la práctica es importante probar, o al menos hacer los planes de prueba, de los requerimientos y el diseño funcional sin tener mucho conocimiento del código. –El conocer el código contamina la manera como se ven los requerimientos. Estrategias de Pruebas

18 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Caja Blanca –Se realizan a partir de las especificaciones del diseño interno y del código. –Estas pruebas no detectan funciones faltantes u omisiones. –Son necesarias para probar rutas lógicas que no son discernibles en la funcionalidad externa (ejem. una función matemática que tiene dos algoritmos diferentes dependiendo de los datos). Estrategias de Pruebas

19 Diplomado en Calidad en el Software La fuente de las Pruebas ¿De dónde sacamos los casos de prueba que validan al código? –Documento de los requerimientos –Documento del diseño funcional –Documento del diseño interno Derechos Reservados, 1999 Juan Antonio Vega Fernández

20 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Pruebas basadas en requerimientos –Estrategia de Caja Negra Pruebas funcionales –Estrategia de Caja Negra Pruebas internas –Estrategia de Caja Blanca Estrategias de Validación

21 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Definición de Resultados –Si el resultado esperado no está especificado, es muy fácil interpretar el resultado obtendio como el correcto –El ojo ve lo que quiere ver. (Myers, 1979). Repetición –Si un error no se puede repetir, no es error. –Es muy difícil en un ambiente de multiprocesamiento (o multi-hilos) asíncrono. Requerimientos de las Pruebas de Validación

22 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Definiciones de la IEEE/ANSI Una prueba –(i) Una actividad en la cual el sistema o componente es ejecutado bajo condiciones específicas, los resultados son observados o grabados, y se hace una evaluación de algunos aspectos del sistema o componente. –(ii) Un conjunto de uno o más casos de pruebas.

23 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Un caso de prueba –(i) Un conjunto de entradas de prueba, condiciones de ejecución, y resultados esperados desarrollados para un objetivo particular. –(ii) La entidad más pequeña que siempre es ejecutada como una unidad, de principio a fin. Definiciones de la IEEE/ANSI

24 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Un procedimiento de prueba –(i) Las instrucciones detalladas para la implantación, ejecución y evaluación de los resultados para un caso de pruebas dado. –(ii) Un caso de pruebas puede ser usado en uno o más procedimientos de prueba. Definiciones de la IEEE/ANSI

25 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Métodos de Validación Métodos de Caja Negra –Partición de Equivalencias –Análisis de valores límite –Adivinar errores –Grafos causa efecto –Pruebas de sintáxis –Pruebas de Transición de estados –Matriz de Grafos Métodos de Caja Blanca –Cobertura de sentencias –Cobertura de decisiones –Cobertura de condiciones –Cobertura de rutas

26 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Partición de Equivalencia

27 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Es un proceso sistemático que identifica un conjunto de clases interesantes de condiciones de entrada a ser probados. Cada clase es representativa o cubre un conjunto grande de otras pruebas. Si se aplica partición, el producto se comportará de la misma manera para todos los miembros de las clases. El objetivo es minimizar el número de casos de prueba requeridos para cubrir las condiciones de entrada. Partición de Equivalencias

28 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández (1) Identificar las Clases de Equivalencia (CE) (2) Identificar los Casos de Prueba Pasos para la Partición de Pruebas

29 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Para cada entrada externa: –(1) Si la entrada especifica un rango de valores válidos, define una CE válida (dentro del rango) y dos CE inválidas (una fuera de cada límite del rango). –Ejemplo: Si la entrada requiere un mes en el rango de 1-12, define un mes válido, uno 12. Identificación de Clases de Equivalencia

30 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Identificación de Clases de Equivalencia (2) Si la entrada especifica un número (N) de valores válidos, define una CE válida y dos CE inválidas, una N. –Ejemplo: En el programa del triángulo, define un caso con tres valores (1, 3, 3), otro con dos o menos valores (1, 3) y otro con cuatro o más valores (1, 2, 3, 4).

31 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández (3) Si la entrada especifica un conjunto de valores válidos, define una CE válida (dentro del conjunto) y otra CE inválidas (fuera del conjunto). –Ejemplo: Si un programa requiere un nombre del conjunto [HUGO, PACO, LUIS], selecciona un nombre válido [HUGO], y otro inválido [PANCHO]. Identificación de Clases de Equivalencia

32 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández (4) Si hay razones para creer que el programa trata cada valor de entrada diferente, entonces hay que definir una CE válida para cada entrada válida. –Ejemplo: Si un programa que recibe un número trata a los pares de una forma y a los impares de otra. Hay que definir un número válido par y otro válido impar. Identificación de Clases de Equivalencia

33 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández (5) Si la entrada especifica una situación obligatoria, define una CE válida y otra inválida. –Ejemplo: Si el primer caracter de una entrada tiene que ser cualquier letra del alfabeto, define una entrada con un primer caracter que sea letra del alfabeto (H567634) y otra entrada con un primer caracter numérico ( ). Identificación de Clases de Equivalencia

34 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández (6) Si hay alguna razón para creer que los elementos en una CE no son tratados de manera idéntica, subdivide la CE en clases más pequeñas. –Ejemplo: Para el programa de los números pares e impares, una CE son los pares y otra CE son los impares. Identificación de Clases de Equivalencia

35 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández (1) Asignar un número único a cada CE (2) Hasta que todas las CE válidas hayan sido cubiertas por casos de prueba: –Escribe un nuevo caso de prueba cubriendo tantas CE no cubiertas como sea posible. Identificación de los Casos de Prueba

36 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández (3) Hasta que todas las CE inválidas hayan sido cubiertas por casos de prueba: –Escribe un nuevo caso de prueba que cubra una y solo una CE no cubierta. (4) Si se prueban múltiples CE inválidas en el mismo caso de prueba, algunas de estas pruebas nunca van a ser ejecutadas porque la primera prueba puede enmascarar otras pruebas o terminar la ejecución del caso de prueba. Identificación de los Casos de Prueba

37 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Análisis de Valores Límite

38 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Es una variante y refinamiento de la partición de equivalencia con dos diferencias principales: –(1) En lugar de seleccionar cualquier elemento en una clase de equivalencia como representativo, los elementos son seleccionados de manera que cada orilla de la CE sea probada. –(2) En vez de concentrarse exclusivamente en condiciones de entrada, se exploran las condiciones de salida definiendo las CE de salida. Análisis de Valores Límite

39 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Si una entrada especifica un rango de valores válidos, escribe casos de prueba para los límites del rango y para las condiciones justo fuera de los límites. –Ejemplo: Si el programa requiere una entrada que sea un número real en el rango de 0.0 a 90.0, escribe casos de prueba para 0.0, 90.0, , y Guía para el Análisis de Valores Límite

40 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Si para una entrada se especifica un número de valores válidos, escribe casos de prueba para los número límite de entradas y para las condiciones justo fuera de los límites. –Ejemplo: Si el programa requiere de dos a cinco datos de entradas, escribir casos de prueba para 2, 5, 1, y 6 datos de entrada. Usar estos dos lineamientos para cada condición de salida. Guía para el Análisis de Valores Límite

41 Realice la Partición de Equivalencia y el Análisis de Valores Límite para el Diseño Funcional siguiente. Trabaje en equipos pequeños de 2 ó 3 personas. Utilice el formato incluído para la Partición de Equivalencias. Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Ejercicio

42 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Es un enfoque práctico basado en la intuición y experiencia del tester para identificar pruebas que se considere probables que muestren errores. Las historias de defectos pueden ser útiles; hay una alta probabilidad de que los errores que han aparecido en el pasado, puedan volver a aparecer. –listas o strings vacíos o nulos –cero ocurrencias o instancias –números negativos Adivinar Errores

43 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Es un enfoque sistemático para explorar combinanciones de condiciones de entrada. Es un método rigoroso para transformar una especificación en lenguaje natural a una especificación en lenguaje formal. Es muy útil en la verificación del diseño funcional pero es muy difícil y consume mucho tiempo al implementarlo. Es una propuesta práctica cuando hay una herramienta que convierte el grafo en una tabla de decisiones. Grafos Causa-Efecto

44 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Se aplica a programas que tienen un lenguaje que define los datos o acciones, por ejemplo el lenguaje de la línea de comandos de un sistema operativo. Pruebas de Sintaxis

45 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Identificar el lenguaje Definir la sintaxis formalmente Prueba los casos válidos siguiendo un grafo de definición. Prueba nivel por nivel haciendo un error a la vez. Prueba casos inválidos. Automatiza la creación y ejecución de las pruebas. Pasos para prueba de sintaxis

46 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Es un método analítico que utiliza máquinas de estado finito para diseñar pruebas que tienen funciones de control similares pero diferentes. También se utiliza principalmente para la verificación funcional. Pruebas de Transición de Estados

47 Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Es una representación más simple de un grafo para organizar datos. Cada fila representa un nodo del grafo. Cada columna representa un nodo del grafo. M(i,j) define la relación entre el nodo i y el nodo j. Generalmente es una matriz dispersa. Matriz de Grafos


Descargar ppt "Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Pruebas de Código."

Presentaciones similares


Anuncios Google