خدمات اختبارات الأداء والأمان

اختبار الأداء: الحمل والضغط والتحمّل

لا تفيد خدمة اختبار الأداء إلا إذا أجاب كل تشغيل عن سؤال سيبني عليه أحدٌ قراراً. اختبار الحمل (Load testing) واختبار الضغط (Stress testing) واختبار التحمّل (Soak testing) تجيب عن أسئلة مختلفة، لذلك تحدد استراتيجية الاختبار أيها يحتاجه إصداركم وما الذي يجب أن يُثبته كل منها. تُشغَّل الثلاثة بأداة Apache JMeter، ويُؤخذ نموذج عبء العمل (workload model) عادةً من تحليلاتكم أو من توقعات العمل: أي نقاط النهاية، وبأي مزيج، وبأي بيانات، وبأي تزامن.

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

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

• اختبار الحمل — هل يحقق المنتج أهدافه عند الحركة التي تتوقعونها؟ عبء العمل المتوقع في المستوى الاعتيادي وفي الذروة، مقارَناً بالأهداف التي حددتموها.
• اختبار الضغط — أين الحد، وكيف يفشل النظام؟ يُرفع الحمل فوق الذروة المتوقعة حتى تظهر الأخطاء أو انتهاءات المهلة، لنرى هل يتراجع بأخطاء واضحة ويتعافى وحده، أم ينهار ويحتاج إلى إعادة تشغيل.
• اختبار التحمّل — هل يبقى النظام سليماً لساعات؟ حمل واقعي ثابت لعدة ساعات يكشف تسرّب الذاكرة، واستنفاد مجمّع الاتصالات، والجداول أو الطوابير التي تكبر حتى يبطؤ كل شيء.
• المقاييس — زمن الاستجابة والإنتاجية (throughput) ومعدل الأخطاء. ويُقرأ زمن الاستجابة عادةً بالمئينات (percentiles): ‏p50 وp95 وp99 لا المتوسط الذي يخفي الذيل البطيء، لكل نقطة نهاية على حدة، حتى لا تُخفي صفحةٌ رئيسية سريعة عمليةَ دفع بطيئة.

معايير النجاح والإخفاق: اتفقوا على العتبات قبل التشغيل

الاختبار بلا عتبات متفق عليها يقيس، لكنه لا يُنتج نجاحاً ولا إخفاقاً. ينبغي الاتفاق على المعايير (pass/fail criteria) قبل أول تشغيل، أرقاماً مربوطة بعبء عمل ونافذة زمنية — اطلبوها ممن يُجري لكم اختبارات الحمل أياً كان. الجدول مثال توضيحي لعملية الدفع في متجر خيالي هو «متجر بستان» — قيمكم تأتي من حركتكم ورحلات مستخدميكم والتزاماتكم أنتم، لا من هذه الصفحة.

طريقة قياس زمن الاستجابة لا تقل أهمية عن الحد نفسه. لكل طلب تسجّل JMeter الزمن المنقضي (elapsed time) من قُبيل إرسال الطلب مباشرة إلى ما بعد وصول آخر جزء من الاستجابة، ولا يشمل ذلك عرض الصفحة في المتصفح ولا تنفيذ JavaScript. ثم تُلخَّص هذه الأزمنة في مئينات — تعرض لوحة تقارير JMeter بصيغة HTML المئينات 90 و95 و99 افتراضياً — إلى جانب الإنتاجية ومعدل الأخطاء. والمعايير المفيدة تحدد كذلك أي نافذة تُحتسب (عادةً الحالة المستقرة بعد مرحلة التصاعد)، وما الذي يُعدّ خطأً (استجابات 5xx، وانتهاء المهلة، واستجابات 200 تحمل رسالة خطأ يكشفها تحقق assertion)، ومتى يكون التشغيل غير صالح لا ناجحاً: إذا تشبّع مولّد الحمل نفسه، أو تغيّر البناء أثناء التشغيل، أو لم تكن البيئة هي المتفق عليها.

اختبار الأمان: ثغرات OWASP الشائعة في الويب وواجهات API

يفحص الجزء الأمني تطبيق الويب وواجهات API لديكم بحثاً عن نقاط الضعف الشائعة المصنّفة في قائمتين من OWASP: قائمة OWASP Top 10:2025 لتطبيقات الويب، وقائمة OWASP API Security Top 10 (إصدار 2023) لواجهات API. تُجرى الفحوص على البيئة المتفق عليها، وتحتاج فحوص التحكم في الوصول إلى حسابات اختبار لكل دور. والقائمتان مرجعان لا قوائم للتأشير: يصف دليل OWASP لاختبار أمان الويب (WSTG) كيف تُختبر كل نقطة ضعف، ويضع معيار التحقق من أمان التطبيقات (ASVS) متطلبات قابلة للاختبار — وكلاهما مفيد لفريقكم حين يكتب الإصلاح واختبار الانحدار الخاص به.

تُراجَع المصادقة (authentication) والتفويض (authorization) ومعالجة المدخلات ضمن هذه الخدمة. فيها تتقاطع القائمتان، وفيها تكون الماسحات الآلية أضعف ما تكون: لا يعرف الماسح أن العميل «أ» يجب ألا يقرأ طلب العميل «ب». وبعض الفئات — مثل إخفاقات سلسلة توريد البرمجيات (A03:2025) والتصميم غير الآمن (A06:2025) — لا يظهر منها من الخارج إلا جزء، ولا يكفي الاختبار وحده لاستبعادها.

حدود النطاق: ما لا تدّعيه هذه الخدمة

هذه الخدمة اختبار لنقاط الضعف الشائعة وقياس للأداء، مع الدليل الذي يسند كل نتيجة. ومن المفيد أن نكون دقيقين فيما ليست عليه، لتخططوا لأي شيء آخر تحتاجونه.

• ليست اختبار اختراق معتمداً (certified penetration test) ولا شهادة امتثال. التقرير دليل اختبار، ولا يشهد بالامتثال لنظام أو معيار. وإن طلب مدقق أو جهة تنظيمية أو عقد عميل أياً منهما فخططوا له بشكل منفصل؛ وتبقى النتائج ونتائج إعادة الاختبار من هذا العمل مدخلاً مفيداً.
• تطبيقات الجوال: واجهات API التي يستدعيها تطبيق الجوال ضمن النطاق، وتخضع للفحوص نفسها التي تخضع لها أي واجهة أخرى. أما حزمة التطبيق نفسها — البيانات المخزّنة على الجهاز، والتفاعل مع المنصة، ومقاومة الهندسة العكسية والعبث، وهي المجالات التي يعرّفها معيار OWASP MASVS — فليست جزءاً من هذه الخدمة كما توصف هنا.
• ليست تمريناً على هجمات حجب الخدمة. اختبار الضغط يجد حد السعة لنظامكم تحت حمل مضبوط من مولّد حمل، وليس محاكاة لهجوم موزّع.
• الخدمات الخارجية — بوابات الدفع ومزوّدو الرسائل النصية والتكاملات الوطنية — لا ينبغي أن تتلقى حمل اختبار دون إذن مالكها. وأياً كانت الجهة التي تختبر لكم، تأكدوا أن النطاق يحدد هل تُستبدل كل واحدة منها ببديل محاكٍ (stub) أم تُستدعى عبر بيئتها التجريبية (sandbox).
• الإنتاج: يُجرى الاختبار على بيئة اختبار أو بيئة مرحلية (staging). وتشغيل أي شيء على الإنتاج قراركم أنتم؛ وإن اتخذتموه فاتفقوا صراحةً ومسبقاً على الأهداف والمعدل والنافذة الزمنية وشروط الإيقاف (انظروا الأسئلة الشائعة).

كيف يسير العمل

يتبع العمل المراحل الست نفسها التي يتبعها كل مشروع لدى متقن سوفت، مكيّفةً للأداء والأمان. والمرحلة لا تُغلق إلا بمُخرجها.

المهندس الذي ينفّذ الاختبارات هو من يكتب النتائج ويتحقق من الإصلاحات، فلا يضيع شيء بين من وجد المشكلة ومن يؤكد زوالها.

ما الذي تستلمونه

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

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

ما الذي نحتاجه منكم

المنتج والتقنيات وموعد الإصدار تكفي لبدء الحديث. ولتنفيذ الاختبارات نحتاج إلى ما يلي:

• بيئة: بيئة اختبار أو بيئة مرحلية قريبة من الإنتاج حجماً وإعداداً قدر الإمكان؛ وحيث تختلف يُكتب الفرق في التقرير لتُقرأ الأرقام قراءة صحيحة. وبناء لا يتغير أثناء التشغيل.
• الحركة والمواعيد: ذروة المستخدمين أو الطلبات في الثانية المتوقعة، والرحلات الرئيسية، وموعد الإطلاق وأي مواسم ذروة — أو تحليلات يمكن استخراجها منها.
• بيانات اختبار بحجم كافٍ: حسابات اصطناعية (حسابان على الأقل لكل دور، لفحوص التحكم في الوصول)، وقاعدة بيانات بحجم واقعي — لا نسخاً من سجلات عملاء حقيقيين.
• وصول: عقد الواجهة (OpenAPI أو مجموعة Postman)، وحسابات الاختبار، وصلاحية قراءة للمراقبة أو السجلات أو مقاييس قاعدة البيانات أثناء التشغيل. والوصول إلى المستودع يفيد في تحليل الأسباب الجذرية لكنه ليس شرطاً.
• تفويض واضح: مع أي جهة اختبار، يستحسن أن يُكتب أي المضيفات ونقاط النهاية ضمن نطاق اختبارات الحمل والأمان ومتى يجوز تشغيلها، وأن يُتحقق هل يحتاج جدار حماية تطبيقات الويب (WAF) أو محدِّد المعدل إلى إضافة مولّدات الحمل إلى قائمة السماح.
• جهة اتصال: شخص تقني واحد يستطيع قراءة السجلات وإعادة تشغيل خدمة وإيقاف التشغيل إن حدث ما لم يكن متوقعاً.

متى تُجرى اختبارات الأداء والأمان

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

الأسئلة الشائعة

المراجع

• Apache JMeter User's ManualApache Software Foundationكيف تُبنى اختبارات الحمل وتُعامَل بالمعاملات وتُشغَّل في JMeter، وكيف تُقرأ مستمعاته وتقاريره.
• OWASP Top 10:2025OWASP Foundation · 2025أخطر عشرة مخاطر أمنية لتطبيقات الويب، مع كيفية اختبار كل منها والوقاية منه.
• OWASP API Security Top 10 (2023)OWASP Foundation · 2023أكثر عشر نقاط ضعف شيوعاً في واجهات API: خلل التفويض على مستوى الكائن، وخلل التوثيق، والاستهلاك غير المقيد للموارد، وغيرها.
• OWASP Web Security Testing Guide (WSTG)OWASP Foundationالمنهجية المرجعية لاختبار تطبيقات الويب وواجهات API بحثاً عن نقاط الضعف الأمنية، اختباراً تلو الآخر.
• OWASP Application Security Verification Standard (ASVS)OWASP Foundationقائمة تحقق بمتطلبات أمنية قابلة للتحقق لتطبيقات الويب، مصنّفة في ثلاثة مستويات ضمان.
• OWASP Mobile Application Security Verification Standard (MASVS)OWASP Foundationمتطلبات OWASP الأمنية لتطبيقات الجوال، مجمّعة في مجالات ضبط مثل التخزين والتشفير والمصادقة والشبكة والتفاعل مع المنصة.