Configure check points to check whether requests are successful - Performance Testing

Un código de estado HTTP exitoso no garantiza que la lógica de negocio sea correcta. Una API de inicio de sesión podría devolver 200 OK con un mensaje de "credenciales no válidas", o una API de pedidos podría tener éxito a nivel HTTP pero devolver un conjunto de resultados vacío. Los puntos de control le permiten definir criterios de aprobación o rechazo basados en el contenido real de la respuesta (códigos de estado, encabezados, texto del cuerpo y parámetros de salida) para que el informe de pruebas de estrés refleje los resultados reales del negocio y no solo el éxito a nivel HTTP.

Tipos de puntos de control

PTS admite cuatro tipos de puntos de control, cada uno valida una parte diferente de la respuesta de la API:

Tipo	Qué verifica	Uso típico
Status Code	Código de estado de la respuesta HTTP	Comprobar que la respuesta devuelva `2xx` o un código específico
Response Header	Valores de los encabezados de respuesta HTTP	Confirmar encabezados como `Content-Type` o `Cache-Control`
Response Body	Contenido en el cuerpo de la respuesta	Coincidir con texto esperado, campos JSON o patrones
Output Parameters	Valores de parámetros de salida extraídos	Validar valores dinámicos capturados de llamadas anteriores a la API

Cómo se evalúan los puntos de control

Defina uno o más puntos de control en la pestaña Check Point (Assertion) de un nodo de API en su escenario de pruebas de estrés.
Para cada solicitud durante la prueba, PTS evalúa todos los puntos de control con respecto a la respuesta.
Todos los puntos de control para una sola solicitud usan lógica AND; cada punto de control debe aprobarse para que la solicitud cuente como un éxito de negocio.
El monitoreo en tiempo real y el informe final de pruebas de estrés muestran si el negocio probado se ejecuta según lo esperado o si presenta errores. Puede determinar si continuar la prueba de estrés basándose en estos informes.

Checkpoint configuration interface

Resultados de los puntos de control en los informes

Después de configurar los puntos de control, las pruebas de estrés en tiempo real y sus informes indican si el negocio probado se ejecuta según lo esperado o si presenta errores. Utilice estos resultados para decidir si continúa la prueba de estrés.

Condiciones de verificación

Las condiciones disponibles para un punto de control dependen de si el valor de Content es numérico o no numérico.

Valores no numéricos

Si el valor de Content contiene caracteres no numéricos:

Condición	Comportamiento
Equal To	Coincidencia exacta
Not Equal To	No coincide exactamente
Contain	El contenido incluye la subcadena especificada
Not Contain	El contenido no incluye la subcadena especificada
Belong To	El contenido es miembro del conjunto especificado
Not Belong To	El contenido no es miembro del conjunto especificado
Exist	El objeto de verificación existe en la respuesta
Not Exist	El objeto de verificación no existe en la respuesta
Regular Expression	El contenido coincide con el patrón de expresión regular especificado

Valores numéricos

Si el valor de Content contiene solo dígitos, hay comparaciones numéricas adicionales disponibles:

Condición	Comportamiento
Greater Than	El valor es estrictamente mayor que el umbral
Greater Than or Equal To	El valor es mayor o igual al umbral
Equal To	El valor es exactamente igual al umbral
Less Than or Equal To	El valor es menor o igual al umbral
Less Than	El valor es estrictamente menor que el umbral
Belong To	El valor está dentro del conjunto o rango especificado
Not Belong To	El valor está fuera del conjunto o rango especificado
Exist	El objeto de verificación existe
Not Exist	El objeto de verificación no existe
Regular Expression	El valor coincide con el patrón de expresión regular especificado

Exist y Not Exist

Las condiciones Exist y Not Exist se aplican a todos los tipos de datos. Solo verifican si el objeto objetivo existe en la respuesta, sin evaluar el valor real.

Expresiones de conjunto y rango para Belong To y Not Belong To

Las condiciones Belong To y Not Belong To aceptan enteros positivos, enteros negativos, 0 y cadenas. Use notación matemática estándar para definir rangos y conjuntos.

Tipo de expresión	Sintaxis	Ejemplo	Con qué coincide
Intervalo cerrado	`[min,max]`	`[-20,20]`	Cualquier entero de -20 a 20, inclusive
Conjunto con rangos	`{elements}`	`{[-200,200],-1,2}`	-1, 2 y cualquier entero en el rango [-200, 200]
Conjunto de cadenas	`{"str1","str2"}`	`{"abc","bcd","200","-200","Registered","Signed Up"}`	Cualquier cadena que coincida exactamente con un miembro del conjunto

Nota

Si un conjunto no incluye un entero negativo, puede escribirlo como una expresión de intervalo cerrado. Sin embargo, use una expresión de conjunto para mayor claridad. Por ejemplo, [200-300,1] coincide con el entero 1 y todos los enteros en el intervalo cerrado de 200 a 300.

Directrices de sintaxis de expresiones

Cuando utilice Belong To o Not Belong To con números negativos y rangos combinados, use siempre notación de conjunto ({...}) para evitar ambigüedades con el signo menos.

Ejemplo: validar una cookie y un código de estado

Suponga que la prueba se aprueba solo cuando se cumplen ambas condiciones siguientes:

El parámetro de salida export_cookie contiene información del sandbox.
El código de estado de la respuesta cae en el rango de 200 a 399.

Paso 1: Definir el parámetro de salida

En la pestaña Output Parameter Definition del nodo de API objetivo, configure el parámetro de salida export_cookie.

Output parameter definition configuration

Paso 2: Configurar puntos de control

En la pestaña Check Point (Assertion) del mismo nodo de API, agregue dos puntos de control:

Un punto de control de Output Parameters que verifique que export_cookie contenga el valor esperado del sandbox.
Un punto de control de Status Code que verifique que el código de respuesta pertenezca al rango [200,399].

Checkpoint assertion configuration

Dado que los puntos de control usan lógica AND, ambas condiciones deben cumplirse para que la solicitud cuente como un éxito de negocio.