يعمل الاختبار اليدوي بشكل جيد حتى يتوقف عن ذلك. يمكن لمطور واحد النقر عبر عدد قليل من نقاط النهاية قبل الإصدار. لا يمكن لفريق يدير خمسين خدمة عبر عشرات البيئات القيام بذلك، ويوم محاولتهم، سيتم شحن شيء غير مختبر. الاختبار الآلي هو الحل لمشكلة التوسع هذه: دع الآلات تقوم بالفحوصات المتكررة، في كل مرة، حتى يركز البشر انتباههم حيث يكون الأمر مهمًا.
يشرح هذا الدليل ماهية الاختبار الآلي، وأين يساعد وأين لا يساعد، ويوضح كيفية إعداد اختبارات API الآلية خطوة بخطوة في Apidog.
ما هو الاختبار الآلي؟
الاختبار الآلي يعني استخدام البرامج لتشغيل الاختبارات والتحقق من النتائج، بدلاً من قيام شخص بأداء كل خطوة يدويًا. تقوم بتحديد الاختبار مرة واحدة: المدخلات، الإجراء، والنتيجة المتوقعة. من ثم، تقوم أداة بتشغيله عند الطلب، أو بجدول زمني، أو مع كل تغيير في الكود، وتقدم تقارير النجاح أو الفشل دون أي مراقبة.
التحول ليس مجرد سرعة. إنه الاتساق. سيقوم المختبر البشري الذي يجري نفس الفحص خمسين مرة بتشغيله بشكل مختلف قليلاً في كل مرة وسيتعب في المرة الأربعين. الاختبار الآلي يقوم بتشغيل المرة الخمسين تمامًا مثل الأولى. هذه القابلية للتكرار هي المنتج الحقيقي للأتمتة.
ينطبق الاختبار الآلي على جميع طبقات النظام: اختبارات الوحدات للوظائف، اختبارات التكامل للمكونات، اختبارات واجهة المستخدم (UI) للواجهات، واختبارات API لنقاط النهاية. غالبًا ما يكون اختبار API هو المكان الأنسب للبدء، لأن واجهات الـ API مستقرة، وسريعة الاستدعاء، وتحمل منطق العمل الأساسي. يعمل اختبار API في غضون أجزاء من الثانية ولا يحتوي على متصفح متقلب لمواجهته.
لماذا تقوم الفرق بأتمتة الاختبارات؟
الاختبار اليدوي لا يتوسع. كل نقطة نهاية جديدة تضيف فحوصات. كل بيئة تضاعفها. بعد حجم معين، تصبح التغطية اليدوية الكاملة قبل كل إصدار مستحيلة جسديًا، لذلك يتم التنازل عن جوانب بشكل صامت.
التراجعات تتسرب بدونه. يمكن لتغيير في خدمة واحدة أن يكسر عقدًا يبعد ثلاث خدمات. فقط مجموعة تعيد تشغيل كل شيء عند كل تغيير يمكنها اكتشاف ذلك، وفقط الأتمتة تجعل "إعادة تشغيل كل شيء" رخيصًا بما يكفي للقيام به باستمرار.
تصبح الاختبارات أصولًا قابلة لإعادة الاستخدام. الاختبار اليدوي يُستهلك بمجرد تشغيله. الاختبار الآلي يُكتب مرة واحدة ويُشغل آلاف المرات. التكلفة مركزة في البداية؛ العائد يتضاعف.
التعليقات تصبح سريعة. عندما تعمل الاختبارات تلقائيًا في مسار العمل، يتعلم المطور في غضون دقائق أن تغييرًا قد أحدث عطلاً، بينما لا يزال السياق جديدًا. تكلفة إصلاح خطأ تم اكتشافه في الإنتاج أعلى بكثير من تكلفة إصلاح نفس الخطأ الذي تم اكتشافه في التكامل المستمر (CI).
يقوم الأشخاص بعمل أفضل. الأتمتة لا تحل محل المختبرين. إنها تحررهم من النقر الروتيني حتى يتمكنوا من القيام بالاختبار الاستكشافي، والبحث عن الحالات الحدودية، وعمل قابلية الاستخدام، وهي الأمور التي لا تجيدها الآلات.
ما لا يحله الاختبار الآلي
الأتمتة ليست مجانية، والتظاهر بخلاف ذلك يؤدي إلى خيبة الأمل.
تتطلب الاختبارات الآلية جهدًا في الكتابة وجهدًا في الصيانة. عندما تتغير واجهة الـ API، تتغير الاختبارات أيضًا. مجموعة من الاختبارات القديمة التي تفشل لأسباب خاطئة أسوأ من عدم وجود أي مجموعة، لأن الفريق يتعلم تجاهل البناءات الحمراء.
كما أن الأتمتة لا يمكنها الحكم على ما إذا كان البرنامج جيدًا، بل فقط ما إذا كان يتطابق مع ما أخبرت الاختبار أن يتوقعه. لن تلاحظ أن سير العمل مربك أو أن الاستجابة، على الرغم من صحتها تقنيًا، عديمة الفائدة للعميل. هذا الحكم يبقى بشريًا.
وليس كل شيء يستحق الأتمتة. الفحص الذي ستجريه مرتين ليس كذلك. الفحص الذي ستجريه مع كل تغيير لمدة عامين هو كذلك بالتأكيد. قم بأتمتة المسارات المستقرة والمتكررة وذات القيمة العالية أولاً؛ اترك العمل النادر والاستكشافي يدويًا.
كيفية إعداد اختبارات API الآلية في Apidog
يقوم Apidog ببناء اختبارات API الآلية بصريًا، لذلك لا تحتاج إلى كتابة أو صيانة نصوص اختبار للحصول على مجموعة عمل. إليك الخطوات الكاملة:
الخطوة 1: تحديد أو استيراد واجهة الـ API الخاصة بك. قم بإحضار نقاط النهاية الخاصة بك من ملف OpenAPI، أو مجموعة Postman، أو قم بتعريفها مباشرة في Apidog. تحمل كل نقطة نهاية مخطط طلبها ومخطط استجابتها، والتي تصبح الأساس للتأكيدات. إذا بدأت من مواصفات، فإن عقد الـ API والاختبارات تظل متزامنة تلقائيًا.
الخطوة 2: إضافة تأكيدات لكل طلب. بالنسبة لنقطة نهاية، افتح لوحة التأكيدات وأضف الفحوصات بدون برمجة: الحالة تساوي 200، يوجد حقل في الجسم وله النوع الصحيح، الاستجابة تتطابق مع المخطط، وقت الاستجابة أقل من ميزانيتك. هذه التأكيدات البصرية للـ API هي جوهر الاختبار؛ طلب بدون تأكيدات يثبت فقط أن الخادم قد أجاب.
الخطوة 3: إنشاء سيناريو اختبار. قم بتجميع الطلبات ذات الصلة في سيناريو مسمى، على سبيل المثال "دورة حياة المستخدم". اربطها بحيث تتدفق المخرجات إلى الأسفل: تسجيل الدخول يعيد رمزًا، والطلب التالي يستهلكه. كل كتلة طلبات مع تأكيدات هي حالة اختبار؛ يغطي كيفية كتابة حالات اختبار API الهيكل.
الخطوة 4: إضافة تغطية تعتمد على البيانات. قم بإرفاق ملف CSV أو JSON بحيث يتم تشغيل سيناريو واحد مقابل العديد من صفوف الإدخال. بدلاً من كتابة عشرين حالة شبه متطابقة، تكتب حالة واحدة وتغذيها بعشرين مجموعة بيانات. اختبار API المعتمد على البيانات هو كيف تغطي مجموعة صغيرة مساحة إدخال كبيرة.
الخطوة 5: تشغيل السيناريو. قم بتنفيذه عند الطلب وتعيين عدد التكرارات، على سبيل المثال خمسين تشغيلاً، للتحقق من الاستقرار تحت التكرار. يقوم Apidog بتشغيل كل حالة، وتقييم كل تأكيد، وإنتاج تقرير يسمي التأكيد المحدد الذي فشل، مع القيم المتوقعة والفعلية.
الخطوة 6: التنظيم في مجموعات اختبار. قم بجمع السيناريوهات في مجموعات اختبار بحيث تعمل واجهة API كاملة بنقرة واحدة. تحافظ المجموعات على قاعدة اختبار متنامية قابلة للإدارة مع توسع التغطية.
الخطوة 7: ربطها بـ CI/CD. هذه هي الخطوة التي تحول مجموعة الاختبار إلى اختبار آلي. قم بتشغيل المجموعة في كل عملية commit أو pull request حتى تظهر التراجعات قبل الدمج. يعمل Apidog في أي مسار عمل؛ يشرح أتمتة اختبارات API في CI/CD ذلك، ويغطي تشغيل اختبارات API في GitHub Actions هذه المنصة على وجه التحديد.
حمل Apidog لبناء أول سيناريو آلي لك وشاهده يعمل.
الأنواع الرئيسية للاختبارات الآلية
الاختبار الآلي ليس شيئًا واحدًا. إنه مجموعة طبقية من أنواع الاختبارات، كل منها يكتشف فئة مختلفة من الأخطاء بتكلفة مختلفة.
اختبارات الوحدات (Unit tests) تتحقق من وظيفة واحدة أو فئة واحدة بمعزل عن غيرها. إنها سريعة ورخيصة وتُشغل بالآلاف، لكنها لا تستطيع اكتشاف المشاكل التي تظهر فقط عندما تتحدث المكونات مع بعضها البعض.
اختبارات التكامل (Integration tests) تتحقق من أن المكونات تعمل معًا: خدمة وقاعدة بياناتها، أو خدمتان عبر حدود الشبكة. إنها تكتشف أخطاء الاتصال التي تفوتها اختبارات الوحدات، على حساب كونها أبطأ وتحتاج إلى إعداد أكثر.
اختبارات الـ API (API tests) تقع في نقطة مثالية. إنها تمارس نقطة نهاية عبر HTTP، بنفس الطريقة التي يفعل بها العميل الحقيقي، لذا فهي تتحقق من العقد الفعلي. تعمل بسرعة، ولا تحتاج إلى متصفح، وتغطي منطق العمل الأكثر أهمية. بالنسبة لمعظم الفرق، هذه هي الطبقة التي تحقق أفضل عائد على الجهد.
اختبارات شاملة (End-to-end tests) تقود سير عمل كامل عبر النظام الحقيقي، غالبًا ما يتضمن واجهة المستخدم. إنها الأكثر واقعية والأبطأ، وتميل إلى أن تكون الأكثر تقلبًا، لذا تحتفظ بها الفرق قليلة ومركزة على الرحلات الحاسمة.
يلخص هرم الاختبار المعروف التوازن: العديد من اختبارات الوحدات السريعة في القاعدة، عدد أقل من اختبارات التكامل والـ API في المنتصف، وطبقة رقيقة من الاختبارات الشاملة في الأعلى. مجموعة تكون معكوسة الشكل، معظمها اختبارات شاملة بطيئة، تعمل ببطء وتفشل بشكل غير متوقع. اختبارات الـ API هي حيث تحصل الفرق على تغطية واسعة وموثوقة دون دفع ضريبة الاختبارات الشاملة، ولهذا السبب هي نقطة البداية الموصى بها.
جعل الأتمتة تؤتي ثمارها
هناك عدد قليل من العادات التي تفصل بين المجموعات التي تستحق جهدها وتلك التي تتدهور.
حافظ على الاختبارات قريبة من تصميم الـ API. عندما يعيش العقد والاختبارات في مكان واحد، يكون من الصعب نسيان تغيير العقد في الاختبارات. الانجراف هو السبب الرئيسي لتدهور المجموعات.
أكد على النتائج الحقيقية، وليس فقط رموز الحالة. الاختبار الآلي الذي يتحقق فقط من 200 سيمرر الاختبار بينما يعيد بيانات غير صالحة. قم بأتمتة التأكيدات القوية أو ستكون قد أتمتت إحساسًا زائفًا بالأمان.
اجعل حالات الفشل واضحة. التقرير الجيد يذكر التأكيد الفاشل، وليس مجرد الاختبار الفاشل. كلما تمكن المطور من قراءة الفشل بشكل أسرع، زادت ثقة الفريق في المجموعة.
شغلها حيث تتخذ القرارات. المجموعة التي تعمل فقط عندما يتذكرها شخص ما ليست مؤتمتة. ضعها في مسار العمل بحيث تعمل دون الحاجة إلى طلبها.
استند إلى الذكاء الاصطناعي للأجزاء الشاقة. يعد إنشاء مسودة أولية للحالات من المواصفات، أو توسيع الحالات الحدودية، مناسبًا تمامًا للمساعدة؛ يوضح الاختبار الآلي للـ API المعزز بالذكاء الاصطناعي أين يساعد ذلك وأين لا يزال التقييم البشري مطلوبًا.
الأسئلة المتكررة
هل الاختبار الآلي أفضل من الاختبار اليدوي؟ لا يحل أحدهما محل الآخر. قم بأتمتة الفحوصات المستقرة والمتكررة وذات القيمة العالية. احتفظ بالاختبار الاستكشافي، ومراجعة قابلية الاستخدام، والعمل الذي يتطلب حكمًا بشريًا يدويًا. أفضل الفرق تفعل كليهما.
هل أحتاج إلى معرفة كيفية البرمجة لأتمتة اختبارات الـ API؟ ليس باستخدام أداة بصرية. في Apidog، تقوم ببناء الطلبات والتأكيدات والسيناريوهات بالنقر، وتلجأ إلى النصوص البرمجية فقط للمنطق الذي لا يمكن للمنشئ البصري التعبير عنه.
أين يجب أن يبدأ الفريق بالأتمتة؟ اختبارات الـ API. إنها سريعة ومستقرة وتغطي المنطق الأساسي، بدون تقلبات أتمتة واجهة المستخدم. ابدأ بنقاط النهاية الحيوية ثم قم بالتوسع.
كم تحتاج الاختبارات الآلية من صيانة؟ تتغير كلما تغيرت واجهة الـ API. الحفاظ على الاختبارات بالقرب من تصميم الـ API يقلل من المفاجآت، ولكن خصص وقتًا مستمرًا؛ تتوقف المجموعة غير المصانة عن كونها جديرة بالثقة.
ما الذي يجعل الاختبار الآلي متقلبًا، وكيف أصلحه؟ عادة ما يأتي التقلب من افتراضات التوقيت، أو الحالة المشتركة بين الاختبارات، أو التأكيدات على البيانات المتغيرة مثل الطوابع الزمنية. قم بإصلاح ذلك عن طريق عزل بيانات الاختبار، والتأكيد على الهيكل بدلاً من القيم المتغيرة الدقيقة، وإزالة الترتيب الضمني بين الاختبارات. مجموعة متقلبة تدرب الفريق على تجاهل حالات الفشل، لذا تعامل مع التقلب كخطأ حقيقي.
كيف أقيس ما إذا كان اختباري الآلي يعمل؟ تتبع عدد الأخطاء الحقيقية التي تكتشفها المجموعة قبل الإصدار مقابل عدد الأخطاء التي تتسرب إلى الإنتاج، ومدى سرعة تشغيل المجموعة. مجموعة تكون "خضراء" لأشهر بينما تتسرب أخطاء الإنتاج لا تحميك؛ تغطية التأكيدات ذات المعنى أهم من العدد الخام للاختبارات.