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

110

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

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

Revisé la documentación de Ruby on Rails para su clasificación de estos tipos de prueba, y ahora me ha arrojado por completo.

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

Martin Blore
fuente
76
Por cierto, cuando tienes una frase nominal ("Yo y algunos amigos") debes tener cuidado con el singular en primera persona que utilizas. Aquí está la prueba. Deja a los amigos y mira si aún funciona. "He estado luchando" vs "He estado luchando". Esta prueba te dice que somos "Yo y mis amigos ..." Y, para ser cortés, enumeramos a los demás primero. "Mis amigos y yo". La prueba es importante.
S.Lott
58
Creo que S.Lott acaba de darte una prueba de integración de gramática-> sociedad.
Jordan

Respuestas:

78

Por el momento me gusta esta declaración: "No es importante cómo lo llames, sino lo que hace" hecho por Gojko Adzic en este artículo .

Realmente necesita especificar con las personas que hablan sobre las pruebas lo que pretende probar.

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

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 (todo tipo / nivel)
  • prueba de aceptación funcional
  • prueba de aceptación del usuario
  • prueba de aceptación de producción

Tienen un tipo más específico de pruebas que se pueden realizar dentro de las pruebas mencionadas anteriormente. Mire esta palabra doc para una descripción general.

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

El libro que el programador pragmático dice:

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

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

  • quien hace las pruebas en general
  • lo que se prueba
  • cual es el objetivo de la prueba

    • Prueba unitaria : prueba la lógica en clases por 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 pretendas probar
    • Prueba de aceptación funcional : pruebe los escenarios de casos de uso en un conjunto de datos limitado (especialmente creado) realizado por el departamento de pruebas para mostrar que cada escenario especificado funciona como se especifica.
    • Prueba de aceptación del usuario : pruebe escenarios de casos de uso en producción como datos hechos por representantes de los usuarios para que acepten formalmente la aplicación
    • Prueba de integración : pruebe las rutas de comunicación entre las diferentes partes del módulo realizadas por el departamento de prueba o por los desarrolladores para mostrar que todos los módulos funcionan correctamente juntos.

Mi lista anterior es solo un comienzo y una sugerencia, pero realmente pienso: "No es importante cómo lo llames, sino lo que hace"

Espero que esto ayude.

26-10-2016 Editar: Recientemente, se introdujo una muy buena introducción en las pruebas de unidad de YouTube frente a las pruebas de integración - Reflexiones de MPJ - FunFunFunction # 55

KeesDijk
fuente
3
+1 Para "no importa cómo lo llames". Lamentablemente, no existe una definición universal de ningún tipo de prueba. Incluso el buen ol unit-test es un poco variable. ¿La prueba de DOM para una aplicación web se considera una prueba unitaria? Algunos dicen que sí, otros dicen que no.
Laurent Bourgault-Roy
2
El enlace a la palabra doc no está disponible.
Paul Rougieux
66
"No es importante cómo lo llames" se aplica a toda la informática y, de hecho, a casi todas las áreas. Creo que muchos de los acalorados argumentos en los que se mete la gente pueden resumirse en "estamos discutiendo sobre la definición de una frase arbitraria".
cabeza de jardín
Estoy de acuerdo con las definiciones: he estado en un lugar en el que "Prueba de unidad" indica que el programador probó el sistema con al menos una entrada de muestra ... manualmente ... y verificó visualmente la salida si "parecía correcto" . No hay contrato en cuanto a lo que se esperaba, no hay entradas controladas, etc.
Newtopian
El enlace a Gojko está devolviendo un 404. Puede acceder a un archivo aquí: web.archive.org/web/20150104002755/http://gojko.net/2011/01/12/…
Eduardo Copat
32

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 la 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 codificadores.

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

S.Lott
fuente
77
Lo único que agregaría a esto es que las pruebas de integración también pueden probar solo una parte del sistema, pero más de una pieza a la vez. Cada vez que busca errores causados ​​por dos o más partes del sistema que funcionan al unísono (integrados juntos), está realizando pruebas de integración. La integración se ejecuta desde dos componentes reales y todo lo demás burlado, hasta el conjunto completo de aplicaciones que trabajan juntas, e incluso puede ir tan lejos como verificar la integración con otras aplicaciones (por ejemplo, "¿Cómo funciona MS Office con Internet Explorer?").
Ethel Evans
1
@Ethel Evans: Buen punto. La prueba seguirá siendo borrosa entre integración y aceptación, incluso si solo una parte del sistema está involucrada. La prueba se realiza a un nivel suficientemente alto para que la aceptación y la integración se sientan similares.
S.Lott
3
Las pruebas de integración ciertamente no prueban (y probablemente no deberían) "el sistema en su conjunto". En cualquier lugar en el que dos o más componentes se prueben juntos, en particular cuando se prueba con componentes externos (base de datos, red, etc.), está haciendo pruebas de integración. Debido a los altos costos de las pruebas de "todo el sistema", desea evitar esto tanto como sea posible, en su lugar, busque realizar más pruebas de integración de sistemas parciales (consulte Pirámide de prueba
Schneider,
1
@Schneider lo dice bien, las pruebas de integración no deberían probar "el sistema en su conjunto". Dichas pruebas se considerarían "pruebas de extremo a extremo" o "pruebas del sistema", según el alcance que considere en su proyecto. Las pruebas de extremo a extremo pueden cubrir un flujo de datos "en su conjunto" que se ejecuta a través de múltiples sistemas, y las pruebas del sistema solo "un sistema en su conjunto".
RoyB
Así es como los defino para evitar la confusión sobre el uso generalizado de la prueba de "Integración". Pruebas unitarias -> prueba la unidad de trabajo más pequeña, un método en una clase, que no llama a ningún otro código fuera de ese método (burlándose de las dependencias si es necesario) Pruebas de integración -> pruebas de mayor alcance de las pruebas unitarias donde pueden y debería probar las capas de una aplicación trabajando juntas, pero NO toda la aplicación implementada en algún lugar.) Pruebas funcionales / prueba de aceptación -> pruebas que prueban una versión implementada de la aplicación
Kevin M
16

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

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


fuente
44
Estoy de acuerdo, excepto que no necesita ser un sistema "completamente ensamblado". Puede (y debe) hacer pruebas de integración con subconjuntos del sistema completo, ya que esto suele ser más barato / fácil.
Schneider
La integración entre 2 unidades / componentes también se puede "probar para la integración" mientras que el resto todavía se burla. Por lo tanto, muchos marcos de prueba de integración permiten burlarse :)
RoyB
1
Tengo pruebas en una aplicación Spring Boot que prueba el front-end (contrato de API) dentro de un contenedor Spring pero se burla del repositorio / capa de datos. Por lo tanto, utiliza repositorios / datos simulados, pero fusiona la capa del controlador y realiza la clasificación de Jackson, etc. Prueba de integración.
Kevin M
8

En mi poca experiencia (lo admito), entendí que la palabra integración realmente puede crear malentendidos: realmente, 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:

  • Utilizo pruebas unitarias para identificar, documentar y enfatizar todos los comportamientos que la clase que estoy probando es responsable de realizar.
  • Estoy haciendo pruebas de integración cada vez que tengo un componente (tal vez más de uno) en mi sistema que está teniendo una conversación con otro sistema " externo ". (continúa abajo ...)
  • Implemento una prueba de aceptación para definir, documentar y enfatizar un cierto flujo de trabajo que el sistema espera.

En la definición de la prueba de integración, por externo me refería a un sistema que está fuera de mi rango de desarrollo : no puedo cambiar inmediatamente su forma de comportamiento, por ningún motivo. Podría ser una biblioteca, un componente del sistema que no se puede cambiar (es decir, se comparte con otros proyectos de 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 cierto estado; los datos realistas deben registrarse en la base de datos; etc.

En cambio, cuando estoy haciendo pruebas de aceptación, finjo cosas: estoy trabajando en algo diferente, estoy trabajando en las especificaciones del sistema, no en su capacidad de colaborar con entidades externas.

Esta es realmente una visión más limitada 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.

Marco Ciambrone
fuente
6

Una prueba de integración verifica que los componentes de un sistema complejo (p. Ej., Software, aeronave, planta de energía) están trabajando juntos como se diseñó.

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

  • Correcta interacción entre algunos componentes. Ejemplo: al presionar el botón de arranque, el motor arranca y la hélice alcanza la velocidad de rotación esperada (la aeronave aún permanece en tierra)
  • correcta interacción con componentes externos. Ejemplo: compruebe que la radio integrada puede comunicarse con una radio estacionaria (el avión aún está en tierra)
  • interacción correcta entre todos los componentes involucrados, para que el sistema en su conjunto funcione como se espera. Ejemplo: una tripulación de pilotos e ingenieros de prueba inicia 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 software los componentes pueden ser casos de uso, módulos, funciones, interfaces, bibliotecas, etc.

La prueba de aceptación verifica que el producto es apto para su propósito. En principio son realizados 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 abordaje con pasajeros de prueba para verificar que el personal pueda monitorear el abordaje como se esperaba con los procedimientos operativos. Algunos escenarios podrían ser tan simples que se verían como pruebas unitarias, pero los realiza el usuario (por ejemplo, pruebe los enchufes eléctricos con el equipo de las empresas).
  • El sistema funciona en una situación comercial casi real. Ejemplo: haga 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 garantizar que sus tareas puedan llevarse a cabo con el sistema y prevenir con prudencia cualquier problema imprevisto (por ejemplo, como esta corporación ferroviaria que descubrió durante las pruebas de aceptación que tenían 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 tienen la intención de mostrar que el sistema en su conjunto funciona. Sin embargo, el "todo" podría ser más grande para el cliente (porque el sistema puede ser parte de un sistema organizacional más grande), y más técnico para el integrador del sistema:

ingrese la descripción de la imagen aquí

Christophe
fuente
1

Las pruebas de integración no son 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 una identificación de usuario válida (segundo módulo), la prueba de integración consiste en verificar si el correo enviado está en los elementos enviados.

Anita
fuente
3
Bienvenido a programadores. ¿Qué agrega su respuesta que aún no ha sido proporcionada por las respuestas existentes? Programmers.SE no es como los foros tradicionales. Se centra en preguntas y respuestas de alta calidad en lugar de mucha charla. Eche un vistazo a la página del recorrido para obtener más información sobre cómo funciona el sitio.
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 sistema / espacio de extremo a extremo.

Las pruebas unitarias pueden probar toda la lógica dentro de los límites 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 que esta definición no cubre (de ahí por qué la llamé una definición práctica ), creo que son mucho menos comunes / útiles.

Nota: en sentido estricto, sí, esta definición también abarcaría las pruebas de sistema / de extremo a extremo. En mi filosofía, son una forma de prueba de integración "extrema", de ahí que sus nombres enfaticen otro aspecto. En la otra dirección, una prueba unitaria puede considerarse una prueba de integración de cero componentes, es decir, todas las pruebas pueden considerarse en algún lugar del espectro de integración, integrando entre 0-n componentes :-)

Schneider
fuente
Cuando tiene dos unidades, prueba cada una con una prueba de unidad. Cuando esas dos unidades se integran entre sí, prueba la integración con una prueba de integración. No tienen que estar "fuera de proceso", y este tipo de pruebas son extremadamente comunes.
Bryan Oakley
Tiene toda la razón: las cosas no tienen que estar fuera de proceso para ser una prueba de integración. Es por eso que traté de dejar en claro que mi respuesta era más una "regla general" (pero tal vez falló). Sin embargo, no estoy de acuerdo con que las pruebas de integración entre unidades sean "extremadamente comunes". Las pruebas de integración fuera de proceso son mucho más comunes en mi experiencia y con frecuencia son muy valiosas, de ahí que mi respuesta enfatice ese aspecto de las pruebas de integración.
Schneider