Ejemplos: Pruebas

En esta sección se supone que los agentes de prueba (tantos como sean necesarios para las pruebas) se han creado de acuerdo con Creación e implementación de un nuevo agente de prueba.

Descripción general de la orquestación de pruebas

Antes de poder crear y ejecutar una prueba a través de la API de REST, debe tener una plantilla en la que basar la prueba definida en el Centro de control, como se explica en el capítulo Plantillas de prueba y monitoreo. A todos los parámetros especificados en esa plantilla como "Entrada de plantilla" se les deben asignar valores cuando se crea una prueba a partir de ella en la API de REST.

Creación y ejecución de una prueba

La plantilla que usaremos para nuestra prueba en este ejemplo es una plantilla de prueba HTTP.

Para inspeccionar esa plantilla a través de la API de REST, recuperamos una lista de todas las plantillas de prueba de la cuenta:

Si nuestra plantilla HTTP es la única plantilla de prueba definida, la respuesta se verá así:

La prueba HTTP en esta plantilla tiene dos requisitos que inputs deben definirse en tiempo de ejecución: clients (lista de interfaces del agente de prueba que desempeñan el papel de clientes) y url (la URL para obtener usando HTTP). Los nombres de los parámetros son los definidos como Nombre de variable en el Centro de control. Aquí, son simplemente versiones en minúsculas de los nombres para mostrar del Centro de control ("clientes" vs. "Clientes", etc.).

Si hay varias plantillas y desea inspeccionar una sola plantilla con un ID conocido, puede hacerlo de la siguiente manera:

Ahora creamos y ejecutamos la prueba HTTP usando la operación POST para las pruebas.

A continuación se muestra el código que proporciona la configuración de parámetros necesarios para una prueba basada en la plantilla de prueba HTTP. Dependiendo de la estructura de la plantilla, los detalles aquí variarán, por supuesto. Otro ejemplo con una plantilla de prueba un poco más compleja se encuentra en la sección Ejemplo con una plantilla de prueba diferente.

La ejecución de la prueba se muestra en el Centro de control:

El centro de control también responderá al comando de la API de REST con el ID de la prueba. En este ejemplo, el ID de prueba es 47:

El ID de la prueba también se puede encontrar en la URL de la prueba en la GUI web del Centro de control. En este ejemplo, esa URL es https://<host IP>/<account>/testing/47/.

Ejemplo con una plantilla de prueba diferente

Aquí hay otro ejemplo de una plantilla de prueba: una para UDP, tomando como entrada un servidor, una lista de clientes y un número de puerto UDP. En la GUI de Routing Active Testing, esta plantilla UDP tiene el siguiente aspecto:

Para proporcionar los insumos a esta plantilla, podemos usar el siguiente código. Aquí, hemos anulado el valor predeterminado de port. Si se mantiene el valor predeterminado (5000), la port sección se puede omitir de input_values.

Recuperación de los resultados de las pruebas

Para recuperar los resultados de una prueba, apunte al ID de prueba. Esto también obtiene la configuración completa de la prueba.

Los resultados básicos de la prueba consisten en un resultado aprobado / reprobado para cada paso de la prueba y para la prueba en su conjunto.

De forma predeterminada, para las pruebas en las que esto es relevante, los resultados de la prueba también incluyen métricas promediadas tomadas durante toda la duración de la prueba. Las métricas promedio se encuentran en tasks > streams > metrics_avg. Puede desactivar estas métricas promedio estableciendo with_metrics_avg en false en la cadena de consulta.

Opcionalmente, esta operación puede devolver métricas de datos detalladas (segundo a segundo) para cada tarea realizada por la prueba (nuevamente, para las pruebas que producen dichos datos). Esta característica se activa estableciendo with_detailed_metrics en true. De forma predeterminada, esta marca se establece en false. Las métricas de datos detalladas se encuentran en tasks > streams > metrics.

Hay otra configuración with_other_results que, si se establece en true, hace que se devuelvan resultados de pruebas adicionales para el tipo de tarea Path trace (rutas y eventos de reenrutamiento).

Ejemplo 1: Prueba TWAMP

Una prueba TWAMP es un ejemplo de una prueba que produce métricas continuamente.

A continuación se muestra el código Python para obtener los resultados de una prueba TWAMP:

El resultado tendrá un aspecto similar al siguiente:

Ejemplo 2: Prueba de reasignación de DSCP

Una prueba de reasignación DSCP es aquella que no produce métricas continuas, sino un único conjunto de resultados al final. No puede ejecutarse simultáneamente con nada más. El formato de la salida de esta prueba se indica a continuación. (El código de Python para recuperar los resultados de la prueba es el mismo, excepto por el ID de la prueba).

Generación de un informe en PDF sobre una prueba

Puede generar un informe en PDF sobre una prueba directamente desde la API de REST. El informe tiene el mismo formato que el generado desde la GUI del Centro de control.

De forma predeterminada, el informe cubre los últimos 15 minutos de la prueba. Puede especificar un intervalo de tiempo diferente si incluye los start parámetros y end en una cadena de consulta al final de la dirección URL. La hora se indica en UTC (ISO 8601) como se especifica en GTI-I RFC 3339.

Además, se pueden incluir las siguientes opciones en la cadena de consulta:

• worst_num: Para cada tarea de una prueba, puede especificar cuántos resultados de medición mostrar, clasificados por el número de segundos con errores con el peor en la parte superior. El alcance de un resultado de medición depende de la tarea; por poner un ejemplo, para HTTP es el resultado obtenido para un cliente. El número predeterminado es 30.
• graphs: Incluya gráficos en el informe.

Ejemplo: