ملٹی پروڈکٹ سافٹ ویئر فروشوں کو اکثر جن مسائل کا سامنا کرنا پڑتا ہے ان میں سے ایک انجینئرز - ڈویلپرز، ٹیسٹرز، اور انفراسٹرکچر ایڈمنسٹریٹرز - کی تقریباً ہر ٹیم میں قابلیت کی نقل ہے۔ یہ مہنگے انجینئرز پر بھی لاگو ہوتا ہے - لوڈ ٹیسٹنگ کے شعبے میں ماہرین۔
اپنے براہ راست فرائض انجام دینے اور لوڈ ٹیسٹنگ کے عمل کو بنانے کے لیے اپنے منفرد تجربے کو استعمال کرنے کے بجائے، ایک طریقہ کار، بہترین میٹرکس کا انتخاب کریں اور لوڈ پروفائلز کے مطابق آٹو ٹیسٹ لکھیں، انجینئرز کو اکثر ٹیسٹ کے بنیادی ڈھانچے کو شروع سے ہی تعینات کرنا پڑتا ہے، لوڈ ٹولز کو ترتیب دینا پڑتا ہے، اور انہیں ایمبیڈ کرنا پڑتا ہے۔ خود CI نظاموں میں، نگرانی اور رپورٹوں کی اشاعت کا اہتمام کیا۔
آپ جانچ میں کچھ تنظیمی مسائل کا حل تلاش کر سکتے ہیں جو ہم مثبت ٹیکنالوجیز میں استعمال کرتے ہیں۔ . اور اس میں، میں "لوڈ ٹیسٹنگ بطور سروس" (ایک خدمت کے طور پر لوڈ ٹیسٹنگ) کے تصور کو استعمال کرتے ہوئے ایک عام CI پائپ لائن میں لوڈ ٹیسٹ کو ضم کرنے کے امکان کے بارے میں بات کروں گا۔ آپ سیکھیں گے کہ CI پائپ لائن میں لوڈ ذرائع کی کون سی ڈاکر امیجز کیسے اور کس طرح استعمال کی جا سکتی ہیں۔ بلڈ ٹیمپلیٹ کا استعمال کرتے ہوئے لوڈ کے ذرائع کو اپنے CI پروجیکٹ سے کیسے جوڑیں۔ لوڈ ٹیسٹ چلانے اور نتائج شائع کرنے کے لیے ڈیمو پائپ لائن کیسی دکھتی ہے۔ یہ مضمون CI میں سافٹ ویئر ٹیسٹنگ انجینئرز اور آٹومیشن انجینئرز کے لیے مفید ہو سکتا ہے جو اپنے لوڈ سسٹم کے فن تعمیر کے بارے میں سوچ رہے ہیں۔
تصور کا جوہر
ایک سروس کے طور پر لوڈ ٹیسٹنگ کا تصور لوڈ ٹولز Apache JMeter، Yandex.Tank اور آپ کے اپنے فریم ورک کو ایک من مانی مسلسل انضمام کے نظام میں ضم کرنے کی صلاحیت کو ظاہر کرتا ہے۔ ڈیمو GitLab CI کے لیے ہو گا، لیکن اصول تمام 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) درج ذیل جدول میں میٹرکس دکھائے گئے ہیں۔ ایجنٹ اور ہدف کے لیے ایک جیسے میٹرکس ایک ہی لائن پر درج ہیں۔
لوڈ ایجنٹ کے لیے میٹرکس
ٹارگٹ سسٹم یا ایپلیکیشن کے میٹرکس بوجھ کے تحت ٹیسٹ کیے جا رہے ہیں۔
نمبر وی سی پی یو اور میموری RAM,
ڈسک - لوڈ ایجنٹ کی "آئرن" کی خصوصیات
CPU, میموری، ڈسک کا استعمال - سی پی یو، میموری اور ڈسک لوڈنگ کی حرکیات
جانچ کے عمل میں۔ عام طور پر فیصد کے طور پر ماپا جاتا ہے۔
زیادہ سے زیادہ دستیاب اقدار
نیٹ ورک تھرو پٹ (لوڈ ایجنٹ پر) - تھرو پٹ
سرور پر نیٹ ورک انٹرفیس،
جہاں لوڈ ایجنٹ نصب ہے۔
عام طور پر بائٹس فی سیکنڈ میں ماپا جاتا ہے (bps)
نیٹ ورک تھرو پٹ(ٹارگٹ پر) - نیٹ ورک انٹرفیس بینڈوتھ
ہدف سرور پر. عام طور پر بائٹس فی سیکنڈ میں ماپا جاتا ہے (bps)
ورچوئل صارفین- ورچوئل صارفین کی تعداد،
لوڈ منظرناموں کو نافذ کرنا اور
حقیقی صارف کے اعمال کی نقل کرنا
ورچوئل صارفین کی حیثیت, پاس/ناکام/کل — کامیابوں کی تعداد اور
ورچوئل صارفین کی ناکام حالتیں۔
لوڈ منظرناموں کے ساتھ ساتھ ان کی کل تعداد کے لیے۔
عام طور پر یہ توقع کی جاتی ہے کہ تمام صارفین مکمل کرنے کے قابل تھے۔
آپ کے تمام کام جو لوڈ پروفائل میں بیان کیے گئے ہیں۔
کسی بھی غلطی کا مطلب یہ ہوگا کہ ایک حقیقی صارف نہیں کر سکے گا۔
سسٹم کے ساتھ کام کرتے وقت اپنا مسئلہ حل کریں۔
درخواستیں فی سیکنڈ (منٹ)- نیٹ ورک کی درخواستوں کی تعداد فی سیکنڈ (یا منٹ)۔
لوڈ ایجنٹ کی ایک اہم خصوصیت یہ ہے کہ وہ کتنی درخواستیں تیار کر سکتا ہے۔
درحقیقت، یہ ورچوئل صارفین کے ذریعے ایپلی کیشن تک رسائی کی نقل ہے۔
جوابات فی سیکنڈ (منٹ)
- نیٹ ورک کے جوابات کی تعداد فی سیکنڈ (یا منٹ)۔
ٹارگٹ سروس کی ایک اہم خصوصیت: کتنا
کے ساتھ سوالات کے جوابات تیار کریں اور بھیجیں۔
لوڈنگ ایجنٹ
HTTP ردعمل کی حیثیت- مختلف رسپانس کوڈز کی تعداد
لوڈ ایجنٹ کے ذریعہ موصول ہونے والے ایپلیکیشن سرور سے۔
مثال کے طور پر، 200 OK کا مطلب ہے ایک کامیاب کال،
اور 404 - کہ وسیلہ نہیں ملا
تاخیر (جواب کا وقت) - آخر سے وقت
جواب (جواب) موصول ہونے سے پہلے درخواست (درخواست) بھیجنا۔
عام طور پر ملی سیکنڈ (ms) میں ماپا جاتا ہے
لین دین کے جواب کا وقت- ایک مکمل لین دین کا وقت،
درخواست کے جواب کے چکر کی تکمیل۔
یہ درخواست بھیجنے کے آغاز کا وقت ہے (درخواست)
جواب (جواب) موصول ہونے تک۔
لین دین کا وقت سیکنڈ (یا منٹ) میں ماپا جا سکتا ہے
کئی طریقوں سے: کم سے کم پر غور کریں،
زیادہ سے زیادہ، اوسط اور، مثال کے طور پر، 90 واں پرسنٹائل۔
کم از کم اور زیادہ سے زیادہ ریڈنگ انتہائی ہیں۔
نظام کی کارکردگی کی حیثیت
نوے پرسنٹائل سب سے زیادہ استعمال کیا جاتا ہے،
جیسا کہ یہ زیادہ تر صارفین کو دکھاتا ہے،
سسٹم کی کارکردگی کی دہلیز پر آرام سے کام کرنا
لین دین فی سیکنڈ (منٹ) - مکمل کی تعداد
لین دین فی سیکنڈ (منٹ)،
یعنی، درخواست کتنی قبول کرنے کے قابل تھی اور
درخواستوں پر کارروائی کریں اور جوابات جاری کریں۔
درحقیقت یہ نظام کا تھرو پٹ ہے۔
لین دین کی حیثیت , پاس / ناکام / کل - تعداد
کامیاب، ناکام اور لین دین کی کل تعداد۔
حقیقی صارفین کے لیے ناکام
لین دین کا اصل مطلب ہوگا۔
بوجھ کے تحت نظام کے ساتھ کام کرنے میں ناکامی۔
لوڈ ٹیسٹنگ اسکیمیٹک ڈایاگرام
لوڈ ٹیسٹنگ کا تصور بہت آسان ہے اور یہ تین اہم مراحل پر مشتمل ہے، جن کا میں پہلے ذکر کر چکا ہوں: ٹیسٹ رپورٹ تیار کریں۔، یعنی، ٹیسٹ کے اہداف کی تیاری اور بوجھ کے ذرائع کے لیے پیرامیٹرز ترتیب دینا، پھر لوڈ ٹیسٹوں کو انجام دینا اور، آخر میں، ٹیسٹ رپورٹ تیار کرنا اور شائع کرنا۔
اسکیمیٹک نوٹ:
- QA.Tester لوڈ ٹیسٹنگ میں ماہر ہے،
- ٹارگٹ وہ ٹارگٹ ایپلی کیشن ہے جس کے لیے آپ بوجھ کے نیچے اس کے رویے کو جاننا چاہتے ہیں۔
خاکہ میں ہستیوں، مراحل اور مراحل کا درجہ بندی کرنے والا
مراحل اور مراحل
کیا ہو رہا ہے
داخلی دروازے پر کیا ہے۔
آؤٹ پٹ کیا ہے
تیار کریں: جانچ کے لیے تیاری کا مرحلہ
لوڈ پیرامیٹرز
ترتیب اور ابتدا
صارف
لوڈ پیرامیٹرز،
میٹرکس کا انتخاب اور
ٹیسٹ پلان کی تیاری
(لوڈ پروفائل)
کے لیے اپنی مرضی کے اختیارات
لوڈ ایجنٹ کی ابتدا
ٹیسٹ پلان
ٹیسٹنگ کا مقصد
VM
کلاؤڈ کی تعیناتی۔
ورچوئل مشین کے ساتھ
مطلوبہ خصوصیات
لوڈ ایجنٹ کے لیے VM کی ترتیبات
کے لیے آٹومیشن اسکرپٹس
VM تخلیق
VM کنفیگر ہو گیا۔
بادل
Env
OS سیٹ اپ اور تیاری
کے لئے ماحول
لوڈ ایجنٹ کا کام
کے لیے ماحولیات کی ترتیبات
لوڈ ایجنٹ
کے لیے آٹومیشن اسکرپٹس
ماحول کی ترتیبات
تیار ماحول:
OS، خدمات اور ایپلیکیشنز،
کام کے لئے ضروری ہے
لوڈ ایجنٹ
لوڈ ایجنٹس
تنصیب، ترتیب اور پیرامیٹرائزیشن
لوڈنگ ایجنٹ.
یا سے ایک ڈاکر امیج ڈاؤن لوڈ کرنا
پہلے سے تشکیل شدہ لوڈ سورس
لوڈ سورس ڈوکر امیج
(YAT، JM یا خود لکھا ہوا فریم ورک)
ترتیب کے اختیارات۔
لوڈ ایجنٹ
سیٹ اپ اور تیار
لوڈ ایجنٹ کام کرنے کے لئے
ٹیسٹ: لوڈ ٹیسٹ پر عمل درآمد کا مرحلہ۔ ذرائع GitLab CI کے لیے مخصوص ایجنٹ پولز میں تعینات لوڈ ایجنٹس ہیں
لوڈ
لوڈ ایجنٹ شروع کرنا
منتخب ٹیسٹ پلان کے ساتھ
اور لوڈ پیرامیٹرز
صارف کے اختیارات
ابتدا کے لیے
لوڈ ایجنٹ
ٹیسٹ پلان
ٹیسٹنگ کا مقصد
پھانسی کے نوشتہ جات
لوڈ ٹیسٹ
سسٹم لاگز
گول میٹرکس اور لوڈ ایجنٹ میں تبدیلیوں کی حرکیات
ایجنٹوں کو چلائیں۔
ایجنٹ پھانسی
ٹیسٹ سکرپٹ کا بوجھ
بمطابق
پروفائل لوڈ کریں۔
لوڈ ایجنٹ کا تعامل
جانچ کے مقصد کے لیے
ٹیسٹ پلان
ٹیسٹنگ کا مقصد
کھنگالیں
"کچے" نوشتہ جات کا مجموعہ
لوڈ ٹیسٹنگ کے دوران:
لوڈ ایجنٹ کی سرگرمی کے ریکارڈ،
ٹیسٹ کے ہدف کی حالت
اور VM ایجنٹ چلا رہا ہے۔
پھانسی کے نوشتہ جات
لوڈ ٹیسٹ
سسٹم لاگز
پیمائش کا معیار
جانچ کے دوران "خام" میٹرکس جمع کرنا
گول میٹرکس میں تبدیلیوں کی حرکیات
اور لوڈ ایجنٹ
رپورٹ: ٹیسٹ رپورٹ کی تیاری کا مرحلہ
جنریٹر
پروسیسنگ اکٹھا کی گئی۔
لوڈنگ سسٹم اور
نگرانی کا نظام "خام"
میٹرکس اور لاگز
میں رپورٹ کی تشکیل
انسانی پڑھنے کے قابل فارم
عناصر کے ساتھ ممکن ہے
تجزیہ کار
پھانسی کے نوشتہ جات
لوڈ ٹیسٹ
سسٹم لاگز
میٹرکس میں تبدیلیوں کی حرکیات
ہدف اور لوڈ ایجنٹ
پروسیس شدہ "کچے" لاگز
کے لیے موزوں شکل میں
بیرونی اسٹوریج پر اپ لوڈ کرتا ہے۔
جامد لوڈ کی رپورٹ،
انسانی پڑھنے کے قابل
شائع
رپورٹ کی اشاعت
لوڈ کے بارے میں
بیرونی میں ٹیسٹنگ
خدمت
پروسیس شدہ "خام"
ایک مناسب فارمیٹ میں لاگ ان کرتا ہے۔
بیرونی پر اتارنے کے لیے
والٹس
بیرونی میں محفوظ کیا گیا۔
پر سٹوریج کی رپورٹ
لوڈ، مناسب
انسانی تجزیہ کے لیے
CI ٹیمپلیٹ میں لوڈ ذرائع کو جوڑنا
آئیے عملی حصے کی طرف چلتے ہیں۔ میں یہ بتانا چاہتا ہوں کہ کمپنی میں کچھ پروجیکٹس کیسے ہیں۔ ہم نے لوڈ ٹیسٹنگ کے تصور کو بطور سروس لاگو کیا ہے۔
سب سے پہلے، اپنے DevOps انجینئرز کی مدد سے، ہم نے لوڈ ٹیسٹ چلانے کے لیے GitLab CI میں ایجنٹوں کا ایک وقف شدہ پول بنایا۔ ٹیمپلیٹس میں انہیں دوسروں کے ساتھ الجھانے کے لیے، جیسے اسمبلی پول، ہم نے ان ایجنٹوں میں ٹیگ شامل کیے، : بوجھ آپ کوئی اور قابل فہم ٹیگ استعمال کر سکتے ہیں۔ وہ پوچھتے ہیں GitLab CI رنرز۔
ہارڈ ویئر کے ذریعے مطلوبہ طاقت کیسے معلوم کی جائے؟ لوڈ ایجنٹس کی خصوصیات - vCPU، RAM اور ڈسک کی کافی تعداد - کا اندازہ اس حقیقت کی بنیاد پر لگایا جا سکتا ہے کہ Docker، Python (Yandex.Tank کے لیے)، GitLab CI ایجنٹ، Java (Apache JMeter کے لیے) ایجنٹ پر چل رہے ہوں گے۔ . JMeter کے تحت Java کے لیے، یہ بھی تجویز کیا جاتا ہے کہ کم از کم 512 MB RAM استعمال کی جائے اور اوپری حد کے طور پر، .
اس طرح، ہمارے تجربے کی بنیاد پر، ہم تجویز کرتے ہیں کہ کم از کم 4 vCPUs، 4 GB RAM، 60 GB SSD لوڈ ایجنٹس کے لیے استعمال کریں۔ نیٹ ورک کارڈ کے تھرو پٹ کا تعین لوڈ پروفائل کی ضروریات کی بنیاد پر کیا جاتا ہے۔
ہم بنیادی طور پر لوڈ کے دو ذرائع استعمال کرتے ہیں - Apache JMeter اور Yandex.Tank ڈاکر امیجز۔
لوڈ ٹیسٹنگ کے لیے Yandex کا ایک اوپن سورس ٹول ہے۔ اس کا ماڈیولر فن تعمیر فینٹم کے اعلیٰ کارکردگی کے غیر مطابقت پذیر ہٹ پر مبنی HTTP درخواست جنریٹر پر مبنی ہے۔ ٹینک میں SSH پروٹوکول کے ذریعے ٹیسٹ کے تحت سرور کے وسائل کی بلٹ ان مانیٹرنگ ہوتی ہے، مخصوص حالات میں ٹیسٹ کو خود بخود روک سکتا ہے، نتائج کو کنسول اور گراف کی شکل میں ظاہر کر سکتا ہے، آپ اپنے ماڈیولز کو جوڑ سکتے ہیں۔ فعالیت کو بڑھانے کے لیے اس پر۔ ویسے، ہم نے ٹینک کا استعمال اس وقت کیا جب یہ ابھی مین اسٹریم نہیں تھا۔ مضمون میں "» آپ اس کی کہانی پڑھ سکتے ہیں کہ ہم نے 2013 میں اس کے ساتھ لوڈ ٹیسٹنگ کیسے کی تھی۔ ہماری کمپنی کی مصنوعات میں سے ایک ہے۔
اپاچی کا ایک اوپن سورس لوڈ ٹیسٹنگ ٹول ہے۔ یہ جامد اور متحرک ویب ایپلیکیشنز دونوں کی جانچ کے لیے یکساں طور پر اچھی طرح سے استعمال کیا جا سکتا ہے۔ JMeter بڑی تعداد میں پروٹوکولز اور ایپلی کیشنز کے ساتھ تعامل کے طریقوں کی حمایت کرتا ہے: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET، وغیرہ)، SOAP / REST ویب سروسز، FTP، TCP، LDAP، SMTP(S)، POP3( S) ) اور IMAP(S)، JDBC کے ذریعے ڈیٹا بیس، شیل کمانڈز کو چلا سکتے ہیں اور جاوا آبجیکٹ کے ساتھ کام کر سکتے ہیں۔ JMeter کے پاس ٹیسٹ پلان بنانے، ڈیبگ کرنے اور عمل کرنے کے لیے IDE ہے۔ کسی بھی جاوا سے مطابقت رکھنے والے آپریٹنگ سسٹم (لینکس، ونڈوز، میک او ایس ایکس) پر کمانڈ لائن آپریشن کے لیے ایک CLI بھی ہے۔ ٹول متحرک طور پر ایچ ٹی ایم ایل ٹیسٹ رپورٹ بنا سکتا ہے۔
ہماری کمپنی کے اندر استعمال میں آسانی کے لیے، ٹیسٹرز کی خود کو تبدیل کرنے اور ماحول کو شامل کرنے کی صلاحیت کے لیے، ہم نے GitLab CI پر لوڈ سورسز کی ڈوکر امیجز بنا کر داخلی میں شائع کیں۔ . اس سے لوڈ ٹیسٹ کے لیے ان کو پائپ لائنوں میں جوڑنا تیز اور آسان ہو جاتا ہے۔ GitLab CI کے ذریعے رجسٹری میں ڈاکر پش کیسے کریں - دیکھیں .
ہم نے Yandex.Tank کے لیے یہ بنیادی ڈاکر فائل لی:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]اور Apache JMeter کے لیے یہ ایک:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]آپ مضمون میں پڑھ سکتے ہیں کہ ہمارا مسلسل انضمام کا نظام کیسے کام کرتا ہے۔'.
ٹیمپلیٹ اور پائپ لائن
لوڈ ٹیسٹ کے انعقاد کے لیے ٹیمپلیٹ کی ایک مثال پروجیکٹ میں دستیاب ہے۔ . میں آپ ٹیمپلیٹ استعمال کرنے کے لیے ہدایات پڑھ سکتے ہیں۔ ٹیمپلیٹ میں ہی (فائل ) اس بارے میں نوٹس موجود ہیں کہ ہر قدم کس چیز کے لیے ذمہ دار ہے۔
ٹیمپلیٹ بہت آسان ہے اور اوپر دیے گئے خاکے میں بیان کردہ لوڈ ٹیسٹنگ کے تین مراحل کو ظاہر کرتا ہے: رپورٹس کی تیاری، جانچ اور شائع کرنا۔ اس کے ذمہ دار : تیار کریں، ٹیسٹ کریں اور رپورٹ کریں۔.
- اسٹیج ٹیسٹ کے اہداف کو پہلے سے ترتیب دینے یا ان کی دستیابی کو چیک کرنے کے لیے استعمال کیا جانا چاہیے۔ لوڈ ذرائع کے لیے ماحول کو ترتیب دینے کی ضرورت نہیں ہے، وہ ڈوکر امیجز کے طور پر پہلے سے بنائے گئے ہیں اور ڈاکر رجسٹری میں پوسٹ کیے گئے ہیں: ٹیسٹ کے مرحلے پر صرف مطلوبہ ورژن کی وضاحت کریں۔ لیکن آپ انہیں دوبارہ بنا سکتے ہیں اور اپنی ترمیم شدہ تصاویر بنا سکتے ہیں۔
- اسٹیج لوڈ سورس کی وضاحت کرنے، ٹیسٹ چلانے، اور ٹیسٹ کے نمونے اسٹور کرنے کے لیے استعمال کیا جاتا ہے۔ آپ لوڈ کا کوئی بھی ذریعہ منتخب کر سکتے ہیں: Yandex.Tank، Apache JMeter، آپ کا اپنا، یا سب ایک ساتھ۔ غیر ضروری ذرائع کو غیر فعال کرنے کے لیے، صرف تبصرہ کریں یا کام کو حذف کریں۔ لوڈ ذرائع کے لیے داخلے کے مقامات:
- Yandex.Tank کے لیے لانچ پیرامیٹرز میں بیان کیے گئے ہیں۔,
- اپاچی جے میٹر اسٹارٹ اپ پیرامیٹرز فائل میں بتائے گئے ہیں۔ .
نوٹ: اسمبلی کنفیگریشن ٹیمپلیٹ کا استعمال CI سسٹم کے ساتھ تعامل قائم کرنے کے لیے کیا جاتا ہے اور اس میں ٹیسٹ منطق کی جگہ کا مطلب نہیں ہے۔ ٹیسٹ کے لیے، انٹری پوائنٹ کی وضاحت کی گئی ہے، جہاں کنٹرول باش اسکرپٹ واقع ہے۔ ٹیسٹ چلانے، رپورٹیں تیار کرنے، اور ٹیسٹ اسکرپٹس کا طریقہ خود QA انجینئرز کے ذریعے لاگو کیا جانا چاہیے۔ ڈیمو میں، دونوں لوڈ ذرائع کے لیے، Yandex مین پیج کی درخواست کو آسان ترین ٹیسٹ کے طور پر استعمال کیا جاتا ہے۔ سکرپٹ اور ٹیسٹ پیرامیٹرز ڈائریکٹری میں ہیں .
- اسٹیج پر آپ کو یہ بتانے کی ضرورت ہے کہ ٹیسٹ کے مرحلے پر حاصل کردہ ٹیسٹ کے نتائج کو بیرونی ذخیرہ میں کیسے شائع کیا جائے، مثال کے طور پر GitLab صفحات یا خصوصی رپورٹنگ سسٹمز پر۔ GitLab صفحات کا تقاضہ ہے کہ ./public ڈائریکٹری غیر خالی ہو اور ٹیسٹ مکمل ہونے کے بعد کم از کم ایک index.html فائل پر مشتمل ہو۔ آپ GitLab پیجز سروس کی باریکیوں کے بارے میں پڑھ سکتے ہیں۔ .
ڈیٹا ایکسپورٹ کرنے کے طریقے کی مثالیں:
- JMeter سے ,
- Yandex.Tank سے .
سیٹ اپ ہدایات پوسٹ کرنا:
- ایچ ٹی ایم ایل کے اعدادوشمار ,
- InfluxDB اور پھر .
ڈیمو مثال میں، لوڈ ٹیسٹ اور لوڈ کے دو ذرائع والی پائپ لائن (آپ غیر ضروری کو غیر فعال کر سکتے ہیں) اس طرح نظر آتی ہے:
Apache JMeter خود ایک HTML رپورٹ بنا سکتا ہے، اس لیے اسے معیاری ٹولز کا استعمال کرتے ہوئے GitLab صفحات میں محفوظ کرنا زیادہ منافع بخش ہے۔ Apache JMeter رپورٹ اس طرح دکھتی ہے:
Yandex.Tank کی ڈیمو مثال میں، آپ کو صرف نظر آئے گا۔ GitLab صفحات کے سیکشن میں۔ ٹیسٹنگ کے دوران، ٹینک نتائج کو InfluxDB ڈیٹا بیس میں محفوظ کر سکتا ہے، اور وہاں سے انہیں دکھایا جا سکتا ہے، مثال کے طور پر، Grafana میں (کنفیگریشن فائل میں کی جاتی ہے۔ )۔ ٹانک کی رپورٹ گرافانا میں اس طرح نظر آتی ہے:
خلاصہ
مضمون میں، میں نے "لوڈ ٹیسٹنگ بطور سروس" (لوڈ ٹیسٹنگ بطور سروس) کے تصور کے بارے میں بات کی۔ بنیادی خیال یہ ہے کہ لوڈ ایجنٹس کے پہلے سے ترتیب شدہ پولز، لوڈ سورسز کی ڈاکر امیجز، رپورٹنگ سسٹمز اور ایک پائپ لائن جو انہیں GitLab CI میں ایک سادہ .gitlab-ci.yml ٹیمپلیٹ کی بنیاد پر یکجا کرتی ہے، کا بنیادی ڈھانچہ استعمال کرنا ہے۔ )۔ یہ سب آٹومیشن انجینئرز کی ایک چھوٹی ٹیم کے ذریعہ سپورٹ کیا جاتا ہے اور پروڈکٹ ٹیموں کی درخواست پر نقل کیا جاتا ہے۔ مجھے امید ہے کہ اس سے آپ کی کمپنی میں اسی طرح کی اسکیم تیار کرنے اور اس پر عمل درآمد کرنے میں مدد ملے گی۔ توجہ کے لئے شکریہ!
PS میں اپنی کمپنی میں سروس کے طور پر لوڈ ٹیسٹنگ کے تصور کو نافذ کرنے کے لیے تکنیکی مدد کے لیے اپنے ساتھیوں، سرگئی قربانوف اور نکولائی یوسیو کا بہت شکریہ کہنا چاہتا ہوں۔
مصنف: --.نائب n مثبت ٹیکنالوجیز میں ٹیکنالوجی اور ترقی کے عمل (DevOps) کے سربراہ
ماخذ: www.habr.com