Unit-тэсты ў СКБД - як мы робім гэта ў Спортмайстры, частка другая

Першая частка тут.

Уявіце сітуацыю. Перад вамі стаіць задача распрацоўкі новага функцыяналу. У вас ёсць напрацоўкі ад вашых папярэднікаў. Калі меркаваць, што вы ніякіх маральных абавязацельстваў не маеце, то як бы вы зрабілі?

Часцей за ўсё ўсе старыя напрацоўкі падвяргаюцца забыццю і ўсё пачынаецца спачатку. У чужым кодзе капацца ніхто не кахае, а пры наяўнасці часу чаму б не заняцца стварэннем уласнай сістэмы? Гэта тыповы падыход, і ён шмат у чым правільны. Але ў сваім праекце мы зрабілі не так. У аснову будучай сістэмы аўтаматычнага тэсціравання мы заклалі напрацоўкі па unit-тэстах на utPLSQL ад папярэднікаў, а затым пайшлі працаваць у некалькіх паралельных напрамках.

1. Аднаўленне старых unit-тэстаў. Пад аднаўленнем разумеецца адаптацыя тэстаў пад наяўны стан сістэмы лаяльнасці і адаптацыя тэстаў пад стандарты utPLSQL.
2. Рашэнне праблемы з разуменнем, а што менавіта, якія метады і працэсы, у нас пакрыты аўтатэстамі. Трэба альбо гэтую інфармацыю памятаць, альбо рабіць высновы на падставе непасрэдна кода аўтатэстаў. Таму мы вырашылі сфарміраваць каталог. Кожнаму аўтатэсту мы прысвоілі ўнікальны мнемокод, сфарміравалі апісанне і зафіксавалі налады (напрыклад, у якіх умовах ён павінен запускацца, ці што павінна адбывацца, калі запуск тэсту завяршыўся няўдачай). Па сутнасці, мы запоўнілі метададзеныя аб аўтатэстах і змясцілі гэтыя метададзеныя ў стандартныя табліцы схемы utPLSQL.
3. Вызначэнне стратэгіі пашырэння, г.зн. выбар функцыяналу, які падлягае праверцы аўтатэстамі. Мы вырашылі звярнуць увагу на тры рэчы: новыя дапрацоўкі сістэмы, інцыдэнты з прадакшэнам і ключавыя працэсы сістэмы. Такім чынам, мы развіваемся паралельна з рэлізам, забяспечваючы больш высокую яго якасць, адначасна пашыраем аб'ём рэгрэсу і забяспечваем надзейнасць сістэмы ў крытычных месцах. Першым такім вузкім месцам стаў працэс размеркавання скідак і бонусаў па чэку.
4. Натуральна, мы заняліся распрацоўкай новых аўтатэстаў. Адной з першых рэлізных задач стала ацэнка прадукцыйнасці наканаваных выбарак сістэмы лаяльнасці. У нашым праекце ёсць блок цвёрда зафіксаваных sql-запытаў, якія адбіраюць кліентаў па ўмовах. Напрыклад, атрымаць спіс усіх кліентаў, апошняя купля якіх была ў канкрэтным горадзе, або спіс кліентаў, сярэдняя сума пакупкі якіх вышэй вызначанага значэння. Напісаўшы аўтатэсты, мы праверылі наканаваныя выбаркі, зафіксавалі эталонныя параметры прадукцыйнасці, а дадаткова ў нас з'явіліся нагрузачнае тэсціраванне.
5. Праца з аўтатэстамі павінна быць зручнай. Найбольш часта здзяйсняюцца два дзеянні: запуск аўтатэстаў і стварэнне тэставых дадзеных. Так у нашай сістэме з'явіліся два дапаможныя модулі: модуль запуску і модуль генерацыі дадзеных.

   Модуль запуску прадстаўлены ў выглядзе адной універсальнай працэдуры з адным уваходным тэкставым параметрам. У якасці параметру можна перадаваць мнемокод аўтатэста, назоў пакета, назоў тэсту, наладу аўтатэста або зарэзерваванае ключавое слова. Працэдура адбірае і запускае ўсе аўтатэсты, якія задавальняюць умовам.

   Модуль генерацыі дадзеных прадстаўлены ў выглядзе пакета, у якім для кожнага аб'екта тэсціруемай сістэмы (табліца ў БД), створана спецыяльная працэдура, якая ўстаўляе туды дадзеныя. У дадзенай працэдуры максімальна запоўненыя дэфолтныя значэнні, што забяспечвае стварэнне аб'ектаў літаральна па пстрычцы пальцаў. І для зручнасці выкарыстання былі створаны шаблоны дадзеных, якія ствараюцца. Напрыклад, стварыць кліента пэўнага ўзросту з тэставым тэлефонам і здзейсненай пакупкай.

6. Аўтатэсты павінны запускацца і працаваць за прымальны для вашай сістэмы час. Таму быў арганізаваны штодзённы начны запуск, па выніках якога фарміруецца справаздача аб выніках і рассылаецца ўсёй камандзе распрацоўкі па карпаратыўнай пошце. Пасля аднаўлення старых аўтатэстаў і стварэння новых агульны час працы складаў 30 хвілін. Падобная прадукцыйнасць усіх уладкоўвала, бо запуск праходзіў у пазапрацоўны час.

   Але над аптымізацыяй хуткасці працы прыйшлося папрацаваць. Абнаўленне сістэмы лаяльнасці на прадакшэне праводзіцца ноччу. У рамках аднаго з рэлізаў ноччу прыйшлося экстрана ўносіць змены. Паўгадзіннае чаканне вынікаў аўтатэстаў у тры гадзіны ночы не зрабіла адказнага за рэліз шчаслівым (палымянае прывітанне Аляксею Васюкову!), а на наступную раніцу ў бок нашай сістэмы было сказана шмат цёплых слоў. Але па выніках быў устаноўлены 5-хвілінны нарматыў на працу.

   Для паскарэння прадукцыйнасці мы скарысталіся двума метадамі: аўтатэсты сталі запускацца ў трох паралельных патоках, балазе гэта вельмі зручна з-за архітэктуры нашай сістэмы лаяльнасці. І мы адмовіліся ад падыходу, калі аўтатэст не стварае для сябе тэставыя дадзеныя, а спрабуе знайсці ў сістэме нешта прыдатнае. Пасля ўнясення змен агульны час працы скараціўся да 3-4 хвілін.

7. Праект з аўтатэстамі трэба магчы разгортваць на розных стэндах. У пачатку шляху былі спробы напісаць уласныя батнікі, але стала зразумела, што самапісная аўтаматызаваная ўстаноўка - гэта поўны жах, і мы звярнуліся ў бок прамысловых рашэнняў. У сувязі з тым, што ў праекце вельмі шмат непасрэдна кода (у першую чаргу мы захоўваем код аўтатэстаў) і вельмі мала дадзеных (асноўныя дадзеныя – гэта метададзеныя аб аўтатэстах), то вельмі простым аказалася ўкараненне ў праект Liquibase.

   Гэта незалежная ад базы дадзеных бібліятэка з адчыненым зыходным кодам для адсочвання, кіраванні і ўжыванні змен схемы базы дадзеных. Кіруецца з дапамогай каманднага радка або фрэймворкаў тыпу Apache Maven. Прынцып працы Liquibase дастаткова просты. У нас ёсць арганізаваны вызначанай выявай праект, які складаецца са змен або скрыптоў, якія трэба накатваць на мэтавы сервер, і кіравальныя файлы, якія вызначаюць, у якой паслядоўнасці і з якімі параметрамі дадзеныя змены трэба ўсталёўваць.

   На ўзроўні СКБД ствараецца спецыяльная табліца, у якой Liquibase захоўвае лог накатаў. Кожная змена мае разлічаны хэш, які кожны раз параўноўваецца паміж праектам і станам у базе. Дзякуючы Liquibase мы лёгка накатваем змены нашай сістэмы на любы контур. Аўтатэсты зараз запускаюцца на тэставым і рэлізным контурах, а таксама на кантэйнерах (асабістых контурах распрацоўшчыкаў).

Такім чынам, давайце пагаворым аб выніках ужывання нашай сістэмы unit-тэставанні.

1. Вядома ж, у першую чаргу, мы перакананыя, што пачалі распрацоўваць больш якаснае ПЗ. Аўтатэсты запускаюцца штодня і ежарэлізна знаходзяць дзясяткі памылак. Прытым частка гэтых памылак толькі ўскосна звязана з функцыяналам, які мы рэальна хацелі памяняць. Ёсць вялікія сумневы, што гэтыя памылкі былі знойдзеныя ручным тэсціраваннем.
2. У каманды з'явілася ўпэўненасць, што канкрэтны функцыянал працуе карэктна… Найперш гэта тычыцца нашых крытычных працэсаў. Напрыклад, за апошнія паўгода ў нас не было праблем з размеркаваннем скідак і бонусаў па чэку, нягледзячы на ​​ежерелизные змены, хоць у папярэднія перыяды з некаторай перыядычнасцю памылкі ўзнікалі
3. Нам удалося скараціць колькасць ітэрацый тэсціравання. Дзякуючы таму, што аўтатэсты пішуцца на новы функцыянал, да аналітыкаў і па сумяшчальніцтве тэсціроўшчыкам трапляе код больш высокай якасці, т.я. ён ужо быў правераны.
4. Частка напрацовак аўтаматызаванага тэсціравання выкарыстоўваецца распрацоўшчыкамі. Напрыклад, тэставыя дадзеныя на кантэйнерах ствараюцца з дапамогай модуля генерацыі аб'ектаў.
5. Немалаважна, што ў нас склалася «прыняцце» сістэмы аўтаматызаванага тэсціравання з боку распрацоўшчыкаў. Ёсць разуменне, што гэта важна і карысна. А па сваім досведзе магу сказаць, што гэта далёка не так. Аўтатэсты трэба пісаць, іх трэба падтрымліваць і развіваць, аналізаваць вынікі, а часта гэтыя часовыя выдаткі проста таго не вартыя. Нашмат прасцей схадзіць на прадакшн і там разбірацца з праблемамі. У нас жа распрацоўшчыкі выстройваюцца ў чаргу і просяць пакрыць іх функцыянал аўтатэстамі.

Што далей

Давайце пагаворым аб планах развіцця праекта па аўтаматызаваным тэсціраванні.

Безумоўна, пакуль сістэма лаяльнасці Спартмайстра жывая і працягвае развівацца, можна таксама практычна бясконца развіваць аўтатэсты. Таму асноўны напрамак развіцця - гэта пашырэнне зоны пакрыцця.

Па меры павелічэння колькасці аўтатэстаў няўхільна будзе расці агульны час іх працы, і нам ізноў давядзецца вярнуцца да пытання прадукцыйнасці. Хутчэй за ўсё, рашэнне будзе ў павелічэнні колькасці раўналежных струменяў.

Але гэта відавочныя шляхі развіцця. Калі казаць пра нешта больш нетрывіяльнае, вылучым наступнае:

1. Цяпер кіраванне аўтатэстамі выконваецца на ўзроўні СКБД, г.зн. патрэбныя веды PL/SQL для паспяховай працы. Па неабходнасці кіраванне сістэмай (напрыклад, ажыццяўленне запускаў ці стварэнне метададзеных) можна вынесці нейкую адмінку, выкарыстаўшы Jenkins ці нешта аналагічнае.
2. Усе любяць колькасныя і якасныя паказчыкі. Для аўтаматычнага тэсціравання такім універсальным паказчыкам з'яўляецца Code Coverage або метрыка пакрыцця кода. Пры дапамозе дадзенага паказчыка мы можам вызначыць, які працэнт кода нашай тэсціруемай сістэмы пакрываецца аўтатэстамі. Пачынальна з версіі 12.2 Oracle падае магчымасці па разліку дадзенай метрыкі і прапануе выкарыстаць стандартны пакет DBMS_PLSQL_CODE_COVERAGE.

   Нашай сістэме аўтатэставання крыху больш за год і, магчыма, зараз самы час для ацэнкі пакрыцця. У маім мінулым праекце (праект не Спартмайстра) так і атрымалася. Праз год пасля працы над аўтатэстамі кіраўніцтва паставіла задачу ацаніць, які адсотак кода мы пакрываем. Пры пакрыцці больш за 1% кіраўніцтва было б шчасліва. Мы, распрацоўшчыкі, чакалі вынік каля 10%. Прыкруцілі code coverage, замерылі, атрымалі 20%. На радасцях адправіліся за прэміяй, але як мы за ёй схадзілі і куды накіраваліся пазней, гэта зусім іншая гісторыя.

3. Аўтатэсты могуць правяраць выстаўленыя вэб-сэрвісы. Oracle цалкам дазваляе гэта рабіць, а мы больш не сустрэнем цэлы шэраг праблем.
4. І, натуральна, нашу сістэму аўтаматызаванага тэсціравання можна прымяніць на іншым праекце. Атрыманае намі рашэнне з'яўляецца ўніверсальным і ўсяго толькі патрабуе выкарыстання Oracle. Я чуў, што на іншых праектах Спартмайстра ёсць зацікаўленасць у аўтаматычным тэсціраванні і, магчыма, мы адправімся да іх.

Высновы

Давайце падсумуем. На праекце сістэма лаяльнасці ў Спортмайстры нам удалося рэалізаваць сістэму аўтаматызаванага тэсціравання. Базісам яе з'яўляецца рашэнне utPLSQL ад Стывена Феерштэйна. Вакол utPLSQL размешчаны код аўтатэстаў і дапаможныя самапісныя модулі: модуль запуску, модуль генерацыі дадзеных і іншыя. Аўтатэсты штодня запускаюцца і, што найважнейшае, працуюць і прыносяць карысць. Мы перакананыя, што пачалі выпускаць ПЗ больш высокай якасці. Пры гэтым атрыманае рашэнне ўніверсальна і можа быць свабодна прыменена на любым праекце, дзе неабходна арганізаваць аўтаматызаванае тэсціраванне на СКБД Аракл.

PS Гэты артыкул атрымаўся не вельмі канкрэтным: тут шмат тэксту і практычна адсутнічаюць тэхнічныя прыклады. Калі глабальна тэматыка цікавая, то мы гатовы яе прадоўжыць і вярнуцца з працягам, дзе раскажам, што змянілася за мінулыя паўгода і прывесці прыклады кода.

Пішыце каментары, калі ёсць моманты, на якіх варта зрабіць акцэнт у будучыні, ці пытанні, якія патрабуюць раскрыцця.

Толькі зарэгістраваныя карыстачы могуць удзельнічаць у апытанні. Увайдзіце, Калі ласка.

Пішам далей пра такое?

• Так, вядома

• Не Дзякуй

Прагаласавалі 12 карыстальнікаў. Устрымаліся 4 карыстальніка.

Крыніца: habr.com