Configuración del sistema para el uso de TAST
Indice de la herramienta TAST
Adaptadores de TAST
Ejemplos de adaptadores
TAST Integraciones
Características de interés
Documentación de administración técnica
Recomendaciones para modelar
Formación en la herramienta TAST
This is an old revision of the document!
Este adaptador es utilizado para ejecutar pruebas de Servicios web: REST, SOAP y otros.
En el setup del adaptador deberemos incluir todos los datos que consideremos descriptivos del servicio en general y que apliquen a todas sus peticiones. De forma que el usuario no tenga que pasarlos en cada mensaje del diagrama. Como por ejemplo la url base del servicio, cabeceras o el método de autenticación.
Sería la parte de la URL que es común a todas las peticiones o solicitudes sobre ese servicio web, de forma que el usuario no tenga introducirla en cada mensaje que configure como petición al servicio.
Se entiende que la primera interacción que el adaptador deberá realizar con el servicio web será la de autenticación y autorización. Actualmente existen varios métodos estándar diferentes para realizar este paso y otros propietarios que yo dejaría para desarrollar bajo demanda, es decir si encontramos la necesidad.
Resaltar que no son métodos de autenticación-autorización propios de los servicios Web Rest, más bien están asociados al protocolo Http, con lo que el desarrollo debería orientarse a ser reutilizado por el adaptador GUI Html y el adaptador Webservices SOAP, si en el futuro se pretende acceder a alguna aplicación Web que emplee alguno de estos métodos para autenticarse-autorizarse,
Para administrar el authentication_type existe un campo de tipo combo, que contiene el tipo de la autenticación, que debe ser seleccionado por el usuario.
Pasamos a enumerarlas, hacer breve descripción de los mismos y pensar que parámetros podríamos necesitar.
https://en.wikipedia.org/wiki/Basic_access_authentication
- Usuario - Password Y como opcionales (se emplean valores por defecto si el usuario no los facilita) los siguientes: - Realm: Dominio de seguridad contra el que autenticarse. - Algorithm: Algoritmo de encriptación. MD5 o MD5-sess. - Nonce: Código que emite el servidor en la response cuando una request no es autorizada. Es único por sesión y se debe incluir en las siguientes peticiones. - Qop: Quality of protection, los posibles valores son auth (más comun) o auth-int (autorización con integridad) creo que menos soportado y utilizado. - Nonce Count: Número de petición realizada al servidor con el mismo nonce, su obligatoriedad depende del valor asignado a Qop . - Opaque: Es un valor retornado por el servidor en la primera response no autorizada, y se debe añadir sin modificar a todas las peticiones posteriores al servidor. https://en.wikipedia.org/wiki/Digest_access_authentication
En Postman se solicitan los siguiente parámetros: - ConsumerKey: Un valor empleado por el consumidor del servicio para identificarse ante el mismo. - ConsumerSecret: Token empleado por el consumidor para validar su propiedad sobre la ConsumerKey. - Access Token: Token de acceso. - Token Secret: Otra clave para asegurar la propiedad del token de acceso. Y como parámetros opcionales (valores por defecto si usuario no introduce): - Signature Method: El método de firma usado por el consumidor para firmar las peticiónes. - Timestamp: Se añade un timestamp a la petición. - Nonce: Cadena aleatoria generada por el cliente, se añadirá a todas las request. - Realm: Indica el dominio de seguridad que realiza la autenticación. https://es.wikipedia.org/wiki/OAuth
Postman solo pide el parámetro: - Access Token. Clave de acceso al servicio. Pero en la opción de solicitar un Access Token solicita datos para autenticarte contra el servicio que te va a dar la clave de acceso para esa operación. Además de estos métodos aparecen otros métodos de autenticación en Postman como: - Bearer Token. https://swagger.io/docs/specification/authentication/bearer-authentication/ - AWS Signature. Metodo propietario para autenticarse en web services en la plataforma de nube de Amazon. http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html - Hawk Authentication. Nuevo. https://www.drupal.org/project/hawk_auth Para implementar los diferentes métodos de autenticación en el Front se necesitaría que cuando el usuario seleccionara el método se mostraran unos parámetros u otros dinámicamente, y eso actualmente no está implementado. En principio entiendo que deberíamos ir agregando cada método en función de las prioridades del cliente por necesidad, aunque soportar Basic y Diggest son algo mínimo.
FUNCIONES PREDEFINIDAS Lista de Funciones Predefinidas para envío de peticiones al servidor provistas por el adaptador, y parámetros necesarios para su ejecución. En rest los tipos de peticiones se corresponden con los diferentes métodos/verbos contemplados en el protocolo HTTP. En principio existirá una función para formar una petición por cada método HTTP. Otro requisito es que se debe permitir emplear variables del diagrama, para componer los diferentes campos de la petición.
Los métodos existentes son:** - GET Se emplea para leer y recuperar la información de un recurso en el servidor.
Es probablemente el más sencillo de implementar ya que todos los datos más relevantes de la petición aparecen en la URL de la petición.
httpResponse=get(UrlBase, Recurso, List Headers, List Parameters)
UrlBase: Se obtendría de la inicialización del adaptador.
Recurso: El recurso que se quiere obtener.
List Headers: Una lista de cabeceras a agregar a la petición, de repetirse sobre escribirán los valores dados en el setup del adaptador.
List Parameters: Lista de parámetros a agregar a la URL de la petición en forma de clave=valor.
Ejemplo = 
Como hemos comentado las peticiones get se emplean para recuperar la información asociada a un recurso en el servidor, el tipo del recurso recuperado se informa en la cabecera media-type, podríamos recuperar información con formato Json, Xml, Html, Pdf, Word, Excel …
Uno de las cuestiones que debe responder la función es como va a reportar las evidencias de su correcta ejecución, más allá de incluir un mensaje en el log de la aplicación indicando si se ejecuto correctamente, debemos considerar la opción de generar un fichero de evidencias con el contenido de la respuesta.
Por ejemplo supongamos una petición get a la aplicación cuyo resultado en la propia aplicación es la descarga de un fichero Pdf o Excel, creo que al ejecutarla en Tast y recuperar el fichero deberíamos crearlo en el directorio de evidencias de la ejecución.
Esta es la pantalla sencilla en la que el usuario incluye las cabeceras y los header como un único String que será parseado por el adaptador para descomponerlo, se podría hacer otro diseño en que el usuario fuera añadiendo parámetros o cabeceras a voluntad. - POST Se emplea para crear un recurso en el servidor, con la información contenida en un formulario, o bien en un fichero Json, XML o de otro tipo. Es decir la forma en que se transmiten los datos en el cuerpo de la petición puede variar, y es necesario permitirle al usuario indicárnoslo de alguna forma para poder construir la petición. Es la cabecera content_type.
httpResponse=post(UrlBase, Recurso, List Headers, Content Type, Datos) En este caso los datos podrían venir representados en un fichero Json o XML que el usuario debería o poder subir a la aplicación o bien cortar y pegarlo en algún editor como en el caso de la Consultas o el código Javascript. En el caso de emplear formularios, los tipos X-WWW-FORM-URLENCODED o FORM-DATA los requisitos cambian y el usuario nos debería facilitar una serie de parámetros en forma de clave valor. Así como en algunos casos adjuntar ficheros a la petición.
Example: http://www.mkyong.com/java/how-to-send-http-request-getpost-in-java/ Con dos librerías diferentes.
- PUT Se emplea para actualizar la información relativa a un recurso en el servidor. Similar a post en requisitos.
httpResponse=put(“UrlBase, Recurso, List Headers, Content Type, Datos)
- DELETE Se emplea para eliminar un recurso en el servidor. httpResponse=delete(“https://#Banco/#Usuario/#Cuenta/saldo”)
- HEAD Similar a get, pero la response no contiene el body, los datos, solo contiene la cabecera. EL PROBLEMA DEL MANTENIMIENTO DE SESIÓN. Como sabéis Http es un protocolo de petición/respuesta sin estado, pero en algunas ocasiones los flujos de trabajo, obligan a que se relacionen varias peticiones como de un mismo cliente. Es decir mantener la sesión entre cliente y servidor durante todo el flujo de trabajo. Normalmente se realiza con cookies, aunque también se puede realizar mediante cabeceras. En todo caso esto es transparente para el usuario, pero el adaptador si debe tenerlo en cuenta, ya que debe almacenar la cookie enviada por el servidor en la primera petición para agregarla a las peticiones Http posteriores en el diagrama. O en otros casos mediante Tokens que son facilitados por el servidor después de autenticarte y que el cliente debe incluir en una cabecera en cada petición. Es posible que el usuario deba indicarnos si se debe mantener sesión durante el envío de varios mensajes consecutivos, y el mecanismo que el servidor emplea para ello. En SoapUi al crear un test case nos ofrece la posibilidad de marcar un chek-box que indica si queremos mantener la sesión, nada más no solicita más datos, entiendo que intenta mantenerla el de forma transparente para el usuario. EL PROBLEMA DE LA VALIDACIÓN DE RESPUESTAS. Hasta ahora hemos revisado los requisitos y los datos que debemos solicitar a un usuario para conseguir crear los diferentes tipos de peticiones HTTP que se emplean en un uso normal de un servicio Rest. Como el objetivo final de la aplicación es el Testing de esos servicios, debemos según entiendo ver cómo podemos analizar las respuestas http para validar si el resultado de la acción enviada al servidor fue el esperado. Propongo crear un “nuevo” tipo de dato complejo en Tast, al igual que se hizo con TastDataTable, sería un tipo que representaría una httpResponse, siendo original llamémoslo TastHttpResponse. Esta clase se encargaría de contener todos los datos relevantes de la respuesta recibida del servidor, y ofrecería una interfaz al ejecutor en forma de métodos para trabajar con ellos. Esa interfaz luego podría ser accesible como en el caso de TastTableData de dos formas, una creando funciones predefinidas en el adaptador que las invoquen o bien ser accedidas desde javaScript en los script que puede crear y ejecutar el usuario. Sin entrar en profundidad, por ejemplo el objeto TastHttpResponse encapsulara el código http de retorno. Ofreciendo la posibilidad de recuperarlo como variable con una función predefinida GetHttpStatus. Además debería ofrecer una interfaz que permita al usuario acceder y recuperar como lista o individualmente las cabeceras de la respuesta, con el objetivo de validar su contenido o su existencia. Sobre un servicio Rest la aplicación SOAPUI en su versión open source ofrece las siguientes validaciones, las mismas más o menos se pueden encontrar en la aplicación PostMan pero la forma en que se expone al usuario es con funciones javaScript predefinidas que actúan sobre la Response. Boolean resultado = AssertPropertyContains(HttpResponse, String valueParam, Boolean RegExp); Esta función devuelve true si el valor de cualquiera de las propiedades de la respuesta coincide con el valor pasado en el parámetro “valueParam”. El parámetro httpResponse se correspondería con el nombre de la variable de tipo httpResponse generada en mensajes anteriores del diagrama, si lo eliminamos podríamos establecer la convención de que el mensaje siempre aplica sobre la última httpResponse generada en el diagrama. El parámetro paramValue se corresponde con el valor a buscar. El parámetro RegExp es un booleano que indica si el valor introducido en el parámetro paramValue se corresponde con una expresión regular. Ejemplo:
Boolean resultado = AssertPropertyContains(httpResponse1, valueParam, RegExp);
O
Boolean resultado = AssertPropertyContains(valueParam, RegExp);
Boolean resultado = AssertPropertyNotContains(HttpResponse, string valueParam, boolean RegExp); Esta función devuelve true si el valor de ninguna de las propiedades de la respuesta no coincide con el valor pasado en el parámetro “valueParam”. El resto es similar a la función anterior, si queremos podemos fusionarlas agregando un parámetro que indique si buscamos si existe o si no. Boolean resultado = AssertPropertyXPathMatch(HttpResponse, String xPathExp, String CompareValue, Boolean RegExp); Esta función emplea una expresión XPATH para recuperar el valor contenido en el elemento indicado por la expresión XPATH y lo compara con el valor contenido en el parámetro CompareValue, dicho valor puede ser o no una expresión regular, lo que vendrá indicado por el parámetro RegExp. Esta función solo aplica cuando la respuesta recibida a la petición tiene formato XML. Boolean resultado = AssertPropertyXQueryMatch(HttpResponse, String xQueryExp, String CompareValue, Boolean RegExp) Esta función devuelve true, si el valor recuperado de la respuesta aplicando la expresión xQuery coincide con el valor incluido en el parámetro CompareValue, como en las anteriores si RegExp es igual a true se realiza la búsqueda tomando CompareValue como una expresión regular. Solo aplica si la respuesta tiene formato Xml. Boolean resultado = AssertPropertyJsonPathMatch(HttpResponse, String JsonPathExp, String CompareValue, boolean RegExp); Esta función devuelve true si el valor recuperado mediante la expresión JsonPath, se corresponde con el valor indicado en el parámetro CompareValue, como en los anteriores REgExp nos indica si debemos aplicar el valor como un patrón de RegExp. Esta función solo aplica cuando el formato de la respuesta es Json.
Integer resultado = AssertPropertyJsonPathCount(HttpResponse, string JsonPathExp); Esta función retorna el número de ocurrencias en la respuesta del elemento indicado por la expresión JSonPath, solo aplica a respuestas con formato JSon.
Boolean resultado = AssertHttpStatus(HttpResponse, HttpStatuscode, Equals ); La función nos permite comparar el código de retorno de una petición con un código de retorno introducido por el usuario en el parámetro HttpStatuscode, podemos buscar igualdad o desigualdad con el parámetro Equals, y devuelve true o false en función de si se cumple la condición o no. También podríamos implementar una función GetHttpStatusCode(), que devuelva el valor del código de retorno y que sea el usuario comparándolo en un combained fragment el que decida si es correcto o no. Boolean resultado = AssertSchemaCompliance(httpResponse); La función chequea si el mensaje de la respuesta cumple con el formato definido en el fichero WADL. En cuyo caso devuelve true, false en otro caso. Boolean AssertSLATime(httpResponse, timeInMilis); Esta función se puede emplear para validar el tiempo de respuesta de una petición, y comprobar si se encuentra dentro del acuerdo de nivel de servicio establecido para el mismo. Si la respuesta se recibió en igual o menor tiempo del indicado devolvería true, si es superior false. FUNCIONES DE RECUPERACIÓN DE DATOS DE LA RESPONSE. Las funciones anteriores están orientadas a realizar validaciones sobre la respuesta obtenida por la petición, pero todavía no hemos provisto al usuario con funciones que le permitan recuperar la información contenida en la respuesta. Como hemos indicado anteriormente algunas de estas funciones podrían ser: Integer Code = GetStatusCode(httpResponse). Retorna el código de retorno como variable al diagrama. Integer timeMilis = GetResponseTime(httpResponse). Retorna el tiempo empleado en procesar la solicitud. String headerValue = GetHeaderValue(httpResponse, String HeaderKey). Retorna el valor contenido en la cabecera indicada por el parámetro HeaderKey. String propertyValues = GetXPathPropertyValue(httpResponse, String XPathExp); Esta función retornaría el valor o lista de valores contenidos en los elementos de la respuesta que macheen con la expresión Xpath introducida como parámetro. Si existen varios elementos en el documento que cumplen la condición, se concatenarían todos los valores separados por algún carácter. Solo aplica cuando la respuesta tiene formato XML. String propertyValues = GetJSonPathPropertyValue(httpResponse, String JSonPathExp); Similar a la función anterior pero empleando el estándar JSonPath para navegar sobre los datos de la respuesta. Solo aplica a respuestas del tipo JSon. En principio iremos desarrollando más funciones de este tipo que permitan recuperar los datos de la respuesta e introducirlos como variables en el flujo de ejecución del diagrama, por si quieren ser empleados como valores de entrada a otros mensajes del diagrama.
