¿Qué son las pruebas SOA? Tutorial con ejemplo

¿Qué son las pruebas SOA?

SOA (Orientado a Servicios Architectura) Pruebas Se trata de la prueba del estilo arquitectónico SOA, en el que los componentes de la aplicación están diseñados para comunicarse mediante protocolos de comunicación, normalmente 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.

In Ingeniería de SoftwareLa arquitectura orientada a servicios (SOA) proporciona agilidad y flexibilidad a los procesos de negocio. Un cambio en un proceso o aplicación puede dirigirse a un componente específico sin afectar a todo el sistema.

Los desarrolladores de software que trabajan en SOA desarrollan o compran fragmentos de programas llamados servicios.

¿Qué es el servicio?

El diagrama que aparece a continuación muestra una pasarela de pago publicada como un servicio al que pueden acceder varios sitios de comercio electrónico.

• Un servicio puede ser una unidad funcional de una aplicación o un proceso de negocio, que puede ser reutilizada o repetida por cualquier otra aplicación o proceso. (Por ejemplo, en la imagen superior, la pasarela de pago es un servicio que puede ser reutilizado por cualquier sitio de comercio electrónico. Cuando se necesita realizar un pago, el sitio de comercio electrónico llama o solicita el servicio de pasarela de pago. Una vez completado el pago en la 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 pueden compararse con bloques de construcción. Permiten crear cualquier aplicación necesaria, y añadirlos o eliminarlos de la aplicación o del proceso empresarial es sencillo.
• Los servicios se definen más por la función empresarial que desempeñan que como fragmentos de código.

Servicios Web

La mayoría de los servicios SOA se exponen como servicios web, por lo que conviene definir la mecánica de una llamada a un servicio web antes de implementar las capas de prueba.

Los servicios Web son componentes de aplicación independientes que están disponibles a través de la web.

Pueden publicarse, encontrarse y utilizarse en la web, y se comunican a través de internet. La siguiente secuencia muestra cómo interactúan un proveedor, un registro y un consumidor.

• El Proveedor de Servicios publica el servicio en Internet.
• El cliente busca un servicio web específico en el Registro de Servicios Web.
• A URL y conectar WSDL Se devuelven los servicios web requeridos. Utilizando el WSDL y el URLLa comunicación entre el proveedor de servicios y el solicitante se realiza mediante mensajes SOAP.
• Cuando un consumidor llama a un servicio web, se establece una conexión HTTP con el proveedor.
• Se crea un mensaje SOAP para indicar al proveedor que invoque la lógica del servicio web necesaria.
• La respuesta recibida del proveedor es un mensaje SOAP integrado en la respuesta HTTP. Esta respuesta HTTP es el formato de datos que la aplicación del cliente puede comprender.

Ejemplo

La captura de pantalla que aparece a continuación muestra un informe meteorológico proporcionado por un servicio externo e integrado en la página principal de un motor de búsqueda.

La página de inicio de un sitio web y un motor de búsqueda muestran un informe meteorológico diario. En lugar de programar la sección del informe meteorológico desde cero, se puede adquirir un servicio de informes meteorológicos de un proveedor e integrarlo en las páginas.

Capas de prueba de SOA

SOA se compone de diversas tecnologías, y las aplicaciones desarrolladas con SOA cuentan con varios servicios débilmente acoplados. El siguiente diagrama muestra las tres capas que debe abarcar un plan de pruebas.

Las pruebas SOA deben centrarse en 3 capas del sistema.

Capa de servicios

Esta capa consta de los servicios expuestos por un sistema, derivados de las funciones de negocio.

Por ejemplo, consideremos un sitio web de bienestar que consta de:

• Peso Tracker
• Glicemia Tracker
• Presión sanguínea Tracker

TracLos kers muestran los datos correspondientes y la fecha en que se ingresaron. La capa de servicios consta de los servicios que obtienen los datos correspondientes de la base de datos:

• Peso Tracservicio de ker
• Glicemia Tracservicio de ker
• Presión sanguínea Tracservicio de ker
• Servicio de inicio de sesión

Capa de proceso

La capa de procesos consta de los procesos, el conjunto de servicios que forman parte de una única funcionalidad.

Estos procesos podrían formar parte de una interfaz de usuario (por ejemplo, un motor de búsqueda) o de una herramienta ETL que extrae datos de la base de datos.

El enfoque principal en esta capa está en las interfaces de usuario y los procesos. La interfaz de usuario del peso tracEl enfoque principal es el kernel y su integración con la base de datos.

Se tendrán en cuenta las siguientes funciones:

• Agregar nuevos datos
• Editar datos existentes
• Creando un nuevo tracker
• Borrando datos

Capa de consumidor

Esta capa se compone principalmente de interfaces de usuario, como ilustra la siguiente pantalla.

En función de estas capas, las pruebas de una aplicación SOA se distribuyen en tres niveles:

• Nivel de servicio
• Nivel de interfaz
• Nivel de extremo a extremo

Los dos enfoques difieren: para el diseño de las pruebas se utiliza un enfoque de arriba hacia abajo, mientras que para la ejecución de las pruebas se utiliza un enfoque de abajo hacia arriba.

Estrategia para pruebas SOA

Enfoque de planificación de pruebas

• Los evaluadores de SOA deben comprender la arquitectura completa de la aplicación.
• La aplicación debe dividirse en servicios independientes (un servicio que tenga su propia estructura de solicitud y respuesta y que no dependa de ningún otro servicio para generar una respuesta).
• Es necesario reorganizar la estructura de la aplicación en tres componentes: datos, servicios y aplicaciones de interfaz de usuario.
• Es necesario analizar cuidadosamente todos los componentes y elaborar escenarios de negocio.
• Los escenarios de negocio deben clasificarse en escenarios comunes y escenarios específicos de la aplicación.
• A Matriz de Trazabilidad deben estar preparados, y todos los casos de prueba deben estar tracadaptado a escenarios empresariales.

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 validación del modelo completo para comprobar 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 y orientadas a escenarios de negocio

• Deben analizarse diversos aspectos comerciales relacionados con el sistema.
• Se deben desarrollar escenarios basados ​​en la integración de los diversos servicios web de la aplicación, y de los servicios web con la aplicación.
• La configuración de los datos debe realizarse en función de los escenarios descritos anteriormente.
• La configuración de los datos también debe abarcar escenarios de principio a fin.

2) Talones

• Se crean 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á siendo probado (un servicio de terceros), se puede crear un stub durante las pruebas de integración.

3) Pruebas de regresión

• Pruebas de regresión La actualización de la aplicación debe realizarse cuando haya 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 la comprobación de la funcionalidad, la seguridad, el rendimiento y la interoperabilidad del componente. Cada servicio debe probarse de forma independiente previamente.

5) Pruebas funcionales

Prueba de funcion debe hacerse en cada servicio para:

• Asegúrese de que el servicio proporcione la respuesta adecuada a cada solicitud.
• Asegúrese de que se reciban los errores correctos para las solicitudes con datos no válidos o erróneos.
• Verifique cada solicitud y respuesta para cada operación que el servicio deba realizar en tiempo de ejecución.
• Validar los mensajes de error cuando se produzca un fallo en el servidor, el cliente o la red.
• Validar que las respuestas recibidas estén en el formato correcto.
• Verifique que los datos recibidos en la respuesta se correspondan con 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, ya que garantizan 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 de la industria definido por WS-Security.
• Las medidas de seguridad deberían funcionar perfectamente.
• Cifrado de datos y firmas digitales en los documentos.
• Autenticación y autorización.
• Se probarán las vulnerabilidades de inyección SQL, malware, XSS, CSRF y otras en el sistema. XML.
• Ataques de denegación de servicio.

7) Pruebas de rendimiento

Es necesario realizar pruebas de rendimiento del servicio porque los servicios son reutilizables y varias aplicaciones podrían estar 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.
• Es necesario comparar el rendimiento del servicio cuando funciona de forma independiente y cuando está integrado en la aplicación.
• Prueba de carga Se debe realizar una prueba del servicio para verificar el tiempo de respuesta, detectar cuellos de botella, comprobar la utilización de la CPU y la memoria, y predecir la escalabilidad.

8) Pruebas de nivel de integración

• Las pruebas de nivel de servicio garantizan el correcto funcionamiento de los servicios individualmente; no garantizan el funcionamiento de los componentes acoplados.
• Las pruebas de integración se realizan centrándose principalmente en el las interfaces.
• Esta fase cubre todos los escenarios de negocio posibles.
• En esta fase, se deben realizar nuevamente las pruebas no funcionales de la aplicación. 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 del negocio tanto a nivel funcional como no funcional.

Se garantiza que los elementos que se indican a continuación serán probados durante pruebas de extremo a extremo:

• 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 de SOA

Aplicar esos métodos rara vez es sencillo, y las dificultades que se describen a continuación se repiten en casi todos los programas SOA.

• Falta de interfaces para los servicios.
• El proceso de pruebas abarca múltiples sistemas, lo que genera necesidades de datos complejas.
• La aplicación es un conjunto de varios componentes que tienden a cambiar, por lo que la necesidad de realizar pruebas de regresión es más frecuente.
• Debido a su arquitectura multicapa, resulta difícil aislar los defectos.
• Dado que un servicio es utilizado por diferentes interfaces, la carga es difícil de predecir, lo que dificulta la planificación de las pruebas de rendimiento.
• SOA es un conjunto de tecnologías heterogéneas. Probar una aplicación SOA requiere personas con diferentes habilidades, lo que a su vez aumenta los costos de planificación y ejecución.
• Dado que la aplicación integra múltiples servicios, las pruebas de seguridad presentan sus propios problemas. Validar la autenticación y la autorización resulta difícil.

Herramientas de prueba SOA

Existen numerosas herramientas de prueba SOA disponibles en el mercado para ayudar a los evaluadores a probar aplicaciones SOA. A continuación, se presentan algunas de las herramientas de prueba SOA más populares.

1) SoapUI

SoapUI es una herramienta de prueba funcional de código abierto para servicios y Pruebas de API.

• Aplicación de escritorio
• Admite múltiples protocolos: SOAP, REST, HTTP, JMS, AMF, JDBC.
• Los servicios web pueden desarrollarse, inspeccionarse e invocarse.
• También se puede utilizar para pruebas de carga, Pruebas de automatizacióny pruebas de seguridad
• MockServices puede crear apéndices
• Las solicitudes y pruebas de servicios web se pueden generar automáticamente a través de su cliente de servicios web.
• Cuenta con herramientas de generación de informes integradas.
• Desarrollado por SmartBear, que realiza envíos tanto del De código abierto SoapUI distribución y el comercial ReadyAPI edición

2) Virtualización de servicios de Broadcom (anteriormente iTKO LISA)

LISA es un conjunto de productos que proporciona una solución de pruebas funcionales para sistemas distribuidos como SOA. El producto pasó de iTKO a CA Technologies y actualmente se comercializa como Broadcom Service Virtualization.

• También se puede utilizar para pruebas de regresión, integración, carga y rendimiento.
• Se puede utilizar para diseñar y ejecutar pruebas.

3) UFT Uno (anteriormente HP Service Test)

Service Test es una herramienta de pruebas funcionales que admite pruebas de interfaz de usuario y servicios compartidos. Su capacidad de prueba de API se integró en Unified Functional Testing, que ahora vende OpenText as UFT Uno.

• Tanto las pruebas funcionales como las de rendimiento de los servicios pueden realizarse mediante un único script.
• Integrado con Quality Center, ahora vendido como OpenText ALM / Centro de Calidad.
• Se puede gestionar una enorme cantidad de servicios y datos.
• Admite pruebas de interoperabilidad mediante la simulación de entornos de cliente JEE, AXIS y DotNet.

4) Prueba SOA de Parasoft

Parasoft SOAtest es un conjunto de herramientas de prueba y análisis desarrollado para la prueba de API y aplicaciones basadas en API.

• Admite servicios web y tecnologías REST, JSON, MQ, JMS, TIBCO, HTTP y XML.
• Es posible realizar pruebas funcionales, unitarias, de integración, de regresión, de seguridad, de interoperabilidad, de cumplimiento y de rendimiento.
• Los stubs se pueden crear usando Virtualización de Parasoft, que son más capaces que SoapUI Servicios simulados.

Casos de uso de pruebas SOA

El ejemplo práctico que se muestra a continuación aplica la estrategia, los métodos y las herramientas descritas anteriormente a un único sitio web de comercio electrónico, fase por fase.

Consideremos un sitio web de comercio electrónico que contiene las siguientes funciones y subfunciones.

procesando orden

El siguiente diagrama divide el procesamiento de pedidos en las subfunciones que se convierten en servicios.

FASE 1

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

Consideremos los servicios que se detallan a continuación en la aplicación.

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

Las funciones empresariales son las mismas que las funciones del sitio web.

Nota: El documento de estrategia de pruebas contendrá la lista de los servicios y las funciones que deben someterse a prueba.

FASE 2

Esta es la fase de planificación de las pruebas. Casos de prueba Están escritos para cada nivel.

Nivel de extremo a extremo. Los casos de prueba están diseñados para cada caso de uso y flujo de negocio. A continuación se muestran ejemplos de casos de prueba.

• Crea un pedido con un usuario activo.
• Crea un pedido con un usuario inactivo.
• Crea un pedido con un producto disponible cuya cantidad sea menor que la cantidad disponible.
• Crea un pedido con un producto disponible cuya cantidad sea mayor que la cantidad disponible.
• Crea un pedido con varios artículos.
• Cancelar un pedido por completo.
• Cancelar un pedido parcialmente.

Nivel de integración. Se han diseñado casos de prueba para la integración de la base de datos y la interfaz de usuario. A continuación se muestran ejemplos de casos de prueba.

• 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. Verifica que la cantidad del producto disponible se reduzca en la cantidad del pedido.
• Verifique que el estado del pedido que se muestra en la interfaz de usuario sea el mismo que el que figura en 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 introducidos en la interfaz de usuario se hayan guardado 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.

Nivel de servicio. Cada servicio se prueba para todas las condiciones de datos. A continuación se muestran 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 orden. 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 las pruebas utiliza un enfoque ascendente: primero se realizan las pruebas a nivel de servicio, luego las de nivel de integración y, por último, las pruebas de extremo a extremo.

1) nivel de servicio

Consideremos que el SoapUI La herramienta se utiliza para probar la aplicación. El WSDL y URL se navegan en la ventana de prueba de SoapUIy la solicitud para cada servicio se muestra 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 pedido. Número de artículos = 1, Cantidad en el pedido < Cantidad en la base de datos	x2	o3251Exitoso
Crear pedido. Número de artículos > 1, Cantidad en el pedido < Cantidad en la base de datos	y1y1	o3251Exitoso
Crear pedido. Número de artículos = 1, Cantidad en el pedido > Cantidad en la base de datos	x23	nuloFalló
Verificar el estado del pedido. Estado en la base de datos = Activo	o9876	Activo Exitoso
Verificar el estado del pedido. Estado en la base de datos = Enviado	o9656	Enviado Exitoso
Verificar el estado del pedido. ID del pedido = Inválido	y5686	nulo Fracasado
Comprobar disponibilidad del producto. Cantidad de producto >0	d34	34síExitoso
Comprobar disponibilidad del producto. Cantidad del producto = 0	y34	0noExitoso
Compruebe la disponibilidad del producto. ID del producto = no válido	sder	Fracasado

2) Nivel de integración

Los casos de prueba de nivel de integración se ejecutan en la interfaz de usuario y la base de datos. Cree un pedido con un solo artículo:

• Un usuario abre el sitio web.
• El usuario procede a realizar un pedido.
• El usuario selecciona un producto y una cantidad válidos y guarda el pedido.
• Debería mostrarse un mensaje indicando que el pedido se ha realizado correctamente.
• El usuario abre la base de datos y comprueba si los detalles del pedido coinciden con los introducidos en la página web.

3) Nivel de extremo a extremo

Los flujos de negocio y los casos de uso se ejecutan en la interfaz de usuario. Cree un pedido con varios artículos:

• Un usuario abre el sitio web.
• El usuario procede a realizar un pedido.
• El usuario consulta sobre un producto y una cantidad válidos y los añade al carrito.
• Se añaden otros productos válidos con las cantidades correspondientes y se guarda el pedido. Se realiza el pago mediante un nuevo método de pago y se confirma el pedido.
• Debería aparecer un mensaje que diga “Pedido realizado exitosamente”.
• El evaluador debe validar que todo el flujo se complete sin que se produzcan distorsiones en los datos.

Preguntas Frecuentes