أنواع اختبار محاكاة الحمل والأداء

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

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

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

محاكاة الحمل المستندة إلى HTTP

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

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

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


//sample protocol level script
transaction TMain
var
hContext: number;
begin
WebPageUrl("https://lab3/st/", "Greetings");
WebPageStoreContext(hContext);
WebPageLink("Join the experience!", " - New Visitor");
WebPageSubmit("Continue", CONTINUE001, "Main menu");
WebPageLink("Products", "ShopIt - Products");
WebPageLink(NULL, "ShopIt - Product", 3);
WebPageSubmit("Search", SEARCH001, " - Search", 0, NULL, hContext);
end TMain;

dclform
CONTINUE001:
“الاسم”: = “جاك” ،
“زر الاسم الجديد”: = “متابعة” ؛

SEARCH001:
“بحث”: = “تمهيد” ؛

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

محاكاة تحميل بدون رأس قائم على المستعرض
مع ظهور تقنيات الويب 2.0 ، واجهت أعمال الاختبار تحديات خطيرة. لم يعد من الممكن اختبار تطبيقات المستعرضات الثرية أو محاكاتها على مستوى البروتوكول بسبب فقدان منطق العميل أثناء إعادة تشغيل البرنامج النصي. لذلك ، تم تقديم العديد من المتصفحات بدون رأس ، مثل HtmlUnit أو PhantomJS أو SlimerJS. غالبًا ما يتم بناؤها على WebKit ، المحرك وراء Chrome و Safari.

تتمتع المتصفحات بدون رأس بجميع مزايا المتصفحات الحقيقية وتعمل بشكل أسرع بدون واجهة المستخدم الرسومية الثقيلة. تستخدم العديد من أنظمة التشغيل الآلي للاختبار واختبار الأداء متصفحات بدون رأس لأنها تتيح محاكاة واقعية للمستخدم.

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

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

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

في نموذج البرنامج النصي أدناه ، يتم تنفيذ طلب نشر بسيط. أنت بحاجة إلى مهارات برمجة Java لتخصيص مثل هذه البرامج النصية للاختبار.


//sample phantomjs script
"use strict";
var page = require('webpage').create(),
server = 'https://posttestserver.com/post.php?dump',
data = 'universe=expanding&answer=42';

page.open (الخادم ، “النشر” ، البيانات ، الوظيفة (الحالة) {
إذا (الحالة! == ‘نجاح’) {
console.log (‘غير قادر على النشر!’) ؛
} آخر {
console.log (page.content) ؛
}

phantom.exit () ،
}) ؛

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

 

محاكاة تحميل حقيقية تعتمد على المستعرض

تطبيقات الويب 2.0 مليئة بـ JavaScript و Flash و AJAX و CSS وما إلى ذلك. بدون متصفح كامل ، لا يمكن قياس أوقات الاستجابة الفعلية من طرف إلى طرف للتطبيق بأكمله أو صفحة الويب. يسمح لك اختبار الأداء الحقيقي المستند إلى المستعرض بالتحقق من وظائف الموقع وسرعته كما يراها المستخدم النهائي ، كما ناقشنا أعلاه ، هو المكان المهم حقًا.

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

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

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


//sample real browser-based script
transaction TMain
begin
BrowserStart(BROWSER_MODE_DEFAULT, 800, 600);

// انتقل إلى موقع تسجيل الدخول
BrowserNavigate (“https://demo.com/TestSite/LoginForm.html”) ؛
// تعيين المصادقة للموقع الآمن
BrowserSetText (“// INPUT [@ name = ‘user’]”، “User1”) ؛
BrowserSetPassword (“// INPUT [@ name = ‘pwd’]” ، “Password1”) ؛
//تسجيل الدخول
BrowserClick (“// INPUT [@ value = ‘تسجيل الدخول’]” ، BUTTON_Left) ؛
نهاية TMain ؛

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

 

أنواع مختلفة من اختبارات الحمل والأداء

اختبارات سرعة المكون

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

أهداف اختبارات سرعة المكونات:

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

اختبارات التحميل

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

أهداف اختبارات الحمل:

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

اختبار الإجهاد

إذا كان لا بد من إثبات موثوقية التطبيق الخاص بك في ظل ظروف تحميل الذروة ، فقم بإجراء اختبار إجهاد لتحديد نقطة الانهيار في نظامك.

أهداف اختبار الإجهاد:

• إثبات قابلية التوسع والاستقرار في ظروف حركة المرور القصوى.
• لاحظ كيف يفشل النظام ويعود إلى الإنترنت.
• القابلية للتكاثر ليست مهمة.

 

مقارنة

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

معايير	HTTP	متصفح مقطوعة الرأس	متصفح حقيقي
محاكاة المستخدم	(1) عدم التقديم من جانب العميل	(2) تمت محاكاة بعض عناصر جانب العميل	(3) محاكاة حقيقية للمستخدم
تنفيذ البرنامج النصي والتخصيص	(1) صعب عندما تكون مواقع الويب معقدة	(2) مهارات المطور المطلوبة لبناء نصوص قوية	(3) نصوص بسيطة وسهلة التخصيص
اعادتها البرنامج النصي	(1) تحليل المستوى المنخفض المطلوب	(2) اعتمادًا على المحرك المستخدم ، يمكن إعادة العرض المرئي	(3) ترى ما تحصل عليه
إمكانية صيانة البرنامج النصي	(1) مهارات البرمجة المطلوبة	(2) من الصعب حل الأخطاء في الأقسام غير المقدمة	(3) سهل لأنك ترى حالات فشل أثناء إعادة التشغيل
دعم متعدد المتصفحات	(1) بعض الأدوات تحاكي متصفحات الويب ، لكن هذا لا يمكن مقارنته	(2) نعم ، ولكن غالبًا ما تكون بعض العناصر مفقودة	(2) يدعم البعض الإصدارات الأخرى والمتصفحات المختلفة
البصمة على آلة حقن الحمل	(3) منخفضة ، حتى 800 جلسة لكل خادم	(2) متوسط ، حتى 8 جلسات لكل خادم	(1) عالية ، تصل إلى 6 جلسات لكل خادم
يوصى به لـ DevOps	(2) يعتمد على سيناريو الاختبار الفعلي	(1) لا ، غالبًا نصوص معقدة	(3) نعم ، سهل الاستخدام وشخصيات واقعية
موصى به لاختبارات التحميل	(1) لا ، تم تخطي المعالجة من جانب العميل	(2) نعم ، أفضل من محاكاة HTTP	(3) نعم ، محاكاة واقعية للمستخدم
يوصى به لاختبارات الإجهاد	(3) نعم ، نظرًا لوجود حمل منخفض على آلة مولد الحمل	(2) لا ، الحمل على آلة مولد الحمل مرتفع للغاية	(1) لا ، أعلى حمل على آلة مولد الحمل
التكاليف	(3) منخفض	(2) متوسطة	(1) مرتفع
مجموع النقاط	17	19	24

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