Sprawdzone metody testowania (Dialogflow)

Opracowanie akcji na platformie Actions on Google często wiąże się Wdrożenie Dialogflow do rozumienia języka naturalnego (NLU) i Dialogflow fulfillment, który obsługuje logikę akcji. Przeprowadzanie testów w bazie kodu pomaga zapewnić, że akcja działa zgodnie z oczekiwaniami w produkcji.

Gdy wdrażasz testy jednostkowe, integracyjne lub kompleksowe testy akcji, należy traktować agenta Dialogflow i realizację jako osobne komponenty.

Schemat blokowy z zapytaniem użytkownika do Actions on Google, Dialogflow, i webhooki realizacji, które w końcu wróciły do użytkownika.

Rysunek 1. Schemat blokowy opisujący systemy, które należy wziąć pod uwagę podczas testowania

Testowanie agenta Dialogflow

Agent Dialogflow i realizacja są testowane jako osobne komponenty. W kolejnych podsekcjach omawiamy koncepcję i testowanie koncepcji Dialogflow. dla agenta akcji.

Dialogflow jako system wysyłania zapytań i zgłaszania intencji;

Agent Dialogflow jest odpowiedzialny za wykonanie zapytania użytkownika przez dopasowanie go do oraz wyodrębnienie z zapytania wszelkich wstępnie zdefiniowanych encji. Twój agent wchodzi w interakcję z Twoją realizację, przekazując komunikat zawierający dopasowany intencji, jej parametrów i metadanych Actions on Google.

Jako deweloper kontrolujesz konfigurację agenta Dialogflow, np. do struktury intencji i encji. Metadane w Actions on Google pochodzą Actions on Google, które mogą zawierać prawidłowe dane do testowania.

Podczas testowania skup się na tym, aby agent mógł prawidłowo wyodrębnić intencję i dopasowywania zapytań do intencji. Takie podejście zapewnia wymiernych wskaźników do oceny wydajności agenta. Dostępne opcje obliczać te dane, przygotowując i stosując poszczególne przypadki testowe do walidacji.

Agent Dialogflow może być reprezentowany za pomocą zapytania tekstowego jako danych wejściowych oraz wyodrębnione parametry intencji jako dane wyjściowe.

Rysunek 2. Przedstawianie Dialogflow jako systemu zapytań przychodzących i wychodzących

Testy jednostkowe

Dla agenta Dialogflow możesz utworzyć testy, w których każde przypadek spodziewa się tekstu jako dane wejściowe i generują metadane intencji jako dane wyjściowe. Te metadane powinien (co najmniej) zawierać nazwę dopasowanej intencji oraz listę dopasowanych .

punkt końcowy detectIntent interfejsu Dialogflow API, traktuje zapytanie tekstowe jako dane wejściowe i generuje ustrukturyzowane dane wyjściowe, które zawierają nazwę zatwierdzonej intencji i wyodrębnione parametry. Te dane wyjściowe są przydatne oceny skuteczności dopasowania do intencji. Pełną listę odniesienia do innych przydatnych pól znajdziesz w dokumentacji QueryResult.

Przykładowy test wygląda tak:

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');
});

Ten fragment kodu wykorzystuje słowa Mocha i Chai. Zobacz pełne działającego przykładu testu jednostkowego Dialogflow napisanego w Node.js dla Fakty o Google.

Pliki testowe można uruchamiać równolegle, ponieważ interfejs Dialogflow API akceptuje sessionId jako argument. Dlatego możesz mieć osobną piaskownicę dla w każdej rozmowie przy użyciu jednego klienta Dialogflow API.

Ponieważ wysyłasz żądania za pomocą interfejsu Dialogflow API, obciążenie może być poniesionych po osiągnięciu limitu bezpłatnych połączeń. Zobacz limity .

Testy integracji

Punkt końcowy detectIntent interfejsu Dialogflow API ma też uruchamia realizację zamówień zewnętrznych. Dzięki temu można pisać przypadki testowe Omówimy integrację między agentem Dialogflow a Dialogflow i realizacji.

Główna różnica między pisaniem integracji a testami jednostowymi w Dialogflow to: że w teście integracji można potwierdzić odpowiedzi pochodzące z webhooka a także intencję Dialogflow i wyodrębnianie encji.

Zobacz pełny przykład działania testu integracji zapisanego w Node.js w Fakty o Google.

Testowanie webhooka realizacji Dialogflow

Agent Dialogflow i realizacja Dialogflow są testowane jako osobne W sekcjach poniżej omówiono koncepcje aby przetestować realizację Akcji.

Realizacja w ramach systemu JSON-In i JSON-out

Twój kod realizacji Dialogflow oczekuje żądań i generuje odpowiedzi w w formacie JSON. Możesz więc przetestować kod realizacji i zastanowić się nad go jako systemu JSON-in i JSON-out. Żądanie zawiera metadane zarówno z Dialogflow i Actions on Google, więc zawiera on wszystko, co jest potrzebne do wywołania konkretnego modułu obsługi intencji w ramach realizacji.

Aby przetestować aktywowanie modułu obsługi intencji, wysyłasz żądanie JSON (dane wejściowe) do akcję. To żądanie jest przekazywane do usługi realizacji, która jest dostępna na w internecie. Realizacja powoduje następnie wygenerowanie odpowiedzi JSON (dane wyjściowej), która może poddawane ocenie.

Realizacja może być reprezentowana za pomocą danych wejściowych żądania JSON i kodu JSON webhooka dane wyjściowe odpowiedzi.

Rysunek 3. Przedstawienie realizacji w formie systemu JSON-In i JSON-out

Testy jednostkowe

Kod webhooka realizacji to system, który akceptuje dane wejściowe JSON zwróci dane wyjściowe JSON. Proces testowania Akcji jest następnie uproszczony do przez udostępnienie żądania do realizacji i sprawdzenie wynikowego kodu JSON.

Daje Ci to swobodę hostowania realizacji lokalnie i wysyłania HTTP lokalnie do testowania. Jeśli używasz Actions on Google Node.js klienta, możesz też wysyłać żądania JSON bezpośrednio do biblioteki klienta warstwa oprogramowania pośredniczącego.

Jeśli testujesz kod webhooka z użyciem danych wejściowych JSON i otrzymujesz oczekiwany kod JSON możesz z większą pewnością stwierdzić, że części, nad którymi masz kontrolę działają poprawnie. Możesz zakładać, że Dialogflow i Actions on Google działają prawidłowo, ponieważ generują prawidłowe ładunki JSON. Ta izolacja to uproszczony model programowania do pisania testów.

Ogólny opis procesu testowania wygląda tak:

  1. Użyj symulatora w Konsoli Actions, aby pobrać żądania JSON dla każdego etapu w danym przypadku użycia. Zapisz je jako pliki JSON. Ewentualnie możesz własne żądania, korzystając z informacji dokumentacji webhooka.
  2. Zapisz testy, które pozwolą wywołać webhooka z tymi ładunkami.
  3. W przypadku każdego testu sprawdź, czy odpowiedź JSON zawiera oczekiwane elementy.

Dodatkowo ten model umożliwia testowanie realizacji Dialogflow w integracji ciągłej, ponieważ punkt końcowy realizacji może działać lokalnie, a interfejs Dialogflow API ma wbudowaną koncepcję sesji.

Przykładowy test wygląda tak:

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'},
    ]);
});

Powyższy fragment kodu używa słów Mocha i Chai. Zobacz pełny przykład działania napisany w Node.js w sekcji Fakty o Google z repozytorium.

Projektowanie realizacji możliwej do przetestowania jednostkowego

Kod webhooka często zawiera niestandardową logikę biznesową, na której opiera się aplikacja w celu zaspokojenia jego potrzeb. Dodatkowo kod webhooka może też zawierać intencję modułów obsługi.

Aby zwiększyć szczegółowość testów jednostkowych kodu realizacji, warto: uporządkuj kod w taki sposób, aby logika biznesowa była i jest oddzielone od procedur obsługi intencji. Oznacza to, że musisz mieć moduły obsługi intencji i logikę biznesową w osobnych modułach, więc każdy element można przetestować dzięki czemu mogą pracować niezależnie.

Możesz to sprawdzić w przykładowym działaniu shiritori na GitHubie. W tej próbce functions/index.js i functions/shiritori/*.js oddzielnie zawierają moduły obsługi intencji i logikę biznesową, co pozwala na i apartamenty.

Testy integracji

Do pisania przypadków testowych obejmujących integrację między Dialogflow a kontem kod webhooka realizacji, przeczytaj sekcję testowania integracji dla Dialogflow. powyżej.

Testy wczytywania

Przed wdrożeniem akcji w środowisku produkcyjnym zalecamy również przetestowanie wczytywania realizacja webhooka w celu wykrywania problemów z wydajnością, które powodują pogorszenie wyników lub przerw w świadczeniu usług realizacji zamówień.

Oto kilka przykładów problemów z wydajnością, które mogą wystąpić podczas testowania wczytywania:

  • Ograniczona moc obliczeniowa i pamięć
  • Ograniczenia limitów od Twoich dostawców
  • Powolne odczyty i zapisy danych
  • Problemy z równoczesnością w kodzie

Scenariusze testowania obciążenia zależą od oczekiwanego lub historycznego wzorca wykorzystania do działania, ale zazwyczaj testujemy gwałtowny wzrost obciążenia. i ciągłe obciążenie (nagrzanie).

Zidentyfikuj scenariusze, w których webhook jest wywoływany i spełnia swoje zadanie i operacji wymagających wielu zasobów. Typowe operacje intensywnie korzystające z zasobów to: zapytania do bazy danych, wywoływanie innego interfejsu API, wykonywanie obliczeń i wykonywanie pamięci intensywnych operacji, takich jak renderowanie pliku dźwiękowego.

W takich sytuacjach możesz przechwytywać żądania wysyłane z serwerów Actions on Google do webhooka z logów webhooka lub z logów usługi Stackdriver. Możesz też przechwytywania żądań z symulatora Konsoli Actions.

Gdy otrzymasz żądania, możesz użyć narzędzia do testowania obciążenia, aby sprawdzić, webhook odpowiada w ramach różnych scenariuszy testowania obciążenia. Poniżej można znaleźć kilka przykładów ApacheBench

Testy gwałtownych wzrostów

Testowanie gwałtownego wzrostu wymaga wysyłania do webhooka stałej liczby żądań i nagle zwiększyć obciążenie. Możesz na przykład skonfigurować test wysyła obciążenie 10 zapytań na sekundę, przy czym liczba skoków na sekundę wynosi 60.

Aby wysłać 60 równoczesnych żądań, możesz uruchomić poniższe polecenie ApacheBench do webhooka:

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

Zakładamy, że plik ActionRequest.json zawiera przechwycony ładunek żądania wysłany do webhooka.

Testy utrzymywania sekwencji

Testowanie utrzymywania sekwencji wymaga wysyłania do webhooka stałej liczby żądań i przyjrzyć się odpowiedzi. Możesz np. skonfigurować test, który wysyła stałe obciążenie 10–20 zapytań na sekundę przez kilka minut, aby sprawdzić, czy czas odpowiedzi wzrost.

Aby wysłać 1200 żądań, z czego 10 z nich możesz uruchomić podane niżej polecenie ApacheBench żądań równoczesnych co sekundę:

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

Zakładamy, że plik ActionRequest.json zawiera przechwycony ładunek żądania wysłany do webhooka.

Analizuję wyniki testu obciążenia

Po przeprowadzeniu testów obciążenia przeanalizuj wyniki czasów odpowiedzi webhooka. Oznakami problemów w implementacji webhooka są zwykle trendy, takie jak mediana czasu odpowiedzi, która zwiększa się po każdym uruchomieniu testu, lub w najgorszym przypadku. czas odpowiedzi niedopuszczalny dla danej akcji.

Kompleksowe testowanie

Przed przesłaniem Akcji do zatwierdzenia w ramach kompleksowego testowania używana jest Symulator w Konsoli Actions. Kompleksowe instrukcje znajdziesz testowania za pomocą symulatora Actions Console w Symulatorze działań, dokumentacji. Przeprowadzanie tych testów pomaga wyeliminować potencjalne niepewności za pomocą komponentu infrastruktury Actions on Google.