پہلا حصہ - .
صورتحال کا تصور کریں۔ آپ کو نئی فعالیت تیار کرنے کا کام درپیش ہے۔ آپ کے پاس اپنے پیشروؤں کی ترقی ہے۔ اگر ہم فرض کر لیں کہ آپ کی کوئی اخلاقی ذمہ داری نہیں ہے تو آپ کیا کریں گے؟
اکثر، تمام پرانی پیش رفت بھول جاتے ہیں اور سب کچھ دوبارہ شروع ہوتا ہے. کوئی بھی کسی دوسرے کے کوڈ کو کھودنا پسند نہیں کرتا، لیکن اگر آپ کے پاس وقت ہے، تو کیوں نہ اپنا نظام خود بنانا شروع کر دیں؟ یہ ایک عام طریقہ ہے، اور یہ بڑی حد تک درست ہے۔ لیکن ہمارے پروجیکٹ میں ہم نے اسے غلط کیا۔ ہم نے اپنے پیشرووں سے utPLSQL پر یونٹ ٹیسٹ میں ہونے والی پیش رفت پر مستقبل کے خودکار ٹیسٹنگ سسٹم کی بنیاد رکھی، اور پھر کئی متوازی سمتوں میں کام کرنے گئے۔
- پرانے یونٹ ٹیسٹ کی بحالی۔ بحالی کا مطلب ہے ٹیسٹوں کو لائلٹی سسٹم کی موجودہ حالت کے مطابق ڈھالنا اور ٹیسٹوں کو utPLSQL معیارات کے مطابق ڈھالنا۔
- کسی مسئلے کو اس بات کی سمجھ کے ساتھ حل کرنا کہ اصل میں کیا، کون سے طریقے اور عمل آٹو ٹیسٹ کے ساتھ احاطہ کیے گئے ہیں۔ آپ کو یا تو اس معلومات کو اپنے ذہن میں رکھنا چاہیے، یا براہ راست آٹو ٹیسٹ کوڈ کی بنیاد پر نتیجہ اخذ کرنا چاہیے۔ لہذا، ہم نے ایک کیٹلاگ بنانے کا فیصلہ کیا. ہم نے ہر آٹو ٹیسٹ کے لیے ایک منفرد یادداشت کا کوڈ تفویض کیا، ایک تفصیل اور ریکارڈ کی ترتیبات بنائی (مثال کے طور پر، اسے کن حالات میں لانچ کیا جانا چاہیے، یا اگر ٹیسٹ لانچ ناکام ہو جاتا ہے تو کیا ہونا چاہیے)۔ بنیادی طور پر، ہم نے آٹو ٹیسٹس کے بارے میں میٹا ڈیٹا کو آباد کیا اور اس میٹا ڈیٹا کو معیاری utPLSQL اسکیما ٹیبلز میں رکھا۔
- توسیعی حکمت عملی کی وضاحت کرنا، یعنی فعالیت کا انتخاب جو خودکار ٹیسٹ کے ذریعے تصدیق کے تابع ہے۔ ہم نے تین چیزوں پر توجہ دینے کا فیصلہ کیا: نئے نظام میں بہتری، پیداوار کے واقعات، اور اہم نظام کے عمل۔ اس طرح، ہم ریلیز کے ساتھ متوازی طور پر ترقی کر رہے ہیں، اس کے اعلیٰ معیار کو یقینی بنا رہے ہیں، بیک وقت رجعت کے دائرہ کار کو بڑھا رہے ہیں اور اہم جگہوں پر سسٹم کی وشوسنییتا کو یقینی بنا رہے ہیں۔ اس طرح کی پہلی رکاوٹ چیک پر چھوٹ اور بونس کی تقسیم کا عمل تھا۔
- قدرتی طور پر، ہم نے نئے آٹو ٹیسٹ تیار کرنا شروع کر دیے۔ ریلیز کے پہلے کاموں میں سے ایک لائلٹی سسٹم کے پہلے سے طے شدہ نمونوں کی کارکردگی کا جائزہ لینا تھا۔ ہمارے پروجیکٹ میں سختی سے طے شدہ SQL سوالات کا ایک بلاک ہے جو شرائط کی بنیاد پر کلائنٹس کا انتخاب کرتا ہے۔ مثال کے طور پر، ان تمام صارفین کی فہرست حاصل کریں جن کی آخری خریداری کسی مخصوص شہر میں ہوئی تھی، یا ان صارفین کی فہرست حاصل کریں جن کی خریداری کی اوسط رقم ایک خاص قدر سے زیادہ ہے۔ تحریری آٹو ٹیسٹ کے بعد، ہم نے پہلے سے طے شدہ نمونے چیک کیے، بینچ مارک کارکردگی کے پیرامیٹرز کو ریکارڈ کیا، اور اس کے علاوہ ہمارے پاس لوڈ ٹیسٹنگ بھی تھی۔
- آٹوٹیسٹ کے ساتھ کام کرنا آسان ہونا چاہیے۔. دو سب سے عام کارروائیاں آٹوٹیسٹ چلانا اور ٹیسٹ ڈیٹا بنانا ہیں۔ اس طرح ہمارے سسٹم میں دو معاون ماڈیول نمودار ہوئے: ایک لانچ ماڈیول اور ایک ڈیٹا جنریشن ماڈیول۔
لانچر کو ایک متن ان پٹ پیرامیٹر کے ساتھ ایک عالمگیر طریقہ کار کے طور پر پیش کیا جاتا ہے۔ ایک پیرامیٹر کے طور پر، آپ آٹوٹیسٹ میمونک کوڈ، پیکیج کا نام، ٹیسٹ کا نام، آٹوٹیسٹ سیٹنگ، یا ایک محفوظ مطلوبہ لفظ پاس کر سکتے ہیں۔ طریقہ کار تمام آٹو ٹیسٹس کو منتخب کرتا ہے اور چلاتا ہے جو شرائط کو پورا کرتے ہیں۔
ڈیٹا جنریشن ماڈیول کو ایک پیکج کی شکل میں پیش کیا گیا ہے جس میں ٹیسٹ کے تحت سسٹم کی ہر چیز کے لیے (ڈیٹا بیس میں ایک ٹیبل)، ایک خاص طریقہ کار بنایا گیا ہے جو وہاں ڈیٹا داخل کرتا ہے۔ اس طریقہ کار میں، پہلے سے طے شدہ اقدار کو زیادہ سے زیادہ بھرا جاتا ہے، جو انگلی کے کلک پر لفظی طور پر اشیاء کی تخلیق کو یقینی بناتا ہے۔ اور استعمال میں آسانی کے لیے، تیار کردہ ڈیٹا کے لیے ٹیمپلیٹس بنائے گئے۔ مثال کے طور پر، ٹیسٹ فون اور مکمل خریداری کے ساتھ ایک مخصوص عمر کا کلائنٹ بنائیں۔
- آٹوٹیسٹ شروع ہونا چاہیے اور ایسے وقت میں چلنا چاہیے جو آپ کے سسٹم کے لیے قابل قبول ہو۔ لہذا، روزانہ رات کے آغاز کا اہتمام کیا گیا تھا، جس کے نتائج کی بنیاد پر نتائج کی رپورٹ تیار کی جاتی ہے اور کارپوریٹ میل کے ذریعے پوری ترقیاتی ٹیم کو بھیجی جاتی ہے۔ پرانے آٹو ٹیسٹس کو بحال کرنے اور نئے بنانے کے بعد، کل آپریٹنگ ٹائم 30 منٹ تھا۔ یہ کارکردگی سب کے لیے موزوں تھی، کیونکہ لانچ کام کے اوقات سے باہر ہوئی تھی۔
لیکن ہمیں کام کی رفتار کو بہتر بنانے پر کام کرنا تھا۔ پیداوار میں وفاداری کا نظام رات کو اپ ڈیٹ ہوتا ہے۔ ریلیز میں سے ایک کے حصے کے طور پر، ہمیں رات کو فوری تبدیلیاں کرنی پڑیں۔ صبح تین بجے آٹو ٹیسٹ کے نتائج کا آدھا گھنٹہ انتظار کرنے سے رہائی کا ذمہ دار شخص خوش نہیں ہوا (الیکسے واسیوکوف کو پرجوش سلام!) اور اگلی صبح ہمارے سسٹم کے لیے بہت سے مہربان الفاظ کہے گئے۔ لیکن اس کے نتیجے میں کام کے لیے 5 منٹ کا معیار قائم ہوا۔
کارکردگی کو تیز کرنے کے لیے، ہم نے دو طریقے استعمال کیے: آٹو ٹیسٹ تین متوازی دھاگوں میں چلنے لگے، خوش قسمتی سے ہمارے لائلٹی سسٹم کے فن تعمیر کی وجہ سے یہ بہت آسان ہے۔ اور ہم نے اس نقطہ نظر کو ترک کر دیا جہاں آٹوٹیسٹ اپنے لیے ٹیسٹ ڈیٹا نہیں بناتا، لیکن سسٹم میں کچھ مناسب تلاش کرنے کی کوشش کرتا ہے۔ تبدیلیاں کرنے کے بعد، کل آپریٹنگ وقت 3-4 منٹ تک کم کر دیا گیا۔
- خودکار ٹیسٹ کے ساتھ ایک پروجیکٹ کو مختلف اسٹینڈز پر تعینات کرنے کے قابل ہونا چاہیے۔ ہمارے سفر کے آغاز میں، اپنے بیچ کی فائلیں لکھنے کی کوشش کی گئی، لیکن یہ واضح ہو گیا کہ خود سے لکھی ہوئی خودکار تنصیب مکمل ہولناک تھی، اور ہم نے صنعتی حل کی طرف رخ کیا۔ اس حقیقت کی وجہ سے کہ پروجیکٹ میں بہت سارے ڈائریکٹ کوڈ ہیں (سب سے پہلے، ہم آٹوٹیسٹ کوڈ کو اسٹور کرتے ہیں) اور بہت کم ڈیٹا (بنیادی ڈیٹا آٹو ٹیسٹ کے بارے میں میٹا ڈیٹا ہے)، Liquibase پروجیکٹ میں عمل درآمد بہت آسان نکلا۔
یہ ایک اوپن سورس، ڈیٹا بیس سے آزاد لائبریری ہے جو ڈیٹا بیس اسکیما تبدیلیوں کو ٹریک کرنے، ان کا انتظام کرنے اور نافذ کرنے کے لیے ہے۔ کمانڈ لائن یا اپاچی ماون جیسے فریم ورک کے ذریعے منظم کیا جاتا ہے۔ Liquibase کے آپریشن کے اصول بہت آسان ہے. ہمارے پاس ایک پروجیکٹ کو ایک خاص طریقے سے ترتیب دیا گیا ہے، جس میں تبدیلیاں یا اسکرپٹ شامل ہیں جنہیں ٹارگٹ سرور تک پہنچانے کی ضرورت ہے، اور فائلوں کو کنٹرول کرتی ہیں جو یہ طے کرتی ہیں کہ ان تبدیلیوں کو کس ترتیب میں اور کن پیرامیٹرز کے ساتھ انسٹال کیا جانا چاہیے۔
ڈی بی ایم ایس کی سطح پر، ایک خاص ٹیبل بنایا جاتا ہے جس میں لیکوبیس رول اوور لاگ کو اسٹور کرتا ہے۔ ہر تبدیلی میں ایک حسابی ہیش ہوتا ہے، جس کا ڈیٹا بیس میں پروجیکٹ اور ریاست کے درمیان ہر بار موازنہ کیا جاتا ہے۔ Liquibase کی بدولت، ہم آسانی سے اپنے سسٹم میں کسی بھی سرکٹ میں تبدیلیاں کر سکتے ہیں۔ آٹو ٹیسٹ اب ٹیسٹ اور ریلیز سرکٹس کے ساتھ ساتھ کنٹینرز (ڈویلپرز کے ذاتی سرکٹس) پر شروع کیے گئے ہیں۔
تو آئیے اپنے یونٹ ٹیسٹنگ سسٹم کے استعمال کے نتائج کے بارے میں بات کرتے ہیں۔
- یقیناً، سب سے پہلے، ہمیں یقین ہے کہ ہم نے بہتر سافٹ ویئر تیار کرنا شروع کر دیا ہے۔ آٹو ٹیسٹ روزانہ شروع کیے جاتے ہیں اور ہر ریلیز میں درجنوں غلطیاں پائی جاتی ہیں۔ مزید یہ کہ، ان میں سے کچھ غلطیاں صرف بالواسطہ طور پر اس فعالیت سے متعلق ہیں جسے ہم واقعی تبدیل کرنا چاہتے تھے۔ سنگین شکوک و شبہات ہیں کہ یہ غلطیاں دستی جانچ سے پائی گئیں۔
- ٹیم کو اب یقین ہے کہ مخصوص فعالیت صحیح طریقے سے کام کر رہی ہے... سب سے پہلے، یہ ہمارے اہم عمل سے متعلق ہے۔ مثال کے طور پر، گزشتہ چھ مہینوں کے دوران ہمیں ریلیز کی تبدیلیوں کے باوجود رسیدوں پر چھوٹ اور بونس کی تقسیم میں کوئی پریشانی نہیں ہوئی، حالانکہ پچھلے ادوار میں کچھ فریکوئنسی کے ساتھ غلطیاں ہوئی تھیں۔
- ہم ٹیسٹنگ کی تکرار کی تعداد کو کم کرنے میں کامیاب ہو گئے۔ اس حقیقت کی وجہ سے کہ آٹوٹیسٹ نئی فعالیت کے لیے لکھے جاتے ہیں، تجزیہ کار اور پارٹ ٹائم ٹیسٹرز کو اعلیٰ معیار کا کوڈ ملتا ہے، کیونکہ یہ پہلے ہی چیک کیا گیا ہے.
- خودکار جانچ میں ہونے والی کچھ پیشرفتوں کو ڈویلپرز استعمال کرتے ہیں۔ مثال کے طور پر، کنٹینرز پر ٹیسٹ ڈیٹا آبجیکٹ جنریشن ماڈیول کا استعمال کرتے ہوئے بنایا جاتا ہے۔
- یہ ضروری ہے کہ ہم نے ڈویلپرز کی طرف سے خودکار ٹیسٹنگ سسٹم کی "قبولیت" تیار کی ہو۔ ایک سمجھ ہے کہ یہ اہم اور مفید ہے۔ لیکن میں اپنے تجربے سے کہہ سکتا ہوں کہ یہ معاملہ بہت دور ہے۔ آٹو ٹیسٹس کو لکھنے کی ضرورت ہے، انہیں سپورٹ کرنے اور تیار کرنے کی ضرورت ہے، نتائج کا تجزیہ کرنا ضروری ہے، اور اکثر اوقات یہ وقت کے اخراجات اس کے قابل نہیں ہوتے ہیں۔ پروڈکشن میں جانا اور وہاں کے مسائل سے نمٹنا بہت آسان ہے۔ یہاں، ڈیولپرز قطار میں کھڑے ہوتے ہیں اور ہم سے کہتے ہیں کہ وہ آٹو ٹیسٹ کے ساتھ اپنی فعالیت کا احاطہ کریں۔
آگے کیا ہے
آئیے خودکار ٹیسٹنگ پروجیکٹ کے ترقیاتی منصوبوں کے بارے میں بات کرتے ہیں۔
بلاشبہ، جب تک اسپورٹ ماسٹر کا لائلٹی سسٹم زندہ ہے اور ترقی کرتا رہتا ہے، آٹو ٹیسٹس کو تقریباً لامتناہی تیار کرنا بھی ممکن ہے۔ لہذا، ترقی کی اہم سمت کوریج کے علاقے کو بڑھا رہا ہے.
جیسے جیسے آٹو ٹیسٹس کی تعداد میں اضافہ ہوتا جائے گا، ان کا کل آپریٹنگ وقت مسلسل بڑھتا جائے گا، اور ہمیں دوبارہ کارکردگی کے مسئلے پر واپس جانا پڑے گا۔ زیادہ تر امکان، حل متوازی دھاگوں کی تعداد میں اضافہ کرنا ہو گا۔
لیکن یہ ترقی کے واضح طریقے ہیں۔ اگر ہم کسی غیر معمولی چیز کے بارے میں بات کرتے ہیں تو ہم درج ذیل کو نمایاں کرتے ہیں:
- فی الحال، آٹو ٹیسٹ کا انتظام DBMS سطح پر کیا جاتا ہے، یعنی کامیاب کام کے لیے PL/SQL کا علم ضروری ہے۔ اگر ضروری ہو تو، سسٹم مینجمنٹ (مثال کے طور پر، میٹا ڈیٹا لانچ کرنا یا تخلیق کرنا)، آپ جینکنز یا اس سے ملتی جلتی کوئی چیز استعمال کر کے کسی قسم کا ایڈمن پینل بنا سکتے ہیں۔
- ہر کوئی مقداری اور معیاری اشارے سے محبت کرتا ہے۔ خودکار جانچ کے لیے، ایسا یونیورسل انڈیکیٹر کوڈ کوریج یا کوڈ کوریج میٹرک ہے۔ اس اشارے کا استعمال کرتے ہوئے، ہم اس بات کا تعین کر سکتے ہیں کہ ہمارے سسٹم کے کوڈ کا کتنا فیصد ٹیسٹ کے تحت آٹو ٹیسٹس کا احاطہ کرتا ہے۔ ورژن 12.2 سے شروع کرتے ہوئے، Oracle اس میٹرک کو شمار کرنے کی صلاحیت فراہم کرتا ہے اور معیاری DBMS_PLSQL_CODE_COVERAGE پیکیج کے استعمال کی پیشکش کرتا ہے۔
ہمارا آٹو ٹیسٹ سسٹم صرف ایک سال پرانا ہے اور شاید اب ہماری کوریج کا جائزہ لینے کا وقت آگیا ہے۔ میرے آخری پروجیکٹ میں (اسپورٹ ماسٹر پروجیکٹ نہیں) ایسا ہی ہوا۔ آٹو ٹیسٹس پر کام کرنے کے ایک سال بعد، انتظامیہ نے اس بات کا تعین کرنے کا کام مقرر کیا کہ ہم کتنے فیصد کوڈ کا احاطہ کرتے ہیں۔ 1% سے زیادہ کی کوریج کے ساتھ، انتظامیہ خوش ہو گی۔ ہم، ڈویلپرز، تقریباً 10% کے نتیجے کی توقع کرتے ہیں۔ ہم نے کوڈ کوریج انسٹال کی، اس کی پیمائش کی، اور 20% حاصل کیا۔ جشن منانے کے لیے، ہم انعام لینے گئے تھے، لیکن ہم اسے لینے کیسے گئے اور بعد میں کہاں گئے یہ ایک بالکل الگ کہانی ہے۔
- آٹو ٹیسٹس بے نقاب ویب سروسز کو چیک کر سکتے ہیں۔ اوریکل ہمیں یہ بہت اچھی طرح سے کرنے کی اجازت دیتا ہے، اور ہمیں مزید مسائل کا سامنا نہیں کرنا پڑے گا۔
- اور یقیناً، ہمارا خودکار ٹیسٹنگ سسٹم کسی دوسرے پروجیکٹ پر لاگو کیا جا سکتا ہے۔ ہمیں جو حل موصول ہوا ہے وہ عالمگیر ہے اور صرف اوریکل کے استعمال کی ضرورت ہے۔ میں نے سنا ہے کہ دوسرے اسپورٹ ماسٹر پروجیکٹس خودکار جانچ میں دلچسپی رکھتے ہیں اور شاید ہم ان کے پاس جائیں گے۔
نتائج
آئیے خلاصہ کرتے ہیں۔ Sportmaster میں لائلٹی سسٹم پروجیکٹ پر، ہم نے خودکار ٹیسٹنگ سسٹم کو لاگو کرنے کا انتظام کیا۔ یہ اسٹیفن فیورسٹین کے utPLSQL حل پر مبنی ہے۔ utPLSQL کے ارد گرد آٹو ٹیسٹ کوڈ اور معاون خود تحریری ماڈیولز ہیں: لانچ ماڈیول، ڈیٹا جنریشن ماڈیول اور دیگر۔ آٹو ٹیسٹ روزانہ شروع کیے جاتے ہیں اور سب سے اہم بات یہ ہے کہ وہ کام کرتے ہیں اور مفید ہیں۔ ہمیں یقین ہے کہ ہم نے اعلیٰ معیار کا سافٹ ویئر جاری کرنا شروع کر دیا ہے۔ ایک ہی وقت میں، نتیجہ حل عالمگیر ہے اور کسی بھی پروجیکٹ پر آزادانہ طور پر لاگو کیا جا سکتا ہے جہاں Oracle DBMS پر خودکار جانچ کا اہتمام کرنا ضروری ہو۔
پی ایس یہ مضمون بہت مخصوص نہیں ہے: بہت سارے متن ہیں اور عملی طور پر کوئی تکنیکی مثال نہیں ہے۔ اگر موضوع عام طور پر دلچسپ ہے، تو ہم اسے جاری رکھنے اور ایک تسلسل کے ساتھ واپس آنے کے لیے تیار ہیں، جہاں ہم آپ کو بتائیں گے کہ پچھلے چھ مہینوں میں کیا تبدیلی آئی ہے اور کوڈ کی مثالیں فراہم کریں گے۔
تبصرے لکھیں اگر ایسے نکات ہیں جن پر مستقبل میں زور دیا جانا چاہیے، یا ایسے سوالات جن کے لیے انکشاف ضروری ہے۔
سروے میں صرف رجسٹرڈ صارفین ہی حصہ لے سکتے ہیں۔ ، برائے مہربانی.
کیا ہم اس پر مزید لکھیں؟
-
ہاں ضرور
-
نہیں شکریہ
12 صارفین نے ووٹ دیا۔ 4 صارفین غیر حاضر رہے۔
ماخذ: www.habr.com