سنشارك في هذه المقالة تجربتنا العملية الخاصة التي اكتسبناها أثناء اختبار تطبيق Web Apps (المتجر عبر الإنترنت) الذي يعمل في سحابة MS Azure ، بالإضافة إلى وصف الأدوات التي استخدمناها لحل هذه المشكلة والاستنتاجات التي تم التوصل إليها بناءً على النتائج النتائج.
كائن الاختبار
اخترنا VirtoCommerce Storefront (تطبيق ويب يستخدم كواجهة أمامية للتطبيقات التي تم إنشاؤها على منصة VirtoCommerce) ككائنات اختبار.
للحصول على صورة حقيقية لقدرات النظام ، نحتاج إلى محاكاة طلبات المستخدمين في أقرب وقت ممكن من الواقع. ليس من المنطقي التحقق من الصفحة الرئيسية ، التي قد تكون في ذاكرة التخزين المؤقت ، ثم تدعي أن سرعتنا كانت 1 كيلو / ثانية. ليس هناك معنى في مقياس الأداء في الحياة الواقعية.
لذلك ، لكي تكون نتائج الاختبار لدينا ذات دلالة إحصائية وتعكس مؤشرات الأداء في حركة المرور الحقيقية بأكبر قدر ممكن ، تقرر استخدام الاستعلامات الأقرب قدر الإمكان من سلوك المستخدم الحقيقي في المتجر عبر الإنترنت.
دعونا نتحدث عن الإجراءات التالية ، التي سيتألف منها اختبارنا "الحقيقي":
إجراء المستخدم (نوع الاختبار)
| النسبة المئوية لإجمالي الطلبات
|
عرض صفحة فئة فريدة بمنتجاتها
| 30٪
|
عرض بطاقة منتج فريدة
| 40٪
|
إضافة عناصر إلى سلة التسوق
| 10٪
|
البحث عن المنتجات باستخدام كلمة رئيسية أو سمة فريدة
| 20٪
|
التين. 1. الإجراءات الرئيسية للمستخدمين وتكرار استخدامها المحدد.إعداد بيانات الاختبار
أهم مرحلة في أي اختبار هي إعداد البيانات. يجب اختيار بيانات الاختبار بطريقة تتوافق قدر الإمكان مع البيانات الموجودة في نظام حقيقي ، سواء من حيث الكم أو الجودة (الاتصال ، الهيكل ، إلخ). إذا كان ذلك ممكنًا ، فيجب أن يكون المبلغ الإجمالي للبيانات كافيًا ، وذلك عند الاختبار يكون هناك أقل عدد ممكن من المكالمات المتكررة للبيانات نفسها ، الأمر الذي سيتجنب الاستخدام المتكرر لذاكرة التخزين المؤقت ونتيجة لذلك الحصول على الصورة الأكثر تشاؤمًا لأداء النظام.
البيانات الرئيسية للمتجر عبر الإنترنت ، كقاعدة عامة ، هي: كتالوج للمنتجات والفئات مع الأسعار والخصومات والمعلومات حول الأرصدة.
كملء بيئة اختبار ، تم استخدام بيانات الكتالوج الحقيقية ، والتي سيتم استخدامها في بيئة الإنتاج الرئيسية:
الشكل 2. البيانات المستخدمة لملء النظام قيد الاختبار.من الواضح أنه بالنسبة للقارئ الذي ليس على دراية ببنية كتالوج VirtoCommerce ، قد لا تعني بعض أنواع البيانات أي شيء ، ولكن مع ذلك سنقدمها من أجل الحصول على فكرة على الأقل عن الترتيب الكمي.
اختبارات إعداد المشروع وتسجيله
كأداة رئيسية لاختبار التحميل ، سنستخدم MS Visual Studio Enterprise 2017 (قد لا تدعم إصدارات الاستوديو الأخرى هذا النوع من المشاريع) ونوع المشروع
Web Performance and Project Test Project .
الشكل 3. إنشاء مشروع جديد.بعد إنشاء المشروع ، سنحتاج إلى إنشاء اختبارات لكل من إجراءات المستخدم المحددة مسبقًا. نحن نقصر أنفسنا على إنشاء اختبار لإجراء مستخدم واحد كمثال ، حيث يتم إنشاء بقية الإجراءات عن طريق القياس.
بالنسبة للاختبارات ، سوف نستخدم النوع القياسي من اختبار اختبار أداء الويب ، المدمج في Visual Studio.
سيكون الاختبار الأول الذي سننشئه اختبارًا يكشف تفاصيل المنتج في متجر عبر الإنترنت.
لإنشاء اختبار ، حدد نوع الاختبار
"اختبار أداء الويب" من القائمة التي تقدمها Studio ، واضبط اسم
"Storefront-ProductDetail" .
الشكل 4. اختيار نوع الاختبار في Visual Studio.لهذا النوع من الاختبار ، سيحاول Visual Studio على الفور فتح متصفح ، حيث سيكون من الممكن النقر بشكل تفاعلي على الإجراءات الضرورية مباشرة على الموقع ، لكننا لن نقوم بذلك ، ولكننا سنغلق المتصفح على الفور ونوقف التسجيل. نتيجة لذلك ، نحصل على اختبار
Storefront-ProductDetail.webtest فارغ.
بعد ذلك ، نحتاج إلى إضافة مصدر بيانات لهذا الاختبار ، حتى نتمكن من استخدام معلمات استعلام مختلفة ضمن نفس الاختبار ، لهذا ، يوفر V
S Studio Web Performance Test مثل هذه الفرصة.
كمصدر بيانات لاختبارنا ، سنستخدم جدولًا في قاعدة البيانات حيث يتم تخزين سجلات المنتجات. بعد ذلك ، سنكون قادرين على استخدام البيانات من المصدر المتصل في الطلب ، والذي يجب أن يفتح تفاصيل المنتج على التطبيق المختبر. يتم تحقيق ذلك عن طريق إدراج البناء
"{{Data source name. Table name. Column name}}"ونتيجة لذلك ، بعد كل التلاعبات ، سيأخذ اختبارنا الأول هذا النموذج.
التين. 5. محتوى الاختبارلقد حان الوقت لأول تشغيل ، حاول تشغيل الاختبار وتأكد من أنه يعمل بشكل صحيح.
التين. 6. نتيجة اختبار واحدبالقياس ، سنقوم بإنشاء اختبارات لجميع السيناريوهات الأخرى لدينا.
التين. 7. جناح الاختبار الناتجبعد ذلك ، أصبح كل شيء تقريبًا جاهزًا لإنشاء اختبار مشترك يحاكي السلوك الفعلي للمستخدم على الموقع.
للقيام بذلك ، قم بإضافة
LoadTest جديد إلى مشروعنا
.
الشكل 8. إنشاء اختبار تحميل جديدفي المعالج الذي يظهر ، حدد نوع
اختبار التحميل المحلي .
التين. 9. اختيار نوع الاختباريتطلب هذا البند بعض التوضيح ، لأنك تسأل عن حق: "وماذا على فرضية؟" موضوع المقالة هو حول الاختبار باستخدام Teams Services و MS Azure ، ولكن هناك فارق بسيط ، نظرًا لأننا نستخدم مصادر البيانات في شكل جداول أو خدمات خارجية أخرى للاختبارات ، فقد يتسبب هذا في بعض الصعوبات عندما نحاول تشغيل هذا الاختبار في السحابة.
بعد محاولات عقيمة لجعل هذه الاختبارات تعمل في السحابة ، تخلينا عن هذا المشروع وقررنا استخدام ما يسمى بالاختبارات "المسجلة" للاختبار ، والتي يتم الحصول عليها عن طريق تسجيل الاستعلامات الناتجة عن الاختبارات التي يتم تشغيلها محليًا ومتصلة بمصادر البيانات.
لتسجيل الاختبارات ، نستخدم Fiddler ، الذي لديه القدرة على تصدير الطلبات إلى تنسيق
Visual Studio Web Tests . أكثر قليلاً سنصف بمزيد من التفصيل إجراء تسجيل مثل هذا الاختبار.
في الخطوات التالية ، نختار مدة الاختبار ، وعدد المستخدمين ، والأهم من ذلك ،
نشير إلى الاختبارات التي
ستتألف منها MixedLoadTest وما هي النسب التي سيتم استخدامها فيها.
الشكل 10. مكونات الاختبارونتيجة لذلك ، بعد كل الإجراءات ، نحصل على
MixedLoadTest مجتمعة
مهيأة للتشغيل لتطبيق منتشر محليًا.
بعد ذلك ، نحتاج إلى تشغيل هذا الاختبار ومحاولة التسجيل مع
Fiddler جميع الطلبات التي سيتم إنشاؤها نتيجة الاختبار ، بالإضافة إلى الحصول على "سجل" يمكننا تشغيله مباشرة في السحابة.
قم أولاً بتشغيل
Fiddler واختبار
MixedLoadTest .
التين. 11. نتيجة الاختباربعد معالجة جميع البيانات ، نحصل على هذه الصورة في Fiddler
التين. 12. جلسة اختبار في عازف الكمانبعد ذلك ، في Fiddler ، احفظ جميع الجلسات بتنسيق
Visual Studio Web Tests ،
ملف -> تصدير الجلسات -> جميع الجلسات -> Visual Studio Web Tests وأضف الملف الناتج إلى المشروع. دعني أذكرك بأن هذا الإجراء ضروري حتى نتمكن من الحصول على الاختبار دون الرجوع إلى مصادر البيانات الخارجية ، لأن بدء هذا النوع من الاختبارات يمكن أن يسبب مشاكل في السحابة.
التين. 13. تفاصيل الاختبار "المسجل"الآن كل شيء جاهز تقريبًا لتشغيل
اختبارنا في السحابة ، والخطوة الأخيرة في إعداد الاختبار هي فتح
MixedLoadTest "المسجل" في أي محرر نصوص واستبدال
localhost : 8888 (عنوان الوكيل ، Fiddler) بعنوان متجرنا في السحابة.
إجراء اختبار في السحابة
لإجراء الاختبارات في السحابة ، نحتاج إلى حساب صالح في
Visual Studio Team Services .
قم بإنشاء LoadTest جديد ، ولكن هذه المرة فقط حدد
اختبار التحميل المستند إلى السحابة باستخدام Visual Studio Team Services .
في الخطوات التالية ، نختار مركز البيانات الذي سيتم من خلاله إنشاء حركة المرور إلى المورد المختبر ، بالإضافة إلى الحد الأقصى لعدد الوكلاء (المستخدمين) للنمط الثابت ، أو إذا أردنا استخدام زيادة تدريجية في الحمل ، فإننا نحتاج إلى تعيين المعلمات المناسبة.
في خطوة اختيار الاختبارات ، نختار الاختبار الوحيد الذي سجلناه سابقًا باستخدام
Fiddler ، وسوف يحاكي الحمل "الحقيقي" على المورد المختبر.
بعد اكتمال الإنشاء ، أطلقنا اختبارًا ، سيعرض خلاله الاستوديو بعض المقاييس الرئيسية ، مثل الأداء وعرض النطاق الترددي ، بالإضافة إلى إنشاء الرسوم البيانية في الوقت الفعلي.
التين. 14. عملية تشغيل الاختبار في السحابةبعد اكتمال الاختبار ، يمكنك أيضًا عرض تقرير الويب المحفوظ في VSTS:
التين. 15. تقرير ويب على بوابة Visual Studio Team Servicesتحليل النتائج
النقطة الأكثر أهمية هي معالجة وتحليل نتائج الاختبار. بالنسبة للمهمة المعنية ، كان من الضروري تقييم أداء تطبيق يعمل على تكوينات مختلفة لتعريفات Azure Web Apps B2 و B3.
للقيام بذلك ، قمنا بتشغيل الاختبار "المسجل" مرة أخرى للتطبيق على تكوينات مختلفة وقمنا بتسجيل النتائج في مستند Excel.
ونتيجة لذلك ، حصلنا على هذا التقرير:
الشكل 16. تقرير نتيجة الاختباربعد تحليل البيانات التي تم الحصول عليها ، كان من الممكن معرفة الحد الأقصى للحمل الذي يمكن أن يتحمله تطبيقنا - إنه حوالي 60 مستخدمًا متزامنًا أو 9 طلبات في الثانية. مع متوسط وقت إرجاع للصفحة يبلغ 2.5 ثانية. يوضح الرسم البياني أن مشكلات الأداء تبدأ فجأة بعد قيمة حد معينة لعدد الطلبات.
كما اتضح لاحقًا ، كان السبب في ذلك هو تحميل المعالج بنسبة 100٪ ، نظرًا لأننا استخدمنا مكتبة تابعة لجهة خارجية لعرض صفحات الخادم ، والتي استخدمت التعبيرات العادية للترميز والتحليل الترميز.
الاستنتاجات
دائمًا ما يكون أداء التطبيق الذي يتم تطويره بنشاط يميل بشدة إلى التدهور ، لأن أي تغيير ، حتى الأكثر أهمية من وجهة نظر المطور ، يمكن أن يؤدي إلى عواقب وخيمة على أداء التطبيق. في هذا الصدد ، يعد اختبار الأداء الدوري إجراءً هامًا يجب إجراؤه بانتظام ويكون جزءًا من عمليات التكامل المستمر.
المشروع نفسه والتقارير التي تم تلقيها نتيجة للاختبار متوفرة على GitHub .