اختبار موثوق للضغط مع مراعاة الفروق الدقيقة غير المتوقعة

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

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



هذه هي الطريقة التي يبسط بها مخطط miro.com: الكثير من الخوادم المختلفة التي تتفاعل بطريقة ما مع بعضها البعض ، بينما يؤدي كل منها مهام محددة. يبدو أنه من أجل بناء البنية التحتية لاختبارات الحمل ، كان كافياً بالنسبة لنا أن نرسم مثل هذا المخطط ، ونأخذ في الاعتبار جميع العلاقات ونبدأ في تغطية كل كتلة بالتتابعات النصية. هذا النهج جيد ، لكن الأمر سيستغرق عدة أشهر ، وهو ما لم يكن مناسبًا لنا نظرًا للنمو السريع - على مدار الأشهر الستة الماضية ، زاد عدد المستخدمين من 12 ألفًا إلى 20 ألف مستخدم عبر الإنترنت في الخدمة في نفس الوقت. بالإضافة إلى ذلك ، لم نكن نعرف كيف ستستجيب البنية التحتية لخدمتنا إلى زيادة في الحمل: أي من هذه الكتل سوف تصبح عنق الزجاجة ، والتي يمكننا قياسها خطيًا.

نتيجة لذلك ، قررنا اختبار الخدمة بمساعدة المستخدمين الظاهريين ، ومحاكاة عملهم الواقعي ، أي بناء استنساخ إنتاج وإجراء اختبار كبير ، والذي:

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

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

في هذه المقالة ، سوف أخبرك عن إنشاء سيناريو واقعي ، ومكونات إضافية - WS ، و Stress-client ، و Taurus ، - وتحميل الكتلة ، وبيع الكتلة ، وإظهار أمثلة على استخدام الاختبارات. المقالة التالية تدور حول كيفية إدارة مئات الخوادم لاختبار الحمل.

إنشاء سيناريو واقعي

لإنشاء سيناريو واقعي ، نحتاج إلى:

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

الآن المزيد عن كل بند.

تحليل عمل المستخدم على همز

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


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

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



كتل مخصصة مريحة

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



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

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

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

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

البيانات جزء من البرنامج النصي.

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

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

نتائج لهذا الجزء

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

تحميل الكتلة

مخطط الأدوات لتطبيق الحمل:



في Jmeter ، نقوم بإنشاء برنامج نصي نطلقه باستخدام Taurus ونحمّل خوادم متعددة معه: web ، api ، خوادم board. نقوم بإجراء اختبارات قاعدة البيانات بشكل منفصل باستخدام Postgresql ، وليس Jmeter ، لذلك يعرض الرسم التخطيطي خطًا متقطعًا.

عمل مخصص داخل مقبس الويب

يحدث العمل على اللوحة داخل WS-connection ، ومن الممكن أن يكون هناك عمل متعدد المستخدمين على اللوحة. يوجد الآن في مربع Jmeter داخل مدير المكونات الإضافية العديد من المكونات الإضافية للعمل مع مقبس الويب. المنطق هو نفسه في كل مكان - تفتح المكونات الإضافية ببساطة اتصال مأخذ توصيل ويب ، ولكن كل الإجراءات التي تحدث في الداخل ، في أي حال ، تحتاج إلى كتابة نفسك. لماذا؟ نظرًا لأننا لا نستطيع العمل بنفس الطريقة التي تعمل بها مع طلبات http ، أي أننا لا نستطيع كتابة نص برمجي ، وسحب قيم ديناميكية مع مستخرجات وتخطيها أكثر.

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

الإجهاد العميل

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

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

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

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

مثال الأمازون لدينا مثال

 Jmeter server  AWS: m5.large ($0.06 per Hour) vCPU: 2 Mem (GiB): 8 Dedicated EBS Bandwidth (Mbps): Up to 3,500 Network Performance (Gbps): Up to 10 → ~730  

أين يمكن الحصول على المئات من الخوادم وكيفية حفظها

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

لم نستخدم أدوات التحميل السحابية مثل Blazemeter و RedLine13 ، نظرًا لوجود قيود على الاستخدام لا تناسبنا. لدينا مواقع اختبار مختلفة ، لذلك أردنا إيجاد حل عالمي يسمح باستخدام 90٪ من التطورات ، بما في ذلك في الاختبارات المحلية.

نتيجة لذلك ، اخترنا بين مقدمي سحابة.



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

إن اختبار 50 ألف مستخدم مع 69 حالة في AWS يكلفنا حوالي 3 آلاف دولار شهريًا. كيف تحفظ؟ على سبيل المثال ، لدى AWS مثيلات مؤقتة - مثيلات موضعية. رباطة جأشنا هو أننا لا نحافظ عليها باستمرار ، فنحن نرفعها فقط لمدة الاختبارات وتكلفتها أقل بكثير. الفارق البسيط هو أن شخصًا آخر يمكنه شرائه بسعر أعلى في وقت الاختبار. لحسن الحظ ، لم يحدث هذا من قبل ، لكننا وفرنا بالفعل 60٪ على الأقل من التكلفة على حسابهم.

تحميل الكتلة

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



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

للحصول على تحليل مفصل لنتائج تنفيذ البرنامج النصي في جميع الحالات ، نستخدم Kibana. سجلات Parsim باستخدام Filebeat.

مستمع بروميثيوس لـ Apache JMeter

يحتوي Jmeter على مكون إضافي للعمل مع Prometheus ، والذي يعطي جميع الإحصاءات عن استخدام JVM والخيوط داخل الاختبار. يتيح لك هذا معرفة عدد مرات تسجيل دخول المستخدمين وتسجيل الخروج وما إلى ذلك. يمكن تخصيص المكون الإضافي لإرسال البيانات على البرنامج النصي إلى بروميثيوس ورؤيتها في الوقت الحقيقي في غرافانا.

برج الثور

نريد حل عدد من المشكلات الحالية مع Taurus ، لكننا لم نتعامل معها بعد:

• التكوينات بدلاً من النسخ النصي. إذا قمت بإجراء اختبار على Jmeter ، فمن المحتمل أنك واجهت الحاجة إلى تشغيل البرامج النصية مع مجموعات مختلفة من معلمات المصدر ، والتي كان عليك إنشاء النسخ الخاصة بها. في برج الثور ، يمكن أن يكون هناك سيناريو واحد ، وبمساعدة التكوينات للتحكم في معلمات الإطلاق ؛
• Configs لإدارة Jmeter- الخوادم عند العمل مع كتلة ؛
• محلل للنتائج عبر الإنترنت يسمح لك بجمع النتائج بشكل منفصل عن سلاسل Jmeter وعدم تحميل البرنامج النصي نفسه ؛
• التكامل مريحة مع CI.
• القدرة على اختبار النظام الموزع.

نتائج هذا الجزء

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

أمثلة على استخدام اختبارات البنية التحتية

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

اختبار قاعدة البيانات

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

هناك موقف مثير للاهتمام عندما نجري الاختبار ونرى الحمل على القرص. يوضح الرسم البياني كيف يرتفع iowait.



كذلك نرى أن هذا يؤثر على المستخدمين.



نحن نتفهم السبب: لم يعمل فراغ ولم يحذف بيانات القمامة من قاعدة البيانات. إذا لم تكن قد عملت مع Postgresql ، فسيكون Vacuum تمامًا مثل جامع Garbage في Java.



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



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

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

نحن نبحث عن حل نجد واحدة من أدوات Postgresql - Pg_replay . يمكنه أن يقوم بإعادة إنتاج ما هو مكتوب في السجلات تمامًا كما كان يحدث في وقت تسجيلهم. كيف يمكننا استخدامها بفعالية؟ نحن ننهار تفريغ قاعدة البيانات ، ثم نسجل كل ما يحدث في قاعدة البيانات بعد الحفظ في السجلات ، ومن ثم لدينا الفرصة لنشر التفريغ ولعب كل ما حدث مع قاعدة البيانات ذات مؤشرات الترابط المتعددة.

أين تكتب السجلات؟ أحد الحلول الشائعة لتسجيل السجلات هو جمعها على المنتج ، حيث يوفر هذا البرنامج النصي الأكثر واقعية للتكرار. ولكن هناك عدد من المشاكل:

• بالنسبة للاختبار ، يلزمك استخدام بيانات المبيعات ، وهو أمر غير ممكن دائمًا ؛
• تستخدم العملية عملية syslog باهظة الثمن ؛
• القرص قيد التحميل.

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

1. يتم إنشاء مثيل في AWS ؛
2. يتم نشر تفريغ نحتاج ؛
3. يتم إطلاق Pg_replay ويقوم بتشغيل السجلات اللازمة ؛
4. نحن نستخدم رصدنا لتحليل نتائج Prometheus + Grafana. هناك أمثلة على لوحات المعلومات في المستودع.

عند بدء التشغيل marucy ، يمكننا تمرير عدد صغير من المعلمات التي يمكن تغييرها ، على سبيل المثال ، كثافة البرنامج النصي.

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

رصد التدهور

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

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



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

في هذا التقرير ، على سبيل المثال ، نرى أن اختبار المقارنة قد انخفض مع وجود قيمة مرجعية.



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

نتائج لهذا الجزء

• يتيح لك اختبار واقعي اختبار قاعدة البيانات بثمن بخس وتكوينها بسهولة ؛
• اختبار وظيفي تحت الحمل ممكن.

المقالة التالية تدور حول كيفية إدارة مئات الخوادم لاختبار الحمل.