Առաջին մաս - .
Պատկերացրեք իրավիճակը. Ձեր առջեւ խնդիր է դրված նոր ֆունկցիոնալություն մշակել: Դուք զարգացումներ ունեք ձեր նախորդներից։ Եթե ենթադրենք, որ դուք բարոյական պարտավորություններ չունեք, ի՞նչ կանեիք։
Ամենից հաճախ մոռացվում են բոլոր հին զարգացումները, և ամեն ինչ սկսվում է նորից: Ոչ ոք չի սիրում փորփրել ուրիշի ծածկագիրը, բայց եթե ժամանակ ունես, ինչու չսկսել ստեղծել քո սեփական համակարգը: Սա տիպիկ մոտեցում է, և այն մեծ մասամբ ճիշտ է։ Բայց մեր նախագծում մենք դա սխալ արեցինք։ Մենք ապագա ավտոմատ թեստավորման համակարգը հիմնեցինք մեր նախորդների utPLSQL-ի միավորային թեստերի զարգացումների վրա, այնուհետև անցանք մի քանի զուգահեռ ուղղություններով:
- Հին միավորի թեստերի վերականգնում: Վերականգնում նշանակում է թեստերի հարմարեցում հավատարմության համակարգի առկա վիճակին և թեստերի հարմարեցում utPLSQL ստանդարտներին:
- Խնդրի լուծում՝ հասկանալով, թե կոնկրետ ինչ, ինչ մեթոդներ և գործընթացներ են ծածկված ավտոթեստերով: Դուք կամ պետք է պահեք այս տեղեկատվությունը ձեր գլխում, կամ եզրակացություններ անեք՝ հիմնվելով անմիջապես autotest ծածկագրի վրա: Հետեւաբար, մենք որոշեցինք ստեղծել կատալոգ: Մենք յուրաքանչյուր ինքնաթեստին հատկացրել ենք յուրահատուկ մնեմոնիկ կոդ, ստեղծել ենք նկարագրություն և գրանցել կարգավորումներ (օրինակ՝ ինչ պայմաններում այն պետք է գործարկվի, կամ ինչ պետք է տեղի ունենա, եթե փորձնական մեկնարկը ձախողվի): Ըստ էության, մենք լրացրել ենք ավտոմատ փորձարկումների մետատվյալները և տեղադրել այդ մետատվյալները ստանդարտ utPLSQL սխեմաների աղյուսակներում:
- Ընդլայնման ռազմավարության սահմանում, այսինքն. ֆունկցիոնալության ընտրություն, որը ենթակա է ստուգման ավտոմատացված թեստերի միջոցով: Մենք որոշեցինք ուշադրություն դարձնել երեք բանի վրա՝ նոր համակարգի բարելավումներ, արտադրության միջադեպեր և հիմնական համակարգի գործընթացներ: Այսպիսով, մենք զարգանում ենք թողարկմանը զուգահեռ՝ ապահովելով դրա ավելի բարձր որակը, միաժամանակ ընդլայնելով ռեգրեսիայի շրջանակը և ապահովելով համակարգի հուսալիությունը կրիտիկական վայրերում։ Առաջին նման խոչընդոտը չեկի վրա զեղչերի և բոնուսների բաշխման գործընթացն էր:
- Բնականաբար, մենք սկսեցինք մշակել նոր ավտոթեստեր։ Թողարկման առաջին առաջադրանքներից մեկը հավատարմության համակարգի նախապես սահմանված նմուշների կատարողականի գնահատումն էր: Մեր նախագիծն ունի խիստ ֆիքսված SQL հարցումների բլոկ, որն ընտրում է հաճախորդներին՝ հիմնվելով պայմանների վրա: Օրինակ՝ ստացեք բոլոր հաճախորդների ցուցակը, որոնց վերջին գնումը կատարվել է որոշակի քաղաքում, կամ այն հաճախորդների ցուցակը, որոնց գնման միջին գումարը որոշակի արժեքից բարձր է: Ունենալով գրավոր ինքնաթեստեր, մենք ստուգեցինք նախապես սահմանված նմուշները, գրանցեցինք հենանիշի կատարողականի պարամետրերը, և լրացուցիչ մենք ունեցանք բեռնվածության թեստավորում:
- Ավտոթեստերի հետ աշխատելը պետք է հարմար լինի. Ամենատարածված երկու գործողություններն են ավտոմատ թեստավորումը և թեստային տվյալների ստեղծումը: Այսպես մեր համակարգում հայտնվեցին երկու օժանդակ մոդուլներ՝ գործարկման մոդուլ և տվյալների ստեղծման մոդուլ։
Գործարկիչը ներկայացված է որպես մեկ ունիվերսալ ընթացակարգ՝ տեքստի մուտքագրման մեկ պարամետրով: Որպես պարամետր, դուք կարող եք փոխանցել autotest մնեմոնիկ կոդը, փաթեթի անունը, թեստի անունը, autotest պարամետրը կամ վերապահված հիմնաբառը: Ընթացակարգը ընտրում և գործարկում է բոլոր ինքնաթեստերը, որոնք բավարարում են պայմաններին:
Տվյալների ստեղծման մոդուլը ներկայացված է փաթեթի տեսքով, որում փորձարկվող համակարգի յուրաքանչյուր օբյեկտի համար (շտեմարանում աղյուսակ) ստեղծվել է հատուկ ընթացակարգ, որը տվյալներ է տեղադրում այնտեղ։ Այս ընթացակարգում լռելյայն արժեքները լրացվում են հնարավորինս, ինչը ապահովում է օբյեկտների ստեղծումը բառացիորեն մատի սեղմումով: Իսկ օգտագործման հարմարավետության համար ստեղծվել են գեներացված տվյալների կաղապարներ։ Օրինակ՝ ստեղծեք որոշակի տարիքի հաճախորդ՝ թեստային հեռախոսով և ավարտված գնումով:
- Ավտոփորձարկումները պետք է սկսվեն և գործարկվեն ձեր համակարգի համար ընդունելի ժամանակում: Հետևաբար, կազմակերպվեց ամենօրյա գիշերային մեկնարկ, որի արդյունքների հիման վրա գեներացվում է արդյունքների վերաբերյալ հաշվետվություն և կորպորատիվ փոստով ուղարկվում զարգացման ողջ թիմին: Հին ավտոթեստերը վերականգնելուց և նորերը ստեղծելուց հետո ընդհանուր գործառնական ժամանակը կազմել է 30 րոպե: Այս ներկայացումը սազում էր բոլորին, քանի որ մեկնարկը տեղի ունեցավ աշխատանքային ժամերից դուրս։
Բայց մենք պետք է աշխատեինք աշխատանքի արագության օպտիմալացման վրա։ Արտադրության մեջ հավատարմության համակարգը թարմացվում է գիշերը: Թողարկումներից մեկի շրջանակներում մենք ստիպված էինք շտապ փոփոխություններ կատարել գիշերը: Առավոտյան ժամը երեքին ավտոթեստերի արդյունքներին կես ժամ սպասելը չուրախացրեց ազատման համար պատասխանատուին (ջերմ ողջույններ Ալեքսեյ Վասյուկովին), իսկ հաջորդ առավոտ շատ բարի խոսքեր ասվեցին մեր համակարգի հասցեին։ Բայց արդյունքում հաստատվեց աշխատանքի 5 րոպեանոց չափորոշիչ։
Գործողությունը արագացնելու համար մենք օգտագործեցինք երկու մեթոդ. ավտոմատ փորձարկումները սկսեցին աշխատել երեք զուգահեռ թելերով, բարեբախտաբար դա շատ հարմար է մեր հավատարմության համակարգի ճարտարապետության շնորհիվ: Եվ մենք հրաժարվեցինք այն մոտեցումից, որտեղ autotest-ը չի ստեղծում թեստային տվյալներ իր համար, այլ փորձում է համակարգում հարմար բան գտնել։ Փոփոխությունները կատարելուց հետո ընդհանուր գործառնական ժամանակը կրճատվել է մինչև 3-4 րոպե:
- Ավտոմատ փորձարկումներով նախագիծը պետք է կարողանա տեղակայվել տարբեր կանգառներում: Մեր ճանապարհորդության սկզբում փորձեր եղան գրելու մեր սեփական խմբաքանակային ֆայլերը, բայց պարզ դարձավ, որ ինքնագրված ավտոմատ տեղադրումը կատարյալ սարսափ էր, և մենք դիմեցինք արդյունաբերական լուծումներին: Հաշվի առնելով այն հանգամանքը, որ նախագիծը պարունակում է շատ ուղիղ կոդ (առաջին հերթին, մենք պահպանում ենք autotest կոդը) և շատ քիչ տվյալներ (հիմնական տվյալները մետատվյալներն են autotests-ի վերաբերյալ), Liquibase նախագծում իրականացումը պարզվեց, որ շատ պարզ է:
Այն բաց կոդով, տվյալների բազայից անկախ գրադարան է՝ տվյալների բազայի սխեմայի փոփոխությունները հետևելու, կառավարելու և պարտադրելու համար: Կառավարվում է հրամանի տողի կամ շրջանակների միջոցով, ինչպիսիք են Apache Maven-ը: Liquibase-ի շահագործման սկզբունքը բավականին պարզ է. Մենք ունենք որոշակի ձևով կազմակերպված նախագիծ, որը բաղկացած է փոփոխություններից կամ սկրիպտներից, որոնք պետք է փոխանցվեն թիրախային սերվերին, և վերահսկիչ ֆայլեր, որոնք որոշում են, թե ինչ հաջորդականությամբ և ինչ պարամետրերով պետք է տեղադրվեն այդ փոփոխությունները:
DBMS մակարդակում ստեղծվում է հատուկ աղյուսակ, որտեղ Liquibase-ը պահում է rollover log-ը: Յուրաքանչյուր փոփոխություն ունի հաշվարկված հեշ, որը ամեն անգամ համեմատվում է նախագծի և տվյալների բազայի վիճակի միջև: Liquibase-ի շնորհիվ մենք հեշտությամբ կարող ենք փոփոխություններ կատարել մեր համակարգում ցանկացած շղթայում: Ինքնաթեստերն այժմ գործարկվում են փորձարկման և թողարկման սխեմաների, ինչպես նաև բեռնարկղերի (մշակողների անձնական սխեմաների) վրա:
Այսպիսով, եկեք խոսենք մեր միավորի փորձարկման համակարգի օգտագործման արդյունքների մասին:
- Իհարկե, առաջին հերթին մենք համոզված ենք, որ սկսել ենք ավելի լավ ծրագրեր մշակել։ Ամեն օր մեկնարկում են ավտոմատ թեստեր, և յուրաքանչյուր թողարկում հայտնաբերվում են տասնյակ սխալներ: Ավելին, այս սխալներից որոշները միայն անուղղակիորեն կապված են այն ֆունկցիոնալության հետ, որը մենք իսկապես ցանկանում էինք փոխել: Լուրջ կասկածներ կան, որ այդ սխալները հայտնաբերվել են ձեռքով թեստավորման միջոցով:
- Թիմն այժմ վստահ է, որ կոնկրետ ֆունկցիոնալությունը ճիշտ է աշխատում... Առաջին հերթին դա վերաբերում է մեր կրիտիկական գործընթացներին: Օրինակ, վերջին վեց ամիսների ընթացքում մենք որևէ խնդիր չենք ունեցել անդորրագրերի վրա զեղչերի և բոնուսների բաշխման հետ կապված՝ չնայած թողարկման փոփոխություններին, թեև նախորդ ժամանակաշրջաններում սխալները տեղի են ունեցել որոշակի հաճախականությամբ։
- Մեզ հաջողվեց նվազեցնել թեստավորման կրկնությունների քանակը։ Հաշվի առնելով այն հանգամանքը, որ ավտոմատ թեստերը գրված են նոր ֆունկցիոնալության համար, վերլուծաբանները և կես դրույքով փորձարկողները ստանում են ավելի բարձր որակի ծածկագիր, քանի որ այն արդեն ստուգված է։
- Ավտոմատացված թեստավորման որոշ զարգացումներ օգտագործվում են մշակողների կողմից: Օրինակ, բեռնարկղերի թեստային տվյալները ստեղծվում են օբյեկտների ստեղծման մոդուլի միջոցով:
- Կարևոր է, որ մենք մշակել ենք ավտոմատացված թեստավորման համակարգի «ընդունում» մշակողների կողմից: Կա հասկացողություն, որ սա կարևոր և օգտակար է: Բայց իմ սեփական փորձից կարող եմ ասել, որ դա հեռու է դեպքից։ Ավտոթեստերը պետք է գրվեն, դրանք պետք է աջակցվեն և մշակվեն, արդյունքները պետք է վերլուծվեն, և հաճախ այդ ժամանակի ծախսերը պարզապես չարժեն: Շատ ավելի հեշտ է գնալ արտադրության և այնտեղ խնդիրներ լուծել: Այստեղ մշակողները հերթ են կանգնում և խնդրում մեզ ծածկել իրենց ֆունկցիոնալությունը ավտոթեստերով:
Ինչ է հաջորդը
Խոսենք ավտոմատացված թեստավորման նախագծի զարգացման պլանների մասին։
Իհարկե, քանի դեռ Sportmaster-ի հավատարմության համակարգը կենդանի է և շարունակում է զարգանալ, հնարավոր է նաև գրեթե անվերջ զարգացնել ավտոթեստերը: Ուստի զարգացման հիմնական ուղղությունը ծածկույթի ընդլայնումն է։
Ինքնաթեստերի քանակի ավելացման հետ մեկտեղ դրանց ընդհանուր գործառնական ժամանակը անշեղորեն կավելանա, և մենք կրկին ստիպված կլինենք վերադառնալ կատարողականի խնդրին: Ամենայն հավանականությամբ, լուծումը կլինի զուգահեռ թելերի քանակի ավելացումը։
Բայց սրանք զարգացման ակնհայտ ուղիներ են։ Եթե խոսենք ավելի ոչ տրիվիալ բանի մասին, ապա առանձնացնում ենք հետևյալը.
- Ներկայումս ավտոմատ փորձարկման կառավարումն իրականացվում է DBMS մակարդակով, այսինքն. Հաջող աշխատանքի համար անհրաժեշտ է PL/SQL-ի իմացություն: Անհրաժեշտության դեպքում, համակարգի կառավարում (օրինակ, մետատվյալների գործարկում կամ ստեղծում), կարող եք ստեղծել ինչ-որ ադմինիստրատորի վահանակ՝ օգտագործելով Jenkins-ը կամ նման բան:
- Բոլորը սիրում են քանակական և որակական ցուցանիշներ։ Ավտոմատացված թեստավորման համար նման համընդհանուր ցուցիչ է ծածկույթի ծածկույթը կամ ծածկույթի մետրիկը: Օգտագործելով այս ցուցանիշը՝ մենք կարող ենք որոշել, թե մեր փորձարկվող համակարգի կոդի քանի տոկոսն է ծածկված ավտոթեստերով։ Սկսած 12.2 տարբերակից՝ Oracle-ն ապահովում է այս ցուցանիշը հաշվարկելու հնարավորություն և առաջարկում է օգտագործել ստանդարտ DBMS_PLSQL_CODE_COVERAGE փաթեթը:
Մեր ավտոթեստավորման համակարգը մեկ տարուց մի փոքր ավելի վաղեմություն ունի, և գուցե հիմա ժամանակն է գնահատել մեր ծածկույթը: Իմ վերջին նախագծում (ոչ Sportmaster նախագծում) այսպես եղավ: Ավտոթեստերի վրա աշխատելուց մեկ տարի անց ղեկավարությունը խնդիր դրեց գնահատել, թե ծածկագրի քանի տոկոսն ենք ծածկում: 1%-ից ավելի լուսաբանման դեպքում ղեկավարությունը ուրախ կլիներ: Մենք՝ մշակողներս, ակնկալում էինք մոտ 10% արդյունք։ Մենք տեղադրեցինք ծածկույթի ծածկույթը, չափեցինք այն և ստացանք 20%: Տոնելու համար մենք գնացինք մրցանակը ստանալու, բայց թե ինչպես գնացինք այն ստանալու և ուր գնացինք հետո, բոլորովին այլ պատմություն է:
- Ավտոփորձարկումները կարող են ստուգել բացված վեբ ծառայությունները: Oracle-ը մեզ թույլ է տալիս դա անել բավականին լավ, և մենք այլևս չենք հանդիպի մի շարք խնդիրների։
- Եվ, իհարկե, մեր ավտոմատացված թեստավորման համակարգը կարող է կիրառվել մեկ այլ նախագծի համար: Մեր ստացած լուծումը ունիվերսալ է և պահանջում է միայն Oracle-ի օգտագործումը: Ես լսել եմ, որ Sportmaster-ի մյուս նախագծերը հետաքրքրված են ավտոմատ թեստավորումով, և միգուցե մենք գնանք դրանց:
Արդյունքները
Եկեք ամփոփենք. Sportmaster-ում հավատարմության համակարգի նախագծում մեզ հաջողվեց ներդրել ավտոմատացված թեստավորման համակարգ: Այն հիմնված է Stephen Feuerstein-ի utPLSQL լուծման վրա: utPLSQL-ի շուրջ կա autotest կոդ և օժանդակ ինքնուրույն գրված մոդուլներ՝ գործարկման մոդուլ, տվյալների ստեղծման մոդուլ և այլն: Ավտոթեստերը ամեն օր մեկնարկում են, և որ ամենակարևորն է, դրանք գործում են և օգտակար: Մենք վստահ ենք, որ սկսել ենք ավելի բարձր որակի ծրագրեր թողարկել: Միևնույն ժամանակ, ստացված լուծումը ունիվերսալ է և կարող է ազատորեն կիրառվել ցանկացած նախագծի համար, որտեղ անհրաժեշտ է Oracle DBMS-ի վրա ավտոմատ թեստավորում կազմակերպել:
Հ.Գ. Այս հոդվածն այնքան էլ կոնկրետ չէ. կան շատ տեքստեր և գործնականում ոչ մի տեխնիկական օրինակ: Եթե թեման ընդհանուր առմամբ հետաքրքիր է, ապա մենք պատրաստ ենք այն շարունակել և վերադառնալ շարունակությամբ, որտեղ կպատմենք, թե ինչ է փոխվել վերջին վեց ամիսների ընթացքում և կներկայացնենք կոդերի օրինակներ։
Գրեք մեկնաբանություններ, եթե կան կետեր, որոնք պետք է ընդգծվեն ապագայում, կամ հարցեր, որոնք պահանջում են բացահայտում:
Հարցմանը կարող են մասնակցել միայն գրանցված օգտվողները։ , խնդրում եմ:
Այս մասին ավելին գրե՞նք։
-
Այո, իհարկե
-
Ոչ, շնորհակալություն
Քվեարկել է 12 օգտատեր։ 4 օգտատեր ձեռնպահ է մնացել։
Source: www.habr.com