استخدم Batch Test لتقييم عدة سيناريوهات قابلة للتكرار معًا بدلًا من الاعتماد فقط على محادثة غير رسمية في Playground. تصبح مجموعة البيانات قائمة تحقق ثابتة لاختبار التراجع للأسئلة المهمة الخاصة بالعملاء.

يجمع Agent بين التعليمات وإعدادات الواجهة الموجهة للعميل وKnowledge وبيانات الكتالوج والأدوات الاختيارية. يتم اختبار الإعداد الموثوق بأسئلة عملاء واقعية قبل النشر. يجب أن تغطي الاختبارات الإجابات المتوقعة والمعلومات المفقودة وسيناريوهات المنتجات والتصعيد وأي تفاعل اختياري قام الفريق بتمكينه.

قبل أن تبدأ

الوصول: افتح إعداد Agent واختباره مع توفر إذن تشغيل الاختبارات لـ Agent المحدد.

• اختر Agent الخاضع للاختبار.
• حدّد رحلات العميل التي يجب أن تغطيها مجموعة البيانات.
• جهّز الأسئلة يدويًا أو في ملف CSV متوافق أو من منتجات الكتالوج.

اعمل في أصغر نطاق مسؤولية موصوف أدناه، وأبقِ الحالة الحالية الموجهة للعميل متاحة أثناء إعداد التغيير. قبل النقر على أي إجراء نهائي، أكّد الشركة النشطة وAgent والمتجر واللغة والسوق المعروضة في Humind. قد يشير عنصر تحكم مفقود إلى وصول للقراءة فقط أو إلى إمكانية غير مهيأة لهذه الشركة. في هذه الحالة، سجّل المهمة المقصودة واطلب من مسؤول مراجعة الإذن أو التبعية المحددة بدقة. لا تتجاوز هذا الحد عبر مشاركة حساب أو نسخ البيانات إلى نطاق آخر أو الوعد بإمكانية لا تكشف عنها مساحة العمل.

سير العمل خطوة بخطوة

1. تحديد هدف الاختبار

   أنشئ مجموعة بيانات مركزة لإصدار واحد أو خطر واحد أو رحلة واحدة. امزج حالات النجاح المتوقعة مع حالات نقص المعلومات والحالات الحدية حتى لا تتمكن الدرجة المرتفعة من إخفاء سلوك غير آمن.

   • امنح مجموعة البيانات اسمًا محددًا وقابلًا لإعادة الاستخدام.
   • اكتب توقع القبول بجانب كل سؤال مخطط له.

2. إضافة حالات الاختبار

   أدخل الأسئلة يدويًا، أو استورد ملف CSV يضم حتى 50 حالة، أو أنشئ حالات موجهة للمنتجات من الكتالوج. راجع النص المستورد قبل تشغيله.

   • أزل التكرارات والبيانات الشخصية الخاصة بالعملاء.
   • اجعل كل حالة مفهومة من دون سياق مخفي.

3. تحديد Agent وتشغيله

   أكّد Agent ومجموعة البيانات، ثم ابدأ التشغيل. اترك التشغيل يصل إلى حالته النهائية قبل تفسير النتائج الجزئية.

   • لا تعدّل التهيئة المستهدفة أثناء التشغيل.
   • سجّل وقت التشغيل والتهيئة التي يتم تقييمها.

4. الاحتفاظ بمجموعة البيانات لاختبار التراجع

   بعد التشغيل، احتفظ بالحالات المفيدة وحسّن الحالات المبهمة. أعد استخدام مجموعة البيانات نفسها بعد أي تغيير في Knowledge أو الإرشادات أو الكتالوج أو الأدوات.

   • أضف حالات الفشل المكتشفة حديثًا.
   • تجنب إعادة كتابة الحالات القديمة لمجرد تحسين الدرجة.

الحدود المهمة وملاحظات التشغيل

• يقتصر استيراد CSV على 50 حالة اختبار لكل مجموعة بيانات.
• تعتمد حالات المنتجات المُنشأة على الكتالوج المتاح.
• لا تحل نتيجة الدفعة محل التحقق في القناة المباشرة.
• لا تُدرج أسرارًا حقيقية للعملاء أو معلومات شخصية في مطالبات الاختبار.

التحقق من النتيجة

• تحتوي مجموعة البيانات على العدد المقصود من الحالات المميزة.
• يصل التشغيل إلى حالة نهائية مكتملة أو مُبلّغ عنها بوضوح.
• يمكن فتح كل استجابة ومراجعتها.
• يمكن تحديد مجموعة البيانات مرة أخرى لتشغيل تراجع لاحق.

احتفظ بسجل قصير لما اختبرته، وسيناريو العميل الذي استخدمته، وما الذي تغيّر. يجعل ذلك استكشاف الأخطاء وإصلاحها لاحقًا أكثر دقة، ويساعد زميلًا آخر في إعادة إنتاج النتيجة من دون الاعتماد على الذاكرة.

استكشاف الأخطاء وإصلاحها

لا يتم استيراد حالات CSV كما هو متوقع

تحقق من بنية الملف والترميز وعدد الصفوف ومحتوى السؤال المطلوب. ابدأ بملف صغير ونظيف، وتحقق من استيراده، ثم أضف الحالات المتبقية.

يبقى التشغيل في قائمة الانتظار أو يفشل

أبقِ مجموعة البيانات دون تغيير، ودوّن الحالة المُبلّغ عنها، وأعد المحاولة فقط بعد التأكد من أن Agent والخدمة متاحان. يجب الإبلاغ عن الفشل المتكرر مع سياق التشغيل.

الأدلة ذات الصلة

• مراجعة نتائج Batch Test وتقييمها
• اختبر كيفية تعامل Agent مع منتج
• اختبر Agent الخاص بك في Playground
• أكمل قائمة التحقق الخاصة بإطلاقك الأول