Հե՜յ Հաբր։
Ես Մաքսիմ Պոնոմարենկոն եմ, և ես Sportmaster-ի ծրագրավորող եմ: Ունեմ ՏՏ ոլորտում 10 տարվա փորձ։ Նա իր կարիերան սկսել է ձեռքով թեստավորման ոլորտում, այնուհետև անցել է տվյալների բազայի մշակմանը: Վերջին 4 տարիների ընթացքում, կուտակելով թեստավորման և մշակման ոլորտում ձեռք բերված գիտելիքները, ես ավտոմատացնում եմ թեստավորումը DBMS մակարդակում:
Ես Sportmaster-ի թիմում եմ եղել մեկ տարուց ավելին և մշակում եմ ավտոմատացված թեստավորում խոշոր նախագծերից մեկի վրա: Ապրիլին Sportmaster Lab-ի տղաները և ես խոսեցինք Կրասնոդարում կայացած կոնֆերանսի ժամանակ, իմ զեկույցը կոչվում էր «Միավոր փորձարկումներ DBMS-ում», և հիմա ես ուզում եմ կիսվել ձեզ հետ: Տեքստը շատ կլինի, ուստի որոշեցի զեկույցը բաժանել երկու գրառման: Առաջինում մենք կխոսենք ավտոթեստերի և ընդհանրապես թեստավորման մասին, իսկ երկրորդում ավելի մանրամասն կանդրադառնամ մեր միավորի թեստավորման համակարգի և դրա կիրառման արդյունքներին:
Նախ, մի փոքր ձանձրալի տեսություն. Ի՞նչ է ավտոմատացված թեստավորումը: Սա թեստավորում է, որն իրականացվում է ծրագրային ապահովման միջոցով, իսկ ժամանակակից ՏՏ-ում այն ավելի ու ավելի է օգտագործվում ծրագրային ապահովման մշակման մեջ: Դա պայմանավորված է նրանով, որ ընկերություններն աճում են, նրանց տեղեկատվական համակարգերն աճում են, և, համապատասխանաբար, աճում է այն ֆունկցիոնալության քանակը, որը պետք է փորձարկվի: Ձեռքով թեստավորումն ավելի ու ավելի թանկ է դառնում։
Ես աշխատել եմ մի մեծ ընկերությունում, որի թողարկումները թողարկվում են երկու ամիսը մեկ: Միևնույն ժամանակ, մի ամբողջ ամիս ծախսվել է տասնյակ թեստերի ձեռքով ստուգելու ֆունկցիոնալությունը։ Մշակողների փոքր թիմի կողմից ավտոմատացման ներդրման շնորհիվ մենք կարողացանք մեկուկես տարվա ընթացքում կրճատել փորձարկման ժամանակը մինչև 2 շաբաթ: Մենք ոչ միայն բարձրացրել ենք թեստավորման արագությունը, այլև բարելավել ենք դրա որակը։ Պարբերաբար գործարկվում են ավտոմատ թեստեր և դրանք միշտ իրականացնում են դրանցում ներառված ստուգումների ամբողջ ընթացքը, այսինքն՝ մենք բացառում ենք մարդկային գործոնը։
Ժամանակակից ՏՏ-ն բնութագրվում է նրանով, որ մշակողից կարող է պահանջվել ոչ միայն գրել ապրանքի կոդը, այլև գրել միավորի թեստեր, որոնք ստուգում են այս կոդը:
Բայց ինչ անել, եթե ձեր համակարգը հիմնված է հիմնականում սերվերի տրամաբանության վրա: Շուկայում չկա ունիվերսալ լուծում կամ լավագույն փորձ: Որպես կանոն, ընկերությունները լուծում են այս խնդիրը՝ ստեղծելով սեփական գրավոր թեստավորման համակարգը։ Սա մեր սեփական գրավոր ավտոմատացված թեստավորման համակարգն է, որը ստեղծվել է մեր նախագծի վրա, և ես դրա մասին կխոսեմ իմ զեկույցում:
Հավատարմության ստուգում
Նախ, եկեք խոսենք նախագծի մասին, որտեղ մենք տեղադրեցինք ավտոմատացված թեստավորման համակարգ: Մեր նախագիծը Sportmaster հավատարմության համակարգն է (ի դեպ, մենք արդեն գրել ենք դրա մասին ).
Եթե ձեր ընկերությունը բավականաչափ մեծ է, ապա ձեր հավատարմության համակարգը կունենա երեք ստանդարտ հատկություններ.
- Ձեր համակարգը շատ ծանրաբեռնված կլինի
- Ձեր համակարգը կպարունակի բարդ հաշվողական գործընթացներ
- Ձեր համակարգը ակտիվորեն կբարելավվի:
Գնանք հերթականությամբ... Ընդհանուր առմամբ, եթե դիտարկենք Sportmaster-ի բոլոր բրենդերը, ապա մենք ունենք 1000-ից ավելի խանութ Ռուսաստանում, Ուկրաինայում, Չինաստանում, Ղազախստանում և Բելառուսում։ Այս խանութներից օրական մոտ 300 հազար գնում է կատարվում։ Այսինքն՝ ամեն վայրկյան 000-3 ստուգում է մտնում մեր համակարգ։ Բնականաբար, մեր հավատարմության համակարգը շատ ծանրաբեռնված է: Եվ քանի որ այն ակտիվորեն օգտագործվում է, մենք պետք է ապահովենք դրա որակի ամենաբարձր չափանիշները, քանի որ ծրագրային ապահովման ցանկացած սխալ նշանակում է մեծ դրամական, հեղինակության և այլ կորուստներ։
Միևնույն ժամանակ Sportmaster-ն անցկացնում է ավելի քան հարյուր տարբեր ակցիաներ: Կան տարբեր ակցիաներ՝ կան ապրանքների ակցիաներ, կան շաբաթվա օրվան նվիրվածներ, կան կոնկրետ խանութի հետ կապված, անդորրագրի չափի համար կան ակցիաներ, կան ապրանքների քանակի համար։ Ընդհանուր առմամբ, վատ չէ: Հաճախորդներն ունեն բոնուսներ և գովազդային կոդեր, որոնք օգտագործվում են գնումներ կատարելիս: Այս ամենը հանգեցնում է նրան, որ ցանկացած պատվերի հաշվարկը շատ ոչ տրիվիալ խնդիր է։
Պատվերների մշակումն իրականացնող ալգորիթմն իսկապես սարսափելի է և բարդ։ Եվ այս ալգորիթմի ցանկացած փոփոխություն բավականին ռիսկային է: Թվում էր, որ ամենաաննշան թվացող փոփոխությունները կարող են հանգեցնել բավականին անկանխատեսելի հետևանքների։ Բայց հենց այդպիսի բարդ հաշվողական գործընթացներն են, հատկապես նրանք, որոնք իրականացնում են կրիտիկական ֆունկցիոնալություն, ավտոմատացման լավագույն թեկնածուներն են: Տասնյակ նմանատիպ դեպքեր ձեռքով ստուգելը շատ ժամանակատար է։ Եվ քանի որ գործընթացի մուտքի կետն անփոփոխ է, այն մեկ անգամ նկարագրելով, կարող եք արագ ստեղծել ավտոմատ թեստեր և վստահ լինել, որ ֆունկցիոնալությունը կաշխատի:
Քանի որ մեր համակարգը ակտիվորեն օգտագործվում է, բիզնեսը ձեզանից նոր բան կցանկանա, ապրել ժամանակի համաձայն և լինել հաճախորդամետ: Մեր հավատարմության համակարգում թողարկումները թողարկվում են երկու ամիսը մեկ: Սա նշանակում է, որ երկու ամիսը մեկ պետք է ամբողջ համակարգի ամբողջական ռեգրեսիա իրականացնել։ Միևնույն ժամանակ, բնականաբար, ինչպես ցանկացած ժամանակակից ՏՏ-ում, զարգացումը մշակողից անմիջապես չի անցնում արտադրություն: Այն ծագում է մշակողի միացումից, այնուհետև հաջորդաբար անցնում է փորձարկման նստարանով, թողարկում, ընդունում և միայն այնուհետև ավարտվում արտադրության մեջ: Առնվազն փորձարկման և արձակման սխեմաների վրա մենք պետք է իրականացնենք ամբողջ համակարգի ամբողջական ռեգրեսիա:
Նկարագրված հատկությունները ստանդարտ են գրեթե ցանկացած հավատարմության համակարգի համար: Եկեք խոսենք մեր նախագծի առանձնահատկությունների մասին:
Տեխնոլոգիապես մեր հավատարմության համակարգի տրամաբանության 90%-ը հիմնված է սերվերի վրա և իրականացվում է Oracle-ի վրա: Դելֆիում կա հաճախորդ, որը կատարում է աշխատավայրի ավտոմատացված ադմինիստրատորի գործառույթը: Կան բացված վեբ ծառայություններ արտաքին հավելվածների համար (օրինակ՝ կայք): Հետևաբար, շատ տրամաբանական է, որ եթե մենք տեղադրենք ավտոմատ թեստավորման համակարգ, մենք դա կանենք Oracle-ում:
Հավատարմության համակարգը Sportmaster-ում գոյություն ունի ավելի քան 7 տարի և ստեղծվել է միայնակ ծրագրավորողների կողմից... Այս 7 տարիների ընթացքում մեր նախագծի մշակողների միջին թիվը եղել է 3-4 հոգի։ Սակայն վերջին մեկ տարվա ընթացքում մեր թիմը զգալիորեն աճել է, և այժմ 10 մարդ է աշխատում նախագծի վրա: Այսինքն՝ նախագծին գալիս են մարդիկ, ովքեր ծանոթ չեն տիպիկ առաջադրանքներին, գործընթացներին և ճարտարապետությանը: Եվ մեծանում է վտանգը, որ մենք բաց կթողնենք սխալները։
Նախագիծը բնութագրվում է որպես անձնակազմի ստորաբաժանումներ նվիրված փորձարկողների բացակայությամբ: Կա, իհարկե, թեստավորում, բայց թեստավորումն իրականացվում է վերլուծաբանների կողմից՝ ի լրումն իրենց մյուս հիմնական պարտականությունների՝ բիզնես հաճախորդների, օգտատերերի հետ շփում, համակարգի պահանջների մշակում և այլն։ և այլն... Չնայած այն հանգամանքին, որ թեստավորումն իրականացվում է շատ բարձր որակով (սա հատկապես տեղին է նշել, քանի որ որոշ վերլուծաբաններ կարող են աչքի ընկնել այս զեկույցի վրա), մասնագիտացման և կենտրոնացման արդյունավետությունը մի բանի վրա չի չեղարկվել: .
Հաշվի առնելով վերը նշված բոլորը, առաքված արտադրանքի որակը բարելավելու և զարգացման ժամանակը նվազեցնելու համար, նախագծի վրա փորձարկման ավտոմատացման գաղափարը շատ տրամաբանական է թվում: Եվ հավատարմության համակարգի գոյության տարբեր փուլերում առանձին մշակողները ջանքեր են գործադրել ծածկելու իրենց կոդը միավորի թեստերով: Ընդհանուր առմամբ, դա բավականին տարանջատված գործընթաց էր, որտեղ յուրաքանչյուրն օգտագործում էր իր ճարտարապետությունն ու մեթոդները: Վերջնական արդյունքները սովորական էին միավորի թեստերի համար. թեստերը մշակվեցին, որոշ ժամանակ օգտագործվեցին, պահվեցին տարբերակված ֆայլերի պահեստում, բայց ինչ-որ պահի դրանք դադարեցին աշխատել և մոռացվեցին: Առաջին հերթին դա պայմանավորված էր նրանով, որ թեստերն ավելի շատ կապված էին կոնկրետ կատարողի, այլ ոչ թե նախագծի հետ։
utPLSQL-ը գալիս է օգնության
Դուք որևէ բան գիտե՞ք Սթիվեն Ֆոյերշտեյնի մասին:
Սա խելացի տղա է, ով իր կարիերայի երկար մասը նվիրել է Oracle-ի և PL/SQL-ի հետ աշխատելուն և բավականին մեծ թվով աշխատանքներ է գրել այս թեմայով: Նրա հայտնի գրքերից մեկը կոչվում է՝ «Oracle PL/SQL. Պրոֆեսիոնալների համար»։ Սթիվենն էր, ով մշակեց utPLSQL լուծումը կամ, ինչպես դա նշանակում է, Unit Testing Framework Oracle PL/SQL-ի համար: utPLSQL լուծումը ստեղծվել է 2016 թվականին, սակայն դրա վրա շարունակվում է ակտիվ աշխատել և թողարկվել են նոր տարբերակներ։ Հաշվետվության պահին վերջին տարբերակը թվագրվում է 24 թվականի մարտի 2019-ով:
Ինչ է դա։ Սա առանձին բաց կոդով նախագիծ է: Այն կշռում է մի քանի մեգաբայթ, ներառյալ օրինակները և փաստաթղթերը: Ֆիզիկապես, դա ORACLE տվյալների բազայի առանձին սխեմա է՝ փաթեթների և աղյուսակների մի շարք միավորների փորձարկումը կազմակերպելու համար: Տեղադրումը տևում է մի քանի վայրկյան: utPLSQL-ի տարբերակիչ առանձնահատկությունը օգտագործման հեշտությունն է:
Համաշխարհային մասշտաբով utPLSQL-ը միավորի թեստերի իրականացման մեխանիզմ է, որտեղ միավորի թեստը հասկացվում է որպես սովորական Oracle սերիայի ընթացակարգեր, որոնց կազմակերպումը հետևում է որոշակի կանոնների: Գործարկումից բացի, utPLSQL-ը պահում է ձեր բոլոր փորձնական գործարկումների մատյանը, ինչպես նաև ունի ներքին հաշվետվության համակարգ:
Դիտարկենք մի օրինակ, թե ինչ տեսք ունի միավորի թեստային կոդը, որն իրականացվել է այս տեխնիկայի միջոցով:
Այսպիսով, էկրանը ցույց է տալիս տիպիկ փաթեթի ճշգրտման կոդը՝ միավորի թեստերով: Որո՞նք են պարտադիր պահանջները: Փաթեթի նախածանցը պետք է լինի «utp_»: Թեստերով բոլոր ընթացակարգերը պետք է ունենան նույն նախածանցը: Փաթեթը պետք է պարունակի երկու ստանդարտ ընթացակարգ՝ «utp_setup» և «utp_teardown»: Առաջին ընթացակարգը կոչվում է յուրաքանչյուր միավորի թեստը վերագործարկելու միջոցով, երկրորդը՝ գործարկումից հետո:
«utp_setup»-ը, որպես կանոն, պատրաստում է մեր համակարգը միավորի թեստը գործարկելու համար, օրինակ՝ ստեղծելով թեստային տվյալներ: «utp_teardown» - ընդհակառակը, ամեն ինչ վերադառնում է սկզբնական կարգավորումներին և վերականգնում է գործարկման արդյունքները:
Ահա ամենապարզ միավորի թեստի օրինակը, որը ստուգում է մուտքագրված հաճախորդի հեռախոսահամարի նորմալացումը մեր հավատարմության համակարգի ստանդարտ ձևին: Չկան պարտադիր չափորոշիչներ, թե ինչպես կարելի է ընթացակարգեր գրել միավորի թեստերով: Որպես կանոն, զանգ է կատարվում փորձարկվող համակարգի մեթոդին, և այս մեթոդով վերադարձված արդյունքը համեմատվում է հղման հետ: Կարևոր է, որ հղման արդյունքի և ստացվածի համեմատությունը տեղի ունենա ստանդարտ utPLSQL մեթոդների միջոցով:
Միավոր թեստը կարող է ունենալ ցանկացած քանակությամբ ստուգումներ: Ինչպես երևում է օրինակից, մենք չորս անընդմեջ զանգ ենք կատարում փորձարկված մեթոդին՝ հեռախոսահամարը նորմալացնելու և յուրաքանչյուր զանգից հետո արդյունքը գնահատելու համար: Միավոր թեստ մշակելիս պետք է հաշվի առնել, որ կան ստուգումներ, որոնք ոչ մի կերպ չեն ազդում համակարգի վրա, և որոշ ժամանակ անց պետք է հետ գլորվել համակարգի սկզբնական վիճակին:
Օրինակ, ներկայացված միավորի թեստում մենք պարզապես ձևավորում ենք մուտքագրված հեռախոսահամարը, որը որևէ կերպ չի ազդում լոյալության համակարգի վրա։
Եվ եթե մենք գրում ենք միավորի թեստեր՝ օգտագործելով նոր հաճախորդ ստեղծելու մեթոդը, ապա յուրաքանչյուր թեստից հետո համակարգում կստեղծվի նոր հաճախորդ, որը կարող է ազդել թեստի հետագա գործարկման վրա։
Ահա թե ինչպես են կատարվում միավորի թեստերը: Գործարկման երկու հնարավոր տարբերակ կա՝ գործարկել բոլոր միավորի թեստերը կոնկրետ փաթեթից կամ կատարել կոնկրետ միավորի թեստ կոնկրետ փաթեթում:
Ահա թե ինչ տեսք ունի ներքին հաշվետվության համակարգի օրինակը: Հիմնվելով միավորի թեստի արդյունքների վրա՝ utPLSQL-ը ստեղծում է փոքր հաշվետվություն։ Դրանում մենք տեսնում ենք յուրաքանչյուր կոնկրետ ստուգման արդյունքը և միավորի թեստի ընդհանուր արդյունքը:
Ավտոթեստերի 6 կանոն
Նախքան հավատարմության համակարգի ավտոմատացված թեստավորման նոր համակարգի ստեղծումը սկսելը, ղեկավարության հետ միասին մենք որոշեցինք այն սկզբունքները, որոնց պետք է համապատասխանեն մեր ապագա ավտոմատացված թեստերը:
- Ավտոթեստերը պետք է արդյունավետ լինեն և պետք է օգտակար լինեն: Մենք ունենք հիանալի մշակողներ, որոնց անպայման պետք է նշել, քանի որ նրանցից ոմանք հավանաբար կտեսնեն այս զեկույցը, և նրանք հիանալի կոդ են գրում։ Բայց նույնիսկ նրանց հրաշալի ծածկագիրը կատարյալ չէ և ունի, ունի և կշարունակի պարունակել սխալներ։ Այս սխալները գտնելու համար պահանջվում են ավտոմատ թեստեր: Եթե դա այդպես չէ, ուրեմն կամ վատ ավտոթեստեր ենք գրում, կամ եկել ենք մի մեռյալ տարածք, որը սկզբունքորեն չի մշակվում։ Երկու դեպքում էլ մենք սխալ բան ենք անում, և մեր մոտեցումն ուղղակի իմաստ չունի։
- Պետք է օգտագործել ավտոմատ թեստեր: Անիմաստ է շատ ժամանակ և ջանք ծախսել ծրագրային արտադրանք գրելու վրա, այն դնել պահեստում և մոռանալ: Թեստերը պետք է իրականացվեն և հնարավորինս կանոնավոր լինեն:
- Ավտոթեստերը պետք է կայուն աշխատեն: Անկախ օրվա ժամից, գործարկման կանգառից և համակարգի այլ կարգավորումներից, փորձնական գործարկումները պետք է հանգեցնեն նույն արդյունքին: Որպես կանոն, դա ապահովվում է նրանով, որ ավտոմատ փորձարկումներն աշխատում են հատուկ թեստային տվյալների հետ՝ ֆիքսված համակարգի կարգավորումներով։
- Ավտոփորձարկումները պետք է աշխատեն ձեր նախագծի համար ընդունելի արագությամբ: Այս ժամանակը որոշվում է անհատապես յուրաքանչյուր համակարգի համար: Ոմանք կարող են իրենց թույլ տալ ամբողջ օրը աշխատել, իսկ ոմանք համարում են, որ կարևոր է դա անել վայրկյանների ընթացքում: Ես ձեզ մի փոքր ավելի ուշ կպատմեմ, թե արագության ինչ չափանիշների ենք հասել մեր նախագծում։
- Autotest-ի մշակումը պետք է լինի ճկուն: Ցանկալի չէ հրաժարվել որևէ ֆունկցիոնալության փորձարկումից, պարզապես այն պատճառով, որ մենք նախկինում դա չենք արել կամ ինչ-որ այլ պատճառով: utPLSQL-ը որևէ սահմանափակում չի դնում զարգացման վրա, և Oracle-ը, սկզբունքորեն, թույլ է տալիս իրականացնել տարբեր բաներ: Խնդիրների մեծ մասը լուծում ունի, դա պարզապես ժամանակի և ջանքերի հարց է:
- Տեղակայման հնարավորություն: Մենք ունենք մի քանի ստենդեր, որտեղ պետք է թեստեր անցկացնենք: Յուրաքանչյուր կանգառում տվյալների աղբանոցը կարող է թարմացվել ցանկացած պահի: Անհրաժեշտ է նախագիծ իրականացնել ավտոմատ թեստերով այնպես, որ կարողանաք առանց ցավի իրականացնել դրա ամբողջական կամ մասնակի տեղադրումը։
Իսկ երկրորդ գրառման մեջ մի երկու օրից կպատմեմ, թե ինչ արեցինք և ինչ արդյունքների հասանք։
Source: www.habr.com