O desenvolvimento de uma ação para a plataforma Actions on Google geralmente envolve implementar o Dialogflow como ferramenta de processamento de linguagem natural (PLN) e fulfillment do Dialogflow, que processa a lógica da sua ação. Ter testes na base de código ajuda a garantir que a ação tenha o desempenho esperado em produção.
Ao implementar testes de unidade, integração ou ponta a ponta para sua ação, você deve considerar o agente e o fulfillment do Dialogflow como componentes separados.
Figura 1. Fluxograma que descreve os sistemas a serem considerados para testes
Como testar um agente do Dialogflow
O agente e o fulfillment do Dialogflow são testados como componentes separados. A as subseções a seguir descrevem como conceitualizar e testar o uso do agente para sua ação.
Dialogflow como um sistema de consulta e saída de intenção
O agente do Dialogflow é responsável por receber a consulta do usuário e fazer a correspondência uma intent e extrair qualquer entidade predefinida da consulta. Seu agente interage com o fulfillment transmitindo uma mensagem com o intent, parâmetros e metadados do Actions on Google.
Como desenvolvedor, você controla a configuração do agente do Dialogflow, como a estrutura de intents e entidades. Os metadados do Actions on Google vêm da Actions on Google e pode ser considerado que contêm os dados corretos para o teste.
Ao testar, concentre-se em tornar seu agente capaz de extrair corretamente a intent parâmetros e consultas correspondentes a intents. Essa abordagem fornece uma quantificável e quantificável para avaliar o desempenho do agente. Você pode calcular essa métrica preparando e usando casos de teste individuais ou conjunto de validação.
Figura 2. Representação do Dialogflow como sistema de consulta de entrada e de saída
Testes de unidade
No agente do Dialogflow, é possível escrever testes em que cada caso espera um texto como uma entrada e produz metadados de intent como uma saída. Esses metadados deve conter (no mínimo) o nome da intent correspondente e uma lista de parâmetros.
O endpoint detectIntent da API Dialogflow
usa a consulta de texto como uma entrada e produz uma saída estruturada que contém
o nome da intent resolvida e os parâmetros extraídos. Essa saída é útil
para avaliar o desempenho da correspondência de intent do agente. Para um guia
referência de outros campos úteis, consulte a referência do QueryResult.
Um teste de exemplo tem esta aparência:
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');
});
Esse snippet usa Mocha e Chai. Veja o exemplo prático do teste de unidade do Dialogflow escrito em Node.js para Fatos sobre o Google.
Os arquivos de teste podem ser executados em paralelo porque a API Dialogflow aceita uma
sessionId como argumento. Como resultado, você pode ter um sandbox separado para
em cada conversa usando um único cliente da API Dialogflow.
Como você está fazendo solicitações para a API Dialogflow, pode haver uma cobrança caso sua cota de chamadas sem custo financeiro seja atingida. Veja cotas e limites para mais informações.
Testes de integração
O endpoint detectIntent da API Dialogflow também
aciona o fulfillment de terceiros. Dessa forma, é possível programar casos de teste
que abrangem a integração entre o agente e o agente do Dialogflow
o atendimento do pedido.
A principal diferença entre criar testes de integração e unidade para o Dialogflow é que, no teste de integração, é possível declarar respostas provenientes do webhook a intent do Dialogflow e a extração de entidades.
Veja o exemplo completo de trabalho de um teste de integração escrito em Node.js no Repositório Fatos sobre o Google.
Como testar um webhook de fulfillment do Dialogflow
O agente e o fulfillment do Dialogflow são testados como itens separados componentes de solução. As subseções a seguir descrevem como é possível conceitualizar e o fulfillment de teste da sua ação.
Fulfillment como um sistema de entrada e saída de JSON
O código de fulfillment do Dialogflow espera solicitações e produz respostas o formato JSON. Como resultado, é possível testar o código de fulfillment pensando em como um sistema JSON-in e JSON-out. A solicitação contém metadados de Dialogflow e Actions on Google, ou seja, tem tudo o que é necessário para acionar uma gerenciador de intents específico do fulfillment.
Para testar o acionamento de um gerenciador de intents, envie uma solicitação JSON (entrada) para sua ação. Essa solicitação é transmitida para o fulfillment, que pode ser acessado na Internet. O fulfillment produz uma resposta JSON (saída), que pode para validação.
Figura 3. Representação de um fulfillment como sistema de entrada e saída de JSON
Testes de unidade
Pense no código do webhook de fulfillment como um sistema que aceita uma entrada JSON produz uma saída JSON. O processo de testar uma ação é simplificado para fornecer uma solicitação ao fulfillment e verificar o JSON de saída resultante.
Isso dá a você a liberdade de hospedar o fulfillment localmente e enviar solicitações localmente para teste. Se você estiver usando o Node.js do Actions on Google você também pode enviar solicitações JSON diretamente para a biblioteca de cliente a camada de middleware.
Se você testar o código do webhook com entradas JSON e receber o JSON esperado das suas saídas, é possível dizer com confiança razoável que as partes que você controla funcionar corretamente. Suponha que o Dialogflow e o Actions on Google estejam funcionando corretamente porque estão gerando os payloads JSON corretos. Esse isolamento fornece um modelo de programação simplificado para a criação de testes.
Veja uma descrição geral do processo de teste:
- Use o simulador no Console do Actions para receber as solicitações JSON do cada etapa em um caso de uso. Salve-os como arquivos JSON. Também é possível crie você mesmo essas solicitações usando informações do documentação de referência do webhook.
- Escreva testes para invocar o webhook com esses payloads.
- Para cada teste, verifique se o JSON de resposta contém os itens esperados.
Além disso, esse modelo permite testar o fulfillment do Dialogflow em um integração contínua, porque o endpoint de fulfillment pode ser executado localmente, e a API Dialogflow tem um conceito integrado de sessões.
Confira um exemplo de teste:
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'},
]);
});
O snippet acima usa Mocha e Chai. Consulte a exemplo completo de trabalho escrito em Node.js no livro Facts About Google repositório de dados.
Como projetar o fulfillment testável por unidade
O código do webhook geralmente contém uma lógica de negócios personalizada que seu aplicativo usa para satisfazer suas necessidades. Além disso, o código do webhook também pode conter intents .
Para melhorar a granularidade dos testes de unidade do código de fulfillment, é recomendável praticar para organizar seu código de forma que a lógica de negócios seja dissociados das rotinas de processamento de intents. Ou seja, ter gerenciadores de intents e lógica de negócios em módulos separados, para que cada parte possa ser testada de forma independente.
Consulte nosso exemplo de ação shiritori no GitHub (link em inglês).
Nessa amostra, functions/index.js e functions/shiritori/*.js separadamente
contêm os gerenciadores de intent e a lógica de negócios, permitindo um teste mais
suítes.
Testes de integração
Para criar casos de teste que abrangem a integração entre o Dialogflow e sua código do webhook de fulfillment, leia a seção de teste de integração do Dialogflow acima.
Testes de carregamento
Antes de implantar a ação na produção, também recomendamos testar o carregamento do fulfillment de webhook para revelar problemas de desempenho que causam degradação ou interrupção do serviço de atendimento do pedido.
Confira alguns exemplos de problemas de desempenho que podem ocorrer no teste de carga:
- Computação e memória limitadas
- Restrições de cota dos seus provedores
- Leituras e gravações de dados lentas
- Problemas de simultaneidade no código
Os cenários de teste de carga dependem do padrão de uso esperado ou histórico dos sua ação, mas os cenários comuns a serem testados são aumentos repentinos de carga (picos) e cargas sustentadas (de imersão).
Identifique cenários em que o webhook é chamado e executado. operações que exigem muitos recursos. Operações típicas com uso intensivo de recursos incluem consultar um banco de dados, chamar outra API, executar computação e memória operações intensivas, como renderizar um arquivo de som.
Nesses cenários, é possível capturar solicitações enviadas pelos servidores do Actions on Google. para o webhook a partir dos registros do webhook ou dos registros do Stackdriver. Você também pode capturar solicitações do simulador do Console do Actions.
Depois de ter as solicitações, você pode usar uma ferramenta de teste de carga para descobrir como seu O webhook responde em diferentes cenários de teste de carga. O seguinte as subseções fornecem alguns exemplos de teste de pico e de imersão usando ApacheBench (link em inglês).
Teste de pico
O teste de pico exige o envio de um número constante de solicitações para o webhook. por algum tempo e repentinamente aumentar a carga. Por exemplo, configure um teste que envia uma carga de 10 consultas por segundo (QPS) com alguns picos de 60 QPS.
É possível executar o seguinte comando do ApacheBench para enviar 60 solicitações simultâneas ao webhook:
ab -n 60 -c 60 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName
Suponha que o arquivo ActionRequest.json contenha o payload da solicitação capturada enviado
ao webhook.
Teste de imersão
O teste de imersão requer que você envie um número constante de solicitações para o webhook. e observar a resposta. Por exemplo, você pode configurar um teste que envia uma carga constante de 10 a 20 QPS por vários minutos para ver se os tempos de resposta aumentam.
Você pode executar o seguinte comando do ApacheBench para enviar 1.200 solicitações, com 10 solicitações simultâneas a cada segundo:
ab -t 120 -n 1200 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName
Suponha que o arquivo ActionRequest.json contenha o payload da solicitação capturada enviado
ao webhook.
Como analisar os resultados do teste de carga
Depois de executar testes de carga, analise os resultados dos tempos de resposta do webhook. Os indicadores de problemas na implementação do webhook geralmente são tendências, como uma o tempo médio de resposta que aumenta a cada execução de teste, ou o tempo de resposta inaceitável para a Ação.
Testes de ponta a ponta
Os testes completos antes do envio da Ação para aprovação usam o Simulador do Console do Actions Confira as etapas Testes com o simulador do Console do Actions no simulador do Actions na documentação do Google Cloud. A realização desses testes ajuda a remover possíveis incertezas do componente de infraestrutura do Actions on Google.