Pruebas de Integración.
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. La integración
puede ser descendente si se integran los módulos desde el control o programa principal,
o bien, ascendente, si la verificación del diseño empieza desde los módulos más
bajos y de allí al principal. La selección de una estrategia de integración
depende de las características depende de las características del software y, a
veces, del plan del proyecto, en algunos de los casos se puede combinar ambas
estrategias.
Diseñadas para probar la
interacción entre los distintos componentes de un sistema.
Tipos de errores:
·
Errores de
programación entre componentes.
·
Errores de
interoperabilidad.
Estrategias de pruebas:
·
Pruebas no incrementales (“Big Band Approach”):
Se integran todos los componentes
y entices se prueba el Sistema como un todo. No es una técnica recomendada pues
dificulta el aislamiento de errores.
·
Pruebas incrementales:
El programa es
construido y probado en pequeños incrementos. Facilita el aislamiento de
errores y las pruebas sistemáticas.
o Integración descendente (Top-down).
§ En profundidad (Depth-first).
§ En anchura (Breadth-first).
o Integración ascendente (Bottom-up).
Integración descendente.
·
Permite verificar
los puntos de control o decisión al principio del proceso de prueba.
·
La integración
en profundidad permite probar funcionalidades completas lo cual aumenta la
confianza.
·
Puede
requerir el uso de muchos stubs.
La integración se
realiza partiendo del programa principal y moviéndolos hacia abajo por la jerarquía
de control.
Integración descendente
en profundidad.
La integración se realiza
por ramas. Cada rama suele implementar una funcionalidad específica.
Integración descendente
en anchura.
La integración se
realiza por niveles moviéndose en horizontal por la estructura de control.
Integración ascendente.
·
Se elimina
la necesidad de usar stubs.
·
Es necesario
el uso de controladores de prueba (“drivers”) a fin de coordinar la entrada y
salida de casos de prueba.
La integración se
realiza partiendo de módulos atómicos situados en los nodos finales de la jerarquía
de control. No suele necesitar el uso de stubs.
Pruebas
de Sistema.
Diseñadas para probar el sistema en su totalidad como si de una caja
negra se tratase.
Un clásico problema de la prueba del sistema es la delegación de
culpabilidad. Esto ocurre cuando se descubre un error t cada uno de los
creadores de cada elemento del sistema echa la culpa del problema a otros, para
evitar esto se debe prever y tomar medidas correctivas tomando en cuenta lo
siguiente:
- Diseñar caminos de manejo de errores que prueben toda la información procedente de otros elementos del sistema.
- Lleva a cabo una serie de pruebas que simulan la presencia de datos en mal estado o de otros posibles errores en la interfaz del software.
- Registrar los resultados de las pruebas como “evidencias” en el caso de señalamientos informales.
- Participar en la planificación y diseño de las pruebas del sistema para asegurarse de que el software es probado en forma adecuada.
La prueba del sistema se basa en otras técnicas de pruebas, aunque la
finalidad de cada prueba es distinta, sirven para verificar que se hayan
integrado correctamente cada uno de los elementos del sistema:
- Prueba de Recuperación: es una prueba que se hace al sistema forzando a que produzca fallas de software de muchas maneras y verificando que la recuperación se lleve a cabo, ya sea automáticamente o manual, tomando en cuenta los recursos que se requieran para efectuar la recuperación.
- Prueba de Seguridad: intenta verificar la aplicación de los mecanismos de protección incorporados en el sistema. Durante la prueba el encargado desempeña el papel de intruso tratando de violar la seguridad del sistema, intentando obtener las claves de acceso por cualquier medio externo; debe bloquear el sistema negando así el servicio a otras personas además de producir errores a propósito en el sistema o debe curiosear los datos públicos intentando encontrar una clave de acceso al sistema.
- Prueba de Resistencia: está diseñada para enfrentar a los problemas en situaciones anormales, es decir ejecutar el sistema en forma que demande recursos en cantidad, frecuencia o volúmenes anormales. El encargado de la prueba debe intentar tirar el sistema. Para lograr esto se puede tomar en consideración lo siguiente:
- Diseñar pruebas especiales que generen 10 o más interrupciones por segundo.
- Incrementar la frecuencia de datos de entrada en un orden de magnitud con el fin de comprobar cómo responden las funciones de entrada.
- Ejecutar casos de prueba que requieran al máximo de memoria o de espacio en disco.
- Diseñar casos de prueba que produzcan excesivas búsquedas de datos almacenados en el disco.
