Lo sviluppo di un'azione per la piattaforma Actions on Google spesso comporta L'implementazione di Dialogflow per la comprensione del linguaggio naturale (NLU) e fulfillment Dialogflow, che gestisce la logica dell'Azione. Eseguire test nel codebase aiuta a garantire che l'azione si comporti come previsto in produzione.
Quando implementi test delle unità, di integrazione o end-to-end per l'Azione, devi considerare l'agente e il fulfillment Dialogflow come componenti separati.
Figura 1. Diagramma di flusso che descrive i sistemi da considerare per i test
Test di un agente Dialogflow
L'agente e il fulfillment Dialogflow vengono testati come componenti separati. La le seguenti sottosezioni descrivono come concettualizzare e testare Dialogflow per l'Azione.
Dialogflow come sistema di query in entrata e uscita
L'agente Dialogflow è responsabile per trovare la query di un utente e associarla a un intent ed estraendo eventuali entità predefinite dalla query. Il tuo agente interagisce con il fulfillment passando un messaggio contenente l'intent, i relativi parametri e i metadati di Actions on Google.
In qualità di sviluppatore, puoi controllare la configurazione dell'agente Dialogflow, ad esempio la struttura di intenti ed entità. I metadati di Actions on Google provengono Actions on Google e si presume che contenga i dati corretti per i test.
Durante il test, concentrati su come rendere l'agente in grado di estrarre correttamente l'intento e associando le query agli intent. Questo approccio fornisce metrica quantificabile per valutare le prestazioni dell'agente. Puoi calcolare questa metrica preparando e utilizzando singoli scenari di test o set di convalida.
Figura 2. Rappresentazione di Dialogflow come sistema di query in entrata e di uscita
Test delle unità
Per l'agente Dialogflow, puoi scrivere test in cui ogni richiesta prevede un messaggio come input e produce metadati di intent come output. Questi metadati deve contenere almeno il nome dell'intent abbinato e un elenco di parametri.
Endpoint detectIntent dell'API Dialogflow
prende la query di testo come input e produce un output strutturato che contiene
il nome dell'intent risolto e dei parametri estratti. Questo output è utile
per valutare le prestazioni
di corrispondenza di intenzione dell'agente. Per un
riferimento di altri campi utili, consulta il riferimento QueryResult.
Un test di esempio ha il seguente aspetto:
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');
});
Questo snippet utilizza Mocha e Chai. Visualizza la esempio funzionante del test delle unità Dialogflow scritto in Node.js per Informazioni su Google.
I file di test possono essere eseguiti in parallelo perché l'API Dialogflow accetta
sessionId come argomento. Di conseguenza, puoi avere una sandbox separata per
ogni conversazione usando un singolo client API Dialogflow.
Dato che stai effettuando richieste contro l'API Dialogflow, un addebito potrebbe essere sostieni se viene raggiunta la tua quota di chiamate senza costi. Vedi quote e limiti per ulteriori informazioni.
Test di integrazione
Anche l'endpoint detectIntent dell'API Dialogflow
attiva il fulfillment di terze parti. Di conseguenza, è possibile scrivere scenari di test
che coprono l'integrazione tra l'agente Dialogflow e Dialogflow
fulfillment.
La differenza principale tra la scrittura dei test di integrazione e di test delle unità in Dialogflow è che nel test di integrazione puoi affermare le risposte provenienti dal webhook nonché l'intento e l'estrazione delle entità di Dialogflow.
Guarda l'esempio funzionante completo di un test di integrazione scritto in Node.js nel Repository di Facts About Google.
Test di un webhook di fulfillment Dialogflow
L'agente Dialogflow e il fulfillment Dialogflow vengono testati come strumenti separati componenti. Le seguenti sottosezioni descrivono come concettualizzare e il completamento del test per l'Azione.
Evasione degli ordini come sistema JSON-in e JSON-out
Il codice di fulfillment Dialogflow prevede richieste e produce risposte nel formato JSON. Di conseguenza, puoi testare il codice di distribuzione pensando a come sistema JSON-in e JSON-out. La richiesta contiene metadati sia da Dialogflow e Actions on Google, quindi ha tutto il necessario per attivare un un particolare gestore di intent nel tuo fulfillment.
Per testare l'attivazione di un gestore di intent, devi inviare una richiesta JSON (input) a l'Azione. Questa richiesta viene passata al tuo fulfillment, che è accessibile su su internet. Il fulfillment produce quindi una risposta JSON (output), che può per la convalida.
Figura 3. Rappresentazione di un fulfillment come sistema JSON-in e JSON-out
Test delle unità
Pensa al codice webhook di completamento come a un sistema che accetta un input JSON e produce un output JSON. Il processo di test di un'azione viene quindi semplificato inviando una richiesta al fulfillment e controllando il JSON di output risultante.
In questo modo avrai la libertà di ospitare il fulfillment localmente e inviare messaggi HTTP a livello locale per i test. Se utilizzi Node.js Actions on Google libreria client, puoi anche inviare richieste JSON direttamente alla libreria client il livello middleware.
Se testi il codice webhook con input JSON e ricevi il codice JSON previsto, puoi affermare con ragionevole certezza che le parti che controlli funzionino correttamente. Possiamo presumere che Dialogflow e Actions on Google funzionino. correttamente perché stanno generando i payload JSON corretti. Questo isolamento offre un modello di programmazione semplificato per la scrittura dei test.
Di seguito è riportata una descrizione generale della procedura di test:
- Utilizza il simulatore nella console di Actions per ottenere le richieste JSON per in ogni passaggio in un caso d'uso. Salvali come file JSON. In alternativa, puoi a creare personalmente queste richieste utilizzando le informazioni documentazione di riferimento per webhook.
- Scrivi test per richiamare il webhook con questi payload.
- Per ogni test, assicurati che il JSON della risposta contenga gli elementi previsti.
Inoltre, questo modello ti consente di testare il fulfillment Dialogflow in un di integrazione continua perché l'endpoint di fulfillment può essere eseguito localmente e l'API Dialogflow prevede un concetto integrato di sessioni.
Ecco un esempio di test:
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'},
]);
});
Lo snippet riportato sopra utilizza Mocha e Chai. Consulta le esempio funzionante completo scritto in Node.js nel libro Facts About Google repository Git.
Progettazione del fulfillment verificabile delle unità
Il codice webhook spesso contiene una logica di business personalizzata basata sulla tua applicazione per soddisfare le sue esigenze. Inoltre, il codice webhook può contenere anche un intent e i gestori di rete.
Per migliorare la granularità dei test delle unità per il codice di evasione degli ordini, è utile organizzare il codice in modo che la logica di business sia disaccoppiate dalle routine di gestione degli intent. Ciò significa avere gestori di intent e la logica di business in moduli separati, in modo che ogni elemento possa essere testato in modo indipendente.
Per un esempio, consulta la nostra azione di esempio di Shiritori su GitHub.
Nell'esempio, functions/index.js e functions/shiritori/*.js separatamente
contengono i gestori di intent e la logica di business, consentendo test più
suite.
Test di integrazione
Per scrivere scenari di test che coprono l'integrazione tra Dialogflow e codice webhook di fulfillment, leggi la sezione relativa ai test di integrazione per Dialogflow in alto.
Test di carico
Prima di eseguire il deployment dell'azione in produzione, ti consigliamo anche di testare il carico fulfillment webhook per individuare problemi di prestazioni che causano un peggioramento l'interruzione del servizio di evasione ordine.
Di seguito sono riportati alcuni esempi di problemi di prestazioni che puoi rilevare nei test di carico:
- Computing e memoria limitati
- Limitazioni delle quote dei tuoi provider
- Letture e scritture di dati lente
- Problemi di contemporaneità nel codice
Gli scenari di test di carico dipendono dal modello di utilizzo previsto o storico di l'azione, ma gli scenari tipici da testare sono aumenti improvvisi del carico (picco) e carichi sostenuti (soak).
Identifica gli scenari in cui viene chiamato e in cui viene eseguito il webhook e ad alta intensità di risorse. Le operazioni tipiche che richiedono un uso intensivo delle risorse includono eseguire query su un database, chiamare un'altra API, eseguire computing e memoria per le operazioni più complesse, come il rendering di un file audio.
In questi scenari, puoi acquisire le richieste inviate dai server di Actions on Google al webhook dai log webhook o dai log di Stackdriver. Puoi anche acquisire le richieste dal simulatore della console Actions.
Una volta ricevute le richieste, puoi utilizzare uno strumento di test del carico per scoprire in che modo il webhook risponde in diversi scenari di test di carico. Le seguenti le sottosezioni forniscono alcuni esempi di test di picchi e di test di soak test utilizzando ApacheBench.
Test dei picchi
Il test dei picchi richiede l'invio di un numero costante di richieste al webhook per un po' di tempo e aumentare improvvisamente il carico. Ad esempio, puoi configurare un test che invia un carico di 10 query al secondo (QPS) con alcuni picchi di 60 QPS.
Puoi eseguire questo comando ApacheBench per inviare 60 richieste in parallelo al webhook:
ab -n 60 -c 60 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName
Supponiamo che il file ActionRequest.json contenga il payload della richiesta acquisita inviato
al webhook.
Test di soak
Il test di sospensione richiede l'invio di un numero costante di richieste al webhook e osservare la risposta. Ad esempio, puoi configurare un test che invii carico costante di 10-20 QPS per diversi minuti per vedere se i tempi di risposta aumentano.
Puoi eseguire il seguente comando ApacheBench per inviare 1200 richieste, con 10 richieste in parallelo al secondo:
ab -t 120 -n 1200 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName
Supponiamo che il file ActionRequest.json contenga il payload della richiesta acquisita inviato
al webhook.
Analisi dei risultati del test di carico
Dopo aver eseguito i test di carico, analizza i risultati per i tempi di risposta del webhook. Gli indicatori dei problemi nell'implementazione del webhook sono in genere tendenze come tempo di risposta medio che aumenta a ogni esecuzione di test o nel peggiore dei casi tempi di risposta non accettabili per l'Azione.
Test end-to-end
Il test end-to-end prima di inviare l'Azione per l'approvazione utilizza il parametro Simulatore della console Actions. Puoi trovare i passaggi per test tramite il simulatore della console di Actions nel simulatore di Actions documentazione. L'esecuzione di questi test ti aiuta a eliminare potenziali incertezze dal componente dell'infrastruttura Actions on Google.