MARIANO SEIXO GRUEIRO - Tema 4 –Técnicas de diseño de pruebas

Annotations:

•  El análisis y diseño de pruebas es la segunda fase del proceso de las pruebas de software

1. Proceso de desarrollo de pruebas (SE CREAN DOCUMENTOS)
   1. 1) Identificar las CONDICIONES de test 1) Decidir una CONDICIÓN de prueba
      1. Condición de prueba: podemos comprobar con una prueba o un conjunto de pruebas. PONER UNA CONDICIÓN DE RETIRAR O NO 25.000 EUROS O EL MIRAR SI LA PUERTA ESTÁ ABIERTA O NO ANTES DE SALIR DA CLASE

         Annotations:

         • ítem o evento de un componente o sistema que podría ser verificado por uno o más casos de prueba( por ejemplo, una función, transacción, característica, atributo de calidad o elemento estructural).
      2. Test DESIGN specification
   2. 2) Especificar los CASOS de test 2) Diseñar un CASO de prueba
      1. Caso de prueba: punto de partida para test, aplica valores y deja en un punto final. PE 25000 EUROS CARGO, UN CASO CONCRETO, ES UNA ACCIÓN. O SI ME DICEN QUE SALGA DE CLASE

         Annotations:

         • conjunto de valores de entrada, precondiciones de ejecución, resultados esperados y post condiciones deejecución desarrollados para un objetivo particular o una condición de test, como ejercitar un aparte de un programa o verificar el cumplimiento de un requisito específico.
      2. Test CASE specification
   3. 3) Especificar los PROCESOS de test 3) Escribir un PROCEDIMIENTO (o script) para ejecutar la prueba
      1. Test PROCEDURE specification
      2. PROCESO DE PRUEBA: seria el realizar todas las acciones de los casos con las condiciones
   4. IEEE 829 propone cómo deben ser estos documentos
      1. ESTÁNDAR IEEE 829: PLANTILLA DE ESPECIFICACIÓN DE CASOS DE PRUEBA
         1. IDENTIFICADOR de caso de test
         2. ITEMS de pruebas.
         3. ESPECIFICACIONES ENTRADA (entradas, usuarios, archivos, etc.).
         4. ESPECIFICACIONES SALIDA (resultados esperados -incluyendo pantallas por ejemplo-, archivos, tiempo, etc.).
         5. NECESIDADES DEL ENTORNO (hardware, software, personas, etc.).
         6. REQUISITOS ESPECIALES del procedimiento (permisos, operadores, etc.).
         7. DEPENDENCIA entre casos (si es necesario, para establecer condiciones previas).
2. Categorías de técnicas de diseño de casos de prueba
   1. Técnicas basadas en ESPECIFICACIONES, de CAJA NEGRA o COMPORTAMIENTO
      1. CARACTERISTICAS CAJA NEGRA
         1. No utilizan ninguna información sobre la estructura interna del componente o sistema a probar
         2. derivan los CASOS DE PRUEBA directamente de las especificaciones o de otro modelo disponible del sistema. La fuente de información empleada esla “base de las pruebas o tests”.
         3. DOCUMENTACIÓN es muy informal o inexistente, lo que provoca que deba crearse algún tipo de modelo que ayude a diseñar las pruebas
         4. Especificaciones= lo que el sistema debe hacer (funcional y no funcional) Diseño= cómo debe hacerlo
         5. procedimiento para derivar y/o seleccionar casos de prueba basados en un análisis de la especificación.
      2. Técnica 1: PARTICIONES EQUIVALENTES
         1. las ENTRADAS o INPUTS para un programa se pueden agrupar en grupos de INPUTS similares.
            1. Cada uno de estos grupos es una “partición de equivalencia”

               Annotations:

               • Cada uno de estos grupos es una “partición de equivalencia ”porque todos los valores que forman el grupo son equivalentes entre sí por lo que respecta al programa
            2. VÁLIDAS

               Annotations:

               • grupos de valores válidos para el programa
            3. NO VÁLIDAS
         2. particiones de los RESULTADOS o OUTPUTS
         3. particiones basadas en mayor conocimiento del programa
         4. es suficiente con probar con uno de los valores como representante de la partición (en general, buscando un valor intermedio).
      3. Técnica 2: ANÁLISIS DE VALORES LÍMITE
         1. Los errores tienden a concentrarse en los límites de las particiones (debido a los bucles)
         2. encaja bien con técnica de las particiones, ya que estas tienen límites, en los que podemos encontrar valores límite (válidos y no válidos)
         3. 2 enfoques
            1. 2 valores límites: límite de la partición y el siguiente valor dentro de la partición
            2. 3 valores límites: límitedelapartición y los dos siguientes valores (dentro y fuera de la partición). Especialmente con este enfoque, valores límite de un apartición se pueden repetir en otra.
      4. Técnica 3: Prueba de TABLAS DE DECISIÓN
         1. Las especificaciones suelen contener “reglas de negocio” para definirlas funciones del sistema y las condiciones bajo las que cada función opera
         2. probar que cada combinación de las condiciones que se, así que debemos contemplar todas las posibles decisiones
         3. tabla de decisión: lista todas las condiciones de entrada (solo faltan los outputs)
         4. imitando las posibles combinaciones a aquellas que corresponden a reglas de negocio, por lo que estrictamente deberíamos hablar de “tablas de decisión de entradas limitadas”
         5. se eliminan las columnas repetidas o que no aporten nada
      5. Técnica 4: Test deTRANSICIÓN DE ESTADOS
         1. sistemas cuyo comportamiento depende de un “estado” presente y pasado, en los que hay transiciones entre estados
         2. diagramas de transición de estados
            1. Círculos (estados): el sistema, cuando está en un estado, permanece en él a menos que algún evento suceda y provoque un cambio de estado
            2. Flechas (transiciones): los eventos o acciones que provocan cambios de estados ( y a veces OUTPUTS)
            3. Círculo doble o una flecha sin origen suelen marcar el estado inicial
      6. Técnica 5: Prueba de CASOS DE USO
         1. especificar la funcionalidad basada en definir usos típicos de un software
            1. útiles en las PRUEBAS DE ACEPTACIÓN, ya que se corresponden con USOS TÍPICOS del software,
            2. útiles en PRUEBAS DE SISTEMA al probar la comunicación entre varios módulos
            3. CAMINO o PATH (RUTA o camino) principal a seguir y uno o varios caminos ALTERNATIVOS más relacionados con condiciones extrañas o errores.
   2. Técnicas basadas en la ESTRUCTURA, ESTRUCTURALES o de CAJA BLANCA
      1. Técnicas basadas en la ESTRUCTURA o de CAJA BLANCA
         1. test de SENTENCIAS ó prueba de SENTENCIAS para COMPROBAR cobertura de SENTENCIAS
            1. probar sentencias concretas
            2. % sentencias es la cobertura del test
            3. 100% COBERTURA DE SENTENCIAS no implica se hayan realizado todas las pruebas necesarias
            4. en ejemplo a>b se prueba que se cumpla
         2. test de DECISIONES ó pruebas de DECISIONES para COMPROBAR cobertura de DECISIÓN ó cobertura de CONDICIÓN
            1. probar condición cierta y también falsa
            2. El % de resultados de decisiones probadas es la COBERTURA de la prueba (COBERTURA DE DECISIÓN O
            3. prueba la SENTENCIA y lo contrario también
            4. en ejemplo a>b que se cumpla y lo contrario también (TODO LO QUE NO SEA A>B, como A<B O A=B)
         3. otras técnicas
            1. en todos los casos puede definirse cobertura (p.e.,de interfaces entre componentes o de opciones del menú probadas).
            2. otras técnicas disponibles que examinan más y en escenarios más complejos.
         4. sirven para pruebas en varios NIVELES
            1. COMPONENTES (lo más habitual): para probar estructuras del código (decisiones , bucles , quetodo el código se ejecuta, etc.).
         5. STATEMENT COBERTURE
         6. DECISION / BRANCH / COVERAGE
      2. Basadas en la derivación de casos de prueba directamente de la estructura de un componente o sistema