שיטות מומלצות לבדיקה (Dialogflow)

לעיתים קרובות, במסגרת פיתוח פעולה עבור פלטפורמת Actions on Google יש צורך להטמיע את Dialogflow להבנת השפה הטבעית שלו (NLU) ומילוי הזמנות של Dialogflow, שמטפל בלוגיקה של הפעולה שלכם. בעזרת בדיקות ב-codebase, אפשר לוודא שהפעולה פועלת כצפוי בסביבת הייצור.

כשמטמיעים בדיקות יחידה, שילוב או בדיקות מקצה לקצה לפעולה צריך להתייחס לסוכן Dialogflow ולמילוי ההזמנות כרכיבים נפרדים.

תרשים זרימה מתקדם משאילתת משתמש אל Actions on Google, Dialogflow, וה-webhook של מילוי הבקשה, שבסופו של דבר יחזרו למשתמש.

איור 1. תרשים זרימה שמתאר מערכות שכדאי לבדוק

בדיקת נציג של Dialogflow

הסוכן ומילוי ההזמנות של Dialogflow נבדקים כרכיבים נפרדים. בקטעי המשנה הבאים מוסבר איך אפשר להגות ולבדוק את Dialogflow עבור הפעולה שלכם.

Dialogflow במקרה של מערכת שנותנת מענה לשאילתות והכוונה אוטומטית

הנציג ב-Dialogflow אחראי לקבל שאילתה של משתמש, ולהתאים אותה Intent, ולחלץ ישויות מוגדרות מראש מהשאילתה. הנציג שלך מקיים אינטראקציה עם מילוי ההזמנה על ידי העברת הודעה שכוללת את ההתאמה Intent, הפרמטרים שלו והמטא-נתונים של Actions on Google.

כמפתחים, אתם שולטים בהגדרות של הנציג ב-Dialogflow, למשל את המבנה של כוונות וישויות. המטא-נתונים של Actions on Google מגיעים פעולות ב-Google, ואפשר להניח שהן מכילות את הנתונים הנכונים לבדיקה.

במהלך הבדיקה, חשוב להתמקד בכך שהנציג יוכל לחלץ את הכוונה בצורה נכונה והתאמה של שאילתות ל-Intent, הגישה הזאת מספקת זהו מדד שניתן לכימות לצורך הערכת הביצועים של הנציג. אפשר לחשב את המדד הזה באמצעות הכנה ושימוש במקרי בדיקה ספציפיים, קבוצת אימות.

אפשר לייצג סוכן Dialogflow באמצעות שאילתת טקסט כקלט Intent ופרמטרים של Intent שחולצו כפלט.

איור 2. ייצוג של Dialogflow כמערכת של התחלת שאילתות ו-Intent חוץ

בדיקות יחידה (unit testing)

אתם יכולים לכתוב בדיקות בנציג של Dialogflow שבהן כל פנייה מצפה לקבל הודעת טקסט. בשאילתה כקלט ומפיקה פלט מטא-נתונים של Intent. המטא-נתונים האלה צריך (לכל הפחות) לכלול את השם של הכוונה התואמת ורשימה של התאמות .

נקודת הקצה detectIntent ב-Dialogflow API מקבלת את שאילתת הטקסט כקלט ומפיקה פלט מובנה שמכיל שם ה-Intent המחושב והפרמטרים שחולצו. הפלט הזה מועיל לצורך הערכת ביצועים של תאימות לכוונה של הנציג. לקבלת תמונה מלאה לשדות שימושיים אחרים, ראו חומר עזר בנושא 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');
});

קטע הקוד הזה משתמש ב-Mocha וב-Chai. לצפייה המלאה דוגמת העבודה לבדיקת היחידה של Dialogflow שנכתבה ב-Node.js עבור עובדות על Google.

אפשר להריץ את קובצי הבדיקה במקביל כי Dialogflow API מקבל sessionId כארגומנט. כתוצאה מכך, יכול להיות לכם ארגז חול נפרד עבור כל שיחה באמצעות לקוח יחיד של Dialogflow API.

מאחר ששלחת בקשות נגד Dialogflow API, יכול להיות שהחיוב יהיה שנצברו אם הגעת למכסת השיחות בחינם. למידע נוסף על מכסות ומגבלות אפשר לקבל מידע נוסף.

בדיקות שילוב

גם נקודת הקצה detectIntent ב-Dialogflow API מפעילה מילוי הזמנה על ידי צד שלישי. לכן, אפשר לכתוב מקרי בדיקה בנושא השילוב בין הנציג של Dialogflow לבין Dialogflow

ההבדל העיקרי בין כתיבת בדיקות אינטגרציה לבין כתיבת בדיקות יחידה ב-Dialogflow הוא שבבדיקת השילוב, אפשר להצהיר שהתשובות מגיעות מה-webhook וגם את Intent וחילוץ ישויות ב-Dialogflow.

תוכלו לראות את הדוגמה המלאה של בדיקת אינטגרציה שנכתבה ב-Node.js מאגר עובדות על Google.

בדיקת webhook של מילוי הזמנות ב-Dialogflow

סוכן Dialogflow ומילוי ההזמנות ב-Dialogflow נבדקים כנפרדים רכיבים. בקטעי המשנה הבאים מתוארים האופן שבו ניתן להבין של ביצוע הבדיקה של הפעולה.

מילוי הזמנות כמערכת JSON-in ו-JSON

קוד מילוי ההזמנה של Dialogflow הוא גם מצפה לבקשות וגם מייצר תשובות בפורמט ה-JSON. לכן אפשר לבדוק את קוד האספקה של ההזמנה אותה כמערכת JSON-in ו-JSON-out. הבקשה מכילה מטא-נתונים גם מהמקורות הבאים: Dialogflow ו-Actions on Google, כך שיש בהם את כל המידע הנדרש כדי להפעיל של Intent ספציפי במילוי הבקשה.

כדי לבדוק את הטריגר של handler של Intent, צריך לשלוח בקשת JSON (קלט) אל בפעולה שלך. הבקשה הזו מועברת למילוי ההזמנות, שאפשר לגשת אליו דרך האינטרנט. לאחר מכן מילוי הבקשה יוצר תגובת JSON (פלט), כדי לאמת אותם.

אפשר לייצג מילוי הזמנה באמצעות קלט של בקשת JSON ו-webhook JSON הפלט של התשובה.

איור 3. ייצוג של מילוי הזמנה כמערכת JSON-in ו-JSON

בדיקות יחידה (unit testing)

צריך להתייחס לקוד התגובה לפעולה מאתר אחר (webhook) כמערכת שמקבלת קלט JSON יוצרת פלט JSON. לאחר מכן תהליך בדיקת הפעולה הוא פשוט יותר, שליחת בקשה למילוי ההזמנות ובדיקת קובץ ה-JSON של הפלט שמתקבל.

זה מאפשר לארח את מילוי ההזמנות באופן מקומי ולשלוח HTTP של בקשות באופן מקומי לבדיקה. אם אתם משתמשים ב-Actions on Google Node.js לספריית הלקוח אפשר גם לשלוח בקשות JSON ישירות לספריית הלקוח בשכבת התווכה.

אם בודקים את קוד ה-webhook באמצעות קלט JSON ומקבלים את קובץ ה-JSON הצפוי אז אפשר לומר בביטחון סביר שחלקים שאתם שולטים בהם פועלות כראוי. כנראה ש-Dialogflow ו-Actions on Google פועלים כראוי, כי הן יוצרות מטענים ייעודיים (payloads) נכונים של JSON. הבידוד הזה שמספק מודל תכנות פשוט יותר לכתיבת מבחנים.

תיאור כללי של תהליך הבדיקה:

  1. משתמשים ב-Simulator שבמסוף הפעולות כדי לקבל את בקשות ה-JSON של בכל שלב בתרחיש לדוגמה. שומרים את הקבצים האלה כקובצי JSON. לחלופין, אפשר ליצור את הבקשות האלה בעצמכם בעזרת מידע מסמכי עזר בנושא תגובה לפעולה מאתר אחר (webhook).
  2. כתיבת בדיקות כדי להפעיל את ה-webhook באמצעות מטענים ייעודיים (payloads) האלה.
  3. בכל בדיקה, צריך לוודא שקובץ ה-JSON של התגובה מכיל את הפריטים הצפויים.

בנוסף, המודל הזה מאפשר לבדוק מילוי הזמנות ב-Dialogflow הגדרת אינטגרציה רציפה (CI) כי נקודת הקצה של מילוי הבקשות יכולה לפעול באופן מקומי, וב-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'},
    ]);
});

קטע הקוד שלמעלה משתמש ב-Mocha וב-Chai. לצפייה דוגמה לעבודה מלאה שמופיעה ב-Node.js בקטע Facts about Google של מאגר הנתונים.

עיצוב מילוי הזמנות של יחידה שניתן לבדוק

לרוב, הקוד של תגובה לפעולה מאתר אחר כולל לוגיקה עסקית מותאמת אישית שהאפליקציה שלכם מסתמכת כדי לענות על הצרכים שלו. בנוסף, קוד ה-webhook יכול לכלול גם Intent של ה-handlers שלו.

כדי לשפר את רמת הפירוט של בדיקות היחידה עבור קוד האספקה, מומלץ לארגן את הקוד כך שהלוגיקה העסקית בנפרד מהשגרה של טיפול בכוונה. כלומר, יש גורמים מטפלים בכוונות ולוגיקה עסקית במודולים נפרדים, כך שאפשר לבדוק כל חלק באופן עצמאי.

לדוגמה, אפשר לעיין בפעולה לדוגמה של Shiritori ב-GitHub. בדוגמה הזו, functions/index.js ו-functions/shiritori/*.js בנפרד שכולל את הגורמים המטפלים בכוונות ואת הלוגיקה העסקית, וכך מאפשר לבצע בדיקות מעמיקות יותר סוויטות.

בדיקות שילוב

לכתיבת תרחישים לדוגמה שקשורים לשילוב בין Dialogflow קוד webhook של מילוי הבקשה, אפשר לקרוא את הקטע לבדיקת שילוב עם Dialogflow למעלה.

טעינת בדיקות

לפני פריסת הפעולה בסביבת הייצור, מומלץ גם לבדוק את העומס מילוי הזמנות באמצעות תגובה לפעולה מאתר אחר (webhook) כדי לזהות בעיות בביצועים שגורמות לירידה בביצועים, או הפרעה בשירות מילוי ההזמנות.

ריכזנו כאן כמה דוגמאות לבעיות בביצועים שאתם עשויים להיתקל בהן במהלך בדיקת העומס:

  • מחשוב וזיכרון מוגבלים
  • הגבלות על מכסות מהספקים שלך
  • קריאה וכתיבה של נתונים לאט
  • בעיות בו-זמניות (concurrency) בקוד

תרחישי בדיקת העומסים תלויים בדפוס השימוש הצפוי או ההיסטורי של הפעולה שלך, אבל תרחישים אופייניים לבדיקה הם עליות פתאומיות בעומס (עליות חדות) וטעינות ממושכות (השהייה).

זיהוי תרחישים שבהם ה-webhook נקרא והוא פועל פעולות עתירות משאבים. פעולות אופייניות שצורכות משאבים רבים כוללות שליחת שאילתות למסד נתונים, שליחת קריאה ל-API אחר, ביצוע מחשוב וזיכרון בפעולות אינטנסיביות כמו עיבוד קובץ קול.

בתרחישים האלה, אפשר לתעד בקשות שנשלחו על ידי פעולות בשרתי Google ל-webhook Google מיומני ה-webhook או מיומני Stackdriver. אפשר גם לתעד בקשות באמצעות הסימולטור של מסוף Actions.

אחרי שתקבלו את הבקשות, תוכלו להשתמש בכלי לבדיקת טעינה כדי לבדוק איך התגובה לפעולה מאתר אחר (webhook) מגיבה בתרחישים שונים של בדיקת עומס. הבאים בקטעי המשנה מספקים כמה דוגמאות של בדיקות שיא ובדיקת ספיגה באמצעות ApacheBench.

בדיקת נקודות שיא

כדי לבצע בדיקת נקודות שיא צריך לשלוח מספר קבוע של בקשות ל-webhook למשך זמן מה ופתאום להגדיל את העומס. לדוגמה, אפשר להגדיר בדיקה ששולח טעינה של 10 שאילתות לשנייה (QPS) עם כמה עליות חדות של 60 QPS.

אפשר להריץ את פקודת ApacheBench הבאה כדי לשלוח 60 בקשות בו-זמנית ל-webhook:

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

נניח שהקובץ ActionRequest.json מכיל את המטען הייעודי (payload) של הבקשה שתועדה נשלח ל-webhook.

בדיקת הספיגה

כדי לבצע בדיקת סוד, צריך לשלוח מספר קבוע של בקשות ל-webhook ובוחנים את התשובה. לדוגמה, אפשר להגדיר בדיקה ששולחת טעינה קבועה של 10-20 QPS למשך כמה דקות כדי לראות אם זמני התגובה עלייה.

אפשר להריץ את פקודת ApacheBench הבאה כדי לשלוח 1200 בקשות, כולל 10 בקשות בו-זמניות בכל שנייה:

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

נניח שהקובץ ActionRequest.json מכיל את המטען הייעודי (payload) של הבקשה שתועדה נשלח ל-webhook.

ניתוח התוצאות של בדיקת העומס

אחרי שמריצים בדיקות טעינה, צריך לנתח את התוצאות של זמני התגובה של ה-webhook. סימנים לבעיות בהטמעת התגובה לפעולה מאתר אחר (webhook) הם בדרך כלל מגמות כמו זמן תגובה חציוני שגדל בכל הרצת בדיקה, או במקרה הגרוע ביותר זמן תגובה שלא מתאים לפעולה שלך.

בדיקות 'קצה-לקצה' (end-to-end)

בדיקות מקצה לקצה לפני שליחת הפעולה לאישור כוללות את סימולטור של מסוף Actions. אפשר למצוא הוראות מפורטות בדיקה באמצעות הסימולטור של מסוף הפעולות בסימולטור הפעולות התיעוד. ביצוע הבדיקות האלה יעזור לך למנוע אי-ודאות פוטנציאלית מרכיב התשתית של Actions on Google.