Fundamentos del proceso de testing funcional II – (Pruebas de Integración)
Pruebas de integración
Definición
Son las pruebas que definen la interrelación de los elementos del software (componentes). La integración es el proceso por el cual los elementos básicos del software (componentes) son agrupados en elementos mayores. Si estos elementos se unen a su vez entre si, esto también pertenece a la integración Aún cuando los componentes básicos pasen sin error las pruebas de componentes debe comprobarse su funcionalidad externa y la interrelación entre todos los componentes. Ello implica pruebas de interoperabilidad entre diferentes componentes de un software.
¿Qué se prueba?
En las pruebas de integración (caja blanca) se comprueba la interoperabilidad entre elementos básicos (grupos de elementos) del software y la funcionalidad de las interfaces. Cada elemento básico debería haber sido comprobado antes de que comience la integración. También se comprueban las interfaces con el entorno del sistema, se hace bajo condiciones reales, ya puede haber factores adicionales que afecten al funcionamiento del componente. Las pruebas de integración no pueden por ello garantizar una funcionalidad sin defectos en el entorno real del sistema. No se prueba lo que debería haber, si no que lo que hay funciona tal y como ha sido implementado.
¿Dónde y como se prueba?
Se realizan pruebas de la interrelación de los elementos del software (componentes). Se usan stubs y controladores de prueba:
Stubs:
- Sustituyen a los componentes que faltan.
- Asumen las tarea elementales de los componentes que falten (aun no han sido integrados)
Controladores de prueba:
- Proporcionan el entorno de ejecución del sistema (subsistema).
- Producen entradas y salidas para el sistema y registran datos.
- Los controladores usados para las pruebas de componentes pueden ser reutilizados.
¿Por qué se prueba?
Con estas pruebas se persigue encontrar errores de interfaces, se comprueba el correcto funcionamiento conjunto de los componentes (entre otras cosas también con vistas al rendimiento o a la seguridad). Los errores de interface no aparecen hasta después de la integración de los elementos básicos. Si se cambian los controladores y los stubs por interfaces de componentes “reales” pueden aparecer circunstancialmente errores. Por ejemplo, se pueden perder ciertos datos, no transmitirse o transmitirse de manera errónea, …
Las pruebas de integración deben realizarse después de las pruebas de componentes por que los errores detectados en las pruebas de componentes pueden detectarse aquí pero su localización es muy costosa.
Además hay muchas pruebas de componente que no pueden lanzarse en esta fase.
Pruebas e integración
Existen diferentes alternativas para las estrategias de integración. Generalmente son establecidas por el gestor/responsable de pruebas, el modo de proceder es incremental excepto en la de Big Bang. La elección de la estrategia deberá tener en cuenta la eficiencia de las pruebas. La terminación de los componentes fija para cada estrategia de integración el marco temporal, sin unos componentes probados no es eficaz una estrategia de integración encaminada a ahorrar esfuerzos, en función del proyecto se deberá sopesar entre el ahorro de tiempo y el esfuerzo en pruebas.
Si se prueba lo que está terminado, eventualmente se genera un mayor esfuerzo, pero no existen periodos de inactividad.
Si se sigue una estrategia preestablecida hay un menor esfuerzo, pero eventualmente se pueden generar periodos de inactividad.
Estrategias de Integración
Bottom-Up
Se realiza de abajo a arriba, se comienza por aquellos componentes que no llaman a otras partes del programa, a continuación siguen los componentes que sólo llaman a la parte ya integrada, se aplica principalmente en desarrollos nuevos, pruebas de equipos grandes y distribuidos, no existen huecos que deban ser completados por stubs. Los componentes superiores deber ser simulados mediante controladores de prueba.
La implantación usando esta estrategia solo es posible para el software construido de forma jerarquica.
Top-Down
Estas pruebas se realizas de arriba a abajo, se comienza por aquellos componentes que no son llamados por otras partes del programa, siguen los componentes que únicamente son llamados por la parte ya integrada. Se aplica cuando se utiliza software ajeno o Frameworks. No son necesarios los controladores de prueba y los componentes inferiores deber ser sustituidos por stubs. Como en el caso anterior la implantación usando esta estrategia solo es posible en software construido de forma jerárquica.
Integración orientada al proceso de negocio
Se comienza por los componentes necesarios por parte de un proceso de negocio. Los componentes inferiores deber ser sustituidos por stubs. Los componentes superiores deber ser simulados mediante controladores de prueba.
Integración orientada a funciones
Se comienza por los componentes necesarios por una función elegida del sistema. Los componentes inferiores deber ser sustituidos por stubs. Los componentes superiores deber ser simulados mediante controladores de prueba.
Integración Ad-Hoc
Se comienza por los componentes que han ya han sido desarrollados y probados de forma inmediata. Dependiendo del componente terminado son necesarios Stubs (para componentes inferiores) y/o controladores de prueba (para componentes superiores). Esta estrategia puede ser usada en cualquier situación y se suele combinar con otras técnicas.
Integración no incremental (Big Bang)
Se realiza en el momento que se dispone de todos los componentes integrados. No son necesarios ni stubs ni controladores de prueba. El área de pruebas dispone de mucho tiempo muerto, ya que tiene que esperar a que el producto esté terminado, y si se encuentran defectos, a que estén corregidos. Los efectos de los errores aparecen con frecuencia y son difíciles de rastrear. Son pruebas más complicadas y amplias. Normalmente este tipo de pruebas se aplica en proyectos de mantenimiento, ampliación, así como en migraciones.
¿Cómo se pueden coordinar la integración y las pruebas?
Tanto si estás buscando trabajar full time, como suplementar tus actuales ingresos con desarrollos adicionales a los que estás haciendo en tu actual trabajo, o quieres implicarte en el desarrollo de proyectos opensource y apoyar a la comunidad, rellena el formulario que hay a continuación y nos pondremos en contacto contigo para ver los proyectos en los que podemos colaborar.