יצירה והפעלה של Batch Test

השתמשו ב-Batch Test כדי להעריך יחד כמה תרחישים ניתנים לחזרה, במקום להסתמך רק על שיחה לא פורמלית ב-Playground. מערך נתונים הופך לרשימת בדיקת רגרסיה יציבה עבור שאלות חשובות של לקוחות. Agent משלב הוראות, הגדרות ממשק הפונ...

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

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

לפני שמתחילים

גישה: פתחו את הגדרת Agent והבדיקות עם הרשאה להריץ בדיקות עבור ה-Agent שנבחר.

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

עבדו באזור הבעלות המצומצם ביותר המתואר להלן, והשאירו את המצב הנוכחי הפונה ללקוח זמין בזמן שאתם מכינים את השינוי. לפני לחיצה על פעולה סופית כלשהי, אשרו את החברה הפעילה, ה-Agent, החנות, השפה והשוק שמוצגים ב-Humind. אמצעי בקרה חסר יכול להעיד על גישת קריאה בלבד או על יכולת שאינה מוגדרת עבור חברה זו. במקרה כזה, תעדו את המשימה המתוכננת ובקשו ממנהל לבדוק את ההרשאה או התלות המדויקת. אל תעקפו את הגבול הזה באמצעות שיתוף חשבון, העתקת נתונים לאזור אחר, או הבטחת יכולת שסביבת העבודה אינה חושפת.

תהליך עבודה שלב אחר שלב

  1. הגדרת מטרת הבדיקה

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

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

    הזינו שאלות ידנית, ייבאו CSV עם עד 50 מקרים, או צרו מקרים מוכווני מוצר מהקטלוג. בדקו את הטקסט שיובא לפני ההרצה.

    • הסירו כפילויות ונתונים אישיים של לקוחות.
    • שמרו שכל מקרה יהיה מובן ללא הקשר נסתר.
  3. בחירת ה-Agent והרצה

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

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

    לאחר ההרצה, שמרו מקרים שימושיים ושפרו מקרים מעורפלים. השתמשו שוב באותו מערך נתונים לאחר שינוי ב-Knowledge, בהנחיות, בקטלוג או בכלים.

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

מגבלות חשובות והערות תפעול

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

אימות התוצאה

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

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

פתרון תקלות

מקרי CSV לא מיובאים כצפוי

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

ההרצה נשארת בתור או נכשלת

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

מדריכים קשורים

האם המאמר היה מועיל?