ما المقصود باختبار الأداء؟
يهدف اختبار الأداء إلى تقييم أداء النظام أو التطبيق تحت أحمال متفاوتة في الحجم.
وتشمل المعايير الرئيسية ما يلي: السرعة (مدى سرعة أداء النظام)، والاستقرار (قدرته على العمل دون تعطل)، وقابلية التوسع (مدى سلاسة تعامل النظام مع الأحمال المتزايدة)، والاستجابة (مدى سرعة استجابة النظام للموجِّهات).
يمثل مفهوم أداء البرمجيات أساس استخدام الحاسوب بالكامل، ويمكن أن يؤدي ضعف الأداء إلى تقويض كل الجهود التي تبذلها المؤسسة لتقديم تجربة مستخدم عالية الجودة. إذا لم يُولِّ المطورون اختبار الأداء العناية الكافية أو لم يجروا اختبارات أداء بشكل منتظم، فقد تظهر اختناقات في الأداء. وهذا قد يؤدي إلى اختناق قدرة النظام على التعامل حتى مع الأحمال المتوقعة خلال الفترات العادية. وتتفاقم المشكلة عندما تتزايد الأحمال في أوقات ذروة غير متوقعة، مما يفرض طلبًا إضافيًا على الموارد.
قد تضع هذه التحديات عمليات الشركة العامة بأكملها في مهب الخطر. فبناء سمعة قوية وموثوقة يتطلب وقتًا طويلًا، لكن يمكن أن تتعرض تلك السمعة لضرر دائم وسريع بمجرد أن يبدأ المستخدمون في التشكيك في موثوقية النظام أو التطبيق. أصبح المستخدمون النهائيون أقل صبرًا وأكثر حساسية تجاه أداء الأنظمة. وبالتالي، عندما يدور الحديث حول مشكلات الأداء، فإن الأمر يتجاوز مجرد الجوانب التقنية — فهناك الكثير على المحك.
النشرة الإخبارية الخاصة بالمجال
أحدث الأخبار التقنية، مدعومة برؤى خبراء
ابقَ على اطلاع دومًا بأهم—اتجاهات المجال وأكثرها إثارة للفضول—بشأن الذكاء الاصطناعي والأتمتة والبيانات وغيرها الكثير مع نشرة Think الإخبارية. راجع بيان الخصوصية لشركة IBM.
سيتم تسليم اشتراكك باللغة الإنجليزية. ستجد رابط إلغاء الاشتراك في كل رسالة إخبارية. يمكنك إدارة اشتراكاتك أو إلغاء اشتراكك هنا. راجع بيان خصوصية IBM لمزيد من المعلومات.
لنبدأ بتحديد المنهجية المُستخدمة في معظم سيناريوهات اختبار الأداء. تُحدَّد عملية اختبار الأداء النموذجية من خلال ست خطوات متعددة الأجزاء.
1. تحديد معايير ومتطلبات الأداء
تتضمن الخطوة الأولى في عملية اختبار الأداء تحديد المعايير المفيدة، مثل تحديد أهداف أداء التطبيق.
بعد ذلك، يتم تحديد ما يُشكّل معايير الأداء المقبول (مثل أوقات الاستجابة، والإنتاجية، واستهلاك الموارد، ومعدلات الخطأ).
وتعد هذه المرحلة أيضًا هي المرحلة التي يحدد فيها الموظفون مؤشرات الأداء الرئيسية (KPIs) لدعم متطلبات الأداء وأولويات العمل.
2. اختبارات التصميم والتخطيط
لا ينبغي استخدام جميع أنواع الاختبارات في كل الحالات. ينبغي على المطورين أو المختبرين تحديد ما يُراد تحليله من خلال الاختبار.
ويبدؤون بتحديد أكثر سيناريوهات الاستخدام شيوعًا وتصميم حالات اختبار تُحاكي تفاعلات المستخدمين في الواقع. الخطوة التالية تتمثل في تحديد بيانات الاختبار وأحمال التشغيل التي سيتم استخدامها أثناء عملية الاختبار.
بعد تثبيت هذه المتغيرات، يختار المختبرون أدوات اختبار الأداء، ونصوص الاختبار، وتقنيات الاختبار. تشمل هذه المرحلة أيضًا إعداد آليات التوجيه، وهي عملية تُستخدم فيها بوابات جودة قائمة على التعليمات البرمجية للسماح بالوصول إلى مراحل الإنتاج اللاحقة أو رفضه.
يقيس اختبار الأداء أيضًا النطاق الترددي للتحقق من قدرة معدلات نقل البيانات على التعامل مع حركة البيانات الناتجة عن أحمال التشغيل.
3. إنشاء بيئات الاختبار
ثمة خطوة أخيرة ينبغي اتخاذها قبل بدء عملية اختبار الأداء رسميًا. يُنشئ المختبرون بيئة اختبار تحاكي بدقة بيئة الإنتاج الفعلية للنظام ثم يتحقّقون من أن تطبيقات البرمجيات قيد الاختبار قد نُشرت ضمن هذه البيئة.
تتضمّن التحضيرات الأخيرة دمج أدوات مراقبة لجمع المقاييس الناتجة عن النظام أثناء الاختبار.
4. إجراء الاختبارات
بمجرد تحديد معايير الاختبار، يبدأ تنفيذ اختبار الأداء. يُجري المختبرون أو أدوات أتمتة الاختبار سيناريوهات الاختبار المحددة باستخدام أدوات اختبار الأداء.
يراقب المختبرون أداء النظام في الوقت الفعلي لمتابعة الإنتاجية، وأوقات الاستجابة، واستهلاك الموارد. خلال سيناريوهات الاختبار، يراقب المختبرون النظام لرصد اختناقات الأداء أو أية حالات غير طبيعية تظهر في مقاييس الاختبار.
5. نتائج الدراسة
بعد ذلك، يُقيّم المختبرون بيانات الأداء التي تم جمعها خلال الاختبار. يُمعنون النظر في البيانات المُجمّعة ويبحثون عن جوانب الأداء التي تتطلّب تحسينًا.
ثم يُقارن المختبرون نتائج الاختبار هذه بمعايير الأداء التي تم تحديدها كجزء من الخطوة الأولى في عملية الاختبار. ومن خلال هذه المقارنة، يمكنهم تحديد مواضع الانحراف عن الأداء المتوقع والمواقع التي ربما ظهرت فيها اختناقات.
6. التحسين والاختبار والتكرار
بعد تحديد مشكلات الأداء من خلال تحليل بيانات الاختبار، يعمل المطوّرون على تحديث التعليمات البرمجية ضمن النظام. يستخدمون تحسينات في التعليمات البرمجية، أو ترقية الموارد، أو تغييرات في الإعدادات لمعالجة مشكلات الأداء التي تم تحديدها.
بعد تنفيذ هذه التعديلات، يُعيد المطوّرون تسلسل اختبار البرمجيات للتحقّق من أنهم طبّقوا التعديلات بنجاح. يُعيد المطورون تكرار هذه الإجراءات إلى أن تتماشى نتائج الأداء مع معايير الأداء المحددة.
نظرًا لأن اختبار الأداء يتعمّق في تحليل مخرجات النظام أو التطبيق، فمن المنطقي أن تكون فرق تطوير البرمجيات هي الفئة الأكثر استخدامًا لأساليب اختبار الأداء. تتضمّن هذه الفئة الأولى من المستخدمين متخصصين يشاركون بنشاط في عملية التطوير: المطورون ومهندسو ضمان الجودة (QA) وفرق عمليات التطوير. كل فئة منهم تستفيد من اختبار الأداء بطريقة مختلفة:
- يستخدم المطوّرون اختبار الأداء لاكتشاف مشكلات الأداء في وقت مبكر من دورة حياة تطوير البرمجيات (SDLC)، حتى يتمكنوا من ترتيب أولويات التعديلات البرمجية وتنفيذها بكفاءة.
- تعتمد فرق ضمان الجودة (QA) على اختبار الأداء لدعم جهودها وتحديد ما إذا كانت سرعة التطبيق، واستقراره الوظيفي، وخصائص التوسّع تعمل على النحو الكافي ضمن مستويات مختلفة من أحمال التشغيل.
- تستطيع فرق عمليات التطوير التي تعمل ضمن بيئة التكامل المستمر والتسليم المستمر (CI/CD) دمج اختبار الأداء تلقائيًا للتحقق من أن كل تعديل يُجريه المطوّر لا يؤثر سلبًا على سلوك النظام.
الفئة التالية من المستخدمين ليست من المطوّرين، لكنها لا تزال تعمل بشكل مباشر في إدارة أداء النظام كجزء أساسي من مهامها:
- يستخدم مديرو المشروعات اختبارات الأداء لتقييم المخاطر وقياس تأثير التغييرات التي قد تطرأ على النظام.
- يحتاج رؤساء أقسام التكنولوجيا (CTOs) أو من يشغل مناصب مشابهة إلى اختبار الأداء لمساعدتهم في تحديد كيفية تحويل الطلبات المتغيرة إلى نمو طويل الأجل.
- يهتم أصحاب الشركات بحماية مصادر الإيرادات. يضمن اختبار الأداء أن أوقات التحميل سريعة بما فيه الكفاية، وأن ضعف استجابة خدمات العملاء لا يعيق عملية توليد الإيرادات.
لكن اختبار الأداء لا يقتصر على الإدارة فقط. إذ تعتمد العديد من المؤسسات والشركات، بمختلف أحجامها، على اختبارات الأداء لأغراض متنوعة:
- الشركات الكبيرة التي تواجه بانتظام فترات من حجم حركة مرور مرتفع تعتمد على اختبارات الأداء لتأكيد أن تطبيقاتها يمكنها التعامل مع أحمال تشغيل ثقيلة. يُعتبر هذا النهج ذا أهمية خاصة للشركات التي تعتمد بشكل كبير على المنصات عبر الإنترنت مع قواعد مستخدمين كبيرة.
- تحتاج الشركات الصغيرة (والشركات الناشئة) إلى اختبارات الأداء بوصفها جزءًا من جهود تخطيط النمو. وتستخدم هذه المؤسسات اختبارات الأداء لتنبيهها إلى الاختناقات المستقبلية التي قد تؤثر سلبًا في قدرتها على النمو بنجاح.
- والشركات (بمختلف أحجامها) التي تستعد لإطلاق تطبيقات جديدة تُحسن صنعًا بإجراء اختبارات الأداء بوصفها وسيلة للتنبؤ بالمشكلات في سيناريوهات التشغيل الواقعية. وينطبق الأمر نفسه على الشركات التي تُجري تغييرات مهمة في أنظمة تكنولوجيا المعلومات لديها.
- وتتحمّل المؤسسات المالية مسؤوليات جسيمة وتخضع لأنظمة تنظيمية صارمة في هذا القطاع. وتلجأ هذه الشركات بشكل روتيني إلى اختبارات الأداء لمساعدتها على الحفاظ على المعايير الأساسية، لا سيما خلال فترات ارتفاع حجم المعاملات.
ويُجري المطوّرون أنواعًا مختلفة من اختبارات الأداء لاستخلاص أنواع محدَّدة من بيانات النتائج ودعم إستراتيجية اختبار معيّنة. فيما يلي أبرز أنواع هذه الاختبارات.
يُبيّن اختبار التحميل كيفية أداء النظام عند العمل ضمن الأحمال المتوقَّعة. وهدفه إظهار سلوك النظام عند التعرّض لأحمال تشغيل روتينية الحجم، وفي ظل ظروف عمل طبيعية مع أعداد متوسطة من المستخدمين المتزامنين.
مثال: في موقع للتجارة الإلكترونية، يُحاكي المختبِر دور مستخدم الموقع ويجتاز خطوات التسوّق للمنتجات، ووضعها في السلة، وسداد ثمن المشتريات.
يُظهر اختبار التحميل ما إذا كان النظام يستطيع تحمّل ظروف الأحمال الاعتيادية. يَضع اختبار قابلية التوسّع ذلك النظام تحت ضغط بزيادة حجم البيانات أو أحمال المستخدمين التي يعالجها.ويُبيّن ما إذا كان النظام قادرًا على مواكبة الوتيرة المتصاعدة والاستمرار في الأداء المطلوب.
مثال: في التوسّع الرأسي، قد يعمد المطوّر إلى تعزيز وحدة المعالجة المركزية (CPU) والذاكرة في خادم قاعدة البيانات ليتمكن من استيعاب حجم أكبر من استعلامات البيانات.
يشبه اختبار الإجهاد اختبار الغطس الذي يجريه طاقم غواصة. حيث يُدفَع النظام إلى حدوده التشغيلية المعروفة—ثم إلى أبعد من ذلك—لتحديد مقدار ما يستطيع تحمّله بدقة قبل بلوغ نقطة الانهيار.
مثال: يُعدّ اختبار التبديل التلقائي شكلًا متطرفًا من اختبارات الإجهاد يبدأ بمحاكاة تعطل المكوّنات. وهدفه معرفة المدة التي يستغرقها النظام للتعافي واستئناف التشغيل.
هنا نختبر نوعًا مختلفًا من الضغط—حين يشهد عدد الزيارات للمستخدمين أو حجم نقل البيانات ارتفاعًا حادًا ومفاجئًا في النشاط. ويجب على النظام امتصاص تلك التغيّرات مع مواصلة عملياته المعتادة.
مثال: على الشركات التي تُشغِّل مواقع إلكترونية أن تستعدّ ليس للانقطاع فحسب، بل أيضًا لطفرة المستخدمين الذين يحاولون الوصول إلى الموقع في الوقت نفسه فور عودته إلى العمل. كما يجب عليها تقييم ما إذا كان النظام قادرًا على التعامل مع تلك الزيادة المفاجئة في الطلب.يمكن لاختبار الارتفاع المفاجئ في الحمل تقدير مدى سلاسة سير الأمور على الأرجح.
أحيانًا حين نتحدّث عن الأداء، يكون المقصود حركة المستخدمين. أما اختبار الحجم فيركّز، على النقيض، على كيفية إدارة النظام لكميات كبيرة من البيانات. هل يستطيع النظام معالجة البيانات بالكامل وتوفير التخزين دون تدهور في البيانات؟
مثال: تحتفظ عيادة طبية بأحجام هائلة من معلومات المرضى، ويُلزمها القانون بالقدرة على الوصول إلى تلك السجلات الطبية والبيانات ذات الصلة. يمكن أن يؤدي هذا التدفق المستمر للبيانات إلى إجهاد النظام. يُمكّن اختبارُ الحجم المستخدمين من معرفة ما إذا كان نظامهم بمستوى التحدّي المتمثّل في الاستيعاب المستمر لكمّ أكبر من البيانات.
يمكن اعتباره اختبار أداء على المدى الطويل. المشكلات الرئيسية التي يستهدفها اختبار التحمّل (ويُسمّى أيضًا اختبار النقع) هي تدهور البيانات ومشكلات تسرّب الذاكرة التي تظهر غالبًا على مدى فترات مطوّلة.
مثال: تعمل منصّات التواصل الاجتماعي على مدار الساعة، وقد يفضي الاستخدام المتواصل إلى مشاكل في استقرار المنصّة وتخزين البيانات وحسابات المستخدمين. يقدّم اختبار التحمّل صورة عن التشغيل الحالي ومؤشرات إلى الأداء المستقبلي.
يمكن للمطوّرين والمختبِرين الاختيار من بين أدوات عديدة مخصّصة لاختبارات الأداء. فيما يلي بعض أبرز هذه الأدوات:
- JMeter: يُعدّ تطبيق JMeter من Apache برنامج مفتوح المصدر مفضَّلة لاختبار أداء أحمال التشغيل. تستطيع الأداة استخدام مجموعات مؤشرات الترابط لإنشاء مستخدمين افتراضيين يحاكون سيناريوهات حركة المرور التي تشمل مستخدمين حقيقيين، بما في ذلك الحالات التي يحدث فيها فرطٌ في عدد المستخدمين. وتُصنَّف هذه الحالات القصوى ضمن دراسة «النظام قيد الاختبار» (SUT). يوفّر JMeter مقاييس اختبار قيّمة، مثل أزمنة الاستجابة التي تقيس سرعة استجابة النظام قيد الاختبار لطلبات المستخدمين. كما يتتبّع معدّلات الأخطاء (نسبة الطلبات الفاشلة) ومعدل الإنتاجية (throughput)، الذي يبيّن عدد الطلبات التي يمكن للنظام قيد الاختبار التعامل معها ضمن إطارٍ زمنيٍّ محدّد.
- LoadRunner: على غرار JMeter، ينشئ LoadRunner أعدادًا ضخمة من المستخدمين الافتراضيين. ثم يولّد نشاطًا اصطناعيًا لهؤلاء الملايين من المستخدمين الافتراضيين—مثل تبادل الرسائل بين المكوّنات أو تفاعلات المستخدم مع واجهة المستخدم. ثم تُحفَظ هذه التفاعلات في نصوص الاختبار التي يُولِّدها LoadRunner. وتشير تقارير إلى أنه، حتى عام 2025، كانت أكثر من 2600 شركة تستخدم Micro Focus LoadRunner أداةً لاختبار الأداء وأنشطة ضمان الجودة.
- RoadRunner: كانت «PHP» في الأصل اختصارًا لعبارة "personal home page" (الصفحة الشخصية الرئيسية)، ثم أصبح معناها "hypertext preprocessor" (المعالجة المُسبقة للنص التشعُّبي). وهي اليوم لغة برمجة تعمل على جهة الخادم (أي تُنفَّذ الشيفرة على الخوادم لا على متصفحات الويب). وهي الآن تشير إلى لغة البرمجة نصية تعمل من جهة الخادم (مما يعني أن المطورين ينفذون التعليمات البرمجية على الخوادم لا على متصفّحات الويب لدى العملاء). RoadRunner مفتوح المصدر (ولا ينبغي الخلط بينه وبين LoadRunner المتشابه في اللفظ) يعمل كخادم تطبيقاتٍ لـ PHP ومديرٍ للعمليات. وهو يُبسّط أداء التطبيقات بإلغاء الحاجة إلى وقت بدء التشغيل والحدّ من زمن الانتقال. كما يتيح RoadRunner إطارًا للتحليل الديناميكي لبرامج Java التي تعمل تزامنيًا. ويوفّر RoadRunner واجهة برمجة تطبيقات (API) لتقييم تدفّقات الأحداث.
كما هو الحال في معظم ما يتعلّق بالحوسبة، يدفع الذكاء الاصطناعي (AI) اليوم باختبار البرمجيات إلى مستويات جديدة من الكفاءة. فهو يجعل عملية اختبارات الأداء أسرع وأكثر دقّة وأسهل في الأتمتة.
وبالتحديد، يستطيع الذكاء الاصطناعي اعتماد دورات اختبار أقصر، مما يقلل زمن إجراء الاختبارات. وبفضل دقّته العالية، يمكنه أيضًا رصد تغيّرات دقيقة في الأداء قد تغيب عن المختبِرين البشريين. إضافة غلى ذلك، ومن خلال التحليلات التنبؤية، يستطيع الذكاء الاصطناعي تقييم اتجاهات التشغيل والبيانات التاريخية والتنبؤ بمكان وزمان حدوث الاختناقات التالية. ويمكنه كذلك الاستفادة من ذلك السلوك التنبؤي للنظام وضبط معلمات الاختبار بناءً عليه.
لكنّ أبرز ما قدّمه الذكاء الاصطناعي لاختبارات الأداء (حتى الآن) هو تمكين الأتمتة ودعم الجهود على نطاق واسع. تتّسم هذه الأتمتة بقدرتها الكاملة على تشغيل عملية اختبارات الأداء—بأكملها.
لا يقتصر دور الذكاء الاصطناعي على أتمتة أسلوب تنفيذ الاختبارات، بل يمكنه أيضًا كتابة نصوص الاختبار المعدّة للتنفيذ. بالإضافة إلى ذلك، يستطيع تفسير نتائج الاختبار على الواجهة الخلفية وتقديم إرشادات لمعالجة حالات المشكلات.
من أبرز الآثار الواعدة والمثيرة للاهتمام للذكاء الاصطناعي في اختبارات الأداء ازديادُ استخدامِ التعاون بين الإنسان والذكاء الاصطناعي. يُقِرّ هذا الترتيب بأن الحدس والمعرفة البشريين لا يزال لهما دورٌ حاسم. وفي الواقع، تظلّ في بعض الحالات أولوية الاتّباع لِلدوافع البشرية هي المبدأ المُوجِّه.
ويقتنع بعض الخبراء بأن اختبارات الأداء في المستقبل ستعتمد على هذا النهج الهجين، إذ يجمع بين العقلية الحاسوبية والقوة المعالِجة من جهة، والحسّ البشري بالسياق والفروق الدقيقة من جهة أخرى.
الموارد
أتمتة تسليم البرامج لأي تطبيق محليًا أو على السحابة أو الكمبيوتر المركزي.
استخدم أدوات وبرمجيات عمليات التطوير لإنشاء تطبيقات السحابة الأصلية ونشرها وإدارتها عبر أجهزة وبيئات متعددة.
أطلق العنان للقدرات الجديدة وحفِّز مرونة الأعمال من خلال خدمات الاستشارات السحابية من IBM. اكتشف كيفية المشاركة في إنشاء الحلول وتسريع التحول الرقمي وتحسين الأداء من خلال إستراتيجيات السحابة الهجينة والشراكات مع الخبراء.