En iyi uygulamaları test etme (Dialogflow)

Actions on Google platformuna yönelik işlem geliştirme genellikle doğal dil anlayışı için Dialogflow'u uygulama (NLU) ve İşleminizin mantığını işleyen Dialogflow istek karşılama. Kod tabanınızda testler olması, İşleminizin beklendiği gibi performans göstermesine yardımcı olur emin olabilirsiniz.

İşleminiz için birim, entegrasyon veya uçtan uca test uygularken Dialogflow aracınızı ve istek karşılamayı ayrı bileşenler olarak düşünmelisiniz.

Akış şeması, kullanıcı sorgusundan Actions on Google, Dialogflow,
ve sonunda kullanıcıya geri dönen bir istek karşılama webhook.

Şekil 1. Test için dikkate alınacak sistemleri açıklayan akış şeması

Dialogflow aracısını test etme

Dialogflow aracısı ve karşılama, ayrı bileşenler olarak test edilir. İlgili içeriği oluşturmak için kullanılan aşağıdaki alt bölümlerde Dialogflow'u nasıl kavrayıp test edebileceğiniz aracınız var.

Giriş ve çıkış sistemi olarak Dialogflow

Dialogflow aracınız bir kullanıcının sorgusunu alıp bir amaç ve sorgudan önceden tanımlanmış varlıkları ayıklamaktır. Temsilciniz kullanıcı, eşleşen e-postayı içeren bir mesaj ileterek intent, parametreleri ve Actions on Google meta verileri bulunur.

Geliştirici olarak, Dialogflow aracısının yapılandırmasını siz belirlersiniz. amaçların ve varlıkların yapısı. Actions on Google meta verileri, Actions on Google'dır ve test için doğru verileri içerdiği varsayılabilir.

Test sırasında aracınızın niyeti doğru şekilde ayıklamasına odaklanın amaca yönelik eşleştirme sorguları için kullanılır. Bu yaklaşım, Aracının performansını değerlendirmek için ölçülebilir bir metrik Şunları yapabilirsiniz: bu metriği hesaplamak için, tek tek test durumları hazırlayıp kullanarak veya doğrulama seti var.

Bir Dialogflow aracısı giriş olarak bir metin sorgusu ve
intent ve çıkış olarak ayıklanan intent parametreleri.

Şekil 2. Dialogflow'un sorgu giriş ve amaç çıkarma sistemi olarak temsil edilmesi

Birim testleri

Dialogflow aracınız için her vakanın bir metin beklediği testler yazabilirsiniz. sorgusunu girdi olarak kullanır ve çıkış olarak niyet meta verilerini üretir. Bu meta veri en azından, eşleşen amacın adını ve eşleşen anahtar kelimelerin listesini içermelidir. parametreleridir.

Dialogflow API'nin detectIntent uç noktası girdi olarak metin sorgusunu alır ve şunu içeren yapılandırılmış bir çıktı üretir: çözümlenen amacın ve ayıklanan parametrelerin adı. Bu çıkış faydalı aracını kullanın. Eksiksiz bir referans için QueryResult referansını inceleyin.

Örnek test aşağıdaki gibi görünür:

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

Bu snippet, Mocha ve Chai'yi kullanmaktadır. Tamamını göster için Node.js’de yazılan Dialogflow birim testinin çalışan örneği Google Hakkında Bilgiler.

Dialogflow API şunu kabul ettiği için test dosyalarınız paralel olarak çalıştırılabilir: sessionId adresini bağımsız değişken olarak kullanın. Sonuç olarak, her biri için ayrı bir korumalı alan istemciler arasında geçiş yapabilir.

Dialogflow API'ye yönelik istek yaptığınız için bir ücret ücretsiz arama kotanıza ulaşıldığında ücret alınır. Kota ve sınırları inceleyin konulu videomuzu izleyin.

Entegrasyon testleri

Dialogflow API'nin detectIntent uç noktası da üçüncü taraf sipariş karşılamayı tetikler. Bu nedenle test senaryoları, Dialogflow aracısı ile Dialogflow arasındaki entegrasyonu kapsayan istek karşılamayı da kapsar.

Dialogflow için entegrasyon ve birim testleri yazma arasındaki temel fark: Entegrasyon testinde, webhook'tan gelen yanıtların doğrulanıp Dialogflow niyeti ve varlık çıkarma gibi API'ler kullanılabilir.

Node.js'de yazılmış bir entegrasyon testinin tam çalışan örneğini Google Hakkında Bilgi deposu.

Dialogflow karşılama webhook'unu test etme

Dialogflow aracısı ve Dialogflow karşılama özelliği ayrı olarak test edilir. bileşenlerine ayıralım. Aşağıdaki alt bölümlerde kavrayışınızı nasıl İşleminizin test karşılamayı.

JSON giriş ve JSON çıkış sistemi olarak sipariş karşılama

Dialogflow sipariş karşılama kodunuz hem istek bekler hem de yanıt üretir: JSON biçimindedir. Sonuç olarak, sipariş karşılama kodunuzu JSON giriş ve çıkış sistemleri olarak da kullanabilirsiniz. İstek, hem kaynak hem de Dialogflow ve Actions on Google ile çalışır. Böylece, bir belirli bir amaç işleyiciyi kullanın.

Niyet işleyicinin tetiklenmesini test etmek için şuraya bir JSON isteği (giriş) gönderirsiniz: İşleminiz. Bu istek, şu tarihte erişilebilen karşılama sayfanıza iletildi: internet. Daha sonra, istek karşılama tarafından bir JSON yanıtı (çıkış) üretilir. değerlendirilmesi gerekir.

İstek karşılama, JSON istek girişi ve webhook JSON ile temsil edilebilir.
yanıt çıkışı.

Şekil 3. Bir istek karşılamanın JSON giriş ve JSON çıkış sistemi olarak gösterilmesi

Birim testleri

Karşılama webhook kodunu, JSON girişini kabul eden bir sistem olarak düşünebilirsiniz. JSON çıkışı üretir. Böylece bir İşlemi test etme süreci basitleştirilmiştir. ve sonuçta ortaya çıkan JSON'u kontrol ederek, sipariş karşılamaya bir istek yapılmasını sağlar.

Bu sayede, istek karşılamayı yerel olarak barındırma ve HTTP gönderme özgürlüğüne sahip olursunuz. yerel olarak istekte bulunabilirsiniz. Actions on Google Node.js kullanıyorsanız JSON isteklerini doğrudan istemci kitaplığına da gönderebilirsiniz katman yazılımı katmanıdır.

Webhook kodunu JSON girişleriyle test edip beklenen JSON'u alırsanız kontrol ettikten sonra, kontrol ettiğiniz bölümlerin düzgün çalışır. Dialogflow'un ve Actions on Google'ın çalıştığını varsayabilirsiniz. doğru JSON yüklerini oluşturduğundan emin olun. Bu izolasyon test yazmak için basitleştirilmiş bir programlama modeli sunar.

Test sürecinin genel bir özetini aşağıda bulabilirsiniz:

  1. Actions Console'daki simülatör kullanarak tek kullanımlık olabilir. Bunları JSON dosyaları olarak kaydedin. Alternatif olarak bilgileri kullanarak bu istekleri kendiniz webhook referans belgelerine göz atın.
  2. Bu yüklerle webhook'u çağırmak için testler yazın.
  3. Her test için, yanıt JSON dosyasının beklenen öğeleri içerdiğinden emin olun.

Ayrıca bu model, Dialogflow istek karşılamayı sürekli entegrasyon ayarı vardır. Bunun nedeni, karşılama uç noktasının yerel olarak Dialogflow API'de yerleşik bir oturum kavramı vardır.

Örnek bir test şöyle görünür:

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

Yukarıdaki snippet, Mocha ve Chai'yi kullanmaktadır. Bkz. Google Hakkında Bilgiler bölümünde, Node.js'de yazılmış tam çalışan bir örnek depodur.

Birim tarafından test edilebilir istek karşılamayı tasarlama

Webhook kodu, genellikle uygulamanızın temel aldığı özel iş mantığı içerir. üzerine konuşacağız. Ayrıca, webhook kodu intent içerebilir. işleyicileri tarafından desteklenmektedir.

Sipariş karşılama kodunuz için birim testlerinin ayrıntı düzeyini artırmak istiyorsanız kodunuzu iş mantığınıza ve işletme mantığınıza uygun olacak şekilde ayrı olarak ele alınır. Yani, amaca yönelik ve iş mantığını ayrı modüller halinde destekler. Böylece her parça, bağımsız olarak değiştirebilirsiniz.

Örneğin, GitHub'daki shiritori örnek işlemimize bakın. Bu örnekte functions/index.js ve functions/shiritori/*.js ayrı ayrı Amaç işleyicileri ve iş mantığını içerir. Bu da testin daha güvenilir olmasını sağlar. süitleri.

Entegrasyon testleri

Dialogflow ile Dialogflow entegrasyon testi bölümünü okuyun. bölümünü ziyaret edin.

Yük testleri

İşleminizi üretime dağıtmadan önce düşüşe neden olan performans sorunlarını ortaya çıkarmak için webhook karşılama sipariş karşılama hizmetinizin kesintiye uğraması.

Aşağıda, yük testinde karşılaşabileceğiniz performans sorunlarına bazı örnekler verilmiştir:

  • Sınırlı işlem ve bellek
  • Sağlayıcılarınızın kota kısıtlamaları
  • Yavaş veri okuma ve yazma işlemleri
  • Koddaki eşzamanlılık sorunları

Yük testi senaryoları, yük testinin beklenen veya geçmiş kullanım kalıbına bağlıdır. ancak test edilmesi gereken tipik senaryolar yükteki ani artışlardır (artış) ve sürekli yük (soğutma).

Webhook'unuzun çağrıldığı ve performans gösterdiği senaryoları belirleyin ve yoğun kaynak kullanan işlemler. Tipik kaynak yoğun işlemler şunlardır: veritabanını sorgulama, başka bir API çağırma, işlem yapma ve bellek veya ses dosyası oluşturmak gibi yoğun işlemler.

Bu senaryolarda, Actions on Google sunucuları tarafından gönderilen istekleri yakalayabilirsiniz webhook günlüklerinizden veya Stackdriver günlüklerinden webhook'a. Ayrıca transkriptinizi Actions Console simülasyon aracından istekleri yakalama

İstekleri aldıktan sonra, yük testi aracını kullanarak webhook farklı yük testi senaryolarında yanıt verir. Aşağıdakiler alt bölümler, ani artış testi ve soğutma testi için ApacheBench olarak değiştirin.

Ani artış testi

Ani artış testi için webhook'a sabit sayıda istek göndermeniz gerekir. yükü aniden artırır. Örneğin, Yeşil Ofis projenizde 60 QPS'lik birkaç artışla saniyede 10 sorgu (QPS) gönderir.

60 eşzamanlı istek göndermek için aşağıdaki ApacheBench komutunu çalıştırabilirsiniz ekleyin:

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

ActionRequest.json dosyasının, gönderilen yakalanmış istek yükünü içerdiğini varsayın bağlayın.

Havuz testi

Soak testi için webhook'a sabit sayıda istek göndermeniz gerekir. yanıtı gözlemleyin. Örneğin, bir anahtar kelimeden oluşan bir yanıt sürelerinin olup olmadığını görmek için birkaç dakika boyunca 10-20 QPS arasında sabit yük artırmış olabilir.

Aşağıdaki ApacheBench komutunu çalıştırarak 10 taneyle 1.200 istek gönderebilirsiniz her saniyede eşzamanlı istek sayısı:

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

ActionRequest.json dosyasının, gönderilen yakalanmış istek yükünü içerdiğini varsayın bağlayın.

Yük testi sonuçlarını analiz etme

Yük testlerini çalıştırdıktan sonra, webhook yanıt sürelerine ilişkin sonuçları analiz edin. Webhook uygulamanızdaki sorunların göstergeleri genellikle her test çalıştırmasında veya en kötü senaryoda artan ortalama yanıt süresi İşleminiz için kabul edilemez yanıt süresi.

Uçtan uca test

İşleminizi onaya göndermeden önceki uçtan uca test, Actions Console simülasyon aracı. Uçtan uca için gereken adımları Actions simülatöründeki Actions konsolu simülatörü aracılığıyla test etme belgelerinden faydalanabilirsiniz. Bu testleri yapmak, potansiyel belirsizlikleri ortadan kaldırmanıza yardımcı olur Actions on Google altyapı bileşeninden alınır.