في مقالتنا السابقة، اختبار تحميل الويب: LoadRunner مقابل LoadView – سيناريو واقعي، أوضحنا كيفية محاكاة رحلة مستخدم نموذجية على موقع PhoneNumberMonitoring.com — بدءًا من تشغيل الموقع، وتسجيل الدخول، والتنقل بين التبويبات، ثم تسجيل الخروج — باستخدام كل من LoadRunner وLoadView. وقد ركز ذلك التحليل على الفروقات في جهد البرمجة، وتعقيد الإعداد، وسهولة الاستخدام.
استنادًا إلى هذا التمرين، تقدم هذه المقالة مقارنة مفصلة بين LoadView وLoadRunner، مع التركيز تحديدًا على إعداد سيناريو الاختبار وقدرات إعداد التقارير. نستعرض كيف يعمل كل أداة عند تنفيذ تدفق مستخدم حقيقي مع عدة مستخدمين افتراضيين، ومدى كفاءتها في التعامل مع:
- رؤية التنفيذ ودقته
- التقارير في الوقت الفعلي وما بعد الاختبار
- المحتوى الديناميكي وسلوك الواجهة الأمامية
- تشخيص الجلسات وتصحيح الأخطاء
نظرة عامة
تركز هذه المقارنة بشكل حصري على تجربة إعداد الاختبار وقدرات التقارير لكل من LoadView وLoadRunner، وهما من أبرز أدوات اختبار الأداء.
يعتمد التقييم على تدفق مستخدم حقيقي — تشغيل، تسجيل الدخول، تنفيذ إجراءات، تسجيل الخروج — تم تنفيذه على تطبيق ويب ديناميكي. وتُبرز المقارنة النقاط التالية:
- سهولة إعداد سيناريوهات التحميل
- الرؤية أثناء تنفيذ الاختبار
- عمق ووضوح تقارير الاختبار
- ميزات التصحيح مثل إعادة تشغيل الفيديو، التقاط لقطات الشاشة، تصنيف الأخطاء، وتحليل الشلال
ومع التوجه المتزايد للتطبيقات الحديثة نحو التطبيقات أحادية الصفحة (SPA) والواجهات الغنية بـ JavaScript، أصبحت الأدوات القادرة على محاكاة سلوك المتصفح الحقيقي وتوفير تشخيصات بصرية فورية أكثر أهمية من أي وقت مضى.
- إعداد سيناريو الاختبار
LoadView
مصمم سيناريو قائم على المتصفح الحقيقي
يسجل LoadView تفاعلات المتصفح الفعلية (النقرات، التمرير، الانتظار، تشغيل AJAX) مباشرة في متصفح Chrome أو Edge. يتم تمثيل كل خطوة في مخطط انسيابي مرئي، لضمان التوافق الكامل مع تجربة المستخدم.
معالج تكوين الحمل البصري
إعداد سهل لـ:
- أنواع تحميل المستخدمين: منحنى الحمل التدريجي، منحنى التعديل الديناميكي، ومنحنى قائم على الأهداف
- أنماط التحميل: تدريجي، أسي، مفاجئ، ثابت، طويل الأمد، الفشل… إلخ
- إعداد السيناريو: مدة الاختبار، التصعيد، الانخفاض، التثبيت
- المناطق: أكثر من 40 موقع سحابي عالمي (مثل سنغافورة، كاليفورنيا، لندن)
- المتصفحات: Chrome أو Edge لمحاكاة واقعية للعرض
إعداد خالٍ من البيئة
لا حاجة لتثبيت أو إدارة مولدات التحميل (LGs)، أو الأجهزة الافتراضية، أو إعدادات الجدار الناري، أو تكوينات الشبكة. يتم توفير البنية التحتية تلقائيًا من خلال سحابة LoadView.
شروط على مستوى الخطوة
تكوين معايير النجاح/الفشل لكل خطوة، مثل:
- التحقق من النص
- رؤية العناصر
- تشغيل JavaScript
- رموز حالة HTTP وغيرها
معاينة بنقرة واحدة
تشغيل معاينة لمستخدم واحد للتحقق من تدفق الاختبار بالكامل قبل التنفيذ الكامل. ويشمل ذلك عرض الواجهة، والتحقق، وقياسات الاستجابة.
ملاحظات إضافية:
- يمكن تخصيص أسماء المعاملات، التأخيرات، قياسات الوقت، Lighthouse، تحديد سرعة الشبكة وغيرها.
- منطق التفرع، الانتظار الشرطي، والتكرار متوفر افتراضيًا.
LoadRunner
تصميم السيناريو عبر وحدة التحكم
يتم إنشاء السيناريوهات باستخدام وحدة تحكم LoadRunner من خلال تعيين:
- مجموعات المستخدمين
- جداول التصعيد
- أوقات التفكير والتوقيت
- مدة التنفيذ
إعداد يدوي لمولدات التحميل
يجب على المختبرين نشر وتكوين مولدات التحميل يدويًا عبر أجهزة مختلفة أو مضيفي السحابة. يتطلب الاتصال بين LGs ووحدة التحكم إعدادات جدار ناري/NAT، وأذونات المنافذ، وتصاريح البنية التحتية.
اختبار المواقع الجغرافية معقد
لمحاكاة التحميل من مناطق متعددة، يجب على المستخدمين توفير الخوادم يدويًا في كل موقع مستهدف، وتكوين الوصول، ومزامنة تنفيذ الاختبارات.
منطق التحقق الأساسي
يعتمد التحقق من الخطوات على الاستجابات على مستوى البروتوكول (مثل HTTP 200). عمليات التحقق البصرية ممكنة فقط في سكربتات TrueClient، وهي تستهلك الموارد وتتطلب صيانة أكبر.
معاينة التنفيذ
معاينة تدفقات الاختبار مع عرض الواجهة متاحة فقط في TrueClient. بالنسبة للبروتوكولات الأخرى، لا تتضمن المعاينات تأكيدًا بصريًا لمسار الاختبار.
ملاحظات إضافية:
- يتطلب خبرة في البرمجة والبروتوكولات
- اختيار البروتوكول (Web HTTP/HTML، SAP، Citrix، وغيرها) يؤثر على تصميم السكربت
- رؤية التنفيذ في الوقت الحقيقي
LoadView
تقارير غنية مستضافة على السحابة ومتاحة في الوقت الحقيقي: يتم عرض مقاييس الأداء المباشرة باستمرار أثناء تنفيذ الاختبار.
تحديث مستمر لمؤشرات الأداء (KPIs): مثل متوسط زمن الاستجابة، النسبة المئوية الـ90، الحد الأدنى، الحد الأقصى، ومعدل الفشل.
تصنيف الأخطاء لتحديد السبب الجذري بسرعة: يتم تصنيف الأخطاء إلى فئات التحقق، العميل، الخادم، والأطراف الخارجية.
روابط لوحات القيادة القابلة للمشاركة وتقارير PDF: مشاركة سهلة للوحات المعلومات الحية أو تصدير الملخصات لمشاركتها مع الفرق.
مخططات تفاعلية لأزمنة الاستجابة، توزيع الأخطاء، ونشاط المستخدمين الافتراضيين: تتيح التعرف السريع على القمم، الاتجاهات أو حالات الفشل. عرض ملخص شامل لمراقبة تقدم الاختبار في الوقت الحقيقي.
النصف العلوي يعرض زيادة مفاجئة في متوسط وقت الاستجابة، والتي تتزامن (انظر الأسهم الحمراء) مع انخفاض في الجلسات الناجحة وارتفاع في الفاشلة (الرسم السفلي). هذا مثال مثالي لقدرة LoadView على ربط التدهور في الأداء مع سلوك الجلسات.
تتبع الجلسات عبر فترات زمنية: يساعد على تقييم استقرار الاختبار طوال فترة التنفيذ.
منحنيات تصعيد المستخدمين الافتراضيين: تمثيل بصري لزيادات التحميل مع أداء الجلسة.
يعرض هذا الرسم كيف تم تصعيد عدد المستخدمين الافتراضيين بمرور الوقت. يُظهر الخط الأخضر العدد الفعلي للمستخدمين المنفذين، والمتطابق تقريبًا مع الخط البرتقالي (المستخدمين المتوقعين)، مما يثبت ثبات التصعيد والانخفاض. يشير الخط الأرجواني إلى الحد الأقصى المكوَّن للمستخدمين الافتراضيين.
إحصاءات الخادم من كل منطقة جغرافية: لتشخيص المشكلات أو التأخير حسب المنطقة.
التنقل عبر الجلسات وعرض رحلات المستخدمين الأفراد: تحليل مسار أي مستخدم افتراضي مع بيانات الاستجابة ذات الصلة.
التعمق في معرفات الجلسات الفردية: استعراض رحلات اختبار محددة ورؤية تفاصيل الشبكة لكل مستخدم، وتحديد مصدر الأخطاء بسرعة لحلها.
يوضح هذا كيف قامت عدة وكالات سحابية (من مناطق AWS وAzure) بتوزيع الحمل. ظلت وحدة المعالجة والذاكرة متوازنة طوال الوقت، مما يؤكد على هندسة توزيع الاختبارات المرنة في LoadView.
مقارنة نتائج الاختبارات السابقة في LoadView
مقارنة النتائج عبر عدة عمليات تنفيذ للاختبار
بينما تعد التقارير في الوقت الفعلي والتقارير الثابتة ذات قيمة، يوفر LoadView أيضًا تتبعًا للتوجهات التاريخية بشكل مدمج. يتم أرشفة كل اختبار تلقائيًا ويمكن مقارنته بالتنفيذات السابقة.
عرض الأداء قبل/بعد
يتيح ذلك للفرق تقييم التغييرات التي تمت على كود التطبيق أو البنية التحتية أو الخدمات الخارجية من خلال مقارنة خطوط الأساس السابقة للأداء مع النتائج الأحدث — دون الحاجة إلى تكامل أو إعداد معقد.
لا حاجة لأي إعداد
على عكس LoadRunner، الذي يتطلب عادة تكاملًا مع أدوات خارجية مثل InfluxDB أو Grafana أو HP ALM لتحليل التوجهات والمقارنة التاريخية، يوفر LoadView تصوّرًا تاريخيًا مدمجًا من خلال واجهة ويب بسيطة — دون الحاجة لأي إعداد إضافي أو بنية تحتية.
مثال: يمكن لفريق تطوير مقارنة اختبار تم قبل أسبوعين (قبل تحسين قاعدة البيانات) مع آخر تنفيذ ورؤية التحسينات في وقت الاستجابة ومعدلات الخطأ مباشرة.
فوائد إضافية:
- يمكن لفرق ضمان الجودة التحقق من التدفقات وظيفيًا وبصريًا
- يقلل من جهود تصحيح الأخطاء من خلال تجنب تحليل السجلات أو العرض الخلفي فقط
LoadRunner
رسوم وحدة التحكم (النسخة المرخصة فقط)
عند الترخيص، توفر وحدة تحكم LoadRunner مقاييس وقت التشغيل مثل:
- المستخدمون الافتراضيون النشطون
- المعاملات في الثانية (TPS)
- عدد الأخطاء في الثانية وبعض المقاييس الأخرى
هذه الرسوم غير متوفرة في النسخة المجانية، مما يحد بشكل كبير من الرؤية أثناء التنفيذ.
لا توجد تغذية راجعة من الواجهة الأمامية
اللقطات والتحقق البصري وبيانات DOM غير متوفرة ما لم يتم استخدام TrueClient. وحتى مع TrueClient، يصعب تحليل هذه البيانات تحت ضغط تحميل مرتفع.
لا يوجد تحليل حسب المنطقة الجغرافية
لا يوفر LoadRunner تحليلًا للأداء حسب المناطق خارج الصندوق. يتطلب الأمر برمجة مخصصة أو وضع علامات خاصة.
غياب مراقبة مستوى الجلسة
لا يوفر LoadRunner رؤى لكل جلسة، مما يصعّب تتبع الخطوة التي فشلت، أو ما الذي عرضه المتصفح حينها، أو كيف تطورت الجلسة أثناء تنفيذها.
قيود إضافية:
- لا يوجد التقاط لقطات شاشة مدمج
- لا توجد بيانات جلسة في الوقت الفعلي
- يتم تأجيل تحليل السبب الجذري حتى تقرير ما بعد التنفيذ في أداة Analysis
- جدول مقارنة موجز
| الميزة | LoadView | LoadRunner |
| منشئ السيناريوهات | مرئي، قائم على المتصفح | قائم على السكربت والبروتوكولات (وحدة التحكم) |
| إعداد تحميل جغرافي | مدمج، مُدار سحابيًا | يتطلب نشر LG يدويًا |
| رؤية مستوى الجلسة | كاملة، مع إعادة التشغيل واللقطات | غير متوفرة |
| مخطط الشلال | نعم، على مستوى المتصفح | غير متوفر |
| تشغيل فيديو | نعم | لا |
| مقاييس الواجهة الأمامية (FCP، LCP، TTI، CLS) | نعم | لا |
| تصنيف الأخطاء | تجميع تلقائي حسب النوع | تحليل يدوي للسجلات |
| مشاركة التقارير | لوحات سحابية، PDF، Excel، روابط مشاركة | HTML أو PDF محلي فقط |
| مقارنة النتائج التاريخية | مدمجة | تتطلب ALM/إعداد خارجي |
| تقارير مناسبة لأصحاب المصلحة | نعم، ملائمة للأعمال | تقنية فقط |
| إعداد البيئة | مُستضاف على السحابة، لا حاجة لبنية تحتية | يتطلب إعداد مولدات التحميل |
| أفضل حالة استخدام | تطبيقات الويب، تجربة المستخدم، واجهات حديثة | واجهات خلفية، اختبار على مستوى البروتوكول |
أفضل حالات استخدام LoadRunner (اختبار على مستوى البروتوكول)
LoadRunner هو أداة قوية لاختبار الأداء على مستوى المؤسسات، ومناسبة تمامًا للتطبيقات المعتمدة بشكل كبير على الواجهة الخلفية والتي تعتمد على البروتوكولات. يقوم بمحاكاة حركة المرور على طبقة النقل، مما يجعله مثاليًا للتطبيقات التي لا تتطلب عرضًا للمتصفح.
| حالة الاستخدام | لماذا يعمل LoadRunner بشكل جيد | مثال |
| 1. اختبار تحميل واجهات API | يدعم بروتوكولات متعددة مثل HTTP، وخدمات الويب، وREST. يتيح التخصيص الدقيق والمعالجة الديناميكية للبيانات. | اختبار تحميل واجهة API لبنك أو شركة تأمين تتعامل مع معاملات كثيفة |
| 2. اختبار SAP وOracle وCitrix | يوفر دعمًا على مستوى البروتوكول لأنظمة المؤسسات المعقدة مثل SAP GUI وOracle Forms وCitrix. | اختبار أداء سير العمل في نظام SAP للموارد البشرية |
| 3. اختبار تحميل أنظمة الواجهة الخلفية | فعال لاختبار الضغط على طوابير الرسائل، وقواعد البيانات، والأنظمة القديمة مثل Mainframe. | اختبار تحميل لنظام تقارير مالية مبني على COBOL |
| 4. تكامل مع خط CI/CD | يتكامل مع Jenkins وAzure DevOps وALM لاختبارات الأداء والانحدار الآلية. | تشغيل اختبارات أداء ليلية بعد دمج الكود |
| 5. اختبار بروتوكولات معقدة | يحاكي تفاعلات FTP وSMTP وWebSocket وTelnet بدقة على مستوى البروتوكول. | اختبار أداء تحميل الملفات على خادم FTP داخلي |
| 6. البرمجة المخصصة بلغة C | يتيح تصميم اختبارات مفصلة والتعامل مع البيانات باستخدام لغة C الكاملة. | محاكاة عملية تقديم مطالبة تأمين متعددة الخطوات باستخدام سكربتات برمجية |
أفضل حالات استخدام LoadView (الاختبار باستخدام متصفح حقيقي)
(Chrome، Edge) لمحاكاة سلوك المستخدم الفعلي، مما يجعله مثاليًا لتطبيقات الويب الحديثة والفرق التي تعطي الأولوية لتجربة المستخدم والتحقق البصري.
| حالة الاستخدام | لماذا يعتبر LoadView الأنسب | مثال |
| 1. اختبار تحميل قائم على المتصفح | ينفذ رحلات مستخدم حقيقية تتضمن JavaScript والكوكيز وتحديثات DOM وعرض الصفحات. | اختبار تحميل بوابة حجز سفر |
| 2. اختبار تطبيقات SPA (React، Angular، Vue) | يتعامل تلقائيًا مع السلوك غير المتزامن (AJAX، fetch، WebSockets) في أطر JavaScript. | اختبار لوحة تحكم عملاء مبنية باستخدام Angular |
| 3. التحقق من تجربة المستخدم في التجارة الإلكترونية | يقيس زمن التحميل، وFCP، وLCP، وTTI — وهي مقاييس فعلية تؤثر على معدل التحويل. | اختبار تدفق عربة التسوق إلى الدفع قبل الجمعة السوداء |
| 4. اختبار موزّع جغرافيًا | يدعم الاختبار من أكثر من 40 موقعًا لمحاكاة الوصول من مناطق مختلفة. | اختبار سرعة الموقع من الولايات المتحدة وأوروبا والهند |
| 5. اختبار تحميل بدون سكربت | تسجيل التدفقات مثل المستخدم (نقرات، تمرير، فلاتر، تنقل). لا حاجة للبرمجة. | مديرو المنتجات أو فرق الجودة يختبرون تدفقات المستخدم بدون تدخل المطورين |
| 6. تقارير جاهزة لأصحاب المصلحة | التقارير تتضمن إعادة تشغيل الجلسات، ورسوم بيانية بصرية، وتصدير PDF — مناسبة للمستخدمين غير التقنيين. | مشاركة النتائج مع مدراء تنفيذيين أو مالكي المنتج أو العملاء |
| 7. التحقق من المحتوى الديناميكي | يلتقط كل تغيير في واجهة المستخدم، والعرض المؤجل، والنوافذ المنبثقة، والفلاتر القائمة على AJAX. | اختبار موقع حجز فنادق يحتوي على فلاتر وتحميل كسول |
ملخص من المقالة
LoadView يقدم تجربة اختبار حديثة قائمة على المتصفح ومُحسّنة لتطبيقات الويب الديناميكية. يتيح:
- الوصول في الوقت الفعلي إلى المقاييس المباشرة والرسوم البيانية أثناء تنفيذ الاختبار
- رؤى تفصيلية على مستوى الجلسة مع إمكانية إعادة تشغيل الفيديو، ولقطات الشاشة، وإعادة تشغيل التفاعلات بالكامل
- سهولة مشاركة التقارير من خلال لوحات معلومات سحابية، وملفات PDF، وتصدير إلى Excel
- تصحيح مبسط بفضل المقاييس المدمجة للمتصفح (FCP، LCP، TTI)، والتقسيم الجغرافي، وتصنيف الأخطاء التلقائي
LoadRunner، رغم قوته في الأنظمة المؤسسية المعتمدة على البروتوكولات، يقدم:
- رؤية محدودة للواجهة وعدم وجود مقاييس مدمجة للواجهة الأمامية
- تقارير بعد التنفيذ بدون لوحات مباشرة أو إعادة تشغيل للجلسات
- قدرات تقارير تعتمد غالبًا على تكاملات خارجية (مثل ALM، InfluxDB، Grafana)
- يتطلب سكربت TrueClient لمحاكاة المتصفح، مما يزيد من تعقيد الاختبار وحمل النظام