الأداء

جمع توقعات المستخدم في مرحلة تعريف المنتج، وقياس متطلبات الأعمال كمّيًا، واستخدام ذلك كأساس للبنية والتصميم اللاحقين للمنتج.

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

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

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

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

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

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

• تجنُّب المهام طويلة التشغيل. إذا كان الحل يجب أن يدعم مهام طويلة التشغيل (مثل تنفيذ عملية حساب علمية معقدة)، فيجب تصميم المهمة بحيث تدعم التوسع أو الانخفاض من خلال آلية مقاطعة ونقاط تحقق تمكِّن الحل من إيقاف المهمة وإعادة تشغيلها مع إضافة الموارد إلى الحل أو إزالتها منه.

• البيانات في الأطراف. يمكن للعناصر عديمة الحالة، من الناحية النظرية، أن تتوسع بلا حدود كما يمكن إعادة استخدامها بين العملاء. تدفع الحلول عالية الأداء الحالة، أي بيانات المستخدم والتطبيق، إلى تطبيقات العميل وقواعد البيانات الموجودة عند أطراف بنية الحل، ولا تحتفظ بأي حالة في طبقات البنية الوسيطة.

الموارد:
ذات الحالة مقابل عديمة الحالة

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

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

يُعَد نمط البنية Representational State Transfer (REST)، شائع الاستخدام في التطبيقات المعتمدة على الويب، مثالًا جيدًا على نوع التوازن الذي يميز الحل المصمم بشكل جيد؛ حيث يتم نقل الحالة الكاملة للمورد على شكل مستند JSON أو XML أو أي صيغة أخرى، بما يوازن بين كمية المعلومات المنقولة وبين التأخير العالي الناتج عن التفاعل القائم على الويب.

يساعد التخزين المؤقت على الحد من الطلب على الموارد والخدمات التي تُنتج البيانات. من لأفضل استخدام التخزين المؤقت للبيانات طويلة الأمد أو شبه الثابتة، و/أو البيانات التي يكون إنتاجها "مكلفًا". تطبِّق الحلول المصممة بشكل جيد آلية التخزين المؤقت في جميع طبقات البنية؛ مع وضع الذاكرات المؤقتة أقرب ما يمكن منطقيًا إلى المستهلك لتقليل الاتصالات بين المستهلك والذاكرة المؤقتة وتحسين زمن الاستجابة الكلي.

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

تُتيح الرسائل غير المتزامنة باستخدام قوائم الرسائل، أو نماذج الاستدعاء الرجعي، أو وسائل أخرى، للحلول أن تتوسع بكفاءة وأن تتدهور بشكل متدرج عند التحميل إذا نفدت الموارد. تستفيد الحلول المصممة بشكل جيد من الاتصالات غير المتزامنة، وخاصةً قوائم الرسائل، لتوفير تجربة مستخدم سريعة الاستجابة، ولتجنُّب "فقدان" طلبات المستخدمين في حال فشل أحد العناصر. يمكن استخدام الآلية نفسها أيضًا للربط الأنظمة التي تمتلك مستويات خدمة أو ساعات تشغيل مختلفة؛ على سبيل المثال، يُتيح توصيل تطبيق ويب يعمل على مدار الساعة (24x7) بنظام سجل يعمل من 9 صباحًا حتى 5 مساءً باستخدام قائمة رسائل لتلقي طلبات المستخدمين حتى عندما يكون نظام السجل غير متاح.

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

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

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

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

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

التركيز على تصوُّر المستخدم يعني التركيز بشكل أساسي على أزمنة الاستجابة المتصورة والاستجابة العامة لواجهة المستخدم. عادةً ما يكون تدهور السعة غير مرئي للمستخدمين حتى يتأثر أداء المنتج. وجدت دراسة عام 1968 أن هناك ثلاثة أوامر حجم متميزة في تفاعلات الإنسان مع الكمبيوتر:

• يُنظر إلى زمن استجابة قدره 100 مللي ثانية على أنه فوري. يمتلك الإنسان متوسط زمن استجابة يبلغ 250 مللي ثانية، لذا أي زمن أقل من ذلك يُعَد سريعًا جدًا أو فوريًا.
• تكون أزمنة الاستجابة حتى ثانية واحدة أو أقل عادةً سريعة بما يكفي ليشعر المستخدمون بأن النظام لا يبطئهم.
• أما أزمنة الاستجابة الأكثر من 10 ثوانٍ فتؤدي إلى فقدان المستخدمين للانتباه تمامًا.

استنادًا إلى ذلك، تم اعتبار أن زمن استجابة قدره ثانيتان هو الأمثل، وبالتالي فإن زمن الاستجابة ثانيتان أو أكثر قليلًا يمثل هدفًا جيدًا للحلول الهجينة السحابية حيثما أمكن. بالطبع، تعتمد توقعات المستخدمين تعتمد على طبيعة ما يقومون به؛ على سبيل المثال، لا يتوقع أحد أن تستغرق حركة الضغط على زر ثانيتين، لكن زمن استجابة من 2 إلى 3 ثوانٍ يُعَد هدفًا عامًا جيدًا لتطبيقات واجهة المستخدم.

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

غالبًا ما يكون لدى المستخدمين توقعات مختلفة لما يُعَد أداءً جيدًا. على سبيل المثال، يكون لدى المستخدم المتقدم الذي يستخدم التطبيق عدة مرات يوميًا توقعات أداء مختلفة تمامًا عن شخص يستخدم التطبيق نفسه ربما مرة واحدة في الشهر. غالبًا ما يواجه المستخدمون صعوبةً في تحديد ما يعنيه الأداء الجيد بالنسبة لهم، وغالبًا ما يتوقفون عند متطلبات مثل "سريع بما يكفي" (وهو هدف يصعب تحديده بدقة). كما أن التصوُّر الفردي لأداء المنتج الموجَّه للمستخدم يختلف من شخص لآخر. على سبيل المثال، بالنسبة إلى بعض المستخدمين، مدة تسجيل دخول تبلغ 10 ثوانٍ مقبولة (خاصةً إذا كان هذا الحدث يحدث مرة واحدة)، بينما قد تكون بالنسبة للآخرين بطيئة جدًا (خاصةً إذا كان تسجيل الدخول جزءًا متكررًا من سير العمل).

للمساعدة على تحديد توقعات المستخدمين وإدارتها، يُوصى بما يلي:

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

مراقبة حدود الأداء والتواصل معها للعملاء

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

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

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

إحدى الطرق الشائعة لاختبار الأداء هي التأكد من أن الحل يحقق أهداف زمن الاستجابة عند الحد الأقصى المتوقع للحمل؛ مع الافتراض أن الحل إذا كان يعمل جيدًا عند الحد الأقصى للحمل، فسيكون جيدًا عند الأحمال الأقل منه. والتحدي في هذا النهج هو أنه يوفر نقطة بيانات واحدة فقط لكل حِمل أقصى تم اختباره، كأنه تمرين نجاح/فشل.

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

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

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

يهدف نهج *اختبار الأداء الاستكشافي" الأكثر تقدمًا إلى إنشاء *لقطة أداء (Performance Snapshot)* للحل قيد الاختبار. تتضمن اللقطة مجموعة شاملة من مقاييس الأداء التي يتم جمعها عبر أوسع نطاق مدعوم من الأحمال - بدءًا من قياسات المستخدم الواحد ووصولًا إلى الأحمال بعد نقطة الانهيار (عند الإمكان، باستثناء الحالات التي يتعطل فيها النظام). يشمل ذلك تجميع أزمنة استجابة المعاملات، ومعدلات معالجة المعاملات والبيانات، وبيانات استهلاك الموارد التي يتم جمعها مع زيادة ظروف الحِمل تدريجيًا. ويُقصد بالمعاملة وحدة عمل محددة ينفِّذها النظام - بدءًا من المعاملات الكبيرة مثل تسجيل الدخول أو تحديث الحساب، ووصولًا إلى المعاملات الفرعية الفردية (مثل استدعاء المصادقة ضمن معاملة تسجيل دخول)، أو حتى طلبات http البسيطة.

تتضمن المجموعة الشاملة من بيانات الأداء، أي Performance Snapshot، مقاييس الأداء المذكورة عبر نطاقات الأحمال المختلفة: نطاق الحِمل المنخفض "الخطي" (حيث لا تشعر الخيوط المعالجة بشكل فردي بوجود بعضها ولا تزداد أزمنة الاستجابة مع زيادة الحِمل)، والنطاق "غير الخطي" حيث ترتفع أزمنة الاستجابة مع زيادة الحِمل، ونقاط التشبع حيث تتوقف معدلات المعالجة عن الزيادة مع ارتفاع الحِمل وتصل إلى مستويات التشبع، ونطاق ما بعد نقطة الانهيار حيث يتراجع الأداء بعد وصول معدلات المعالجة إلى الحد الأقصى وتتجاوز أزمنة الاستجابة مستويات SLA.

لا تتطلب تغطية النطاق الكامل للأحمال عادةً جهدًا أكبر من فِرق الاختبار مقارنةً بالاختبار عند مستويات "الذروة" و"الضغط" واختبارات الاستمرارية، إذ يتم استخدام نصوص الاختبار نفسها (ويكون الجهد الرئيسي عادةً في إنشاء هذه النصوص). لكن مزايا إنشاء لقطة أداء (Performance Snapshot) تشمل ما يلي:

• لا حاجة لقضاء الوقت والجهد في محاولة تخمين إعداد الاختبار المناسب الذي يُنتج معدل المعاملات "الصحيح" (مثل "الذروة" أو "الضغط")؛ يكفي زيادة الحِمل تدريجيًا لتغطية جميع مستويات الأحمال ومعدلات المعالجة المدعومة.

• يمكن عندها تحديد مستويات الحِمل التي تبدأ عندها أزمنة الاستجابة في الارتفاع، والمستويات التي تتجاوز فيها حدود SLA، وكذلك النقاط التي تصل عندها معدلات المعالجة إلى أقصى مستوياتها.

• يسمح ذلك بقياس سعة النظام بشكل مباشر، مثل تحديد مستوى الحِمل الذي تتحقق عنده حالة نقطة الانهيار (عندما يتجاوز زمن الاستجابة حدود SLA، أو تصل معدلات المعالجة إلى الحد الأقصى، أو يدخل استهلاك موارد النظام إلى "المنطقة الحمراء" المحددة، مثل وصول استخدام CPU إلى ‎90%‎، أو تعطل النظام - أيهما يحدث أولًا). وهذا يعني عدم الحاجة إلى الأساليب التقليدية المعتمدة على التخمين في تحليل السعة وتخطيطها.

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

• إن تغطية نطاق الأحمال بأكمله بدلًا من عدد محدود من المستويات المحددة مسبقًا يضمن الحصول على رؤية كاملة لأداء النظام وعدم تفويت أي مشكلات أداء محتملة نتيجة عدم اختبار المنتج في الظروف القصوى.

• كما أن ضمان أن تشمل الاختبارات الوصول إلى نقاط انهيار الأداء يُتيح معرفة أماكن العوائق، وأي رابط أو عنصر أو طبقة ستفشل أولًا مع زيادة الأحمال. يسمح ذلك بتقديم ملاحظات مفيدة ومبنية على الأدلة إلى فِرق البنية والتصميم لتحسين متانة المنتج وأدائه.

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

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

الهدف هو الاستفادة القصوى من تنوع بيانات الأداء التي يتم جمعها أثناء الاختبارات:

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