Эй Хабр!
Менің атым Максим Пономаренко және мен Sportmaster компаниясында әзірлеушімін. Менің IT саласында 10 жылдық тәжірибем бар. Ол өз мансабын қолмен тестілеуден бастады, содан кейін мәліметтер базасын әзірлеуге ауысты. Соңғы 4 жылда тестілеу мен әзірлеуде алған білімімді жинақтай отырып, мен ДҚБЖ деңгейінде тестілеуді автоматтандырумен айналыстым.
Мен Sportmaster командасында болғаныма бір жылдан астам уақыт болды және ірі жобалардың бірінде автоматтандырылған тестілеуді дамытудамын. Сәуір айында Sportmaster Lab-тың жігіттері екеуміз Краснодарда өткен конференцияда сөз сөйледік, менің баяндамам «ДҚБЖ-дағы бірлік сынақтары» деп аталды, енді мен оны сіздермен бөліскім келеді. Мәтін көп болады, сондықтан есепті екі постқа бөлуді жөн көрдім. Біріншісінде біз автотесттер мен жалпы тестілеу туралы айтатын боламыз, ал екіншісінде мен біздің бірлік тестілеу жүйесіне және оны қолдану нәтижелеріне толығырақ тоқталамын.
Біріншіден, кішкене қызық теория. Автоматтандырылған тестілеу дегеніміз не? Бұл бағдарламалық қамтамасыз ету арқылы жүзеге асырылатын тестілеу және қазіргі заманғы АТ-да ол бағдарламалық жасақтаманы әзірлеуде көбірек қолданылады. Бұл компаниялардың өсіп келе жатқанына, олардың ақпараттық жүйелерінің өсуіне және сәйкесінше тестілеуді қажет ететін функционалдық мүмкіндіктердің көлемінің өсуіне байланысты. Қолмен тестілеуді өткізу барған сайын қымбаттауда.
Мен екі ай сайын шығарылымдары шығатын үлкен компанияда жұмыс істедім. Сонымен қатар, ондаған тестерлер функционалдылықты қолмен тексеруге бір ай жұмсалды. Әзірлеушілердің шағын тобының автоматтандыруды енгізуінің арқасында біз бір жарым жыл ішінде тестілеу уақытын 2 аптаға дейін қысқарта алдық. Біз тестілеу жылдамдығын арттырып қана қоймай, оның сапасын да арттырдық. Автоматтандырылған сынақтар жүйелі түрде іске қосылады және олар әрқашан оларға енгізілген тексерулердің барлық курсын жүргізеді, яғни біз адам факторын жоққа шығарамыз.
Қазіргі заманғы АТ әзірлеушіден өнім кодын жазуды ғана емес, сонымен қатар осы кодты тексеретін бірлік сынақтарын жазуды талап етуі мүмкін екендігімен сипатталады.
Бірақ сіздің жүйеңіз негізінен сервер логикасына негізделген болса ше? Нарықта әмбебап шешім немесе ең жақсы тәжірибе жоқ. Әдетте, компаниялар бұл мәселені өздерінің жазбаша тестілеу жүйесін құру арқылы шешеді. Бұл біздің жобамызда жасалған өзіміз жазған автоматтандырылған тестілеу жүйесі және мен бұл туралы өз баяндамамда айтатын боламын.
Адалдықты сынау
Біріншіден, біз автоматтандырылған тестілеу жүйесін енгізген жоба туралы сөйлесейік. Біздің жоба - бұл Sportmaster адалдық жүйесі (айтпақшы, біз бұл туралы бұрын жазғанбыз ).
Егер сіздің компанияңыз жеткілікті үлкен болса, сіздің адалдық жүйеңізде үш стандартты қасиет болады:
- Жүйеңіз жоғары жүктеледі
- Жүйеде күрделі есептеу процестері болады
- Жүйеңіз белсенді түрде жетілдіріледі.
Тәртіппен барайық... Жалпы Sportmaster брендтерінің барлығын қарастыратын болсақ, Ресейде, Украинада, Қытайда, Қазақстанда және Беларусьте 1000-нан астам дүкеніміз бар. Бұл дүкендерде күніне шамамен 300 000 сатып алу жасалады. Яғни, біздің жүйеге секунд сайын 3-4 чек кіреді. Әрине, біздің адалдық жүйеміз өте жүктелген. Және ол белсенді түрде қолданылғандықтан, біз оның сапасының ең жоғары стандарттарын қамтамасыз етуіміз керек, өйткені бағдарламалық жасақтамадағы кез келген қате үлкен ақшалай, беделді және басқа да шығындарды білдіреді.
Сонымен қатар, Sportmaster жүзден астам түрлі акцияларды өткізеді. Акциялардың алуан түрлілігі бар: өнімнің акциялары бар, аптаның күніне арналғандары бар, белгілі бір дүкенге байланғандары бар, түбіртек сомасына акциялар бар, тауар санына арналған акциялар бар. Жалпы, жаман емес. Клиенттерде сатып алу кезінде қолданылатын бонустар мен жарнамалық кодтар бар. Мұның бәрі кез келген тапсырысты есептеу өте тривиальды емес міндет екеніне әкеледі.
Тапсырысты өңдеуді жүзеге асыратын алгоритм шынымен қорқынышты және күрделі. Және бұл алгоритмге кез келген өзгертулер өте қауіпті. Ең елеусіз болып көрінетін өзгерістер күтпеген әсерлерге әкелуі мүмкін сияқты көрінді. Бірақ дәл осындай күрделі есептеу процестері, әсіресе маңызды функционалдылықты жүзеге асыратын процестер автоматтандыруға ең жақсы үміткерлер болып табылады. Ондаған ұқсас жағдайларды қолмен тексеру өте көп уақытты қажет етеді. Процесске кіру нүктесі өзгеріссіз болғандықтан, оны бір рет сипаттай отырып, сіз автоматты сынақтарды жылдам жасай аласыз және функционалдық жұмыс істейтініне сенімді бола аласыз.
Біздің жүйе белсенді түрде қолданылғандықтан, бизнес сізден жаңа нәрсені қалайды, уақытпен өмір сүреді және тұтынушыға бағдарланады. Біздің адалдық жүйемізде шығарылымдар екі ай сайын шығады. Бұл екі ай сайын біз бүкіл жүйенің толық регрессиясын жүргізуіміз керек дегенді білдіреді. Сонымен қатар, әрине, кез келген заманауи АТ-дағыдай, даму әзірлеушіден өндіріске бірден өтпейді. Ол әзірлеушінің тізбегінде пайда болады, содан кейін сынақ стендінен дәйекті түрде өтеді, босатылады, қабылданады, содан кейін ғана өндірісте аяқталады. Кем дегенде, сынақ және босату тізбектерінде біз бүкіл жүйенің толық регрессиясын жүргізуіміз керек.
Сипатталған сипаттар барлық дерлік адалдық жүйесі үшін стандартты болып табылады. Жобамыздың ерекшеліктеріне тоқталайық.
Технологиялық тұрғыдан алғанда, біздің адалдық жүйеміздің логикасының 90% серверге негізделген және Oracle жүйесінде жүзеге асырылады. Delphi-де жұмыс орнының автоматтандырылған әкімшісі қызметін атқаратын клиент ашылады. Сыртқы қолданбаларға арналған ашық веб-қызметтері бар (мысалы, веб-сайт). Сондықтан, егер біз автоматтандырылған тестілеу жүйесін енгізсек, оны Oracle-де жасайтынымыз өте қисынды.
Sportmaster-тегі адалдық жүйесі 7 жылдан астам жұмыс істеп келеді және оны жалғыз әзірлеушілер жасаған... Осы 7 жыл ішінде жобамыздағы әзірлеушілердің орташа саны 3-4 адамды құрады. Бірақ соңғы бір жылда біздің команда айтарлықтай өсті, қазір жобада 10 адам жұмыс істейді. Яғни, жобаға типтік тапсырмаларды, процестерді және архитектураны білмейтін адамдар келеді. Ал қателіктерді жіберіп алу қаупі артады.
Жоба штаттық бірлік ретінде арнайы тестілеушілердің болмауымен сипатталады. Әрине, тестілеу бар, бірақ тестілеуді талдаушылар басқа да негізгі міндеттерінен басқа жүзеге асырады: бизнес тұтынушылармен, пайдаланушылармен байланысу, жүйе талаптарын әзірлеу және т.б. т.б.... Тестілеу өте жоғары сапалы жүргізілгеніне қарамастан (бұл туралы ерекше атап өткен жөн, өйткені кейбір сарапшылар бұл есептің назарын аударуы мүмкін), бір нәрсеге мамандану мен шоғырланудың тиімділігі жойылған жоқ. .
Жоғарыда айтылғандардың барлығын ескере отырып, жеткізілетін өнімнің сапасын жақсарту және әзірлеу уақытын қысқарту үшін жобадағы тестілеуді автоматтандыру идеясы өте қисынды болып көрінеді. Ал адалдық жүйесінің өмір сүруінің әртүрлі кезеңдерінде жеке әзірлеушілер өздерінің кодтарын бірлік сынақтарымен қамтуға күш салды. Тұтастай алғанда, бұл әркім өз архитектурасы мен әдістерін қолданатын өте бөлек процесс болды. Соңғы нәтижелер бірлік сынақтары үшін ортақ болды: сынақтар әзірленді, біраз уақыт пайдаланылды, нұсқаланған файлдар қоймасында сақталды, бірақ бір сәтте олар жұмысын тоқтатты және ұмытылды. Біріншіден, бұл сынақтардың жобаға емес, нақты орындаушыға көбірек байланысты болуымен байланысты болды.
utPLSQL көмекке келеді
Сіз Стивен Фейерштейн туралы бірдеңе білесіз бе?
Бұл өз мансабының көп бөлігін Oracle және PL/SQL-пен жұмыс істеуге арнаған және осы тақырып бойынша көптеген жұмыстарды жазған ақылды жігіт. Оның әйгілі кітаптарының бірі: «Oracle PL/SQL. Кәсіби мамандар үшін». Бұл utPLSQL шешімін немесе, оның мағынасында Oracle PL/SQL үшін Unit Testing құрылымын жасаған Стивен болды. utPLSQL шешімі 2016 жылы жасалды, бірақ ол белсенді түрде жұмыс істеуді жалғастыруда және жаңа нұсқалары шығарылды. Есеп беру кезінде соңғы нұсқасы 24 жылдың 2019 наурызынан басталады.
Бұл не. Бұл бөлек ашық бастапқы жоба. Оның салмағы бірнеше мегабайт, соның ішінде мысалдар мен құжаттамалар. Физикалық тұрғыдан алғанда, бұл ORACLE дерекқорындағы бірлікті тестілеуді ұйымдастыруға арналған пакеттер мен кестелер жиынтығы бар жеке схема. Орнату бірнеше секундқа созылады. utPLSQL-тің айрықша ерекшелігі - оны пайдаланудың қарапайымдылығы.
Ғаламдық деңгейде utPLSQL бірлік сынақтарын іске қосу механизмі болып табылады, мұнда бірлік сынағы ұйымы белгілі ережелерге сәйкес келетін қарапайым Oracle пакеттік процедуралары ретінде түсініледі. Іске қосудан басқа, utPLSQL сіздің барлық сынақтарыңыздың журналын сақтайды, сонымен қатар ішкі есеп беру жүйесі бар.
Осы әдістемені қолдану арқылы жүзеге асырылатын бірлік сынақ коды қалай көрінетінінің мысалын қарастырайық.
Сонымен, экранда бірлік сынақтары бар типтік бума спецификациясының коды көрсетіледі. Міндетті талаптар қандай? Пакетке "utp_" префиксі қойылуы керек. Сынақтары бар барлық процедураларда дәл бірдей префикс болуы керек. Бумада екі стандартты процедура болуы керек: “utp_setup” және “utp_teardown”. Бірінші процедура әрбір бірлік сынауын қайта іске қосу арқылы шақырылады, екіншісі - іске қосылғаннан кейін.
“utp_setup”, әдетте, жүйемізді бірлік сынағын іске қосуға дайындайды, мысалы, сынақ деректерін жасау. «utp_teardown» - керісінше, бәрі бастапқы параметрлерге оралады және іске қосу нәтижелерін қалпына келтіреді.
Мұнда енгізілген тұтынушы телефон нөмірін біздің адалдық жүйеміз үшін стандартты пішінге қалыпқа келтіруді тексеретін қарапайым бірлік сынағының мысалы келтірілген. Бірлік сынақтарымен процедураларды жазудың міндетті стандарттары жоқ. Әдетте, тексерілетін жүйенің әдісіне шақыру жасалады және осы әдіс арқылы қайтарылған нәтиже анықтамалық әдіспен салыстырылады. Анықтамалық нәтиже мен алынған нәтижені салыстыру стандартты utPLSQL әдістері арқылы жүзеге асуы маңызды.
Бірлік сынағы тексерулердің кез келген санына ие болуы мүмкін. Мысалдан көрініп тұрғандай, біз телефон нөмірін қалыпқа келтіру және әрбір қоңыраудан кейін нәтижені бағалау үшін сынақтан өткен әдіске қатарынан төрт қоңырау шаламыз. Бірлік сынағы әзірлеген кезде жүйеге ешқандай әсер етпейтін тексерулер бар екенін ескеру керек және біраз уақыттан кейін жүйенің бастапқы күйіне оралу керек.
Мысалы, ұсынылған бірлік тестінде біз кіріс телефон нөмірін жай ғана пішімдейміз, бұл адалдық жүйесіне ешқандай әсер етпейді.
Ал егер біз жаңа клиентті құру әдісін қолданып бірлік сынақтарын жазсақ, онда әрбір сынақтан кейін жүйеде жаңа клиент жасалады, бұл тесттің келесі іске қосылуына әсер етуі мүмкін.
Бірлік сынақтары осылай орындалады. Екі ықтимал іске қосу опциясы бар: белгілі бір бумадан барлық бірлік сынақтарын орындау немесе белгілі бір бумада белгілі бір бірлік сынағын іске қосу.
Ішкі есеп беру жүйесінің мысалы осылай көрінеді. Бірлік сынағының нәтижелері бойынша utPLSQL шағын есеп құрастырады. Онда біз әрбір нақты тексерудің нәтижесін және бірлік сынағының жалпы нәтижесін көреміз.
Автотестілеудің 6 ережесі
Адалдық жүйесін автоматтандырылған тестілеудің жаңа жүйесін құруды бастамас бұрын, менеджментпен бірге біз болашақ автоматтандырылған сынақтарымыз сәйкес келетін принциптерді анықтадық.
- Автотесттер тиімді және пайдалы болуы керек. Бізде керемет әзірлеушілер бар, оларды сөзсіз атап өту керек, өйткені олардың кейбіреулері бұл есепті көріп, тамаша код жазады. Бірақ тіпті олардың тамаша коды мінсіз емес және қателер бар, бар және бола береді. Бұл қателерді табу үшін автотесттер қажет. Егер бұлай болмаса, онда біз нашар автотесттер жазамыз, немесе біз негізінен әзірленбеген өлі аймаққа келдік. Екі жағдайда да біз дұрыс емес нәрсе жасап жатырмыз және біздің көзқарасымыз мағынасыз.
- Автотесттерді қолдану керек. Бағдарламалық өнімді жазуға көп уақыт пен күш жұмсап, оны репозиторийге салып, ұмытып кетудің мағынасы жоқ. Сынақтарды орындау және мүмкіндігінше жүйелі түрде орындау керек.
- Автотесттер тұрақты жұмыс істеуі керек. Тәулік уақытына, іске қосу стендіне және басқа жүйе параметрлеріне қарамастан, сынақтар бірдей нәтижеге әкелуі керек. Әдетте, бұл автотесттердің бекітілген жүйе параметрлері бар арнайы сынақ деректерімен жұмыс істеуімен қамтамасыз етіледі.
- Автотесттер жобаңыз үшін қолайлы жылдамдықта жұмыс істеуі керек. Бұл уақыт әр жүйе үшін жеке анықталады. Кейбір адамдар күні бойы жұмыс істей алады, ал басқалары мұны бірнеше секундта жасау өте маңызды деп санайды. Біз жобамызда қандай жылдамдық стандарттарына қол жеткізгенімізді сәл кейінірек айтамын.
- Автотест әзірлеу икемді болуы керек. Кез келген функционалдылықты сынақтан бұрын орындамағандықтан немесе басқа себептермен бас тарту ұсынылмайды. utPLSQL әзірлеуге ешқандай шектеулер қоймайды және Oracle, негізінен, әртүрлі нәрселерді жүзеге асыруға мүмкіндік береді. Көптеген мәселелердің шешімі бар, бұл уақыт пен күш-жігер мәселесі.
- Орналастыру мүмкіндігі. Бізде сынақтарды өткізу қажет бірнеше стендтер бар. Әрбір стендте деректер қоқысын кез келген уақытта жаңартуға болады. Автоматты сынақтары бар жобаны оны толық немесе ішінара орнатуды ауыртпалықсыз жүзеге асыра алатындай етіп жүргізу қажет.
Ал бір-екі күнде не істеп, қандай нәтижеге қол жеткізгенімізді екінші постта айтамын.
Ақпарат көзі: www.habr.com