Јединични тестови у ДБМС - како то радимо у Спортмастеру, први део

Хеј Хабр!

Моје име је Максим Пономаренко и ја сам програмер у Спортмастеру. Имам 10 година искуства у ИТ области. Каријеру је започео у ручном тестирању, а затим је прешао на развој базе података. Последње 4 године, акумулирајући знања стечена у тестирању и развоју, аутоматизујем тестирање на нивоу ДБМС.

У Спортмастер тиму сам нешто више од годину дана и развијам аутоматизовано тестирање на једном од великих пројеката. У априлу смо момци из Спортмастер Лаб-а и ја разговарали на конференцији у Краснодару, мој извештај се звао „Тестови јединица у ДБМС-у“, а сада желим да га поделим са вама. Биће много текста, па сам одлучио да извештај поделим на два поста. У првом ћемо говорити о аутотестовима и тестирању уопште, а у другом ћу се детаљније задржати на нашем систему за тестирање јединица и резултатима његове примене.

Прво, мало досадна теорија. Шта је аутоматизовано тестирање? Реч је о тестирању које се спроводи коришћењем софтвера, а у савременим ИТ се све више користи у развоју софтвера. То је због чињенице да компаније расту, њихови информациони системи расту и, сходно томе, расте количина функционалности коју треба тестирати. Спровођење ручног тестирања постаје све скупље.

Радио сам за велику компанију чија издања излазе свака два месеца. У исто време, цео месец је потрошено на то да десетак тестера ручно провери функционалност. Захваљујући имплементацији аутоматизације од стране малог тима програмера, успели смо да смањимо време тестирања на 2 недеље за годину и по дана. Не само да смо повећали брзину тестирања, већ смо побољшали и његов квалитет. Аутоматизовани тестови се покрећу редовно и они увек спроводе цео ток провера који су у њих укључени, односно искључујемо људски фактор.

Савремени ИТ карактерише чињеница да се од програмера може захтевати не само да напише код производа, већ и да напише јединичне тестове који проверавају овај код.

Али шта ако је ваш систем заснован првенствено на логици сервера? Не постоји универзално решење или најбоља пракса на тржишту. По правилу, компаније решавају овај проблем стварањем сопственог система тестирања који се пише. Ово је наш сопствени систем аутоматизованог тестирања који је креиран на нашем пројекту и о томе ћу говорити у свом извештају.

Тестирање лојалности

Прво, хајде да причамо о пројекту где смо поставили аутоматизовани систем за тестирање. Наш пројекат је систем лојалности Спортмастер (о томе смо већ писали у овај пост).

Ако је ваша компанија довољно велика, онда ће ваш систем лојалности имати три стандардна својства:

• Ваш систем ће бити веома оптерећен
• Ваш систем ће садржати сложене рачунарске процесе
• Ваш систем ће се активно побољшавати.

Идемо редом... Укупно, ако узмемо у обзир све брендове Спортмастер, онда имамо више од 1000 продавница у Русији, Украјини, Кини, Казахстану и Белорусији. У овим продавницама се сваког дана обави око 300 куповине. То јест, сваке секунде 000-3 провере улазе у наш систем. Наравно, наш систем лојалности је веома оптерећен. А пошто се активно користи, морамо обезбедити највише стандарде његовог квалитета, јер свака грешка у софтверу значи велике новчане, репутационе и друге губитке.

Истовремено, Спортмастер води више од стотину различитих промоција. Постоје разне промоције: постоје промоције производа, постоје оне посвећене дану у недељи, постоје оне везане за одређену продавницу, постоје промоције за износ рачуна, постоје за број робе. Генерално, није лоше. Клијенти имају бонусе и промотивне кодове који се користе приликом куповине. Све ово доводи до чињенице да је израчунавање било ког реда веома нетривијалан задатак.

Алгоритам који имплементира обраду налога је заиста ужасан и компликован. И било какве промене овог алгоритма су прилично ризичне. Чинило се да наизглед безначајне промене могу довести до прилично непредвидивих ефеката. Али управо су такви сложени рачунарски процеси, посебно они који имплементирају критичну функционалност, најбољи кандидати за аутоматизацију. Ручна провера десетина сличних случајева одузима много времена. А пошто је улазна тачка у процес непромењена, након што сте је једном описали, можете брзо креирати аутоматске тестове и бити сигурни да ће функционалност функционисати.

Пошто се наш систем активно користи, предузеће ће желети нешто ново од вас, живети у складу са временом и бити оријентисани на купца. У нашем систему лојалности, издања излазе свака два месеца. То значи да свака два месеца треба да извршимо потпуну регресију целог система. У исто време, природно, као иу сваком модерном ИТ-у, развој не иде одмах од програмера до производње. Настаје у кругу програмера, затим сукцесивно пролази кроз тестни сто, ослобађа, прихвата, и тек онда завршава у производњи. У најмању руку, на круговима за тестирање и ослобађање, потребно је да извршимо потпуну регресију целог система.

Описана својства су стандардна за скоро сваки систем лојалности. Хајде да причамо о карактеристикама нашег пројекта.

Технолошки, 90% логике нашег система лојалности је засновано на серверу и имплементирано на Орацле. У Делпхију је изложен клијент, који обавља функцију аутоматизованог администратора радног места. Постоје изложене веб услуге за спољне апликације (на пример, веб локација). Због тога је врло логично да ако применимо аутоматизовани систем за тестирање, то урадимо на Орацле-у.

Систем лојалности у Спортмастер-у постоји више од 7 година и креирали су га појединачни програмери... Просечан број програмера на нашем пројекту током ових 7 година је био 3-4 особе. Али током протекле године наш тим је значајно порастао и сада на пројекту ради 10 људи. Односно, у пројекат долазе људи који нису упознати са типичним задацима, процесима и архитектуром. И повећан је ризик да ћемо пропустити грешке.

Пројекат карактерише одсуство наменских тестера као јединица особља. Постоји, наравно, тестирање, али тестирање спроводе аналитичари, поред својих других главних одговорности: комуникација са пословним корисницима, корисницима, развој системских захтева итд. итд... Упркос чињеници да се тестирање обавља веома квалитетно (ово је посебно умесно напоменути, јер неки од аналитичара могу запасти за око у овом извештају), ефикасност специјализације и концентрације на једну ствар није поништена .

Узимајући у обзир све наведено, за побољшање квалитета испорученог производа и смањење времена развоја, идеја о аутоматизацији тестирања на пројекту делује врло логично. И у различитим фазама постојања система лојалности, појединачни програмери су се трудили да свој код покрију тестовима јединица. Све у свему, то је био прилично неповезан процес, при чему је свако користио своју архитектуру и методе. Коначни резултати су били заједнички за тестове јединица: тестови су развијени, коришћени неко време, ускладиштени у верзионисаном складишту датотека, али су у неком тренутку престали да раде и били заборављени. Пре свега, то је било због чињенице да су тестови били везани више за одређеног извођача, а не за пројекат.

утПЛСКЛ долази у помоћ

Да ли знате нешто о Степхену Феуерстеину?

Ово је паметан момак који је дуг део своје каријере посветио раду са Орацле-ом и ПЛ/СКЛ-ом, и написао је прилично велики број радова на ову тему. Једна од његових познатих књига зове се: „Орацле ПЛ/СКЛ. За професионалце." Стивен је био тај који је развио утПЛСКЛ решење, или, како то значи, оквир за тестирање јединица за Орацле ПЛ/СКЛ. УтПЛСКЛ решење је креирано 2016. године, али се и даље активно ради на њему и излазе нове верзије. У време извештавања, најновија верзија датира од 24. марта 2019.
Шта је то. Ово је посебан пројекат отвореног кода. Тешка је неколико мегабајта, укључујући примере и документацију. Физички, то је посебна шема у бази података ОРАЦЛЕ са скупом пакета и табела за организовање тестирања јединица. Инсталација траје неколико секунди. Карактеристична карактеристика утПЛСКЛ-а је његова лакоћа коришћења.
У глобалу, утПЛСКЛ је механизам за покретање јединичних тестова, где се јединични тест подразумева као обичне Орацле групне процедуре, чија организација следи одређена правила. Поред покретања, утПЛСКЛ складишти евиденцију свих ваших тестних покретања, а такође има и интерни систем извештавања.

Хајде да погледамо пример како изгледа код за тестирање јединице, имплементиран овом техником.

Дакле, екран приказује код за типичну спецификацију пакета са јединичним тестовима. Који су обавезни захтеви? Пакет мора имати префикс "утп_". Све процедуре са тестовима морају имати потпуно исти префикс. Пакет мора да садржи две стандардне процедуре: „утп_сетуп“ и „утп_теардовн“. Прва процедура се позива поновним покретањем сваког теста јединице, друга - након покретања.

„утп_сетуп“, по правилу, припрема наш систем за покретање јединичног теста, на пример, креирање тестних података. „утп_теардовн“ - напротив, све се враћа на првобитна подешавања и ресетује резултате покретања.

Ево примера најједноставнијег јединичног теста који проверава нормализацију унетог броја телефона корисника на стандардни образац за наш систем лојалности. Не постоје обавезни стандарди о томе како писати процедуре са јединичним тестовима. По правилу се позива методу система који се тестира, а резултат који ова метода враћа се упоређује са референтним. Важно је да се поређење референтног резултата и добијеног одвија путем стандардних утПЛСКЛ метода.

Јединични тест може имати било који број провера. Као што се може видети из примера, вршимо четири узастопна позива тестираној методи да бисмо нормализовали број телефона и проценили резултат након сваког позива. Када развијате јединични тест, морате узети у обзир да постоје провере које ни на који начин не утичу на систем, а након неких морате да се вратите у првобитно стање система.
На пример, у приказаном јединичном тесту једноставно форматирамо улазни број телефона, што ни на који начин не утиче на систем лојалности.

А ако пишемо јединичне тестове користећи методу креирања новог клијента, онда ће се након сваког теста креирати нови клијент у систему, што може утицати на накнадно покретање теста.

Овако се изводе тестови јединица. Постоје две могуће опције покретања: покретање свих тестова јединица из одређеног пакета или покретање специфичног теста јединице у одређеном пакету.

Овако изгледа пример интерног система извештавања. На основу резултата теста јединице, утПЛСКЛ прави мали извештај. У њему видимо резултат за сваку конкретну проверу и укупан резултат јединичног теста.

6 правила аутотестова

Пре него што смо започели креирање новог система за аутоматизовано тестирање система лојалности, заједно са менаџментом, утврдили смо принципе са којима треба да се придржавају наши будући аутоматизовани тестови.

1. Аутотестови морају бити ефикасни и корисни. Имамо дивне програмере, које свакако треба поменути, јер ће неки од њих вероватно видети овај извештај, и пишу диван код. Али чак ни њихов дивни код није савршен и има, има и наставиће да садржи грешке. Аутотестови су потребни да би се пронашле ове грешке. Ако то није случај, онда или пишемо лоше аутотестове, или смо дошли до мртве области која се, у принципу, не развија. У оба случаја радимо нешто погрешно, а наш приступ једноставно нема смисла.
2. Треба користити аутотестове. Нема смисла трошити много времена и труда на писање софтверског производа, стављати га у спремиште и заборавити. Тестове треба изводити, и то што је могуће редовно.
3. Аутотестови би требало да раде стабилно. Без обзира на доба дана, штанд за лансирање и друга подешавања система, пробни радови би требало да доведу до истог резултата. По правилу, то је осигурано чињеницом да аутотестови раде са посебним подацима теста са фиксним системским поставкама.
4. Аутотестови би требало да раде брзином прихватљивом за ваш пројекат. Ово време се одређује појединачно за сваки систем. Неки људи могу приуштити да раде цео дан, док други сматрају да је критично да то ураде за неколико секунди. Рећи ћу вам мало касније које смо стандарде брзине постигли у нашем пројекту.
5. Развој аутотестирања треба да буде флексибилан. Није препоручљиво одбити тестирање било које функционалности само зато што то нисмо урадили раније или из неког другог разлога. утПЛСКЛ не намеће никаква ограничења у развоју, а Орацле вам у принципу омогућава да имплементирате разне ствари. Већина проблема има решење, само је питање времена и труда.
6. Могућност распоређивања. Имамо неколико штандова на којима треба да извршимо тестове. На сваком штанду, думп података се може ажурирати у било ком тренутку. Неопходно је спровести пројекат са аутоматским тестовима на такав начин да можете безболно извршити његову пуну или делимичну инсталацију.

А у другом посту за пар дана ћу вам рећи шта смо урадили и које смо резултате постигли.

Извор: ввв.хабр.цом