¿Cuál es la diferencia entre las pruebas de integración y las pruebas funcionales? [cerrado]

¿Las pruebas funcionales y las pruebas de integración son iguales?

Comienza su prueba a través de pruebas unitarias, luego, después de completar las pruebas unitarias, realiza pruebas de integración donde prueba el sistema en su conjunto. ¿Las pruebas funcionales son lo mismo que las pruebas de integración? Todavía está tomando el sistema como un todo y probándolo para la conformidad de la funcionalidad.

La prueba de integración es cuando prueba más de un componente y cómo funcionan juntos. Por ejemplo, cómo otro sistema interactúa con su sistema o la base de datos interactúa con su capa de abstracción de datos. Por lo general, esto requiere un sistema completamente instalado, aunque en su forma más pura no.

La prueba funcional es cuando prueba el sistema contra los requisitos funcionales del producto. La gestión de productos / proyectos generalmente los redacta y el control de calidad formaliza el proceso de lo que un usuario debería ver y experimentar, y cuál debería ser el resultado final de esos procesos. Dependiendo del producto, esto puede ser automatizado o no.

Prueba funcional :

Sí, estamos probando el producto o el software en su conjunto funcionalmente si funciona correctamente o no (botones de prueba, enlaces, etc.)

Por ejemplo: página de inicio de sesión.

usted proporciona el nombre de usuario y la contraseña, prueba si lo lleva a la página de inicio o no.

Pruebas de integración :

Sí, solo prueba el software integrado, pero prueba dónde está ocurriendo el flujo de datos y si hay algún cambio en la base de datos.

Por ejemplo: envío de correo electrónico

Envía un correo a alguien, hay un flujo de datos y también cambia en la base de datos (la tabla enviada aumenta el valor en 1)

Recuerde: hacer clic en enlaces e imágenes no es una prueba de integración. Espero que haya entendido por qué, porque no hay cambios en la base de datos simplemente haciendo clic en un enlace.

Espero que esto te haya ayudado.

Esta es una distinción importante, pero desafortunadamente nunca encontrará un acuerdo. El problema es que la mayoría de los desarrolladores los definen desde su propio punto de vista. Es muy similar al debate sobre Plutón. (Si estuviera más cerca del Sol, ¿sería un planeta?)

Las pruebas unitarias son fáciles de definir. Prueba el CUT ( Código bajo prueba ) y nada más. (Bueno, tan poco como sea posible). Eso significa simulacros, falsificaciones y accesorios.

En el otro extremo del espectro hay lo que muchas personas llaman pruebas de integración de sistemas . Eso está probando tanto como sea posible, pero sigue buscando errores en su propio CUT.

Pero ¿qué pasa con la vasta extensión entre?

• Por ejemplo, ¿qué pasa si prueba solo un poco más que el CUT? ¿Qué pasa si incluye una función de Fibonacci, en lugar de usar un dispositivo que se había inyectado? Llamaría a eso prueba funcional , pero el mundo no está de acuerdo conmigo.
• ¿Qué pasa si incluye time()o rand()? ¿O qué pasa si llamas http://google.com? Llamaría a ese sistema de prueba , pero nuevamente, estoy solo.

¿Por qué importa esto? Porque las pruebas del sistema no son confiables. Son necesarios, pero a veces fallarán por razones más allá de su control. Por otro lado, las pruebas funcionales siempre deben pasar, no fallar al azar; si son rápidos, también podrían usarse desde el principio para usar el desarrollo guiado por pruebas sin escribir demasiadas pruebas para su implementación interna. En otras palabras, creo que las pruebas unitarias pueden ser más problemáticas de lo que valen, y tengo buena compañía .

Puse pruebas en 3 ejes, con todos sus ceros en las pruebas unitarias :

1. Pruebas funcionales: usando código real cada vez más profundo en tu pila de llamadas.
2. Pruebas de integración: cada vez más alto en su pila de llamadas; en otras palabras, probar su CUT ejecutando el código que lo usaría.
3. Pruebas del sistema: más y más operaciones irrepetibles (planificador O / S, reloj, red, etc. )

Una prueba puede ser fácilmente los 3, en diversos grados.

Pruebas funcionales: es un proceso de prueba en el que se prueban todos y cada uno de los componentes del módulo. Por ejemplo: si una página web contiene campos de texto, botones de radio, botones y componentes desplegables, etc., es necesario verificarlos.

Pruebas de integración: proceso donde se verifica el flujo de datos entre 2 módulos.

Diría que ambos están estrechamente vinculados entre sí y son muy difíciles de distinguir entre ellos. En mi opinión, las pruebas de integración son un subconjunto de pruebas funcionales.

La prueba de funcionalidad se basa en los requisitos iniciales que recibe. Probará que el comportamiento de la aplicación es el esperado con los requisitos.

Cuando se trata de pruebas de integración, es la interacción entre módulos. Si el módulo A envía una entrada, el módulo B puede procesarla o no.

Pruebas de integración: las pruebas de integración no son más que la prueba de diferentes módulos. Tienes que probar la relación entre módulos. Por ejemplo, si abre Facebook, verá la página de inicio de sesión después de ingresar el nombre de usuario y la contraseña, puede ver la página de inicio de Facebook, por lo tanto, la página de inicio de sesión es un módulo y la página de inicio es otro módulo. debe verificar solo la relación entre ellos significa que cuando inició sesión, solo la página de inicio debe estar abierta, no el cuadro de mensaje ni nada más. Existen 2 tipos principales de pruebas de integración: enfoque de arriba hacia abajo y enfoque de abajo hacia arriba.

Pruebas funcionales: en las pruebas funcionales solo debe pensar en la entrada y la salida. En este caso, debes pensar como un usuario real. Prueba de qué entrada dio y qué salida obtuvo es Prueba funcional. solo tienes que observar la salida. En las pruebas funcionales no necesita probar la codificación de la aplicación o el software.

En un probador de pruebas funcionales, solo se enfoca la funcionalidad y la subfuncionalidad de la aplicación. La funcionalidad de la aplicación debería funcionar correctamente o no.

En las pruebas de integración, el probador debe verificar la dependencia entre los módulos o submódulos. El ejemplo de los registros de los módulos se debe buscar y mostrar correctamente en otro módulo.

Prueba de integración: - Cuando se realizan las pruebas unitarias y los problemas se resuelven en los componentes relacionados, todos los componentes necesarios deben integrarse en un sistema para que pueda realizar una operación. Después de combinar los componentes del sistema, para comprobar si el sistema funciona correctamente o no, este tipo de prueba se denomina Prueba de integración.

Pruebas funcionales: - Las pruebas se dividen principalmente en dos categorías como 1. Pruebas funcionales 2. Pruebas no funcionales ** Pruebas funcionales: - Para comprobar si el software funciona de acuerdo con los requisitos del usuario o no. ** Pruebas no funcionales: - Para comprobar si el software cumple con los criterios de calidad como Prueba de estrés, Prueba de seguridad, etc.

Por lo general, el Cliente proporcionará los requisitos solo para la Prueba funcional y para la Prueba no funcional. No se deben mencionar los Requisitos, pero la aplicación necesariamente realiza esa actividad.

Pruebas de integración

La verificación de la funcionalidad de la aplicación se conoce generalmente como prueba funcional, donde la prueba de integración consiste en verificar el flujo de datos de un módulo a otro. Tomemos un ejemplo de la aplicación de transferencia de dinero. Supongamos que tenemos una página en la que ingresamos todas las credenciales y si presionamos el botón de transferencia y luego si tenemos éxito, entonces esta es una prueba funcional. Pero en el mismo ejemplo, si verificamos la transferencia de la cantidad, se trata de pruebas de integración.

Los autores divergen mucho en esto. No creo que haya "la" interpretación correcta para esto. Realmente depende

Por ejemplo: la mayoría de los desarrolladores de Rails consideran las pruebas unitarias como pruebas de modelo, pruebas funcionales como pruebas de controlador y pruebas de integración como aquellas que usan algo como Capybara para explorar la aplicación desde la perspectiva del usuario final, es decir, navegar a través del HTML generado de la página, usando el DOM para verificar las expectativas.

También hay pruebas de aceptación, que a su vez son una documentación "en vivo" del sistema (generalmente usan Gherkin para que sea posible escribirlas en lenguaje natural), que describen todas las características de la aplicación a través de múltiples escenarios, que a su vez están automatizados por un desarrollador. Esos, en mi humilde opinión, también podrían considerarse tanto pruebas funcionales como pruebas de integración.

Una vez que comprenda el concepto clave detrás de cada uno de ellos, podrá ser más flexible con respecto a lo correcto o incorrecto. Entonces, nuevamente en mi humilde opinión, una prueba funcional también podría considerarse una prueba de integración. Para la prueba de integración, dependiendo del tipo de integración que esté ejerciendo, puede no considerarse una prueba funcional, pero generalmente tiene algunos requisitos en mente cuando escribe una prueba de integración, por lo que la mayoría de las veces también puede considerarse como Una prueba funcional.