¿Qué son las pruebas SOA? Tutorial con ejemplo

¿Qué son las pruebas SOA?

SOA (Orientado a Servicios ArchiLa prueba de tecnología es una prueba del estilo arquitectónico SOA en el que los componentes de la aplicación están diseñados para comunicarse a través de protocolos de comunicación, generalmente a través de una red.

¿Qué es SOA?

SOA es un método para integrar aplicaciones y procesos comerciales para satisfacer las necesidades comerciales.

En Ingeniería de Software, SOA aporta agilidad y flexibilidad a los procesos de negocio. Los cambios en el proceso o aplicación se pueden dirigir a un componente en particular sin afectar a todo el sistema.

Los desarrolladores de software en SOA desarrollan o compran fragmentos de programas llamados SERVICIOS.

¿Qué es el servicio?

• Los servicios pueden ser una unidad funcional de aplicación o proceso comercial, que puede ser reutilizado o repetido por cualquier otra aplicación o proceso (por ejemplo, en la imagen de arriba, Payment Gateway es un servicio que puede ser reutilizado por cualquier sitio de comercio electrónico. Cada vez que es necesario realizar un pago, el sitio de comercio electrónico llama/solicita el servicio de pasarela de pago. Una vez realizado el pago en una pasarela, se envía una respuesta al sitio web de comercio electrónico).
• Los servicios son componentes fáciles de ensamblar y fáciles de reconfigurar.
• Los servicios se pueden comparar con bloques de construcción. Pueden construir cualquier aplicación necesaria. Agregarlos y eliminarlos de la aplicación o del proceso comercial es fácil.
• Los servicios se definen más por la función empresarial que realizan que como fragmentos de código.

Servicios Web

Los servicios web son componentes de aplicaciones independientes, que están disponibles en la web.

Se pueden publicar, encontrar y utilizar en la web. Pueden comunicarse a través de Internet.

1. El Proveedor de Servicios publica el servicio en Internet.
2. El Cliente busca un servicio web concreto en el Registro de Servicios Web
3. Se devuelve una URL y el WSDL para el servicio web requerido. Utilizando el WSDL y la URL, la comunicación entre el proveedor de servicios y el solicitante se produce a través de mensajes SOAP.
4. Cuando un consumidor llama a un servicio web, se establecerá una conexión HTTP con el proveedor.
   Se crea un mensaje SOAP para indicarle al proveedor que invoque la lógica del servicio web requerida.
5. La respuesta recibida del proveedor es un mensaje SOAP que se incrustará en la respuesta HTTP. Esta respuesta HTTP es el formato de datos comprensible para la aplicación del consumidor.

Ejemplo

La página de inicio de un sitio web y un motor de búsqueda muestra el informe meteorológico diario. En lugar de codificar toda la sección del informe meteorológico, se puede comprar un servicio de informe meteorológico a un proveedor e integrarlo en las páginas.

Pruebas SOA

SOA consta de varias tecnologías. Las aplicaciones creadas con SOA tienen varios servicios que están débilmente acoplados.

Las pruebas SOA deben centrarse en 3 capas del sistema

Capa de servicios

Esta capa está formada por los servicios, servicios expuestos por un sistema derivados de funciones empresariales.

Por ejemplo -

Considere un sitio web de bienestar que consista en

1. Rastreador de peso
2. Rastreador de azúcar en la sangre
3. Rastreador de presión arterial

Los rastreadores muestran los datos respectivos y la fecha en que se ingresan. La capa de servicios consta de los servicios que obtienen los datos respectivos de la base de datos.

• Servicio de seguimiento de peso
• Servicio de seguimiento de azúcar en sangre
• Servicio de seguimiento de la presión arterial
• Servicio de inicio de sesión

Capa de proceso

La capa de proceso consiste en procesos, colección de servicios que forman parte de una única funcionalidad.

Los procesos pueden ser parte de la interfaz de usuario (por ejemplo, un motor de búsqueda), parte de una herramienta ETL (para obtener datos de la base de datos).

El enfoque principal en esta capa estará en las interfaces de usuario y los procesos.

La interfaz de usuario del rastreador de peso y su integración con la base de datos es el enfoque principal.

Las siguientes funciones serán de consideración

1. Agregar nuevos datos
2. Editar datos existentes
3. Creando un nuevo rastreador
4. Borrando datos

Capa de consumidor

Esta capa se compone principalmente de interfaces de usuario.

Según la capa, las pruebas de una aplicación SOA se distribuyen en tres niveles.

1. Nivel de servicio
2. Nivel de interfaz
3. Nivel de extremo a extremo

• El enfoque de arriba hacia abajo se utiliza para el diseño de pruebas.
• El enfoque Bottom Up se utiliza para la ejecución de pruebas.

Estrategia para pruebas SOA

Enfoque de planificación de pruebas,

• Los evaluadores SOA deben comprender la arquitectura completa de la aplicación.
• La aplicación debe dividirse en servicios independientes (servicio que tiene su propia estructura de solicitud y respuesta y no depende de ningún otro servicio para generar una respuesta).
• La estructura de la aplicación debe reorganizarse en tres componentes: datos, servicios y aplicaciones de front-end.
• Es necesario analizar cuidadosamente todos los componentes y trazar los escenarios comerciales.
• Los escenarios empresariales deben clasificarse en escenarios comunes y escenarios de aplicaciones específicas.
• A Matriz de Trazabilidad Se debe preparar y todos los casos de prueba deben rastrearse hasta escenarios comerciales.

Enfoque de ejecución de pruebas

• Cada componente del servicio debe ser probado.
• Pruebas de integración Se debe realizar una revisión de los componentes del servicio para validar el flujo de datos a través de los servicios y la integridad de los datos.
• Pruebas del sistema Se debe realizar una revisión del modelo completo para validar el flujo de datos entre la aplicación front-end y la base de datos.
• Test de rendimiento debe hacerse para lograr un ajuste fino y un rendimiento óptimo.

Métodos de prueba SOA

1) Pruebas basadas en datos impulsadas por escenarios comerciales,

• Se deben analizar varios aspectos comerciales relacionados con el sistema.
• Se deben desarrollar escenarios basados ​​en la integración de
• Varios Los servicios Web de la aplicación
• Servicios web y aplicación.
• La configuración de datos debe realizarse en función de los escenarios anteriores.
• La configuración de los datos debe realizarse de manera que cubra también los escenarios de un extremo a otro.

2) Talones

• Se crearán interfaces ficticias para probar los servicios.
• Se pueden proporcionar varias entradas a través de estas interfaces y las salidas se pueden validar.
• Cuando una aplicación utiliza una interfaz para un servicio externo, que no está bajo prueba (servicio de terceros), se puede crear un código auxiliar durante las pruebas de integración.

3) Pruebas de regresión

• Pruebas de regresión en la aplicación debe realizarse cuando hay varias versiones para garantizar la estabilidad y disponibilidad de los sistemas.
• Se creará un conjunto completo de pruebas de regresión que cubra los servicios que forman una parte importante de la aplicación.
• Este conjunto de pruebas se puede reutilizar en varias versiones del proyecto.

4) Pruebas de nivel de servicio

Las pruebas de nivel de servicio incluyen probar el componente en términos de funcionalidad, seguridad, rendimiento e interoperabilidad.

Todos y cada uno de los servicios deben probarse primero de forma independiente.

5) Pruebas funcionales

Se deben realizar pruebas funcionales en cada servicio para

• Asegúrese de que el servicio brinde la respuesta correcta a cada solicitud.
• Se reciben errores correctos para solicitudes con datos no válidos, datos incorrectos, etc.
• Verifique cada solicitud y respuesta para todas y cada una de las operaciones que el servicio debe realizar en tiempo de ejecución.
• Validar los mensajes de error cuando se produzca un error a nivel de servidor, cliente o red.
• Validar que las respuestas recibidas estén en el formato correcto.
• Validar que los datos recibidos en la respuesta correspondan a los datos solicitados.

6) Pruebas de seguridad

Las pruebas de seguridad del servicio web son un aspecto importante durante las pruebas de nivel de servicio de la aplicación SOA; esto garantiza la seguridad de la aplicación.

Los siguientes factores deben tenerse en cuenta durante las pruebas:

• El servicio web debe cumplir con el estándar industrial definido por las pruebas de WS-Security.
• Las medidas de seguridad deberían funcionar perfectamente.
• Cifrado de datos y Digifirmas tal en los documentos
• Autenticacion y autorizacion
• Inyección SQL, malware, XSS, CSRF y otras vulnerabilidades se probarán en XML.
• Ataques de denegación de servicio

7) Pruebas de rendimiento

Es necesario realizar pruebas de rendimiento del servicio, ya que los servicios son reutilizables y es posible que varias aplicaciones estén utilizando el mismo servicio.

Durante las pruebas se tienen en cuenta los siguientes factores:

• Es necesario probar el rendimiento y la funcionalidad del servicio bajo una carga pesada.
• El rendimiento del servicio debe compararse mientras se trabaja individualmente y dentro de la aplicación con la que está acoplado.
• Se deben realizar pruebas de carga del servicio.
• para verificar el tiempo de respuesta
• para comprobar si hay cuellos de botella
• para verificar la utilización de CPU y memoria
• para predecir la escalabilidad

8) Pruebas de nivel de integración

• Las pruebas de nivel de servicio garantizan el funcionamiento adecuado sólo de los servicios individualmente, no garantizan el funcionamiento de los componentes acoplados.
• Las pruebas de integración se realizan centrándose principalmente en las interfaces.
• Esta fase cubre todos los escenarios de negocio posibles.
• Las pruebas no funcionales de la aplicación se deben realizar una vez más en esta fase. Las pruebas de seguridad, cumplimiento y rendimiento garantizan la disponibilidad y estabilidad del sistema en todos los aspectos.
• Los protocolos de comunicación y de red deben probarse para validar la coherencia de la comunicación de datos entre los servicios.

9) Pruebas de extremo a extremo

Esta fase garantiza que la aplicación cumpla con los requisitos comerciales tanto funcional como no funcionalmente.

Se garantiza que los siguientes elementos se probarán durante las pruebas de principio a fin.

• Todos los servicios funcionan como se esperaba después de la integración.
• Manejo de excepciones
• Interfaz de usuario de la aplicación
• Flujo de datos adecuado a través de todos los componentes.
• Procesos de negocio

Desafíos en las pruebas SOA

• Falta de interfaces para Servicios
• El proceso de prueba abarca múltiples sistemas, lo que crea necesidades de datos complejas
• La aplicación es una colección de varios componentes que tiende a cambiar. La necesidad de realizar pruebas de regresión es más frecuente.
• Debido a la arquitectura multicapa, es difícil aislar los defectos.
• Dado que el servicio se utilizará en diferentes interfaces, es difícil predecir la carga, lo que hace que la planificación de las pruebas de rendimiento sea engorrosa.
• SOA es un conjunto de tecnologías heterogéneas. Para probar una aplicación SOA se necesitan personas con diferentes habilidades, lo que a su vez aumenta los costos de planificación y ejecución.
• Dado que la aplicación es una integración de múltiples servicios, las pruebas de seguridad tienen sus propios problemas. La validación de la autenticación y autorización es bastante difícil.

Casos de uso de pruebas SOA

Considere un sitio web de comercio electrónico, que contiene las siguientes funciones y subfunciones:

procesando orden

FASE 1

En la primera fase de las pruebas SOA, es decir, la fase de estrategia de prueba, la aplicación se divide en servicios y funciones comerciales.

Consideremos a continuación los Servicios de la aplicación.

• Crear orden
• Verificar el estado del cliente
• Cambiar el estado del pedido
• Comprobar el estado del pedido
• Comprobar inventario

Las funciones comerciales son las mismas que las del Sitio Web.

Nota: El documento de estrategia de prueba contendría la lista del servicio y las funciones que deben probarse.

FASE 2

Fase de planificación de pruebas. Los casos de prueba se escriben para cada nivel.

1. Nivel de extremo a extremo. Los casos de prueba se escriben para cada flujo y caso de uso empresarial. A continuación se muestran ejemplos de casos de prueba.
   • Crea un pedido con el usuario activo.
   • Crea un pedido con un usuario inactivo.
   • Cree un pedido con el producto disponible con cantidad de pedido <cantidad disponible.
   • Cree un pedido con el producto disponible con cantidad de pedido > cantidad disponible.
   • Crear un pedido con varios artículos
   • Cancelar un pedido por completo.
   • Cancelar pedido parcialmente.
2. Nivel de integración. Los casos de prueba están escritos para la integración de la base de datos y la interfaz de usuario. A continuación se muestran casos de prueba de ejemplo.
   • Crea un nuevo pedido con un solo artículo. Verifique que el pedido esté creado en la base de datos.
   • Crea un nuevo pedido con un solo artículo. Verifique que el precio calculado para el pedido sea correcto.
   • Crea un nuevo pedido con un solo artículo. Verifique que la cantidad del producto disponible sea menor al monto del pedido.
   • Verifique que el estado del pedido que se muestra en la interfaz de usuario sea el mismo que el de la base de datos.
   • Cancelar el pedido y verificar que el estado del pedido se modifique en la base de datos.
   • Para el primer pago, verifique que los detalles de pago ingresados ​​en la interfaz de usuario estén guardados en la base de datos.
   • Para devolver pagos, verifique que los detalles de pago en la base de datos se muestren en la interfaz de usuario.
3. Nivel de servicio. Cada servicio se prueba para todas las condiciones de datos.

Abajo hay algunos ejemplos.

No.	Detalles de pedido	Condición del pedido
1	Crear orden. No. de artículos = 1	Cantidad en pedido < Cantidad en base de datos
2	Crear orden. No. de artículos > 1	Cantidad en pedido < Cantidad en la base de datos.
3	Crear pedido No. de artículos = 1	Cantidad en pedido > Cantidad en base de datos
4	Comprobar el estado del pedido	Estado en la base de datos = Activo
5	Comprobar el estado del pedido	Estado en la base de datos = Enviado
6	Comprobar el estado del pedido	Estado en la base de datos = Cancelado
7	Comprobar el estado del pedido	ID de pedido = no válido
8	Consultar disponibilidad de producto	Cantidad de producto >0
9	Consultar disponibilidad de producto	Cantidad de producto =0
10	Consultar disponibilidad de producto	ID del producto = no válido

FASE 3 – Ejecución de la prueba

La ejecución de pruebas utiliza un enfoque ascendente, es decir, primero se realizan las pruebas de nivel de servicio, luego el nivel de integración y, por último, el nivel de integración. Pruebas de extremo a extremo.

1) nivel de servicio

Consideremos que Jabón Se considera una herramienta para probar la aplicación.

La WSDL y la URL se exploran en la ventana de prueba de SOAP.

La solicitud de cada servicio se mostrará en la ventana de solicitud.

Al modificar los datos según los casos de prueba de nivel de servicio, se crean solicitudes para cada caso de prueba.

Caso de prueba	Solicitar retiro	Respuesta esperada
Crear orden. No. de artículos = 1Cantidad en pedido < Cantidad en base de datos	x2	o3251Exitoso
Crear pedido.No. de artículos > 1Cantidad en pedido < Cantidad en base de datos	y1y1	o3251Exitoso
Crear número de pedido. de artículos = 1Cantidad en pedido > Cantidad en base de datos	x23	nuloFalló
Verifique el estado del pedidoEstado en la base de datos = Activo	o9876	ActivoExitoso
Verifique el estado del pedidoEstado en la base de datos = Enviado	o9656	EnviadoExitoso
Verificar estado del pedidoId. del pedido = no válido	y5686	nuloFracasado
Consultar disponibilidad del productoCantidad de producto >0	d34	34síExitoso
Consultar disponibilidad del productoCantidad de producto =0	y34	0noExitoso
Verificar disponibilidad del productoID del producto = no válido	sder	Fracasado

2) Nivel de integración

Los casos de prueba del nivel de integración se ejecutan en la interfaz de usuario y la base de datos.

• Crear un pedido con un solo artículo –
• Un usuario abre el sitio web.
• Va a hacer un pedido.
• Selecciona un producto y una cantidad válidos y guarda el pedido.
• Debería mostrarse un mensaje que indique que el pedido se realizó correctamente.
• Un usuario abre la base de datos y verifica si los detalles del pedido coinciden con los ingresados ​​en el sitio web.

3) Nivel de extremo a extremo

Los flujos de negocio y los casos de uso se ejecutan en la interfaz de usuario.

• Crear un pedido con varios artículos –
• Un usuario abre un sitio web.
• Va a hacer un pedido.
• Consulta sobre un producto válido y cantidad agrégalos al carrito.
• Se agregan otros productos válidos con cantidades válidas y se guarda el pedido. El pago se realiza a través de un nuevo método de pago y se realiza el pedido.
• Debería aparecer un mensaje que diga “Pedido realizado exitosamente”.
• Un evaluador debe validar que todo el flujo se realice sin sesgos en los datos.

Conclusión

Al esbozar la estrategia adecuada para las pruebas, los recursos, las herramientas y el cumplimiento para brindar un buen servicio, las pruebas SOA pueden entregar aplicaciones completamente y perfectamente probadas.