ارے حبر!
میرا نام Maxim Ponomarenko ہے اور میں Sportmaster میں ایک ڈویلپر ہوں۔ میرے پاس آئی ٹی کے شعبے میں 10 سال کا تجربہ ہے۔ اس نے اپنے کیریئر کا آغاز دستی ٹیسٹنگ میں کیا، پھر ڈیٹا بیس کی ترقی میں تبدیل ہو گیا۔ پچھلے 4 سالوں سے، ٹیسٹنگ اور ڈیولپمنٹ میں حاصل کردہ علم کو جمع کرتے ہوئے، میں DBMS کی سطح پر خودکار ٹیسٹنگ کر رہا ہوں۔
میں اسپورٹ ماسٹر ٹیم میں صرف ایک سال سے ہوں اور ایک بڑے پروجیکٹ پر خودکار جانچ تیار کر رہا ہوں۔ اپریل میں، Sportmaster Lab کے لڑکوں اور میں نے Krasnodar میں ایک کانفرنس میں بات کی، میری رپورٹ کا نام تھا "DBMS میں یونٹ ٹیسٹ" اور اب میں اسے آپ کے ساتھ شیئر کرنا چاہتا ہوں۔ بہت سارے متن ہوں گے، لہذا میں نے رپورٹ کو دو خطوط میں تقسیم کرنے کا فیصلہ کیا۔ پہلے میں، ہم عام طور پر آٹو ٹیسٹ اور ٹیسٹنگ کے بارے میں بات کریں گے، اور دوسرے میں، میں اپنے یونٹ ٹیسٹنگ سسٹم اور اس کے اطلاق کے نتائج پر مزید تفصیل سے بات کروں گا۔
سب سے پہلے، ایک چھوٹا سا بورنگ نظریہ. خودکار جانچ کیا ہے؟ یہ ٹیسٹنگ ہے جو سافٹ ویئر کے ذریعہ کی جاتی ہے، اور جدید IT میں یہ تیزی سے سافٹ ویئر کی ترقی میں استعمال ہوتی ہے۔ یہ اس حقیقت کی وجہ سے ہے کہ کمپنیاں بڑھ رہی ہیں، ان کے انفارمیشن سسٹم بڑھ رہے ہیں اور اس کے مطابق، فعالیت کی مقدار جس کو جانچنے کی ضرورت ہے بڑھ رہی ہے۔ دستی جانچ کا انعقاد دن بدن مہنگا ہوتا جا رہا ہے۔
میں نے ایک بڑی کمپنی میں کام کیا جس کی ریلیز ہر دو ماہ بعد آتی ہے۔ ایک ہی وقت میں، ایک درجن ٹیسٹرز کو دستی طور پر فعالیت کی جانچ کرنے پر پورا ایک مہینہ صرف ہوا۔ ڈیولپرز کی ایک چھوٹی ٹیم کی طرف سے آٹومیشن کے نفاذ کی بدولت، ہم ڈیڑھ سال میں ٹیسٹنگ کے وقت کو 2 ہفتوں تک کم کرنے میں کامیاب ہو گئے۔ ہم نے نہ صرف جانچ کی رفتار میں اضافہ کیا ہے بلکہ اس کے معیار کو بھی بہتر بنایا ہے۔ خودکار ٹیسٹ باقاعدگی سے شروع کیے جاتے ہیں اور وہ ہمیشہ ان میں شامل جانچ کے پورے کورس کو انجام دیتے ہیں، یعنی ہم انسانی عنصر کو خارج کرتے ہیں۔
جدید آئی ٹی کی خصوصیت یہ ہے کہ ایک ڈویلپر کو نہ صرف پروڈکٹ کوڈ لکھنے کی ضرورت پڑ سکتی ہے بلکہ اس کوڈ کو چیک کرنے والے یونٹ ٹیسٹ بھی لکھنا پڑ سکتا ہے۔
لیکن کیا ہوگا اگر آپ کا سسٹم بنیادی طور پر سرور منطق پر مبنی ہے؟ مارکیٹ میں کوئی آفاقی حل یا بہترین طریقہ کار نہیں ہے۔ ایک اصول کے طور پر، کمپنیاں اس مسئلے کو خود تحریری ٹیسٹنگ سسٹم بنا کر حل کرتی ہیں۔ یہ ہمارا اپنا لکھا ہوا خودکار ٹیسٹنگ سسٹم ہے جو ہمارے پروجیکٹ پر بنایا گیا تھا اور میں اپنی رپورٹ میں اس کے بارے میں بات کروں گا۔
وفاداری کی جانچ
سب سے پہلے، آئیے اس پروجیکٹ کے بارے میں بات کرتے ہیں جہاں ہم نے خودکار ٹیسٹنگ سسٹم لگایا تھا۔ ہمارا پروجیکٹ اسپورٹ ماسٹر لائلٹی سسٹم ہے (ویسے، ہم پہلے ہی اس کے بارے میں لکھ چکے ہیں۔ ).
اگر آپ کی کمپنی کافی بڑی ہے، تو آپ کے لائلٹی سسٹم میں تین معیاری خصوصیات ہوں گی:
- آپ کا سسٹم بہت زیادہ لوڈ ہو جائے گا۔
- آپ کے سسٹم میں کمپیوٹنگ کے پیچیدہ عمل ہوں گے۔
- آپ کے سسٹم کو فعال طور پر بہتر بنایا جائے گا۔
آئیے ترتیب سے چلتے ہیں... مجموعی طور پر، اگر ہم تمام Sportmaster برانڈز پر غور کریں، تو ہمارے پاس روس، یوکرین، چین، قازقستان اور بیلاروس میں 1000 سے زیادہ اسٹورز ہیں۔ ان اسٹورز میں روزانہ تقریباً 300 خریداریاں کی جاتی ہیں۔ یعنی ہر سیکنڈ میں 000-3 چیک ہمارے سسٹم میں داخل ہوتے ہیں۔ قدرتی طور پر، ہمارا وفاداری کا نظام بہت زیادہ بھرا ہوا ہے۔ اور چونکہ یہ فعال طور پر استعمال ہوتا ہے، ہمیں اس کے معیار کے اعلیٰ ترین معیارات فراہم کرنے چاہییں، کیونکہ سافٹ ویئر میں کسی بھی خرابی کا مطلب بڑا مالی، ساکھ اور دیگر نقصانات ہیں۔
ایک ہی وقت میں، Sportmaster سو سے زیادہ مختلف پروموشنز چلاتا ہے۔ پروموشنز کی ایک قسم ہے: پروڈکٹ پروموشنز ہیں، ہفتے کے دن کے لیے وقف ہیں، وہاں وہ ہیں جو ایک مخصوص اسٹور سے منسلک ہیں، وہاں رسید کی رقم کے لیے پروموشنز ہیں، سامان کی تعداد کے لیے ہیں۔ عام طور پر، برا نہیں. کلائنٹس کے پاس بونس اور پروموشنل کوڈ ہوتے ہیں جو خریداری کرتے وقت استعمال ہوتے ہیں۔ یہ سب اس حقیقت کی طرف لے جاتا ہے کہ کسی بھی حکم کا حساب لگانا ایک بہت ہی غیر معمولی کام ہے۔
آرڈر پروسیسنگ کو لاگو کرنے والا الگورتھم واقعی خوفناک اور پیچیدہ ہے۔ اور اس الگورتھم میں کوئی بھی تبدیلی کافی خطرناک ہے۔ ایسا لگتا تھا کہ سب سے زیادہ بظاہر معمولی تبدیلیاں کافی غیر متوقع اثرات کا باعث بن سکتی ہیں۔ لیکن یہ بالکل ایسے پیچیدہ کمپیوٹنگ عمل ہیں، خاص طور پر وہ جو کہ اہم فعالیت کو نافذ کرتے ہیں، جو آٹومیشن کے لیے بہترین امیدوار ہیں۔ اسی طرح کے درجنوں کیسز کو ہاتھ سے چیک کرنا بہت وقت طلب ہے۔ اور چونکہ عمل میں داخلے کا نقطہ تبدیل نہیں ہوتا ہے، اس لیے اسے ایک بار بیان کرنے کے بعد، آپ جلدی سے خودکار ٹیسٹ بنا سکتے ہیں اور یقین رکھ سکتے ہیں کہ فعالیت کام کرے گی۔
چونکہ ہمارا نظام فعال طور پر استعمال ہوتا ہے، اس لیے کاروبار آپ سے کچھ نیا چاہتا ہے، وقت کے ساتھ رہنا چاہتا ہے اور کسٹمر پر مبنی ہونا چاہتا ہے۔ ہمارے لائلٹی سسٹم میں ہر دو ماہ بعد ریلیز نکلتی ہے۔ اس کا مطلب یہ ہے کہ ہر دو ماہ بعد ہمیں پورے نظام کی مکمل رجعت کرنے کی ضرورت ہے۔ ایک ہی وقت میں، قدرتی طور پر، جیسا کہ کسی بھی جدید آئی ٹی میں، ترقی فوری طور پر ڈویلپر سے پیداوار کی طرف نہیں جاتی ہے۔ یہ ڈویلپر کے سرکٹ سے شروع ہوتا ہے، پھر یکے بعد دیگرے ٹیسٹ بینچ، رہائی، قبولیت سے گزرتا ہے اور تب ہی پیداوار میں ختم ہوتا ہے۔ کم از کم، ٹیسٹ اور ریلیز سرکٹس پر، ہمیں پورے سسٹم کی مکمل ریگریشن کرنے کی ضرورت ہے۔
بیان کردہ خصوصیات تقریباً کسی بھی وفاداری کے نظام کے لیے معیاری ہیں۔ آئیے اپنے پروجیکٹ کی خصوصیات کے بارے میں بات کرتے ہیں۔
تکنیکی طور پر، ہمارے لائلٹی سسٹم کی 90% منطق سرور پر مبنی ہے اور Oracle پر لاگو ہوتی ہے۔ ڈیلفی میں ایک کلائنٹ سامنے آیا ہے، جو کام کی جگہ کے خودکار منتظم کا کام انجام دیتا ہے۔ بیرونی ایپلیکیشنز (مثال کے طور پر ایک ویب سائٹ) کے لیے بے نقاب ویب سروسز موجود ہیں۔ لہذا، یہ بہت منطقی ہے کہ اگر ہم خودکار جانچ کا نظام لگاتے ہیں، تو ہم اسے اوریکل پر کریں گے۔
اسپورٹ ماسٹر میں وفاداری کا نظام 7 سال سے زیادہ عرصے سے موجود ہے اور اسے سنگل ڈویلپرز نے بنایا تھا... ان 7 سالوں کے دوران ہمارے پروجیکٹ پر ڈیولپرز کی اوسط تعداد 3-4 افراد تھی۔ لیکن پچھلے ایک سال کے دوران، ہماری ٹیم میں نمایاں اضافہ ہوا ہے، اور اب اس پروجیکٹ پر 10 لوگ کام کر رہے ہیں۔ یعنی ایسے لوگ پروجیکٹ میں آتے ہیں جو عام کاموں، عمل اور فن تعمیر سے واقف نہیں ہوتے۔ اور اس بات کا خطرہ بڑھ جاتا ہے کہ ہم غلطیوں سے چھوٹ جائیں گے۔
اس پروجیکٹ کی خصوصیت اسٹاف یونٹ کے طور پر سرشار ٹیسٹرز کی عدم موجودگی ہے۔ یقیناً جانچ ہوتی ہے، لیکن جانچ ان کی دیگر اہم ذمہ داریوں کے علاوہ تجزیہ کاروں کے ذریعے کی جاتی ہے: کاروباری صارفین، صارفین کے ساتھ بات چیت کرنا، نظام کی ضروریات کو تیار کرنا وغیرہ۔ اس حقیقت کے باوجود کہ جانچ بہت اعلیٰ معیار کی ہے (اس کا تذکرہ کرنا خاص طور پر مناسب ہے، کیونکہ کچھ تجزیہ کار اس رپورٹ کو دیکھ سکتے ہیں)، کسی ایک چیز پر مہارت اور ارتکاز کی تاثیر کو منسوخ نہیں کیا گیا ہے۔ .
مندرجہ بالا تمام چیزوں کو مدنظر رکھتے ہوئے، ڈیلیور شدہ پروڈکٹ کے معیار کو بہتر بنانے اور ترقی کے وقت کو کم کرنے کے لیے، کسی پروجیکٹ پر خودکار جانچ کا خیال بہت منطقی لگتا ہے۔ اور وفاداری کے نظام کے وجود کے مختلف مراحل میں، انفرادی ڈویلپرز نے اپنے کوڈ کو یونٹ ٹیسٹ کے ساتھ کور کرنے کی کوشش کی۔ مجموعی طور پر یہ کافی حد تک منقطع عمل تھا، جس میں ہر کوئی اپنے فن تعمیر اور طریقے استعمال کر رہا تھا۔ حتمی نتائج یونٹ ٹیسٹوں کے لیے عام تھے: ٹیسٹ تیار کیے گئے، کچھ وقت کے لیے استعمال کیے گئے، ایک ورژن والی فائل اسٹوریج میں محفوظ کیے گئے، لیکن کسی وقت وہ چلنا بند ہو گئے اور بھول گئے۔ سب سے پہلے، یہ اس حقیقت کی وجہ سے تھا کہ ٹیسٹ ایک مخصوص اداکار کے ساتھ زیادہ منسلک تھے، اور اس منصوبے سے نہیں.
utPLSQL بچاؤ کے لیے آتا ہے۔
کیا آپ سٹیفن فیورسٹین کے بارے میں کچھ جانتے ہیں؟
یہ ایک ذہین آدمی ہے جس نے اپنے کیریئر کا ایک طویل حصہ Oracle اور PL/SQL کے ساتھ کام کرنے کے لیے وقف کیا، اور اس موضوع پر کافی بڑی تعداد میں کام لکھا ہے۔ ان کی ایک مشہور کتاب کا نام ہے: "Oracle PL/SQL۔ پیشہ ور افراد کے لیے۔" یہ اسٹیفن تھا جس نے utPLSQL حل تیار کیا، یا جیسا کہ اس کا مطلب ہے، Oracle PL/SQL کے لیے یونٹ ٹیسٹنگ فریم ورک۔ utPLSQL حل 2016 میں بنایا گیا تھا، لیکن اس پر فعال طور پر کام جاری ہے اور نئے ورژن جاری کیے گئے ہیں۔ رپورٹنگ کے وقت، تازہ ترین ورژن 24 مارچ 2019 کا ہے۔
یہ کیا ہے. یہ ایک علیحدہ اوپن سورس پروجیکٹ ہے۔ اس کا وزن کچھ میگا بائٹس ہے، بشمول مثالیں اور دستاویزات۔ جسمانی طور پر، یہ ORACLE ڈیٹا بیس میں یونٹ ٹیسٹنگ کو منظم کرنے کے لیے پیکجوں اور جدولوں کے سیٹ کے ساتھ ایک الگ اسکیما ہے۔ تنصیب میں چند سیکنڈ لگتے ہیں۔ utPLSQL کی ایک مخصوص خصوصیت اس کے استعمال میں آسانی ہے۔
عالمی سطح پر، utPLSQL یونٹ ٹیسٹ چلانے کا ایک طریقہ کار ہے، جہاں یونٹ ٹیسٹ کو عام اوریکل بیچ کے طریقہ کار کے طور پر سمجھا جاتا ہے، جس کی تنظیم کچھ اصولوں پر عمل کرتی ہے۔ لانچ کرنے کے علاوہ، utPLSQL آپ کے تمام ٹیسٹ رنز کا لاگ اسٹور کرتا ہے، اور اس کے پاس اندرونی رپورٹنگ سسٹم بھی ہے۔
آئیے ایک مثال دیکھتے ہیں کہ یونٹ ٹیسٹ کوڈ کیسا لگتا ہے، اس تکنیک کا استعمال کرتے ہوئے لاگو کیا گیا ہے۔
لہذا، سکرین یونٹ ٹیسٹ کے ساتھ ایک عام پیکج کی تفصیلات کا کوڈ دکھاتی ہے۔ لازمی تقاضے کیا ہیں؟ پیکٹ پر "utp_" کا سابقہ ہونا ضروری ہے۔ ٹیسٹ کے ساتھ تمام طریقہ کار کا بالکل ایک جیسا سابقہ ہونا چاہیے۔ پیکیج میں دو معیاری طریقہ کار پر مشتمل ہونا چاہیے: "utp_setup" اور "utp_teardown"۔ پہلا طریقہ کار ہر یونٹ ٹیسٹ کو دوبارہ شروع کرکے کہا جاتا ہے، دوسرا - لانچ کے بعد۔
"utp_setup"، ایک اصول کے طور پر، ہمارے سسٹم کو یونٹ ٹیسٹ چلانے کے لیے تیار کرتا ہے، مثال کے طور پر، ٹیسٹ ڈیٹا بنانا۔ "utp_teardown" - اس کے برعکس، سب کچھ اصل سیٹنگز پر واپس آجاتا ہے اور لانچ کے نتائج کو ری سیٹ کرتا ہے۔
یہاں سب سے آسان یونٹ ٹیسٹ کی ایک مثال ہے جو ہمارے لائلٹی سسٹم کے لیے درج کردہ کسٹمر فون نمبر کو معیاری شکل میں معمول پر لانے کی جانچ کرتا ہے۔ یونٹ ٹیسٹ کے ساتھ طریقہ کار کیسے لکھنا ہے اس بارے میں کوئی لازمی معیار نہیں ہے۔ ایک اصول کے طور پر، ٹیسٹ کے تحت نظام کے طریقہ کار پر کال کی جاتی ہے، اور اس طریقہ سے واپس آنے والے نتائج کا حوالہ ایک سے موازنہ کیا جاتا ہے۔ یہ ضروری ہے کہ حوالہ کے نتائج اور حاصل کردہ کا موازنہ معیاری utPLSQL طریقوں سے کیا جائے۔
یونٹ ٹیسٹ میں کئی چیک ہو سکتے ہیں۔ جیسا کہ مثال سے دیکھا جا سکتا ہے، ہم فون نمبر کو معمول پر لانے اور ہر کال کے بعد نتیجہ کا جائزہ لینے کے لیے آزمائشی طریقے سے لگاتار چار کالیں کرتے ہیں۔ یونٹ ٹیسٹ تیار کرتے وقت، آپ کو اس بات کا خیال رکھنا چاہیے کہ ایسے چیک ہیں جو سسٹم پر کسی بھی طرح سے اثر انداز نہیں ہوتے ہیں، اور کچھ کے بعد آپ کو سسٹم کی اصل حالت میں واپس آنے کی ضرورت ہے۔
مثال کے طور پر، پیش کردہ یونٹ ٹیسٹ میں ہم صرف ان پٹ فون نمبر کو فارمیٹ کرتے ہیں، جو کسی بھی طرح سے لائلٹی سسٹم کو متاثر نہیں کرتا ہے۔
اور اگر ہم نیا کلائنٹ بنانے کے طریقہ کار کو استعمال کرتے ہوئے یونٹ ٹیسٹ لکھتے ہیں، تو ہر ٹیسٹ کے بعد سسٹم میں ایک نیا کلائنٹ بن جائے گا، جو کہ ٹیسٹ کے بعد کے آغاز کو متاثر کر سکتا ہے۔
اس طرح یونٹ ٹیسٹ چلائے جاتے ہیں۔ لانچ کے دو ممکنہ اختیارات ہیں: مخصوص پیکیج سے تمام یونٹ ٹیسٹ چلانا یا مخصوص پیکیج میں مخصوص یونٹ ٹیسٹ چلانا۔
اندرونی رپورٹنگ سسٹم کی مثال یہی ہے۔ یونٹ ٹیسٹ کے نتائج کی بنیاد پر، utPLSQL ایک چھوٹی رپورٹ بناتا ہے۔ اس میں ہم ہر مخصوص چیک کا نتیجہ اور یونٹ ٹیسٹ کا مجموعی نتیجہ دیکھتے ہیں۔
آٹو ٹیسٹ کے 6 اصول
وفاداری کے نظام کی خودکار جانچ کے لیے ایک نیا نظام بنانا شروع کرنے سے پہلے، انتظامیہ کے ساتھ مل کر، ہم نے ان اصولوں کا تعین کیا جن کی تعمیل ہمارے مستقبل کے خودکار ٹیسٹوں کو کرنی چاہیے۔
- آٹو ٹیسٹس کو موثر ہونا چاہیے اور مفید ہونا چاہیے۔ ہمارے پاس شاندار ڈویلپرز ہیں، جن کا تذکرہ ضروری ہے، کیونکہ ان میں سے کچھ شاید یہ رپورٹ دیکھیں گے، اور وہ شاندار کوڈ لکھتے ہیں۔ لیکن یہاں تک کہ ان کا شاندار کوڈ بھی کامل نہیں ہے اور اس میں غلطیاں ہیں، ہیں اور رہیں گی۔ ان غلطیوں کو تلاش کرنے کے لیے آٹو ٹیسٹ کی ضرورت ہے۔ اگر یہ معاملہ نہیں ہے، تو یا تو ہم خراب آٹو ٹیسٹ لکھ رہے ہیں، یا ہم ایک مردہ علاقے میں آگئے ہیں جو، اصولی طور پر، تیار نہیں کیا جا رہا ہے. دونوں صورتوں میں، ہم کچھ غلط کر رہے ہیں، اور ہمارا نقطہ نظر محض کوئی معنی نہیں رکھتا۔
- آٹو ٹیسٹ کا استعمال کیا جانا چاہئے. سافٹ ویئر پروڈکٹ کو لکھنے پر بہت زیادہ وقت اور محنت صرف کرنا، اسے ایک ذخیرہ میں رکھنا اور بھول جانا کوئی معنی نہیں رکھتا۔ ٹیسٹ چلائے جائیں، اور جتنا ممکن ہو سکے باقاعدگی سے چلائیں۔
- آٹو ٹیسٹس کو مستقل طور پر کام کرنا چاہئے۔ دن کے وقت، لانچ اسٹینڈ اور سسٹم کی دیگر ترتیبات سے قطع نظر، ٹیسٹ رنز کو ایک ہی نتیجہ حاصل ہونا چاہیے۔ ایک اصول کے طور پر، یہ اس حقیقت کی طرف سے یقینی بنایا جاتا ہے کہ آٹو ٹیسٹس مقررہ نظام کی ترتیبات کے ساتھ خصوصی ٹیسٹ ڈیٹا کے ساتھ کام کرتے ہیں۔
- آٹو ٹیسٹس کو آپ کے پروجیکٹ کے لیے قابل قبول رفتار سے کام کرنا چاہیے۔ یہ وقت ہر نظام کے لیے انفرادی طور پر مقرر کیا جاتا ہے۔ کچھ لوگ سارا دن کام کرنے کی استطاعت رکھتے ہیں، جبکہ دوسروں کو سیکنڈوں میں کام کرنا ضروری لگتا ہے۔ میں آپ کو تھوڑی دیر بعد بتاؤں گا کہ ہم نے اپنے پروجیکٹ میں رفتار کے کون سے معیارات حاصل کیے ہیں۔
- Autotest ترقی لچکدار ہونا چاہئے. کسی بھی فعالیت کو جانچنے سے صرف اس لیے انکار کرنا مناسب نہیں ہے کہ ہم نے اسے پہلے یا کسی اور وجہ سے نہیں کیا ہے۔ utPLSQL ترقی پر کوئی پابندی نہیں لگاتا، اور اوریکل، اصولی طور پر، آپ کو مختلف چیزوں کو لاگو کرنے کی اجازت دیتا ہے۔ زیادہ تر مسائل کا حل ہوتا ہے، یہ صرف وقت اور کوشش کی بات ہے۔
- تعیناتی ہمارے پاس کئی اسٹینڈز ہیں جہاں ہمیں ٹیسٹ چلانے کی ضرورت ہے۔ ہر اسٹینڈ پر، ڈیٹا ڈمپ کو کسی بھی وقت اپ ڈیٹ کیا جا سکتا ہے۔ خودکار ٹیسٹوں کے ساتھ پروجیکٹ کو اس طرح انجام دینا ضروری ہے کہ آپ اس کی مکمل یا جزوی تنصیب کو بغیر کسی تکلیف کے انجام دے سکیں۔
اور ایک دو دن میں دوسری پوسٹ میں میں آپ کو بتاؤں گا کہ ہم نے کیا کیا اور کیا نتائج حاصل کئے۔
ماخذ: www.habr.com