> For the complete documentation index, see [llms.txt](https://docs.airops.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.airops.com/docs/es/acciones/workflow-concepts/testing-and-iteration.md).
# Pruebas e iteración
Mejores prácticas para probar e iterar en tu flujo de trabajo
Las pruebas y la iteración son pasos fundamentales para crear un flujo de trabajo listo para producción. En esta sección, describiremos las mejores prácticas para probar e iterar en tu flujo de trabajo.
## Modo de prueba gratuito
AirOps proporciona **50.000 tareas de prueba gratuitas al mes** para pruebas en Studio. Puedes usar tareas de prueba para pruebas de Workflow y ejecuciones iniciadas desde el editor de Playbook.
{% hint style="info" %}
Las tareas de prueba están disponibles para todos los espacios de trabajo y son independientes de tu asignación de tareas de producción. Las pruebas de Workflow y las ejecuciones del editor de Playbook usan primero las tareas de prueba y luego usan tareas de producción después de agotar el saldo de tareas de prueba.
{% endhint %}
## Cómo probar tu flujo de trabajo
Hay dos formas de probar tu flujo de trabajo: paso a paso o todos los pasos a la vez.
Cuando pruebas un paso a la vez, el valor de cada paso se actualizará. **Cuando pruebas todos los pasos a la vez, los valores de cada paso solo se actualizarán si la ejecución tiene éxito. Sin embargo, los valores no se actualizarán si encuentras un error.** Como resultado, la mejor práctica es probar siempre un paso a la vez hasta que tu flujo de trabajo esté listo para producción
### Probar un paso
* **Comienza en el paso de inicio:** para comenzar a probar un flujo de trabajo, debes agregar valores al paso de inicio
* **Haz clic en la flecha del primer paso:** esto ejecutará solo el primer paso
* **Usa los registros para entender la salida del paso y poder referenciarla en pasos futuros:** los registros son fundamentales para entender la estructura de datos de la salida del paso: usa esta salida para ayudarte a referenciar este paso en pasos posteriores
* **Diseña el/los siguiente(s) paso(s):** continúa diseñando tu flujo de trabajo haciendo referencia a los pasos anteriores usando el botón rosa de ayuda de variables
* **Continúa probando cada paso posterior:** después de diseñar un paso, haz clic en el botón de reproducir para probar el paso. Continúa este proceso hasta que tengas un flujo de trabajo listo para producción
### Probar pasos en condicionales
Puedes depurar pasos individuales dentro de ramas condicionales (tanto las rutas verdaderas como falsas). Esto facilita probar e iterar sobre flujos de trabajo complejos con lógica de ramificación:
1. Navega hasta el paso condicional en tu flujo de trabajo
2. Expande la rama verdadera o falsa que quieras probar
3. Haz clic en el botón de reproducir en cualquier paso individual dentro de la rama
4. El paso se ejecutará usando los valores de prueba actuales, lo que te permitirá verificar la lógica en cada ruta
### Prueba tu flujo de trabajo completo
Hay **dos opciones para probar tu flujo de trabajo de extremo a extremo:**
Opción 1: Haz clic en "Prueba flujo de trabajo" desde el paso de Entradas
{% hint style="info" %}
Usa la **función Prueba flujo de trabajo** cuando tu flujo de trabajo esté listo
{% endhint %}
* **Haz clic en Prueba flujo de trabajo:** haz clic **función Prueba flujo de trabajo** en la esquina superior derecha
* **Ingresa tus valores de prueba:** añade los valores de prueba que quieres ejecutar
* **Ejecutar:** haz clic **Ejecutar** para probar todo el flujo de trabajo
## Mejores prácticas para el manejo de errores
Al crear un flujo de trabajo para producción, hay casos límite que debes probar y manejar en tu flujo de trabajo antes de ejecutarlo a escala. Además, recuerda que siempre puedes pedir ayuda de [Copilot para corregir errores](/docs/es/acciones/workflow-concepts/chat-with-copilot/fix-errors-with-copilot.md) que encuentres mientras pruebas.
### 1. Límite de ventana de contexto
Cada modelo LLM tiene una ventana máxima de contexto, lo que significa que hay un número máximo de tokens (o caracteres) que puedes tener en tu prompt antes de que falle.
{% hint style="info" %}
1 token generalmente corresponde a \~4 caracteres y \~3/4 de una palabra.
{% endhint %}
1. Para asegurarte de que tu prompt permanezca dentro del límite de la ventana de contexto, puedes aproximar la cantidad de tokens que usarás copiando y pegando tu prompt en el siguiente contador de tokens de OpenAI:
2. Para manejar casos límite en los que tu prompt supere el límite de tokens, puedes usar la siguiente sintaxis de Liquid para dividir tus entradas o salidas de paso en un fragmento más corto: `{{step_1.output | slice: 0, 10000}}`donde 10000 se reemplaza por el número de caracteres que quieres dividir.
### 2. Errores de formato del prompt
Muchos flujos de trabajo de producción de modelos de lenguaje grande dependen de un formato de salida consistente del modelo. Para garantizar la consistencia en tu flujo de trabajo, considera los siguientes métodos para manejar una salida inesperada del prompt:
1. **Técnicas de prompt:**
* Para evitar que el modelo introduzca su respuesta con una frase como "*Claro, aquí tienes un...*", puedes agregar un comando en ambos el **Sistema** y **Usuario** como "*Genera tu respuesta en el siguiente formato y no incluyas ningún comentario adicional:*"
* Si tu salida es HTML o JSON, para evitar que el modelo comience con ` ```html ` o ` ```json `, puedes decirle al modelo *"Empieza con #..."* o *"Empieza con {, y termina con } y no incluyas ` ```json ` en tu respuesta"*
2. **Análisis de código:**
* Si sigues teniendo problemas con una salida consistente, o quieres manejar casos extremos en los que pueda desviarse de la salida esperada, puedes usar código para extraer cualquier texto que preceda a tu primer carácter.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.airops.com/docs/es/acciones/workflow-concepts/testing-and-iteration.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
