هرم أتمتة الاختبار

لماذا يهم

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

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

الطبقات وما يتغيّر بينها

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

• اختبارات الوحدة أو المكوّنات (القاعدة، كثيرة): دالة أو صنف أو مكوّن واجهة واحد، تُستبدل اعتمادياته عند الحاجة ببدائل الاختبار (Test Doubles) كما في درس اختبار المكوّنات. يعمل كل منها في أجزاء من الثانية، وإذا فشل سمّى الوحدة المعطوبة. ويكتبها المطورون عادةً مع الشيفرة.
• اختبارات التكامل أو الخدمة أو API (الوسط، أقل): مكوّنات أو خدمات تعمل معاً عبر واجهة حقيقية مثل واجهة HTTP برمجية أو قاعدة بيانات أو طابور رسائل. تكشف عيوب الواجهات التي لا تراها اختبارات الوحدة، مثل حقل تغيّر اسمه أو سجل لا يُحفظ أبداً، ويعمل كل منها في ثوانٍ.
• الاختبارات من البداية إلى النهاية أو اختبارات واجهة المستخدم (القمة، قليلة): رحلة مستخدم كاملة عبر الواجهة الحقيقية وكل الأنظمة التي خلفها. تثبت أن الأجزاء موصولة ببعضها من منظور المستخدم، لكن كلاً منها يحتاج إلى بيئة كاملة وبيانات اختبار، ويستغرق ثوانيَ أو دقائق، وقد يفشل لأسباب لا علاقة لها بالتغيير.

القاعدة: اختبر في أدنى مستوى يستطيع كشف العيب

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

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

وكثيراً ما يمكن اختبار مكوّن في الواجهة الأمامية مقابل استجابة API محاكاة (Mock) بدلاً من الخادم الحقيقي، فينتقل الفحص من قمة الهرم إلى قاعدته.

جرّبها: مولّد استجابات API وهمية

مثال تطبيقي: توزيع فحوص رمز ترويجي

المتطلب: «الرمز SAVE10 يمنح خصماً ⁦10%⁩ على الطلبات بقيمة ⁦200.00⁩ ريال فأكثر، بحدّ أقصى ⁦50.00⁩ ريالاً، من ⁦1⁩ إلى ⁦31⁩ مارس 2027 بتوقيت الرياض، ومرة واحدة لكل عميل». هذا هو رمز SAVE10 من درس اختبار المكوّنات مع قاعدة العمل كاملة. يعطيك تحليل القيم الحدّية القيم، ويقرر الهرم أين يعمل كل فحص.

تذهب الفحوص الاثنا عشر للمبالغ والتواريخ والاستخدام السابق إلى اختبارات الوحدة، فهي قواعد صرفة، ومعظم فحوصها قيم حدّية. وتضيف طبقة API ما لا تستطيع الدالة وحدها إظهاره: البحث عن الرمز في قاعدة البيانات الحقيقية، وتسجيل الاستخدام الأول كي يُرفض الثاني، وحفظ الخصم على الطلب. أما الاختبار الوحيد من البداية إلى النهاية فلا يعيد فحص أي حدّ، بل يثبت أن الحقل والسلة والدفع والتأكيد موصولة ببعضها من منظور العميل. ولو كُتبت هذه الفحوص ثمانية عشر اختبار متصفح، لسجّل كل منها الدخول وملأ السلة، ولقالت رسالة الفشل «العنصر غير موجود» بدلاً من «⁦500.10⁩ أعطى ⁦50.01⁩».

Rule: SAVE10 = 10% off orders from 200.00 SAR, at most 50.00 SAR off,
      valid 1 to 31 March 2027 (Riyadh time), once per customer

UNIT: discount and validity functions, test doubles for the rest     12 tests
  199.99 -> 0.00      200.00 -> 20.00     333.33 -> 33.33
  499.90 -> 49.99     500.00 -> 50.00     500.10 -> 50.00 (cap)
  28 Feb 23:59:59 -> invalid            1 Mar 00:00:00 -> valid
  31 Mar 23:59:59 -> valid              1 Apr 00:00:00 -> invalid
  first use -> valid                    earlier use by this customer -> invalid

API / INTEGRATION: cart service with its real database                5 tests
  apply SAVE10 to a 250.00 cart     -> accepted, discount 25.00
  apply an expired code             -> rejected, PROMO_EXPIRED
  apply an unknown code             -> rejected, PROMO_UNKNOWN
  same customer applies it again    -> rejected, PROMO_ALREADY_USED
  place the order                   -> discount 25.00 saved on the order

END-TO-END: browser, all services, test payment                       1 test
  log in, add 250.00 SAR of items, apply SAVE10, see -25.00,
  pay with a test card, confirmation shows 225.00

جرّبها: مولّد مجموعات الأرقام الحدّية جرّبها: مولّد حالات اختبار من OpenAPI

النمط المضاد: مخروط الآيس كريم

مخروط الآيس كريم (Ice-Cream Cone) هو الهرم مقلوباً: رأس ضيق من اختبارات الوحدة، وقليل من اختبارات التكامل، وشريحة عريضة من اختبارات الواجهة الآلية، وفي الأعلى كرة كبيرة من اختبار الانحدار اليدوي. نشر أليستر سكوت (Alister Scott) هذا الاسم، ويحذّر مقال «The Practical Test Pyramid» من أن حزمة كهذه صعبة الصيانة وتستغرق وقتاً أطول بكثير مما ينبغي.

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

أعراض تراها في خط أنابيب الفريق:

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

جرّبها: مولّد سيناريوهات الانحدار

شكل آخر: كأس الاختبار

الهرم ليس النموذج الوحيد. فقد اقترح كِنت سي. دودز (Kent C. Dodds) كأس الاختبار (Testing Trophy) لتطبيقات الويب المكتوبة بلغة JavaScript: في القاعدة التحليل الساكن (Static Analysis)، أي فحص الأنواع والتدقيق الآلي للشيفرة (Linting)، ثم اختبارات الوحدة، ثم اختبارات التكامل بوصفها أكبر طبقة، ثم قمة صغيرة من الاختبارات من البداية إلى النهاية. وحجته أن الاختبار كلما أشبه طريقة استخدام البرمجية منح ثقة أكبر، وأن اختبارات التكامل تحقق أفضل توازن بين هذه الثقة وكلفة تشغيل الاختبارات وصيانتها.

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

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• The Practical Test Pyramid (Ham Vocke)martinfowler.com · 2018شرح واسع الاستشهاد لكيفية الموازنة بين اختبارات الوحدة والتكامل والعقود والواجهة في محفظة الاختبارات الآلية.
• Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)Addison-Wesley (Pearson) · 2009أرباع الاختبار الرشيق وكيف يعمل المختبرون داخل فريق التسليم — أساس «الاختبار في الطبقة الصحيحة».