Ejemplo de Pruebas Automáticas

<< Clic para mostrar Tabla de Contenidos >>

Navegación:  Automatización de Procesos con poco código > Studio Cloud -ambiente de autoría > Bizagi Studio > Pruebas Automáticas > Utilizar las Pruebas automáticas >

Ejemplo de Pruebas Automáticas

Introducción

La herramienta de Pruebas automáticas es un kit de recursos diseñado para probar los procesos de Bizagi de una manera automática en un ambiente de desarrollo o de pruebas, de manera que se valide que los diferentes caminos del flujo de proceso se comporten como se espera.

Para información básica sobre esta funcionalidad, consulte Pruebas automáticas.

 

Esta sección ilustra cómo ejecutar e interpretar los resultados al llevar a cabo pruebas automáticas de un escenario.

 

Antes de comenzar

Este ejemplo se enfoca en la grabación y ejecución de un escenario, para interpretar sus resultados y log.

Por lo tanto, el punto de inicio de este ejemplo es tener previamente configurada la herramienta (principalmente no se enfatizaá en la configuración porque ella depende de los parámetros en su ambiente).

 

Lo que debe hacer

Al llevar a cabo este ejemplo, estos son los pasos considerados:

 

1. Grabar el escenario

La grabación del escenario considera 2 tareas, y el uso de un único usuario (domain\admon).

 

2. Modificar el escenario

Las modificaciones se realiza con el fin de introducir participantes diferentes para cada una de las tareas.

 

3. Ejecutar el escenario

Se ejecutará el escenario un número predeterminado de veces.

 

Ejemplo

El proceso de este ejemplo es una simplificación genérica de un proceso que involucre solicitudes y aprobación de la misma.

La siguiente imagen ilustra las actividades y participantes de dicho proceso llamado My process:

 

Autotesting_example1

 

El ejemplo utilizado para este propósito es proceso sencillo, donde existe un usuario solicitante (requester) que inicia una nueva instancia.

Al llenar los campos y detalle de la solicitud, otro usuario queda encargado de revisarla (approver), ya sea para aprobarla, rechazarla o enviarla de vuelta dado que se necesiten cambios .

Lo que sucede después de ese punto no es relevante dado que para este ejemplo, se considera el final de la grabación (hasta cuando el encargado de revisar la solicitud da clic en Siguiente).

 

1. Grabar el escenario

Para grabar el escenario, ejecutamos la herramienta y damos clic en Grabar un escenario (Record scenario).

 

Autotesting_example2

 

Una vez que el servicio de grabación se inicie, ingresamos al portal con el usuario domain\admon.

 

Autotesting_example3

 

Iniciamos un nuevo caso del proceso My process y trabajamos en la primera tarea.

 

Autotesting_example4

 

Nótese que la primera tarea se llama Submit request (Registrar solicitud), y que estaremos utilizando una fecha (Request date) asignada a 15/12/2016, Los comentarios de la solicitud (Request comments) es especificarán como "Need these ASAP", y se ingresan 2 ítems dentro de la tabla colección: un portátil (con código LAPTOP) y un proyecto de video (con código VIDEOB).

 

Autotesting_example5

 

Una vez que se complete esta tarea (al dar clic en Siguiente), se activa la segunda tarea llamada Approve request (Aprobar solicitud).

Ingresamos la siguiente información:

Aprobado? (Approved?) igual a Si (Approved).

Comentarios de revisión (Review comments) especificados como "None".

 

Damos clic en Siguiente.

 

Autotesting_example6

 

Finalmente, damos clic en Finalizar (Stop) para detener y guardar la grabación.

 

Autotesting_example7

 

Nuestro archivo del escenario de prueba guardado se llama TestScenario_20161109_153951.test.

 

Autotesting_example8

 

Si ubicamos el log de este escenario (de acuerdo a la fecha de registro de la grabación), podemos ver detalles como el identificador del caso creado:

 

Autotesting_example9

 

Nótese que otros datos adicionales también se pueden visualizar junto con otra metadata:

 

Autotesting_example10

 

2. Modificar el escenario

Para poder incluir participantes en el escenario grabado, cargamos el escenario guardado utilizando la opción Load scenario y ubicando el archivo de prueba.

 

Autotesting_example11

 

Una vez que cargue, navegue hacia la pestaña de tareas (Tasks) y edite los usuarios asignados.

 

Autotesting_example12

 

Nótese que puede verificar el nombre exacto de los usuarios (userName y Domain, con sensibilidad a mayúsculas o minúsculas) a través de la opción de inicio rápido:

 

Autotesting_example13

 

Al finalizar, dé clic en Guardar (Save) y nombre el escenario modificado.

 

Autotesting_example14

 

3. Ejecutar el escenario

Asegúrese de cargar el escenario modificado anteriormente dando clic en Cargar escenario (Load scenario), de manera que pueda verificar que la configuración de dicho escenario es la esperada de acuerdo a los cambios en los participantes.

 

Autotesting_example15

 

Dé clic en opciones (Options) y defina cómo ejecutar este escenario en particular:

 

Autotesting_example16

 

Nótese que para este ejemplo, vamos a ejecutar la prueba repitiéndola 50 veces en un mismo hilo.

Dé clic en Cerrar (Close) y luego en ejecutar (Run).

 

Autotesting_example17

 

Al finalizar, el panel de abajo enseñará un mensaje acerca de la finalización de la prueba (TEST RUN FINISHED); en este punto podrá cerrar la herramienta y revisar los logs de ejecución.

 

Interpretar los resultados

El escenario ejecutado producirá un log identificable como TestRunLog_[timestamp].log:

 

Autotesting_example18

 

Nótese que la segunda línea de este log contiene información útil sobre la ejecución del escenario, acerca de la máquina cliente donde se ejecutó la herramienta.

Presenta información por ejemplo acerca del nombre de la máquina, su número de procesadores, el usuario de Windows empleado, y el sistema operativo Windows junto con el framework de, .NET, entre otros.

 

Seguidamente, también encontrará ocurrencias de cada una de las solicitudes realizadas en el escenario (recuerde que un único caso o única actividad de por si podrá involucrar más de una solicitud tipo HTTP request), junto con mensajes informativos.

Tomando como ejemplo la línea #19, usted podrá identificar el registro del tiempo (timestamp) cuando fue procesado, junto con el identificador del caso, y también de manera importante si hubo error o no, entre otros.

 

Recuerde que también podrá escoger almacenar los logs de ejecución como archivos csv, en cuyo caso necesitará cambiar el parámetro AutoTesting.Log.Type dentro de la configuración del archivo XML,y finalmente renombrar el archivo .log como uno .csv (para que por ejemplo se abra directamente por Excel):

 

Autotesting_example19

 

Nótese que se obtiene información similar a la presentada en el formato plano (junto a duración -duration-, escenario actual -current scenario-, etc) en el formato csv pero bajo un orden diferente.

 

Autotesting_example20

 

Junto con esta información, usted encontrará detalles como se describe en la tabla a continuación.

 

COLUMNA

DESCRIPCIÓN

Level

El tipo de mensaje que indica si esa línea en particular es informativa o contiene detalle de error.

Context

Provee información contextualizada sobre la ejecución de manera que se conozca si las lineas especificas pertenecen a una solicitud.

Element

El objeto padre al que el contexto anterior hace referencia.

Description

Detalle adicional a nivel descriptivo.

CurrentThread

El número de hilos ejecutándo esa línea en particular.

StartTime

El registro de tiempo o timestamp al que hace referencia el inicio de procesamiento de esa línea.

Duration

El tiempo total bajo un formato tipo HH:mm:ss donde se incluyen milisegundos.

Loops

El número de repeticiones (aplicables al escenario, según se haya definido en las opciones de la herramienta).

Threads

El número de hilos, según se haya definido en las opciones de la herramienta.

Errors

Detalle del error, cuando sea aplicable.

Name

Nombre del escenario (aplicable a líneas de log del escenario).

RequestCount

Número de solicitudes totales que contiene un escenario (aplicable a líneas de log del escenario).

Host

URL del proyecto (aplicable a líneas de log del escenario).

ParentScenario

El escenario previo encadenado (aplicable cuando se ha grabado utilizando la opción de grabar basado en escenario existente).

TaskName

El nombre de la tarea donde se realiza la solicitud tipo HTTP.

Action

El nombre de la acción de Bizagi que describe el objetivo general de la solicitud tipo HTTP.

Verb

Define si la acción es un POST, GET, PUT o DELETE.

URL

URL específica (el sufijo) del servicio REST donde se realiza la solicitud tipo HTTP.

Params

Parámetros adicionales del servicio REST específico.

 

En este punto usted habrá ejecutado las pruebas automáticas para su escenario, y podrá asegurarse de que sus diferentes flujos del proceso se encuentren libres de errores o podrá inspeccionar de cerca la duración promedio de las solicitudes (a nivel de cada HTTP request) en caso de necesitar adecuar su implementación en términos de rendimiento.


Last Updated 10/6/2023 5:21:38 PM