Praktik terbaik pengujian

Pengembangan Action untuk platform Actions on Google sering kali melibatkan implementasi Dialogflow untuk natural language understanding (NLU) dan fulfillment Dialogflow, yang menangani logika untuk Action Anda. Melakukan pengujian di codebase akan membantu memastikan bahwa Action Anda berfungsi seperti yang diharapkan dalam produksi.

Saat mengimplementasikan unit, integrasi, atau pengujian menyeluruh untuk Action, Anda harus mempertimbangkan agen dan fulfillment Dialogflow sebagai komponen terpisah.

Gambar 1. Diagram alir yang menjelaskan sistem yang perlu dipertimbangkan untuk pengujian

Perhatian: Halaman ini terutama berfokus pada pengembangan Action menggunakan Dialogflow. Meskipun beberapa konsep pengujian yang disajikan juga berlaku untuk developer yang menggunakan Actions SDK, ada perbedaan yang melekat di antara kedua sistem ini. Developer yang bekerja dengan Actions SDK perlu mempertimbangkan cara menguji solusi NLU kustom mereka karena integrasinya mungkin sangat berbeda dengan komponen agen Dialogflow.

Menguji agen Dialogflow

Agen dan fulfillment Dialogflow diuji sebagai komponen terpisah. Sub-bagian berikut menjelaskan cara membuat konsep dan menguji agen Dialogflow untuk Action Anda.

Dialogflow sebagai sistem query-in dan intent-out

Agen Dialogflow Anda bertanggung jawab mengambil kueri pengguna, mencocokkannya dengan intent, dan mengekstrak entity yang telah ditetapkan sebelumnya dari kueri. Agen berinteraksi dengan fulfillment Anda dengan meneruskan pesan yang berisi intent yang cocok, 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 diasumsikan berisi data yang benar untuk pengujian.

Saat melakukan pengujian, fokuslah untuk membuat agen Anda mampu mengekstrak parameter intent dan mencocokkan kueri dengan intent dengan benar. Pendekatan ini memberikan metrik yang dapat diukur untuk menilai performa agen. Anda dapat menghitung metrik ini dengan menyiapkan dan menggunakan kasus pengujian individu atau set validasi.

Gambar 2. Representasi Dialogflow sebagai sistem query-in dan intent-out

Pengujian unit

Untuk agen Dialogflow, Anda dapat menulis pengujian dengan setiap kasus mengharapkan kueri teks sebagai input dan menghasilkan metadata intent sebagai output. Metadata ini harus (minimal) berisi nama intent yang cocok dan daftar parameter yang cocok.

Endpoint detectIntent Dialogflow API mengambil 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 referensi lengkap tentang kolom berguna lainnya, lihat referensi QueryResult.

Contoh pengujian 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 contoh lengkap pengujian unit Dialogflow yang ditulis di Node.js untuk mengetahui Fakta Tentang Google.

File pengujian Anda dapat dijalankan secara paralel karena Dialogflow API menerima sessionId sebagai argumen. Karena itu, Anda dapat memiliki sandbox terpisah untuk setiap percakapan saat menggunakan satu klien Dialogflow API.

Karena Anda membuat permintaan terhadap Dialogflow API, biaya mungkin dikenakan jika kuota panggilan gratis tercapai. Lihat kuota dan batas untuk mengetahui informasi selengkapnya.

Catatan: Endpoint detectIntent juga memicu fulfillment Dialogflow, yang dapat menyebabkan panggilan jaringan tambahan. Anda dapat mengaktifkan atau menonaktifkan fulfillment untuk setiap intent di bagian Fulfillment pada halaman intent tersebut.

Pengujian integrasi

Endpoint detectIntent Dialogflow API juga memicu fulfillment pihak ketiga. Dengan demikian, Anda dapat menulis kasus pengujian yang mencakup integrasi antara agen Dialogflow dan fulfillment Dialogflow.

Perbedaan utama antara penulisan integrasi dan pengujian unit untuk Dialogflow adalah bahwa, dalam pengujian integrasi, Anda dapat menyatakan respons yang berasal dari webhook serta intent Dialogflow dan ekstraksi entity.

Lihat contoh lengkap pengujian integrasi yang ditulis dalam Node.js di repositori Fakta Tentang Google.

Menguji webhook fulfillment Dialogflow

Agen Dialogflow dan fulfillment Dialogflow diuji sebagai komponen terpisah. Subbagian berikut menjelaskan cara membuat konsep dan menguji fulfillment untuk Action Anda.

Fulfillment sebagai sistem JSON-in dan JSON-out

Kode fulfillment Dialogflow Anda mengharapkan permintaan dan menghasilkan respons dalam format JSON. Akibatnya, Anda dapat menguji kode fulfillment dengan menganggapnya sebagai sistem JSON-in dan JSON-out. Permintaan tersebut berisi metadata dari Dialogflow dan Actions on Google, sehingga memiliki semua yang diperlukan untuk memicu pengendali intent tertentu dalam fulfillment Anda.

Untuk menguji pemicuan pengendali intent, kirim permintaan (input) JSON ke Action Anda. Permintaan ini diteruskan ke fulfillment Anda, yang dapat diakses di internet. Fulfillment kemudian menghasilkan respons JSON (output), yang dapat dinilai untuk validasi.

Gambar 3. Representasi fulfillment sebagai sistem JSON-in dan JSON-out

Pengujian unit

Anggaplah kode webhook fulfillment sebagai sistem yang menerima input JSON dan menghasilkan output JSON. Proses pengujian Action kemudian disederhanakan untuk memberikan permintaan ke fulfillment Anda dan memeriksa JSON output yang dihasilkan.

Hal ini memberi Anda kebebasan untuk menghosting fulfillment secara lokal dan mengirim permintaan HTTP secara lokal untuk pengujian. Jika menggunakan library klien Node.js Actions on Google, Anda juga dapat mengirim permintaan JSON langsung ke lapisan middleware library klien.

Jika Anda menguji kode webhook dengan input JSON dan menerima output JSON yang diharapkan, maka Anda dapat mengatakan dengan keyakinan yang wajar bahwa bagian yang Anda kontrol berfungsi dengan benar. Anda dapat berasumsi bahwa Dialogflow dan Actions on Google berfungsi dengan benar karena keduanya menghasilkan payload JSON yang benar. Pemisahan ini menyediakan model pemrograman yang disederhanakan untuk menulis pengujian.

Berikut adalah garis besar umum proses pengujian:

1. Gunakan simulator di konsol Actions untuk mendapatkan permintaan JSON untuk setiap langkah dalam kasus penggunaan. Simpan sebagai file JSON. Atau, Anda dapat membuat permintaan tersebut sendiri menggunakan informasi dari dokumentasi referensi webhook.
2. Tulis pengujian untuk memanggil webhook dengan payload ini.
3. Untuk setiap pengujian, pastikan JSON respons berisi item yang diharapkan.

Selain itu, model ini memungkinkan Anda menguji fulfillment Dialogflow dalam setelan continuous integration karena endpoint fulfillment dapat berjalan secara lokal, dan Dialogflow API memiliki konsep sesi bawaan.

Contoh pengujian 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 repositori Fakta Tentang Google.

Mendesain fulfillment yang dapat diuji unit

Kode webhook sering kali berisi logika bisnis kustom yang diandalkan aplikasi untuk memenuhi kebutuhannya. Selain itu, kode webhook juga dapat berisi pengendali intent.

Untuk meningkatkan perincian pengujian unit untuk kode fulfillment Anda, praktik yang baik adalah 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 secara independen.

Sebagai contoh, lihat contoh tindakan shiritori di GitHub. Dalam contoh tersebut, functions/index.js dan functions/shiritori/*.js berisi pengendali intent dan logika bisnis secara terpisah, sehingga memungkinkan rangkaian pengujian yang lebih andal.

Pengujian integrasi

Untuk menulis kasus pengujian yang mencakup integrasi antara Dialogflow dan kode webhook fulfillment Anda, baca bagian pengujian integrasi untuk Dialogflow di atas.

Pengujian beban

Sebelum men-deploy Action ke produksi, sebaiknya uji beban fulfillment webhook Anda untuk menampilkan masalah performa yang menyebabkan degradasi atau gangguan layanan fulfillment Anda.

Berikut adalah beberapa contoh masalah performa yang mungkin Anda temukan dalam pengujian beban:

• Komputasi dan memori terbatas
• Pembatasan kuota dari penyedia Anda
• Pembacaan dan penulisan data yang lambat
• Masalah serentak dalam kode

Skenario pengujian beban bergantung pada pola penggunaan yang diharapkan atau historis dari Action Anda, tetapi skenario umum yang akan diuji adalah peningkatan beban (lonjakan) dan pemuatan berkelanjutan (merendam) yang tiba-tiba.

Identifikasi skenario saat webhook Anda dipanggil, lalu webhook akan melakukan operasi yang menggunakan banyak resource. Operasi yang menggunakan banyak resource biasanya meliputi kueri database, memanggil API lain, menjalankan komputasi, dan operasi yang intensif memori seperti merender file suara.

Untuk skenario ini, Anda dapat menangkap permintaan yang dikirim oleh server Actions on Google ke webhook dari log webhook atau dari log Stackdriver. Anda juga dapat mengambil permintaan dari simulator Konsol Actions.

Setelah mendapatkan permintaan, Anda dapat menggunakan alat pengujian beban untuk mengetahui respons webhook Anda dalam berbagai skenario pengujian beban. Subbagian berikut memberikan beberapa contoh pengujian lonjakan dan pengujian rendam menggunakan ApacheBench.

Pengujian lonjakan

Pengujian lonjakan mengharuskan Anda mengirim permintaan dalam jumlah yang konstan ke webhook selama beberapa waktu dan tiba-tiba meningkatkan 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:

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

Asumsikan file ActionRequest.json berisi payload permintaan yang ditangkap yang dikirim ke webhook Anda.

Pengujian rendam

Pengujian soak mengharuskan Anda mengirim permintaan dalam jumlah yang konstan ke webhook dan mengamati responsnya. Misalnya, Anda dapat menyiapkan pengujian yang mengirimkan beban konstan 10-20 QPS 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 file ActionRequest.json berisi payload permintaan yang ditangkap yang dikirim ke webhook Anda.

Menganalisis hasil pengujian beban

Setelah menjalankan pengujian beban, analisis hasil untuk waktu respons webhook. Indikator masalah dalam implementasi webhook biasanya berupa tren seperti waktu respons median yang meningkat seiring berjalannya pengujian, atau waktu respons kasus terburuk yang tidak dapat diterima untuk Action Anda.

Pengujian menyeluruh

Pengujian menyeluruh sebelum mengirimkan Action untuk disetujui menggunakan Simulator Konsol Action. Anda dapat menemukan langkah-langkah untuk pengujian menyeluruh melalui simulator Konsol Action dalam dokumentasi Simulator Action. Menjalankan pengujian ini membantu Anda menghapus potensi ketidakpastian dari komponen infrastruktur Actions on Google.