¿Qué es exactamente una prueba de integración?

100

Mis amigos y yo hemos estado luchando para clasificar exactamente qué es una prueba de integración.

Ahora, camino a casa, me di cuenta de que cada vez que trato de dar un ejemplo de una prueba de integración en el mundo real, resulta ser una prueba de aceptación, es decir. algo que una persona de negocios diría en voz alta que especifica qué debería entregar el sistema.

Revisé la documentación de Ruby on Rails para ver su clasificación de estos tipos de pruebas, y ahora me arrojaron por completo.

¿Me puede dar una breve descripción académica de una prueba de integración con un ejemplo del mundo real?

    
pregunta Martin Blore 15.02.2011 - 20:03

7 respuestas

73

En este momento me gusta esta afirmación: "No es importante cómo se llama, sino lo que hace" hecha por Gojko Adzic en este artículo .

Realmente necesitas especificar con las personas que hablan sobre las pruebas lo que pretendes probar.

Hay muchas personas que tienen diferentes puntos de vista, dependiendo de cuál sea su función.

Para los evaluadores, una metodología de prueba generalmente aceptada en los Países Bajos es TMap . TMap hace la siguiente distinción.

  • prueba de unidad
  • prueba de integración de la unidad
  • prueba del sistema
  • prueba de integración del sistema
  • prueba de aceptación (todos los tipos / niveles)
  • prueba de aceptación funcional
  • prueba de aceptación del usuario
  • prueba de aceptación de producción

Tienen pruebas más específicas que pueden realizarse dentro de las pruebas mencionadas anteriormente. Mire esta palabra doc para una descripción general.

Wikipedia también tiene una buena descripción general .

El reserva el programador pragmático dice:

  • una prueba de unidad es una prueba que ejerce un módulo
  • las pruebas de integración muestran que las partes principales de un sistema funcionan bien juntas

Mirando estas diferentes fuentes y compartiendo algunas de mis propias experiencias y opiniones, comenzaría haciendo distinciones por tres categorías

  • quién hace las pruebas en general
  • lo que se prueba
  • ¿Cuál es el objetivo de la prueba

    • Prueba de unidad : prueba la lógica en las clases por parte de los programadores para mostrar la corrección del nivel de código. Deben ser rápidos y no depender de otras partes del sistema que no pretende probar
    • Prueba de aceptación funcional : los escenarios de caso de uso de prueba en un conjunto de datos limitado (especialmente creado) realizado por el departamento de pruebas para mostrar que cada escenario especificado funciona según lo especificado.
    • Prueba de aceptación del usuario : los escenarios de caso de uso de prueba están en producción, como los datos realizados por representantes de los usuarios para que acepten formalmente la solicitud
    • Prueba de integración : pruebe las rutas de comunicación entre diferentes partes del módulo realizadas por el departamento de pruebas o por los desarrolladores para mostrar que todos los módulos funcionan correctamente juntos.

Mi lista de arriba es solo un comienzo y una sugerencia, pero realmente pienso: "No es importante cómo se llama, sino qué hace"

Espero que esto ayude.

26-10-2016 Edición: Recientemente, se colocó una muy buena introducción en YouTube Pruebas de unidad vs. Pruebas de integración - MPJ's Reflexiones - FunFunFunction # 55

    
respondido por el KeesDijk 15.02.2011 - 21:15
29
  

prueba de integración, resulta ser una prueba de aceptación

Obviamente.

Estos dos son casi lo mismo. Pero hay algunas dimensiones ligeramente diferentes a la definición de prueba.

Integración == el sistema en su conjunto.

Aceptación == el sistema en su conjunto.

La única diferencia, y esto es sutil, es la definición de los casos de prueba.

Integración == casos de prueba para probar la profundidad y el grado de integración. ¿Funciona para todos los casos de borde y casos de esquina? Los casos de prueba tienden a ser técnicos, escritos por diseñadores y programadores.

Aceptación == casos de prueba para ejercer solo el 80% centrado en el usuario final del conjunto de funciones. No todos los casos de borde y esquina. Los casos de prueba tienden a ser no técnicos, escritos por usuarios finales.

    
respondido por el S.Lott 15.02.2011 - 20:57
15

Personalmente, me gusta pensar en una prueba de integración como en una prueba de características cuando cada componente del sistema es real , sin objetos simulados.

Un repositorio real, una base de datos real, una IU real. Usted prueba una funcionalidad específica cuando el sistema está completamente ensamblado y es como se supone que debe estar cuando se implementa.

    
respondido por el user8685 15.02.2011 - 20:41
7

En mi (yo admito) poca experiencia, entendí que la palabra integración realmente puede crear malentendidos: en realidad, es difícil encontrar algo completamente aislado en un sistema, algunos elementos necesitarán cierta integración con seguridad.

Por lo tanto, me acostumbré a hacer las siguientes distinciones:

  • Uso prueba de unidad para identificar, Documentar y subrayar todos los comportamientos. la clase que estoy probando es responsable cumplir.
  • Estoy haciendo pruebas de integración cada vez que tengo un componente (tal vez más de uno) en mi sistema que es tener alguna conversación con otro Sistema " externo ". (continúa abajo ...)
  • Implemento una prueba de aceptación para definir, documentar y subrayar un cierto flujo de trabajo que es esperado por el sistema.

En la definición de la prueba de integración, me refiero a un sistema externo que está fuera de mi rango de desarrollo : no puedo cambiar inmediatamente la forma en que se comportan, por cualquier motivo. Podría ser una biblioteca, un componente del sistema que no se puede cambiar (es decir, se comparte con otros proyectos en la empresa), un dbms, etc. Para estas pruebas, necesito configurar algo muy similar al entorno real del sistema. funcionará en: un sistema externo debe inicializarse y establecerse en un estado determinado; Los datos realistas deben estar registrados en la db; etc.

En cambio, cuando estoy haciendo pruebas de aceptación, falsifico : estoy trabajando en algo diferente, estoy trabajando en las especificaciones del sistema, no en su capacidad para colaborar con proveedores externos. entidades.

Esta es realmente una visión más estrecha en comparación con lo que KeesDijk describió anteriormente, sin embargo, supongo que los proyectos en los que trabajé hasta ahora eran lo suficientemente pequeños como para permitirme este nivel de simplificación.

    
respondido por el Marco Ciambrone 23.02.2011 - 17:08
5

Una prueba de integración verifica que los componentes de un sistema complejo (por ejemplo, software, aeronaves, planta de energía) están trabajando juntos según lo diseñado.

Imaginemos que estamos hablando de un avión (con el software es más abstracto y difícil de hacer la diferencia). Las pruebas de integración incluyen, verificando:

  • interacción correcta entre algunos componentes. Ejemplo: cuando se presiona el botón de arranque, el motor arranca y la hélice alcanza la velocidad de rotación esperada (el avión todavía permanece en tierra)
  • interacción correcta con componentes externos. Ejemplo: compruebe que la radio incorporada pueda comunicarse con una radio estacionaria (avión aún en tierra)
  • interacción correcta entre todos los componentes involucrados, para que el sistema en su conjunto funcione como se espera. Ejemplo: un equipo de pilotos e ingenieros de prueba arranca el avión y vuela con él (todos usan paracaídas ...).

La prueba de integración aborda un problema técnico , a saber, que el sistema funciona a pesar de su subdivisión en componentes. En el software, los componentes pueden ser casos de uso, módulos, funciones, interfaces, bibliotecas, etc ...

La prueba de aceptación verifica que el producto es adecuado para su propósito. Son en principio realizadas por el cliente. Tomando la analogía del avión, incluyen verificar que:

  • los escenarios empresariales previstos conducen al resultado esperado en una situación casi real. Ejemplo: ensayar un embarque con pasajeros de prueba para verificar que el personal pueda monitorear el embarque como se espera con los procedimientos operativos. Algunos escenarios podrían ser tan simples que se verían como una prueba de unidad, pero los realiza el usuario (por ejemplo, pruebe los enchufes eléctricos con el equipo de las compañías).
  • el sistema funciona en una situación empresarial casi real. Ejemplo: realice un vuelo de prueba vacío entre dos destinos reales, con pilotos recién entrenados de la aerolínea para verificar que el consumo de combustible sea el prometido.

La prueba de aceptación aborda más un problema de responsabilidad . En una relación cliente / proveedor puede ser una responsabilidad contractual (cumplimiento de todos los requisitos). Pero en cualquier caso, también es responsabilidad de la organización usuaria asegurarse de que sus tareas se puedan llevar a cabo con el sistema y de prevenir con prudencia cualquier problema imprevisto (por ejemplo, como esta corporación de ferrocarriles que descubrió durante las pruebas de aceptación que tuvieron que acortar algunos quais porque Los nuevos vagones eran 5 cm demasiado grandes, ¡no es broma!).

Conclusiones: las pruebas de integración y aceptación se superponen. Ambos pretenden demostrar que el sistema en su conjunto funciona. Sin embargo, el "todo" podría ser mayor para el cliente (debido a que el sistema puede ser parte de un sistema organizativo más grande) y más técnico para el integrador del sistema:

    
respondido por el Christophe 27.10.2016 - 00:55
1

La prueba de integración no es más que verificar la conexión y la corrección del flujo de datos entre dos o más módulos.

Por ejemplo: cuando redactamos un correo (un módulo) y lo enviamos a algún ID de usuario válido (segundo módulo), la prueba de integración es para verificar si el correo enviado está en los artículos enviados.

    
respondido por el Anita 16.01.2014 - 21:25
0

Una definición práctica de una prueba de integración es: Cualquier prueba que requiera interacción con algo fuera de proceso.

Por ejemplo:

  • El sistema de archivos
  • La red
  • Una base de datos
  • Una API externa

Existe un tipo de contrato entre su proceso y el mundo externo, y la verificación mínima de ese contrato debe ser el objetivo de una prueba de integración. es decir, no debe hacer más que verificar el contrato. Si lo hace, entonces se está moviendo hacia el espacio del sistema / extremo a extremo.

Las pruebas unitarias son capaces de probar toda la lógica dentro del límite de su proceso, y pueden hacerlo fácilmente precisamente debido a la falta de dependencias en el "mundo externo" lento / frágil / complejo.

Si bien hay pruebas de integración, esta definición no cubre (por eso lo llamé una definición práctica ) Creo que son mucho menos comunes / útiles.

N.B. Estrictamente hablando, sí, esta definición abarcaría también las pruebas de sistema / extremo a extremo. En mi filosofía, son una forma de prueba de integración "extrema", por lo que sus nombres enfatizan otro aspecto. En la otra dirección, una prueba unitaria se puede considerar una prueba de integración de cero componentes, es decir, Se puede considerar que todas las pruebas se encuentran en algún lugar del espectro de integración, integrando entre 0-n componentes :-)

    
respondido por el Schneider 17.10.2016 - 01:03

Lea otras preguntas en las etiquetas