Best Practices für Tests (Dialogflow)

Die Entwicklung einer Aktion für die Actions on Google-Plattform umfasst oft Dialogflow für sein Natural Language Understanding implementieren (NLU) und die Dialogflow-Auftragsausführung, die die Logik für deine Aktion verarbeitet. Mit Tests in Ihrer Codebasis können Sie sicherstellen, dass Ihre Aktion wie erwartet funktioniert. in der Produktion.

Wenn du Einheiten-, Integrations- oder End-to-End-Tests für deine Aktion implementierst, sollten den Dialogflow-Agent und die Auftragsausführung als separate Komponenten betrachten.

Abbildung 1. Flussdiagramm, das die für Tests zu berücksichtigenden Systeme beschreibt

Achtung :Auf dieser Seite geht es hauptsächlich um die Aktionsentwicklung mit Dialogflow. Obwohl einige der vorgestellten Testkonzepte auch für Entwicklerinnen und Entwickler Actions SDK verwenden, gibt es inhärente Unterschiede zwischen den beiden Systemen. Entwickler, die mit dem Actions SDK arbeiten, müssen überlegen, wie sie ihre benutzerdefinierte NLU-Lösung erstellen, da sich die Integration erheblich vom Dialogflow-Agent-Komponente.

Dialogflow-Agent testen

Der Dialogflow-Agent und die Auftragsausführung werden als separate Komponenten getestet. Die In den folgenden Unterabschnitten wird beschrieben, wie Sie Dialogflow für deine Aktion.

Dialogflow als Query-in- und Intent-out-System

Ihr Dialogflow-Agent ist dafür verantwortlich, die Abfrage eines Nutzers Intent und extrahiert vordefinierte Entitäten aus der Abfrage. Mein Agent mit der Auftragsausführung interagiert, indem eine Nachricht mit den übereinstimmenden Intent, seine Parameter und Actions on Google-Metadaten.

Als Entwickler steuern Sie die Konfiguration des Dialogflow-Agents, z. B. die Struktur von Intents und Entitäten. Die Metadaten von Actions on Google Actions on Google. Es kann davon ausgegangen werden, dass sie die richtigen Daten für Tests enthalten.

Konzentrieren Sie sich beim Testen darauf, dass der Agent in der Lage ist, Intents korrekt zu extrahieren. und Abgleichen von Abfragen mit Intents. Dieser Ansatz bietet eine quantifizierbaren Messwert zur Bewertung der Leistung des Agents. Sie können berechnen Sie diesen Messwert, indem Sie einzelne Testfälle oder eine Validierungs-Dataset.

Abbildung 2: Darstellung von Dialogflow als Query-in- und Intent-out-System

Einheitentests

Für den Dialogflow-Agent können Sie Tests schreiben, bei denen für jeden Fall eine Textnachricht erwartet wird. Abfrage als Eingabe und generiert Intent-Metadaten als Ausgabe. Diese Metadaten sollte (mindestens) den Namen des zugeordneten Intents und eine Liste der übereinstimmenden Parameter.

Der Endpunkt detectIntent der Dialogflow API nimmt die Textabfrage als Eingabe und erzeugt eine strukturierte Ausgabe, die Name des aufgelösten Intents und der extrahierten Parameter. Diese Ausgabe ist hilfreich um die Leistung des Agents für den Intent-Abgleich zu bewerten. Eine vollständige Weitere nützliche Felder finden Sie in der Referenz zu QueryResult.

Ein Beispieltest sieht so aus:

it('choose_fact', async function() {
  // The `dialogflow` variable is an abstraction around the API that creates
  // and sends payloads to Dialogflow.
  const resJson = await dialogflow.detectIntent(
    'Tell me about the history of Google');
  expect(resJson.queryResult).to.include.deep.keys('parameters');
  // Check that Dialogflow extracted required entities from the query.
  expect(resJson.queryResult.parameters).to.deep.equal({
    'category': 'history',
    // Put any other parameters you wish were extracted
  });
  expect(resJson.queryResult.intent.displayName).to.equal('choose_fact');
});

In diesem Snippet werden Mocha und Chai verwendet. Alle ansehen Arbeitsbeispiel des in Node.js geschriebenen Dialogflow-Unittests für Fakten über Google

Ihre Testdateien können parallel ausgeführt werden, da die Dialogflow API eine sessionId als Argument. Daher können Sie eine separate Sandbox für mit einem einzigen Dialogflow API-Client kommunizieren.

Da Sie Anfragen an die Dialogflow API stellen, kann eine Gebühr u. U. anfallen, wenn Ihr Kontingent an kostenlosen Anrufen erreicht ist. Siehe Kontingente und Limits .

Hinweis: Der Endpunkt detectIntent löst auch die Dialogflow-Auftragsausführung aus, die kann zu zusätzlichen Netzwerkaufrufen führen. Sie können die Auftragsausführung für eine bestimmte des individuellen Intents im Abschnitt Fulfillment (Auftragsausführung) der Seite des jeweiligen Intents an.

Integrationstests

Der Endpunkt detectIntent der Dialogflow API die Auftragsausführung durch einen Drittanbieter auslöst. Daher ist es möglich, Testfälle zur Integration zwischen Dialogflow-Agent und Dialogflow. Auftragsausführung.

Der Hauptunterschied zwischen dem Schreiben von Integrations- und Einheitentests für Dialogflow ist Damit du im Integrationstest Antworten vom Webhook bestätigen kannst sowie den Intent und die Entitätsextraktion in Dialogflow.

Das vollständige Beispiel eines in Node.js geschriebenen Integrationstests finden Sie in der Repository Facts About Google.

Dialogflow-Webhook für die Auftragsausführung testen

Der Dialogflow-Agent und die Dialogflow-Auftragsausführung werden separat getestet. Komponenten. In den folgenden Unterabschnitten wird beschrieben, wie Sie Testausführung für deine Aktion.

Auftragsausführung als JSON-Ein- und JSON-Ausgabesystem

Der Dialogflow-Auftragsausführungscode erwartet Anfragen und liefert Antworten in das JSON-Format. Sie können Ihren Auftragsausführungscode testen, indem Sie sich ein JSON-In- und JSON-Out-System verwenden. Die Anfrage enthält Metadaten sowohl von Dialogflow und Actions on Google. Somit bietet es alles, was zum Auslösen einer Intent-Handler in der Auftragsausführung.

Um das Auslösen eines Intent-Handlers zu testen, senden Sie eine JSON-Anfrage (Eingabe) an deine Aktion. Diese Anfrage wird an Ihre Auftragsausführung übergeben, auf die Sie zugreifen können unter über das Internet. Die Auftragsausführung erzeugt dann eine JSON-Antwort (Ausgabe), die für die Validierung beurteilt werden.

Abbildung 3: Darstellung einer Auftragsausführung als JSON-Ein- und JSON-Ausgabesystem

Einheitentests

Stellen Sie sich den Webhook-Code für die Auftragsausführung als ein System vor, das JSON-Eingaben und eine JSON-Ausgabe. Das Testen einer Aktion wird dann so vereinfacht, eine Anfrage an die Auftragsausführung stellen und die resultierende JSON-Ausgabe prüfen

So haben Sie die Möglichkeit, die Auftragsausführung lokal zu hosten und HTTP- lokale Anfragen zu Testzwecken an. Bei Verwendung von Node.js für Actions on Google können Sie JSON-Anfragen auch direkt an die Clientbibliothek Middleware-Ebene.

Wenn Sie den Webhook-Code mit JSON-Eingaben testen und das erwartete JSON erhalten Ausgaben, können Sie mit angemessener Sicherheit sagen, dass die von Ihnen kontrollierten Teile ordnungsgemäß funktioniert. Sie können davon ausgehen, dass Dialogflow und Actions on Google funktionieren weil sie die richtigen JSON-Nutzlasten generieren. Diese Isolation bietet ein vereinfachtes Programmiermodell zum Schreiben von Tests.

Hier ein allgemeiner Überblick über den Testprozess:

1. Verwenden Sie den Simulator in der Actions Console, um die JSON-Anfragen für Schritt in einem Anwendungsfall. Speichern Sie diese als JSON-Datei. Alternativ können Sie diese Anfragen mithilfe von Informationen aus dem Webhook-Referenzdokumentation
2. Schreiben Sie Tests, um den Webhook mit diesen Nutzlasten aufzurufen.
3. Achten Sie bei jedem Test darauf, dass die JSON-Antwort die erwarteten Elemente enthält.

Außerdem können Sie mit diesem Modell die Dialogflow-Auftragsausführung in einem da der Auftragsausführungsendpunkt lokal ausgeführt werden kann, Die Dialogflow API hat ein integriertes Konzept von Sitzungen.

Ein Beispieltest sieht so aus:

it('yes-history', function() {
  expect(jsonRes.payload).to.have.deep.keys('google');
  expect(jsonRes.payload.google.expectUserResponse).to.be.true;
  expect(jsonRes.payload.google.richResponse.items).to.have.lengthOf(3);
  expect(jsonRes.payload.google.richResponse.suggestions).to.have
    .deep.members([
      {'title': 'Sure'}, {'title': 'No thanks'},
    ]);
});

Im Snippet oben werden Mocha und Chai verwendet. Weitere Informationen finden Sie in der vollständiges funktionierendes Beispiel in Node.js unter Fakten über Google zu erstellen.

Einheitentestbare Auftragsausführung entwerfen

Der Webhook-Code enthält häufig benutzerdefinierte Geschäftslogik, die von Ihrer Anwendung benötigt wird. um seine Anforderungen zu erfüllen. Darüber hinaus kann der Webhook-Code auch Intents Handler.

Um den Detaillierungsgrad der Einheitentests für Ihren Auftragsausführungscode zu verbessern, ist es Ihren Code so zu organisieren, dass die Geschäftslogik von den Intent-Verarbeitungsroutinen entkoppelt sein. Das bedeutet, dass Intent-Handler und Geschäftslogik in separaten Modulen, sodass jedes Teil unabhängig voneinander unterscheiden.

Ein Beispiel finden Sie in unserer shiritori-beispielaktion auf GitHub. In diesem Beispiel haben functions/index.js und functions/shiritori/*.js separat Intent-Handler und Geschäftslogik enthalten, was zuverlässigere Tests ermöglicht Suiten.

Integrationstests

Zum Schreiben von Testfällen, die die Integration zwischen Dialogflow und Ihrem Webhook-Code für die Auftragsausführung finden Sie im Abschnitt zu Integrationstests für Dialogflow. oben.

Lasttests

Bevor Sie die Aktion in der Produktion bereitstellen, sollten Sie auch Belastungstests für Ihre der Webhook-Ausführung, um Leistungsprobleme zu erkennen, die zu einer Verschlechterung oder Unterbrechung Ihres Auftrags.

Hier sind einige Beispiele für Leistungsprobleme, die bei Belastungstests auftreten können:

• Begrenzte Rechen- und Arbeitsspeicherressourcen
• Kontingentbeschränkungen Ihrer Anbieter
• Langsame Datenlese- und -schreibvorgänge
• Gleichzeitigkeitsprobleme im Code

Belastungstestszenarien hängen vom erwarteten oder bisherigen Nutzungsmuster ab: Aktion ausführen. Typische Testszenarien sind jedoch plötzliche Lastanstiege (Spitzen) und dauerhafte Lasten (soak).

Szenarien ermitteln, in denen der Webhook aufgerufen und ausgeführt wird ressourcenintensiven Vorgängen. Typische ressourcenintensive Vorgänge sind Abfragen einer Datenbank, Aufrufen einer anderen API, Ausführen von Rechenvorgängen und Arbeitsspeicher wie das Rendern einer Audiodatei.

In diesen Fällen können Sie Anfragen erfassen, die von Actions on Google-Servern gesendet werden aus Ihren Webhook-Logs oder Stackdriver-Logs an den Webhook. Sie können auch Sie erfassen Anfragen vom Actions Console-Simulator.

Sobald Sie die Anfragen erhalten haben, können Sie ein Belastungstesttool verwenden, um herauszufinden, Der Webhook antwortet in verschiedenen Lasttestszenarien. Die folgenden Unterabschnitten finden Sie einige Beispiele für Spike-Tests und Soak-Tests mit ApacheBench

Ausschlagstests

Bei Spike-Tests müssen Sie eine konstante Anzahl von Anfragen an den Webhook senden und die Last plötzlich zu erhöhen. Sie können z. B. einen Test einrichten, das eine Last von 10 Abfragen pro Sekunde (Queries per Second, QPS) mit einigen Spitzen von 60 QPS sendet.

Mit dem folgenden ApacheBench-Befehl können Sie 60 Anfragen gleichzeitig senden. an Ihren Webhook:

ab -n 60 -c 60 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName

Angenommen, die Datei ActionRequest.json enthält die erfasste gesendete Anfragenutzlast mit Ihrem Webhook.

Soak-Test

Für Soak-Tests müssen Sie eine konstante Anzahl von Anfragen an den Webhook senden und die Reaktion beobachten. Sie können z. B. einen Test einrichten, der eine konstante Belastung von 10–20 Abfragen pro Sekunde über mehrere Minuten hinweg, um die Antwortzeiten zu ermitteln erhöhen können.

Mit dem folgenden ApacheBench-Befehl senden Sie 1.200 Anfragen mit 10 gleichzeitige Anfragen pro Sekunde:

ab -t 120 -n 1200 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName

Angenommen, die Datei ActionRequest.json enthält die erfasste gesendete Anfragenutzlast mit Ihrem Webhook.

Ergebnisse von Belastungstests analysieren

Analysieren Sie nach dem Ausführen von Lasttests die Ergebnisse auf die Webhook-Antwortzeiten. Indikatoren für Probleme in Ihrer Webhook-Implementierung sind in der Regel Trends wie Medianwert für die Antwortzeit, die mit jedem Testlauf zunimmt, oder im Worst-Case- Antwortzeit, die für deine Aktion inakzeptabel ist.

End-to-End-Tests

Bei End-to-End-Tests vor dem Einreichen deiner Aktion zur Genehmigung wird das Actions Console-Simulator Sie finden Schritte für den gesamten Tests über den Actions Console-Simulator im Actions-Simulator Dokumentation. Mit diesen Tests können Sie potenzielle Unsicherheiten beseitigen aus der Actions on Google-Infrastrukturkomponente.