Actions on Google प्लैटफ़ॉर्म पर, अक्सर अपनी सामान्य भाषा की समझ (एनएलयू) के लिए, Dialogflow को लागू किया जाता है. साथ ही, Dialogflow को पूरा करना, आपकी सेट की गई कार्रवाई का लॉजिक मैनेज करने वाला होता है. अपने कोडबेस में जांच करने से यह पक्का करने में मदद मिलती है कि आपकी सेट की गई कार्रवाई, प्रोडक्शन में उम्मीद के मुताबिक परफ़ॉर्म कर रही है.
अपनी सेट की गई कार्रवाई के लिए यूनिट, इंटिग्रेशन या एंड-टू-एंड टेस्ट लागू करते समय, आपको अपने Dialogflow एजेंट और फ़ुलफ़िलमेंट को अलग-अलग कॉम्पोनेंट के तौर पर देखना चाहिए.
पहला डायग्राम. जांच के लिए इस्तेमाल किए जाने वाले सिस्टम की जानकारी देने वाला फ़्लोचार्ट
Dialogflow एजेंट की जांच करना
Dialogflow एजेंट और फ़ुलफ़िलमेंट की जांच, अलग-अलग कॉम्पोनेंट के तौर पर की जाती है. नीचे दिए गए सब-सेक्शन में बताया गया है कि अपनी सेट की गई कार्रवाई के लिए, Dialogflow एजेंट को कैसे समझा और टेस्ट किया जा सकता है.
क्वेरी-इन और इंटेंट-आउट सिस्टम के तौर पर डायलॉग फ़्लो
उपयोगकर्ता की क्वेरी का जवाब देने, उसे किसी इंटेंट से मैच करने, और क्वेरी से पहले से तय इकाइयों को निकालने के लिए, आपके Dialogflow एजेंट की ज़िम्मेदारी होती है. आपका एजेंट, मेल खाने वाले इंटेंट, उसके पैरामीटर, और Actions on Google मेटाडेटा वाला एक मैसेज भेजकर आपके ऑर्डर को पूरा करने में मदद करता है.
डेवलपर के तौर पर, आप Dialogflow एजेंट के कॉन्फ़िगरेशन को कंट्रोल करते हैं, जैसे कि इंटेंट और इकाइयों का स्ट्रक्चर. Actions on Google का मेटाडेटा, Actions on Google से मिलता है और यह माना जा सकता है कि इसमें जांच के लिए सही डेटा शामिल है.
टेस्टिंग करते समय, इस बात पर ध्यान दें कि आपका एजेंट इंटेंट पैरामीटर और क्वेरी से मिलती-जुलती क्वेरी को सही तरीके से एक्सट्रैक्ट कर पाए. इस तरीके से, एजेंट की परफ़ॉर्मेंस का आकलन करने के लिए एक मापी जा सकने वाली मेट्रिक मिलती है. इस मेट्रिक का हिसाब, अलग-अलग टेस्ट केस या पुष्टि के सेट को तैयार करके और उनका इस्तेमाल करके लगाया जा सकता है.
दूसरा डायग्राम. क्वेरी-इन और इंटेंट-आउट सिस्टम के तौर पर Dialogflow को दिखाना
यूनिट टेस्ट
Dialogflow एजेंट के लिए, आपके पास ऐसे टेस्ट लिखने का विकल्प होता है जिनमें हर केस, इनपुट के तौर पर टेक्स्ट क्वेरी की उम्मीद करता है. साथ ही, इंटेंट मेटाडेटा को आउटपुट के तौर पर बनाता है. इस मेटाडेटा में मेल खाने वाले इंटेंट का नाम और मेल खाने वाले पैरामीटर की सूची शामिल होनी चाहिए (कम से कम).
Dialogflow API का detectIntent एंडपॉइंट, टेक्स्ट क्वेरी को इनपुट के तौर पर लेता है और एक स्ट्रक्चर्ड आउटपुट जनरेट करता है. इसमें, रिज़ॉल्व किए गए इंटेंट और एक्सट्रैक्ट किए गए पैरामीटर का नाम होता है. यह आउटपुट, एजेंट की इंटेंट-मैचिंग परफ़ॉर्मेंस का आकलन करने के लिए उपयोगी है. काम के दूसरे फ़ील्ड के पूरे रेफ़रंस के लिए, QueryResult रेफ़रंस देखें.
टेस्ट का एक नमूना ऐसा दिखता है:
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');
});
इस स्निपेट में मोका और चाई का इस्तेमाल होता है. Google के बारे में तथ्य के लिए Node.js में लिखे गए Dialogflow यूनिट टेस्ट का पूरा उदाहरण देखें.
आपकी टेस्ट फ़ाइलें एक साथ चल सकती हैं, क्योंकि Dialogflow एपीआई
sessionId को तर्क के तौर पर स्वीकार करता है. इस वजह से, एक ही Dialogflow API क्लाइंट का इस्तेमाल करते समय,
हर बातचीत के लिए एक अलग सैंडबॉक्स हो सकता है.
Dialogflow एपीआई के ज़रिए अनुरोध किए जा रहे हैं. इसलिए, अगर मुफ़्त कॉल का कोटा खत्म हो जाता है, तो आपसे शुल्क लिया जा सकता है. ज़्यादा जानकारी के लिए, कोटेशन और सीमाएं देखें.
इंटिग्रेशन की जांच
Dialogflow API का detectIntent एंडपॉइंट, तीसरे पक्ष के फ़ुलफ़िलमेंट को भी ट्रिगर करता है. इसलिए, ऐसे टेस्ट केस लिखे जा सकते हैं जिनमें Dialogflow एजेंट और Dialogflow के साथ काम करने के लिए इंटिग्रेशन को कवर किया जाता है.
Dialogflow के लिए राइटिंग इंटिग्रेशन और यूनिट टेस्ट के बीच मुख्य अंतर यह है कि इंटिग्रेशन टेस्ट में, वेबहुक के साथ-साथ Dialogflow इंटेंट और इकाई एक्सट्रैक्शन से मिलने वाले रिस्पॉन्स पर दावा किया जा सकता है.
Google के बारे में जानकारी डेटा स्टोर करने की जगह में Node.js में लिखे गए इंटिग्रेशन टेस्ट का पूरा उदाहरण देखें.
Dialogflow फ़ुलफ़िलमेंट वेबहुक की जांच
Dialogflow एजेंट और Dialogflow फ़ुलफ़िलमेंट की जांच, अलग-अलग कॉम्पोनेंट के तौर पर की जाती है. इन सब-सेक्शन में बताया गया है कि अपनी सेट की गई कार्रवाई को बनाने और उसके पूरा होने की जांच कैसे की जा सकती है.
JSON-in और JSON-out सिस्टम के तौर पर फ़ुलफ़िलमेंट
आपका Dialogflow फ़ुलफ़िलमेंट कोड, दोनों ही अनुरोधों की उम्मीद करता है और JSON फ़ॉर्मैट में जवाब देता है. इस वजह से, आप इसे JSON-in और JSON-out सिस्टम के तौर पर मानकर, अपने फ़ुलफ़िलमेंट कोड की जांच कर सकते हैं. अनुरोध में Dialogflow और Actions on Google, दोनों का मेटाडेटा शामिल है, ताकि इसमें आपके फ़ुलफ़िलमेंट में किसी खास इंटेंट हैंडलर को ट्रिगर करने के लिए सभी ज़रूरी चीज़ें मौजूद हों.
किसी इंटेंट हैंडलर के ट्रिगर होने की जांच करने के लिए, आपको अपनी सेट की गई कार्रवाई को JSON अनुरोध (इनपुट) भेजना होगा. यह अनुरोध आपके ऑर्डर को पूरा कर दिया जाता है. इसे इंटरनेट पर ऐक्सेस किया जा सकता है. इसके बाद, फ़ुलफ़िलमेंट एक JSON रिस्पॉन्स (आउटपुट) जनरेट करता है, जिसका आकलन पुष्टि के लिए किया जा सकता है.
तीसरी इमेज. JSON-in और JSON-out सिस्टम में फ़ुलफ़िलमेंट को दिखाने का तरीका
यूनिट टेस्ट
फ़ुलफ़िलमेंट वेबहुक कोड को एक ऐसे सिस्टम के तौर पर देखें जो JSON इनपुट स्वीकार करता है और JSON आउटपुट बनाता है. इसके बाद, कार्रवाई का अनुरोध करने और उससे मिलने वाले आउटपुट JSON की जांच करने के लिए, कार्रवाई को टेस्ट करने की प्रोसेस को आसान बनाया जाता है.
इससे आपको स्थानीय तौर पर फ़ुलफ़िलमेंट होस्ट करने और जांच के लिए एचटीटीपी अनुरोध भेजने की आज़ादी मिलती है. अगर Actions on Google Node.js क्लाइंट लाइब्रेरी का इस्तेमाल किया जा रहा है, तो सीधे क्लाइंट लाइब्रेरी मिडलवेयर लेयर पर भी JSON अनुरोध भेजे जा सकते हैं.
अगर JSON इनपुट के साथ वेबहुक कोड की जांच की जाती है और आपको JSON इनपुट मिल जाते हैं, तो पूरे भरोसे के साथ कहा जा सकता है कि जिन पार्ट को कंट्रोल किया जाता है वे ठीक से काम कर रहे हैं. आप यह मान सकते हैं कि Dialogflow और Actions on Google ठीक से काम कर रहे हैं, क्योंकि वे सही JSON पेलोड जनरेट कर रहे हैं. यह आइसोलेशन, लिखने की जांचों के लिए एक आसान प्रोग्रामिंग मॉडल देता है.
यहां जांच की प्रक्रिया की सामान्य जानकारी दी गई है:
- इस्तेमाल के उदाहरण में हर चरण के लिए JSON अनुरोध पाने के लिए, Actions कंसोल में सिम्युलेटर का इस्तेमाल करें. इन्हें JSON फ़ाइलों के तौर पर सेव करें. इसके अलावा, वेबहुक रेफ़रंस दस्तावेज़ में मौजूद जानकारी का इस्तेमाल करके, खुद भी ये अनुरोध बनाए जा सकते हैं.
- इन पेलोड की मदद से वेबहुक को शुरू करने के लिए, टेस्ट लिखें.
- हर जांच के लिए, पक्का करें कि रिस्पॉन्स JSON में वे आइटम मौजूद हों जिनकी उम्मीद थी.
इसके अलावा, इस मॉडल की मदद से आप लगातार इंटिग्रेशन की सेटिंग में Dialogflow के मुताबिक काम करने की जांच कर सकते हैं, क्योंकि फ़ुलफ़िलमेंट एंडपॉइंट स्थानीय तौर पर चल सकता है. साथ ही, Dialogflow API में सेशन का कॉन्सेप्ट पहले से मौजूद होता है.
टेस्ट का एक उदाहरण:
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'},
]);
});
ऊपर दिए गए स्निपेट में मोका और चाई का इस्तेमाल किया गया है. Google के बारे में जानकारी डेटा स्टोर करने की जगह में Node.js में लिखा गया पूरा उदाहरण देखें.
यूनिट-टेस्टेबल फ़ुलफ़िलमेंट को डिज़ाइन करना
वेबहुक कोड में अक्सर पसंद के मुताबिक बनाए गए कारोबारी नियम होते हैं. इन नियमों पर आपका ऐप्लिकेशन निर्भर करता है, ताकि वे अपनी ज़रूरतों को पूरा कर सकें. इसके अलावा, वेबहुक कोड में इंटेंट हैंडलर भी शामिल हो सकते हैं.
फ़ुलफ़िलमेंट कोड के लिए यूनिट टेस्ट की जानकारी का स्तर बढ़ाने के लिए, बेहतर होगा कि आप कोड को इस तरह से व्यवस्थित करें कि कारोबारी लॉजिक, इंटेंट हैंडलिंग रूटीन से अलग हो जाए. इसका मतलब है कि इसके पास अलग-अलग मॉड्यूल में इंटेंट हैंडलर और बिज़नेस लॉजिक है. इसलिए, हर हिस्से की अलग से जांच की जा सकती है.
उदाहरण के लिए, GitHub पर हमारा Shiritori सैंपल ऐक्शन देखें.
उस नमूने में, functions/index.js और functions/shiritori/*.js अलग-अलग हैं, जिनमें इंटेंट हैंडलर और बिज़नेस लॉजिक शामिल हैं. इससे, आपको ज़्यादा मज़बूत टेस्ट सुइट बनाने में मदद मिलती है.
इंटिग्रेशन की जांच
Dialogflow और आपके फ़ुलफ़िलमेंट वेबहुक कोड के बीच इंटिग्रेशन को कवर करने वाले टेस्ट केस लिखने के लिए, ऊपर दिया गया Dialogflow के लिए इंटिग्रेशन टेस्टिंग सेक्शन पढ़ें.
टेस्ट लोड करें
अपनी सेट की गई कार्रवाई को प्रोडक्शन में लागू करने से पहले, हमारा यह भी सुझाव है कि आप वेबहुक फ़ुलफ़िलमेंट को लोड करके टेस्ट करें. इससे, परफ़ॉर्मेंस से जुड़ी उन समस्याओं का पता चलेगा जिनकी वजह से ऑर्डर पूरा करने की सेवा में रुकावट या डिग्रेडेशन होती है.
परफ़ॉर्मेंस की समस्याओं के कुछ उदाहरण यहां दिए गए हैं, जो लोड जांच के दौरान पता चल सकते हैं:
- सीमित कंप्यूट और मेमोरी
- सेवा देने वाली कंपनियों की तरफ़ से लगाई गई कोटा से जुड़ी पाबंदियां
- डेटा को पढ़ने और उसमें बदलाव करने में देरी हो रही है
- कोड में कॉनमुद्रा (एक साथ काम करने वाली) से जुड़ी समस्याएं
लोड की जांच की स्थितियां, आपकी सेट की गई कार्रवाई के अनुमानित या पुराने इस्तेमाल के पैटर्न पर निर्भर करती हैं. हालांकि, आम तौर पर इसकी जांच की जाती है: लोड में अचानक बढ़ोतरी (स्पाइक) और लंबे समय तक बने रहने वाले लोड (सोक) में.
उन स्थितियों की पहचान करें जहां आपके वेबहुक को कॉल किया जाता है और वह संसाधनों से चलने वाले काम करता है. आम संसाधनों पर ज़्यादा ध्यान देने वाली कार्रवाइयों में, डेटाबेस के बारे में क्वेरी करना, दूसरे एपीआई को कॉल करना, कंप्यूट करना, और साउंड फ़ाइल को रेंडर करने जैसे मेमोरी वाले काम शामिल होते हैं.
इन स्थितियों के लिए, Actions on Google के सर्वर से अपने वेबहुक लॉग या स्टैकड्राइवर लॉग पर वेबहुक पर भेजे गए अनुरोधों को कैप्चर किया जा सकता है. आपके पास ऐक्शन कंसोल सिम्युलेटर से भी अनुरोध कैप्चर करने का विकल्प होता है.
अनुरोध मिलने के बाद, लोड टेस्टिंग टूल का इस्तेमाल करके यह पता लगाया जा सकता है कि वेबहुक, लोड की अलग-अलग स्थितियों में कैसा काम करता है. यहां दिए गए सब-सेक्शन में, ApacheBench का इस्तेमाल करके स्पाइक टेस्टिंग और सोक टेस्टिंग के कुछ उदाहरण दिए गए हैं.
स्पाइक टेस्टिंग
स्पाइक टेस्टिंग के लिए ज़रूरी है कि आप वेबहुक पर कुछ समय के लिए लगातार अनुरोध भेजें और फिर अचानक लोड बढ़ा दें. उदाहरण के लिए, ऐसा टेस्ट सेट अप किया जा सकता है जो 60 क्यूपीएस की कुछ बढ़ोतरी के साथ 10 क्वेरी प्रति सेकंड (क्यूपीएस) का लोड भेजता है.
अपने वेबहुक पर एक साथ 60 अनुरोध भेजने के लिए, ApacheBench का यह निर्देश चलाया जा सकता है:
ab -n 60 -c 60 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName
मान लें कि ActionRequest.json फ़ाइल में, आपके वेबहुक पर भेजा गया कैप्चर किया गया अनुरोध पेलोड शामिल है.
सोक टेस्टिंग
सोक टेस्टिंग के लिए ज़रूरी है कि आप वेबहुक पर लगातार कई अनुरोध भेजें और रिस्पॉन्स का ध्यान रखें. उदाहरण के लिए, ऐसा टेस्ट सेट अप किया जा सकता है जो कई मिनट तक 10-20 क्यूपीएस का लगातार लोड भेजे. इससे यह पता चलता है कि रिस्पॉन्स मिलने में लगने वाला समय बढ़ रहा है या नहीं.
हर सेकंड एक साथ 10 अनुरोध भेजकर, 1,200 अनुरोध भेजने के लिए ApacheBench का यह कमांड चलाया जा सकता है:
ab -t 120 -n 1200 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName
मान लें कि ActionRequest.json फ़ाइल में, आपके वेबहुक पर भेजा गया कैप्चर किया गया अनुरोध पेलोड शामिल है.
लोड की जांच के नतीजों का विश्लेषण करना
लोड होने से जुड़ी जांच करने के बाद, वेबहुक के जवाब मिलने में लगने वाले समय के नतीजों का विश्लेषण करें. आपके वेबहुक को लागू करने में आने वाली समस्याओं के संकेत आम तौर पर ट्रेंड होते हैं. जैसे, हर टेस्ट रन के साथ बढ़ने वाला मीडियन रिस्पॉन्स टाइम या सबसे खराब स्थिति में, जवाब देने में लगने वाला ऐसा समय जो आपकी सेट की गई कार्रवाई के लिए स्वीकार नहीं किया जा सकता.
शुरू से अंत तक के परीक्षण
मंज़ूरी के लिए अपनी कार्रवाई सबमिट करने से पहले एंड-टू-एंड टेस्टिंग, Actions कंसोल सिम्युलेटर का इस्तेमाल करती है. आप ऐक्शन सिम्युलेटर दस्तावेज़ में, Actions कंसोल सिम्युलेटर के ज़रिए पूरी तरह से टेस्ट करने के तरीके देख सकते हैं. ये परीक्षण करने से आपको Actions on Google इंफ़्रास्ट्रक्चर कॉम्पोनेंट से संभावित अनिश्चितताओं को दूर करने में मदद मिलती है.