Orquestar suite de pruebas

Después de crear una suite de pruebas, debe añadir contenido de prueba. Apidog proporciona modos flexibles "Estático" y "Dinámico" para satisfacer distintas necesidades de gestión de pruebas.

Importar contenido de prueba

En la página de detalles de la suite de pruebas, bajo la pestaña Orchestration, haga clic en + Add Endpoint Test Case o + Add Test Scenario. En la ventana emergente de selección, puede alternar entre el modo Static o Dynamic.

1. Modo estático

El modo estático se utiliza para especificar con precisión los elementos de prueba que se ejecutarán.

🎯 Lógica principal

El sistema registra los ID de los casos de prueba específicos que usted selecciona. Incluso si se añaden nuevos casos de prueba a la categoría de origen, el alcance de ejecución de esta suite no cambiará, lo que garantiza la controlabilidad de los resultados de la prueba.

🚀 Mejores escenarios de uso

Verificación de corrección de errores (Hotfix): Seleccione entre 3 y 5 casos de prueba estrechamente relacionados con el error, forme un "paquete de verificación" y verifique rápidamente el resultado de la corrección, sin perder tiempo ejecutando casos no relacionados.

Estabilización del negocio principal (Core Path): Para procesos extremadamente esenciales y estables, como "pedido-pago". No queremos que se activen alertas de supervisión porque una persona recién incorporada añadió accidentalmente un caso de prueba incompleto.

Pruebas de compatibilidad con versiones antiguas: Seleccione un lote de casos de prueba de endpoints antiguos específicamente para verificar la compatibilidad de clientes de versiones antiguas.

⚠️ Características de mantenimiento

Alto coste de mantenimiento: Si es necesario incluir nuevos casos en esta prueba especializada, deben añadirse manualmente.

2. Modo dinámico

El modo dinámico se utiliza para filtrar automáticamente, mediante reglas, los elementos de prueba que se ejecutarán.

🎯 Lógica principal

El sistema guarda "Reglas de filtro" (Scope & Filter). Cada vez que se ejecuta, el sistema escanea todo el proyecto en tiempo real e incluye en el plan de ejecución todos los casos más recientes que cumplen los criterios.

🚀 Mejores escenarios de uso

Prueba de regresión a nivel de módulo: Establezca la carpeta "Trading Center" como carpeta de origen. Los evaluadores solo necesitan escribir nuevos casos en la carpeta, y la suite los incluirá automáticamente al ejecutarse.

Prueba de humo: Cree una suite dinámica con la regla Priority = P0. Ejecútela antes de cada lanzamiento para cubrir automáticamente todos los casos clave marcados como P0.

Verificación de iteración de versión: Utilice la función de etiquetas, establezca la regla en Tag = v2.5.0. Una vez finalizado el desarrollo, ejecute esta suite para verificar todas las nuevas funciones de esta versión.

⚠️ Características de mantenimiento

Coste de mantenimiento cero: Una vez configuradas las reglas, no es necesario mantener posteriormente la suite en sí; solo deben mantenerse los atributos de los casos (ubicación, etiquetas, prioridad).

Ajustar el orden de ejecución

El contenido importado se mostrará en una lista, y usted puede arrastrar los elementos de la lista para ajustar el orden de ejecución.

Para los elementos añadidos "estáticamente", puede utilizar Edit para eliminar casos de prueba individualmente o eliminar todo el grupo.

Para los grupos añadidos "dinámicamente", solo puede eliminar todo el grupo o editar los criterios de filtro, y no puede eliminar elementos individuales dentro del grupo.

Configuración avanzada

En el lado derecho de la página de diseño de la suite de pruebas, puede expandir Advanced Config para tener un control más granular sobre cómo se ejecuta la suite de pruebas.

Entorno

Definición: De forma predeterminada, hereda el entorno de ejecución ya establecido en la suite de pruebas. Si se especifica un entorno aquí, esa configuración de entorno tendrá prioridad durante la ejecución.

Caso de uso: Adecuado para escenarios en los que necesita reutilizar el mismo conjunto de pasos de prueba en diferentes entornos.

Datos de prueba

Se utiliza para especificar si se deben usar datos de prueba durante la ejecución.

Sin datos de prueba: Los pasos de prueba se ejecutan solo una vez, sin ejecutar pruebas basadas en datos.

Usar datos de prueba: Ejecute varias veces en función de los datos de prueba; se usa comúnmente para pruebas parametrizadas.

En caso de error

Configure cómo debe gestionar la prueba los errores, que pueden incluir fallos de aserción, fallos de validación de formato de datos, excepciones de petición de endpoint, errores del servidor, etc.

Ignorar: Continúe ejecutando los pasos posteriores cuando se produzca un error, sin interrumpir la ejecución actual.

Continuar: Cuando se produzca un error, omita los pasos restantes de la ronda actual y pase directamente a la siguiente ronda de ejecución.

Finalizar ejecución: Termine inmediatamente los pasos posteriores en cuanto se produzca un error.

Iteraciones

Definición: El número de veces que cada hilo recorre todos los pasos.

Caso de uso: Se utiliza comúnmente para escenarios de verificación de estabilidad o pruebas de estrés simples.

Retraso

Definición: Establezca cuántos milisegundos (ms) se debe esperar después de que se complete cada paso de prueba antes de ejecutar el siguiente paso.

Caso de uso: Evita activar mecanismos de limitación de tasa o de disyuntor en el servidor de destino debido a una alta frecuencia de peticiones, lo que garantiza una ejecución fluida de la prueba.

Guardar peticiones/respuestas

Definición: Controle si el informe de prueba incluye datos detallados de peticiones y respuestas (como Header, Body, etc.).

Opciones:

Todo: Guarde los detalles completos de todos los pasos, independientemente de si se superaron o fallaron. Gran volumen de datos, adecuado para depuración profunda.

Solo fallidos: Guarde únicamente los detalles de los pasos que fallaron durante la ejecución. Recomendado; ahorra espacio de almacenamiento y facilita la identificación rápida de las razones del fallo.

No guardar: No guarde ningún detalle; registre únicamente el estado de aprobado/fallido y la duración.

Valores de variables de entorno/globales

Los valores de variables de entorno/globales especifican qué valores reales se deben usar para las variables de entorno/globales en este escenario de prueba. Hay dos opciones. La información detallada puede verse aquí. Al elegir usar valores de variables guardados en Runner, se le pedirá que seleccione adicionalmente el alcance de variables que se usará.

El propósito de este alcance es ayudar a los usuarios a separar mejor las variables según las necesidades reales, evitando situaciones en las que la ejecución de una tarea programada provoque que otras tareas fallen debido a cambios en las variables. Después de seleccionar el alcance, también puede ver los valores de las variables dentro de este alcance a través de la entrada que aparece en la interfaz del producto.

Alcance de variables en Runner	Leer/escribir variables de entorno/globales	Descripción
Compartir solo en el escenario de prueba actual	En el Runner especificado actual, este escenario de prueba tiene un archivo dedicado para almacenar de forma persistente sus variables de entorno/globales. Solo el escenario de prueba actual puede leer y escribir variables en este archivo.	El alcance de variables más pequeño, con un impacto mínimo. Adecuado para casos en los que los resultados de la ejecución anterior de este escenario de prueba deben usarse en la siguiente ejecución. Los archivos de variables para escenarios de prueba, tareas y carpetas de tareas se guardan todos en la ruta del contenedor de Runner `/opt/runner/variables`.
Compartir entre todos los escenarios de prueba de la tarea programada actual	En el Runner especificado actual, la tarea programada tiene un archivo para almacenar variables de entorno/globales que pueden usarse entre todos sus escenarios de prueba. Todos los escenarios de prueba de la tarea programada actual pueden leer y escribir variables en este archivo.	Un alcance de variables recomendado con impacto moderado. Adecuado para casos en los que es necesario compartir datos entre distintos escenarios de prueba dentro de la misma tarea programada.
Compartir entre todas las tareas programadas de la carpeta de tareas programadas actual	En el Runner especificado actual, la carpeta de tareas programadas tiene un archivo para almacenar variables de entorno/globales que pueden usarse entre todas sus tareas programadas y escenarios de prueba. Todos los escenarios de prueba de todas las tareas programadas dentro de la carpeta actual pueden leer y escribir variables en este archivo.	El alcance de variables más grande, con el impacto más significativo. Es posible que la ejecución de una determinada tarea programada modifique el valor de una variable, lo que provocaría el fallo de otras tareas programadas. Adecuado cuando es necesario compartir datos entre varias tareas de la misma carpeta.

Orquestar suite de pruebas

Importar contenido de prueba#

1. Modo estático#

2. Modo dinámico#

Ajustar el orden de ejecución#

Configuración avanzada#

Entorno#

Datos de prueba#

En caso de error#

Iteraciones#

Retraso#

Guardar peticiones/respuestas#

Valores de variables de entorno/globales#