Test samtaleagenter ved hjælp af Direct Line

Direct Line API fungerer som en kommunikationsgrænseflade for klientprogrammer til at interagere med samtaleagenter, der er bygget med Copilot Studio. API'en Direct Line gør det lettere at sende meddelelser mellem klientprogrammet og agenten via enten WebSocket-streams eller HTTP-anmodninger. I forbindelse med test af ydeevne aktiverer Direct Line værktøjer til belastningstest for at replikere den faktiske brugeradfærd, generere indlæsnings- og målingssvartider.

Kommuniker med Direct Line ved hjælp af WebSockets

Du kan udrulle samtaleagenter, der er bygget med Copilot Studio til webprogrammer, enten som embedded iframes eller ved hjælp af et brugerdefineret lærred. Begge udrulningsindstillinger bruger WebSocket-kommunikation med Direct Line. Hvis du deployerer din samtaleagent til en app ved hjælp af en af disse metoder, bør dit performance test-script bruge WebSocket-kommunikation til at generere belastning, der ligner reel brugeradfærd, og måle ydeevnen med høj grad af sikkerhed.

Klientprogrammer, der bruger Direct Line og WebSocket-kommunikation, skal følge dette flow:

1. For at starte en samtale skal en klientapplikation først indhente et samtaletoken. Hvis din agent er konfigureret med en Direct Line secret, skal du hente et token ved at kalde Direct Line regionale slutpunkt. Tokens for agenter, der ikke bruger hemmeligheder, kan opnås fra token-endpointet.
2. Klientapplikationen starter en samtale ved at bruge tokenet og modtager et Conversation ID og en WebSocket-strøm-URL.
3. Brugerbeskeder sendes ved at sende en HTTP POST-anmodning med Conversation ID.
4. Beskeder fra samtaleagenten modtages over WebSocket-strømmen.

Kommuniker med Direct Line ved hjælp af HTTP GET

Hvis dit load testing-værktøj ikke kan bruge WebSocket-kommunikation, eller hvis din klientorienterede applikation ikke bruger WebSocket-kommunikation, kan du modtage aktiviteter ved at sende HTTP GET i stedet. Som vist i det følgende diagram ændrer samtaleinitieringsflowet sig ikke.

Mål responstider

For at vurdere, hvordan belastningen påvirker brugeroplevelsen, skal du sikre, at dine performance-testscripts følger og rapporterer responstiden for følgende trin:

Sporing af responstider for Generer Token, Start Samtale og Send Aktivitet er ligetil for loadtest-værktøjer, da disse trin bruger standard HTTP-forespørgsler. Dog er det mere komplekst at måle den tid, det tager en agent at svare på brugerbeskeder, af følgende årsager:

• Afsendelse og modtagelse af aktiviteter over Direct Line følger et asynkront mønster. Når en brugerbesked sendes ved hjælp af en Send Activity-anmodning, er svaret ikke en besked fra agenten. I stedet bekræfter den blot, at brugerbeskeden er korrekt postet.

• Baseret på dets design kan en samtaleagent sende et vilkårligt antal beskeder tilbage som svar på en brugerbesked. Derfor bør du i de fleste tilfælde måle den tid, det tager en agent at svare, som den tid, der går mellem en brugerbesked og den sidste agentbesked. I det følgende eksempel udløser en enkelt brugerbesked tre agentbeskeder, med API-kald kørende imellem. Hver besked tager cirka to sekunder at komme tilbage; Men set fra brugerens perspektiv tager det agenten seks sekunder at svare på brugerens anmodning.

  

Identificer agentens sidste svar

For at måle den tid, det tager en agent at færdiggøre sine svar, skal dit performance testing-script:

• Identificer den sidste agentbesked, der følger efter en brugerbesked
• Beregn tidsforskellen mellem de to

Den underliggende protokol, som Copilot Studio bruger, har ikke begrebet 'sidste svar', da både agenter og brugere kan sende meddelelser på et givent tidspunkt. Derfor skal dit performance-test-script antage, at hvis agenten ikke sender en besked inden for en given tidsramme, sendes der ikke flere beskeder, før næste brugerbesked er sendt. Implementeringen af denne logik varierer afhængigt af, hvordan dit script kommunikerer med Direct Line.

Brug WebSockets

Når du kommunikerer med Direct Line via WebSockets, skal du antage, at agenten ikke sender flere meddelelser, når der ikke kan læses flere rammer fra WebSocket. Du kan se dette indikeret med en timeout, når du forsøger at læse næste frame, selvom den præcise adfærd afhænger af din implementering. For en referenceimplementering, der bruger WebSockets, overvej at bruge HTTP GET.

Brug HTTP GET

Performance-testscripts, der bruger HTTP GET i stedet for WebSockets, bør polle Activities-endpointet for at hente hele sættet af bruger- og agentbeskeder. Når du laver en afstemning, skal du sørge for at give din mægler tilstrækkelig tid til at svare. For eksempel, hvis din agent skal kalde et backend-API for at svare på en brugerforespørgsel, og API'en tager op til fem sekunder om at svare, bør dit script ikke spørge Activities-endpointet, før der er gået fem sekunder.

Følgende forenklede nyttelast repræsenterer responsen, der kommer tilbage fra Aktiviteter-endpointet:

[
  {
    "type": "message",
    "id": "98SryQaHr2rGthOGpChPK2-us|0000012",
    "timestamp": "2025-01-07T09:12:22.0329242Z",
    "from": {
      "id": "a688eb7d-092a-42a8-8ef5-73123b9c2aaa",
      "name": ""
    },
    "conversation": {
      "id": "98SryQaHr2rGthOGpChPK2-us"
    },
    "text": "I also want to set up a new account",
  },
  {
    "type": "message",
    "id": "98SryQaHr2rGthOGpChPK2-us|0000017",
    "timestamp": "2025-01-07T09:12:24.5478686Z",
    "from": {
      "id": "4b56bfa5-5574-5bb3-7aa3-99b8798b9d90",
      "name": "Load Testing",
      "role": "bot"
    },
    "conversation": {
      "id": "98SryQaHr2rGthOGpChPK2-us"
    },
    "text": "Sure, please bear with me as I set up your new account",
    "replyToId": "98SryQaHr2rGthOGpChPK2-us|0000012",
  },
  {
    "type": "message",
    "id": "98SryQaHr2rGthOGpChPK2-us|0000018",
    "timestamp": "2025-01-07T09:12:33.1960413Z",
    "from": {
      "id": "4b56bfa5-5574-5bb3-7aa3-99b8798b9d90",
      "name": "Load Testing",
      "role": "bot"
    },
    "conversation": {
      "id": "98SryQaHr2rGthOGpChPK2-us"
    },
    "text": "Almost done! Thank you for your patience",
    "replyToId": "98SryQaHr2rGthOGpChPK2-us|0000012",
  },
  {
    "type": "message",
    "id": "98SryQaHr2rGthOGpChPK2-us|0000019",
    "timestamp": "2025-01-07T09:12:41.9166159Z",
    "from": {
      "id": "4b56bfa5-5574-5bb3-7aa3-99b8798b9d90",
      "name": "Load Testing",
      "role": "bot"
    },
    "conversation": {
      "id": "98SryQaHr2rGthOGpChPK2-us"
    },
    "text": "All done! Your new account is now active.",
    "inputHint": "acceptingInput",
    "replyToId": "98SryQaHr2rGthOGpChPK2-us|0000012"
  }
]

Når du analyserer nyttelasten og beregner svartider, skal du overveje følgende retningslinjer:

• Beskeder fra agenten har egenskaben role: bot, mens beskeder fra brugeren ikke har nogen role egenskab.
• Agentbeskeder, der sendes som svar på brugerbeskeder, har egenskaben replyToId, som har værdien af egenskaben id for brugerbeskeden.
• Du kan beregne agentens svartider som tidsforskellen mellem brugerbeskeden og den sidste agentbesked, der svarer på brugerbeskeden.