Mengembangkan Action untuk platform Actions on Google sering kali melibatkan menerapkan Dialogflow untuk pemahaman natural language (NLU), dan fulfillment Dialogflow, yang menangani logika untuk Action Anda. Melakukan pengujian di codebase membantu memastikan bahwa Action Anda berperforma seperti yang diharapkan dalam lingkungan production.
Saat menerapkan pengujian unit, integrasi, atau menyeluruh untuk Action, Anda harus mempertimbangkan agen dan fulfillment Dialogflow Anda sebagai komponen terpisah.
Gambar 1. Diagram alir yang menjelaskan sistem yang perlu dipertimbangkan untuk pengujian
Menguji agen Dialogflow
Agen dan fulfillment Dialogflow diuji sebagai komponen terpisah. Tujuan subbagian berikut menjelaskan cara membuat konsep dan menguji Dialogflow untuk Action Anda.
Dialogflow sebagai sistem query-in dan intent-out
Agen Dialogflow Anda bertanggung jawab untuk mengambil kueri pengguna, mencocokkannya dengan intent, dan mengekstrak entity yang telah ditetapkan sebelumnya dari kueri. Agen Anda berinteraksi dengan fulfillment Anda dengan meneruskan pesan yang berisi peristiwa intent, parameternya, dan metadata Actions on Google.
Sebagai developer, Anda mengontrol konfigurasi agen Dialogflow, seperti struktur intent dan entity. Metadata Actions on Google berasal dari Actions on Google, dan dapat dianggap berisi data yang benar untuk pengujian.
Saat melakukan pengujian, fokuslah untuk membuat agen Anda mampu mengekstrak intent dengan benar parameter dan kueri yang cocok dengan intent. Pendekatan ini memberikan metrik yang dapat diukur untuk menilai kinerja agen. Anda dapat menghitung metrik ini dengan menyiapkan dan menggunakan kasus uji individu atau set validasi.
Gambar 2. Representasi Dialogflow sebagai sistem query-in dan intent-out
Pengujian unit
Untuk agen Dialogflow, Anda bisa menulis pengujian di mana setiap kasus mengharapkan teks sebagai input dan menghasilkan metadata intent sebagai output. Metadata ini harus (minimal) berisi nama intent yang cocok dan daftar intent yang cocok parameter.
Endpoint detectIntent
dari Dialogflow API
menggunakan kueri teks sebagai input dan menghasilkan output terstruktur yang berisi
nama intent yang di-resolve dan parameter yang diekstrak. Output ini berguna
untuk menilai performa pencocokan intent agen. Untuk
kolom berguna lainnya, lihat referensi QueryResult
.
Contoh pengujian akan terlihat seperti ini:
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');
});
Cuplikan ini menggunakan Mocha dan Chai. Lihat selengkapnya contoh kerja pengujian unit Dialogflow yang ditulis dalam Node.js untuk Fakta tentang Google.
File pengujian Anda dapat dijalankan secara paralel karena Dialogflow API menerima
sessionId
sebagai argumen. Hasilnya, Anda dapat memiliki
{i>sandbox<i} terpisah untuk
setiap percakapan saat menggunakan klien Dialogflow API tunggal.
Karena Anda membuat permintaan terhadap Dialogflow API, tagihan mungkin dikenakan timbul jika kuota panggilan gratis Anda tercapai. Lihat kuota dan batas untuk informasi selengkapnya.
Pengujian integrasi
Endpoint detectIntent
Dialogflow API juga
memicu fulfillment pihak ketiga. Dengan demikian, kita bisa menulis kasus pengujian
yang mencakup integrasi antara agen Dialogflow dan Dialogflow
pemenuhan pesanan.
Perbedaan utama antara penulisan pengujian unit dan integrasi untuk Dialogflow adalah sehingga dalam pengujian integrasi, Anda dapat menyatakan respons yang berasal dari webhook serta ekstraksi intent dan entity Dialogflow.
Lihat contoh kerja penuh pengujian integrasi yang ditulis dalam Node.js di Repositori Fakta Tentang Google.
Menguji webhook fulfillment Dialogflow
Agen Dialogflow dan fulfillment Dialogflow diuji sebagai terpisah komponen. Subbagian berikut menjelaskan bagaimana Anda dapat membuat konsep dan fulfillment pengujian untuk Action Anda.
Pemenuhan sebagai sistem JSON-in dan JSON-out
Kode fulfillment Dialogflow Anda mengharapkan permintaan dan menghasilkan respons dalam dalam format JSON saya. Hasilnya, Anda bisa menguji kode penyelesaian dengan memikirkan sebagai sistem JSON-masuk dan JSON-keluar. Permintaan berisi metadata yang berasal dari Dialogflow dan Actions on Google, sehingga ia memiliki semua yang diperlukan untuk memicu pengendali intent tertentu dalam fulfillment Anda.
Untuk menguji pemicu pengendali intent, Anda mengirim permintaan JSON (input) ke Action Anda. Permintaan ini diteruskan ke fulfillment Anda, yang dapat diakses di internet. fulfillment kemudian menghasilkan respons JSON (output), yang dapat akan dinilai untuk validasi.
Gambar 3. Representasi fulfillment sebagai sistem JSON-in dan JSON-out
Pengujian unit
Bayangkan kode webhook fulfillment sebagai sistem yang menerima input JSON dan yang menghasilkan output JSON. Proses pengujian Action kemudian disederhanakan menjadi menyediakan permintaan ke fulfillment Anda dan memeriksa JSON output yang dihasilkan.
Hal ini memberi Anda kebebasan untuk menghosting fulfillment secara lokal dan mengirim permintaan secara lokal untuk pengujian. Jika Anda menggunakan Node.js Actions on Google library klien, Anda juga dapat mengirim permintaan JSON langsung ke library klien middleware layer.
Jika Anda menguji kode webhook dengan input JSON dan menerima JSON yang diharapkan maka Anda dapat mengatakan dengan keyakinan yang wajar bahwa bagian yang Anda kontrol berfungsi dengan baik. Anda dapat menganggap bahwa Dialogflow dan Actions on Google berfungsi dengan benar karena menghasilkan payload JSON yang benar. Isolasi ini menyediakan model pemrograman yang disederhanakan untuk menulis pengujian.
Berikut adalah garis besar umum proses pengujian:
- Gunakan simulator di Konsol Actions guna mendapatkan permintaan JSON untuk setiap langkah dalam kasus penggunaan. Simpan ini sebagai file JSON. Atau, Anda dapat membangun sendiri permintaan tersebut menggunakan informasi dari dokumentasi referensi webhook.
- Tulis pengujian untuk memanggil webhook dengan payload ini.
- Untuk setiap pengujian, pastikan bahwa JSON respons berisi item yang diharapkan.
Selain itu, model ini memungkinkan Anda menguji fulfillment Dialogflow di setelan continuous integration karena endpoint fulfillment dapat berjalan secara lokal, dan Dialogflow API memiliki konsep sesi bawaan.
Contoh pengujian akan terlihat seperti ini:
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'},
]);
});
Cuplikan di atas menggunakan Mocha dan Chai. Lihat contoh kerja lengkap yang ditulis dalam Node.js di Fakta Tentang Google repositori resource.
Mendesain fulfillment yang dapat diuji unit
Kode webhook sering kali berisi logika bisnis kustom yang diandalkan aplikasi Anda untuk memenuhi kebutuhannya. Selain itu, kode webhook juga dapat berisi intent pengendali.
Untuk meningkatkan perincian pengujian unit untuk kode fulfillment Anda, ada baiknya untuk mengatur kode Anda sedemikian rupa sehingga logika bisnis dipisahkan dari rutinitas penanganan intent. Ini berarti memiliki pengendali intent dan logika bisnis dalam modul terpisah, sehingga setiap bagian dapat diuji mereka dapat bekerja secara mandiri.
Sebagai contoh, lihat tindakan contoh shiritori di GitHub.
Dalam contoh tersebut, functions/index.js
dan functions/shiritori/*.js
secara terpisah
berisi pengendali intent dan logika bisnis, sehingga memungkinkan pengujian yang lebih tangguh
Google Workspace.
Pengujian integrasi
Untuk menulis kasus pengujian yang mencakup integrasi antara Dialogflow dan kode webhook fulfillment, baca bagian pengujian integrasi untuk Dialogflow di atas.
Pengujian beban
Sebelum men-deploy Action ke produksi, sebaiknya Anda juga melakukan pengujian beban yang memenuhi syarat untuk menampilkan masalah performa yang menyebabkan penurunan atau gangguan layanan pemenuhan pesanan Anda.
Berikut adalah beberapa contoh masalah performa yang mungkin Anda temukan dalam pengujian beban:
- Komputasi dan memori terbatas
- Pembatasan kuota dari penyedia Anda
- Operasi baca dan tulis data yang lambat
- Masalah konkurensi dalam kode
Skenario pengujian beban bergantung pada pola penggunaan yang diperkirakan atau historis dari Action Anda, tetapi skenario yang biasanya perlu diuji adalah peningkatan beban yang tiba-tiba (lonjakan) dan beban berkelanjutan (merendam).
Mengidentifikasi skenario di mana webhook Anda dipanggil dan berfungsi operasi yang membutuhkan banyak sumber daya. Operasi yang umumnya menggunakan sumber daya yang intensif meliputi membuat kueri database, memanggil API lain, melakukan komputasi, dan memori operasi intensif seperti merender file suara.
Untuk skenario ini, Anda dapat merekam permintaan yang dikirim oleh server Actions on Google ke webhook dari log webhook Anda atau dari log Stackdriver. Anda juga dapat mengambil permintaan dari simulator Konsol Actions.
Setelah Anda memiliki permintaan, Anda bisa menggunakan alat pengujian beban untuk mengetahui bagaimana webhook dalam skenario pengujian beban yang berbeda. Hal berikut menyediakan beberapa contoh pengujian lonjakan dan pengujian ApacheBench.
Pengujian lonjakan
Pengujian lonjakan mengharuskan Anda mengirim permintaan dalam jumlah konstan ke webhook selama beberapa waktu dan tiba-tiba menambah beban. Misalnya, Anda dapat menyiapkan pengujian yang mengirimkan beban 10 kueri per detik (QPS) dengan beberapa lonjakan 60 QPS.
Anda dapat menjalankan perintah ApacheBench berikut untuk mengirim 60 permintaan serentak ke webhook Anda:
ab -n 60 -c 60 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName
Asumsikan bahwa file ActionRequest.json
berisi payload permintaan yang diambil dan dikirim
ke webhook Anda.
Pengujian rendam
Pengujian rendam mengharuskan Anda mengirim permintaan dalam jumlah konstan ke webhook dan mengamati responsnya. Misalnya, Anda dapat menyiapkan pengujian yang mengirim 10-20 QPS secara konstan selama beberapa menit untuk melihat apakah waktu respons meningkat.
Anda dapat menjalankan perintah ApacheBench berikut untuk mengirim 1.200 permintaan, dengan 10 permintaan serentak setiap detik:
ab -t 120 -n 1200 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName
Asumsikan bahwa file ActionRequest.json
berisi payload permintaan yang diambil dan dikirim
ke webhook Anda.
Menganalisis hasil pengujian beban
Setelah menjalankan uji beban, analisis hasil untuk waktu respons webhook. Indikator masalah pada penerapan webhook Anda biasanya merupakan tren seperti waktu respons median yang meningkat setiap kali pengujian dijalankan, atau kasus terburuk waktu respons yang tidak dapat diterima untuk Action Anda.
Pengujian menyeluruh
Pengujian menyeluruh sebelum mengirimkan Action Anda untuk mendapatkan persetujuan menggunakan Simulator konsol Actions. Anda dapat menemukan langkah-langkah untuk pengujian melalui simulator Konsol Actions di simulator Actions dokumentasi tambahan. Melakukan pengujian ini membantu Anda menghilangkan potensi ketidakpastian dari komponen infrastruktur Actions on Google.