Técnicas de diseño de pruebas

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

Siguiente

Técnicas de diseño de pruebas

Descripción

Resumen del Recurso

Similar

	Creado por Alcides Penaranda hace más de 7 años