Please enable JavaScript.

Coggle requires JavaScript to display documents.

Pruebas de Software - Coggle Diagram

- - - - Diseño de casos de prueba
        
        Prueba
        
        Comparación y evaluación de resultados
        
        Localización del error
  - - - 1. Pruebas de caja negra
        
        Este tipo de pruebas se considera el software como una caja negra, sin preocuparse los detalles procedimentales de los programas. De esta manera, los datos de entrada, deben generar una salida coherente con las especificaciones; si no es así, es porque ha encontrado un error el cual debe ser corregido para continuar con las pruebas. Las dos técnicas más comunes son:
        
        - Partición de Equivalencia
        
        En este tipo de prueba, la entrada de un programa se divide en las clases de datos los cuales se puedan derivar casos de prueba, teniendo en cuenta las siguientes pruebas
        
        Si la entrada es un rango o un valor específico, se define una clase de equivalencia válida y dos inválidas
        
        Si la entrada es un valor lógico, se define una equivalencia válida y otra inválida
        
        - Análisis y de valores límite
        
        Después de probar todos los casos en la técnica de participación de equivalencia, se prueban los valores fronterizos de cada clase (valores límite)
      - 2. Pruebas de caja blanca
        
        Las pruebas de caja blanca permiten probar la lógica interna del programa y su estructura, realizando las siguientes acciones:
        
        Ejecución de todas las sentencias (al menos una vez)
        
        Recorrido de todos los caminos independientes de cada componente
        
        Comprobación de todas las decisiones lógicas
        
        Comprobación de todos los bucles
        
        Implementación de situaciones extremas o límites.
  - - - Aplicar el análisis de valor límite
      - Diseñar casos con la técnica de participación de equivalencia
      - Utilizar la técnica de conjetura de error, combinando entradas y usando casos típicos de error
      - Utilizar pruebas de caja blanca
      - Se pueden utilizar diversos formatos para el diseño de los casos de prueba, los cuales deben incluir entre otros
        
        Identificación del caso de prueba
        
        Caso de uso a probar
        
        Datos de entrada
        
        Salidas esperadas
        
        Secuencia de pasos a seguir
        
        Estado
        
        Fecha y hora de realización
        
        Responsable
  - - - Plan de pruebas
      - Especificación de requerimientos para el diseño de caso de prueba
      - Caso de prueba con descripción del procedimiento y del ítem a probar
      - Reporte de incidentes de prueba
      - Resumen de pruebas
    - - Aunque el plan de pruebas se utiliza en la fase de pruebas, se debe definir en la etapa de diseño, que es cuando se especifica la arquitectura del sistema. Los principales elementos que se deben especificar en un plan de pruebas de acuerdo con el estándar IEEE 829-2008 son:
        
        El alcance y los riesgos asociados
        
        Los objetivos y el criterio de finalización de las pruebas (condiciones de suspensión y reanudación
        
        El tipo de técnicas a aplicar
        
        Método de estrategia de pruebas y tiempo límite disponible
        
        Los recursos requeridos para realizar las pruebas: personal, entorno de pruebas, presupuesto
        
        Priorización de los casos de prueba
        
        Responsabilidades
        
        Programación de los casos de prueba
- - - - Funcionalidad: satisfacción a las necesidades de adaptabilidad, exactitud, interoperabilidad, cumplimiento y seguridad-
      - Confiabilidad: cantidad de tiempo en el que el software se encuentra-
      - Usabilidad: facilidad para usar, siendo entendible y operable.
      - Eficiencia: uso óptimo de los recursos del sistema
      - Facilidad de recibir Mantenimiento: facilidad para realizar reparaciones, es decir, es analizable, estable, susceptible a pruebas.
      - Reusabilidad: grado en el que puede ser usado por otras aplicaciones.
      - Intuitiva: la interfaz sigue patrones de uso esperados, facilitando la comprensión, localización de operaciones y la entrada de datos.
      - Eficiencia: grado en el que es posible localizar o iniciar las operaciones y la información.
      - Robustez: capacidad para tratar entradas erróneas de datos o interacción inapropiada del usuario.
      - Riqueza: interfaz con abundantes características, que permite la personalización según las necesidades del usuario, y la identificación de una secuencia de operaciones comunes por medio de una acción o comando.
    - - En el control de la calidad de software se distinguen procesos de evaluación propios de proceso de desarrollo de software a verificación y validación:
        
        TÉCNICAS PARA V&V
        
        Estáticas
        
        Buscan fallas en el sistema en reposo, analizando los distintos modelos que lo componen. Se aplican a requisitos, modelos de análisis y diseño, y al código.
        
        Dinámicas
        
        Buscan fallas mediante entradas al sistema en funcionamiento. Se denominan pruebas de software o testing, y se aplican al código
  - - - Características de operación
      - Capacidad para soportar cambios (ser modificado)
      - Adaptabilidad a nuevos cambios