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

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are

Derechos Reservados, 1999

Juan Antonio Vega FernándezJuan Antonio Vega Fernández

Pruebas de CódigoPruebas de Código

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• 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.

EjercicioEjercicioVerificación de CódigoVerificación de Código

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• 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 laActividades de laVerificación de CódigoVerificación de Código

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• 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 laActividades de laVerificación de CódigoVerificación de Código

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



Checklist para Checklist para Verificación de CódigoVerificació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?

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• 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?


Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• 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?


Validación del SoftwareValidación del Software Introducción Métodos de Caja Negra Métodos de Caja Blanca Actividades de Validación

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



Introducción a la Introducción a la Validación del SoftwareValidación del Software

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• (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 Axiomas de las Pruebas de ValidaciónPruebas de Validación

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are




• (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.

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• (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.


Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• (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.





• (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.

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• ¿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 PruebasCobertura de Pruebas

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



Cobertura de PruebasCobertura 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.

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• 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 PruebasEstrategias de Pruebas

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• 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 PruebasEstrategias de Pruebas

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are

La fuente de las PruebasLa 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



Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• Pruebas basadas en requerimientos– Estrategia de Caja Negra

• Pruebas funcionales– Estrategia de Caja Negra

• Pruebas internas– Estrategia de Caja Blanca

Estrategias de ValidaciónEstrategias de Validación

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• 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 Requerimientos de las Pruebas de ValidaciónPruebas de Validación

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



Definiciones de la IEEE/ANSIDefiniciones 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.

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• 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.


Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• 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.


Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



Métodos de ValidaciónMé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

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



Partición de EquivalenciaPartición de Equivalencia

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• 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 EquivalenciasPartición de Equivalencias

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• (1) Identificar las Clases de Equivalencia (CE)

• (2) Identificar los Casos de Prueba

Pasos para la Pasos para la Partición de PruebasPartición de Pruebas

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• 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 <1, y otro >12.

Identificación de Identificación de Clases de EquivalenciaClases de Equivalencia

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are




• (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 y otra >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).

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• (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].


Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• (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.


Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• (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 (1234567).


Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• (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.


Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• (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 Identificación de los Casos de Pruebade los Casos de Prueba

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• (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 Identificación de los Casos de Pruebade los Casos de Prueba

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



Análisis de Valores LímiteAnálisis de Valores Límite

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• 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ímiteAnálisis de Valores Límite

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• 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, -0.0001, y 90.0001.

Guía para el Guía para el Análisis de Valores LímiteAnálisis de Valores Límite

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• 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 Guía para el Análisis de Valores LímiteAnálisis de Valores Límite

• 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.

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



EjercicioEjercicio

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• 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 ErroresAdivinar Errores

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• 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-EfectoGrafos Causa-Efecto

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• 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 SintaxisPruebas de Sintaxis

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• 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 sintaxisPasos para prueba de sintaxis

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• 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 Pruebas de Transición de EstadosTransición de Estados

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• 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 GrafosMatriz de Grafos

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

Documents

Transcript of Diplomado en Calidad en el Software Derechos Reservados, 1999 Juan Antonio Vega Fernández Pruebas...