Zusammenfassung der Ressource
Técnicas de diseño de pruebas
- Proceso de desarrollo de pruebas
- Obtención de casos de prueba a partir de los requisitos, este proceso debe ser
controlado y los casos de pruebas pueder ser creados formal o informalmente
- Trazabilidad: Las pruebas deben ser trazables, esto ayuda a determinar la
calidad de los requisitos y establecer la calidad de los casos de prueba
- Definiciones:
- Objeto de prueba: Elemento a ser revisado (documento o pieza de software)
- Condición de prueba: Elemento, evento o sistema que debe ser verificado por 1 o + casos
- criterios de prueba: resultado esperado
- calendario de ejecución de prueba: Un esquema con orden para la ejecución de procedimientos de prueba
- Especificación de diseño de prueba: Documento que especifica las condiciones de prueba, para el
elemento de prueba, el enfoque de prueba detallada y especifica los casos de prueba de alto nivel IEEE829
- Especificación de casos de prueba: Documento que especifica un conjunto de casos de prueba (objetivos,
entradas, acciones de prueba, resultados esperados y precondiciones de ejecución) para un elemento de prueba IEEE829
- Caso de prueba (IEEE 829)
- Identificador / Código
- Precondiciones
- Valores de entrada
- Resultados esperados
- Postcondiciones
- Dependencias
- Identificador distinguible
- Requisitos
- Categorias
- Métodos basados en la especificación (caja negra)
- El objeto de prueba ha sido seleccionado de acuerdo con el modelo funcional
- La cobertura de la especificación puede ser medida
- Métodos basados en la estructura (caja blanca)
- La estructura interna de los objetos de prueba es utilizado para diseñar los casos de prueba
- El porcentaje de cobertura es medido y utilizado como fuente para la creación de casos de prueba
- Métodos basados en la experiencia
- El conocimiento y experiencia respecto a los objetos de prueba
son las fuentes para el diseño de casos de prueba
- El conocimiento y experiencia con respecto a los puntos débiles, posibles errores
y errores previos son utilizados para determinar o definir los casos de prueba
- Técnicas basadas en la
especificación o de caja negra
- Visión general: Las pruebas funcionales están dirigidas a verificar la corrección y completitud de una función,
probar lo menos posible y probar tanto como sea necesario
- Partición de equivalencia o clases de equivalencia
- Se dividen los posibles valores en clases mediante lo cual observan valores de entrada y salida
- El rango de valores definidos se agrupan en clases de equivalencia
- Todos los valores para los cuales se espera que el programa tenga un
comportamiento común se agrupan en una clase de equivalencia
- Las clases de equivalencia no pueden superponerse y no pueden presentar ningún salto de discontinuidad
- Las clases se equivalencia pueden consistir en un rango de valores
- CE válida: Todos los valores dentro del rango de definición
- CE no valida: Se distinguen 2 casos
1. Valores con el formato correcto
pero con un valor fuera del rango 2.
Valores con el formato incorrecto
- Los CE validos se pueden combinar
- Los CE no validos no se pueden combinar
- Una CE no valida solo se puede combinar con representantes de CE validas
- Cobertura (CE) = Número de CE probados / Número de CE definidos
- Cubre los requisitos funcionales y aplicable a todos los niveles de prueba
- Análisis de valores límites
- Amplia la técnica de partición CE introduciendo una regla para seleccionar el representante
- Los valores limites frecuentemente no están bien definidos, o no han sido implementados correctamente
- Es aplicable en todos los niveles de prueba
- Se debe escoger el limite inferior -1, limite inferior y limite inferior + 1
- Se debe escoger el limite superior -1 , limite superior y limite superior + 1
- Pruebas de tabla de decisión
- Una condición de entrada puede tener efecto solo en combinación con otras condiciones de entrada
- Se ayuda en el gráfico de causa y efecto
- Beneficios: Identificación sistemática de combinaciones de entrada, los
casos de prueba son fáciles de obtener a partir de la tabla de decisión
- Desventajas: El establecimiento de un gran número de causas conduce a resultados complejos y extensos
- Pruebas de transición de estados
- Todo estado ha sido alcanzado por lo menos una vez
- Toda transición ha sido ejecutada por lo menos una vez
- Buen método de prueba para objetos de prueba que pueden ser descritos como máquinas de estado
- Buen método de prueba para probar clases solo si el ciclo de vida esta disponible
- Con mucha frecuencia los estados son complejos
- Cubriendo todos los estados no se garantiza una cobertura completa de prueba
- Pruebas basadas en casos de uso
- El objeto de prueba es visto como un sistema reaccionando con actores, precondiciones, poscondiciones
- Se usa UML (Lenguaje Unificado de Modelado)
- Pruebas apropiadas para pruebas de aceptación y de sistema
- Útil para diseñar pruebas de aceptación con la participación del cliente
- Nula obtención de casos de pruebas adicionales
- Debería ser utilizado solo en combinación con otros métodos
- Técnicas basadas en la
estructura o de caja blanca
- Aplica para el nivel de componente, integración y sistema
- Todas las partes de un programa deberían ser ejecutadas por lo menos una vez durante las pruebas
- Requiere el apoyo de herramientas en muchas áreas
- Cobertura de sentencia
- Son los nodos
- Porcentaje de sentencias ejecutables
- El foco de la atención es la sentencia de un programa
- Formula: COBERTURA DE SENTENCIA = Número de sentencias ejecutadas / Número total de sentencias * 100
- Sera detectado el código muerto, si hay código muerto no hay 100% cobertura de sentencia
- Cobertura de decisión
- Son las ramas
- Se centra en el flujo de control en un segmento de programa
- El propósito es lograr la cobertura de un porcentaje especifico de todas las decisiones
- Formula: COBERTURA DE DECISION: Número de decisiones ejecutadas / Número total de decisiones * 100
- SI tengo 100% cobertura de decisión tengo 100% cobertura de sentencia
- No se puede detectar sentencias faltantes
- No es suficiente para probar bucles de forma extensiva
- Cobertura de condición
- Se tiene en cuenta la complejidad de una condición que este constituida por múltiples condiciones atómicas
- El objetivo es detectar defectos que resulten de implementar condiciones múltiples
- Cobertura de condición simple
- Siempre da 2
- Cada subcondición atómica de una sentencia condicional combinada tiene que
tomar al menos una vez los valores lógicos, verdaderos y falso
- Cobertura de condición múltiple
- Formula: 2^n
- Todas las combinaciones que pueden ser creadas deben hacer parte de las pruebas
- La ejecución de aglunas combinaciones no son posibles
- Mínima cobertura de condición múltiple
- Formula: n+1 y 2n
- Todas las combinaciones que puedan ser creadas utilizando los resultados lógicos de cada sub-condición deben ser parte
de las pruebas, si y solo si el cambio de resultado de una sub-condición cambia el resultado de la condición combinada
- Reduce los casos de pruebas
- Las coberturas de sentencia y decisión también son cubiertas
- Es adecuada para que todas las decisiones complejas sean probadas
- Cobertura de camino
- EL foco del análisis de cobertura es el gráfico del flujo de control
- Formula: COBERTURA DE CAMINO = Número de caminos cubiertos / número total de caminos
- Cuando no dan la cantidad de bucles, el resultado es indeterminado
- Cada incremento en el contador del bucle añade un nuevo caso de prueba
- El 100% de cobertura de camino solo se puede lograr en programas muy simples
- El 100% de cobertura de camino incluye 100% de decisión y 100% de sentencia
- Técnicas basadas en la experiencia
- Práctica para la creación de casos de prueba sin un claro enfoque metodológico basada en la intuición y experiencia del probador
- También se denominan pruebas intuitivas e incluyen: predicción de errores y pruebas exploratorias
- Principalmente aplicadas con el objeto de complementar otros casos de pruebas
- El probador debe contar con intuición, experiencia y conocimiento/percepción del objeto de prueba
- Predicción de errores:
- Comprobar lista de errores
- Diseñar casos de pruebas
- Actualizar la lista de defectos durante las pruebas
- Pruebas exploratorias:
- Es apropiado cuando la información base se encuentra poco estructurada
- También es útil cuando el tiempo disponible para pruebas es escaso
- Pasos: Revisar el objeto de prueba, ejecutar un número
reducido de casos de prueba, analizar los resultados e iterar
- Los resultados de una iteración constituyen la base de información para la siguiente iteración
- Selección de las técnicas de prueba
- Los probadores utilizan una combinación de técnica de pruebas, incluyendo
procesos, regla y técnicas guiada por datos para asegurar una cobertura adeucada
- Criterios para seleccionar el enfoque de diseño
- Fuente de pruebas
- Objetivos del proceso de pruebas
- Aspectos asociados al riesgo
- Estructura del proyecto / precondiciones
- Requisitos contractuales