مقارنة أساليب اختبار الواجهات البرمجية

النمط أولاً. تحصل الواجهة اليوم على أسلوب واحد هو الطلبات الاستكشافية، بل ليس حتى استكشافاً حقيقياً: المجموعة نفسها تُعاد يدوياً قبل كل إصدار. وفي أحسن الأحوال كان يمكن لذلك أن يكشف I3 وI7، وكذلك I5 لو وُجد متجر اختباري كبير بما يكفي. أما كل مشكلة أخرى فكانت تحتاج إلى أسلوب لا يستخدمه الفريق. تسمّي الإجابة النموذجية أدناه لكل مشكلة الأسلوبَ الأرجح أن يكشفها قبل الإصدار، ولماذا فاتت الجولةَ اليدوية؛ ثم ما يظل كل أسلوب يفوته، والمزيج، والرد على قائد الفريق.

I1: اختبار العقد من جهة المزوّد. إذا فُحصت كل استجابة لـ GET /api/v2/cart في CI مقابل مستند OpenAPI، يفشل البناء لحظة اختفاء deliveryFee، بشرط أن يجعل المخطط deliveryFee حقلاً إلزامياً (required)؛ فتحقّق من ذلك، لأن المخطط الذي كل حقوله اختيارية يقبل الاستجابة بعد إعادة التسمية. وفاتت المشكلةُ الجولةَ اليدوية لأن "delivery_fee": 9.00 يبدو معقولاً تماماً لأي شخص، وواجهة الويب التي عُدّلت في الإصدار نفسه لم تُظهر أي مشكلة. والتطبيقات المثبّتة هي سبب حاجة هذا الفريق أيضاً إلى العقود المدفوعة بالمستهلك: يسجّل كل إصدار من التطبيق ما زال مستخدماً الحقولَ التي يقرؤها، فيفشل أي تغيير لدى المزوّد يكسر أحدها قبل شحنه. والحقل الذي يجب أن يُعاد تسميته يُرسَل عندئذ بالاسمين معاً، أو في إصدار جديد من الواجهة، حتى يتوقف استخدام التطبيقات القديمة.

I2: المحاكاة. بيئة Sandbox الخاصة بالبوابة توافق على كل دفعة فوراً، فلا الطلب اليدوي ولا التشغيل في البيئة التجريبية (Staging) يستطيع أن يُنتج بوابة تجيب بعد ⁦40⁩ ثانية. أما محاكاة البوابة فتستطيع ذلك، ومعه مسارات الخطأ الأخرى: لا إجابة على الإطلاق، و503 مع ترويسة Retry-After، و429، وجسم JSON صالح لكن بالشكل الخاطئ. ويجب الاتفاق مع الفريق على ما تفعله الواجهة حين تكون نتيجة الدفع مجهولة، مثل أن تعرض الدفعة «قيد المعالجة» وتسأل البوابة عن حالتها بدلاً من الإبلاغ عن فشل؛ ويتحقق الاختبار مما يهم العميل: طلبية واحدة، ومبلغ يُخصم منه مرة واحدة فقط. ثم يعمل الاختبار مقابل المحاكاة في CI مع كل بناء. وقبل كل إصدار، يؤكد تشغيل واحد من البيئة التجريبية مقابل بيئة Sandbox الحقيقية أن المحاكاة ما زالت تتصرف مثل البوابة.

I3: الاختبار الاستكشافي، ثم اختبار مكتوب. يجتاز اختبار العقد الخصمَ الثاني، لأن الاستجابة بالشكل الصحيح تماماً: هذا منطق عمل خاطئ في نقطة نهاية جديدة. والمختبِر الذي يستكشف POST /api/v2/cart/promo بميثاق اختبار (Charter) مثل «اكسر قاعدة المرة الواحدة لكل عميل» يجرّب الرمز في طلبية ثانية، وبعد إلغاء الطلبية الأولى، ومن جهازين في اللحظة نفسها، وبأحرف صغيرة (welcome50). أما الجولة اليدوية فتعيد مجموعة ثابتة، والقاعدة الجديدة هي بالضبط ما لا تحويه: إرسال الطلبات يدوياً ليس هو الاستكشاف. وكل حالة تُكتشف تصبح اختباراً مكتوباً حتى تبقى القاعدة مُصلَحة.

I4: اختبار الحمل بمجموعة بيانات واقعية. لا تستطيع الطلبات اليدوية إظهار المشكلة: شخص واحد يرسل طلباً واحداً في كل مرة، لعملاء اختباريين لكل منهم نحو ⁦30⁩ طلبية، بينما يحتاج الإخفاق إلى عملاء كثيرين لكل منهم ما يصل إلى ⁦2000⁩ طلبية في اللحظة نفسها. أنشئ بيانات اختبار بأعداد طلبيات تشبه الإنتاج، واتفق مع مالك المنتج على الأهداف قبل الاختبار (زمن استجابة ومعدل خطأ عند الذروة المتوقعة)، وشغّله مبكراً بما يكفي لإصلاح ما يكشفه وإعادة تشغيله قبل ⁦12⁩ نوفمبر، ثم مجدداً بعد أي تغيير في سجل الطلبيات، فهو مسار ساخن. ولا يقول اختبار الحمل شيئاً عن صحة الطلبيات المعروضة.

I5: اختبارات مكتوبة تتحقق من جسم استجابة GraphQL. يجيب خادم GraphQL عادة بـ200 حتى حين يفشل حقل، ويضع الإخفاق في مصفوفة errors، فيبقى فحص رمز الحالة أخضر، سواء كان فحص الصحة في اللوحة أم اختباراً. يتحقق الاختبار من غياب errors ومن أن data.storeOrders قائمة فيها الطلبيات المتوقعة، ويعمل بمتاجر اختبارية على جانبي النقطة التي تعطّل عندها: ⁦100⁩ و⁦101⁩ طلبية مفتوحة (تحليل القيم الحدّية ثنائي القيم). ولن يكشفها فحص العقد مقابل مخطط GraphQL وحده: فقد عادت storeOrders بقيمة null بجوار الخطأ، وهذا لا يفعله GraphQL إلا لحقل يعلنه المخطط قابلاً لقيمة null. أصلح فحص الصحة بالطريقة نفسها، وأضف متجراً بأكبر حجم واقعي إلى اختبار الحمل، لأن طلب GraphQL واحداً قد يكون مكلفاً جداً.

I6: اختبار Webhook يؤدي فيه الاختبار دور البوابة. عبارة «تُسلَّم مرة واحدة على الأقل» تعني أن التكرار أمر طبيعي لا عطل في البوابة، فيجب أن يتعامل المستقبِل معه. يرسل الاختبار حدث payment.succeeded الموقّع نفسه، بمعرّف الحدث نفسه، مرتين، ويتحقق من طلبية مدفوعة واحدة وفاتورة واحدة؛ ويرسل اختبار ثانٍ الأحداث بترتيب مختلف، مثل payment.failed بعد payment.succeeded للدفعة نفسها، ويتحقق من النتيجة التي حددها الفريق (واسأل عنها إن لم تكن مكتوبة). ولا يمكن أن تُطلب من بيئة Sandbox إعادة المحاولة في اللحظة التي يحتاجها الاختبار، لذا فهذه محاكاة، أي إنتاج سلوك البوابة عند الطلب، تعمل اختباراً مكتوباً في CI.

I7: اختبارات سلبية مكتوبة لمستقبِل Webhook، وعيب أمني. يجب أن تُرفض ثلاثة طلبات برمز الخطأ الذي يوثّقه الفريق (مثل 401) وأن تبقى الطلبية دون تغيير: طلب بلا ترويسة X-Signature، وتوقيع بسر خاطئ، وجسم موقّع توقيعاً صحيحاً ثم عُدّل بعد التوقيع. والأخير هو ما يُظهره تمرين «مولّد HMAC»: تغيير حرف واحد يعطي توقيعاً مختلفاً. لم تحوِ المجموعة إلا استدعاءات صالحة من البوابة، فلم ترسل الجولة اليدوية طلباً كهذا قط؛ ومراجعة الكود التي كشفته اختبار ساكن، والاختبار المكتوب هو ما يبقيه مُصلَحاً. ولأن الواجهة تنقل أموالاً وتحفظ بيانات شخصية للعملاء، أضف إلى المزيج اختبارات من OWASP API Security Top 10 2023، بدءاً بالتفويض على مستوى الكائن: يجب ألا يستطيع عميل أن يقرأ سلة عميل آخر أو طلبياته أو يغيّرها. ولا تختبر إلا أنظمة مأذوناً لك باختبارها، وهي هنا البيئة التجريبية لفريقك.

I8: اختبارات وظيفية مكتوبة في CI. هذا انحدار: مرشّح عمل في الإصدار ⁦2.12⁩ وتعطّل في ⁦2.13⁩، في إصدار لم تشمل جولته اليدوية المرشّحات مصادفةً. واختبار يتحقق من أن inStock=true لا يعيد أي منتج كميته صفر، ضمن حزمة تعمل مع كل بناء، كان سيفشل عند التغيير الذي كسره. ويجتازه اختبار العقد، لأن المنتج النافد في القائمة بالشكل الصحيح.

ما يظل كل أسلوب يفوته في هذا المنتج، وما يسدّ الثغرة. يفوت اختبارَ العقد القيمُ الخاطئة داخل شكل صحيح، مثل I3 وI8 وقيمة null في I5، فتتحقق الاختبارات المكتوبة من قواعد العمل. ولا تجد الاختبارات المكتوبة إلا ما كُتبت لتجده، والقاعدة الجديدة مثل I3 ليست بينها، فتحصل كل نقطة نهاية جديدة أو متغيرة على جلسة استكشافية. والجلسة الاستكشافية لا تثبت شيئاً بعد انتهائها، فيصبح كل اكتشاف اختباراً مكتوباً. ومحاكاة البوابة توافق فريقك وليس بالضرورة البوابة، فتُبنى من وثائق واجهة البوابة نفسها وتُفحص من البيئة التجريبية مقابل بيئة Sandbox الحقيقية قبل كل إصدار. واختبار الحمل لا يقول شيئاً عن الصحة الوظيفية، فقد يكون سجل الطلبيات سريعاً وخاطئاً معاً، وهذا ما تغطيه حزمة CI.

المزيج. مع كل بناء في CI: حزمة اختبارات الواجهة المكتوبة، وبين أول اختبارات الانحدار فيها I1 إلى I8؛ وفحص كل استجابة مقابل مستند OpenAPI، بما فيها استجابات الخطأ؛ واختبارات GraphQL تتحقق من الجسم؛ واختبارات Webhook في I6 وI7؛ ومحاكاة البوابة لمسارات الخطأ. ولكل نقطة نهاية جديدة أو متغيرة: جلسة استكشافية قصيرة تصبح اكتشافاتها اختبارات مكتوبة. وقبل كل إصدار: تشغيل واحد من البيئة التجريبية مقابل بيئة Sandbox الحقيقية للبوابة. وقبل الحملة، وبعد أي تغيير في مسار ساخن مثل سجل الطلبيات: اختبار حمل ببيانات تشبه الإنتاج. هذا هو المزيج الافتراضي في الدليل مع خروجين عنه. فالتطبيقات المثبّتة لا يمكن تحديثها مع الواجهة في الوقت نفسه، إذ ما زالت إصدارات الأشهر الستة الأخيرة مستخدمة، لذا تتصرف الواجهة بالنسبة إليها كمنتج عام وتحتاج إلى العقود المدفوعة بالمستهلك واختبارات لكل إصدار من التطبيق ما زال مدعوماً. وهي تنقل أموالاً وبيانات شخصية، فتحتاج إلى اختبارات OWASP API Security Top 10.

ما تبدأ به أولاً، اليوم: العقد. حدّث مستند OpenAPI الذي مضت على آخر تحديث له خمسة أشهر ليطابق الواجهة، وتحقق من صلاحيته، لأن المستند القديم أو غير الصالح يجعل كل نتيجة لاختبار العقد بلا معنى؛ ثم ولّد منه أولى الحالات المكتوبة (تساعدك أداة «مولّد حالات اختبار من OpenAPI» في الدليل)، وأضف حالات قواعد العمل التي لا يستطيع المولّد معرفتها، مثل I3. ومع نحو خمسة أسابيع حتى ⁦12⁩ نوفمبر، يكون الترتيب العملي: العقد وفحوص العقد في CI؛ ثم الحزمة المكتوبة مع I1 إلى I8 ومحاكاة البوابة واختبارات Webhook؛ ثم اختبار الحمل، مبكراً بما يكفي لإصلاح ما يكشفه وإعادة تشغيله قبل الحملة.

الرد على قائد الفريق: «لا، فإضافة أشخاص يرسلون الطلبات يدوياً تجيب عن سؤال واحد فقط من الأسئلة الخمسة. فمن مشكلات الربع الماضي الثماني، كان يمكن للطلبات اليدوية في أحسن الأحوال أن تكشف I3 وI7 وربما I5؛ ولم يكن بوسعها إظهار I1، لأن الحقل المعاد تسميته يبدو سليماً لأي شخص، ولا I2 وI6، لأن بيئة Sandbox لا تستطيع إنتاج إجابة بطيئة أو إعادة محاولة، ولا I4، لأن شخصاً واحداً لا يستطيع إنتاج ذروة الحملة؛ ثم لا يبقى شيء مما تكشفه مفحوصاً بعد ذلك، وهكذا وقعت I8. يستطيع Postman تشغيل مجموعات محفوظة بتأكيدات في CI، وهذا يغطي الاختبارات المكتوبة، لكن التحقق من العقد ومحاكاة البوابة واختبار الحمل تحتاج إلى المواصفة وطبقة محاكاة وأداة حمل إلى جانبه. والأفضل أن يُخصَّص المختبِر الثاني لجلسات استكشافية على نقاط النهاية الجديدة ولتحويل اكتشافاتها إلى اختبارات مكتوبة».

راجع عملك. يجب أن يكون لكل مشكلة أسلوب، وسبب فاتت به الممارسةَ الحالية. والتوزيعات الأخرى مقبولة إن ذُكر السبب، مثل وضع I7 تحت الاختبار الاستكشافي بشرط أن تضيف أن الاختبار المكتوب وحده يبقيه مُصلَحاً، أو I6 تحت الاختبارات المكتوبة بشرط أن تذكر أن التسليم المكرر يجب أن يُنتَج عند الطلب. ويجب أن يذكر مزيجك متى يعمل كل أسلوب (مع كل بناء، ولكل نقطة نهاية جديدة، وقبل كل إصدار، وقبل الحملة) وما يفوت كلاً منها. وبمصطلحات ISTQB CTFL v4.0: مستند OpenAPI هو أساس الاختبار (Test basis)، وهو المرجع (Test oracle) لاختبارات العقد؛ والاختبار الاستكشافي تقنية اختبار قائمة على الخبرة (Experience-based)؛ وحزمة CI هي اختبار الانحدار (Regression testing)، وإصلاح كل مشكلة من I1 إلى I8 يحتاج أولاً إلى اختبار التأكيد (Confirmation testing)؛ واختبار الحمل اختبار غير وظيفي لكفاءة الأداء (Performance efficiency) وفق ISO/IEC 25010؛ والتشغيل مقابل البوابة الحقيقية من البيئة التجريبية اختبار تكامل النظام (System integration testing).