انهن مسئلن مان هڪ آهي جيڪو ملٽي پراڊڪٽ سافٽ ويئر وينڊرز کي اڪثر منهن ڏيڻو پوندو آهي انجنيئرن جي صلاحيتن جو نقل - ڊولپرز، ٽيسٽرز، ۽ انفراسٽرڪچر ايڊمنسٽريٽر - تقريبن هر ٽيم تي. اهو به مهانگو انجنيئرن تي لاڳو ٿئي ٿو - لوڊ ٽيسٽ جي ميدان ۾ ماهرن.
بجاءِ پنهنجون سڌيون ڊيوٽيون ڪرڻ ۽ لوڊ ٽيسٽنگ جي عمل کي ٺاهڻ لاءِ پنهنجو منفرد تجربو استعمال ڪرڻ، هڪ طريقو چونڊيو، بهترين ميٽرڪس ۽ لکندا آٽو ٽيسٽ لوڊ پروفائلز جي مطابق، انجنيئرن کي اڪثر ڪري ٽيسٽنگ انفراسٽرڪچر کي شروع کان ئي ترتيب ڏيڻو پوندو آهي، لوڊ ٽولز کي ترتيب ڏيڻ، ۽ انهن کي شامل ڪرڻ. پاڻ CI سسٽم ۾، رپورٽن جي نگراني ۽ اشاعت قائم ڪرڻ.
توھان ڪجھ تنظيمي مسئلن جا حل ڳولي سگھوٿا جاچ ۾ جيڪي اسان استعمال ڪندا آھيون مثبت ٽيڪنالاجيون ۾ . ۽ هن ۾، مان هڪ عام CI پائپ لائن ۾ لوڊ ٽيسٽ کي ضم ڪرڻ جي امڪان جي باري ۾ ڳالهائيندس "لوڊ ٽيسٽنگ ايز سروس" (لوڊ ٽيسٽنگ بطور سروس) جي تصور کي استعمال ڪندي. توهان سکندا سين ته لوڊ ذريعن جون ڪهڙيون ۽ ڪهڙيون ڊڪر تصويرون سي آءِ پائپ لائن ۾ استعمال ٿي سگهن ٿيون؛ بلڊ ٽيمپليٽ استعمال ڪندي لوڊ ذريعن کي پنهنجي سي آءِ پروجيڪٽ سان ڪيئن ڳنڍجي؛ لوڊ ٽيسٽ هلائڻ ۽ نتيجن کي شايع ڪرڻ لاءِ ڊيمو پائپ لائن ڪهڙي طرح نظر اچي ٿي. آرٽيڪل سافٽ ويئر ٽيسٽنگ انجنيئرز ۽ CI ۾ آٽوميشن انجنيئرن لاءِ مفيد ٿي سگھي ٿو جيڪي پنھنجي لوڊ سسٽم جي فن تعمير بابت سوچي رھيا آھن.
تصور جي جوهر
خدمت جي طور تي لوڊ ٽيسٽ جو تصور اپاچي JMeter، Yandex.Tank ۽ توهان جي پنهنجي فريم ورڪ کي هڪ خودمختيار مسلسل انٽيگريشن سسٽم ۾ لوڊ اوزار کي ضم ڪرڻ جي صلاحيت جو مطلب آهي. ڊيمو GitLab CI لاءِ هوندو، پر اصول سڀني سي آءِ سسٽم لاءِ عام آهن.
لوڊ ٽيسٽنگ سروس جي طور تي لوڊ ٽيسٽ لاءِ مرڪزي خدمت آھي. لوڊ ٽيسٽون وقف ٿيل ايجنٽ پولز ۾ هلن ٿيون، نتيجا پاڻمرادو شايع ٿين ٿا GitLab Pages، Influx DB ۽ Grafana يا ٽيسٽ رپورٽنگ سسٽم ۾ (TestRail، ReportPortal، وغيره). خودڪار ۽ اسڪيلنگ کي ممڪن طور تي ممڪن طور تي لاڳو ڪيو ويو آهي - GitLab CI پروجيڪٽ ۾ معمولي gitlab-ci.yml ٽيمپليٽ کي شامل ڪرڻ ۽ پيراميٽر ڪرڻ سان.
هن طريقي جو فائدو اهو آهي ته سڄو CI انفراسٽرڪچر، لوڊ ايجنٽ، لوڊ ذريعن جي ڊاکر تصويرون، ٽيسٽنگ پائپ لائنز، ۽ پبلشنگ رپورٽون هڪ مرڪزي آٽوميشن ڊپارٽمينٽ (DevOps انجنيئرز) پاران برقرار رکيا ويا آهن، جڏهن ته لوڊ ٽيسٽ انجنيئر پنهنجي ڪوششن تي ڌيان ڏئي سگهن ٿا ٽيسٽ ڊولپمينٽ تي. ۽ انهن جي نتيجن جو تجزيو، انفراسٹرڪچر جي مسئلن سان معاملو ڪرڻ کان سواء.
تشريح جي سادگي لاءِ، اسان فرض ڪنداسين ته ٽارگيٽ ايپليڪيشن يا سرور جي ٽيسٽ تحت اڳ ۾ ئي ترتيب ڏني وئي آهي ۽ اڳ ۾ ترتيب ڏني وئي آهي (پائٿون، سالٽ اسٽيڪ، جوابي، وغيره ۾ خودڪار اسڪرپٽ ان لاءِ استعمال ڪري سگهجن ٿيون). پوءِ خدمت جي طور تي لوڊ ٽيسٽ جو سڄو تصور ٽن مرحلن ۾ فٽ ٿئي ٿو: تياري، جاچ، رپورٽ جي اشاعت. ڊاگرام تي وڌيڪ تفصيل (سڀ تصويرون ڪلڪ ڪري سگهجن ٿيون):
لوڊ ٽيسٽ ۾ بنيادي تصور ۽ وصفون
جڏهن لوڊ ٽيسٽ کڻڻ، اسان کي عمل ڪرڻ جي ڪوشش ڪندا آهيون , مناسب اصطلاحن ۽ تجويز ڪيل ميٽرڪ استعمال ڪريو. مان لوڊ ٽيسٽنگ ۾ بنيادي تصورن ۽ وصفن جي مختصر فهرست ڏيندس.
لوڊ ايجنٽ - هڪ ورچوئل مشين جنهن تي ايپليڪيشن لانچ ڪئي ويندي - لوڊ جو ذريعو (Apache JMeter، Yandex.Tank يا خود لکيل لوڊ ماڊل).
ٽيسٽ گول (هدف) - سرور تي نصب ڪيل سرور يا ايپليڪيشن جيڪا لوڊ ٿيڻ جي تابع هوندي.
ٽيسٽ منظر (ٽيسٽ ڪيس) - پيٽرولر ٿيل قدمن جو هڪ سيٽ: صارف جي عملن ۽ انهن عملن تي متوقع ردعمل، مقرر ڪيل نيٽ ورڪ جي درخواستن ۽ جوابن سان، مخصوص پيٽرولن تي منحصر ڪري ٿو.
پروفائل يا لوڊ پلان (پروفائل) - اندر (سيڪشن 4.2.4، ص. 43) لوڊ پروفائلز ميٽرڪ جي وضاحت ڪن ٿا جيڪي خاص ٽيسٽ لاءِ نازڪ آھن ۽ ٽيسٽ دوران لوڊ پيٽرولر کي تبديل ڪرڻ جا اختيار. توھان تصوير ۾ پروفائلز جا مثال ڏسي سگھو ٿا.
ٽيسٽ - ھڪڙو منظرنامو جيڪو اڳواٽ مقرر ڪيل پيٽرولن سان.
ٽيسٽ پلان (ٽيسٽ پلان) - ٽيسٽ جو هڪ سيٽ ۽ لوڊ پروفائل.
ٽيسٽران (ٽيسٽرن) - ھڪڙي آزمائش کي ھلائڻ جو ھڪڙو عمل مڪمل طور تي جاري ڪيل لوڊ منظر ۽ وصول ڪيل رپورٽ سان.
نيٽ ورڪ جي درخواست (درخواست) - هڪ HTTP درخواست هڪ ايجنٽ کان ٽارگيٽ ڏانهن موڪليو ويو.
نيٽ ورڪ جواب (جواب) - ھڪڙو HTTP جواب ھدف کان ايجنٽ ڏانھن موڪليو ويو.
HTTP جوابي ڪوڊ (HTTP جوابن جي حالت) - معياري جوابي ڪوڊ ايپليڪيشن سرور کان.
هڪ ٽرانزيڪشن هڪ مڪمل درخواست-جواب چڪر آهي. هڪ ٽرانزيڪشن کي ڳڻيو ويندو آهي موڪلڻ جي شروعات کان (درخواست) جواب حاصل ڪرڻ جي مڪمل ٿيڻ تائين (جواب).
ٽرانزيڪشن جي حالت - ڇا اهو ممڪن هو ته ڪاميابيءَ سان درخواست-جواب واري چڪر کي مڪمل ڪرڻ. جيڪڏهن هن چڪر ۾ ڪا به غلطي هئي، ته پوء سڄي ٽرانزيڪشن کي ناڪام سمجهيو ويندو آهي.
جوابي وقت (ويڪرائي) - درخواست موڪلڻ جي پڇاڙي کان وٺي (درخواست) جواب حاصل ڪرڻ جي شروعات تائين (جواب).
لوڊ ميٽرڪس - لوڊ ٿيل سروس جون خاصيتون ۽ لوڊ ايجنٽ لوڊ ٽيسٽ جي عمل ۾ طئي ٿيل.
لوڊ پيرا ميٽرز کي ماپڻ لاءِ بنيادي ماپون
ڪجھ سڀ کان وڌيڪ عام طور تي استعمال ٿيل ۽ سفارش ڪيل طريقن ۾ (ص. 36، 52) ماپون ھيٺ ڏنل جدول ۾ ڏيکاريل آھن. ايجنٽ ۽ ٽارگيٽ لاءِ ساڳيا ميٽرڪ ساڳئي لڪير تي درج ٿيل آهن.
لوڊ ايجنٽ لاء ميٽرڪس
ٽارگيٽ سسٽم يا ايپليڪيشن جا ميٽرڪ لوڊ هيٺ آزمايا پيا وڃن
جو تعداد وي سي پي يو ۽ ياداشت رام,
ڊسڪ - لوڊ ايجنٽ جي "لوھ" خاصيتون
سي پي يو, ياداشت، ڊسڪ استعمال - سي پي يو جي متحرڪ، ميموري ۽ ڊسڪ لوڊ ڪرڻ
جاچ جي عمل ۾. عام طور تي في سيڪڙو جي طور تي ماپي ويندي آهي
وڌ ۾ وڌ موجود قدر
نيٽ ورڪ ذريعي (لوڊ ايجنٽ تي) - throughput
سرور تي نيٽ ورڪ انٽرفيس،
جتي لوڊ ايجنٽ نصب ٿيل آهي.
عام طور تي بائيٽ في سيڪنڊ ۾ ماپي ويندي آهي (bps)
نيٽ ورڪ ذريعي(ھدف تي) - نيٽ ورڪ انٽرفيس بينڊوڊٿ
ٽارگيٽ سرور تي. عام طور تي بائيٽ في سيڪنڊ ۾ ماپي ويندي آهي (bps)
مجازي استعمال ڪندڙ- مجازي استعمال ڪندڙن جو تعداد،
لوڊ منظرنامي تي عملدرآمد ۽
حقيقي صارف جي عملن جي نقل ڪرڻ
مجازي صارفين جي حيثيت, پاس / ناڪام / ڪل - ڪامياب جو تعداد ۽
مجازي استعمال ڪندڙن جي ناڪام حالتون
لوڊ منظرنامي لاء، گڏو گڏ انهن جو ڪل تعداد.
اهو عام طور تي توقع آهي ته سڀني صارفين کي مڪمل ڪرڻ جي قابل هئا
توهان جي سڀني ڪمن کي لوڊ پروفائل ۾ بيان ڪيو ويو آهي.
ڪنهن به غلطي جو مطلب ٿيندو ته هڪ حقيقي استعمال ڪندڙ جي قابل نه ٿيندو
سسٽم سان ڪم ڪرڻ وقت توهان جو مسئلو حل ڪريو
درخواستون في سيڪنڊ (منٽ)- نيٽ ورڪ جي درخواستن جو تعداد في سيڪنڊ (يا منٽ).
لوڊ ايجنٽ جي هڪ اهم خصوصيت اها آهي ته اها ڪيتريون درخواستون پيدا ڪري سگهي ٿي.
حقيقت ۾، هي مجازي صارفين طرفان ايپليڪيشن تائين رسائي جي هڪ تقليد آهي
جواب في سيڪنڊ (منٽ)
- نيٽ ورڪ جوابن جو تعداد في سيڪنڊ (يا منٽ).
ٽارگيٽ سروس جي هڪ اهم خصوصيت: ڪيترو
سان سوالن جا جواب ٺاهي ۽ موڪليندا
لوڊ ڪرڻ وارو ايجنٽ
HTTP جواب جي حالت- مختلف جوابي ڪوڊ جو تعداد
لوڊ ايجنٽ پاران حاصل ڪيل ايپليڪيشن سرور مان.
مثال طور، 200 OK مطلب هڪ ڪامياب ڪال،
۽ 404 - اهو وسيلو نه مليو
لاطيني (جواب جو وقت) - آخر کان وقت
جواب (جواب) حاصل ڪرڻ شروع ڪرڻ کان پهريان هڪ درخواست (درخواست) موڪلڻ.
عام طور تي ملي سيڪنڊن ۾ ماپي ويندي آهي (ms)
ٽرانزيڪشن جو جواب وقت- هڪ مڪمل ٽرانزيڪشن جو وقت،
درخواست-جواب چڪر جي مڪمل ٿيڻ.
هي درخواست موڪلڻ جي شروعات کان وقت آهي (درخواست)
هڪ جواب حاصل ڪرڻ جي مڪمل ٿيڻ تائين (جواب).
ٽرانزيڪشن جو وقت سيڪنڊن ۾ ماپي سگھجي ٿو (يا منٽ)
ڪيترن ئي طريقن سان: گهٽ ۾ گهٽ غور ڪريو،
وڌ ۾ وڌ، سراسري ۽، مثال طور، 90 سيڪڙو.
گھٽ ۾ گھٽ ۽ وڌ ۾ وڌ پڙھڻ انتهائي آھن
سسٽم جي ڪارڪردگي جي حالت.
نائيهين سيڪڙو سڀ کان وڌيڪ استعمال ٿيل آهي،
جيئن ته اهو سڀ کان وڌيڪ صارفين کي ڏيکاري ٿو،
آرام سان آپريٽنگ سسٽم جي ڪارڪردگي جي حد تي
ٽرانزيڪشن في سيڪنڊ (منٽ) - مڪمل جو تعداد
ٽرانزيڪشن في سيڪنڊ (منٽ)،
اهو آهي، ڪيترو درخواست قبول ڪرڻ جي قابل هئي ۽
عمل جي درخواستن ۽ مسئلن جو جواب.
حقيقت ۾، هن نظام جي throughput آهي
ٽرانزيڪشن جي حالت ، پاس ٿيل / ناڪام / ڪل - نمبر
ڪامياب، ناڪام ۽ ٽرانزيڪشن جو ڪل تعداد.
حقيقي استعمال ڪندڙن لاء ناڪام
ٽرانزيڪشن جو اصل مطلب ٿيندو
لوڊ هيٺ سسٽم سان ڪم ڪرڻ جي ناڪامي
لوڊ ٽيسٽنگ اسڪيمي ڊاگرام
لوڊ ٽيسٽ جو تصور تمام سادو آهي ۽ ٽن مکيه مرحلن تي مشتمل آهي، جنهن جو مون اڳ ۾ ذڪر ڪيو آهي: تيار ڪرڻ- ٽيسٽ- رپورٽ، اهو آهي، ٽيسٽ جا مقصد تيار ڪرڻ ۽ لوڊ ذريعن لاءِ پيٽرول مقرر ڪرڻ، پوءِ لوڊ ٽيسٽ تي عمل ڪرڻ ۽ آخر ۾، ٽيسٽ رپورٽ تيار ڪرڻ ۽ شايع ڪرڻ.
اسڪيمي نوٽس:
- QA.Tester لوڊ ٽيسٽ ۾ هڪ ماهر آهي،
- ھدف ھدف واري ايپليڪيشن آھي جنھن لاء توھان ڄاڻڻ چاھيو ٿا ان جي رويي کي لوڊ ھيٺ.
شڪل ۾ ادارن، مرحلن ۽ مرحلا جو درجو ڏيڻ وارو
مرحلا ۽ مرحلا
ڇا ٿي رهيو آهي
داخلا تي ڇا آهي
پيداوار ڇا آهي
تيار ڪريو: ٽيسٽ لاء تياري جو مرحلو
لوڊ پيرا ميٽرز
سيٽنگ ۽ شروعات
استعمال ڪندڙ
لوڊ پيراگراف،
ميٽرڪ جو انتخاب ۽
ٽيسٽ پلان تيار ڪرڻ
(لوڊ پروفائل)
لاء ڪسٽمائيز اختيارن
لوڊ ايجنٽ جي شروعات
ٽيسٽ پلان
ٽيسٽ جو مقصد
VM
بادل جي ترتيب
مجازي مشين سان
گهربل خاصيتون
لوڊ ايجنٽ لاء VM سيٽنگون
لاءِ آٽوميشن اسڪرپٽ
VM ٺاھڻ
VM ۾ ترتيب ڏنل
ڪڪر
اين ڊي
او ايس سيٽ اپ ۽ تياري
لاء ماحول
لوڊ ايجنٽ جو ڪم
ماحولياتي سيٽنگون لاء
لوڊ ايجنٽ
لاءِ آٽوميشن اسڪرپٽ
ماحولياتي سيٽنگون
تيار ٿيل ماحول:
او ايس، خدمتون ۽ ايپليڪيشنون،
ڪم لاء ضروري
لوڊ ايجنٽ
لوڊ ايجنٽ
انسٽاليشن، ترتيب ۽ parameterization
لوڊ ڪرڻ وارو ايجنٽ.
يا ڊائون لوڊ ڪندي هڪ ڊاکر تصوير تان
اڳواٽ ترتيب ڏنل لوڊ جو ذريعو
لوڊ سورس ڊڪر تصوير
(YAT، JM يا خود لکيل فريم ورڪ)
سيٽنگون
لوڊ ايجنٽ
سيٽ اپ ۽ تيار
لوڊ ايجنٽ ڪم ڪرڻ لاء
ٽيسٽ: لوڊ ٽيسٽ جي عمل جو مرحلو. ذريعا آهن لوڊ ايجنٽ GitLab CI لاءِ وقف ٿيل ايجنٽ پولز ۾ تعینات آهن
بار
لوڊ ايجنٽ جي شروعات
منتخب ٿيل ٽيسٽ پلان سان
۽ لوڊ پيراگراف
استعمال ڪندڙ جا اختيار
شروعات لاء
لوڊ ايجنٽ
ٽيسٽ پلان
ٽيسٽ جو مقصد
عملدرآمد لاگز
لوڊ ٽيسٽ
سسٽم لاگ
گول ميٽرڪ ۽ لوڊ ايجنٽ ۾ تبديلين جي متحرڪ
ايجنٽ هلائڻ
ايجنٽ جي عملداري
ٽيسٽ اسڪرپٽ جو لوڊ
جي مطابق
پروفائل لوڊ ڪريو
لوڊ ايجنٽ جي رابطي
امتحان جي مقصد لاء
ٽيسٽ پلان
ٽيسٽ جو مقصد
بوٽن
"خام" لاگن جو مجموعو
لوڊ جاچ دوران:
لوڊ ايجنٽ سرگرمي رڪارڊ،
ٽيسٽ هدف جي حالت
۽ VM ايجنٽ هلائيندڙ
عملدرآمد لاگز
لوڊ ٽيسٽ
سسٽم لاگ
ميٽرڪ
گڏ ڪرڻ "خام" ميٽرڪ جاچ دوران
گول ميٽرڪ ۾ تبديلين جي متحرڪ
۽ لوڊ ايجنٽ
رپورٽ: ٽيسٽ رپورٽ تيار ڪرڻ جو مرحلو
جنريٽر
گڏ ڪيل پروسيسنگ
لوڊشيڊنگ سسٽم ۽
نگراني نظام "خام"
ميٽرڪ ۽ لاگ
۾ رپورٽ جي ٺهڻ
انساني پڙهڻ وارو فارم
عناصر سان ممڪن آهي
تجزيه نگار
عملدرآمد لاگز
لوڊ ٽيسٽ
سسٽم لاگ
ميٽرڪ ۾ تبديلين جي متحرڪ
ٽارگيٽ ۽ لوڊ ايجنٽ
پروسيس ٿيل "خام" لاگ
مناسب شڪل ۾
خارجي اسٽوريج تي اپ لوڊ
جامد لوڊ رپورٽ،
انساني پڙهڻ جي قابل
شايع ڪرڻ
رپورٽ جي اشاعت
لوڊ جي باري ۾
ٻاهرين ۾ جاچ
خدمت
پروسيس ٿيل "خام"
هڪ مناسب فارميٽ ۾ لاگ ان
خارجي طور تي لوڊ ڪرڻ لاء
ذخيرو
خارجي ۾ محفوظ ٿيل
اسٽوريج رپورٽون تي
لوڊ، مناسب
انساني تجزيي لاء
CI ٽيمپليٽ ۾ لوڊ ذريعن کي ڳنڍڻ
اچو ته عملي حصو ڏانهن وڃو. مان ڏيکارڻ چاهيان ٿو ته ڪمپني ۾ ڪجهه منصوبن تي ڪيئن اسان هڪ خدمت جي طور تي لوڊ ٽيسٽ جي تصور کي لاڳو ڪيو آهي.
پهريون، اسان جي DevOps انجنيئرن جي مدد سان، اسان GitLab CI ۾ ايجنٽن جو هڪ وقف پول ٺاهيو ته جيئن لوڊ ٽيسٽ هلائڻ لاءِ. انهن کي ٻين سان ٽيمپليٽس ۾ الجھن نه ڏيڻ لاء، جهڙوڪ اسيمبلي پول، اسان انهن ايجنٽن ۾ ٽيگ شامل ڪيا، : لوڊ. توھان استعمال ڪري سگھوٿا ڪي ٻيا سمجھڻ وارا ٽيگ. اهي پڇن ٿا GitLab CI رنرز.
هارڊويئر ذريعي گهربل طاقت ڪيئن معلوم ڪجي؟ لوڊ ايجنٽ جون خاصيتون - وي سي پي يو، رام ۽ ڊسڪ جو ڪافي تعداد - ان حقيقت جي بنياد تي حساب ڪري سگهجي ٿو ته Docker، Python (Yandex.Tank لاءِ)، GitLab CI ايجنٽ، جاوا (Apache JMeter لاءِ) ايجنٽ تي هلڻ گهرجي. . JMeter جي تحت جاوا لاء، اهو پڻ سفارش ڪئي وئي آهي ته گهٽ ۾ گهٽ 512 MB جو رام استعمال ڪيو وڃي ۽، مٿين حد جي طور تي، .
ان ڪري، اسان جي تجربي جي بنياد تي، اسان گھٽ ۾ گھٽ 4 وي سي پي يوز، 4 GB ريم، 60 GB SSD لوڊ ايجنٽن لاءِ استعمال ڪرڻ جي صلاح ڏيون ٿا. نيٽ ورڪ ڪارڊ جي throughput لوڊ پروفائل جي ضرورتن جي بنياد تي مقرر ڪيو ويو آهي.
اسان بنيادي طور تي ٻه لوڊ ذريعن کي استعمال ڪندا آهيون - Apache JMeter ۽ Yandex.Tank ڊاکر تصويرون.
لوڊ ٽيسٽ لاءِ Yandex کان هڪ کليل ذريعو اوزار آهي. ان جي ماڊل آرڪيٽيڪچر تي مبني آهي Phantom جي اعلي ڪارڪردگي غير مطابقت واري هٽ تي ٻڌل HTTP درخواست جنريٽر. ٽينڪ ۾ سرور جي وسيلن جي نگراني جي تعمير ٿيل آهي SSH پروٽوڪول ذريعي ٽيسٽ، خودڪار طور تي مخصوص حالتن ۾ ٽيسٽ کي روڪي سگھي ٿو، نتيجن کي ڏيکاري سگھي ٿو ڪنسول ۽ گراف جي صورت ۾، توھان پنھنجي ماڊلز کي ڳنڍي سگھو ٿا. ان جي ڪارڪردگي کي وڌائڻ لاء. رستي ۾، اسان ٽينڪ استعمال ڪيو جڏهن اهو اڃا تائين مکيه وهڪرو نه هو. مضمون ۾ "»توهان اها ڪهاڻي پڙهي سگهو ٿا ته اسان 2013 ۾ ان سان لوڊ ٽيسٽ ڪيئن ڪئي اسان جي ڪمپني جي شين مان هڪ آهي.
Apache کان هڪ اوپن سورس لوڊ ٽيسٽنگ اوزار آهي. اهو ٻنهي جامد ۽ متحرڪ ويب ايپليڪيشنن کي جانچڻ لاءِ هڪجهڙائي سان استعمال ڪري سگهجي ٿو. JMeter پروٽوڪولن جي وڏي تعداد کي سپورٽ ڪري ٿو ۽ ايپليڪيشنن سان رابطو ڪرڻ جا طريقا: HTTP، HTTPS (Java، NodeJS، PHP، ASP.NET، وغيره)، SOAP / REST Webservices، FTP، TCP، LDAP، SMTP (S)، POP3 ( S) ) ۽ IMAP(S)، ڊيٽابيس ذريعي JDBC، شيل حڪمن تي عمل ڪري سگھن ٿا ۽ جاوا شين سان ڪم ڪري سگھن ٿا. JMeter کي ٽيسٽ منصوبن ٺاهڻ، ڊيبگ ڪرڻ ۽ عمل ڪرڻ لاءِ هڪ IDE آهي. ڪنهن به جاوا مطابقت رکندڙ آپريٽنگ سسٽم (لينڪس، ونڊوز، ميڪ او ايس ايڪس) تي ڪمانڊ لائن آپريشن لاءِ CLI پڻ آهي. اوزار متحرڪ طور تي HTML ٽيسٽ رپورٽ ٺاهي سگھي ٿو.
اسان جي ڪمپني جي اندر استعمال جي آسانيءَ لاءِ، ٽيسٽ ڪندڙن جي پاڻ کي تبديل ڪرڻ ۽ ماحول کي شامل ڪرڻ جي صلاحيت لاءِ، اسان GitLab CI تي لوڊ ذريعن جي ڊاکر تصويرون ٺاهيون آهن. . اهو ان کي تيز ۽ آسان بڻائي ٿو انهن کي ڳنڍڻ لاءِ پائپ لائنن ۾ لوڊ ٽيسٽ لاءِ. GitLab CI ذريعي رجسٽري ڏانهن ڊڪر پش ڪيئن ڪجي - ڏسو .
اسان Yandex.Tank لاءِ هي بنيادي ڊاکر فائل ورتو:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]۽ Apache JMeter لاءِ هي هڪ:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]توهان پڙهي سگهو ٿا ته اسان جو مسلسل انضمام سسٽم ڪيئن ڪم ڪري ٿو مضمون ۾ "».
ٽيمپليٽ ۽ پائپ لائن
لوڊ ٽيسٽ ڪرڻ لاءِ ٽيمپليٽ جو هڪ مثال پروجيڪٽ ۾ موجود آهي . جي توھان پڙھي سگھوٿا ٽيمپليٽ استعمال ڪرڻ لاءِ هدايتون. پاڻ ٽيمپليٽ ۾ (file ) هتي نوٽس آهن ته هر قدم لاء ذميوار آهي.
ٽيمپليٽ تمام سادو آهي ۽ مٿي ڏنل ڊراگرام ۾ بيان ڪيل لوڊ ٽيسٽ جي ٽن مرحلن کي ظاهر ڪري ٿو: رپورٽون تيار ڪرڻ، جانچ ڪرڻ، ۽ شايع ڪرڻ. ان لاءِ ذميوار آهي : تيار ڪريو، ٽيسٽ ۽ رپورٽ ڪريو.
- اسٽيج ٽيسٽ ٽارگيٽ کي اڳ ۾ ترتيب ڏيڻ يا انهن جي دستيابي کي جانچڻ لاءِ استعمال ڪيو وڃي. لوڊ ذريعن لاءِ ماحول کي ترتيب ڏيڻ جي ضرورت ناهي، اهي ڊاکر تصويرن جي طور تي اڳ ۾ ٺهيل آهن ۽ ڊاکر رجسٽري ۾ پوسٽ ٿيل آهن: صرف ٽيسٽ اسٽيج تي گهربل ورزن جي وضاحت ڪريو. پر توهان انهن کي ٻيهر ٺاهي سگهو ٿا ۽ پنهنجون تبديل ٿيل تصويرون ٺاهي سگهو ٿا.
- اسٽيج لوڊ ماخذ جي وضاحت ڪرڻ، ٽيسٽ هلائڻ، ۽ ٽيسٽ نموني کي ذخيرو ڪرڻ لاء استعمال ڪيو ويو. توهان ڪنهن به لوڊ جو ذريعو چونڊي سگهو ٿا: Yandex.Tank، Apache JMeter، توهان جو پنهنجو، يا سڀ گڏجي. غير ضروري ذريعن کي بند ڪرڻ لاء، صرف تبصرو ڪريو يا نوڪري کي ختم ڪريو. لوڊ ذريعن لاء داخلا پوائنٽون:
- Yandex.Tank لاءِ لانچ پيرا ميٽرز ۾ بيان ڪيل آهن.,
- Apache JMeter شروعاتي پيٽرولر فائل ۾ بيان ڪيا ويا آهن .
نوٽ: اسيمبلي جي ٺاھ جوڙ ٽيمپليٽ CI سسٽم سان رابطي کي قائم ڪرڻ لاء استعمال ڪيو ويندو آھي ۽ ان ۾ ٽيسٽ منطق جي جڳھ کي لاڳو نٿو ڪري. ٽيسٽ لاء، داخلا پوائنٽ بيان ڪيو ويو آهي، جتي ڪنٽرول بش اسڪرپٽ واقع آهي. ٽيسٽ هلائڻ جو طريقو، رپورٽون تيار ڪرڻ، ۽ ٽيسٽ اسڪرپٽ پاڻ کي QA انجنيئرن پاران لاڳو ڪيو وڃي. ڊيمو ۾، ٻنهي لوڊ ذريعن لاء، Yandex مکيه صفحي جي درخواست کي استعمال ڪيو ويندو آهي آسان ترين ٽيسٽ. اسڪرپٽ ۽ ٽيسٽ پيٽرولر ڊاريڪٽري ۾ آهن .
- اسٽيج تي توهان کي بيان ڪرڻ جي ضرورت آهي ته ٽيسٽ اسٽيج تي حاصل ڪيل ٽيسٽ جا نتيجا خارجي اسٽوريج ڏانهن ڪيئن شايع ڪيا وڃن، مثال طور، GitLab صفحن يا خاص رپورٽنگ سسٽم ڏانهن. GitLab صفحن جي ضرورت آهي ته ./public ڊاريڪٽري غير خالي هجي ۽ ٽيسٽ مڪمل ٿيڻ کان پوءِ گهٽ ۾ گهٽ هڪ index.html فائل هجي. توهان پڙهي سگهو ٿا GitLab صفحن جي خدمت جي nuances بابت. .
ڊيٽا کي برآمد ڪرڻ جا مثال:
- JMeter کان وٺي ,
- Yandex.Tank کان وٺي .
پوسٽنگ سيٽ اپ هدايتون:
- ۾ HTML statistics ,
- InfluxDB ڏانهن ۽ پوءِ .
ڊيمو مثال ۾، پائپ لائن لوڊ ٽيسٽ ۽ ٻن لوڊ ذريعن سان (توهان غير ضروري هڪ کي بند ڪري سگهو ٿا) هن طرح نظر اچي ٿو:
Apache JMeter هڪ HTML رپورٽ پاڻ ٺاهي سگھي ٿو، تنهنڪري اهو وڌيڪ فائدي وارو آهي ان کي محفوظ ڪرڻ GitLab صفحن ۾ معياري اوزار استعمال ڪندي. هي ڪيئن آهي Apache JMeter رپورٽ وانگر نظر اچي ٿو:
Yandex.Tank لاءِ ڊيمو مثال ۾، توهان صرف ڏسندا GitLab صفحن لاءِ سيڪشن ۾. جاچ دوران، ٽينڪ نتيجن کي محفوظ ڪري سگھي ٿو InfluxDB ڊيٽابيس ۾، ۽ اتان کان اھي ڏيکاري سگھجن ٿيون، مثال طور، گرافانا ۾ (ترتيب فائل ۾ ڪئي وئي آھي. ). هي ڪيئن آهي ٽينڪ جي رپورٽ گرافانا ۾ ڏسڻ ۾ اچي ٿي:
خلاصو
آرٽيڪل ۾، مون "لوڊ ٽيسٽنگ ايز سروس" (لوڊ ٽيسٽنگ ايز سروس) جي تصور بابت ڳالهايو. بنيادي خيال اهو آهي ته لوڊ ايجنٽن جي اڳوڻي ترتيب ڏنل تلاءَ جي انفراسٽرڪچر کي استعمال ڪرڻ، لوڊ ذريعن جي ڊاکر تصويرون، رپورٽنگ سسٽم ۽ هڪ پائپ لائن جيڪا انهن کي GitLab CI ۾ هڪ سادي .gitlab-ci.yml ٽيمپليٽ جي بنياد تي گڏ ڪري ٿي (مثال طور ). اهو سڀ ڪجهه آٽوميشن انجنيئرز جي هڪ ننڍڙي ٽيم جي مدد سان آهي ۽ پراڊڪٽ ٽيمن جي درخواست تي نقل ڪيو ويو آهي. مون کي اميد آهي ته هي توهان جي ڪمپني ۾ هڪ اهڙي اسڪيم تيار ڪرڻ ۽ لاڳو ڪرڻ ۾ توهان جي مدد ڪندي. ڌيان ڏيڻ لاء توهان جي مهرباني!
پي ايس مان چوڻ چاهيان ٿو ته منهنجي ساٿين، سرجي ڪربانوف ۽ نيڪولائي يوسيف جي وڏي مهرباني، اسان جي ڪمپني ۾ هڪ خدمت جي طور تي لوڊ ٽيسٽ جي تصور کي لاڳو ڪرڻ ۾ ٽيڪنيڪل مدد لاءِ.
ليکڪ: - نائب ٽيڪنالاجي ۽ ترقي جي عملن جو سربراهه (DevOps) مثبت ٽيڪنالاجيز تي
جو ذريعو: www.habr.com