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

Първа част - тук.

Представете си ситуация. Вие сте изправени пред задачата да разработите нова функционалност. Имате опит от вашите предшественици. Ако приемем, че нямате морални задължения, какво бихте направили?

Най-често всички стари разработки се забравят и всичко започва отначало. Никой не обича да се рови в кода на някой друг и ако имате време, защо не започнете да създавате своя собствена система? Това е типичен подход и в много отношения е правилен. Но в нашия проект ние действахме по различен начин. Базирахме бъдещата автоматизирана система за тестване на разработките в модулните тестове на utPLSQL от нашите предшественици и след това започнахме да работим в няколко паралелни посоки.

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

   Стартерът е представен като една обща процедура с един входен текстов параметър. Като параметър можете да подадете мнемоничен код за автоматичен тест, име на пакет, име на тест, настройка за автоматичен тест или запазена ключова дума. Процедурата избира и изпълнява всички автотестове, които отговарят на условията.

   Модулът за генериране на данни е представен като пакет, в който за всеки обект на тествана система (таблица в базата данни) е създадена специална процедура, която въвежда данни там. При тази процедура стойностите по подразбиране се запълват максимално, което гарантира създаването на обекти буквално с едно щракване на пръста. И за по-лесно използване бяха създадени шаблони за генерираните данни. Например, създайте клиент на определена възраст с тестов телефон и извършена покупка.

6. Автоматичните тестове трябва да се изпълняват и да се изпълняват в рамките на разумно време за вашата система. Затова беше организирано ежедневно нощно стартиране, въз основа на резултатите от което се генерира отчет за резултатите и се изпраща на целия екип за разработка по корпоративна поща. След възстановяване на стари автотестове и създаване на нови, общото време за работа беше 30 минути. Такова представяне подхождаше на всички, тъй като стартирането се състоя в извънработно време.

   Но трябваше да работим върху оптимизирането на скоростта на работа. Системата за лоялност към производството се актуализира през нощта. Като част от едно от изданията трябваше спешно да направим промени през нощта. Половинчасовото чакане на резултатите от автотестовете в три сутринта не направи лицето, отговорно за освобождаването, щастливо (горещи поздрави на Алексей Васюков!), А на следващата сутрин бяха казани много топли думи към нашата система. Но в резултат на това беше определен 5-минутен стандарт за работа.

   За да ускорим производителността, използвахме два метода: започнахме да изпълняваме автотестове в три паралелни нишки, тъй като това е много удобно поради архитектурата на нашата система за лоялност. И изоставихме подхода, когато автотестът не създава тестови данни за себе си, а се опитва да намери нещо подходящо в системата. След извършване на промени общото време на работа беше намалено до 3-4 минути.

7. Проект с автотестове трябва да може да бъде разположен на различни щандове. В началото на пътуването имаше опити да напишем собствени пакетни файлове, но стана ясно, че самонаписаната автоматизирана инсталация е пълен ужас и се насочихме към индустриални решения. Поради факта, че проектът има много код директно (на първо място, ние съхраняваме кода на автотестовете) и много малко данни (основните данни са метаданни за автотестовете), се оказа много лесно да се интегрира в Проект Liquibase.

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

   На ниво СУБД се създава специална таблица, в която Liquibase съхранява журнала за връщане назад. Всяка промяна има изчислен хеш, който се сравнява всеки път между проекта и състоянието в базата данни. Благодарение на Liquibase можем лесно да внедрим промени в нашата система във всяка верига. Автотестовете вече се изпълняват на вериги за тестване и освобождаване, както и на контейнери (вериги за лични програмисти).

И така, нека поговорим за резултатите от прилагането на нашата система за тестване на единици.

1. Разбира се, на първо място, ние сме убедени, че започнахме да разработваме по-добър софтуер. Автоматичните тестове се изпълняват ежедневно и откриват десетки грешки при всяка версия. Освен това някои от тези грешки са само косвено свързани с функционалността, която наистина искахме да променим. Има силни съмнения, че тези грешки са открити чрез ръчно тестване.
2. Екипът придоби увереност, че конкретна функционалност работи правилно... На първо място, това се отнася за нашите критични процеси. Например, през последните шест месеца не сме имали проблеми с разпределението на отстъпки и бонуси чрез чек, въпреки промените, направени при всяко издание, въпреки че в предишни периоди са възниквали грешки с известна честота
3. Успяхме да намалим броя на тестовите повторения. Поради факта, че автотестовете са написани за нова функционалност, анализаторите и тестерите на непълен работен ден получават код с по-високо качество, т.к. вече е проверено.
4. Част от разработките на автоматизираното тестване се използват от разработчиците. Например, тестови данни за контейнери се създават с помощта на модула за генериране на обекти.
5. Важно е, че сме разработили „приемане“ на системата за автоматизирано тестване от разработчиците. Има разбиране, че това е важно и полезно. И от собствен опит мога да кажа, че това далеч не е така. Автотестовете трябва да бъдат написани, те трябва да се поддържат и развиват, резултатите да се анализират и често тези времеви разходи просто не си заслужават. Много по-лесно е да отидете в производството и да се справите с проблемите там. У нас разработчиците се нареждат и искат да покрият функционалността си с автотестове.

Какво следва?

Нека поговорим за плановете за развитие на проекта за автоматизирано тестване.

Разбира се, докато системата за лоялност Sportmaster е жива и продължава да се развива, автотестовете също могат да се развиват почти безкрайно. Следователно основната посока на развитие е разширяването на зоната на покритие.

С увеличаването на броя на автотестовете, общото време на тяхната работа непрекъснато ще се увеличава и отново ще трябва да се върнем към въпроса за производителността. Най-вероятно решението ще бъде увеличаване на броя на паралелните нишки.

Но това са очевидни пътища за развитие. Ако говорим за нещо по-нетривиално, подчертаваме следното:

1. Сега автотестовете се управляват на ниво СУБД, т.е. за успешна работа са необходими познания по PL/SQL. Ако е необходимо, управлението на системата (например стартиране или създаване на метаданни) може да бъде извадено от някакъв вид администраторски панел с помощта на Jenkins или нещо подобно.
2. Всички обичат количествените и качествените показатели. За автоматично тестване такъв универсален индикатор е покритието на кода или показателят за покритие на кода. Използвайки този индикатор, можем да определим какъв процент от кода на нашата тествана система е покрит от автотестове. Започвайки от версия 12.2, Oracle предоставя възможност за изчисляване на този показател и предлага използването на стандартния пакет DBMS_PLSQL_CODE_COVERAGE.

   Нашата система за автоматично тестване е на малко повече от година и може би е време да оценим покритието. В последния ми проект (не е на Sportmaster) това се случи. Година след работата по автотестовете, ръководството постави задачата да прецени какъв процент от кода сме покрили. При повече от 1% покритие ръководството би било доволно. Ние, разработчиците, очаквахме резултат от около 10%. Прецакахме покритието на кода, измерихме го и получихме 20%. За да отпразнуваме, отидохме за наградата, но как отидохме за нея и къде отидохме по-късно, е съвсем друга история.

3. Автоматичните тестове могат да тестват открити уеб услуги. Oracle ви позволява да направите това и вече няма да срещаме редица проблеми.
4. И, разбира се, нашата автоматизирана система за тестване може да се приложи към друг проект. Решението, което получихме е универсално и изисква използването само на Oracle. Чух, че има интерес към автоматизирано тестване на други проекти на Sportmaster и може би ще отидем при тях.

Данни

Нека обобщим. По проекта за система за лоялност в Sportmaster успяхме да внедрим автоматизирана система за тестване. Неговата основа е решението utPLSQL от Stephen Feuerstein. Около utPLSQL е кодът за автотестове и спомагателни самостоятелно написани модули: стартер, модул за генериране на данни и други. Автотестовете се изпълняват ежедневно и, най-важното, работят и са от полза. Убедени сме, че сме започнали да пускаме софтуер с по-високо качество. В същото време полученото решение е универсално и може свободно да се прилага към всеки проект, където е необходимо да се организира автоматизирано тестване на СУБД Oracle.

PS Тази статия се оказа не много конкретна: има много текст и практически никакви технически примери. Ако темата е глобално интересна, тогава сме готови да я продължим и да се върнем с продължение, където ще ви кажем какво се е променило през последните шест месеца и ще дадем примери за код.

Напишете коментари, ако има точки, които трябва да бъдат подчертани в бъдеще, или въпроси, които изискват разкриване.

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

Ще пишем ли повече за това?

• Да, разбира се

• Не благодаря

12 потребители гласуваха. 4 потребители се въздържаха.

Източник: www.habr.com