اې حبره!
زما نوم ماکسیم پونومارینکو دی او زه په سپورت ماسټر کې پراختیا کونکی یم. زه د معلوماتي ټکنالوجۍ په برخه کې 10 کاله تجربه لرم. هغه خپل مسلک په لاسي ازموینې کې پیل کړ، بیا د ډیټابیس پراختیا ته لاړ. د تیرو 4 کلونو لپاره، د ازموینې او پراختیا په برخه کې ترلاسه شوي پوهه راټولول، زه د DBMS په کچه اتوماتیک ازموینه کوم.
زه یوازې د یو کال راهیسې د سپورت ماسټر ټیم کې یم او په یوې لویې پروژې کې اتوماتیک ازموینې رامینځته کوم. په اپریل کې، د سپورت ماسټر لابراتوار هلکانو او ما په کراسنودار کې په یوه کنفرانس کې خبرې وکړې، زما راپور "په DBMS کې د واحد ازموینې" په نامه یاد شو، او اوس زه غواړم دا ستاسو سره شریک کړم. دلته به ډیر متن وي، نو ما پریکړه وکړه چې راپور په دوو پوستونو ویشم. په لومړي کې، موږ به په عمومي توګه د اتوماتیک ازموینې او ازموینې په اړه وغږیږو، او په دویمه برخه کې، زه به زموږ د واحد ازموینې سیسټم او د هغې د غوښتنلیک پایلو په اړه نور تفصیل سره خبرې وکړم.
لومړی، یو لږ ستړی نظره. اتومات ازموینه څه ده؟ دا ازموینه ده چې د سافټویر په کارولو سره ترسره کیږي، او په عصري IT کې دا په زیاتیدونکي توګه د سافټویر پراختیا کې کارول کیږي. دا د دې حقیقت له امله دی چې شرکتونه وده کوي ، د دوی د معلوماتو سیسټمونه وده کوي او په وینا یې د فعالیت اندازه چې ازموینې ته اړتیا لري وده کوي. د لاسي ازموینې ترسره کول ورځ تر بلې ګران کیږي.
ما د یوې لوی شرکت لپاره کار کاوه چې خپرونه یې په هرو دوو میاشتو کې راځي. په ورته وخت کې ، ټوله میاشت د لسګونو ټیسټرانو په لاسي ډول فعالیت چیک کولو باندې مصرف شوې. د پراختیا کونکو یوې کوچنۍ ډلې لخوا د اتوماتیک پلي کولو څخه مننه ، موږ وکولی شو د ازموینې وخت په یو نیم کال کې 2 اونیو ته راکم کړو. موږ نه یوازې د ازموینې سرعت ډیر کړی ، بلکه د هغې کیفیت یې هم ښه کړی دی. اتومات ازموینې په منظم ډول پیل کیږي او دوی تل د چکونو ټول کورس ترسره کوي چې پدې کې شامل دي ، دا چې موږ انساني فاکتور خارج کوو.
عصري IT د دې حقیقت لخوا مشخص کیږي چې یو پراختیا کونکي ممکن نه یوازې د محصول کوډ لیکلو ته اړتیا ولري ، بلکه د واحد ازموینې لیکلو ته هم اړتیا لري چې دا کوډ چیک کړي.
مګر څه که ستاسو سیسټم اساسا د سرور منطق پراساس وي؟ په بازار کې هیڅ نړیوال حل یا غوره کړنې شتون نلري. د یوې قاعدې په توګه، شرکتونه دا ستونزه د خپل ځان لیکل شوي ازموینې سیسټم په جوړولو سره حل کوي. دا زموږ خپل ځان لیکل شوی اتوماتیک ازموینې سیسټم دی چې زموږ په پروژه کې رامینځته شوی او زه به یې په خپل راپور کې وغږیږم.
د وفادارۍ ازموینه
لومړی، راځئ چې د پروژې په اړه وغږیږو چیرې چې موږ د اتوماتیک ازموینې سیسټم ځای په ځای کړی. زموږ پروژه د سپورت ماسټر وفادارۍ سیسټم دی (په لاره کې، موږ دمخه پدې اړه لیکلي ).
که ستاسو شرکت خورا لوی وي، نو ستاسو د وفادارۍ سیسټم به درې معیاري ملکیتونه ولري:
- ستاسو سیسټم به ډیر بار وي
- ستاسو سیسټم به پیچلي کمپیوټري پروسې ولري
- ستاسو سیسټم به په فعاله توګه ښه شي.
راځئ چې په ترتیب سره لاړ شو ... په مجموع کې، که موږ د سپورت ماسټر ټول برانډونه په پام کې ونیسو، نو موږ په روسیه، اوکراین، چین، قزاقستان او بیلاروس کې له 1000 څخه ډیر پلورنځي لرو. په دې پلورنځیو کې هره ورځ شاوخوا 300 پیرودونه کیږي. دا، هره ثانیه 000-3 چکونه زموږ سیسټم ته ننوځي. په طبیعي توګه، زموږ د وفادارۍ سیسټم خورا لوړ دی. او څنګه چې دا په فعاله توګه کارول کیږي، موږ باید د دې کیفیت لوړ معیارونه چمتو کړو، ځکه چې په سافټویر کې کومه تېروتنه د لوی پیسو، شهرت او نورو زیانونو معنی لري.
په ورته وخت کې ، سپورت ماسټر له سلو څخه ډیر مختلف پرمختګونه پرمخ وړي. دلته مختلف ډوله ترویجونه شتون لري: د محصول ترویجونه شتون لري ، دلته هغه د اونۍ ورځې ته وقف شوي ، دلته هغه څوک دي چې یو ځانګړي پلورنځي پورې تړلي دي ، د رسید مقدار لپاره ترویجونه شتون لري ، د توکو شمیر لپاره شتون لري. په عمومي توګه، بد نه. پیرودونکي بونس او پروموشنل کوډونه لري چې د پیرودلو په وخت کې کارول کیږي. دا ټول د دې حقیقت لامل کیږي چې د هر حکم حساب کول خورا غیر معمولي کار دی.
هغه الګوریتم چې د امر پروسس پلي کوي واقعیا خورا خطرناک او پیچلي دي. او پدې الګوریتم کې کوم بدلون خورا خطرناک دی. داسې بریښي چې خورا مهم ښکاري بدلونونه کولی شي د اټکل وړ اغیزو لامل شي. مګر دا دقیقا دومره پیچلي کمپیوټري پروسې دي ، په ځانګړي توګه هغه چې مهم فعالیت پلي کوي ، دا د اتومات کولو لپاره غوره نوماندان دي. په لسګونو ورته قضیو د لاس په واسطه چک کول ډیر وخت نیسي. او له هغه وخته چې پروسې ته د ننوتلو نقطه بدله شوې نه ده، یو ځل یې تشریح کړئ، تاسو کولی شئ په چټکۍ سره اتوماتیک ازموینې رامینځته کړئ او ډاډه اوسئ چې فعالیت به کار وکړي.
څرنګه چې زموږ سیسټم په فعاله توګه کارول کیږي، سوداګرۍ به له تاسو څخه یو څه نوي وغواړي، د وخت سره ژوند وکړي او د پیرودونکي پر بنسټ وي. زموږ د وفادارۍ سیسټم کې، خوشې کول په هرو دوو میاشتو کې راځي. دا پدې مانا ده چې موږ باید په هرو دوو میاشتو کې د ټول سیسټم بشپړ بیاکتنه ترسره کړو. په عین حال کې، په طبیعي توګه، لکه څنګه چې په هر عصري معلوماتي ټکنالوجۍ کې، پرمختګ سمدلاسه د پراختیا کونکي څخه تولید ته نه ځي. دا د پراختیا کونکي سرکټ کې رامینځته کیږي ، بیا په پرله پسې ډول د ازموینې بنچ څخه تیریږي ، خوشې کول ، منل ، او یوازې بیا په تولید کې پای ته رسیږي. لږترلږه ، د ازموینې او خوشې کولو سرکټونو کې ، موږ اړتیا لرو د ټول سیسټم بشپړ راجسټریشن ترسره کړو.
بیان شوي ملکیتونه د نږدې هر وفادار سیسټم لپاره معیاري دي. راځئ چې زموږ د پروژې د ځانګړتیاوو په اړه خبرې وکړو.
په ټیکنالوژیکي توګه، زموږ د وفادارۍ سیسټم 90٪ منطق د سرور پر بنسټ دی او په اوریکل کې پلي کیږي. په ډیلفي کې یو پیرودونکی څرګند شوی ، کوم چې د اتوماتیک کاري ځای مدیر دنده ترسره کوي. د بهرني غوښتنلیکونو لپاره ښکاره ویب خدمتونه شتون لري (د مثال په توګه یوه ویب پاڼه). نو ځکه، دا خورا منطقي ده چې که موږ د اتوماتیک ازموینې سیسټم ځای په ځای کړو، نو موږ به یې په اوریکل کې ترسره کړو.
په سپورت ماسټر کې د وفادارۍ سیسټم له 7 کلونو څخه ډیر شتون لري او د واحد پراختیا کونکو لخوا رامینځته شوی ... پدې 7 کلونو کې زموږ په پروژه کې د پراختیا کونکو اوسط شمیر 3-4 کسان و. مګر په تیر کال کې، زموږ ټیم د پام وړ وده کړې، او اوس په پروژه کې 10 کسان کار کوي. دا هغه خلک دي چې پروژې ته راځي چې د عادي کارونو، پروسو او جوړښت سره بلد نه وي. او ډیر خطر شتون لري چې موږ به غلطی له لاسه ورکړو.
پروژه د کارمندانو واحدونو په توګه د وقف شوي ازموینې کونکو نشتوالي لخوا مشخص کیږي. البته، ازموینه شتون لري، مګر ازموینه د شنونکو لخوا ترسره کیږي، د دوی د نورو اصلي مسؤلیتونو سربیره: د سوداګرۍ پیرودونکو، کاروونکو سره اړیکه، د سیسټم اړتیاوو ته وده ورکول، او نور. د دې حقیقت سره سره چې ازموینه په خورا لوړ کیفیت ترسره کیږي (دا په ځانګړي توګه د یادولو لپاره مناسبه ده، ځکه چې ځینې شنونکي ممکن دې راپور ته پام وکړي)، په یو شی باندې د تخصص او تمرکز اغیزمنتوب لغوه شوی نه دی. .
د پورته ټولو په پام کې نیولو سره، د وړاندې شوي محصول کیفیت ښه کولو او د پراختیا وخت کمولو لپاره، په پروژه کې د اتوماتیک ازموینې نظر خورا منطقي ښکاري. او د وفادارۍ سیسټم د شتون په مختلفو مرحلو کې، انفرادي پراختیا کونکو هڅې وکړې چې خپل کوډ د واحد ازموینې سره پوښ کړي. په ټولیز ډول دا یو منحل شوی پروسه وه، هرڅوک د خپل جوړښت او میتودونو په کارولو سره. وروستۍ پایلې د واحد ازموینو لپاره عام وې: ازموینې رامینځته شوي ، د یو څه وخت لپاره کارول شوي ، په نسخه شوي فایل ذخیره کې زیرمه شوي ، مګر په یو وخت کې دوی چلول ودرول او هیر شوي. تر ټولو لومړی، دا د دې حقیقت له امله و چې ازموینې په یو ځانګړي لوبغاړي پورې تړلې وې، نه پروژې ته.
utPLSQL ژغورنې ته راځي
ایا تاسو د سټیفن فیورسټین په اړه څه پوهیږئ؟
دا یو هوښیار سړی دی چې د خپل مسلک اوږده برخه یې د اوریکل او PL/SQL سره کار کولو ته وقف کړې ، او پدې موضوع یې خورا لوی کارونه لیکلي دي. د هغه یو مشهور کتاب نومیږي: "اوریکل PL/SQL. د مسلکي کسانو لپاره." دا سټیفن و چې د utPLSQL حل یې رامینځته کړی ، یا لکه څنګه چې دا د اوریکل PL/SQL لپاره د واحد ازموینې چوکاټ دی. د utPLSQL حل په 2016 کې رامینځته شوی ، مګر دا په فعاله توګه کار کولو ته دوام ورکوي او نوې نسخې خوشې کیږي. د راپور ورکولو په وخت کې، وروستۍ نسخه د مارچ 24، 2019 پورې نیټه ده.
دا څه دي. دا د خلاصې سرچینې جلا پروژه ده. دا یو څو میګابایټ وزن لري، په شمول د مثالونو او اسنادو. په فزیکي توګه، دا د ORACLE ډیټابیس کې جلا سکیما ده چې د واحد ازموینې تنظیم کولو لپاره د کڅوړو او میزونو سیټ سره. نصب کول څو ثانیې وخت نیسي. د utPLSQL یو ځانګړی ځانګړتیا د دې کارولو اسانتیا ده.
په نړیواله کچه، utPLSQL د واحد ټیسټونو چلولو لپاره یو میکانیزم دی، چیرې چې د یونټ ازموینه د عادي اوریکل بیچ پروسیجرونو په توګه پیژندل کیږي، چې تنظیم یې ځینې مقررات تعقیبوي. د پیل کولو سربیره، utPLSQL ستاسو د ټولو ټیسټ منډو لاګ ذخیره کوي، او د داخلي راپور ورکولو سیسټم هم لري.
راځئ چې یو مثال وګورو چې د واحد ټیسټ کوډ څه ډول ښکاري ، د دې تخنیک په کارولو سره پلي شوی.
نو، سکرین د واحد ازموینې سره د عادي کڅوړې مشخصاتو لپاره کوډ ښیې. لازمي اړتیاوې څه دي؟ کڅوړه باید د "utp_" سره مخکینۍ وي. د ازموینو سره ټول پروسیجرونه باید دقیقا ورته مخکینۍ ولري. بسته باید دوه معیاري پروسیجرونه ولري: "utp_setup" او "utp_teardown". لومړۍ کړنلاره د هر واحد ازموینې بیا پیلولو سره ویل کیږي، دویمه - د پیل څخه وروسته.
"utp_setup"، د یوې قاعدې په توګه، زموږ سیسټم چمتو کوي چې د واحد ازموینې پرمخ بوځي، د بیلګې په توګه، د ازموینې ډاټا جوړول. "utp_teardown" - په برعکس، هرڅه اصلي ترتیباتو ته راستنیږي او د پیل پایلې بیا تنظیموي.
دلته د ساده واحد ازموینې یوه بیلګه ده چې زموږ د وفادارۍ سیسټم لپاره معیاري فارم ته د ننوتل شوي پیرودونکي تلیفون شمیره نورمال کول چیک کوي. د واحد ازموینې سره د طرزالعملونو لیکلو څرنګوالي په اړه کوم لازمي معیارونه شتون نلري. د یوې قاعدې په توګه ، د ازموینې لاندې سیسټم میتود ته زنګ وهل کیږي ، او د دې میتود لخوا بیرته راستنیدونکي پایله د حوالې سره پرتله کیږي. دا مهمه ده چې د حوالې پایلې او ترلاسه شوي پرتله کول د معیاري utPLSQL میتودونو له لارې ترسره کیږي.
د واحد ازموینه کولی شي هر شمیر چکونه ولري. لکه څنګه چې د مثال څخه لیدل کیدی شي، موږ د تلیفون شمیره نورمال کولو لپاره ازمول شوي میتود ته څلور پرله پسې تلیفونونه کوو او د هرې زنګ وروسته پایله ارزونه کوو. کله چې د واحد ازموینې رامینځته کول ، تاسو باید په پام کې ونیسئ چې داسې چیکونه شتون لري چې سیسټم په هیڅ ډول اغیزه نه کوي ، او د یو څه وروسته تاسو اړتیا لرئ د سیسټم اصلي حالت ته راستون شئ.
د مثال په توګه، په وړاندې شوي واحد ازموینه کې موږ په ساده ډول د ان پټ تلیفون شمیره فارمیټ کوو، کوم چې په هیڅ ډول د وفادارۍ سیسټم اغیزه نه کوي.
او که موږ د نوي پیرودونکي رامینځته کولو میتود په کارولو سره د واحد ازموینې ولیکئ ، نو د هرې ازموینې وروسته به په سیسټم کې نوی پیرودونکی رامینځته شي ، کوم چې کولی شي د ازموینې وروسته پیل اغیزه وکړي.
په دې توګه د واحد ازموینې ترسره کیږي. د لانچ دوه احتمالي اختیارونه شتون لري: د ځانګړي کڅوړې څخه د ټولو واحد ازموینې چلول یا په ځانګړي بسته کې د ځانګړي واحد ټیسټ چلول.
دا هغه څه دي چې د داخلي راپور ورکولو سیسټم یوه بیلګه ورته ښکاري. د واحد ازموینې پایلو پراساس، utPLSQL یو کوچنی راپور جوړوي. پدې کې موږ د هر ځانګړي چک لپاره پایله او د واحد ازموینې عمومي پایله ګورو.
د اتوماتیک ازموینې 6 قواعد
مخکې لدې چې د وفادارۍ سیسټم اتومات ازموینې لپاره د نوي سیسټم رامینځته کولو پیل وکړو ، د مدیریت سره یوځای ، موږ هغه اصول وټاکو چې زموږ راتلونکي اتومات ازموینې باید ورسره مطابقت ولري.
- آټوټسټس باید اغیزمن وي او باید ګټور وي. موږ په زړه پوري پراختیا کونکي لرو ، چې حتما یې باید یادونه وشي ، ځکه چې ځینې به یې شاید دا راپور وګوري ، او دوی په زړه پوري کوډ لیکي. مګر حتی د دوی په زړه پوري کوډ بشپړ ندی او لري، لري، او غلطیو ته به دوام ورکړي. د دې غلطیو موندلو لپاره اتومات ازموینې اړین دي. که دا مسله نه وي، نو یا به موږ بد آټوټس لیکو، یا موږ یوې مړې سیمې ته رسیدلي یو چې په اصولو کې، وده نه کوي. په دواړو حالتونو کې، موږ یو څه غلط کوو، او زموږ چلند په ساده ډول معنی نلري.
- اتوماتیک ازموینې باید وکارول شي. دا هیڅ معنی نلري چې د سافټویر محصول لیکلو لپاره ډیر وخت او هڅې مصرف کړئ ، په ذخیره کې یې واچوئ او هیر یې کړئ. ازموینې باید ترسره شي، او د امکان تر حده په منظمه توګه ودرول شي.
- اتوماتیک ازموینې باید په ثابت ډول کار وکړي. پرته له دې چې د ورځې وخت، د لانچ موقف او نور سیسټم ترتیبات، د ازموینې منډې باید ورته پایلې ته الر پیدا کړي. د یوې قاعدې په توګه، دا د دې حقیقت له مخې ډاډمن کیږي چې آټوټسټونه د ثابت سیسټم ترتیباتو سره د ځانګړي ازموینې ډاټا سره کار کوي.
- Autotests باید ستاسو د پروژې لپاره د منلو وړ سرعت سره کار وکړي. دا وخت د هر سیسټم لپاره په انفرادي ډول ټاکل کیږي. ځینې خلک کولی شي ټوله ورځ کار وکړي، پداسې حال کې چې نور یې په ثانیو کې دا کار کول خورا مهم ګڼي. زه به تاسو ته یو څه وروسته ووایم چې موږ زموږ په پروژه کې کوم سرعت معیارونه ترلاسه کړل.
- د اتوماتیک پراختیا باید انعطاف وړ وي. دا مشوره نده چې د کوم فعالیت ازموینې څخه انکار وکړئ په ساده ډول ځکه چې موږ دا دمخه یا د کوم بل دلیل لپاره نه دی کړی. utPLSQL په پراختیا هیڅ محدودیت نه لګوي، او اوریکل، په اصولو کې، تاسو ته اجازه درکوي چې مختلف شیان پلي کړئ. ډیری ستونزې حل لري، دا یوازې د وخت او هڅې خبره ده.
- ځای پرځای کول. موږ ډیری سټینډونه لرو چیرې چې موږ ازموینې ته اړتیا لرو. په هر موقف کې، د معلوماتو ډمپ په هر وخت کې تازه کیدی شي. دا اړینه ده چې یوه پروژه د اتوماتیک ازموینو سره ترسره کړئ په داسې ډول چې تاسو کولی شئ په بې دردۍ سره د هغې بشپړ یا جزوي نصب ترسره کړئ.
او په یو څو ورځو کې په دوهم پوسټ کې به زه تاسو ته ووایم چې موږ څه وکړل او کومې پایلې مو ترلاسه کړې.
سرچینه: www.habr.com