Единица тестови во DBMS - како го правиме тоа во Sportmaster, втор дел

Прв дел - тука.

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

Најчесто се забораваат сите стари случувања и се почнува одново. Никој не сака да копа во туѓ код, и ако имате време, зошто да не започнете да создавате сопствен систем? Ова е типичен пристап, и во многу аспекти е точен. Но, во нашиот проект постапивме поинаку. Го засновавме идниот автоматизиран систем за тестирање на развојот на единечните тестови на utPLSQL од нашите претходници, а потоа тргнавме на работа во неколку паралелни насоки.

1. Враќање на старите тестови на единицата. Закрепнувањето значи прилагодување на тестовите на постоечката состојба на системот за лојалност и прилагодување на тестовите на стандардите utPLSQL.
2. Решавањето на проблемот со разбирање, и кои точно, какви методи и процеси, опфативме со автотестови. Мора или да ги задржите овие информации во вашата глава или да извлечете заклучоци директно врз основа на кодот на автотестови. Затоа, решивме да создадеме каталог. На секој автотест му доделивме единствен мнемонички код, создадовме опис и ги поправивме поставките (на пример, под кои услови треба да се изврши или што треба да се случи ако тестот не успее). Во суштина, ги пополнивме метаподатоците за автотестовите и ги сместивме овие метаподатоци во стандардните табели на шемата utPLSQL.
3. Дефиниција на стратегија за проширување, т.е. избор на функционалност што е предмет на верификација со автотестови. Решивме да обрнеме внимание на три работи: нови подобрувања на системот, инциденти од производството и клучни процеси на системот. Така, се развиваме паралелно со ослободувањето, обезбедувајќи негов повисок квалитет, истовремено проширувајќи го опсегот на регресијата и обезбедувајќи сигурност на системот на критичните места. Првото такво тесно грло беше процесот на дистрибуција на попусти и бонуси со чек.
4. Секако, почнавме да развиваме нови автотестови. Една од првите задачи за објавување беше да се оцени работата на претходно дефинираните примероци на системот за лојалност. Нашиот проект има блок од строго фиксирани sql барања кои избираат клиенти според условите. На пример, добијте листа на сите клиенти чие последно купување било во одреден град или листа на клиенти чиј просечен износ за купување е над одредена вредност. Имајќи напишани автоматски тестови, проверивме претходно дефинирани примероци, фиксирани репер параметри за изведба, а дополнително добивме и тестирање на оптоварување.
5. Работата со автотестови треба да биде погодна. Двете најчести дејства се извршување на автоматски тестови и генерирање податоци од тестот. Вака се појавија два помошни модула во нашиот систем: модулот за лансирање и модулот за генерирање податоци.

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

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

6. Автоматските тестови треба да се извршуваат и да се извршуваат во разумен рок за вашиот систем. Затоа, беше организирано секојдневно ноќно лансирање, врз основа на чии резултати се генерира извештај за резултатите и се испраќа до целиот тим за развој по корпоративна пошта. По враќањето на старите автоматски тестови и создавањето на нови, вкупното време на траење беше 30 минути. Ваквата изведба им одговараше на сите, бидејќи лансирањето се случуваше за време на слободни часови.

   Но, моравме да работиме на оптимизирање на брзината на работа. Системот за лојалност на производството се ажурира ноќе. Како дел од едно од изданијата, моравме итно да направиме промени ноќе. Половина час чекање за резултатите од автотестовите во три часот наутро не го израдува одговорното лице за ослободување (жестоки поздрави до Алексеј Васјуков!), А следното утро беа кажани многу топли зборови кон нашиот систем. Но, како резултат на тоа, беше поставен стандард за работа од 5 минути.

   За да ги забрзаме перформансите, користевме два методи: почнавме да извршуваме автотестови во три паралелни нишки, бидејќи ова е многу погодно поради архитектурата на нашиот систем за лојалност. И го напуштивме пристапот кога автотестот не создава податоци за тестот за себе, туку се обидува да најде нешто соодветно во системот. По направените промени, вкупното време на работа се намали на 3-4 минути.

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

   Тоа е независна библиотека со база на податоци со отворен код за следење, управување и примена на промени во шемата на базата на податоци. Управувано преку командна линија или рамки како Apache Maven. Принципот на работа на Liquibase е прилично едноставен. Имаме проект организиран на одреден начин, кој се состои од промени или скрипти кои треба да се префрлат на целниот сервер и контролни датотеки кои одредуваат по кој редослед и со кои параметри треба да се инсталираат овие промени.

   На ниво на DBMS, се креира посебна табела во која Liquibase го складира дневникот за враќање назад. Секоја промена има пресметан хаш што се споредува секој пат помеѓу проектот и состојбата во базата на податоци. Благодарение на Liquibase, лесно можеме да ги спроведеме промените во нашиот систем на кое било коло. Автоматските тестови сега се извршуваат на кола за тестирање и ослободување, како и на контејнери (кола за личен програмер).

Значи, ајде да зборуваме за резултатите од примената на нашиот систем за тестирање на единици.

1. Се разбира, пред се, ние сме убедени дека почнавме да развиваме подобар софтвер. Автоматските тестови се извршуваат секојдневно и наоѓаат десетици грешки во секое издание. Покрај тоа, некои од овие грешки се само индиректно поврзани со функционалноста што навистина сакавме да ја промениме. Постојат силни сомневања дека овие грешки се пронајдени со рачно тестирање.
2. Тимот се здоби со доверба дека специфичната функционалност работи правилно... Пред сè, ова се однесува на нашите критични процеси. На пример, во текот на изминатите шест месеци, немавме проблеми со распределбата на попусти и бонуси со чек, и покрај промените направени во секое издание, иако во претходните периоди се случуваа грешки со одредена фреквенција
3. Успеавме да го намалиме бројот на повторувања за тестирање. Поради фактот што автотестовите се пишуваат за нова функционалност, аналитичарите и тестерите со скратено работно време добиваат код со повисок квалитет, бидејќи веќе е потврдено.
4. Дел од развојот на автоматското тестирање го користат програмерите. На пример, податоците за тестирање на контејнерите се креираат со помош на модулот за генерирање на објекти.
5. Важно е дека развивме „прифаќање“ на системот за автоматско тестирање од страна на програмерите. Постои разбирање дека ова е важно и корисно. И од мое искуство можам да кажам дека тоа е далеку од случајот. Автотестовите треба да се напишат, треба да се одржуваат и развиваат, да се анализираат резултатите и честопати овие временски трошоци едноставно не вредат. Многу е полесно да се оди на производство и таму да се справи со проблемите. Кај нас, програмерите се редат и бараат да ја покријат својата функционалност со автотестови.

Што е следно

Ајде да зборуваме за развојните планови на проектот за автоматско тестирање.

Се разбира, додека системот за лојалност на Sportmaster е жив и продолжува да се развива, автотестовите исто така може да се развиваат речиси бесконечно. Затоа, главната насока на развој е проширувањето на областа на покривање.

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

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

1. Сега автотестовите се управуваат на ниво на DBMS, т.е. за успешна работа потребно е познавање на PL/SQL. Доколку е потребно, управувањето со системот (на пример, стартување или креирање метаподатоци) може да се извади од некој вид административен панел користејќи Jenkins или нешто слично.
2. Секој сака квантитативни и квалитативни показатели. За автоматско тестирање, таков универзален индикатор е Покриеност на код или метрика на покриеност на код. Користејќи го овој индикатор, можеме да одредиме колкав процент од кодот на нашиот систем што се тестира е покриен со автотестови. Почнувајќи од верзијата 12.2, Oracle обезбедува можност за пресметување на оваа метрика и предлага користење на стандардниот пакет DBMS_PLSQL_CODE_COVERAGE.

   Нашиот систем за автоматско тестирање е стар нешто повеќе од една година и можеби е време да се оцени покриеноста. Во мојот последен проект (проект не на Спортмастер), ова се случи. Една година откако работеше на автотестовите, менаџментот постави задача да процени колкав процент од кодот покривавме. Со повеќе од 1% покриеност, менаџментот би бил среќен. Ние, програмерите, очекувавме резултат од околу 10%. Ја заебавме покриеноста со кодови, ја измеривме, добивме 20%. За да славиме, отидовме по наградата, но како тргнавме по неа и каде отидовме подоцна е сосема друга приказна.

3. Автоматските тестови можат да тестираат изложени веб-услуги. Oracle ви овозможува да го направите ова, и повеќе нема да се среќаваме со голем број проблеми.
4. И, се разбира, нашиот автоматски систем за тестирање може да се примени на друг проект. Решението што го добивме е универзално и бара само употреба на Oracle. Слушнав дека има интерес за автоматско тестирање на други проекти на Sportmaster и, можеби, ќе одиме кај нив.

Наоди

Да резимираме. На проектот за систем за лојалност во Sportmaster, успеавме да имплементираме автоматизиран систем за тестирање. Нејзината основа е решението utPLSQL од Stephen Feuerstein. Околу utPLSQL е кодот за автоматско тестирање и помошни само-напишани модули: фрлач, модул за генерирање податоци и други. Автотестовите се извршуваат секојдневно и, што е најважно, работат и имаат корист. Убедени сме дека почнавме да издаваме софтвер со повисок квалитет. Во исто време, добиеното решение е универзално и може слободно да се примени на кој било проект каде што е неопходно да се организира автоматско тестирање на Oracle DBMS.

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

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

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

Да напишеме повеќе за ова?

• да секако

• Не, благодарам

Гласаа 12 корисници. 4 корисници се воздржаа.

Извор: www.habr.com