what is end end testing
¿Qué son las pruebas de extremo a extremo: marco de pruebas E2E con ejemplos?
Las pruebas de extremo a extremo son una metodología de prueba de software para probar el flujo de una aplicación de principio a fin. El propósito de las pruebas de extremo a extremo es simular el escenario del usuario real y validar el sistema bajo prueba y sus componentes para la integración y la integridad de los datos.
Nadie quiere ser conocido por sus errores y su negligencia, y lo mismo ocurre con los Testers. Cuando a los Testers se les asigna una aplicación para probar, a partir de ese momento, ellos asumen la responsabilidad y la aplicación también actúa como una plataforma para mostrar sus conocimientos prácticos y técnicos de pruebas.
Entonces, para describirlo técnicamente, para garantizar que las pruebas se realicen por completo, es necesario realizar ' Prueba de extremo a extremo ” .
En este tutorial, aprenderemos qué es la prueba de extremo a extremo, cómo se hace, por qué es necesario, cuáles son las matrices utilizadas, cómo crear casos de prueba específicos de extremo a extremo y también algunos otros aspectos importantes. También aprenderemos sobre la prueba del sistema y la compararemos con la prueba de extremo a extremo.
Real también => Capacitación integral sobre un proyecto en vivo: capacitación gratuita en línea sobre control de calidad.
Lo que vas a aprender:
preguntas y respuestas de la entrevista para desarrolladores de Java
- ¿Qué son las pruebas de extremo a extremo?
- Herramientas de prueba de extremo a extremo
- ¿Cómo funciona la prueba de extremo a extremo?
- Métodos de prueba E2E
- ¿Por qué realizamos las pruebas E2E?
- Marco de diseño de pruebas E2E
- Métricas involucradas
- Conclusión
¿Qué son las pruebas de extremo a extremo?
Las pruebas de extremo a extremo son una metodología de prueba de software para probar el flujo de una aplicación de principio a fin. El propósito de esta prueba es simular el escenario del usuario real y validar el sistema bajo prueba y sus componentes para la integración y la integridad de los datos.
Se realiza de principio a fin en escenarios del mundo real, como la comunicación de la aplicación con hardware, red, base de datos y otras aplicaciones.
La razón principal para llevar a cabo esta prueba es determinar varias dependencias de una aplicación, así como garantizar que se comunique información precisa entre varios componentes del sistema. Por lo general, se realiza después de completar las pruebas funcionales y del sistema de cualquier aplicación.
Tomemos un ejemplo de Gmail:
La verificación de extremo a extremo de una cuenta de Gmail incluirá los siguientes pasos:
- Lanzamiento de una página de inicio de sesión de Gmail a través de URL.
- Iniciar sesión en la cuenta de Gmail con credenciales válidas.
- Accediendo a la Bandeja de entrada. Abrir correos electrónicos leídos y no leídos.
- Redactar un nuevo correo electrónico, responder o reenviar un correo electrónico.
- Abrir elementos enviados y consultar correos electrónicos.
- Comprobación de correos electrónicos en la carpeta Spam
- Cerrar sesión en la aplicación Gmail haciendo clic en 'cerrar sesión'
Herramientas de prueba de extremo a extremo
Herramienta recomendada:
# 1) TestCraft
Recomendamos utilizar una herramienta de automatización de pruebas de un extremo a otro como TestCraft.
TestCraft es una plataforma de automatización de pruebas de selenio sin código. Su revolucionaria tecnología de inteligencia artificial y el modelado visual único permiten una creación y ejecución de pruebas más rápidas al tiempo que eliminan la sobrecarga de mantenimiento de las pruebas.
Los probadores crean escenarios de prueba totalmente automatizados sin codificación. Los clientes encuentran errores más rápido, lanzan con más frecuencia, se integran con el enfoque CI / CD y mejoran la calidad general de sus productos digitales. Todo esto está creando una experiencia de prueba completa de principio a fin.
=> Visite el sitio web de TestCraft
¿Cómo funciona la prueba de extremo a extremo?
Para entender un poco más, averigüemos ¿Cómo funciona?
Toma unejemplode la industria bancaria. Pocos de nosotros debimos haberlo probado Cepo. Cuando el titular de una cuenta Demat compra cualquier acción, se le debe entregar al corredor un porcentaje particular de una cantidad. Cuando el accionista vende esa acción, ya sea que obtenga ganancias o pérdidas, un porcentaje particular de la cantidad se le da nuevamente al corredor. Todas estas transacciones se reflejan y gestionan en cuentas. Todo el proceso involucra la Gestión de Riesgos.
Cuando miramos el ejemplo anterior, teniendo en cuenta la prueba de extremo a extremo, veremos que todo el proceso incluye varios números, así como diferentes niveles de transacciones. Todo el proceso involucra muchos sistemas que pueden ser difíciles de probar.
Métodos de prueba E2E
# 1) Prueba horizontal:
Este método se utiliza con mucha frecuencia. Ocurre horizontalmente en el contexto de múltiples aplicaciones. Este método puede ocurrir fácilmente en una sola aplicación ERP (Enterprise Resource Planning). Tomemos un ejemplo de una aplicación basada en la web de un sistema de pedidos en línea. Todo el proceso incluirá cuentas, estado de inventario de los productos y detalles de envío.
# 2) Prueba vertical:
En este método, todas las transacciones de cualquier aplicación se verifican y evalúan desde el principio hasta el final. Cada capa individual de la aplicación se prueba de arriba a abajo. Tome un ejemplo de una aplicación basada en web que utiliza códigos HTML para llegar a los servidores web. En tales casos, se requiere API para generar códigos SQL contra la base de datos. Todos estos escenarios informáticos complejos requerirán una validación adecuada y pruebas dedicadas. Por tanto, este método es mucho más difícil.
‘ Prueba de caja blanca ’ así como también ‘ Prueba de caja negra ’ ambos están asociados con esta prueba. O, en otras palabras, podemos decir que esta es la combinación de beneficios tanto de las pruebas de caja blanca como de las pruebas de caja negra. Dependiendo del tipo de software que se esté desarrollando, en diferentes niveles, tanto las técnicas de prueba, es decir, las pruebas de caja blanca como las de caja negra, se utilizan cuando sea necesario. Básicamente, la prueba de extremo a extremo funciona tan bien como el enfoque arquitectónico de cualquier software o programa para validar las funciones del sistema.
Los probadores como la verificación de extremo a extremo porque la escritura de casos de prueba del usuario ’ s perspectiva y en un escenario del mundo real, puede evitar los dos errores comunes. ‘ falta un error ’ y ‘ escribir casos de prueba que no verifican escenarios del mundo real ’ . Esto proporciona a los probadores una inmensa sensación de logro.
A continuación se enumeran algunas pautas que deben tenerse en cuenta al diseñar los casos de prueba para realizar este tipo de pruebas:
- Los casos de prueba deben diseñarse desde la perspectiva del usuario final.
- Debería centrarse en probar algunas características existentes del sistema.
- Se deben considerar múltiples escenarios para crear múltiples casos de prueba.
- Deben crearse diferentes conjuntos de casos de prueba para centrarse en múltiples escenarios del sistema.
A medida que ejecutamos cualquier caso de prueba, es similar el caso con esta prueba. Si los casos de prueba son 'Pasados', es decir, obtenemos el resultado esperado, se dice que el sistema ha superado con éxito la prueba de extremo a extremo. Del mismo modo, si el sistema no produce el resultado deseado, entonces se requiere una nueva prueba de un caso de prueba teniendo en cuenta las áreas de falla.
¿Por qué realizamos las pruebas E2E?
En el escenario actual, como también se muestra en el diagrama anterior, un sistema de software moderno comprende su interconexión con múltiples subsistemas. Esto ha hecho que los sistemas de software modernos sean muy complicados.
Estos subsistemas de los que estamos hablando pueden estar dentro de la misma organización o en muchos casos también pueden ser de diferentes organizaciones. Además, estos subsistemas pueden ser algo similares o diferentes al sistema actual. Como resultado, si hay alguna falla o falla en cualquier subsistema, puede afectar negativamente a todo el sistema de software y provocar su colapso.
Estos importantes riesgos pueden evitarse y controlarse mediante este tipo de pruebas:
- Mantenga un control y realice la verificación del flujo del sistema.
- Aumente las áreas de cobertura de prueba de todos los subsistemas involucrados con el sistema de software.
- Detecta problemas, si los hay, con los subsistemas y, por lo tanto, aumenta la productividad de todo el sistema de software.
A continuación se mencionan los Algunas actividades que se incluyen en el proceso de un extremo a otro:
- Un estudio exhaustivo de los requisitos para realizar esta prueba.
- Adecuado configuración de entornos de prueba.
- Un estudio exhaustivo de los requisitos de hardware y software.
- Descripciones de todos los subsistemas, así como del principal sistema de software involucrado.
- Enumere los roles y responsabilidades de todos los sistemas y subsistemas involucrados.
- Los métodos de prueba utilizados en esta prueba, así como los estándares que se siguen, su descripción.
- Diseño de casos de prueba y seguimiento de la matriz de requisitos.
- Registre o guarde los datos de entrada y salida de cada sistema.
Marco de diseño de pruebas E2E
Examinaremos las 3 categorías una por una:
# 1) Funciones de usuario: Las siguientes acciones deben realizarse como parte de la creación de funciones de usuario:
- Enumerar las características de los sistemas de software y sus subsistemas interconectados.
- Para cualquier función, realice un seguimiento de las acciones realizadas, así como de los datos de entrada y salida.
- Encuentre las relaciones, si las hay, entre diferentes funciones de Usuarios.
- Descubra la naturaleza de las diferentes funciones de usuario, es decir. si son independientes o son reutilizables.
# 2) Condiciones: Las siguientes actividades deben realizarse como parte de las condiciones del edificio según las funciones del usuario:
- Para todas y cada una de las funciones de usuario, se debe preparar un conjunto de condiciones.
- El tiempo, las condiciones de los datos y otros factores que afectan las funciones del usuario pueden considerarse parámetros.
# 3) Casos de prueba: Se deben considerar los siguientes factores para crear casos de prueba:
- Para cada escenario, se deben crear uno o más casos de prueba para probar todas y cada una de las funciones de las funciones del usuario.
- Cada condición debería incluirse como un caso de prueba independiente.
Métricas involucradas
Pasar a las siguientes actividades o métricas importantes involucradas en esta prueba :
- Estado de la preparación del caso de prueba: Esto se puede rastrear en forma de gráfico para representar el progreso de los casos de prueba planificados que están en preparación.
- Seguimiento semanal del progreso de la prueba: Esto incluye la representación semanal del progreso de ejecución de los casos de prueba. Puede reflejarse a través de la representación porcentual para casos de aprobación, falla, ejecución, no ejecución, inválida, etc.
- Estado e informe detallado de defectos: El informe de estado debe prepararse a diario para mostrar el estado de ejecución del caso de prueba, así como los defectos encontrados y registrados según su gravedad. Semanalmente, se debe calcular el porcentaje de defectos abiertos y cerrados. Además, en función de la gravedad y la prioridad de los defectos, se debe realizar un seguimiento del estado de los defectos semanalmente.
- Entorno de prueba: Esto mantiene un registro de la duración asignada del entorno de prueba, así como el tiempo del entorno de prueba realmente utilizado al realizar esta prueba.
Casi hemos visto todos los aspectos de esta prueba. Ahora déjanos diferenciar “ Prueba del sistema ” y “ Prueba de extremo a extremo ” . Pero antes de eso, permítame darle una idea básica de 'Prueba del sistema' para que podamos diferenciar fácilmente entre las dos formas de pruebas de software .
Prueba del sistema es la modalidad de prueba que incluye una serie de diferentes pruebas cuya finalidad es realizar la prueba completa del sistema integrado. La prueba del sistema es básicamente una forma de prueba de caja negra donde el enfoque está en el funcionamiento externo de los sistemas de software desde el punto de vista del usuario, teniendo en cuenta las condiciones del mundo real.
La prueba del sistema implica:
- Probando una aplicación totalmente integrada que incluye el sistema principal.
- Determine que los componentes interactúan entre sí y dentro del sistema.
- Verifique la salida deseada sobre la base de la entrada proporcionada.
- Analizar la experiencia del usuario mientras usa varios aspectos de la aplicación.
Arriba hemos visto la descripción básica de las pruebas del sistema para entenderlo. Ahora, veremos las diferencias entre 'Prueba del sistema' y 'Prueba de extremo a extremo'.
S.No. | Pruebas de extremo a extremo | Prueba del sistema |
---|---|---|
1 | Valida tanto el sistema de software principal como todos los subsistemas interconectados. | Según las especificaciones proporcionadas en el documento de Requisitos, simplemente valida el sistema de software. |
2 | El énfasis principal está en verificar el flujo del proceso de prueba de un extremo a otro. | El énfasis principal está en verificar y verificar las características y funcionalidades del sistema de software. |
3 | Al realizar las pruebas, se toman en consideración todas las interfaces, incluidos los procesos de backend del sistema de software. | Al realizar las pruebas, solo las áreas funcionales y no funcionales y sus características se consideran para las pruebas. |
4 | Las pruebas de extremo a extremo se ejecutan / realizan después de completar las pruebas del sistema de cualquier sistema de software. | La prueba del sistema se realiza básicamente después de completar la prueba de integración del sistema de software. |
5 | La prueba manual se prefiere principalmente para realizar pruebas de extremo a extremo, ya que esta forma de prueba también implica la prueba de interfaces externas, que a veces pueden ser muy difíciles de automatizar. Y hará que todo el proceso sea muy complejo. | Las pruebas manuales y de automatización se pueden realizar como parte de las pruebas del sistema. |
Conclusión
Espero que haya aprendido varios aspectos de las pruebas de extremo a extremo, como sus procesos, métricas y la diferencia entre las pruebas de sistema y las pruebas de extremo a extremo.
Para cualquier versión comercial del software, la verificación de extremo a extremo juega un papel importante, ya que prueba toda la aplicación en un entorno que imita exactamente a los usuarios del mundo real, como la comunicación en red, la interacción con bases de datos, etc.
En su mayoría, la prueba de extremo a extremo se realiza manualmente ya que el costo de automatizar tales casos de prueba es demasiado alto para que lo pueda pagar cualquier organización. Esto no solo es beneficioso para la validación del sistema, sino que también puede considerarse útil para probar la integración externa.
Háganos saber si tiene preguntas sobre la prueba de un extremo a otro.
Lectura recomendada
- Mejores herramientas de prueba de software 2021 (Herramientas de automatización de pruebas de control de calidad)
- Diferencias clave entre las pruebas de caja negra y las pruebas de caja blanca
- Descarga del libro electrónico Testing Primer
- Pruebas funcionales versus pruebas no funcionales
- Programa del curso de pruebas de software: plan de formación detallado del curso en línea
- ¿Qué son las pruebas de resistencia en las pruebas de software (ejemplos)?
- Prueba de caja negra: un tutorial detallado con ejemplos y técnicas
- ¿Qué son las pruebas de componentes o las pruebas de módulos (aprender con ejemplos)?