Actions on Google platformu için İşlem geliştirmek genellikle doğal dil anlama (NLU) için Dialogflow ve İşleminizin mantığını işleyen Dialogflow karşılama uygulamayı içerir. Kod tabanınızda testlerin olması, İşleminizin üretimde beklendiği gibi çalıştığından emin olmanıza yardımcı olur.
İşleminiz için birim, entegrasyon veya uçtan uca testler uygularken Dialogflow aracınızı ve istek karşılamanızı ayrı bileşenler olarak değerlendirmelisiniz.
Şekil 1. Test için dikkate alınacak sistemleri açıklayan akış şeması
Dialogflow aracısını test etme
Dialogflow aracısı ve istek karşılama ayrı bileşenler olarak test edilir. Aşağıdaki alt bölümlerde, İşleminiz için Dialogflow aracısını nasıl kavramsallaştırabileceğiniz ve test edebileceğiniz açıklanmaktadır.
Sorgu giriş ve intent-out sistemi olarak Dialogflow
Dialogflow aracınız bir kullanıcının sorgusunu almaktan, bir niyetle eşleştirmekten ve önceden tanımlanmış tüm varlıkları sorgudan ayıklamaktan sorumludur. Temsilciniz; eşleşen niyeti, parametrelerini ve Actions on Google meta verilerini içeren bir mesaj ileterek karşılamanızla etkileşimde bulunur.
Geliştirici olarak, niyetlerin ve varlıkların yapısı gibi Dialogflow aracısının yapılandırmasını kontrol edersiniz. Actions on Google meta verileri, Actions on Google'dan gelir ve test için doğru verileri içerdiği varsayılır.
Test sırasında aracınızın intent parametrelerini doğru şekilde çıkarmasını ve sorguları niyetlerle eşleştirmesini sağlamaya odaklanın. Bu yaklaşım, temsilcinin performansını değerlendirmek için ölçülebilir bir metrik sağlar. Bu metriği, tek tek test durumları veya bir doğrulama grubu hazırlayıp kullanarak hesaplayabilirsiniz.
2. Şekil. Dialogflow'un sorgu giriş ve intent-out sistemi olarak gösterilmesi
Birim testleri
Dialogflow aracınız için her durumun giriş olarak metin sorgusu beklediği ve çıkış olarak intent meta verileri oluşturduğu testler yazabilirsiniz. Bu meta veri (en azından) eşleşen amacın adını ve eşleşen parametrelerin bir listesini içermelidir.
Dialogflow API'nin detectIntent uç noktası, metin sorgusunu giriş olarak alır ve çözümlenen amacın adını ve çıkarılan parametreleri içeren yapılandırılmış bir çıkış oluşturur. Bu çıkış, aracının niyet eşleştirme performansını değerlendirmek için yararlıdır. Diğer yararlı alanların tam referansı için QueryResult referansını inceleyin.
Örnek bir test şuna benzer:
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'te Mocha ve Chai kullanılmaktadır. Facts About Google (Google Hakkında Bilgi) için Node.js'de yazılan Dialogflow birim testinin tam çalışan örneğine bakın.
Dialogflow API bir sessionId bağımsız değişkeni olarak kabul ettiğinden test dosyalarınız paralel olarak çalıştırılabilir. Sonuç olarak, tek bir Dialogflow API istemcisi kullanırken her görüşme için ayrı bir korumalı alana sahip olabilirsiniz.
Dialogflow API'ye istek yaptığınız için ücretsiz çağrı kotanıza ulaşılırsa ücret alınabilir. Daha fazla bilgi için kotalar ve sınırlar bölümünü inceleyin.
Entegrasyon testleri
Dialogflow API'nin detectIntent uç noktası, üçüncü taraf istek karşılamayı da tetikler. Bu nedenle Dialogflow aracısı ve Dialogflow istek karşılaması arasındaki entegrasyonu kapsayan test senaryoları yazmak mümkündür.
Dialogflow için birim testleri yazma ile entegrasyon testi arasındaki temel fark, entegrasyon testinde webhook'un yanı sıra Dialogflow niyeti ve varlık çıkarmadan gelen yanıtlar için de istekte bulunabilmenizdir.
Node.js'de yazılmış bir entegrasyon testinin tam çalışan örneğini Facts About Google (Google Hakkında Bilgi) deposunda görebilirsiniz.
Dialogflow istek karşılama webhook'unu test etme
Dialogflow aracısı ve Dialogflow istek karşılaması ayrı bileşenler olarak test edilir. Aşağıdaki alt bölümlerde, İşleminizin yerine getirilmesini nasıl kavramsallaştırabileceğiniz ve test edebileceğiniz açıklanmaktadır.
JSON giriş ve JSON çıkış sistemi olarak karşılama
Dialogflow karşılama kodunuz hem istek bekler hem de JSON biçiminde yanıtlar üretir. Sonuç olarak, onu JSON giriş ve JSON çıkışı sistemi olarak düşünerek sipariş karşılama kodunuzu test edebilirsiniz. İstek, hem Dialogflowflow hem de Actions on Google'dan gelen meta verileri içerir. Böylece, istek karşılama işleminizde belirli bir amaç işleyiciyi tetiklemek için gereken her şeye sahiptir.
Bir amaç işleyicinin tetiklenmesini test etmek için İşleminize bir JSON isteği (giriş) gönderirsiniz. Bu istek, internetten erişilebilen istek karşılamanıza iletilir. Ardından istek karşılama, doğrulama için değerlendirilebilecek bir JSON yanıtı (çıkış) üretir.
3. Şekil. Sipariş karşılamanın JSON-in ve JSON-out sistemi olarak gösterilmesi
Birim testleri
Karşılama webhook'u kodunu, JSON girişini kabul eden ve JSON çıkışı oluşturan bir sistem olarak düşünebilirsiniz. Ardından bir İşlemi test etme süreci, karşılamanıza istek sağlamak ve sonuçta ortaya çıkan JSON çıkışını kontrol etmek için basitleştirilmiştir.
Bu size, karşılamayı yerel olarak barındırma ve test için HTTP isteklerini yerel olarak gönderme özgürlüğü sunar. Actions on Google Node.js istemci kitaplığını kullanıyorsanız JSON isteklerini doğrudan istemci kitaplığı ara katman yazılımı katmanına da gönderebilirsiniz.
Webhook kodunu JSON girişleriyle test edip beklenen JSON çıkışlarını alırsanız kontrol ettiğiniz parçaların düzgün çalıştığını makul bir şekilde güvenle söyleyebilirsiniz. Dialogflow ve Actions on Google'ın doğru JSON yüklerini oluşturdukları için düzgün çalıştıklarını varsayabilirsiniz. Bu yalıtım, test yazmak için basitleştirilmiş bir programlama modeli sağlar.
Test sürecinin genel bir özeti şu şekildedir:
- Bir kullanım alanındaki her adım için JSON isteklerini almak amacıyla Actions konsolundaki simülatörü kullanın. Bunları JSON dosyaları olarak kaydedin. Alternatif olarak, webhook referans belgelerindeki bilgileri kullanarak bu istekleri kendiniz de oluşturabilirsiniz.
- Bu yüklerle webhook'u çağırmak için testler yazın.
- Her test için yanıt JSON dosyasının beklenen öğeleri içerdiğinden emin olun.
Ayrıca bu model, istek karşılama uç noktası yerel olarak çalışabildiğinden ve Dialogflow API yerleşik bir oturum kavramına sahip olduğundan Dialogflow karşılama uç noktasının sürekli entegrasyon ayarında test edilmesini sağlar.
Bir test örneği şu şekilde 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'te Mocha ve Chai kullanılmaktadır. Node.js'de yazılmış tam çalışan örneği Google Hakkında Bilgiler deposunda görebilirsiniz.
Birim test edilebilir istek karşılama tasarlama
Webhook kodu genellikle uygulamanızın ihtiyaçlarını karşılamak için kullandığı özel iş mantığını içerir. Webhook kodu ayrıca amaç işleyiciler de içerebilir.
Sipariş karşılama kodunuza yönelik birim testlerinin ayrıntı düzeyini iyileştirmek için kodunuzu iş mantığını intent işleme rutinlerinden ayrılacak şekilde düzenlemek iyi bir uygulamadır. Bu, intent işleyicilerin ve iş mantığının ayrı modüllerde bulunması anlamına gelir. Böylece her parça bağımsız olarak test edilebilir.
Örneğin, GitHub'daki shiritori örnek işlemimize bakın.
Bu örnekte functions/index.js ve functions/shiritori/*.js ayrı olarak intent işleyiciler ile iş mantığını içerir ve daha sağlam test paketlerine olanak tanır.
Entegrasyon testleri
Dialogflow ile istek karşılama webhook'u kodunuz arasındaki entegrasyonu kapsayan test senaryoları yazmak için yukarıdaki Dialogflow için entegrasyon testi bölümünü okuyun.
Yük testleri
İşleminizi üretime dağıtmadan önce, sipariş karşılama hizmetinizin bozulmasına veya kesintiye uğramasına neden olan performans sorunlarını ortaya çıkarmak için webhook karşılama hizmetinize yük testi uygulamanızı da öneririz.
Aşağıda, yük testinde tespit edebileceğiniz performans sorunlarına dair bazı örnekler verilmiştir:
- Sınırlı bilgi işlem ve bellek
- Sağlayıcılarınızın kota kısıtlamaları
- Yavaş veri okuma ve yazma
- Koddaki eşzamanlılık sorunları
Yük testi senaryoları, işleminizin beklenen veya geçmişteki kullanım şekline bağlıdır ancak test edilmesi gereken tipik senaryolar, yükteki (ani artış) ve sürekli yüklemelerdeki (soğuk su) artışlardır.
Webhook'unuzun çağrıldığı ve yoğun kaynak kullanan işlemler gerçekleştirdiği senaryoları belirleyin. Yoğun kaynak kullanan tipik işlemler arasında veritabanı sorgulama, başka bir API çağırma, bilgi işlem ve ses dosyası oluşturma gibi belleği yoğun olarak kullanan işlemler yer alır.
Bu senaryolarda, Actions on Google sunucuları tarafından webhook'a gönderilen istekleri webhook günlüklerinizden veya Stackdriver günlüklerinden yakalayabilirsiniz. İstekleri Actions Console simülatöründen de yakalayabilirsiniz.
İstekler aldıktan sonra, webhook'unuzun farklı yük testi senaryolarında nasıl yanıt verdiğini öğrenmek için bir yük testi aracı kullanabilirsiniz. Aşağıdaki alt bölümlerde, ApacheBench kullanarak ani artış ve sulama testi örnekleri verilmiştir.
Çivi testi
Ani artış testi, webhook'a bir süre sabit sayıda istek göndermenizi ve yükü aniden artırmanızı gerektirir. Örneğin, saniyede 10 sorgu (QPS) yükü gönderen ve yalnızca 60 QPS'lik artışlar sağlayan bir test ayarlayabilirsiniz.
Webhook'unuza 60 eşzamanlı istek göndermek için aşağıdaki ApacheBench komutunu çalıştırabilirsiniz:
ab -n 60 -c 60 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName
ActionRequest.json dosyasının webhook'unuza gönderilen yakalanmış istek yükünü içerdiğini varsayalım.
Sulama testi
Soaks testi için webhook'a sabit sayıda istek göndermeniz ve yanıtı gözlemlemeniz gerekir. Örneğin, yanıt sürelerinin artıp artmadığını görmek için birkaç dakika boyunca 10-20 QPS'lik sabit bir yük gönderen bir test ayarlayabilirsiniz.
Her saniyede 10 eşzamanlı istekle 1.200 istek göndermek için aşağıdaki ApacheBench komutunu çalıştırabilirsiniz:
ab -t 120 -n 1200 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName
ActionRequest.json dosyasının webhook'unuza gönderilen yakalanmış istek yükünü içerdiğini varsayalım.
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 sorun göstergeleri genellikle her test çalıştırmasında artan ortalama yanıt süresi veya İşleminiz için kabul edilemez olan en kötü durum yanıt süresi gibi eğilimlerdir.
Uçtan uca test
İşleminizi onaya göndermeden önce uçtan uca testlerde Actions Console simülasyon aracı kullanılır. Actions Console simülatörü aracılığıyla uçtan uca test adımlarını Actions simülasyon aracı belgelerinde bulabilirsiniz. Bu testleri gerçekleştirmek, Actions on Google altyapı bileşenindeki olası belirsizlikleri ortadan kaldırmanıza yardımcı olur.