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

Први део - овде.

Замислите ситуацију. Суочени сте са задатком развоја нове функционалности. Имате помаке од својих претходника. Ако претпоставимо да немате моралних обавеза, шта бисте урадили?

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

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

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

   Модул за генерисање података је представљен у виду пакета у коме је за сваки објекат тестираног система (табела у бази података) креирана посебна процедура која ту убацује податке. У овој процедури, подразумеване вредности се попуњавају што је више могуће, што обезбеђује стварање објеката буквално на клик прста. А ради лакшег коришћења, креирани су шаблони за генерисане податке. На пример, направите клијента одређеног узраста са тестним телефоном и обављеном куповином.

6. Аутоматски тестови би требало да почну и раде у времену које је прихватљиво за ваш систем. Због тога је организовано дневно ноћно лансирање на основу чијих резултата се генерише извештај о резултатима и шаље се целом развојном тиму корпоративном поштом. Након обнављања старих аутотестова и креирања нових, укупно време рада је било 30 минута. Ова представа је свима пријала, пошто је лансирање одржано ван радног времена.

   Али морали смо да радимо на оптимизацији брзине рада. Систем лојалности у производњи се ажурира ноћу. У оквиру једног од издања морали смо да извршимо хитне промене ноћу. Пола сата чекања на резултате аутотестова у три ујутру није обрадовало особу одговорну за ослобађање (горљиви поздрав Алексеју Васјукову!), а следећег јутра је изречено много лепих речи на рачун нашег система. Али као резултат, успостављен је 5-минутни стандард за рад.

   Да бисмо убрзали перформансе, користили смо две методе: аутотестови су почели да раде у три паралелне нити, на срећу, ово је веома згодно због архитектуре нашег система лојалности. И напустили смо приступ где аутотест не креира тестне податке за себе, већ покушава да пронађе нешто прикладно у систему. Након извршених измена, укупно време рада је смањено на 3-4 минута.

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

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

   На нивоу ДБМС-а креира се посебна табела у којој Ликуибасе чува дневник преласка. Свака промена има израчунати хеш, који се сваки пут пореди између пројекта и стања у бази података. Захваљујући Ликуибасе-у, лако можемо да уведемо промене у наш систем на било које коло. Аутоматски тестови се сада покрећу на круговима за тестирање и ослобађање, као и на контејнерима (лична кола програмера).

Дакле, хајде да причамо о резултатима коришћења нашег система за тестирање јединица.

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

Шта је следеће

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

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

Како се број аутотестова повећава, њихово укупно време рада ће се стално повећавати и поново ћемо се морати вратити на питање перформанси. Највероватније ће решење бити повећање броја паралелних нити.

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

1. Тренутно се управљање аутотестом врши на нивоу ДБМС, тј. за успешан рад потребно је познавање ПЛ/СКЛ-а. Ако је потребно, управљање системом (на пример, покретање или креирање метаподатака), можете креирати неку врсту административног панела користећи Јенкинс или нешто слично.
2. Сви воле квантитативне и квалитативне показатеље. За аутоматизовано тестирање, такав универзални индикатор је покривеност кода или метрика покривености кода. Користећи овај индикатор, можемо утврдити који проценат кода нашег система који се тестира је покривен аутотестовима. Почевши од верзије 12.2, Орацле пружа могућност израчунавања ове метрике и нуди употребу стандардног пакета ДБМС_ПЛСКЛ_ЦОДЕ_ЦОВЕРАГЕ.

   Наш систем аутотестирања је стар нешто више од годину дана и можда је сада време да проценимо нашу покривеност. У мом последњем пројекту (није у пројекту Спортмастер) десило се то. Годину дана након рада на аутотестовима, менаџмент је поставио задатак да процени који проценат кода покривамо. Са покривеношћу већом од 1%, менаџмент би био срећан. Ми, програмери, очекивали смо резултат од око 10%. Инсталирали смо покривеност кода, измерили је и добили 20%. Да бисмо прославили, отишли ​​смо по награду, али како смо ишли да је узмемо и где смо касније отишли, то је сасвим друга прича.

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

Налази

Хајде да сумирамо. На пројекту система лојалности у Спортмастеру успели смо да имплементирамо аутоматизовани систем тестирања. Заснован је на утПЛСКЛ решењу Степхена Феуерстеина. Око утПЛСКЛ-а постоји код за аутотест и помоћни самописни модули: модул за покретање, модул за генерисање података и други. Аутотестови се покрећу свакодневно и, што је најважније, раде и корисни су. Уверени смо да смо почели да издајемо софтвер вишег квалитета. У исто време, добијено решење је универзално и може се слободно применити на било који пројекат где је потребно организовати аутоматизовано тестирање на Орацле ДБМС.

П.С. Овај чланак није баш конкретан: има пуно текста и практично нема техничких примера. Ако је тема генерално интересантна, онда смо спремни да је наставимо и да се вратимо са наставком, где ћемо вам рећи шта се променило у протеклих шест месеци и дати примере кода.

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

Само регистровани корисници могу учествовати у анкети. Пријавите се, Добродошао си.

Хоћемо ли даље писати о овоме?

• Да, наравно

• Не хвала

Гласало је 12 корисника. 4 корисника су била уздржана.

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