التحميل البطيء أو صفحات الويب غير المستجيبة لها تأثير مباشر على الإيرادات المالية. يعد التأكد من إعداد اختبارات الأداء الخاصة بك باستخدام محاكاة الحمل الصحيحة أمرا بالغ الأهمية. إذا لم يتم القيام به بشكل صحيح ، فقد يكون له آثار كارثية. من المرجح أن يتخلى المستخدمون المحبطون عن كل ما كانوا يفعلونه ولن يعودوا. حتى إذا قمت أنت وفريقك بحل هذه المشكلة ، فمن المحتمل أن يكون الأوان قد فات. ربما وجدوا بالفعل حلا بديلا. وبمجرد أن يفعلوا ذلك ، من غير المرجح أن يعودوا مرة أخرى.
لا داعي للقلق بشأن الإيرادات المفقودة فحسب ، بل إن العوامل الأخرى ، مثل ثقة المستهلك وسلامة العلامة التجارية وما إلى ذلك ، ربما تكون أكثر ضررا على العمل. وكلما طالت المشكلة، زادت صعوبة استعادة ثقة المستهلك. ليس ذلك فحسب ، فإن العائد على الاستثمارات التي قمت بها في منتجك وفرقك ومؤسستك سيستغرق وقتا أطول لتحقيقه ، إن وجد. لذلك ، أصبح اختبار الأداء (والمراقبة) جزءا أساسيا وحاسما من سلسلة تطوير البرامج والتطبيقات. هناك طلب كبير على الحاجة إلى حل يمكنه تنفيذ اختبارات الأداء بشكل صحيح ودقيق بشكل وثيق مع تجربة المستخدم.
توفر منصات اختبار الأداء مجموعة واسعة من طرق محاكاة الحمل مثل 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;
دي كليفورم
متابعة001:
“الاسم”: = “جاك” ،
“زر الاسم الجديد”: = “متابعة” ؛
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 (الخادم ، “النشر” ، البيانات ، الوظيفة (الحالة) {
إذا (الحالة!== ‘النجاح’) {
وحدة التحكم.log(“غير قادر على النشر!”) ؛
} آخر {
وحدة التحكم .log (صفحة المحتوى) ؛
}
فانتوم.إكزيت();
});
مع وضع هذا الاعتبار في الاعتبار ، فإن المتصفحات مقطوعة الرأس هي السبيل للذهاب إذا كانت لديك مهارات برمجة وكنت تستخدم حلا يسمح بإعادة تشغيل البرنامج النصي المرئي.
محاكاة الحمل الحقيقية المستندة إلى المتصفح
تطبيقات الويب 2.0 مليئة بجافا سكريبت ، فلاش ، أجاكس ، CSS ، إلخ. بدون متصفح كامل ، لا يمكن قياس أوقات الاستجابة الفعلية من طرف إلى طرف للتطبيق أو صفحة الويب بأكملها. يتيح لك اختبار الأداء الحقيقي المستند إلى المستعرض التحقق من وظائف الموقع وسرعته كما يراها المستخدم النهائي ، وهو ما يعنيه المستخدم النهائي ، كما ناقشنا أعلاه ، هو المكان الذي يهم فيه حقا.
يجمع حل اختبار أداء المتصفح الحقيقي النموذجي أوقات تحميل الصور وجافا سكريبت و CSS والمزيد. في كثير من الأحيان ، فإنها توفر مخططات الانحدار ، والتي تصور وقت تحميل تلك المكونات.
بصمة المتصفح الحقيقي المستند إلى المتصفح أعلى قليلا. نظرا لأن محاكاة المتصفح مقطوعة الرأس لا توفر أوقات استجابة واقعية بنسبة 100 بالمائة ، فمن الإنصاف القول إن المحاكاة الحقيقية المستندة إلى المتصفح يجب أن تكون الطريقة المفضلة للاختبار.
يعد تنفيذ البرامج النصية للاختبار وصيانتها أمرا سهلا لأن إجراءات المستخدم تنعكس مباشرة ، كما أن إعادة التشغيل المرئية تجعل تصحيح الأخطاء أمرا سهلا. في نموذج البرنامج النصي أدناه، يفتح المتصفح عنوان URL، ويدرج كلمة مرور المستخدم، وينقر على زر تسجيل الدخول.
//sample real browser-based script
transaction TMain
begin
BrowserStart(BROWSER_MODE_DEFAULT, 800, 600);
انتقل إلى موقع تسجيل الدخول
المتصفحالتنقل (“https://demo.com/TestSite/LoginForm.html”) ؛
تعيين المصادقة للموقع الآمن
BrowserSetText (“//INPUT[@name=’user’]”, “User1”);
BrowserSetPassword(“//INPUT[@name=’pwd’]”, “Password1”);
تسجيل الدخول
BrowserClick (“//INPUT[@value=’Login’]”، 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 بشكل عام ، فاتصل بفريقنا أو اشترك في عرض توضيحي مع أحد مهندسي الأداء لدينا.