معظم أخطاء واجهات برمجة التطبيقات (API) ليست غريبة. قد تكون حقلاً مفقوداً، أو رمز حالة خاطئ، أو انتهاء مهلة تحت الحمل، أو تغييراً جذرياً تم شحنه لأن أحداً لم يتحقق من العقد. يلتقط الاختبار المخصص بعض هذه الأخطاء بالصدفة. بينما تلتقطها الاستراتيجية عن قصد.
استراتيجية اختبار واجهات برمجة التطبيقات هي خطة لما تختبره، وفي أي طبقة، ومتى يتم ذلك في دورة التسليم. تحدد أي الفحوصات يتم تشغيلها مع كل التزام (commit)، وأيها يتم تشغيلها ليلاً، وأيها يتم تشغيلها قبل الإصدار. تخبرك أين يجب أن تبذل الجهد لتحقيق أقصى تغطية بأقل قدر من الصيانة.
ماذا تعني استراتيجية اختبار واجهات برمجة التطبيقات بالفعل
تجيب الاستراتيجية عن أربعة أسئلة قبل أن تكتب تأكيداً واحداً.
ماذا تختبر؟ نقاط النهاية والتدفقات التي تحمل قيمة تجارية. تحتاج واجهة برمجة تطبيقات الدفع إلى تغطية أكبر من نقطة نهاية فحص الحالة (health-check). قم بالترتيب حسب المخاطر وحركة المرور، وليس حسب مدى سهولة الوصول إلى نقطة النهاية.
في أي طبقة؟ تنتمي بعض الفحوصات إلى طلب واحد. بينما يحتاج البعض الآخر إلى خدمتين أو ثلاث تتحدثان مع بعضهما البعض. وضع كل فحص في الطبقة العليا يجعل مجموعتك بطيئة وهشة.
متى يتم تشغيله؟ تُشغل الفحوصات السريعة مع كل دفع (push). تُشغل الفحوصات البطيئة وفق جدول زمني أو قبل الإصدار. خلط الاثنين يعني إما أن ملاحظاتك بطيئة أو أن تغطيتك ضعيفة.
ماذا يعتبر نجاحاً؟ الاختبار الذي يتحقق فقط من استجابة 200 لا يخبرك شيئاً تقريباً. حدد رمز الحالة والمخطط وقيم الحقول ووقت الاستجابة الذي تتوقعه.
بمجرد أن تتمكن من الإجابة على هذه الأسئلة الأربعة لواجهة برمجة تطبيقاتك، يكون لديك استراتيجية. بقية هذا الدليل يوضح التفاصيل.
لماذا تتفوق الاستراتيجية على الاختبار المخصص (Ad-Hoc Testing)
الاختبار المخصص يعني أنك ترسل طلباً، وتلقي نظرة سريعة على الاستجابة، ثم تنتقل. إنه يعمل في عرض توضيحي. لكنه ينهار على خدمة حقيقية لثلاثة أسباب.
إنه لا يتكرر. لا يمكن للشخص التالي إعادة تشغيل فحصك اليدوي، لذا تتسلل الانحدارات مرة أخرى. بينما يتم تشغيل الاختبار التلقائي المحفوظ بنفس الطريقة في كل مرة.
يميل نحو المسار السعيد (happy path). عندما تختبر يدوياً، فإنك تختبر ما تتوقع أن يعمل. نادراً ما ترسل حمولة بيانات مشوهة، أو رمزاً منتهية صلاحيته، أو قائمة تحتوي على 10,000 عنصر. تلك هي الحالات التي تتعطل في الإنتاج.
إنه لا يتوسع. الخدمة التي تحتوي على 40 نقطة نهاية و 5 بيئات تعني 200 فحص يدوي لكل إصدار. لا أحد يفعل ذلك يدوياً، لذا تتقلص التغطية مع نمو واجهة برمجة التطبيقات. الاستراتيجية تبادل تكلفة إعداد لمرة واحدة بتغطية قابلة للتكرار: تكتب الاختبارات مرة واحدة، وتُشغل مع كل تغيير بدون تدخلك.
هرم اختبار واجهات برمجة التطبيقات
هرم الاختبار هو قاعدة عامة لعدد الاختبارات التي يجب كتابتها في كل طبقة. واسع من الأسفل، ضيق من الأعلى.
/\
/ \ اختبارات شاملة / تدفق العمل (قليلة، بطيئة، ذات قيمة عالية)
/----\
/ \ اختبارات التكامل / العقد (بعضها، سرعة متوسطة)
/--------\
/ \ اختبارات الوحدة / الطلب الفردي (كثيرة، سريعة، رخيصة)
/____________\
الطبقة السفلية: فحوصات الطلب الفردي. يضرب كل اختبار نقطة نهاية واحدة ويتحقق من الاستجابة. هذه سريعة، ورخيصة الكتابة، وسهلة التصحيح. عندما يفشل أحدهما، تعرف بالضبط أي نقطة نهاية تعطلت. تعيش معظم اختباراتك هنا.
الطبقة الوسطى: فحوصات التكامل والعقود. تتحقق هذه من أن الخدمات تتفق على شكل البيانات التي تتبادلها، وأن الطلب الذي يمس نظامين أو ثلاثة أنظمة يعيد النتيجة الصحيحة. إنها أبطأ لأنها تتضمن أجزاء متحركة أكثر، لكنها تلتقط الأعطال التي تفوتها اختبارات الطلب الفردي.
الطبقة العليا: تدفقات العمل الشاملة (end-to-end). تشغل هذه رحلة مستخدم كاملة عبر عدة نقاط نهاية: إنشاء طلب، الدفع مقابله، التحقق من الحالة. إنها تعطي أكبر قدر من الثقة وتكلف أكثر للصيانة، لذا حافظ عليها قليلة واحتفظ بها للمسارات الحرجة.
الخطأ الذي ترتكبه الفرق هو عكس الهرم: كومة من اختبارات النهاية إلى النهاية البطيئة ولا توجد تقريباً اختبارات سريعة. يمنحك ذلك حلقات ملاحظات طويلة وفشلاً متقلباً. ادفع التغطية إلى أسفل الهرم كلما استطاعت طبقة أدنى التقاط نفس الخطأ.
أنواع الاختبارات ومتى يتم تطبيق كل منها
تستخدم الاستراتيجية الكاملة عدة أنواع من الاختبارات، كل منها يهدف إلى فئة مختلفة من الفشل. إليك ما يتحقق منه كل نوع ومتى يجب اللجوء إليه.
الاختبار الوظيفي
يتحقق الاختبار الوظيفي من أن نقطة النهاية تفعل ما ينص عليه مواصفاتها. أرسل طلباً صالحاً، وتحقق من رمز الحالة، ومخطط الاستجابة، وقيم الحقول. هذا هو أساس مجموعتك وأول شيء يجب أتمتته على أي نقطة نهاية جديدة. للحصول على شرح أعمق، راجع الاختبار الوظيفي لواجهة برمجة التطبيقات.
يبدو الفحص الوظيفي لنقطة نهاية مستخدم كما يلي:
GET /api/users/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer <token>
التأكيدات:
- الحالة هي
200. - يتطابق الجسم مع مخطط
User. idيساوي42.emailهو سلسلة بريد إلكتروني صالحة.
اختبار التكامل
يتحقق اختبار التكامل من أن نقاط النهاية تعمل معاً وأن واجهة برمجة تطبيقاتك تتحدث بشكل صحيح مع تبعياتها: قاعدة البيانات، مزود الدفع، خدمة تابعة. يمكن أن ينجح الاختبار الوظيفي على تبعية وهمية (mocked dependency) ويفشل عندما يتم توصيل الحقيقية. تغلق اختبارات التكامل هذه الفجوة. يتم تغطية الطريقة الكاملة في اختبار التكامل لواجهة برمجة التطبيقات.
اختبار الانحدار
يعيد اختبار الانحدار تشغيل مجموعتك الحالية بعد كل تغيير للتأكد من أنك لم تكسر شيئاً كان يعمل. هذا هو المكان الذي تكسب فيه مجموعة الاختبارات التلقائية المحفوظة قيمتها. لا تكتب اختبارات انحدار جديدة؛ بل تشغل الاختبارات التي لديك بالفعل، وفق جدول زمني وقبل الإصدار. راجع اختبار الانحدار لمعرفة كيفية تنظيم ذلك.
اختبار العقد
يتحقق اختبار العقد من أن مزود ومستهلك واجهة برمجة التطبيقات يتفقان على الشكل الدقيق للطلب والاستجابة. يلتقط التغييرات الجذرية (حقل تم تغيير اسمه، تغيير نوع، نقطة نهاية تمت إزالتها) قبل أن تصل إلى المستهلك. إذا كنت تنشر واجهة برمجة تطبيقات تعتمد عليها فرق أو عملاء آخرون، فإن اختبار العقد ليس اختيارياً. التفاصيل موجودة في اختبار عقد واجهة برمجة التطبيقات.
اختبار التحميل والأداء
يقيس اختبار التحميل كيفية تصرف واجهة برمجة تطبيقاتك تحت حركة المرور المتزامنة: وقت الاستجابة عند الشريحة 95، معدل الخطأ، الإنتاجية، والنقطة التي يتدهور فيها الأداء. قم بتشغيله قبل الإطلاق، وقبل ارتفاع حركة المرور المعروف، وبشكل دوري لاكتشاف التدهور البطيء. هذا تخصص منفصل عن الاختبار الوظيفي ويستخدم أدوات مختلفة؛ راجع أدوات اختبار التحميل للخيارات.
اختبار الأمان
يتحقق اختبار الأمان من أن واجهة برمجة تطبيقاتك ترفض ما يجب أن ترفضه: الطلبات بدون رمز مميز، الطلبات ذات النطاق الخاطئ، محاولات الحقن، والوصول إلى بيانات مستخدم آخر. تحتاج كل نقطة نهاية تمس بيانات حساسة إلى فحوصات المصادقة والتفويض على الأقل. المجموعة الكاملة من التقنيات موجودة في اختبار أمان واجهة برمجة التطبيقات.
إليك دليل تقريبي لمتى يتم تشغيل كل نوع:
| نوع الاختبار | يلتقط | يعمل |
|---|---|---|
| وظيفي | حالة خاطئة، مخطط، أو قيم | مع كل التزام |
| تكامل | تدفقات خدمة إلى خدمة معطلة | مع كل التزام أو ليلاً |
| انحدار | سلوك موجود تعطل حديثاً | مع كل التزام وقبل الإصدار |
| عقد | تغييرات جذرية في الواجهة | مع كل التزام على المزود |
| تحميل | بطء وفشل تحت حركة المرور | قبل الإطلاق ومجدول |
| أمان | مصادقة، حقن، كشف بيانات | قبل الإصدار ومجدول |
الحالات الإيجابية والسلبية والحالات القصوى (Edge Cases)
لكل نقطة نهاية، غطِ ثلاثة أنواع من المدخلات. يعد تخطي النوعين الثاني والثالث الفجوة الأكثر شيوعاً في مجموعة حقيقية.
ترسل الحالات الإيجابية مدخلات صالحة وتتوقع النجاح. طلب إنشاء مستخدم به جسم جيد التكوين يعيد 201 والسجل الجديد. هذه تؤكد أن نقطة النهاية تعمل.
ترسل الحالات السلبية مدخلات غير صالحة وتتوقع فشلاً نظيفاً وصحيحاً. يجب أن يعيد الحقل المطلوب المفقود 400، وليس 500. يجب أن يعيد الطلب بدون رمز مميز 401. يجب أن يعيد الطلب لسجل لا تملكه 403 أو 404، ولا يعيد السجل أبداً. يتحقق الاختبار السلبي من معالجة الأخطاء لديك، وهو المكان الذي غالباً ما تتسرب فيه واجهات برمجة التطبيقات أو تتعطل.
تدفع الحالات القصوى حدود المدخلات الصالحة: قائمة فارغة، الحد الأقصى لطول السلسلة المسموح به، صفر، رقم سالب، اسم يونيكود، طابع زمني عند حدود التوقيت الصيفي. هذه تجد أخطاء "الخطأ بواحد" وأخطاء تجاوز السعة (overflow bugs).
قاعدة صلبة: لكل اختبار إيجابي، اكتب اختباراً سلبياً واحداً على الأقل. إذا كانت نقطة نهاية طلب الإنشاء لديك تحتوي على اختبار مسار سعيد واحد ولا يوجد اختبار لكمية سالبة أو معرف عميل مفقود، فإن تغطيتك أضعف مما تبدو عليه.
POST /api/orders HTTP/1.1
Content-Type: application/json
{ "customerId": "c_123", "quantity": -5 }
المتوقع: الحالة 400، ويحتوي الجسم على خطأ تحقق واضح يسمي quantity. إذا أعاد هذا 201 أو 500، فقد وجدت خطأً لم يكن اختبار المسار السعيد ليلتقطه أبداً.
بيانات الاختبار والبيئات
الاختبارات لا تكون جديرة بالثقة إلا بقدر البيانات والبيئة التي تُجرى عليها.
استخدم بيانات اختبار مخصصة. لا تختبر مقابل سجلات الإنتاج، ولا تعتمد على وجود صف معين. قم بإنشاء البيانات التي يحتاجها اختبارك، أو ازرع تجهيزاً معروفاً في بداية التشغيل. للحصول على مدخلات واقعية ومتنوعة، يوفر مولد البيانات ساعات؛ راجع كيفية إنشاء بيانات اختبار API واقعية.
اجعل الاختبارات مستقلة. يجب أن يقوم كل اختبار بإعداد حالته الخاصة وتنظيف نفسه بعد الانتهاء. الاختبار الذي يعتمد على تشغيل اختبار سابق هو اختبار يفشل بترتيب عشوائي. عندما تحتاج إلى تمرير قيمة من طلب إلى آخر (معرف، رمز مميز)، افعل ذلك بشكل صريح داخل السيناريو، وليس من خلال حالة عامة مشتركة.
عزل البيئات. احتفظ ببيئات منفصلة للتطوير المحلي، CI، التجربة (staging)، والإنتاج. قم بتخزين عنوان URL الأساسي، والرموز المميزة، والإعدادات الأخرى لكل بيئة بحيث يعمل نفس الاختبار في أي مكان عن طريق تبديل متغير واحد. يساعدك فهم الفرق بين بيئة الاختبار الافتراضية (sandbox) وبيئة الاختبار الكاملة على اختيار الهدف الصحيح؛ راجع بيئة الاختبار الافتراضية مقابل بيئة الاختبار.
قم بتحديد المعلمات باستخدام المتغيرات. لا تقم أبداً بتشفير (hardcode) مضيف أو سر في الاختبار. ارجع إلى متغير بيئة بحيث يتم تشغيل نفس السيناريو مقابل البيئة المحلية، التجربة، و CI بدون تعديلات.
الانتقال يساراً: الاختبار مبكراً، وليس أكثر فقط
يعني "الانتقال يساراً" نقل الاختبار إلى وقت أبكر في دورة التسليم، أقرب إلى لحظة كتابة الكود. كلما تأخر اكتشاف الخطأ، زادت تكلفة إصلاحه. عدم تطابق مخطط يتم اكتشافه في وقت التصميم هو تعديل يستغرق خمس دقائق. نفس عدم التطابق الذي يتم اكتشافه في الإنتاج هو حادث.
ثلاث خطوات عملية تنقل اختبارك إلى اليسار:
صمم العقد أولاً. حدد مخططات الطلب والاستجابة لواجهة برمجة التطبيقات قبل بناء نقطة النهاية. يمكنك الآن إنشاء اختبارات ووهميات (mocks) من هذا العقد والبدء في اختبار الواجهة قبل وجود التنفيذ.
اختبر مقابل وهمي (mock) بينما لم يتم الانتهاء من الواجهة الخلفية. لا يجب أن ينتظر العمل الأمامي والتكامل نقطة النهاية الحقيقية. يتيح خادم وهمي مبني من المخطط للمستهلكين اختبار جانبهم بالتوازي.
قم بتشغيل الفحوصات السريعة مع كل التزام (commit). الاختبارات الوظيفية والعقدية التي تعمل في ثوانٍ تنتمي إلى حلقة المطور الداخلية، وليس دفعة ليلية. كلما رأى المطور اختباراً أحمر مبكراً، كلما كان الإصلاح أرخص.
الحالة الكاملة لذلك هي في اختبار الانتقال يساراً في تطوير واجهة برمجة التطبيقات. النتيجة بسيطة: الأخطاء تكلف أقل عندما تجدها مبكراً.
أتمتة الاختبارات في التكامل المستمر (CI)
لا تكون الاستراتيجية حقيقية إلا إذا كانت تعمل بدون تدخلك. الهدف هو خط أنابيب يقوم بتشغيل مجموعتك مع كل دفع (push)، ويمنع الدمج في حالة الفشل، وينتج تقريراً يمكنك قراءته.
يتكون خط أنابيب CI النموذجي لاختبارات API من ثلاث مراحل:
- مع كل دفع (push): قم بتشغيل الاختبارات الوظيفية والعقدية السريعة. افشل البناء إذا فشل أي تأكيد. هذه هي بوابتك.
- ليلاً أو قبل الإصدار: قم بتشغيل مجموعات التكامل والاختبار الشامل البطيئة، بالإضافة إلى فحوصات التحميل والأمان.
- دائماً: انشر تقريراً قابلاً للقراءة آلياً (JUnit XML هو التنسيق الشائع) بحيث تظهر لوحة معلومات CI لديك عدد النجاحات والفشل.
تبدو مهمة GitHub Actions بسيطة تشغل مجموعة اختبار API مع كل دفع كما يلي:
name: api-tests
on: [push]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- name: Run API tests
run: npm test
يعتمد الأمر الدقيق على أدواتك. النمط هو نفسه في كل مكان: قم باستعارة الكود، وإعداد بيئة التشغيل، وتشغيل المجموعة، ودع رمز الخروج غير الصفري يفشل البناء. لمعالجة CI الكاملة، بما في ذلك التخزين المؤقت (caching)، وأسرار البيئة، وإعداد التقارير، راجع كيفية أتمتة اختبارات API في CI/CD.
كيف تتناسب Apidog مع الاستراتيجية
الاستراتيجية المذكورة أعلاه لا تعتمد على أداة معينة. يمكنك تجميعها من أدوات منفصلة للتصميم والاختبار والوهمية (mocking) والتوثيق. تكلفة ذلك هي الانجراف: المواصفات والاختبارات والوهمية تصبح غير متزامنة، وتستهلك وقتاً في التوفيق بينها.
يجمع Apidog كل ذلك في مكان واحد. يمكنك تصميم عقد API، وكتابة سيناريوهات الاختبار بناءً عليه، وإنشاء وهمية من نفس المخطط، ونشر الوثائق، كل ذلك من مصدر واحد للحقيقة. ولأن الاختبارات والوهمية تأتي من نفس العقد، يتوقف اختبار العقد والاختبار المتجه يساراً عن كونهما عملاً إضافياً: إنهما أصبحا الافتراضي.
بالنسبة لنصف استراتيجية CI، يقوم Apidog CLI بتشغيل سيناريوهات الاختبار ومجموعاتك المحفوظة دون واجهة رسومية (headlessly). إنه حزمة Node، لذا يمكن إضافته إلى أي خطوة CI يمكنها تشغيل Node.
قم بتثبيته:
npm install -g apidog-cli
قم بتشغيل سيناريو أو مجموعة محفوظة في CI. أمر التشغيل يعتمد على الأعلام (flag-based)؛ تمرر معرف الهدف، ومعرف البيئة، والمبلغين الذين تريدهم:
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-t <scenarioOrSuiteId> \
-e <environmentId> \
-r cli,html,junit
--access-tokenيقوم بالمصادقة على التشغيل. قم بتخزين الرمز المميز كسري CI وقم بالإشارة إليه كمتغير بيئة.-tهو معرف السيناريو، المجلد، أو المجموعة التي تريد تشغيلها.-eهو معرف البيئة، لذا يتم تشغيل نفس المجموعة مقابل بيئة التجربة (staging) أو CI عن طريق تبديل هذه القيمة.-rيختار واحداً أو أكثر من المبلغين منcli،html،json، وjunit. يغذي إخراجjunitلوحة معلومات CI الخاصة بك؛ يعطيhtmlتقريراً قابلاً للقراءة بشرياً.
لتشغيل مدفوع بالبيانات، وجه CLI إلى ملف بيانات أو معرف بيانات اختبار محفوظ:
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-t <scenarioId> \
-e <environmentId> \
-d ./data/users.csv \
-r cli,junit
أضف --upload-report لدفع التقرير إلى السحابة، أو --branch للتشغيل مقابل فرع معين. يشغل CLI سيناريوهات ومجموعات Apidog المحفوظة. إنه ليس مرسلاً تفاعلياً للطلبات وليس مولداً للتحميل، لذا قم بإقرانه بأداة تحميل مخصصة لطبقة الأداء في هرمك.
قائمة التحقق لاستراتيجية المبتدئين
إذا كنت تبني استراتيجية من الصفر، فاعمل من خلال هذه القائمة بالترتيب.
- [ ] رتب نقاط النهاية الخاصة بك حسب المخاطر وحركة المرور. غطِ النقاط الأعلى أولاً.
- [ ] اكتب اختباراً وظيفياً إيجابياً لكل نقطة نهاية مصنفة.
- [ ] أضف اختباراً سلبياً واحداً على الأقل لكل نقطة نهاية (مصادقة مفقودة، إدخال غير صالح).
- [ ] أضف اختبارات الحالات القصوى (edge-case) لنقاط النهاية التي تقبل القوائم أو الأرقام أو النص الحر.
- [ ] أضف اختبارات عقود لأي واجهة برمجة تطبيقات تستهلكها فرق أو عملاء آخرون.
- [ ] أضف اختبارات تكامل للتدفقات التي تعبر خدمتين أو أكثر.
- [ ] قم بإعداد بيئات منفصلة بمتغيرات وأسرار خاصة بكل بيئة.
- [ ] استخدم بيانات اختبار مُنشأة أو مزروعة؛ حافظ على استقلالية الاختبارات.
- [ ] قم بتشغيل الاختبارات السريعة مع كل دفع (push) في CI؛ افشل البناء في حالة الفشل.
- [ ] جدولة المجموعات البطيئة (التكامل، التحميل، الأمان) ليلاً أو قبل الإصدار.
- [ ] انشر تقرير JUnit حتى تكون أعداد النجاح والفشل مرئية.
- [ ] راجع المجموعة عند تغيير API؛ احذف الاختبارات لنقاط النهاية التي تمت إزالتها.
لا تحتاج إلى كل ذلك في اليوم الأول. ابدأ بالاختبارات الوظيفية والسلبية على نقاط النهاية الأكثر خطورة لديك، واجعلها تعمل في CI، ثم قم بتوسيع المجموعة من هناك.
الأسئلة الشائعة
ما الفرق بين استراتيجية اختبار API وخطة الاختبار؟
الاستراتيجية هي النهج عالي المستوى: أي أنواع الاختبارات تستخدمها، وفي أي طبقة، ومتى يتم تشغيلها. خطة الاختبار هي الوثيقة الملموسة لإصدار أو ميزة معينة: نقاط النهاية الدقيقة، الحالات، البيانات، ومعايير النجاح. الاستراتيجية مستقرة؛ تتغير الخطة لكل إصدار.
كم عدد الاختبارات التي يجب أن تكون في كل طبقة من الهرم؟
لا توجد نسبة ثابتة، لكن الشكل يهم أكثر من الأرقام. يجب أن تكون معظم الاختبارات فحوصات سريعة لطلب واحد في الأسفل، وعدد أقل من اختبارات التكامل والعقد في المنتصف، وعدد قليل فقط من اختبارات تدفق العمل الشاملة في الأعلى. إذا فاق عدد اختباراتك البطيئة في الطبقة العليا عدد اختباراتك السريعة في الطبقة السفلية، قم بإعادة التوازن.
هل أحتاج إلى اختبار العقد إذا كان لدي بالفعل اختبارات وظيفية؟
نعم، إذا كانت فرق أو عملاء آخرون يستهلكون واجهة برمجة تطبيقاتك. تتحقق الاختبارات الوظيفية من أن نقطة النهاية تتصرف بشكل صحيح. تتحقق اختبارات العقد من أن واجهتها لم تتغير بطريقة تكسر المستهلك. يمكن أن يؤدي التغيير إلى استمرار عمل نقطة النهاية بينما لا يزال يكسر كل من يستدعيها.
كم مرة يجب أن أقوم بتشغيل اختبارات التحميل؟
قم بتشغيلها قبل أي إطلاق أو ارتفاع معروف في حركة المرور، ووفق جدول زمني (أسبوعياً أو شهرياً) لاكتشاف انحراف الأداء. اختبارات التحميل بطيئة وتستهلك الكثير من الموارد، لذا لا تنتمي إلى كل التزام (commit). حافظ على الطبقات السريعة في CI وقم بتشغيل اختبار التحميل بشكل منفصل.
هل يمكنني أتمتة الاستراتيجية بأكملها في CI؟
الأجزاء القابلة للتكرار، نعم. تعمل الاختبارات الوظيفية والتكاملية والعقدية والانحدارية بسلاسة في خط أنابيب وتتحكم في عمليات الدمج الخاصة بك. غالباً ما تعمل اختبارات التحميل والأمان وفق جدولها الزمني الخاص بها لأنها أبطأ أو تحتاج إلى بنية تحتية مخصصة. يغطي مشغل الاختبار بدون واجهة رسومية (headless) مثل Apidog CLI النصف الخاص بـ CI عن طريق تنفيذ سيناريوهاتك المحفوظة مع كل دفع (push).