اختبار الأداء القائم على الهدف



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

يعمل الاختبار المستند إلى الهدف باستخدام الخطوات التالية:

  1. تحديد أهداف الأداء: تتضمن الخطوة الأولى تحديد أهداف الأداء المهمة لنظام البرامج الذي يتم اختباره. يمكن أن تتضمن هذه الأهداف عتبات وقت الاستجابة ومتطلبات الإنتاجية وأهداف استخدام الموارد ومعايير قابلية التوسع.
  2. تصميم سيناريوهات الاختبار: تم تصميم سيناريوهات الاختبار استنادا إلى أهداف الأداء المحددة الخاصة بك. تحاكي هذه السيناريوهات سلوكيات المستخدم المختلفة والأحمال وتكوينات النظام لتقييم كيفية أداء البرنامج في ظل ظروف مختلفة. على سبيل المثال، قد تتضمن السيناريوهات فترات ذروة الاستخدام أو أحمال المعاملات الثقيلة أو الارتفاعات المفاجئة في نشاط المستخدم.
  3. تنفيذ الاختبارات: يتم تنفيذ سيناريوهات الاختبار مقابل نظام البرنامج بموجب متطلبات الاختبار. خلال هذه المرحلة ، يتم قياس ومراقبة مقاييس الأداء مثل أوقات الاستجابة والإنتاجية واستخدام الموارد وقابلية تطوير النظام.
  4. تحليل النتائج والتحسين: يتم تحليل بيانات الأداء التي تم جمعها لتقييم ما إذا كان النظام يلبي الأهداف المحددة مسبقا. يساعد هذا التحليل في تحديد اختناقات الأداء وقيود قابلية التوسع والمناطق التي قد يفشل فيها النظام في تلبية متطلبات الأداء. بناء على تحليل نتائج الاختبار ، قم بإجراء أي تحسينات وتحسينات ضرورية لنظام البرنامج الخاص بك.
  5. تكرار العملية: اختبار الأداء القائم على الهدف هو عملية تكرارية. بعد إجراء التحسينات ، يتم تكرار دورة الاختبار للتحقق مما إذا كانت أهداف الأداء قد تحققت ولتحديد أي مشكلات أداء جديدة قد تكون نشأت.

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

 

أهمية تحديد أهداف الأداء

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

 

الأسباب الرئيسية لاختبار الأداء القائم على الهدف

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

 

حالة الاستخدام المستندة إلى الهدف: مشكلة

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

 

حالة الاستخدام القائمة على الهدف: الحل

  1. قم بدمج ThinkTimes في البرامج النصية الخاصة بك لتقديم فترات توقف مؤقت بين إجراءات المستخدم.
  2. تحديد الأساس وقياس وقت تشغيل البرامج النصية لمستخدم واحد لحساب وقت الجلسة.
  3. قم بتكوين معلمات حمل العمل، بما في ذلك الحد الأقصى للمستخدمين ومعدل المعاملات المستند إلى الهدف ووقت المعاملة المستند إلى الهدف.
  4. قم بتنفيذ اختبار الأداء المستند إلى الهدف لمحاكاة الحمل المتوقع على التطبيق.
  5. راجع تقرير الاختبار للتحقق مما إذا كان التطبيق قد تمكن من معالجة الحمل ضمن حدود وقت الاستجابة المحددة مسبقا.
  6. كرر التشغيل التجريبي في الإصدارات الأربعة اللاحقة لتقييم ما إذا كان التطبيق يحافظ على حدود الإنتاجية ووقت الاستجابة بمرور الوقت.

 

توصيات ونصائح لتكوين أداة EveryStep الخاصة ب LoadView

ثينك تايم (مطلوب):

  • قم بإنشاء كلمات رئيسية جديدة في مسجل الويب EveryStep (ThinkTimes) أو أعد استخدام الكلمات الرئيسية الموجودة.
  • تأكد من أن القيم المسموح بها هي نقاط عائمة 0.0 – 999.99.
  • السماح للمستخدمين بإضافة ThinkTimes يدويا إلى البرامج النصية.
  • تذكر أن ThinkTimes يمثل أوقات الانتظار ويتم إضافته تلقائيا بواسطة EveryStep Web Recorder أثناء تسجيل إجراءات المستخدم.
  • يمكن أن توجد ThinkTimes متعددة في برنامج نصي واحد.
  • يتم تجاهل ThinkTimes في عمليات اختبار البرنامج النصي الفردي.
  • سيتم استخدام ThinkTimes في المعايرة / الحصول على خط الأساس.
  • لا تساهم ThinkTimes في قياسات وقت الاستجابة.
  • يتم تجاهل ThinkTimes في اختبارات الإجهاد.

تزامن المستخدم (اختياري):

  • قدم كلمة رئيسية جديدة “WaitFor (عدد المستخدمين)” في مسجل الويب EveryStep.
  • تحظر نقطة الانتظار العالمية هذه محاكاة المستخدمين في قسم نصي معين حتى يصل العدد المتوقع من المستخدمين إلى هذا الجزء من البرنامج النصي.

حدود وقت الاستجابة (اختياري):

  • قم بتنفيذ الكلمة الأساسية SetBoundary الجديدة في مسجل الويب EveryStep.
  • بناء الجملة: SetBoundary (اسم المؤقت ، منضم 1 ، منضم 2).

خط الأساس / المعايرة (مطلوب):

  • ينفذ LoadView تشغيل اختبار مستخدم واحد.
  • سيتم استخدام ThinkTimes كما هو مكتوب.
  • يحسب LoadView وقت الجلسة: وقت الجلسة = وقت تنفيذ البرنامج النصي + ThinkTime.

تكوين عبء العمل / خطة التنفيذ (مطلوب):

  • يحدد العملاء وقت الزيادة.
  • يحدد العملاء معدل معاملاتهم المستهدفة.
  • يحدد العملاء وقت جلسة الهدف.
  • يحسب النظام عدد المستخدمين.
  • يقرر العملاء ما إذا كانوا سيحسبون أوقات الاستجابة أثناء التكثيف أم لا.

تشغيل الاختبار (مطلوب):

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

 

توصيات ونصائح للتكامل مع Dotcom-Monitor

مسجل ويب EveryStep

  • تقديم كلمات رئيسية جديدة ل ThinkTime.
  • تجاهل ThinkTime أثناء عمليات تشغيل اختبار المستخدم الفردي.
  • أضف ThinkTime أثناء تسجيل البرنامج النصي.
  • تقديم كلمة رئيسية جديدة ل WaitFor (رقم المستخدم).
  • تقديم كلمة رئيسية جديدة SetBoundary (اسم المؤقت ، B1 ، B2).
  • يجب إضافة الكلمة الأساسية WaitFor يدويا إلى البرامج النصية التي تم إنشاؤها.
  • استخدم الكلمة الرئيسية SetBound.

المعايرة/الحصول على خط الأساس

  • احسب وقت الجلسة أثناء المعايرة.

خطة التنفيذ / عبء العمل

الخيار 1:

  • إضافة ميزة جديدة لتكوين حمل العمل.
  • استبدل خطة التنفيذ بميزة عبء العمل.
  • قم بإنشاء مربع حوار تكوين حمل العمل لدعم اختبارات الإجهاد وأهداف المعاملات والأنواع الأخرى.
  • حدد وقت التكثيف.
  • حدد المربع لحساب أوقات الاستجابة أثناء التكثيف (نعم / لا).

الخيار 2:

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

تشغيل الاختبار

  • حساب وقت تنفيذ البرنامج النصي الفعلي / وقت الجلسة.
  • اضبط ThinkTimes ديناميكيا بناء على وقت الجلسة الفعلي.
  • قم برفع تحذير إذا تعذر الوصول إلى معدل النقل المتوقع.

تقرير

  • قم بتكوين قسم لوقت الاستجابة ، الفعلي مقابل الحدود لكل مؤقت.
  • قم بتكوين قسم للمعدل النقل، الفعلي مقابل المتوقع.

 

نصائح للتكامل مع Dotcom-Monitor: الأسئلة الشائعة

 

ما هي مدخلات المستخدم؟

  • ثينك تايمز (النقطة العائمة ، >0)
  • حركات الهدف في الساعة (عدد صحيح)
  • الحد الأقصى لعدد المستخدمين (عدد صحيح)
  • وقت التكثيف (بالدقائق)
  • حساب وقت الاستجابة أثناء التكثيف (نعم / لا)

 

ما هو خط الأساس؟

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

 

كيف يمكنك ضبط اختبار الحمل ديناميكيا إذا تغيرت سرعة المعاملة على النظام المستهدف؟

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

 

ما هي الكلمة الرئيسية وايت فور؟

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

 

ما هي الكلمة الرئيسية SetBound؟

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

 

ماذا يجب أن تكون أهدافك لاختبار الحمل الخاص بك؟

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

 

ما نوع التقارير التي يجب تكوينها؟

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

 

القيود

قد تؤدي أوقات جلسات الهدف العالية إلى مهلات الجلسة والإيجابيات الخاطئة. من الأهمية بمكان مراعاة السيناريوهات التي تكون فيها مهلات جلسة الويب منخفضة ، مما يضمن وضع ThinkTimes بشكل مناسب لمنع الفشل بسبب مهلات الجلسة.

 

ماذا سيحدث إذا لم نصل إلى الهدف؟

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

 

كيف يبدو نموذج عبء العمل القائم على الهدف؟

البرنامج النصي / الجهاز ST (ثانية) غير قابل للتحرير إدخال مستخدم ضريبة السلع والخدمات (بالثواني) إدخال مستخدم TPH المستخدم غير قابل للتحرير
Search_User 25 10 500 72
Inser_User 25 60 1000 216
    • وقت التصعيد: 15 دقيقة
    • قياس أوقات الاستجابة أثناء التصعيد: نعم / لا
      ST: وقت الجلسة
    • GST: وقت جلسة الهدف
    • TPH: المعاملات في الساعة
    • المستخدم: محسوب بواسطة LoadView (3600 / TPH) * ضريبة السلع والخدمات = 72
    خذ اختبار المستخدم المتزامن إلى
    المستوى التالي

    استمتع بميزات لا مثيل لها مع قابلية تطوير غير محدودة. لا بطاقة ائتمان ولا عقد.