ما هي إجراءات الاختبار (Test Actions)؟

نظرة عامة

تتيح Test Actions أتمتة الاستجابات لنتائج تنفيذ الاختبارات. عندما يعمل اختبار قياسي (standard test) وينتج نتيجة، يمكن لإجراءات الاختبار اتخاذ خطوات لاحقة داخل Validatar أو تجاه مصدر بيانات متصل — بشكل ديناميكي مستمَد من سياق تنفيذ الاختبار.

تتكون الإجراءات من جزأين:

• Triggers (المحفزات) تحدّد متى يجب أن يُفعَّل الإجراء (مثلًا عند تشغيل الاختبار، أو عند فشله، أو عند تغيّر حالته العامة).
• Steps (الخطوات) تحدّد ما الذي يجب أن يحدث عند تفعيل المحفز (مثلًا تشغيل اختبار آخر، أو تنفيذ سكربت، أو إرسال بريد إلكتروني، أو تحديث بيانات وصفية).

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

المفاهيم الأساسية (Key Concepts)

المحفزات (Triggers)

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

الفرق بين Test Resulted In وTest Overall Status Changed To مهم:

• يُفعَّل Test Resulted In بناءً على نتيجة كل تنفيذ فردي. إذا فشل الاختبار مرتين متتاليتين، فإن محفز "Test Resulted In: Failed" يُفعَّل في المرتين.
• يُفعَّل Test Overall Status Changed To فقط عندما تنتقل الحالة العامة فعليًا. إذا كانت الحالة العامة للاختبار بالفعل "Consistent Failing" وفشل الاختبار مجددًا دون أي تغيّر في الحالة، فإن المحفز لا يُفعَّل.

الخطوات (Steps)

تحدّد الخطوات ما يحدث عند تفعيل المحفز. يمكن أن يحتوي كل محفز على عدة خطوات، تُنفَّذ بالتسلسل بحسب الترتيب الذي رُتِّبت به.

تدعم معظم أنواع الخطوات حقول القوالب (template fields) — عناصر نائبة ديناميكية مثل {{test_name}} أو {{result}} يتم استخلاصها من سياق تنفيذ الاختبار وقت التشغيل. للاطلاع على التفاصيل، راجع مقالة Using Template Fields in Test Actions.

المحفزات والخطوات تعمل معًا

تبدو تهيئة إجراء نموذجية كالتالي:

Trigger: Test Overall Status Changed To → Now Failing
  Step 1: Send an Email to the data engineering team
  Step 2: Run a detail-level comparison test
  Step 3: Set the linked table's "Quality Status" field to "Needs Investigation"

يمكن أن يحتوي نفس الاختبار على عدة محفزات، لكل منها خطواته الخاصة:

Trigger 1: Test Resulted In → Error
  Step 1: Send an Email to the platform admin

Trigger 2: Test Overall Status Changed To → Now Failing
  Step 1: Run a Script that creates a JIRA ticket
  Step 2: Set Linked Object Metadata to flag the table

حالات الاستخدام الشائعة (Common Use Cases)

تشغيل اختبارات تفصيلية بعد فشل اختبار عالي المستوى

يعمل اختبار سريع وعالي المستوى لعدّ الصفوف (row count) كجزء من مهمة مجدولة. في حال فشله، تُشغِّل خطوة "Run a Standard Test" اختبار مقارنة أكثر تفصيلًا لتحديد الصفوف المحددة التي تختلف. هذا يبقي عمليات التشغيل المجدولة سريعة مع توفير تفاصيل معمّقة عند اكتشاف مشكلات.

إنشاء تذاكر في أنظمة خارجية عند تغيّر الحالة

عندما تتغيّر الحالة العامة لاختبار حرج إلى "Now Failing"، تنفّذ خطوة "Run a Script" سكربت SQL أو Python يستدعي واجهة برمجة تطبيقات خارجية (مثل JIRA أو ServiceNow) لإنشاء تذكرة حادثة. تملأ حقول القوالب مثل {{test_name}} و{{result}} و{{execution_url}} التذكرة بالسياق ذي الصلة.

إخطار الفرق عند تغيرات الحالة الدقيقة

بدلًا من إرسال بريد إلكتروني عند كل فشل، يقوم محفز "Test Overall Status Changed To" مع خطوة "Send an Email" بإخطار الفريق فقط عند حدوث انتقالات ذات معنى — على سبيل المثال عندما ينتقل الاختبار إلى "Now Failing" أو "Intermittent Failures". توفر حقول القوالب في الموضوع والنص تفاصيل التنفيذ دون حاجة المستلم لتسجيل الدخول.

وسم كائنات البيانات الوصفية بناءً على نتائج الاختبار

عند تشغيل اختبار معلوماتي، تقوم خطوة "Set Linked Object Metadata Value" بوسم الجدول أو العمود المرتبط بمؤشر جودة (مثل ضبط حقل "Data Quality Status" على "Warning" أو "Needs Research"). هذا يبقي Data Catalog محدَّثًا بأحدث التقييمات المستندة إلى الاختبارات.

النشر إلى كتالوجات بيانات خارجية

يمكن لخطوة "Run a Script" تنفيذ سكربت يستدعي واجهة برمجة تطبيقات كتالوج بيانات خارجي للإبلاغ عن أن كائنًا معينًا لديه مشكلة جودة، مما يبقي المستهلكين اللاحقين على اطلاع دون تدخل يدوي.

كيف تندمج الإجراءات ضمن تنفيذ الاختبار

تعمل الإجراءات تلقائيًا بعد اكتمال تنفيذ الاختبار. المسار كالتالي:

1. 1يتم تنفيذ اختبار قياسي (عبر مهمة، أو جدولة، أو تشغيل يدوي).
2. 2يقيّم Validatar نتيجة الاختبار ويحدد ما إذا كانت الحالة العامة قد تغيّرت.
3. 3يتم تقييم كل محفز على الاختبار مقابل نتيجة التنفيذ.
4. 4بالنسبة لكل محفز تحقق شرطه، تُنفَّذ الخطوات المرتبطة به بالتسلسل.
5. 5إذا فشلت خطوة ما، تستمر الخطوات اللاحقة ضمن نفس المحفز في التنفيذ.

تُنفَّذ الاختبارات التي يستدعيها محفز "Run a Standard Test" كدفعة (batch) منفصلة — ولا تعمل ضمن سياق الدفعة الخاصة بالاختبار الأصل.

المتطلبات الأساسية (Prerequisites)

• تُطلب صلاحية Creator-level access لتهيئة إجراءات الاختبار على اختبار ما.
• يُطلب إعداد SMTP إذا كنت تنوي استخدام خطوة "Send an Email". راجع مقالة SMTP Settings لتعليمات الإعداد.
• يجب تهيئة روابط البيانات الوصفية (metadata links) على مجموعات بيانات الاختبار قبل استخدام خطوة "Set Linked Object Metadata Value".
• يجب تعريف حقول مخصصة (custom fields) على المشروع قبل استخدام خطوتي "Set Test Metadata Value" أو "Set Linked Object Metadata Value". راجع مقالة Project Custom Fields للتفاصيل.

الخطوة التالية

• Configuring Simple Test Actions — دليل خطوة بخطوة لإنشاء أول محفزاتك وخطواتك.
• Using Template Fields in Test Actions — كيفية استخدام القيم الديناميكية من سياق تنفيذ الاختبار في السكربتات والبريد الإلكتروني والبيانات الوصفية.