Las pruebas de validación en la ingeniería de software son el proceso 
de revisión que verifica que el sistema de software producido cumple 
con las especificaciones y que logra su cometido. 
Es normalmente una parte del proceso de pruebas de software de un 
proyecto, que también utiliza técnicas tales como evaluaciones, 
inspecciones y tutoriales.
4.2.1 INTEGRACION 
La prueba de integración es una técnica sistemática para construir la 
estructura del programa mientras al mismo tiempo, se lleva a cabo 
pruebas para detectar errores asociados con la interacción. 
El objetivo es tomar los módulos probados en unidad y estructurar un 
programa que esté de acuerdo con el que dicta el diseño. 
Pruebas de integración. 
Errores. 
 comunicación a través de la interface. 
 efectos colaterales perniciosos. 
 acumulación notable de errores de cálculo. 
 acceso incoherente a estructuras de datos globales. 
 tiempos de respuesta
4.2.1.1 DESCENDENTE 
• De arriba hacia abajo, avanzado. 
• primero en profundidad. 
• primero en anchura. 
• tomamos el módulo principal como driver. 
• Substituimos los módulos dependientes por stubs 
Estrategia descendente (cont). 
• Realizando pruebas específicas para el modulo 
• Repitiendo las realizadas previamente (pruebas regresivas) 
• Progresamos sustituyendo stubs por módulos reales
4.2.1.2 ASCENDENTE 
• Agrupamos los módulos inferiores (según funcionabilidad 
p.e.) 
• Preparamos un driver para cada grupo y realizamos las 
pruebas. 
• Progresamos sustituyendo los driver por módulos reales. 
• Realizamos pruebas específicas y regresivas.

Expo4.2

  • 1.
    Las pruebas devalidación en la ingeniería de software son el proceso de revisión que verifica que el sistema de software producido cumple con las especificaciones y que logra su cometido. Es normalmente una parte del proceso de pruebas de software de un proyecto, que también utiliza técnicas tales como evaluaciones, inspecciones y tutoriales.
  • 2.
    4.2.1 INTEGRACION Laprueba de integración es una técnica sistemática para construir la estructura del programa mientras al mismo tiempo, se lleva a cabo pruebas para detectar errores asociados con la interacción. El objetivo es tomar los módulos probados en unidad y estructurar un programa que esté de acuerdo con el que dicta el diseño. Pruebas de integración. Errores.  comunicación a través de la interface.  efectos colaterales perniciosos.  acumulación notable de errores de cálculo.  acceso incoherente a estructuras de datos globales.  tiempos de respuesta
  • 3.
    4.2.1.1 DESCENDENTE •De arriba hacia abajo, avanzado. • primero en profundidad. • primero en anchura. • tomamos el módulo principal como driver. • Substituimos los módulos dependientes por stubs Estrategia descendente (cont). • Realizando pruebas específicas para el modulo • Repitiendo las realizadas previamente (pruebas regresivas) • Progresamos sustituyendo stubs por módulos reales
  • 4.
    4.2.1.2 ASCENDENTE •Agrupamos los módulos inferiores (según funcionabilidad p.e.) • Preparamos un driver para cada grupo y realizamos las pruebas. • Progresamos sustituyendo los driver por módulos reales. • Realizamos pruebas específicas y regresivas.