المكاسب:
- القدرة على إجراء اختبار واجهة برمجة التطبيقات بعمق مع دعم الذكاء الاصطناعي في رمز الحالة والمخطط/العقد وقاعدة العمل والطبقات السلبية/التفويض
- القدرة على إنشاء مخطط JSON من نموذج الاستجابة وتجنب الثقة الزائفة عند النظر فقط إلى رمز الحالة مع النوع والتحقق الحتمي
- القدرة على اختبار السيناريوهات الأمنية مثل الترخيص وIDOR باستخدام البيانات الاصطناعية ولأغراض دفاعية فقط ضمن الترخيص
تتحدث معظم البرامج الحديثة مع بعضها البعض في الخلفية عبر واجهة برمجة التطبيقات (واجهة برمجة التطبيقات - الواجهة التي يتحدث فيها قطعتان من البرامج وفقًا لعقد محدد). عندما يضيف تطبيق جوال عناصر إلى سلة التسوق، فإنه يرسل في الواقع طلبًا إلى واجهة برمجة التطبيقات (API) على الخادم. يتحقق اختبار واجهة برمجة التطبيقات (API) من أن هذه المحادثة صحيحة وآمنة ومتسقة، بغض النظر عن الواجهة؛ إنه أسرع وأكثر استقرارًا وأعمق من اختبار واجهة المستخدم. يعتبر الذكاء الاصطناعي (AI) فعالاً للغاية في اختبار واجهة برمجة التطبيقات (API): فهو يُنشئ اختبارات من تعريف واجهة برمجة التطبيقات (API)، ويستخرج مخطط الاستجابة (العقد الذي يحدد بنية البيانات)، ويسرد حالات الحافة. ولكن مرة أخرى ينطبق التحذير المركزي: الذكاء الاصطناعي لا يعرف قواعد العمل الحقيقية لواجهة برمجة التطبيقات الخاصة بك؛ يميل إلى إنتاج اختبارات سطحية تؤكد فقط "إرجاع 200". مهمتك هي التأكد من أن الاختبار يتحقق من العقد الفعلي ومنطق العمل.
في هذه الوحدة، ستتعلم كيفية إعداد اختبارات API العميقة المدعومة بالذكاء الاصطناعي باستخدام أساليب مثل Postman وREST Assured والتحقق من صحة المخطط.
طبقات اختبار API
فكر في اختبار واجهة برمجة التطبيقات (API) في عدة مجالات، حيث يساعد الذكاء الاصطناعي بشكل مختلف في كل طبقة:
1. رمز الحالة والاستجابة الأساسية. هل يقوم الطلب بإرجاع رمز حالة HTTP المتوقع (200/201 للنجاح، 400/401/404 للخطأ)؟ هذه هي الطبقة الأكثر سطحية. الذكاء الاصطناعي ينتج بسهولة ولكنه وحده يعطي ثقة زائفة.
2. التحقق من صحة المخطط/العقد. هل يتناسب هيكل الرد مع العقد - هل الحقول المتوقعة موجودة، هل أنواعها صحيحة، هل الحقول المطلوبة مفقودة؟ يمكن للذكاء الاصطناعي إنشاء مخطط JSON - المعيار الذي يحدد بنية مستند JSON - من عينة الاستجابة، ويمكن التحقق من صحة الاختبارات مقابل هذا المخطط. يعد هذا أقوى بكثير من كتابة التأكيد الميداني يدويًا.
3. التحقق من صحة قاعدة العمل. القيمة الحقيقية هنا: "بالنسبة لطلب بقيمة 1000 ليرة تركية، يجب أن يكون حقل الخصم 100"، "لا يمكن إلغاء الطلب الملغى مرة أخرى". لن يتحقق الذكاء الاصطناعي من هذه القواعد إلا إذا أعطيته القواعد؛ إذا لم تعطها، فسوف تقفز.
4. السلبية والأمن. 401 للرمز غير الصالح، 403 للوصول إلى بيانات شخص آخر، مسح 400 للنص السيئ. تعد اختبارات التفويض (التحقق من أنه لا يمكن للمستخدم الوصول إلا إلى بياناته الخاصة) جوهر أمان واجهة برمجة التطبيقات (API) ويتم إجراؤها لأغراض دفاعية.
نصيحة: لا تطلب إجراء اختبار دون مطالبة الذكاء الاصطناعي "بالتحقق ليس فقط من رمز الحالة، ولكن أيضًا من مخطط الاستجابة وقواعد العمل تلك." بخلاف ذلك، ستتبقى لديك اختبارات تقول "تم إرجاع 200، تم اجتيازها" ولكنك لا تلاحظ أن واجهة برمجة التطبيقات (API) تقوم بإرجاع بيانات تالفة.
موجه ضعيف / موجه قوي
ضعيف: "اكتب اختبارات لواجهة برمجة التطبيقات هذه."
قوي: "اكتب اختبارات REST Assured (Java) لنقطة نهاية POST /order. الاتفاقية: معرف المنتج والكمية إلزاميان في النص؛ 201 و{orderId، Total، Discount، Status} يتم إرجاعهما عند النجاح. قواعد العمل: خصم 10% على 1000 ليرة تركية؛ 400 إذا كانت الكمية <=0؛ 401 إذا كان الرمز غير صالح؛ 403 عند رؤية طلب مستخدم آخر. الاختبارات: (1) رمز الحالة، (2) التحقق من صحة مخطط JSON للاستجابة، (3) قاعدة عمل الخصم، (4) ربط كل تأكيد بقاعدة عمل صريحة، لا تقم فقط بالتحقق من 200/201."
يعطي الموجه القوي العقد وقواعد العمل وسيناريوهات الأمان وتوقعات التحقق من صحة المخطط.
اختبار العقد: منع الانفصال بين الفرق
في بنيات الخدمات الصغيرة (الهيكل الذي ينقسم فيه التطبيق إلى خدمات صغيرة مستقلة عن بعضها البعض وتتحدث مع واجهة برمجة التطبيقات)، يؤدي تغيير تنسيق استجابة الخدمة إلى تعطيل الخدمات الأخرى المتصلة بها بصمت. اختبار العقد - الاختبار الذي يتحقق من أن عقد واجهة برمجة التطبيقات (API) بين خدمة المزود وخدمة المستهلك لم يتم انتهاكه من كلا الجانبين - يكتشف مثل هذه الانقطاعات مبكرًا. الفكرة هي كما يلي: يحدد المستهلك شكل الاستجابة التي يتوقعها من المنتج على أنها "عقد"؛ مع كل تغيير، تختبر الشركة المصنعة أنها لا تزال متوافقة مع هذه الاتفاقية. لذلك عندما يتغير اسم أو نوع الحقل، يقوم المستهلك بإعلام خط الأنابيب قبل أن يتعطل.
يعمل الذكاء الاصطناعي على تسريع مهمتين في هذا السياق: صياغة عقد يعكس توقعات المستهلك من استجابة واجهة برمجة التطبيقات الحالية، ووضع علامة مسبقة على بند العقد الذي قد يؤدي التغيير إلى كسره. لكن العقد في حد ذاته هو قرار تجاري: فالخبير هو الذي يحدد المجالات الحاسمة حقًا، وأي التغييرات ستؤدي إلى كسر التوافق مع الإصدارات السابقة - ويستمر المستهلكون القدامى في العمل. منظمة العفو الدولية تكتب العقد؛ أنت من يوافق على ذلك.
نصيحة: يعد حذف حقل أو تغيير نوع الحقل في واجهة برمجة التطبيقات (API) دائمًا تغييرًا عاجلاً. عادةً ما تكون إضافة حقول جديدة أمرًا آمنًا. إن قيام الذكاء الاصطناعي بتصنيف التغيير على أنه "كسر أو آمن" يوفر فحصًا أمنيًا سريعًا قبل الإصدار.
ساعي البريد أم يعتمد على الكود؟
المعيار
ساعي البريد / نيومان
ضمان الراحة / الكود (Java، C#، JS)
التعلم
سهل، بصري
المعرفة بالكود المطلوبة
التحكم في الإصدار
مجموعة JSON
مباشرة في كود المصدر
منطق معقد
محدودة (نصوص JS)
قوة البرمجة الكاملة
تكامل CI/CD
مع نيومان
تعتمد بشكل مباشر على البناء
التحقق من صحة المخطط
مع البرامج النصية للاختبار
قوية مع المكتبة
مقياس الفريق
صغيرة / متوسطة
كبيرة وناضجة
يقوم الذكاء الاصطناعي بإنشاء كود لكليهما؛ كن واضحا أي واحد تريد.
أربعة قوالب قابلة للنسخ
1) اختبار واجهة برمجة التطبيقات (API) على أساس العقد:
دورك: مهندس اختبار واجهة برمجة التطبيقات (API). اكتب اختبارات لنقطة النهاية التالية باستخدام [الأداة/اللغة]: [الطريقة + المسار].العقد: [الحقول المطلوبة، رمز النجاح، بنية الاستجابة].قواعد العمل: [القواعد].طبقات الاختبار: (1) رمز الحالة (2) التحقق من صحة مخطط الاستجابة (3) كل قاعدة عمل (4) سلبية + ترخيص.اربط كل تأكيد بقاعدة/شرط العقد ذي الصلة.
2) إنشاء المخطط من استجابة العينة:
قم بإنشاء مخطط JSON من نموذج استجابة API أدناه. حدد الحقول والأنواع وقيود التنسيق المطلوبة (التاريخ والبريد الإلكتروني ونطاق الأرقام). ثم قم بإعطاء مثال اختباري يتم التحقق من صحته مقابل هذا المخطط. نموذج الاستجابة: [لصق JSON]
3) السيناريوهات السلبية والترخيصية:
إنشاء حالات اختبار سلبية وأمنية لنقطة النهاية[نقطة النهاية]. يتضمن: حقل مفقود/مطلوب، نوع خاطئ، قيمة كبيرة جدًا، رمز مميز غير صالح/منتهي الصلاحية، الوصول إلى مورد غير مصرح به (IDOR - الوصول إلى سجل شخص آخر عن طريق تغيير المعرف)، حد المعدل. حدد رمز الحالة المتوقع ونص الخطأ لكل سيناريو. ملاحظة: سيتم اختباره فقط على واجهة برمجة التطبيقات (API) الخاصة بي، والمصرح بها.
4) مراقبة الثقة الزائفة:
تحقق من اختبار API هذا. هل سيكتشف هذا الاختبار ما إذا كان الخادم قد أعاد رمز الحالة الصحيح ولكن FALSEbody/البيانات؟ إذا لم يكن الأمر كذلك، أضف التحقق من صحة المخطط وقاعدة العمل. الاختبار: [اختبار اللصق]
ثلاث حالات صغيرة
الحالة 1 - قوة التحقق من صحة المخطط. كان الفريق يتحقق فقط من رمز الحالة في الاختبارات التي أجراها باستخدام الذكاء الاصطناعي. في أحد الإصدارات، بدأت واجهة برمجة التطبيقات (API) بإرجاع الحقل الإجمالي بشكل خاطئ كنص ("1200")؛ ظلت الاختبارات باللون الأخضر لأنها كانت لا تزال تعيد 200. وتعطل تطبيق الهاتف المحمول. بعد إضافة التحقق من صحة النوع باستخدام قالب "إنشاء المخطط من نموذج الاستجابة"، تم اكتشاف نفس الخطأ على الفور.
الحالة 2 - فجوة السلطة (IDOR). أجرى أحد الخبراء اختبار IDOR بين "السيناريوهات السلبية وسيناريوهات التفويض" التي تم إنشاؤها بواسطة الذكاء الاصطناعي: لقد طلب معرف الطلب الخاص بالمستخدم "ب" مع الرمز المميز للمستخدم "أ". وأعادت واجهة برمجة التطبيقات بيانات 200 و"ب" - وهي ثغرة أمنية خطيرة في التفويض. أغلق هذا الاختبار الدفاعي تسرب البيانات قبل بدء تشغيله.
الحالة 3 - تجاوز قواعد العمل. أنشأ الذكاء الاصطناعي 8 اختبارات لنقطة نهاية الخصم؛ كان الجميع يتحققون من 200، ولم يكن أي منهم يتحقق من مبلغ الخصم. أضاف الخبير قواعد العمل إلى الموجه وأعاد إنتاجها. كشفت الاختبارات الجديدة أنه تم حساب الخصم بشكل غير صحيح عند حد 1000 ليرة تركية (تم تطبيق الخصم أيضًا على 999). مراقبة العقود ليست كافية؛ التحكم في قواعد العمل أمر لا بد منه.
الأخطاء الشائعة
- مجرد النظر إلى رمز الحالة. لقول "عاد 200 ومضى"؛ عدم رؤية الجسد الفاسد (الثقة الكاذبة).
- تجاوز التحقق من صحة المخطط. عدم التحقق من أنواع الحقول والالتزامات؛ تغييرات النوع تمر بصمت.
- طلب الاختبار دون توفير قواعد العمل. الذكاء الاصطناعي لا يعرف القواعد؛ إنها تنتج التحكم الفني فقط.
- نسيان السيناريوهات السلبية والاستحقاق. يتم اكتشاف الثغرات الأمنية (IDOR، الوصول غير المصرح به) فقط من خلال هذه الاختبارات.
- استخدام الرموز والبيانات الحقيقية/الإنتاجية. استخدام الوسائط المخصصة والبيانات الاصطناعية للاختبار؛ لا تقم بلصق المفاتيح الحقيقية في السيارة.
- اختبار أمني غير مصرح به. لا تقم بإجراء اختبارات الترخيص إلا على واجهة برمجة التطبيقات (API) الخاصة بك وبإذن.
في ملخص
يتحقق اختبار واجهة برمجة التطبيقات (API) من صحة أجزاء البرنامج بسرعة وبعمق، بغض النظر عن الواجهة. منظمة العفو الدولية. تعتبر اختبارات العقود فعالة جدًا في إنشاء مخطط JSON والسيناريوهات السلبية/الأمانية من استجابة العينة. لكن الاختبارات السطحية التي تتحقق فقط من رمز الحالة تعطي ثقة زائفة. تتطلب جميع الطبقات الأربع: رمز الحالة، والتحقق من صحة المخطط، وقاعدة العمل، والسلبية، والتفويض. وضع قواعد العمل والعقد على الفور؛ إجراء اختبارات الأمان باستخدام البيانات الاصطناعية وبعد الحصول على إذن فقط.
مهمة التطبيق
اختر نقطة نهاية API من مشروعك الخاص. اطلب من الذكاء الاصطناعي كتابة اختبارات من أربع طبقات باستخدام قالب "اختبار واجهة برمجة التطبيقات المستندة إلى العقد". ثم قم بإضافة التحقق من صحة النوع/التنفيذ من خلال "إنشاء المخطط من نموذج الاستجابة" وتطبيق "التحقق من الثقة الزائفة". قم بتشغيل سيناريو IDOR/تفويض واحد على الأقل في بيئة الاختبار الخاصة بك. الإبلاغ عن أي انتهاكات للعقد أو قواعد العمل تجدها؛ إذا لم تتمكن من العثور على أي منها، قم بإجراء الاختبار على استجابة مشوهة عمدًا لإثبات أنها اكتشفتها.
قائمة مرجعية
- [ ] قمت بتغطية الطبقات الأربع للاختبار (الحالة، المخطط، قاعدة العمل، السلبية/التفويض).
- [ ] من الواضح أنني أعطيت العقد وقواعد العمل لمنظمة العفو الدولية.
- [ ] أقوم بإعداد اختبارات للتحقق من صحة مخطط الاستجابة (حقل، نوع، أمر حتمي).
- [ ] لقد قمت بتجربة سيناريو ترخيص/IDOR واحد على الأقل بشكل دفاعي.
- [ ] لقد استخدمت بيئة الاختبار والبيانات الاصطناعية بدلاً من الرمز/البيانات الحقيقية.
- [ ] لقد أثبتت من خلال "فحص الثقة الزائفة" أن كل اختبار يلتقط الاستجابة التالفة.