Informática Sana: el blog de Caduceus

Cómo usar SoapUI para crear una batería de tests para mensajes HL7 en 5 pasos

Sin comentarios

Mostramos de forma práctica la configuración básica de una baterías de pruebas con SoapUI, una de sus características más útiles y potentes. Nos basaremos en un ejemplo de informática sanitaria como es habitual: probaremos servicios web SOAP que contienen mensajes HL7.

En el caso práctico 1 hemos utilizado SoapUI para comprobar el funcionamiento de nuestros servicios web desplegados a través de Mirth Connect, pero sin entrar en el campo del testeo de este tipo de aplicaciones.

Material utilizado

Para probar un servicio web que contenga mensajes HL7, lo primero que necesitamos es desplegar un servicio web de estas características.

Aprovecharemos el material utilizado para la solución al caso práctico 1.2, que contiene un servicio web desarrollado con la herramienta Mirth Connect para la validación de mensajes HL7. De esta forma, recomendamos hacer este caso práctico antes para poder seguir mejor este artículo.

En cualquier caso, es posible descargar el material para seguir el artículo:

Material correspondiente al artículo “Cómo usar SoapUI para crear una batería de tests para mensajes HL7 en 5 pasos”:

Contiene los siguientes ficheros:

  • 1-alta-adt-a28-ok.hl7: mensaje de alta utilizado que pasa la validación.
  • 1-alta-adt-a28-no-ok.hl7: modificación del mensaje anterior para que no pase la validación.
  • INFORMATICA_SANA_1_2_2.xml: exportación del canal desarrollado para simular el servicio web de validación de mensajería (para su importación en Mirth Connect).
  • Informática-Sana-soapui-test-suit-project.xml: proyecto SoapUI utilizado para probar el servicio web de validación de mensajería mediante una batería de pruebas (para su importación en SoapUI).
  • validator.wsdl: fichero WSDL generado por el servicio web de validación de mensajería.

Descargar “Material - Cómo usar SoapUI para crear una batería de tests para mensajes HL7 en 5 pasos” material-testcase-soapUI.zip – Descargado 123 veces – 6 KB

Utilizaremos la versión de SoapUI 5.0.0.

¿Qué vamos a hacer?

Vamos a configurar una batería de pruebas sencilla para el servicio web de validación de la mensajería HL7.

Para ello, partiremos del proyecto en SoapUI Informática-Sana-1-2-soapui-project.xml, que ya contiene dos peticiones con mensajes HL7, uno que cumple el proceso de validación y otro que no lo cumple:

Mensaje HL7 que cumple la validación:

MSH|^~\&|NewModernHIS||PharmaCoolX 1.0||20140701123154||ADT^A28|1-alta-adt-a28-ok|T|2.5|||AL|NE
EVN|A28|20140701123153
PID|1||NHC||APELLIDO1^NOMBRE^APELLIDO2||19840123000000|M||||||||||||||||||||||N
PV1|1|N

Mensaje HL7 que no cumple la validación:

MSH|^~\&|NewModernHIS||PharmaCoolX 1.0||20140701123154||ADT^A28|1-alta-adt-a28-no-ok|K|2.5|||AL|NE
EVN|A28|20140701123153
PID|1||NHC||APELLIDO1^NOMBRE^APELLIDO2||19840123000000|M||||||||||||||||||||||N
PV1|1|N

La batería de pruebas tendrá los asertos adecuados para comprobar que:

  • El mensaje HL7 que debe pasar la validación, la pasa.
  • El mensaje HL7 que no debe pasar la validación, no lo hará.

Finalmente, realizaremos un cambio en Mirth Connect que hará que el servicio web se comporte de forma diferente de modo que la batería de pruebas falle.

Creación de la batería de pruebas

Una batería de pruebas (TestSuite) es una estructura jerárquica. Un TestSuite se divide en diferentes TestCase, que agrupan un conjunto de pruebas unitarias llamadas TestStep. En general, todos estos elementos se podrán ejecutar de forma independiente, por lo que es conveniente estructurar muy bien todas nuestras pruebas.

1. Configuración de la batería de pruebas

Para crear una nueva batería de pruebas, hacemos clic con el botón derecho del ratón sobre el proyecto y elegimos la opción New TestSuite:

SoapUI: creación de un <em>TestSuite</em>

SoapUI: creación de un TestSuite

 

Posteriormente, debemos elegir el nombre del TestSuite:

SoapUI: nombrar TestSuite

SoapUI: nombrar TestSuite

Entonces nos aparecerá en el árbol del proyecto.

2. Creación de TestCases

Para crear un nuevo TestCase, podemos hacer clic sobre el botón derecho del ratón sobre el TestSuite recién creado y elegir la opción New TestCase:

SoapUi: creación de TestCase

SoapUi: creación de TestCase

De nuevo, especificamos el nombre para el nuevo elemento. En este caso, es recomendable especificar un nombre representativo del tipo de pruebas unitarias que contendrá:

SoapUI: nombrado de TestCase

SoapUI: nombrado de TestCase

 

3. Creación de los TestSteps

Finalmente, debemos crear los TestStep. El procedimiento es similar a los anteriores, podemos hacer clic con el botón derecho del ratón sobre el TestCase, y elegir la opción “Add Step → Test Request”:

SoapUI: creación de TestSteps

SoapUI: creación de TestSteps

De nuevo, debemos especificar el nombre del elemento:

SoapUi: nombrado de TestStep

SoapUi: nombrado de TestStep

Y en este caso, el tipo de operación que queremos probar:

SoapUI: selección de operación para probar

SoapUI: selección de operación para probar

Finalmente, es posible incorporar algunas validaciones más si queremos:

SoapUi: verificaciones adicionales

SoapUi: verificaciones adicionales

4. Especificación de asertos

Ya tenemos nuestro primer TestCase creado con éxito. Tras copiar en el área de texto el mensaje que queremos enviar (mismo contenido que tenemos en el Request1), debemos especificar los asertos.

Por defecto, y tal como se muestra en la última configuración del TestCase, ya nos incorpora una validación para comprobar que la respuesta obtenida cumple con el protocolo SOAP:

SoapUI: asertos

SoapUI: asertos

Hacemos clic sobre el icono “+” para incorporar un nuevo aserto de tipo Contains, que validará que la respuesta del servicio web contiene cierta información que se espera:

SoapUI: selección de asertos

SoapUI: selección de asertos

Como esta prueba contiene un mensaje HL7 válido, el contenido del campo HL7 MSA.1 de la respuesta debe tener el valor AA. Eso mismo indicamos en el contenido a validar en el aserto:

SoapUI: aserto de tipo contains

SoapUI: aserto de tipo contains

En este punto, ya tenemos completamente configurado nuestro primer TestCase.

De la misma forma, podemos crear un nuevo TestCase llamado Mensaje Inválido donde vamos a copiar el contenido del Request2 con un mensaje que no debe pasar la validación del servicio web. Para no sobrecargar demasiado más el artículo, omitiremos las capturas de pantalla de este proceso.

Para este TestCase también debemos añadir nuestros propios asertos. En primer lugar, para comprobar que el mensaje HL7 no es válido:

SoapUI: aserto para comprobar que el mensaje HL7 no es válido

SoapUI: aserto para comprobar que el mensaje HL7 no es válido

Y luego para validar por qué no:

SoapUI: aserto para validar por qué el mensaje HL7 no es válido

SoapUI: aserto para validar por qué el mensaje HL7 no es válido

 

5. Ejecutar el TestCase

En este punto, y con el servicio web de validación de mensajería desplegado a través de Mirth Connect, ya podemos lanzar nuestro TestCase, haciendo clic sobre el icono del “play verde”.

El resultado nos muestra que el servicio web se ha comportado como esperábamos:

SoapUI: resultado de ejecución del TestCase

SoapUI: resultado de ejecución del TestCase

Si realizamos un cambio en el servicio web que hace que uno de los asertos falle (por ejemplo, omitiendo el segmento HL7 ERR con la especificación del error en la validación), al ejecutar de nuevo el TestCase, obtendremos fracaso:

SoapUI: resultado de ejecución del TestCase

SoapUI: resultado de ejecución del TestCase

Conclusiones

Aquí concluye este artículo en el que hemos configurado una pequeña batería de pruebas en SoapUI para un servicio web de validación de mensajería HL7.

Esto puede darnos una idea de la facilidad de uso, flexibilidad y potencia de esta herramienta, que por algo es una de las más utilizadas en el testeo y validación de servicios web dentro de los entornos sanitarios.

Francisco J. CarrascoCómo usar SoapUI para crear una batería de tests para mensajes HL7 en 5 pasos

Entradas Relacionadas

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *