Please enable JavaScript.

Coggle requires JavaScript to display documents.

Pruebas de integración - Coggle Diagram

- - - - Un mes debe ser: 1 ≤ mes ≤ 12
      - Un día debe ser: 1 ≤ día ≤ 31
      - Deben ser enteros positivos
      - Un año debe ser: 1812 ≤ 2012
    - - Un año es bisiesto si es divisible por 4
      - A menos que sea un año centenario, entonces solo es bisiesto si es múltiplo de 400
- - - - Top-down
      - Bottom-up
      - Big bang
      - Sándwich
  - - - Por pares
      - De vecindad
- - - - Permitiéndonos crear entornos de prueba más fácilmente debido a los resultados más simples de esos módulos
    - - En caso de que haya resultados que no coincidan con los esperados, sabremos cual es el módulo que está causando el problema
      - Parece ser una opción más natural que la integración descendente para este ejemplo
    - - Trabajar hacia el nivel superior, a la raíz del árbol
      - Comience en las hojas del árbol de descomposición funcional
    - - Fácil de crear entornos de prueba
      - Fácil manejo de excepciones
      - Menos programación de códigos desechables
    - - Programa principal probado por última vez
      - Tarde para identificar errores de diseño
      - Sin prototipo
      - Alto costo de corrección de errores
  - - - Los casos de prueba estarán limitados por cómo y qué codificamos en el código auxiliar
      - Comenzaríamos con Main como un nodo de destino y reemplazaríamos los nodos secundarios uno por uno con stubs
    - - Pasa de los módulos de nivel superior a los módulos de nivel inferior
      - La integración comienza en el programa principal
    - - Prototipo temprano de SUT
      - Diseño e implementación de intercalados
    - - Pruebas de interacción tardía entre el programa principal, la capa de aplicación y el hardware
      - Dificultad para crear casos de prueba
      - Programación de código desechable
  - - - Debemos crear un solo conjunto de pruebas que cubra las condiciones aprobadas por diferentes módulos
      - Cuando hay un caso de prueba que produce un valor incorrecto, será más difícil deducir las razones porque
    - - Prueba todos los módulos en una sola sesión de prueba
      - Solo una sesión de prueba de integración
      - Considera a todo el sistema como un subsistema
    - - Prototipo temprano de SUT
      - Diseño e implementación de intercalados
    - - Pruebas de interacción tardía entre el programa principal, la capa de aplicación y el hardware
      - Dificultad para crear casos de prueba
      - Programación de código desechable
  - - - En este ejemplo, podemos usar un enfoque de arriba hacia abajo para los módulos en el nivel superior del árbol
        
        Por ejemplo, Main, incrementDate y printDate
      - Mientras que en el nivel inferior, utilizamos un enfoque de abajo hacia arriba
        
        Por ejemplo, isLeap,lastDayOfMonth y validDate.
      - El enfoque de integración sándwich es conocido por su flexibilidad en la integra
    - - Normalmente, los módulos de nivel inferior utilizan un enfoque de abajo hacia arriba (controlador)
      - Las pruebas convergen hacia el medio
      - En general, los módulos de nivel superior utilizan un enfoque de arriba hacia abajo (stub)
      - El número de sesiones de integración puede variar
      - Combina el enfoque de arriba hacia abajo y el enfoque de abajo hacia arriba
      - El número máximo de sesiones es el número de subárboles del sistema
    - - Casos de prueba fáciles de construir
      - Mejor control de cobertura
      - Se necesitan menos talones y controladores
      - La integración se realiza tan pronto como se implementa un componente
      - Las capas superior e inferior se pueden hacer en paralelo
    - - Integración big bang parcial
      - Problemas difíciles de aislar
      - Todavía requiere programación de código descartable
- - - - Emparejamos los módulos de acuerdo con los bordes del gráfico de llamadas
        
        Por ejemplo, lastDayOfMonth con isLeap y Main con printDate
      - Podremos eliminar el problema de las sesiones de prueba vacías
    - - El emparejamiento de módulos se basa en los bordes del gráfico de llamadas
      - El número de sesiones de prueba de integración es el número de aristas
      - Cada sesión de prueba está restringida a solo un par de módulos
    - - Se elimina la necesidad de trozo y conductor
      - Uso de código real
    - - Muchas sesiones de prueba
  - - - Esto causa dificultad en el aislamiento de fallas
    - - Neighbourhood of incrementDate: Main, lastDayOfMonth
      - Neighbourhood of Main: getDate, incrementDate, printDate
      - Neighbourhood of getDate: Main, validDate
      - Neighbourhood of lastDayOfMonth: validDate, incrementDate, isLeap
      - Agrupamos los módulos de manera que todos los módulos que son sucesores inmediatos
      - Neighbourhood of validDate: getDate, lastDayOfMonth
    - - Un módulo vecino es un módulo que es el sucesor o predecesor inmediato de otra unidad
      - Los módulos se agrupan como barrios
    - - Uso de código real
      - Reducción de sesiones de prueba
      - Se elimina la necesidad de trozo y conductor
    - - Fallas difíciles de aislar
- - - - Message Quiescence
        
        Cuando llegamos a una unidad que no envía mensajes
      - Data Quiescence
        
        Cuando terminamos un conjunto de ejecución con la creación de datos que se almacenan pero no se usan de inmediato
    - - Un problema principal cuando se usa este enfoque es saber cuántos MM-Paths se requieren para completar la prueba de integración
    - - El conjunto de MM-Paths debe cubrir todas las rutas de fuente a sumidero
      - Los puntos de inactividad son puntos finales naturales para un MM-Path
      - Los mensajes enviados entre módulos son rastreados
      - El número de sesiones de prueba de integración depende del sistema en cuestión
    - - Estrechamente relacionado con el comportamiento real del sistema
      - No requiere talón ni conductor
      - Híbrido de pruebas funcionales y estructurales
    - - Esfuerzo adicional requerido para identificar los MM-Paths