أداة اختبار LoadRunner: Archiمخطط الهيكل والمكونات

ما هو LoadRunner؟

LoadRunner هو اختبار أداء أداة رائدة من قبل Mercury التفاعلية في عام 1999. تم الاستحواذ على LoadRunner لاحقًا بواسطة HP في عام 2006، وتم دمج أعمال برامج HP مع Micro Focus في صفقة تم الإعلان عنها في عام 2016 واكتملت في عام 2017.

ملاحظة العلامة التجارية: OpenText أكملت الشركة استحواذها على شركة مايكرو فوكس في يناير 2023لم يعد هذا الجهاز يُباع تحت اسم HP أو Micro Focus LoadRunnerأصبح برنامج LoadRunner Professional الآن متاحًا OpenText هندسة الأداء الاحترافية، برنامج LoadRunner Enterprise هو OpenText هندسة أداء المؤسسات، وLoadRunner Cloud OpenText هندسة الأداء الأساسي. أسماء المكونات أدناه - VuGen، وحدة التحكم، مولدات الأحمال والتحليل - لم تتغير.

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

فيديو لود رانر

شاهد الفيديو أدناه للحصول على مقدمة سريعة عن LoadRunner قبل الخوض في تفاصيل المكونات.

لماذا لود رانر؟

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

إن تغطية البروتوكول هي السبب الأوضح لاختيار الفرق له، كما توضح خريطة المكونات أدناه.

بشكل عام، تدعم أداة LoadRunner RIA (تطبيقات الإنترنت الغنية)، وWeb 2.0 (HTTP/HTML، وAjax، وFlex، وSilverlight وما إلى ذلك)، والهاتف المحمول، SAP, Oracle، MS SQL الخادم، سيتريكس، آر تي إي، Mail وفوق كل شيء، Windows المقابس. قليل من الأدوات المنافسة تقدم مثل هذا التنوع الواسع من البروتوكولات المدمجة في أداة واحدة، كما توضح قائمة البروتوكولات أدناه.

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

يتكامل برنامج LoadRunner بشكل وثيق مع الأدوات الشقيقة في نفس المجموعة - Unified Functional Testing (السابقة) QTP، تُباع الآن باسم OpenText الاختبار الوظيفي) وإدارة دورة حياة التطبيقات (ALM، الآن OpenText مركز إدارة دورة حياة التطبيقات/الجودة) - الذي يمكّنك من تنفيذ عمليات الاختبار الشاملة.

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

لماذا تحتاج إلى اختبار الأداء؟

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

وتشير التقديرات إلى خسارة سنوية في الإيرادات تبلغ 4.4 مليار دولار بسبب ضعف أداء المواقع الإلكترونية.

في عصر الويب 2.0 الحالي، يغادر المستخدمون الموقع إذا لم يستجب خلال 8 ثوانٍ. تخيل نفسك تنتظر 5 ثوانٍ أثناء البحث عن Google أو إرسال طلب صداقة على فيسبوك. غالبًا ما تكون عواقب توقف الأداء أكثر تدميرًا مما يُتصور. وهناك أمثلة معروفة، مثل تلك التي أثرت على الخدمات المصرفية الإلكترونية لبنك أوف أمريكا. Amazon خدمات الويب، إنتويت وبلاك بيري.

بحسب شركة دان أند برادستريت، تعاني 59% من شركات قائمة فورتشن 500 من توقفات في العمل تُقدّر بنحو 1.6 ساعة أسبوعيًا. وبالنظر إلى أن متوسط ​​أجر الساعة في شركات فورتشن 500 التي تضم 10,000 موظف على الأقل يبلغ 56 دولارًا، فإن تكلفة العمالة الناتجة عن توقف العمل في مثل هذه الشركات تصل إلى 896,000 دولار أسبوعيًا، أي ما يزيد عن 46 مليون دولار سنويًا.

فترة توقف لا تتجاوز 5 دقائق Googleتشير التقديرات إلى أن عملية الاستحواذ على موقع .com في أغسطس 2013 كلفت عملاق البحث ما يصل إلى 545,000 ألف دولار.

تشير التقديرات إلى أن الشركات خسرت مبيعات بقيمة 1,100 دولار في الثانية خلال فترة سابقة Amazon انقطاع خدمات الويب.

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

• زيادة عدد السجلات الموجودة في قاعدة البيانات
• زيادة عدد الطلبات المتزامنة المقدمة للنظام
• عدد أكبر من المستخدمين الذين يدخلون إلى النظام في وقت واحد مقارنة بالماضي

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

ما هو لودرنر Archiتكنولوجيا؟

بشكل عام، تُعتبر بنية LoadRunner معقدة، ولكنها سهلة الفهم. يوضح مخطط بنية LoadRunner أدناه كيفية عمل المكونات الأربعة معًا.

لنفترض أنه تم تكليفك بالتحقق من أداء Amazonموقع .com لـ 5000 مستخدم.

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

VuGen

VuGen أو المستخدم الافتراضي Generator VuGen هي بيئة تطوير متكاملة (IDE) أو محرر أكواد متطور. تُستخدم VuGen لمحاكاة سلوك النظام تحت الضغط (SUL). توفر VuGen ميزة "التسجيل" التي تسجل الاتصالات من وإلى العميل والخادم في شكل نص برمجي - يُسمى أيضًا برنامج VUser النصي.

وبناءً على المثال المذكور أعلاه، يمكن لبرنامج VuGen تسجيل ومحاكاة العمليات التجارية التالية:

• تصفح صفحة المنتجات Amazon.com
• الدفع
• معالجة الدفع
• التحقق من صفحة حسابي

بمجرد إعادة تشغيل البرنامج النصي بسلاسة، عادةً ما يتعين التقاط قيم الخادم الديناميكية باستخدام ارتباط قبل أن يتم توسيع نطاقه.

مراقب

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

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

وباستخدام مثالنا كمثال، سيضيف المتحكم المعلمات التالية إلى نص VuGen البرمجي:

1. يتصفح 3500 مستخدم صفحة المنتجات الخاصة بـ Amazon.com
2. يوجد 750 مستخدمًا في صفحة الدفع
3. يقوم 500 مستخدم بإجراء عمليات الدفع
4. لن يقوم سوى 250 مستخدمًا بفحص صفحة حسابي بعد أن يقوم 500 مستخدم بمعالجة الدفع.

بل إن هناك سيناريوهات أكثر تعقيداً ممكنة:

• قم ببدء 5 VUsers كل ثانيتين حتى يتم تحميل 2 VUsers (تصفح Amazon صفحة المنتج) يتم تحقيقه.
• كرر لمدة 30 دقيقة
• تعليق التكرار لـ 25 مستخدمًا VUsers
• أعد تشغيل 20 مستخدمًا افتراضيًا
• قم بإنشاء مستخدمين (في Checkout، ومعالجة الدفع، وصفحة MyAccounts) كل ثانية.
• سيتم إنشاء 2500 مستخدم VUsers في الجهاز A
• سيتم إنشاء 2500 مستخدم VUsers في الجهاز B

آلة الوكلاء / التحميل Generatorق / عن طريق الحقن

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

وكممارسة عامة، توجد وحدة التحكم على جهاز مختلف ويتم محاكاة الحمل من أجهزة أخرى. اعتمادًا على بروتوكول البرامج النصية VUser ومواصفات الجهاز، قد تكون هناك حاجة لعدد من حاقنات التحميل للمحاكاة الكاملة. على سبيل المثال، سيتطلب VUsers لبرنامج نصي HTTP 2-4 ميجابايت لكل مستخدم VUser للمحاكاة، وبالتالي ستكون هناك حاجة إلى 4 أجهزة بذاكرة وصول عشوائي سعتها 4 جيجابايت لكل منها لمحاكاة تحميل 10,000 مستخدم VUsers.

بأخذ القياس من لدينا Amazon على سبيل المثال، يكون ناتج هذا المكون هو 5000 مستخدم افتراضي موزعة على اثنين من أجهزة الحقن: 2500 مستخدم افتراضي تم إنشاؤه على الجهاز أ و 2500 على الجهاز ب.

تحليل الأداء

بعد تنفيذ سيناريوهات التحميل، يصبح دور تحليل الأداء يأتي دور أحد مكونات LoadRunner.

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

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

تُظهر هذه الرسوم البيانية اتجاهات مختلفة لفهم الأسباب الكامنة وراء الأخطاء والفشل تحت الحمل؛ وبالتالي يساعد في معرفة ما إذا كان التحسين مطلوبًا في SUL أو Server (على سبيل المثال JBoss، Oracle) أو البنية التحتية.

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

كيفية القيام باختبار الأداء

يمكن تقسيم خارطة طريق اختبار الأداء بشكل عام إلى 5 خطوات، ملخصة في خارطة الطريق أدناه:

1. التخطيط لاختبار الحمل
2. إنشاء نصوص VuGen
3. إنشاء السيناريو
4. تنفيذ السيناريو
5. تحليل النتائج (متبوعًا بتعديل النظام)

بعد تثبيت برنامج LoadRunner، دعونا نفهم الخطوات المتضمنة في العملية واحدة تلو الأخرى.

الخطوة 1) التخطيط لاختبار الحمل

يختلف التخطيط لاختبار الأداء عن التخطيط أ SIT (اختبار تكامل النظام) or UAT (اختبار قبول المستخدم). يمكن تقسيم التخطيط إلى مراحل صغيرة كما هو موضح أدناه:

قم بتجميع فريقك

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

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

عرض موجز للتطبيقات والعمليات التجارية ذات الصلة

ناجح اختبار الحمل يتطلب أنك تخطط لتنفيذ عملية تجارية معينة. تتكون عملية الأعمال من خطوات محددة بوضوح تتوافق مع المعاملات التجارية المرغوبة - وذلك لتحقيق أهداف اختبار التحميل الخاصة بك.

يمكن إعداد مقياس المتطلبات لإثارة تحميل المستخدم على النظام. وفيما يلي مثال لنظام الحضور في الشركة:

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

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

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

تحديد إجراءات إدارة بيانات الاختبار

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

• يقوم المستخدم "أ" بإنشاء عملية احتيال ماليtracثم يقدمها للمراجعة.
• مستخدم آخر يُدعى "ب" يوافق على 200tracتم إنشاء هذا اليوم بواسطة المستخدم "أ"
• يدفع مستخدم آخر يُدعى "ج" حوالي 150 وحدة نقديةtracتمت الموافقة على هذا اليوم من قبل المستخدم "ب".

في هذه الحالة، يحتاج المستخدم ب إلى 200 وحدة تحكمtracتم إنشاء ts في النظام. بالإضافة إلى ذلك، يحتاج المستخدم C إلى 150 contracتم اعتبارها "موافقة" من أجل محاكاة حمل 150 مستخدمًا.

هذا يعني ضمنيًا أنه يجب عليك إنشاء ما لا يقل عن 200 + 150 = 350 وحدةtracالخبر.

بعد ذلك، وافق على 150 وحدةtracتُستخدم هذه البيانات كبيانات اختبار للمستخدم ج - أما البيانات المتبقية البالغ عددها 200tracستُستخدم هذه البيانات كبيانات اختبار للمستخدم ب.

شاشات المخطط التفصيلي

افترض كل عامل من العوامل التي قد تؤثر على أداء النظام. على سبيل المثال، قد يؤثر تقليل عدد مكونات الجهاز على أداء النظام تحت الحمل (SUL).

قم بتجميع جميع العوامل وقم بإعداد أجهزة المراقبة حتى تتمكن من قياسها. فيما يلي بعض الأمثلة:

• المعالج (لخادم الويب وخادم التطبيقات وخادم قاعدة البيانات والحقن)
• ذاكرة الوصول العشوائي (لخادم الويب وخادم التطبيقات وخادم قاعدة البيانات والحقن)
• خادم الويب/التطبيقات (على سبيل المثال IIS وJBoss وJaguar Server وTomcat وما إلى ذلك)
• خادم قاعدة البيانات (حجم PGA وSGA في حالة Oracle وMSSQL Server وSPs وما إلى ذلك)
• استخدام عرض النطاق الترددي للشبكة
• بطاقة NIC داخلية وخارجية في حالة التجميع
• موزع الحمل (ويقوم بتوزيع الحمل بالتساوي على جميع عقد المجموعات)
• البيانات flux (احسب كمية البيانات التي تنتقل من وإلى العميل والخادم - ثم احسب ما إذا كانت سعة بطاقة الشبكة كافية لمحاكاة عدد X من المستخدمين)

الخطوة الثانية: إنشاء نصوص VuGen

الخطوة التالية بعد التخطيط هي إنشاء نصوص VUser، وإضافة تحديد المعلمات والمعاملات وإعدادات وقت التشغيل مع تطور السيناريو.

الخطوة 3) إنشاء السيناريو

الخطوة التالية هي إنشاء سيناريو التحميل الخاص بك في وحدة التحكم، والاختيار بين سيناريو يدوي وسيناريو موجه نحو الهدف.

الخطوة 4) تنفيذ السيناريو

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

يمكنك ضبط مستوى التحميل عن طريق زيادة أو تقليل عدد مستخدمي VUsers الذين يقومون بمهام في نفس الوقت.

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

الخطوة 5) تحليل النتائج (متبوعًا بتعديل النظام)

أثناء تنفيذ السيناريو، يسجل LoadRunner أداء التطبيق تحت أحمال مختلفة. تُحفظ الإحصائيات المستخلصة من تنفيذ الاختبار، ويُجرى تحليل مفصل لها. تُنشئ أداة التحليل (المعروفة باسم "HP Analysis" في الإصدارات التي كُتب هذا الدليل الإرشادي بناءً عليها) رسومًا بيانية متنوعة تُساعد في تحديد الأسباب الجذرية وراء تباطؤ أداء النظام، وكذلك أعطاله.

بعض الرسوم البيانية التي تم الحصول عليها تشمل:

• الوقت المستغرق للوصول إلى المخزن المؤقت الأول
• وقت الاستجابة للمعاملة
• متوسط ​​وقت الاستجابة للمعاملة
• عدد الزيارات في الثانية
• Windows المصادر
• إحصائيات الأخطاء
• ملخص المعاملات

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