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

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

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

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

אזהרה: הדף הזה מתמקד בעיקר בפיתוח פעולות באמצעות Dialogflow. על אף שחלק ממושגי הבדיקה המוצגים רלוונטיים גם למפתחים שמשתמשים ב-Actions SDK, יש הבדלים מהותיים בין שתי המערכות. מפתחים שעובדים עם Actions SDK צריכים לשקול איך לבדוק את פתרון ה-NLU המותאם אישית שלהם, כי השילוב עשוי להיות שונה באופן משמעותי מהרכיב של הסוכן של Dialogflow.

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

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

Dialogflow כמערכת של שאילתות ו-Intent

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

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

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

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

בדיקות יחידה

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

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

קטע הקוד הזה משתמש במוקה ובצ'אי. מומלץ לעיין בדוגמת העבודה המלאה של בדיקת היחידה של Dialogflow שנמצאת ב-Node.js, בקטע עובדות לגבי Google.

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

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

הערה: נקודת הקצה detectIntent גם מפעילה את מילוי הבקשה ב-Dialogflow, מה שעלול לגרום לקריאות נוספות ברשת. אפשר להפעיל או להשבית את אפשרות מילוי הבקשה עבור אובייקט ספציפי בקטע Fulfillment בדף של ה-Intent הזה.

בדיקות שילוב

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

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

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

בדיקה של תגובה לפעולה מאתר אחר (webhook) למילוי הזמנות ב-Dialogflow

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

מילוי הבקשה כמערכת JSON-in ו-JSON-out

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

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

איור 3. ייצוג של מילוי בקשה כמערכת JSON-in ו-JSON-out

בדיקות יחידה

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

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

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

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

1. משתמשים בסימולטור במסוף Actions כדי לקבל את בקשות ה-JSON לכל שלב בתרחיש לדוגמה. יש לשמור אותם כקובצי JSON. לחלופין, תוכלו ליצור את הבקשות האלה בעצמכם באמצעות מידע מתוך מסמכי התיעוד בנושא webhook.
2. אפשר לכתוב בדיקות כדי להפעיל את התגובה לפעולה מאתר אחר (webhook) באמצעות המטענים האלה (payloads).
3. בכל בדיקה, יש לוודא שה-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'},
    ]);
});

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

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

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

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

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

בדיקות שילוב

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

בדיקות עומס

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

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

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

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

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

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

אחרי שתקבלו את הבקשות, תוכלו להשתמש בכלי לבדיקת עומס כדי לגלות איך התגובה לפעולה מאתר אחר (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.

בדיקת טבילה

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

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

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

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

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

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

בדיקות מקצה לקצה

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