اختبار التحميل: HTTP مقابل مقطوع الرأس مقابل المتصفح الحقيقي

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

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

HTTP مقابل مقطوع الرأس مقابل المتصفح الحقيقي

اختبار الأداء
نظره عامه:

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

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

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

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

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

نموذج البرنامج النصي على مستوى البروتوكول

المعاملة التي تتم

فار

hالسياق: العدد؛

بدأ

WebPageUrl(“http://lab3/st/”, “تحياتي”);

WebPageStoreContext(hContext);

WebPageLink(“انضم إلى التجربة!”, ” – زائر جديد”);

WebPageSubmit(“متابعة”, CONTINUE001, “القائمة الرئيسية”);

WebPageLink(“المنتجات” ، “ShopIt – المنتجات”) ؛

WebPageLink (NULL ، “ShopIt – المنتج” ، 3) ؛

WebPageSubmit (“البحث” ، SEARCH001 ، “- البحث” ، 0 ، NULL ، hContext) ؛

نهاية ماكين.

دكلفورم

CONTINUE001:

“الاسم” := “جاك” ،

“زر اسم جديد” := “متابعة” ؛

SEARCH001:

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

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

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

محاكاة تحميل بدون رأس تعتمد على المتصفح

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

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

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

محاكاة تقديم جانب العميل ليست مجانية. يمكن لخادم حقن التحميل النموذجي محاكاة ما يصل إلى 10-12 جلسة متصفح بدون رأس متزامنة ، مقابل 500 جلسة من الجلسات المستندة إلى HTTP.

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

نموذج البرنامج النصي الوهمي
“استخدام صارم” ؛
var page = requires (‘webpage’).create(),

الخادم = “http://posttestserver.com/post.php?dump”،
البيانات = “الكون = التوسع والإجابة = 42” ؛

page.open(server, ‘post’, data, function (status) {

إذا (الحالة!== ‘النجاح’) {

وحدة التحكم.log(“غير قادر على النشر!”) ؛

} آخر {

وحدة التحكم.log(صفحة.محتوى);

}
phantom.exit();

});

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

محاكاة تحميل حقيقية قائمة على المتصفح

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

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

بصمة متصفح حقيقي قائم على المتصفح أعلى قليلا. بالنظر إلى حقيقة أن محاكاة المتصفح بدون رأس لا توفر أوقات استجابة واقعية بنسبة 100٪ ، فمن الإنصاف القول إنه يجب تفضيل المحاكاة الحقيقية القائمة على المتصفح. في سيناريوهات الحياة الواقعية ، تعمل المتصفحات بدون رأس بنسبة 20٪ فقط أفضل من المتصفحات الحقيقية. لذلك ، إذا كان بإمكان حاقن التحميل الفردي متوسط الحجم تشغيل 10-12 جلسة متصفح بدون رأس ، فيمكن لحاقن الحمل نفسه تشغيل 8-10 جلسات متصفح حقيقية.

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

نموذج برنامج نصي حقيقي يستند إلى المستعرض

المعاملة التي تتم

بدأ

BrowserStart (BROWSER_MODE_DEFAULT ، 800 ، 600) ؛

انتقل إلى موقع تسجيل الدخول

BrowserNavget(“http://demo.com/TestSite/LoginForm.html”);

تعيين المصادقة للموقع الآمن

BrowserSetText(“//INPUT[@name=’user’]”, “User1”);

BrowserSetPassword(“//INPUT[@name=’pwd’]”, “Password1”);

تسجيل الدخول

BrowserClick(“//INPUT[@value=’Login’]”، BUTTON_Left)؛

نهاية ماكين.

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

أنواع اختبارات الأداء

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

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

اهداف

+ التكرار

+ واجهة آلية وفحوصات الأداء من طرف إلى طرف

+ مقارنة أوقات الاستجابة مع العتبات المتفق عليها

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

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

اهداف

+ محاكاة الحمل القابل للتكرار

+ التحقق من عتبات وقت الاستجابة

+ تحديد الاختناقات في ظل ظروف الإنتاج مثل ظروف الحمل

+ سيناريوهات اختبار واقعية من البداية إلى النهاية

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

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

اهداف

+ إثبات قابلية التوسع والاستقرار

+ محاكاة ظروف ذروة الحمل

+ الاستنساخ الدقيق ليس مهما

المقارنه

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

معايير

بروتوكول الإنترنت (HTTP)

متصفح بدون رأس

متصفح حقيقي

محاكاة المستخدم


لا يوجد

عرض من جانب العميل

تتم محاكاة بعض العناصر من جانب العميل

محاكاة المستخدم الحقيقي


تنفيذ البرنامج النصي

وتخصيصه

صعب عندما تكون مواقع الويب معقدة

مهارات المطور المطلوبة لبناء برامج نصية قوية

نصوص بسيطة وسهلة التخصيص


S

cript replay

مطلوب تحليل منخفض المستوى

اعتمادا على المحرك المستخدم ، يمكن إعادة التشغيل المرئي

ترى ما تحصل عليه

إمكانية صيانة البرنامج النصي

مهارات البرمجة المطلوبة

الأخطاء في الأقسام غير المعروضة يصعب حلها

سهل لأنك ترى حالات فشل أثناء الإعادة

دعم المتصفحات المتعددة

تحاكي بعض الأدوات متصفحات الويب ، ولكن هذا لا يمكن مقارنته

نعم، ولكن غالبا ما تكون بعض العناصر مفقودة

يدعم البعض إصدارات أخرى ومتصفحات مختلفة


F

ootprint على آلة حقن الحمل

جلسات منخفضة

تصل إلى 800 جلسة لكل خادم


متوسط

، ما يصل إلى

10-12

جلسة لكل خادم


عالية

، ما يصل إلى 6 جلسات لكل خادم


موصى به

ل

DevOps

يعتمد على سيناريو الاختبار الفعلي

لا، غالبا ما تكون البرامج النصية المعقدة

نعم، أرقام سهلة الاستخدام وواقعية

موصى به لاختبارات الحمل


لا

، يتم تخطي المعالجة من جانب العميل

نعم، أفضل من محاكاة HTTP

نعم، محاكاة واقعية للمستخدم

موصى به لاختبارات الإجهاد

نعم ، لأن هناك نفقات عامة منخفضة على آلة مولد الحمل

لا، النفقات العامة على آلة مولد الحمل مرتفعة جدا


لا،

أعلى النفقات العامة على آلة مولد الحمل

تكاليف

منخفض

عال

عال

يوصى به لاختبارات إجهاد خادم الويب ذات الحجم الكبير والتكلفة المنخفضة (حيثما أمكن ذلك)

غير موصى به

موصى به لمحاكاة التطبيقات المعقدة في الحياة الواقعية.

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

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

اهداف

+ إثبات قابلية التوسع والاستقرار

+ محاكاة ظروف ذروة الحمل

+ الاستنساخ الدقيق ليس مهما

المقارنه

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

معايير بروتوكول الإنترنت (HTTP) متصفح بدون رأس متصفح حقيقي
محاكاة المستخدم لا يوجد عرض من جانب العميل تتم محاكاة بعض العناصر الجانبية للعميل محاكاة المستخدم الحقيقي
تنفيذ البرنامج النصي وتخصيصه صعب عندما تكون مواقع الويب معقدة مهارات المطور المطلوبة لبناء برامج نصية قوية نصوص بسيطة وسهلة التخصيص
إعادة تشغيل السيناريو مطلوب تحليل منخفض المستوى اعتمادا على المحرك المستخدم ، يمكن إعادة التشغيل المرئي ترى ما تحصل عليه
إمكانية صيانة البرنامج النصي مهارات البرمجة المطلوبة الأخطاء في الأقسام التي لم يتم تقديمها صعبة الحل سهل لأنك ترى حالات فشل أثناء الإعادة
دعم المتصفحات المتعددة بعض الأدوات تحاكي متصفح الويب ولكن هذا لا يمكن مقارنته نعم، ولكن غالبا ما تكون بعض العناصر مفقودة يدعم البعض إصدارات أخرى ومتصفحات مختلفة
البصمة على آلة حقن الحمل جلسات منخفضة تصل إلى 800 جلسة لكل خادم متوسط، ما يصل إلى 10-12 جلسة لكل خادم عالية، ما يصل إلى 6 جلسات لكل خادم
موصى به ل DevOps يعتمد على سيناريو الاختبار الفعلي لا، غالبا ما تكون البرامج النصية المعقدة نعم، أرقام سهلة الاستخدام وواقعية
موصى به لاختبارات الحمل لا، يتم تخطي المعالجة من جانب العميل نعم، أفضل من محاكاة HTTP نعم، محاكاة واقعية للمستخدم
موصى به لاختبارات الإجهاد نعم ، لأن هناك نفقات عامة منخفضة على آلة مولد الحمل لا، النفقات العامة على آلة مولد الحمل مرتفعة جدا لا، أعلى النفقات العامة على آلة مولد الحمل
تكاليف منخفض عال عال
يوصى به لاختبارات إجهاد خادم الويب ذات الحجم الكبير والتكلفة المنخفضة (حيثما أمكن ذلك) غير موصى به موصى به لمحاكاة التطبيقات المعقدة في الحياة الواقعية.

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on email
Email
Share on print
Print