البرامج التي تعمل ليست هي نفسها البرامج التي تعمل تحت الضغط. يمكن للميزة أن تجتاز كل اختبار وظيفي، وتُشحن نظيفة، ثم تنهار في المرة الأولى التي يصل فيها حجم مرور حقيقي. اختبار الأداء هو الانضباط الذي يسد هذه الفجوة: فهو يقيس كيف يتصرف النظام عندما يكون مشغولاً، وليس فقط ما إذا كان صحيحاً عندما يكون خاملاً.
يشرح هذا الدليل ماهية اختبار الأداء، وأنواعه الرئيسية، والمقاييس التي تحدد النتيجة، وكيف يتناسب مع عملية الاختبار الحديثة.
ما هو اختبار الأداء
يقوم اختبار الأداء بتقييم سرعة النظام واستقراره وقابليته للتوسع تحت عبء عمل محدد. إنه لا يسأل «هل تعمل هذه الميزة؟» بل يسأل «ما مدى سرعتها، وكم يمكنها أن تتحمل، وماذا يحدث عندما تبلغ طاقتها القصوى؟»
هذا التمييز مهم. يطرح الاختبار الوظيفي واختبار الأداء أسئلة مختلفة ويكشفان عن أخطاء مختلفة. يمكن لنقطة نهاية تسجيل الدخول أن تُرجع الرمز الصحيح في كل مرة ومع ذلك تستغرق أربع ثوانٍ للقيام بذلك تحت الضغط. تجتاز الاختبارات الوظيفية؛ يغادر المستخدمون. اختبار الأداء هو ما يكشف عن المشكلة الثانية.
ناتج اختبار الأداء ليس مجرد نجاح أو فشل. إنه ملف تعريف: عند هذا الحمل، يستجيب النظام بهذه السرعة، ويحافظ على هذا معدل الإنتاجية، ويفشل بهذه الطريقة بمجرد تجاوز هذه النقطة. هذا الملف الشخصي هو ما يسمح للفريق بتخطيط السعة، وتحديد مستويات خدمة واقعية، واكتشاف الانحدارات قبل الإصدار.
الأنواع الرئيسية لاختبار الأداء
اختبار الأداء هو عائلة من أنواع الاختبارات، كل منها يطبق حملاً بشكل مختلف للإجابة على سؤال مختلف.
اختبار الأساس (Baseline testing) يدير النظام تحت حمل طبيعي ومتوقع ويسجل النتيجة. هذا الأساس هو المرجع الذي تُقارن به جميع الاختبارات اللاحقة. بدونه، لا يمكنك معرفة ما إذا كان الرقم جيدًا أو سيئًا أو مختلفًا ببساطة.
اختبار التحميل (Load testing) يطبق حركة المرور القصوى المتوقعة ويؤكد أن النظام يصمد: تظل أوقات الاستجابة ضمن الميزانية، وتبقى الأخطاء قريبة من الصفر. إنه يتحقق من أن النظام ينجو من يوم عمل مزدحم عادي.
اختبار الإجهاد (Stress testing) يتجاوز السعة عمدًا، ويرفع الحمل حتى يتدهور النظام أو يفشل. الهدف هو العثور على نقطة الانهيار ومراقبة وضع الفشل. التدهور المتدرج، أي أن يصبح أبطأ ولكنه لا يزال يعمل، مقبول؛ أما فقدان البيانات أو الأخطاء المتتالية فليست كذلك.
اختبار الارتفاع المفاجئ (Spike testing) يطبق قفزة مفاجئة وحادة في الحمل ثم يخفضها مرة أخرى. إنه يحاكي المبيعات السريعة، والأحداث الإخبارية، والاندفاعات الأخرى. قد يفشل النظام المصمم لحركة مرور ثابتة في التعامل مع ارتفاع مفاجئ لأنه لا يستطيع التوسع بالسرعة الكافية.
اختبار السعة (Capacity testing) يجد أقصى حمل يمكن للنظام تحمله مع الاستمرار في تحقيق أهدافه. الإجابة هي رقم ملموس، يُستخدم مباشرة لتخطيط السعة وعتبات التوسع التلقائي.
اختبار التحمل (Soak testing)، ويسمى أيضًا اختبار الاستقرار أو المتانة، يحافظ على حمل معتدل لفترة طويلة لكشف الإخفاقات البطيئة: تسرب الذاكرة، استنزاف الموارد، التباطؤ التدريجي. هذه غير مرئية في التشغيلات القصيرة وتظهر فقط على مدى ساعات.
تُجري معظم الفرق اختبارات الأساس والتحميل والتحمل كمعيار، وتضيف اختبارات الإجهاد والارتفاع المفاجئ للأنظمة ذات حركة المرور العالية أو غير المتوقعة.
المقاييس التي تحدد النتيجة
اختبار الأداء لا يكون مفيدًا إلا بقدر المقاييس التي تقرأها منه.
وقت الاستجابة (Response time) هو المدة من الطلب إلى الاستجابة. اقرأه دائمًا كتوزيع. المتوسط مضلل؛ يمكن لمتوسط صحي أن يخفي شريحة مئوية 99 أسوأ بعشر مرات. الذيل البطيء هو ما يلاحظه المستخدمون الحقيقيون ويشكون منه.
معدل الإنتاجية (Throughput) هو حجم العمل المكتمل لكل وحدة زمنية، غالبًا الطلبات في الثانية. يتم حسابه كإجمالي الطلبات مقسومًا على مدة الاختبار ويمثل السعة الحقيقية للنظام.
التزامن (Concurrency) هو عدد المستخدمين أو الاتصالات المتزامنة. غالبًا ما يتم ذكر سعة النظام كمستوى التزامن الذي يتجاوز فيه وقت الاستجابة العتبة المقبولة.
معدل الخطأ (Error rate) هو النسبة المئوية للطلبات التي تفشل تحت الضغط. النظام الذي يظل سريعًا ولكنه يبدأ في فشل الطلبات عند التزامن العالي لم ينجح؛ السرعة بدون موثوقية ليست أداءً.
استخدام وحدة المعالجة المركزية والذاكرة (CPU and memory utilization) يفسر لماذا تتغير الأرقام الأخرى. إذا ارتفع زمن الاستجابة بينما تكون وحدة المعالجة المركزية مثبتة عند 100٪، فإن النظام مقيد بالمعالجة. إذا ارتفع زمن الاستجابة بينما تكون وحدة المعالجة المركزية خاملة، فإن عنق الزجاجة يقع في مكان آخر، عادةً في قاعدة بيانات، أو قفل، أو تبعية خارجية.
النتيجة الكاملة تُقرأ كجملة: عند هذا التزامن، بلغ معدل الإنتاجية ذروته هنا، وكان وقت الاستجابة عند الشريحة المئوية 95 هو كذا، وكان معدل الخطأ كذا، وكان الخادم مقيدًا بهذا المورد.
مكانة اختبار الأداء في العملية
اعتاد اختبار الأداء أن يكون بوابة واحدة قرب نهاية المشروع، يتم تشغيله مرة واحدة قبل الإطلاق بواسطة فريق متخصص. هذا النموذج يفشل للأنظمة التي يتم شحنها باستمرار، لأن الأداء يتراجع مع كل تغيير تقريبًا. استعلام جديد، تكامل مضاف، عمود غير مفهرس، كل منها يضيف بصمت تأخيرًا لا يكتشفه أي اختبار وظيفي.
النموذج الأفضل يعامل الأداء كالصحة: يتم التحقق منه باستمرار، بميزانية. حدد ميزانية لوقت الاستجابة ومعدل الخطأ للمسارات الحيوية. قم بتشغيل اختبار تحميل خفيف في CI/CD لكي يتسبب التراجع في فشل البناء عند طلب السحب. خصص اختبارات الإجهاد والتحمل الثقيلة للاختبارات المجدولة قبل الإصدار، حيث يكون وقت تشغيلها الأطول مقبولاً.
بالنسبة لمعظم الأنظمة، فإن المكان الأكثر قيمة لاختبار الأداء هو طبقة الـ API. تحمل واجهات برمجة التطبيقات (APIs) المنطق الأساسي، وهي سريعة وحتمية في الاستدعاء، وليس لديها واجهة مستخدم متقلبة للمواجهة. يوفر اختبار واجهات برمجة التطبيقات تحت الضغط أرقامًا موثوقة بتكلفة منخفضة؛ يغطي اختبار أداء الـ API هذا النهج المركز بالتفصيل. إن الحفاظ على اختبارات الأداء جنبًا إلى جنب مع اختبارات الـ API الوظيفية يعني التحقق من كل تغيير من حيث صحته وسرعته في آن واحد.
أخطاء شائعة في اختبار الأداء
من السهل إجراء اختبار الأداء بطريقة تنتج إجابات خاطئة ومؤكدة. تظهر بعض الأخطاء مرارًا وتكرارًا.
الاختبار مقابل بنية تحتية غير واقعية. اختبار تحميل على جهاز كمبيوتر محمول للمطور، أو مقابل بيئة مرحلية بجزء بسيط من موارد الإنتاج، ينتج أرقامًا لا معنى لها. اختبر على بنية تحتية تطابق الإنتاج قدر الإمكان.
تجاهل تأثيرات الإحماء. تكون العديد من الأنظمة بطيئة في الثواني القليلة الأولى من التشغيل بينما تمتلئ ذاكرات التخزين المؤقت وتفتح تجمعات الاتصال. قياس بدء التشغيل البارد والحالة الثابتة معًا ينتج متوسطًا مضللاً. تخلص من نافذة الإحماء أو أبلغ عنها بشكل منفصل.
قراءة المتوسطات بدلاً من الشرائح المئوية. هذا الخطأ يستحق التكرار لأنه شائع جدًا. متوسط وقت استجابة يبلغ 200 مللي ثانية يمكن أن يخفي شريحة مئوية 99 تبلغ ثلاث ثوانٍ. يصف المتوسط طلبًا لا يقوم به أحد في الواقع؛ وتصف الشرائح المئوية المستخدمين الحقيقيين.
استخدام بيانات غير واقعية. اختبار كل طلب بنفس معرف المستخدم أو نفس المنتج يعني أن قاعدة البيانات تخدم كل شيء من ذاكرة التخزين المؤقت. تنتشر حركة المرور الحقيقية عبر مجموعة البيانات، وتصيب الصفوف الباردة وفقدان ذاكرة التخزين المؤقت. قم بتغيير بيانات الاختبار لتطابق الواقع.
اختبار نقطة نهاية واحدة بمعزل عن غيرها. يتنقل المستخدمون الحقيقيون عبر سير العمل: تسجيل الدخول، التصفح، البحث، الدفع. يؤدي التركيز على نقطة نهاية واحدة إلى إغفال النزاع الذي يظهر عندما تتنافس عدة نقاط نهاية على نفس قاعدة البيانات ومجمع الاتصال. اختبر سيناريوهات واقعية متعددة الخطوات، وليس مجرد استدعاءات فردية.
التعامل مع الاختبار على أنه مرة واحدة وانتهى. يصبح اختبار الأداء الوحيد قبل الإطلاق قديمًا في اللحظة التي يتم فيها شحن الميزة التالية. يتراجع الأداء باستمرار، لذا يجب أن يعمل الاختبار باستمرار أيضًا.
تجنب هذه الأخطاء الستة هو معظم ما يفصل اختبار الأداء الذي يفيد في اتخاذ قرار عن اختبار ينتج علامة خضراء مطمئنة ولكنها بلا معنى.
تشغيل اختبارات الأداء باستخدام Apidog
Apidog يدمج اختبار التحميل في نفس مساحة العمل المستخدمة لتصميم الـ API والاختبار الوظيفي، لذلك لا تتطلب فحوصات الأداء أداة منفصلة أو نسخة منفصلة من تعريف الـ API.
تأخذ نقطة نهاية أو سيناريو اختبار متعدد الخطوات، وتتأكد من نجاحه وظيفيًا، ثم تشغله تحت عدد محدد من المستخدمين الافتراضيين لمدة محددة. يزيد Apidog الحمل تدريجيًا ويبلغ عن الشرائح المئوية لوقت الاستجابة، ومعدل الإنتاجية، ومعدل الخطأ مباشرة، حتى تتمكن من رؤية مستوى التزامن الدقيق الذي يتغير عنده الأداء. بالنسبة للحمل الذي يتجاوز جهازًا واحدًا، يتم تصدير السيناريو إلى JMeter مع الاحتفاظ بنفس التعريف.
نظرًا لأن نفس سيناريو الاختبار يخدم كلاً من التشغيلات الوظيفية وتشغيلات الأداء، فإنك تحتفظ بمصنوعة واحدة بدلاً من اثنتين. قم بتنزيل Apidog لإنشاء ملف تعريف لنقطة نهاية لديك بالفعل.
الأسئلة الشائعة
ما الفرق بين اختبار الأداء والاختبار الوظيفي؟ يتحقق الاختبار الوظيفي مما إذا كان البرنامج ينتج نتائج صحيحة. يتحقق اختبار الأداء من مدى سرعة وموثوقية قيام البرنامج بذلك تحت الضغط. كلاهما ضروري؛ لا يحل أحدهما محل الآخر.
ما نوع اختبار الأداء الذي يجب أن أقوم بتشغيله أولاً؟ الأساسي (Baseline)، ثم التحميل (Load). يوفر لك اختبار الأساس مرجعًا في الظروف العادية؛ ويؤكد اختبار التحميل أن النظام ينجو من ذروة حركة المرور المتوقعة. أضف اختبارات الإجهاد والارتفاع المفاجئ والتحمل بعد ذلك.
لماذا نستخدم الشرائح المئوية بدلاً من متوسط وقت الاستجابة؟ ينجذب المتوسط نحو المنتصف ويخفي الذيل البطيء. تكشف الشرائح المئوية 95 و 99 عن ما تعاني منه الطلبات الأقل حظًا، وهذا الذيل هو ما يشعر به المستخدمون.
هل يمكن أتمتة اختبار الأداء؟ نعم. يعمل اختبار التحميل الخفيف بشكل جيد في التكامل المستمر (CI) مع كل تغيير، بميزانية محددة تتسبب في فشل البناء عند التراجع. وعادة ما يتم جدولة اختبارات الإجهاد والتحمل الأكثر كثافة بدلاً من تشغيلها مع كل التزام.
متى يجب أن يبدأ اختبار الأداء في دورة التطوير؟ أبكر مما يعتقده معظم الفرق. لا يمكنك الحصول على أرقام زمن الاستجابة النهائية بدون بنية تحتية حقيقية، ولكن يمكنك وضع الميزانيات وكتابة سيناريوهات الاختبار أثناء التصميم. تشغيل اختبار تحميل أساسي بمجرد أن تصبح نقطة النهاية وظيفية يكتشف المشاكل بينما لا تزال رخيصة الإصلاح.
من المسؤول عن اختبار الأداء؟ في الفرق الحديثة، المسؤولية مشتركة. يقوم المطورون بإجراء فحوصات تحميل خفيفة على تغييراتهم الخاصة؛ يمتلك قسم ضمان الجودة (QA) سيناريوهات الاختبار والميزانيات الأوسع؛ ويوفر قسم العمليات أو مهندسو موثوقية الموقع (SRE) البنية التحتية الشبيهة بالإنتاج والمقاييس على جانب الخادم. التعامل معها كوظيفة متخصصة واحدة هو كيف تصل مشاكل الأداء إلى الإنتاج.
كم يجب أن يستغرق تشغيل اختبار الأداء؟ فترة كافية لتجاوز نافذة الإحماء والوصول إلى حالة مستقرة، وعادة ما تكون عدة دقائق لاختبار التحميل. تستمر اختبارات التحمل لساعات أو أيام حسب التصميم، حيث إن غرضها الأساسي هو كشف التدهور البطيء الذي تفوته التشغيلات القصيرة.