Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Los agentes conversacionales construidos con Copilot Studio funcionan en una plataforma que escala automáticamente para soportar el aumento de la demanda y la carga. Sin embargo, los agentes conversacionales suelen usar lógica personalizada o llamadas a APIs de backend, lo que introduce latencia porque la lógica personalizada es ineficiente o las APIs subyacentes y los sistemas backend no escalan bien.
Las pruebas de rendimiento evalúan el rendimiento y la estabilidad de un agente bajo diferentes patrones de carga. Identifica posibles problemas a medida que crece la base de usuarios, asegurando que el agente siga siendo funcional y receptivo. Si no pruebas tu agente conversacional bajo carga, puede funcionar bien durante el desarrollo y las pruebas, pero fallar bajo tráfico real de usuarios.
Antes de abordar los aspectos técnicos de las pruebas de rendimiento, define criterios de aceptación que capturen la experiencia de usuario deseada e identifica casos de uso conversacionales que generen patrones de carga distintos. Este artículo cubre brevemente la fase de planificación de las pruebas de rendimiento y ofrece orientación sobre los detalles técnicos de la generación de carga para tus agentes conversacionales.
Planifica tu prueba de rendimiento
Un plan de prueba de rendimiento debe tener un objetivo definido y criterios específicos de aceptación. Por ejemplo, algunas pruebas miden el rendimiento de un sistema bajo carga estándar, mientras que otras generan un estrés más extremo que provoca intencionadamente que el sistema se vuelve no responsivo. Al medir el rendimiento de agentes conversacionales construidos con Copilot Studio, diseña pruebas para medir tanto el rendimiento base del agente como la carga pesada prevista, pero no configures pruebas para generar un estrés excesivo.
Advertencia
Una carga generada que supera el comportamiento esperado del usuario puede provocar un exceso de consumo de mensajes y una limitación no deseada de los entornos. Para evitar limitaciones y excesos de consumo, asegúrate de que:
- Tus pruebas imitan un comportamiento realista del usuario.
- Tu inquilino y los entornos tienen suficientes licencias y políticas de facturación asignadas.
Comprender el comportamiento del usuario
Comienza tu plan de prueba analizando cómo se espera que se comporten los usuarios en diferentes casos de uso conversacionales. Desde la perspectiva de las pruebas de carga, el comportamiento del usuario puede variar entre casos de uso en cuanto a lo que dicen o preguntan (por ejemplo, "Quiero reservar un vuelo" o "¿Cuál es tu política de devoluciones?"), el número de usuarios que impulsa un caso de uso concreto y los patrones de interacción de los usuarios (por ejemplo, usuarios conectándose todos a la vez al mediodía frente a una acumulación gradual a lo largo del día).
La siguiente tabla describe el comportamiento esperado de un usuario para un agente conversacional bancario.
| Caso de uso | Enunciados de usuarios comunes | Patrón de enfrentamiento |
|---|---|---|
| Solicitud de préstamo | Necesito un nuevo préstamo , me gustaría solicitar un nuevo préstamo ... |
1.000 usuarios concurrentes de media a lo largo del día |
| Consulta de saldo | ¿Cuál es el saldo de mi cuenta? Muestra el saldo de mi cuenta... |
10.000 usuarios simultáneos, todos conectados alrededor del mediodía |
| Casos de uso adicionales | … | … |
Creación de un plan de pruebas
Después de definir el comportamiento del usuario en términos de casos de uso y patrones de interacción, piensa en los detalles de tu plan de pruebas de rendimiento. Como mínimo, un plan de prueba de rendimiento para un agente conversacional debe especificar un objetivo, escenarios de prueba, indicadores clave de rendimiento, datos detallados de pruebas y criterios de éxito.
Si tu equipo ya ha definido escenarios conversacionales para evaluaciones, ya sea creando casos de prueba dentro del producto o usando el kit Copilot Studio, puedes reutilizar estos escenarios para empezar a crear tu plan de prueba.
El siguiente ejemplo de plan de prueba es para un agente de conversación bancaria. El plan utiliza los casos de uso conversacionales previamente identificados para definir un escenario de prueba base y un escenario de pruebas de carga. Probar la línea base evalúa el rendimiento normal, identificando problemas durante el uso habitual, mientras que una mayor carga puede revelar cómo el sistema gestiona la actividad máxima de los usuarios.
| Section | Detalles |
|---|---|
| Objective | Evalúa el rendimiento del agente conversacional bancario bajo condiciones de referencia y de carga. |
| Ámbito |
En alcance: pruebas de línea base y de carga. Fuera de alcance: pruebas de estrés. |
| Indicadores clave de rendimiento (KPI) |
|
| Escenarios de prueba |
Pruebas de referencia
|
| Datos de prueba |
|
| Tools |
|
| Criterios de éxito |
|
Trabaja con partes interesadas técnicas y empresariales para desarrollar un plan de pruebas que se adapte a las necesidades de tu organización. Acordaos en los parámetros clave descritos en el ejemplo. Aprende sobre el uso de herramientas como Apache JMeter para crear scripts de prueba en ejemplos de referencia de pruebas de rendimiento y guías.
Simular conversaciones de varios turnos
Los datos de prueba especificados en el plan implican que la prueba de rendimiento planificada impulsa conversaciones de múltiples vueltas. Las conversaciones de varios turnos son una serie de mensajes de ida y vuelta enviados entre los usuarios simulados y el agente conversacional. Las pruebas de rendimiento deberían impulsar conversaciones de varios turnos para que la carga generada se asemeje al comportamiento real del usuario. Además, algunas acciones o llamadas a API de larga duración solo se activan cuando los usuarios toman una serie específica de decisiones o envían un patrón específico de mensajes dentro de una conversación.
En el siguiente ejemplo, la API de backend del banco solo se activa después de que el usuario selecciona la cuenta de ahorros. El tiempo de respuesta para el primer mensaje es inferior a un segundo porque solo está involucrado el motor de reconocimiento de intención del agente. El último mensaje espera una respuesta de una API de backend, lo que introduce latencia adicional. Sin simular una conversación de varios turnos, no habrían surgido problemas de rendimiento.
Simular conversaciones de varios turnos requiere planificar tanto cuando preparas datos de prueba como cuando construyes scripts de prueba. Incluye una serie de enunciados de usuario en tus datos de prueba que invoquen flujos conversacionales completos, como se muestra en el ejemplo. Asegúrate de que tus scripts de prueba envíen múltiples enunciados en una sola conversación.