اختبار الأتمتة قبل الإطلاق: قائمة تحقق للحالات العادية والاستثناءات

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

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

آخر مراجعة: سبتمبر 2026. يملك هذا المقال النية المعلوماتية لاختبار ما قبل الإطلاق. تحتفظ صفحة أتمتة الأعمال بالنية التجارية للخدمة، ويشرح دليل أخطاء أتمتة العمليات أخطاء التصميم العامة، بينما يوضح مقال قياس نجاح الأتمتة مؤشرات الأداء بعد التشغيل.

ما الذي يعنيه نجاح اختبار الأتمتة؟

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

اكتب معايير القبول بصيغة مدخلات وإجراء ونتيجة متوقعة. اجعل النتيجة قابلة للفحص: سجل واحد أُنشئ، رسالة واحدة أُرسلت، مبلغ لم يتغير، أو تنبيه ظهر للمالك. تجنب عبارات مثل «يعمل جيدًا» أو «التجربة ناجحة» لأنها لا تحدد ما يجب إثباته.

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

من يكتب الخطة ومن يعتمد النتيجة؟

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

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

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

كيف تجهز بيئة وبيانات الاختبار؟

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

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

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

ما اختبارات المسار الطبيعي؟

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

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

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

ما اختبارات الاستثناءات الإلزامية؟

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

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

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

كيف تختبر إعادة المحاولة ومنع التكرار؟

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

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

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

كيف تختبر الصلاحيات وحماية البيانات؟

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

راجع السجلات والتنبيهات. ابحث عن مفاتيح API ورؤوس Authorization وكلمات المرور والهوية والبيانات الشخصية الزائدة. استخدم معرفًا مرجعيًا في التنبيه بدل نسخ payload كامل، واجعل رابط التنفيذ متاحًا للمخولين فقط.

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

ما اختبارات التكامل والبيانات؟

قارن مخطط البيانات المتوقع بالاستجابة الفعلية. اختبر حقولًا جديدة ومفقودة وقيمة null وترتيبًا مختلفًا للعناصر. يجب ألا يحول النظام غياب قيمة إلى صفر أو نص فارغ إذا كان لذلك معنى مختلف في الأعمال.

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

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

كيف تختبر الأداء والسعة؟

ابدأ بالحجم المعتاد ثم اختبر ذروة واقعية، مثل نهاية الشهر أو حملة أو دفعة سجلات كبيرة. راقب زمن الانتظار والتنفيذ وحدود API والذاكرة وتراكم قائمة العمل. لا تستخدم أرقامًا مصطنعة لا علاقة لها بنمط المؤسسة؛ استخرج السيناريو من سجلات الحجم المتاحة.

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

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

كيف تختبر التنبيهات والمراقبة؟

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

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

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

ما خطة الرجوع التي يجب إثباتها؟

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

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

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

كيف تنفذ UAT وتوثق قرار الإطلاق؟

يختبر مستخدمون حقيقيون حالات تمثل عملهم، باستخدام سيناريو مكتوب ونتيجة متوقعة. لا تحول UAT إلى عرض يوجه فيه المطور المستخدم خطوة بخطوة؛ المطلوب كشف الغموض والفجوات في العملية والواجهة والتنبيه.

توصي إرشادات Microsoft لاستراتيجية اختبار Power Automate بالتخطيط لأنواع الاختبار وبيئاته وأدواره بدل الاكتفاء بتجربة أخيرة. استخدم سجلًا لكل حالة يوضح PASS أو FAIL والدليل والعيب والمالك وقرار إعادة الاختبار.

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

قائمة تحقق مختصرة قبل قرار GO

• معايير القبول مكتوبة وقابلة للقياس.
• بيئة وبيانات الاختبار معزولة وممثلة للواقع.
• المسارات الطبيعية والرفض والإعادة اجتازت.
• الأخطاء المؤقتة والدائمة واختبارات الصلاحيات اجتازت.
• إعادة المحاولة لا تنشئ أثرًا مكررًا.
• المصالحة بين المصدر والهدف مكتملة.
• الأداء عند الحجم المتوقع مقبول.
• التنبيه والمراقبة وحداثة آخر نجاح مجربة.
• خطة الرجوع نُفذت عمليًا.
• UAT موثق والعيوب المانعة مغلقة.
• مالك التشغيل وقناة التصعيد معروفان.

إذا فشل بند مانع، يكون القرار NO-GO حتى الإصلاح وإعادة الاختبار. لا يحول ضغط الموعد الخطر غير المفهوم إلى خطر مقبول.

أسئلة شائعة عن اختبار الأتمتة

هل يكفي اختبار المسار الطبيعي؟

لا، لأن أكثر مخاطر الإنتاج تظهر عند نقص البيانات أو تعطل التكامل أو إعادة الحدث أو اختلاف الصلاحيات.

من يعتمد UAT؟

يعتمده مالك العملية ومستخدمون ممثلون، مع مراجعة تقنية وأمنية للحالات التي تخص التكامل والبيانات.

هل نختبر على بيانات حقيقية؟

استخدم بيانات اصطناعية أو منزوعة الحساسية قدر الإمكان، ولا تستخدم الإنتاج إلا بنطاق مضبوط وخطة أثر واضحة.

متى نعيد اختبار النظام كاملًا؟

عند تغيير منطق مشترك أو مخطط بيانات أو صلاحيات أو تكامل أساسي؛ أما التغيير المحدود فيحتاج اختبارات أثر وانحدار مناسبة.

ما أهم دليل قبل الإطلاق؟

سجل حالات الاختبار ونتائجها، ومصالحة الأعداد، ونجاح تجربة الرجوع، وتوقيع أصحاب الصلاحية على القرار.