SoapUI es una herramienta de código abierto para probar servicios web y APIs. Comenzó en 2005 como una forma de probar servicios SOAP, de ahí su nombre, y más tarde creció para manejar también REST, GraphQL, JMS y JDBC. Durante dos décadas ha sido un pilar en los equipos de QA empresariales, especialmente aquellos que mantienen integraciones más antiguas basadas en SOAP que las herramientas más nuevas suelen ignorar.
Si solo has trabajado con APIs REST JSON y un cliente moderno, SoapUI puede parecer una reliquia. Pero sigue siendo una de las pocas herramientas que maneja correctamente las pruebas SOAP basadas en WSDL, y sigue siendo relevante dondequiera que bancos, aseguradoras, sistemas gubernamentales y plataformas de telecomunicaciones ejecuten servicios web XML. Esta guía explica qué hace SoapUI, las características importantes, cuándo es la elección correcta y las limitaciones que empujan a muchos equipos hacia alternativas.
Qué hace SoapUI realmente
SoapUI es una aplicación de escritorio que te permite crear, enviar y validar solicitudes API sin escribir código de aplicación. Lo apuntas a una definición de servicio, construyes solicitudes de prueba contra ella, añades aserciones y ejecutas esas solicitudes como suites.
Su truco definitorio es la importación de WSDL. Un archivo WSDL (Web Services Description Language) es un documento XML que describe completamente un servicio SOAP: sus operaciones, formatos de mensajes y tipos de datos. Alimentas SoapUI con una URL WSDL y genera solicitudes esqueleto para cada operación, precargadas con la estructura de sobre XML correcta. Rellenas los valores y envías. Esa generación automática es la razón por la que SoapUI se mantuvo para el trabajo SOAP; escribir manualmente un sobre SOAP es tedioso y propenso a errores.
En el lado REST, SoapUI importa definiciones de OpenAPI y WADL y te permite construir solicitudes con métodos, parámetros, encabezados y cuerpos, de manera muy similar a cualquier otro cliente API. Admite ambos estilos en un solo proyecto, lo que es útil para equipos en plena migración de SOAP a REST.
SoapUI se distribuye en dos ediciones. La versión de código abierto cubre las pruebas funcionales básicas y es gratuita. ReadyAPI es la edición comercial de SmartBear; añade pruebas de carga, escaneo de seguridad, pruebas basadas en datos de fuentes externas y una interfaz más pulida. Cuando la gente dice "SoapUI" generalmente se refieren a la herramienta gratuita de código abierto, y ese es el enfoque aquí.
Características clave
El conjunto de características de SoapUI se basa en una jerarquía clara: los proyectos contienen suites de prueba, las suites de prueba contienen casos de prueba, y los casos de prueba contienen pasos de prueba.
- Proyectos. Un proyecto contiene todas las solicitudes, suites y configuración para un servicio o un grupo relacionado de servicios. Es el contenedor de nivel superior que guardas y compartes con el equipo.
- Suites de pruebas funcionales. Dentro de un proyecto, construyes casos de prueba compuestos por pasos ordenados. Un paso puede ser una solicitud, una aserción, una transferencia de propiedades, un retraso o un script. Los pasos se ejecutan en secuencia, por lo que puedes iniciar sesión, capturar un token y reutilizarlo en solicitudes posteriores.
- Aserciones. SoapUI ofrece una amplia gama de aserciones integradas: comprobaciones de código de estado, coincidencias XPath y XQuery contra respuestas XML, comprobaciones JSONPath contra JSON, cumplimiento de esquemas, límites de tiempo de respuesta de SLA y coincidencia de contenido. Estas te permiten validar una respuesta sin escribir código. Nuestra guía sobre aserciones API explica los patrones que se aplican aquí.
- Transferencia de propiedades. Este paso copia un valor de una respuesta a una solicitud posterior. Así es como encadenas llamadas: extraes un ID de sesión de una respuesta de inicio de sesión y lo inyectas en la siguiente llamada. Es el equivalente en SoapUI de la extracción de variables en otras herramientas.
- Scripts Groovy. Cuando los pasos integrados no son suficientes, SoapUI ejecuta scripts Groovy. Puedes generar datos dinámicos, transformar cargas útiles, ejecutar aserciones personalizadas o llamar a sistemas externos. Esta es la vía de escape que hace que SoapUI sea flexible para escenarios empresariales complejos.
- Servicios mock. SoapUI puede configurar un mock de un servicio SOAP o REST a partir de su definición, para que puedas probar un cliente antes de que exista el backend real. Si la simulación es central para tu flujo de trabajo, compara las opciones en nuestro artículo sobre casos de uso de simulación de API.
En conjunto, estas características hacen de SoapUI un entorno completo de pruebas funcionales para servicios con gran cantidad de XML, que es precisamente el nicho para el que fue construido.
Un flujo de trabajo típico de SoapUI
Recorrer una sesión básica de SoapUI concreta la jerarquía. Así es como un tester suele abordar un nuevo servicio.
- Crear un proyecto a partir de una definición. Iniciamos SoapUI, creamos un nuevo proyecto y pegamos una URL WSDL para un servicio SOAP o un archivo OpenAPI para un servicio REST. SoapUI lo analiza y genera un árbol de operaciones o endpoints.
- Enviar una solicitud exploratoria. Abrimos una de las solicitudes generadas, rellenamos valores de ejemplo y hacemos clic en enviar. SoapUI muestra la respuesta en bruto, formateada como XML o JSON, para que puedas confirmar que el servicio responde como se espera.
- Construir una suite de pruebas. Una vez que comprendes el servicio, creas una suite de pruebas, añades casos de prueba y añades pasos de prueba dentro de ellos. Un paso de inicio de sesión captura un token, un paso de transferencia de propiedades mueve ese token hacia adelante, y los pasos de solicitud subsiguientes lo utilizan.
- Añadir aserciones. En cada paso de solicitud adjuntas aserciones: una verificación de código de estado, una coincidencia XPath en un elemento específico, un límite de SLA en el tiempo de respuesta. Esto convierte una solicitud en una prueba real que pasa o falla.
- Ejecutar y revisar. Ejecutas el caso de prueba o la suite completa. SoapUI muestra un resultado de aprobación o fallo por paso y por aserción, con los datos de respuesta disponibles para cualquier fallo que necesites investigar.
Este ciclo, de la definición a la exploración, a la suite, a las aserciones, a la ejecución, es el mismo ya sea que pruebes SOAP o REST. La estructura es lo que le da a SoapUI su poder y también lo que lo hace sentir pesado para trabajos pequeños.
SoapUI comparado con otras herramientas
Ayuda situar SoapUI frente a las herramientas que los testers utilizan hoy en día. La siguiente tabla esboza los aspectos generales.
| Aspecto | SoapUI | Clientes REST modernos |
|---|---|---|
| Soporte SOAP y WSDL | Fuerte, de primera clase | Débil o ausente |
| Aserciones XML (XPath, XQuery) | Extenso | Limitado |
| Soporte REST y OpenAPI | Adecuado | De primera clase |
| Interfaz | Densa, anticuada | Optimizado, moderno |
| Curva de aprendizaje | Pronunciada | Más suave |
| Pruebas de carga en edición gratuita | No incluido | Varía |
El resumen que la tabla señala es sencillo. SoapUI gana decisivamente en SOAP y XML, y los clientes modernos ganan en flujo de trabajo REST y accesibilidad. Tu pila tecnológica decide qué columna importa más.
Cuando SoapUI es la elección correcta
SoapUI es una opción sólida en situaciones específicas. Úsalo cuando mantengas servicios SOAP y necesites soporte WSDL real, porque pocas herramientas modernas manejan los sobres SOAP y WS-Security de forma tan limpia. Úsalo cuando trabajes en una empresa que ya estandarizó en SoapUI o ReadyAPI, ya que los costos de cambio y los activos de prueba existentes favorecen la continuidad. Úsalo cuando necesites aserciones XPath o XQuery contra XML profundamente anidado, un área donde SoapUI es genuinamente fuerte.
También es adecuado para equipos que desean una herramienta de pruebas funcionales gratuita y sin código y que pueden asimilar la curva de aprendizaje. Si tus servicios son principalmente SOAP, SoapUI probablemente será más rápido de configurar que forzar una herramienta orientada a REST para manejar XML. Para una visión más amplia de los enfoques de prueba, consulta nuestra descripción general de qué es la prueba automatizada.
Dónde SoapUI se queda corto
SoapUI carga con el peso de su edad, y sus limitaciones son reales.
La curva de aprendizaje es pronunciada. La jerarquía proyecto-suite-caso-paso es potente pero poco intuitiva, y la interfaz expone muchas opciones a la vez. Los nuevos usuarios se sienten rutinariamente perdidos. Construir algo más allá de una solicitud básica a menudo significa recurrir a Groovy, lo que añade un requisito de scripting a una herramienta comercializada como "sin código".
El uso de recursos es elevado. SoapUI es una aplicación de escritorio Java, y los proyectos grandes con muchas suites pueden hacerla lenta. En hardware modesto, abrir un proyecto grande y ejecutar suites pone a prueba tu paciencia.
La edición de código abierto no incluye pruebas de carga. Las pruebas de rendimiento y concurrencia se encuentran en el producto de pago ReadyAPI. Si necesitas cobertura tanto funcional como de carga, o pagas o añades una segunda herramienta. Nuestra guía de herramientas de prueba de rendimiento de software cubre las alternativas.
La integración CI/CD es funcional pero anticuada. SoapUI se puede ejecutar desde la línea de comandos y hay un plugin de Maven, pero la experiencia se siente como un añadido en comparación con herramientas diseñadas para pipelines desde el principio. La interfaz en sí misma refleja una era anterior del software de escritorio y no ha mantenido el ritmo de los clientes API modernos.
Finalmente, SoapUI es compatible con REST pero tiene forma de SOAP. Si toda tu pila son APIs REST JSON, probablemente encontrarás un cliente moderno más rápido y agradable. SoapUI se gana su lugar donde SOAP y XML siguen en juego.
Una alternativa moderna: Apidog
Para equipos cuyas APIs son principalmente REST, GraphQL o están construidas alrededor de OpenAPI, Apidog ofrece una visión más actual del mismo flujo de trabajo. Combina diseño de API, depuración, pruebas funcionales automatizadas y servidores mock en una sola aplicación. Diseñas un esquema, envías solicitudes, añades aserciones visuales sin scripting y encadenas pasos en escenarios de prueba automatizados, todo en una interfaz diseñada para el trabajo API moderno en lugar de adaptada sobre una base de veinte años.
Apidog también incluye pruebas de rendimiento en la misma herramienta, por lo que no necesitas un producto de pago separado para la cobertura de carga. Soporta CI/CD a través de un ejecutor de línea de comandos y se integra limpiamente con los pipelines. Puedes descargar Apidog y usar sus funciones de prueba principales de forma gratuita. Si aún necesitas pruebas específicas de SOAP, nuestra guía de tester de API SOAP en línea cubre opciones para ese caso.
El resumen honesto: SoapUI sigue siendo la opción práctica para las pruebas empresariales con gran carga de SOAP, y es gratuito y capaz en ese nicho. Para proyectos REST de nueva creación, una plataforma moderna generalmente te servirá mejor.
Preguntas frecuentes
¿Es SoapUI gratuito?
La edición de código abierto de SoapUI es gratuita y cubre pruebas funcionales para APIs SOAP y REST. ReadyAPI, la edición comercial de SmartBear, es un producto de pago que añade pruebas de carga, escaneo de seguridad, pruebas avanzadas basadas en datos y una interfaz refinada. La mayoría de las referencias a "SoapUI" se refieren a la herramienta gratuita de código abierto.
¿SoapUI solo prueba APIs SOAP?
No. A pesar del nombre, SoapUI prueba REST, GraphQL, JMS y JDBC además de SOAP. Importa definiciones de OpenAPI y WADL para servicios REST. Dicho esto, su soporte WSDL y sus capacidades de aserción XML son sus características más potentes, por lo que es más atractivo para equipos con servicios SOAP que mantener.
¿Puede SoapUI ejecutarse en un pipeline de CI/CD?
Sí. SoapUI puede ejecutar suites de pruebas desde la línea de comandos, y existe un plugin de Maven para la integración en la compilación. La experiencia funciona, pero se siente menos pulida que las herramientas diseñadas para pipelines desde cero. Para un uso intensivo de CI, evalúa lo cómodo que es el ejecutor de línea de comandos para tu flujo de trabajo.
¿Cuál es la diferencia entre SoapUI y Postman?
SoapUI tiene un soporte más profundo para SOAP y WSDL y aserciones XML más potentes, y está construido alrededor de una jerarquía estructurada de suites de prueba. Postman es "REST-first", tiene una interfaz más amigable y un ecosistema más grande. Los equipos que mantienen servicios SOAP a menudo prefieren SoapUI; los equipos que construyen APIs REST JSON generalmente prefieren Postman o una alternativa moderna.
¿Necesito saber Groovy para usar SoapUI?
No para solicitudes básicas y aserciones integradas. Pero cualquier cosa dinámica, como generar datos de prueba, transformar cargas útiles o escribir lógica de validación personalizada, típicamente requiere scripts Groovy. Planea aprender algo de Groovy si tus pruebas van más allá de escenarios simples de solicitud y aserción.
¿Sigue siendo relevante SoapUI en 2026?
Sí, en su nicho. Los servicios SOAP no han desaparecido; siguen siendo comunes en sistemas bancarios, de seguros, gubernamentales, de atención médica y de telecomunicaciones que se construyeron hace años y aún funcionan. Para probar esos servicios, el soporte WSDL de SoapUI es difícil de igualar. Para nuevos proyectos REST y GraphQL, la mayoría de los equipos eligen una herramienta moderna. SoapUI es relevante donde SOAP es relevante.
¿Cuál es la diferencia entre SoapUI y ReadyAPI?
SoapUI es la herramienta gratuita de código abierto para pruebas funcionales. ReadyAPI es el producto comercial de SmartBear que se basa en la misma base y añade pruebas de carga, pruebas de seguridad, pruebas avanzadas basadas en datos y una interfaz más refinada. Si necesitas pruebas de rendimiento o escaneo de seguridad sin añadir una segunda herramienta, ReadyAPI es el camino de pago; de lo contrario, el SoapUI gratuito cubre las pruebas funcionales.