plan de estudios istqb: nivel fundamentosdinamizaconsulting.com/istqb/t5-tecnicas del diseno de...

Plan de estudios ISTQB: Nivel Fundamentos

Temario

1. INTRODUCCIÓN

2. FUNDAMENTOS DE PRUEBAS

3. PRUEBAS A TRAVÉS DEL CICLO DE VIDA DEL SOFTWARE

4. TÉCNICAS ESTÁTICAS

5. TÉCNICAS DE DISEÑO DE PRUEBAS

6. GESTIÓN DE PRUEBAS

7. HERRAMIENTAS DE PRUEBAS

Temario

5. TÉCNICAS DE DISEÑO DE PRUEBAS

5.1 Diseño de Casos de Prueba

5.2 Categorías de las Técnicas de Diseño de Pruebas

5.3 Técnicas de Caja Negra (“Black Box”)

5.4 Técnicas de Caja Blanca (“White Box”)

5.5 Técnicas Basadas en la Experiencia

5.6 Selección de las Técnicas de Pruebas

TÉCNICAS DE DISEÑO DE PRUEBAS


Proceso de desarrollo de pruebas:

Establecer grado de formalidad

Análisis de pruebas

Documentación

Objetivos de las pruebas

Trazabilidad:

Especificaciones

Impacto

Cobertura



Proceso de desarrollo de pruebas (II):

Especificaciones de casos de prueba en base a:

Entradas

Precondiciones

Salidas (esperadas)

Condiciones o entorno de pruebas



Proceso de desarrollo de pruebas (III):

Norma IEEE STD 829:

Revisada en 2008

Especificaciones de diseño de pruebas

Especificaciones de casos de prueba



Norma IEEE STD 829-2008:

El propósito de esta norma es:

Establecer un marco común para los procesos de pruebas, actividades y tareas en apoyo de todo el software procesos del ciclo de vida, incluyendo la adquisición, suministro, desarrollo, operación y mantenimiento procesos.

Definir las tareas de prueba, las necesidades requeridas, y salidas requeridas



Norma IEEE STD 829-2008 (II):


Identificar las tareas de prueba mínimos recomendados correspondientes a los niveles de integridad para un nivel de cuatro esquema de integridad.

Definir el uso y contenido del Maestro testplan y el plan de pruebas de nivel (por ejemplo, para componente, la integración, el sistema y prueba de aceptación)



Norma IEEE STD 829-2008 (III):


Definir el uso y contenido de la documentación relacionada con la prueba (Diseño de prueba, prueba de casos, la prueba Procedimiento, Anomalía Informe, Test Log, Nivel TestReport , Informe provisional de pruebas y prueba de Maestro Informe)



Las técnicas de prueba tienen como objetivo identificar:

Condiciones de prueba

Casos de prueba

Datos de prueba

Categorías:

Caja negra

Caja blanca



Diferenciamos tipos de técnicas de diseño en base a:

Especificaciones

Estructura

Experiencia



Técnicas basadas en la especificación:

El problema a solucionar, el software o sus componentes se especifican a partir de modelos formales o informales

Los casos de prueba pueden obtenerse sistemáticamente a partir de los modelos



Técnicas basadas en la estructura

Información sobre como debe utilizarse el software construido para obtener los casos de prueba

Puede medirse el alcance de la cobertura del software para los casos de prueba



Técnicas basadas en la experiencia

Se emplea el conocimiento y la experiencia

El conocimiento de probadores, desarrolladores y usuarios es la fuente de información utilizada

Conocimiento sobre defectos probables



PARA REPRESENTAR LOS SISTEMAS

Su funcionamiento

Las salidas o respuestas que produce

De las entradas que recibe

SE UTILIZA

DESDE EL PUNTO DE VISTA

SIN TENER EN CUENTA



Se utiliza el concepto de caja negra en doscircunstancias.

Sistema impenetrable.

Sistema complejo.



Característica de Caja Negra: La característica de Caja Negra se aplica

a cualquier sistema, programa o módulo, para dar una visión exclusivade sus entradas y salidas, sin tener en cuenta los detalles de cómo se realiza el proceso.



Las pruebas de caja negra se llevan a cabo sobrela interfaz del software; obviando el comportamiento interno y la estructura del programa.Los casos de prueba de la caja negra pretenden demostrarque: Las funciones del software son operativas La entrada se acepta de forma correcta Se produce una salida correcta La integridad de la información externa se mantiene



La prueba de la caja negra intenta encontrarerrores de las siguientes categorías: Funciones incorrectas o ausentes Errores de interfaz Errores en estructuras de datos o en bases de

datos externas Errores de rendimiento Errores de inicialización y de terminación Errores de navegabilidad



Partición de equivalencia

Análisis de valores límite

Pruebas de tabla de decisión

Pruebas de transición de estado

Pruebas de casos de uso




Los valores de entrada y/o salida se dividen en grupos

En base a datos válidos o no válidos

Aplicable a todos los niveles de pruebas




Clase de equivalencia:

Conjunto de datos de entrada que definen estados válidos y no válidos del sistema.

Clase válida: genera un valor esperado

Clase no válida: genera un valor inesperado

Se obtienen a partir de las condiciones de entrada descritas en lasespecificaciones.


5.3 Técnicas de Caja Negra (“Black Box”)Partición de equivalencia

CONDICIONES DE ENTRADA: Las condiciones de entrada vienen representadas por sentencias en la especificación.



PROCEDIMIENTO

Identificación de las clases de equivalencia

Obtención de los casos de prueba

Se parte de la premisa de que cualquier elemento de una clase dada es representativo del resto del conjunto



IDENTIFICACIÓN DE LAS CLASES DE EQUIVALENCIA

Por cada condición de entrada se identifican clases de equivalencia válidas y no válidas

Este proceso se basa en la experiencia

Sin embargo existen un conjunto de criterios que ayudan a su identificación




Identificación de las clases de equivalencia

Se identifican clases de equivalencia válidas e inválidas con la siguiente tabla:



DERIVACION DE LOS CASOS DE PRUEBA

Clases de equivalencia :

Cada caso debe contemplar el máximo número de clases de equivalencia válidas.

Generar suficientes casos para cubrir todas las clases.

Generar un caso de prueba por cada clase de equivalencia no válida que haya sido identificada




Ejemplo Caso Práctico:

Definir clases de prueba válidas e inválidas en una partición de equivalencia, para probar una aplicación bancaria en la que el operador debe proporcionar un código, un nombre y una operación.




EL MÉTODO DEL ANÁLISIS DE LOS VALORES LÍMITES (AVL)

Se basa en la evidencia experimental de que los errores suelen aparecer con mayor probabilidad en los extremos de los campos de entrada.

Un análisis de las condiciones límites de las clases de equivalencia aumenta la eficiencia de la prueba.

Condiciones límites: valores justo por encima y por debajo de los márgenes de la clase de equivalencia.




Fácil de aplicar

Alta capacidad de detección de fallos

Se considera como una extensión de la partición de equivalencia




DERIVACIÓN DE LOS CASOS DE PRUEBA

Generar tantos casos de prueba como sean necesarios para ejercitar las condiciones límites de las clases de equivalencia.

Proceso basado en la experiencia

Como en el caso anterior se pueden seguir unos criterios que faciliten su obtención




Este método se usa en caso en los que los inputs y outputs tengan unos valores limitados, por ejemplo, “está presente” o “falta” (verdadero o falso).

Al comportamiento de los objetos o los procesos, se les llama acciones y se representan en forma de tabla de la forma siguiente:




El número de reglas está vinculado al número de condiciones, por ejemplo, es igual al total de posibles combinaciones de todas las condiciones.

Por lo tanto:

Si hay 2 condiciones, habrá 4 reglas

Si hay 3 condiciones , habrá 8 reglas

Si hay 4 condiciones, habrá 16 reglas




Ejemplo:Una empresa de apoyo técnico redacta una tabla de resoluciones para diagnosticar problemas de la impresora, basada en los avisos que le han descrito por teléfono sus clientes.




Entender los objetos que se van a modelar y las relaciones que conectan a estos.

Definir una serie de pruebas que verifique que “todos los objetos tienen entre ellos la relaciones esperadas”




Ejemplo:

Probamos cada uno de los

Casos de transición




Interacciones entre usuarios y sistema

Resultado de valor para usuarios o clientes

Niveles:

Abstracto o negocio

Sistema

Consideraciones

Precondiciones y postcondiciones




Escenario principal y derivaciones

Flujos de proceso

Pruebas de aceptación

Probadores: clientes o usuarios




Ejemplo de un caso de uso:



Caso práctico: Construcción de una batería de pruebas para detectarposibles errores en la construcción de los identificadores de un hipotético lenguaje de programación. Las reglas que determinan susconstrucción sintáctica son: No debe tener mas de 15 ni menos de 5 caracteres El juego de caracteres utilizables es:–Letras (Mayúsculas y minúsculas)–Dígitos (0,9)–Guión (-) Se distinguen las mayúsculas de las minúsculas El guión no puede estar ni al principio ni al final, pero puede haber

varios consecutivos. Debe contener al menos un carácter alfabético No puede ser una de las palabras reservadas del lenguaje



CONDICIONES DE ENTRADA

DERIVACION DE LOS CASOS DE PRUEBA


Definición de valores límite



Pruebas de software que se realiza sobre las funciones internas de un módulo

Las pruebas de caja blanca se llevan a cabo en primer lugar, para luego realizar las de caja negra

Niveles de prueba:

Nivel de componente

Nivel de integración

Nivel de sistema



Criterios de cobertura

Encontrar fragmentos del programa que no son ejecutados por los casos de prueba.

Crear casos de prueba adicionales que incrementen la cobertura.

Determinar un valor cuantitativo de la cobertura (que es, de manera indirecta, una medida de la calidad del programa).

Adicionalmente, el análisis de cobertura también permite la identificación de casos de prueba redundantes, que no incrementan la cobertura.



Pruebas de sentencias

Pruebas de decisión

Otras técnicas basadas en la estructura



Pruebas de sentencias y cobertura

Cobertura de sentencia:

Comprueba el número de sentencias ejecutables que se han ejecutado

Se puede diseñar un plan de pruebas que vaya ejercitando más y más sentencias, hasta que hayamos pasado por todas, o por una inmensa mayoría.

Num sentencias ejecutadas / Num de sentencias totales



Pruebas de decisión y cobertura

Cobertura de decisión:

Comprueba el número de decisiones ejecutadas, considerando que se ha ejecutado una decisión cuando se han recorrido todas sus posible ramas (la que la hace true y la que la hace false, pero también todas las posibles ramas de un switch)



Pruebas de decisión y cobertura

Cobertura de decisión:

Número toral de resultados de decisión cubiertos por los casos de prueba entre el número total de posibles resultados de decisión en el código objeto de prueba




Cobertura de condiciones: Comprueba el número de condiciones ejecutadas, entendiendo que se ha ejecutado una condición cuando se han ejecutado todas sus posibles ramas.

Cobertura de condiciones múltiples: Comprueba el número de condiciones múltiples ejecutadas, considerando que se ha ejecutado una condición múltiple cuando se han ejecutado todas sus correspondientes ramas con todas las posibles variantes de la instrucción condicional.




Cobertura de condiciones/decisiones: Comprueba el número de condiciones y decisiones que se han ejecutado.

Cobertura de caminos: Comprueba el número de caminos linealmente independientes que se han ejecutado en el grafo de flujo de la unidad que se está probando.




Cobertura de funciones: Comprueba el número de funciones y procedimientos que han sido llamados.

Cobertura de llamadas: Comprueba el número de llamadas a funciones y procedimientos que se han ejecutado.

Uso de herramientas: Las pruebas de caja blanca se pueden hacer con un depurador (debugger)

Puede aplicarse a otros niveles de prueba



¿Qué hacer en la práctica?

Acercarse al 100% de segmentos

Lograr una buena cobertura de ramas

La buena cobertura depende del tipo de programa

Juegos basta con probar 60-80% del código

Aplicaciones críticas (sanitarias, centrales nucleares, aplicaciones militares, etc.) >90%

La cobertura requerida suele crecer con el grado de distribución del programa



Ejemplo


5.5 Técnicas Basadas en la Experiencia

Experiencia

Intuición

Grados de efectividad dispares

Predicción de errores

Lista de posibles defectos

Previsión de errores

Útiles en caso de pocas especificaciones y poco tiempo



Depende de:

Tipo de sistema

Estándares normativos

Requisitos: contractuales o de cliente

Nivel y tipo de riesgo

Objetivos de prueba

Documentación

Experiencia



Depende de:

Tiempo

Dinero

Ciclo de vida del desarrollo

Casos de uso

Etc…


Ejercicios

Comparar los términos: condición de prueba, caso de prueba y procedimiento de prueba

Explicar las características, coincidencias y diferencias entre las pruebas basadas en la especificación, las pruebas basadas en la estructura y las pruebas basadas en la experiencia

Explicar el concepto de las pruebas de casos de uso y sus ventajas

Explicar las principales características de la cobertura de sentencia

plan de estudios istqb: nivel fundamentosdinamizaconsulting.com/istqb/t5-tecnicas del diseno de...

Documents