Прывітанне, Хабр!
Мяне клічуць Максім Панамарэнка і я - распрацоўшчык у Спортмайстру. Маю 10-гадовы досвед працы ў IT-сферы. Пачынаў кар'еру ў галіне ручнога тэсціравання, затым пераключыўся на распрацоўку баз даных. Апошнія 4 гады, акумулюючы веды, атрыманыя ў тэсціраванні і распрацоўцы, займаюся аўтаматызацыяй тэсціравання на ўзроўні СКБД.
У камандзе Спартмайстра я знаходжуся крыху больш за год і на адным з буйных праектаў займаюся распрацоўкай аўтаматызаванага тэставання. У красавіку мы з хлопцамі з Sportmaster Lab выступалі на канферэнцыі ў Краснадары, мой даклад называўся "Unit-тэсты ў СКБД", і цяпер хачу падзяліцца ім з вамі. Тэкста будзе шмат, таму я вырашыў разбіць даклад на дзве пасады. У першым мы пагаворым аб аўтатэстах і тэставанні ўвогуле, а ў другім я падрабязней спынюся на нашай сістэме unit-тэставанні і выніках яе ўжывання.
Спачатку крыху сумнай тэорыі. Што такое аўтаматычнае тэсціраванне? Гэта тэсціраванне, якое праводзіцца праграмнымі сродкамі, і ў сучасным IT яно ўсё часцей і часцей выкарыстоўваецца пры распрацоўцы ПЗ. Звязана гэта з тым, што кампаніі растуць, растуць іх інфармацыйныя сістэмы і адпаведна расце і колькасць функцыяналу, якую трэба тэсціраваць. Праводзіць ручное тэставанне становіцца ўсё накладней і накладней.
Я працаваў у адной буйной кампаніі, рэлізы якой выходзяць раз на два месяцы. Пры гэтым цэлы месяц марнаваўся на тое, каб дзясятак тэсціроўшчыкаў рукамі правяралі функцыянал. Дзякуючы ўкараненню аўтаматызацыі невялікай камандай распрацоўшчыкаў нам удалося за паўтара года скараціць час тэсціравання да 2 тыдняў. Мы не толькі павялічылі хуткасць тэсціравання, але і павысілі яго якасць. Аўтаматычныя тэсты запускаюцца рэгулярна і яны заўсёды выконваюць увесь курс закладзеных у іх праверак, гэта значыць, мы выключаем чалавечы фактар.
Для сучаснага IT характэрны той факт, што ад распрацоўніка можа патрабавацца не толькі пісаць код прадукта, але пісаць unit-тэсты, якія дадзены код правяраюць.
Але што рабіць, калі ваша сістэма засноўваецца пераважна на сервернай логіцы? Нейкага ўніверсальнага рашэння і best practices на рынку не існуе. Як правіла, кампаніі вырашаюць гэтую праблему за рахунак стварэння ўласнай самапіснай сістэмы тэставання. Вось такая ўласная самапісная сістэма аўтаматызаванага тэсціравання была створана на нашым праекце і пра яе я раскажу ў сваім дакладзе.
Тэстуем лаяльнасць
Для пачатку пагаворым аб праекце, дзе мы разгарнулі сістэму аўтаматызаванага тэсціравання. Наш праект - гэта сістэма лаяльнасці Спортмайстра (дарэчы, мы ўжо пісалі пра яе ў ).
Калі ваша кампанія дастаткова буйная, то ваша сістэма лаяльнасці будзе валодаць трыма стандартнымі ўласцівасцямі:
- Ваша сістэма будзе высоканагружанай
- Ваша сістэма будзе змяшчаць складаныя вылічальныя працэсы
- Ваша сістэма будзе актыўна дапрацоўвацца.
Пойдзем па парадку ... У сукупнасці, калі разглядаць усе брэнды Спартмайстра, то на тэрыторыі Расіі, Украіны, Кітая, Казахстана і Беларусі ў нас больш за 1000 магазінаў. У гэтых крамах штодня ажыццяўляецца каля 300 000 пакупак. Гэта значыць кожную секунду ў нашу сістэму пападае 3-4 чэка. Натуральна, наша сістэма лаяльнасці з'яўляецца высоканагружанай. А раз ёю актыўна карыстаюцца, мы павінны прадастаўляць самыя высокія стандарты яе якасці, бо любая памылка ў ПЗ - гэта вялікія грашовыя, рэпутацыйнага і іншыя страты.
Адначасова ў Спортмайстры працуе больш за сотню розных акцый. Акцыі самыя розныя: ёсць таварныя, ёсць прымеркаваныя да дня тыдня, ёсць прывязаныя да канкрэтнай крамы, ёсць акцыі на суму чэка, ёсць на колькасць тавараў. Увогуле, няслаба. У кліентаў ёсць бонусы, ёсць промакоды, якія выкарыстоўваюцца пры пакупках. Усё гэта прыводзіць да таго, што аблік любой замовы - гэта вельмі нетрывіяльная задача.
Алгарытм, які рэалізуе апрацоўку замовы, сапраўды жудасны і складзены. І любое занясенне змен у гэты алгарытм - даволі рызыкоўная штука. Здавалася былі самыя вонкава малаважныя змены, могуць прыводзіць да дастаткова непрадказальных эфектаў. А бо менавіта такія складаныя вылічальныя працэсы, тым больш якія рэалізуюць крытычны функцыянал - лепшы кандыдат на аўтаматызацыю. Правяраць рукамі дзясяткі аднатыпных кейсаў вельмі накладна па часе. А так як кропка ўваходу ў працэс нязменная, то адзін раз апісаўшы яе, можна дастаткова хутка наштампаваць аўтаматычныя тэсты і быць упэўненым у працы функцыяналу.
Так як нашай сістэмай актыўна карыстаюцца, то бізнэс будзе хацець ад вас чагосьці новага, жыць у нагу з часам і быць кліентаарыентаваным. У нашай сістэме лаяльнасці рэлізы выходзяць раз на два месяцы. Значыць, кожныя два месяцы нам трэба праводзіць поўны рэгрэс усёй сістэмы. Пры гэтым, натуральна, як і ў любым сучасным IT, распрацоўка не пападае адразу ад распрацоўніка на прадакшн. Яна зараджаецца на контуры распрацоўніка, затым паслядоўна абміне тэставы стэнд, рэлізны, прыёмачны і толькі потым апыняецца на прадакшэне. Прынамсі на тэставым і на рэлізным контурах нам трэба праводзіць поўны рэгрэс усёй сістэмы.
Апісаныя ўласцівасці з'яўляюцца стандартнымі для практычна любой сістэмы лаяльнасці. Давайце пагаворым аб асаблівасцях нашага праекта.
Тэхналагічна на 90% логіка нашай сістэмы лаяльнасці серверная і рэалізаваная на Oracle. Ёсць выстаўлены кліент на Delphi, які выконвае функцыю Арм-адміністратара. Ёсць выстаўленыя вэб-сэрвісы для вонкавых прыкладанняў (напрыклад вэб-сайт). Таму вельмі лагічна, што калі мы будзем разгортваць сістэму аўтаматызаванага тэсціравання, то будзем рабіць гэта на Oracle.
Сістэма лаяльнасці ў Спортмайстры існуе больш за 7 гадоў і стваралася адзінкавымі распрацоўшчыкамі ... Сярэдняя колькасць распрацоўшчыкаў на нашым праекце на працягу гэтых 7 гадоў складала 3-4 чалавекі. Але за апошні год наша каманда моцна павялічылася, і зараз над праектам працуюць 10 чалавек. Гэта значыць, у праект прыходзяць людзі, якія не знаёмыя з тыпавымі задачамі, працэсамі, архітэктурай. І ёсць павышаная рызыка таго, што мы будзем прапускаць памылкі.
Для праекта характэрна адсутнасць выдзеленых тэсціроўшчыкаў як штатных адзінак. Тэсціраванне, безумоўна, ёсць, але тэсціраваннем займаюцца аналітыкі, акрамя сваіх іншых асноўных абавязкаў: па зносінам з бізнес-заказчыкамі, карыстальнікамі, прапрацоўкай патрабаванняў да сістэмы і г.д. і да т.п… Нягледзячы на тое, што тэставанне праводзіцца вельмі якасна (асабліва гэта дарэчы згадаць, бо камусьці з аналітыкаў можа трапіцца на вочы гэты даклад), эфектыўнасць спецыялізацыі і канцэнтрацыі на чымсьці адным ніхто не адмяняў.
Улічваючы ўсё вышэйсказанае, для падвышэння якасці выдаванага прадукта і памяншэнні тэрмінаў распрацоўкі, ідэя аўтаматызацыі тэставання на праекце здаецца вельмі лагічнай. І на розных этапах існавання сістэмы лаяльнасці асобныя распрацоўшчыкі рабілі намаганні, каб пакрыць свой код юніт-тэстамі. Гэта ў цэлым быў дастаткова разрознены працэс, дзе кожны выкарыстоўваў сваю архітэктуру і метады. Агульнымі для юніт-тэстаў былі выніковыя вынікі: выпрабаванні распрацоўваліся, нейкі час выкарыстоўваліся, складаліся ў версійнае сховішча файлаў, але ў нейкі момант пераставалі запускацца і забываліся. У першую чаргу гэта адбывалася па тым, што тэсты былі прывязаны больш да канкрэтнага выканаўцы, а не праекту.
На дапамогу прыходзіць utPLSQL
Ведаеце што-небудзь пра Стывена Феерштэйна?
Гэта разумны дзядзька, які доўгую частку сваёй кар'еры прысвяціў працы з Oracle і з PL/SQL, напісаў на гэтую тэму дастаткова вялікая колькасць прац. Адна вядомая яго кніга так і завецца: Oracle PL/SQL. Для прафесіяналаў». Менавіта Стывену належыць распрацоўка рашэння utPLSQL, ці, як яно расшыфроўваецца, Unit Testing framework for Oracle PL/SQL. Рашэнне utPLSQL было створана ў 2016 годзе, але над ім працягваюць актыўна працаваць і выпускаць новыя версіі. На момант даклада апошняя версія датуецца 24 сакавіка 2019 года.
Што ж гэта такое. Гэта асобны апенсарны праект. Важыць пару мегабайт з улікам прыкладаў і дакументацыі. Фізічна ўяўляе сабой асобную схему ў базе даных ORACLE з наборам пакетаў і табліц для арганізацыі юніт-тэставанні. Устаноўка займае некалькі секунд. Адметнай асаблівасцю utPLSQL з'яўляецца прастата эксплуатацыі.
Глабальна, utPLSQL уяўляе сабой механізм для запуску юніт-тэстаў, дзе пад юніт-тэстам разумеюцца звычайныя араклавыя пакетныя працэдуры, арганізацыя якіх адпавядае некаторым правілам. Апроч запуску ў utPLSQL захоўваецца лог усіх вашых тэставых запускаў, а таксама ёсць унутраная сістэма справаздачнасці.
Давайце паглядзім на прыкладзе, як выглядае код unit-тэсту, рэалізаваны па дадзенай методыцы.
Такім чынам, на экране прадстаўлены код тыпавой спецыфікацыі пакета з unit-тэстамі. Якія ёсць абавязковыя патрабаванні? Пакет павінен мець прэфікс "utp_". Дакладна такі ж прэфікс павінны мець усе працэдуры з тэстамі. У пакеце ў абавязковым парадку павінны прысутнічаць дзве стандартныя працэдуры: "utp_setup" і "utp_teardown". Першая працэдура выклікаецца перазапускам кожнага unit-тэсту, другая - пасля запуску.
"utp_setup", як правіла, падрыхтоўвае нашу сістэму да запуску unit-тэсту, напрыклад, стварае тэставыя дадзеныя. "utp_teardown" - наадварот, усё вяртае да зыходных налад і скідае вынікі запуску.
Вось прыклад самага простага unit-тэсту, які правярае нармалізацыю ўведзенага нумара тэлефона кліента да стандартнага для нашай сістэмы лаяльнасці ўвазе. Нейкіх абавязковых стандартаў, як пісаць працэдуры з unit-тэстамі, няма. Як правіла, ажыццяўляецца выклік якога-небудзь метаду тэстоўванай сістэмы, і вынік, вернуты дадзеным метадам, параўноўваецца з эталонным. Важна, каб параўнанне эталоннага выніку і атрыманым адбывалася праз стандартныя utPLSQL-ныя метады.
У юніт-тэсце можа быць любая колькасць праверак. Як відаць з прыкладу, мы робім чатыры паслядоўныя выклікі тэстоўванага метаду па нармалізацыі нумара тэлефона і пасля кожнага выкліку ацэньваем вынік. Пры распрацоўцы юніт-тэсту трэба ўлічваць, што існуюць праверкі, якія ніяк на сістэму не ўплываюць, а пасля некаторых трэба адкочвацца да зыходнага стану сістэмы.
Напрыклад, у прадстаўленым юніт-тэсце мы проста фарматуем уваходны нумар тэлефона, што ніяк на сістэму лаяльнасці не ўплывае.
А калі мы пішам юніт-тэсты па метадзе стварэння новага кліента, то пасля кожнай праверкі ў сістэме будзе створаны новы кліент, што можа ўплываць на наступны запуск тэста.
Вось так unit-тэсты запускаюцца. Дапушчальна два варыянты запуску: запуск усіх юніт-тэстаў з канкрэтнага пакета або запуск канкрэтнага юніт-тэсту ў канкрэтным пакеце.
Вось так выглядае прыклад унутранай сістэмы справаздачнасці. Па выніках працы юніт-тэсту utPLSQL будуе маленькую справаздачу. У ім мы бачым вынік па кожнай канкрэтнай праверцы і агульны вынік выкананьня юніт-тэсту.
6 правілаў аўтатэстаў
Перад тым як прыступаць да стварэння новай сістэмы аўтаматызаванага тэсціравання сістэмы лаяльнасці, сумесна з кіраўніцтвам мы вызначылі прынцыпы, якім нашы будучыя аўтатэсты павінны адпавядаць.
- Аўтатэсты павінны быць эфектыўнымі і павінны прыносіць карысць. У нас выдатныя распрацоўшчыкі, пра якіх абавязкова трэба сказаць, бо нехта з іх напэўна ўбачыць гэты даклад, і яны пішуць выдатны код. Але нават іх выдатны код не з'яўляецца ідэальным і змяшчаў, змяшчае і будзе змяшчаць памылкі. Аўтатэсты абавязаны гэтыя памылкі знаходзіць. Калі гэта не так, то альбо мы пішам дрэнныя аўтатэсты, альбо мы дашлі ў мёртвую вобласць, якая ў прынцыпе не дапрацоўваецца. У абодвух выпадках мы робім нешта не так, і наш падыход проста бессэнсоўны.
- Аўтатэсты павінны выкарыстоўвацца. Бессэнсоўна выдаткаваць кучу часу і сіл на напісанне праграмнага прадукта, скласці яго рэпазітар і забыцца. Тэсты павінны запускацца, і запускацца як мага рэгулярней.
- Аўтатэсты павінны працаваць стабільна. Незалежна ад часу сутак, стэнда запуску і іншых налад сістэмы, запускі тэстаў павінны прыводзіць да аднаго і таго ж рэзультату. Як правіла, гэта забяспечваецца тым, што аўтатэсты працуюць са спецыяльнымі тэставымі дадзенымі з зафіксаванымі наладамі сістэмы.
- Аўтатэсты павінны працаваць з прымальнай для вашага праекта хуткасцю. Дадзены час вызначаецца індывідуальна для кожнай сістэмы. Хтосьці можа сабе дазволіць працаваць цэлы дзень, а камусьці крытычна ўкладвацца за секунды. Якіх хуткасных нарматываў мы дабіліся ў нашым праекце, я раскажу крыху пазней.
- Распрацоўка аўтатэстаў павінна быць гнуткай. Непажадана адмаўляцца ад праверкі якога-небудзь функцыяналу проста таму, што мы так яшчэ не рабілі ці па нейкіх іншых перакананнях. utPLSQL не накладвае ніякіх абмежаванняў на распрацоўку, а Oracle у прынцыпе дазваляе рэалізоўваць самыя розныя рэчы. Большасць задач мае рашэнне, пытанне толькі ў часе і патрачаных намаганнях.
- Разгортванне. У нас некалькі стэндаў, дзе патрэбен запуск тэстаў. На кожным са стэндаў у любы момант можа быць абноўлены дамп з дадзенымі. Трэба весці праект з аўтатэстамі такім чынам, каб мець магчымасць бязбольна вырабляць яго поўную або частковую ўстаноўку.
А ў другім пасце праз пару дзён я раскажу, што мы зрабілі і якіх вынікаў дабіліся.
Крыніца: habr.com