أفضل الممارسات المتعلقة بالاختبار (Dialogflow)

غالبًا ما يتضمن تطوير آلية عمل لمنصة "المهام مع مساعد Google" تنفيذ Dialogflow لفهم اللغة الطبيعية (NLU) وتنفيذ Dialogflow، الذي يتعامل مع منطق الإجراء الخاص بك. يساعد إجراء اختبارات في قاعدة الرموز على ضمان أداء الإجراء على النحو المتوقّع. في مجال الإنتاج.

عند تنفيذ اختبارات الوحدة أو الدمج أو الاختبارات الشاملة للإجراء، يجب: يجب أن يتم النظر في وكيل Dialogflow وتنفيذ عملية التنفيذ كمكوّنين منفصلين.

ينتقل المخطط الانسيابي من طلب بحث المستخدم إلى "المهام مع مساعد Google" وDialogflow، والردّ التلقائي على الويب الخاص بالتنفيذ، ثم يعود في النهاية إلى المستخدم.

الشكل 1. مخطط انسيابي يصف الأنظمة التي يجب مراعاتها في الاختبار

اختبار وكيل Dialogflow

يتم اختبار وكيل Dialogflow وتنفيذ عملية التنفيذ كمكوّنين منفصلين. تشير رسالة الأشكال البيانية توضّح الأقسام الفرعية التالية كيف يمكنك فهم نموذج Dialogflow واختباره لـ Action.

Dialogflow كنظام إدخال طلب البحث والهدف منه

وكيل Dialogflow مسؤول عن نقل طلب بحث المستخدم ومطابقته مع وهدف، واستخراج أي كيانات محددة مسبقًا من الاستعلام. وكيلك تتفاعل مع توصيلك من خلال تمرير رسالة تحتوي على ما هو مطابق الغرض ومَعلماته وبياناته الوصفية في "المهام مع مساعد Google".

بصفتك المطوّر، يمكنك التحكّم في ضبط إعدادات وكيل Dialogflow، مثل وهيكل النوايا والكيانات. تأتي البيانات الوصفية "المهام مع مساعد Google" من المهام مع مساعد Google، ويمكن افتراض احتواءها على البيانات الصحيحة للاختبار.

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

يمكن تمثيل وكيل Dialogflow باستخدام استعلام نصي كإدخال intent بالإضافة إلى معلَمات intent المستخرَجة كنتائج.

الشكل 2. تمثيل Dialogflow كنظام لإدخال طلب البحث و intent-out

اختبارات الوحدات

بالنسبة إلى موظّف الدعم في Dialogflow، يمكنك كتابة اختبارات حيث تتوقع كل حالة نصًّا. طلب البحث كمدخل وينتج بيانات وصفية عن الغرض كمخرج. هذه البيانات الوصفية يجب أن يحتوي (على الأقل) على اسم الغرض المطابق وقائمة المعلَمات.

نقطة نهاية detectIntent لواجهة برمجة تطبيقات Dialogflow باستخدام الاستعلام النصي كمدخل وينتج مخرجًا منظمًا يحتوي على اسم النية التي تم حلها والمعلمات المستخرجة. هذا الناتج مفيد لتقييم الأداء المتوافق مع الأهداف لدى الوكيل. للحصول على مرجع لحقول مفيدة أخرى، يمكنك الاطّلاع على مرجع 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 تقبل sessionId كوسيطة. ونتيجة لذلك، يمكنك الحصول على وضع حماية منفصل كل محادثة أثناء استخدام برنامج واجهة برمجة تطبيقات واحد Dialogflow.

لأنّك ترسل طلبات إلى واجهة برمجة تطبيقات Dialogflow، قد يتم تحصيل رسوم يتم تكبده عند بلوغ حصتك من المكالمات المجانية. الاطّلاع على عروض الأسعار والحدود لمزيد من المعلومات.

اختبارات الدمج

نقطة نهاية detectIntent في Dialogflow API أيضًا تؤدي إلى تنفيذ عملية التنفيذ التابعة لجهة خارجية. وبناءً على ذلك، يمكن كتابة حالات اختبار التي تتناول عملية الدمج بين وكيل Dialogflow وDialogflow التنفيذ.

يتمثل الاختلاف الرئيسي بين تكامل الكتابة واختبارات الوحدة في Dialogflow في وفي اختبار الدمج، يمكنك تأكيد الردود الواردة من الردّ التلقائي على الويب. بالإضافة إلى الغرض من Dialogflow واستخراج الكيانات.

يمكنك الاطّلاع على المثال العملي الكامل لاختبار دمج مكتوب في Node.js في مستودع حقائق عن Google

اختبار الردّ التلقائي على الويب الخاص بتنفيذ Dialogflow

يتم اختبار وكيل Dialogflow وتنفيذ عملية Dialogflow على أنّهما منفصلان. والمكونات. توضح الأقسام الفرعية التالية كيف يمكنك تصور اختبار التنفيذ للإجراء الخاص بك.

التنفيذ كنظام JSON-in وJSON-out

يتوقّع رمز تنفيذ Dialogflow الطلبات ويقدم الردود بها بتنسيق JSON. نتيجةً لذلك، يمكنك اختبار رمز توصيل الطلبات من خلال التفكير كنظام JSON-in وJSON. يحتوي الطلب على بيانات وصفية من وDialogflow و"المهام مع مساعد Google" التي تضم كل ما يلزم لتشغيل معالِج الأهداف المحدد في تنفيذك.

لاختبار تشغيل معالج intent، يمكنك إرسال طلب JSON (إدخال) إلى الإجراء الخاص بك. يتم إرسال هذا الطلب إلى طريقة تنفيذ الطلب، ويمكن الوصول إليه في الإنترنت. ينتج عن التنفيذ بعد ذلك استجابة JSON (المخرجات)، والتي يمكنها تقييمه للتحقق من صحته.

يمكن تمثيل عملية التنفيذ باستخدام إدخال طلب JSON وملف JSON للردّ التلقائي على الويب. ناتج الاستجابة.

الشكل 3. تمثيل عملية التنفيذ كنظام JSON-in وJSON-out

اختبارات الوحدات

فكر في رمز الرد التلقائي على الويب للتنفيذ كنظام يقبل إدخال JSON إلى الحصول على ناتج JSON. بعد ذلك، يتم تبسيط عملية اختبار "الإجراء" لكي من خلال تقديم طلب للتنفيذ والتحقّق من ناتج JSON الناتج.

يمنحك ذلك حرية استضافة التنفيذ محليًا وإرسال HTTP. محليًا للاختبار. في حال استخدام Node.js في "المهام مع مساعد Google" يمكنك أيضًا إرسال طلبات JSON مباشرةً إلى مكتبة البرامج البرمجيات الوسيطة.

في حال اختبار رمز الردّ التلقائي على الويب باستخدام إدخالات JSON وتلقّيت ملف JSON المتوقع والمخرجات، فيمكنك القول بثقة معقولة أن الأجزاء التي تتحكم فيها يعمل بشكل صحيح. يمكنك افتراض أنّ Dialogflow و"المهام مع مساعد Google" تعملان بشكل صحيح. وهي تنتج حمولات JSON الصحيحة. هذه العزلة نموذج برمجة مبسط لكتابة الاختبارات.

في ما يلي مخطط عام لعملية الاختبار:

  1. استخدام المحاكي في وحدة تحكّم المهام للحصول على طلبات JSON كل خطوة في حالة الاستخدام. احفظها كملفات JSON. بدلاً من ذلك، يمكنك وإنشاء هذه الطلبات بنفسك باستخدام معلومات من المستندات المرجعية للردّ التلقائي على الويب.
  2. كتابة اختبارات لاستدعاء الرد التلقائي على الويب مع هذه الحمولات.
  3. في كل اختبار، تأكَّد من أنّ استجابة JSON تحتوي على العناصر المتوقعة.

بالإضافة إلى ذلك، يتيح لك هذا النموذج اختبار تنفيذ Dialogflow في التكامل المستمر لأن نقطة نهاية التنفيذ يمكن أن تعمل محليًا، وتتضمّن واجهة برمجة التطبيقات Dialogflow مفهوم الجلسات المدمَج.

يبدو المثال على الاختبار كما يلي:

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 المستودع.

تصميم التنفيذ القابل للاختبار في الوحدة

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

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

على سبيل المثال، يمكنك الرجوع إلى نموذج إجراء shiriuri على GitHub. في هذا النموذج، يتم استخدام functions/index.js وfunctions/shiritori/*.js بشكل منفصل. تحتوي على معالِجات الأهداف ومنطق الأعمال، ما يسمح بإجراء اختبارات أكثر فعالية والأجنحة.

اختبارات الدمج

لكتابة حالات الاختبار التي تتناول التكامل بين Dialogflow رمز الرد التلقائي على الويب لتنفيذ العملية، يُرجى الاطّلاع على قسم اختبار الدمج في Dialogflow أعلاه.

تحميل الاختبارات

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

في ما يلي بعض الأمثلة على مشاكل الأداء التي قد تكتشفها أثناء اختبار التحميل:

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

تعتمد سيناريوهات اختبار التحميل على نمط الاستخدام المتوقع أو السابق الإجراء، ولكن السيناريوهات المعتادة التي يجب اختبارها هي الزيادة المفاجئة في التحميل (ارتفاع كبير) التحميل المستمر (التربيع)

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

في هذه السيناريوهات، يمكنك تسجيل الطلبات المُرسَلة من خلال خوادم "المهام مع مساعد Google". إلى الرد التلقائي على الويب من سجلات الرد التلقائي على الويب أو من سجلات Stackdriver. يمكنك أيضًا تسجيل الطلبات من محاكي وحدة تحكّم المهام

بعد حصولك على الطلبات، يمكنك استخدام أداة اختبار التحميل لمعرفة كيفية استجابة الرد التلقائي على الويب بموجب سيناريوهات اختبار التحميل المختلفة. ما يلي: تقدم الأقسام الفرعية بعض الأمثلة لاختبار الارتفاع واختبار النقع باستخدام ApacheBench:

اختبار الارتفاع

يتطلب اختبار الارتفاع المفاجئ إرسال عدد ثابت من الطلبات إلى الرد التلقائي على الويب. لبعض الوقت ثم زيادة التحميل فجأة. على سبيل المثال، يمكنك إعداد اختبار يرسل تحميلاً من 10 طلبات في الثانية (QPS) مع بعض الارتفاعات القليلة في 60 QPS.

يمكنك تشغيل الأمر ApacheBench التالي لإرسال 60 طلبًا متزامنًا. إلى الرد التلقائي على الويب:

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

لنفترض أنّ الملف ActionRequest.json يحتوي على حمولة الطلب المسجّلة التي تم إرسالها. إلى الرد التلقائي على الويب.

اختبار تنقيط

يتطلب اختبار Soak إرسال عدد ثابت من الطلبات إلى الرد التلقائي على الويب. ومراقبة الرد. على سبيل المثال، يمكنك إعداد اختبار لإرسال تحميل ثابت من 10 إلى 20 طلب في الثانية لعدة دقائق لمعرفة ما إذا كانت أوقات الاستجابة زيادة.

يمكنك تشغيل الأمر ApacheBench التالي لإرسال 1200 طلب، من خلال 10 طلبات. الطلبات المتزامنة كل ثانية:

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

لنفترض أنّ الملف ActionRequest.json يحتوي على حمولة الطلب المسجّلة التي تم إرسالها. إلى الرد التلقائي على الويب.

تحليل نتائج اختبار التحميل

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

الاختبار الشامل

يستخدم الاختبار الشامل قبل إرسال الإجراء للموافقة عليه محاكي وحدة تحكّم المهام يمكنك العثور على خطوات شاملة للاختبار عبر مُحاكي وحدة تحكّم المهام في محاكي المهام التوثيق. يساعدك إجراء هذه الاختبارات في التخلص من الشك المحتمل من مكوّن البنية الأساسية "المهام مع مساعد Google".