Хей Хабр!
Казвам се Максим Пономаренко и съм разработчик в Sportmaster. Имам 10 години опит в IT сферата. Започва кариерата си в ръчно тестване, след което преминава към разработка на бази данни. През последните 4 години, натрупвайки знанията, придобити в тестването и разработката, автоматизирах тестването на ниво СУБД.
Аз съм в екипа на Sportmaster от малко повече от година и разработвам автоматизирано тестване по един от големите проекти. През април с момчетата от Sportmaster Lab говорихме на конференция в Краснодар, моят доклад се казваше „Единични тестове в СУБД“ и сега искам да го споделя с вас. Ще има много текст, затова реших да разделя доклада на две публикации. В първия ще говорим за автотестовете и тестването като цяло, а във втория ще се спра по-подробно на нашата система за модулно тестване и резултатите от нейното прилагане.
Първо, малко скучна теория. Какво е автоматизирано тестване? Това е тестване, което се извършва с помощта на софтуер, а в съвременните ИТ все повече се използва в разработката на софтуер. Това се дължи на факта, че компаниите растат, информационните им системи растат и съответно количеството функционалност, която трябва да се тества, расте. Провеждането на ръчно тестване става все по-скъпо.
Работих за голяма компания, чиито издания излизат на всеки два месеца. В същото време беше изразходван цял месец за ръчна проверка на функционалността на дузина тестери. Благодарение на внедряването на автоматизация от малък екип от разработчици, успяхме да намалим времето за тестване до 2 седмици за година и половина. Ние не само увеличихме скоростта на тестване, но и подобрихме качеството му. Автоматизираните тестове се стартират редовно и винаги извършват целия курс от проверки, включени в тях, тоест изключваме човешкия фактор.
Съвременните ИТ се характеризират с факта, че от разработчика може да се изисква не само да напише продуктов код, но и да напише модулни тестове, които проверяват този код.
Но какво ще стане, ако вашата система е базирана предимно на сървърна логика? На пазара няма универсално решение или най-добри практики. По правило компаниите решават този проблем, като създават своя собствена система за тестване, написана от тях. Това е нашата собствена самонаписана автоматизирана система за тестване, която е създадена по нашия проект и ще говоря за нея в моя доклад.
Тестване на лоялността
Първо, нека поговорим за проекта, в който внедрихме система за автоматизирано тестване. Нашият проект е системата за лоялност Sportmaster (между другото, вече писахме за това в ).
Ако вашата компания е достатъчно голяма, тогава вашата система за лоялност ще има три стандартни свойства:
- Системата ви ще бъде силно натоварена
- Вашата система ще съдържа сложни изчислителни процеси
- Вашата система ще бъде активно подобрявана.
Да вървим по ред... Общо, ако вземем предвид всички марки Sportmaster, тогава имаме повече от 1000 магазина в Русия, Украйна, Китай, Казахстан и Беларус. Всеки ден в тези магазини се правят около 300 000 покупки. Тоест всяка секунда 3-4 проверки влизат в нашата система. Естествено системата ни за лоялност е силно натоварена. И тъй като той се използва активно, ние трябва да осигурим най-високите стандарти за неговото качество, защото всяка грешка в софтуера означава големи парични, репутационни и други загуби.
В същото време Sportmaster провежда повече от сто различни промоции. Има различни промоции: има продуктови промоции, има такива, посветени на деня от седмицата, има такива, свързани с конкретен магазин, има промоции за сумата на касовата бележка, има за броя на стоките. Като цяло не е лошо. Клиентите имат бонуси и промоционални кодове, които се използват при извършване на покупки. Всичко това води до факта, че изчисляването на всяка поръчка е много нетривиална задача.
Алгоритъмът, който реализира обработката на поръчки, е наистина ужасен и сложен. И всякакви промени в този алгоритъм са доста рисковани. Изглеждаше, че най-незначителните на пръв поглед промени могат да доведат до доста непредвидими ефекти. Но точно такива сложни изчислителни процеси, особено тези, които изпълняват критична функционалност, са най-добрите кандидати за автоматизация. Проверката на десетки подобни случаи на ръка отнема много време. И тъй като входната точка в процеса е непроменена, след като сте я описали веднъж, можете бързо да създавате автоматични тестове и да сте сигурни, че функционалността ще работи.
Тъй като нашата система се използва активно, бизнесът ще иска нещо ново от вас, ще живее в крак с времето и ще бъде ориентиран към клиента. В нашата система за лоялност изданията излизат на всеки два месеца. Това означава, че на всеки два месеца трябва да извършваме пълна регресия на цялата система. В същото време, естествено, както във всяка съвременна ИТ, разработката не преминава веднага от разработчика към производството. Той произхожда от веригата на разработчика, след това последователно преминава през тестовия стенд, освобождаване, приемане и едва след това завършва в производството. Най-малко, на вериги за тестване и освобождаване, трябва да извършим пълна регресия на цялата система.
Описаните свойства са стандартни за почти всяка система за лоялност. Нека поговорим за характеристиките на нашия проект.
Технологично, 90% от логиката на нашата система за лоялност е сървърно базирана и внедрена в Oracle. В Delphi е изложен клиент, който изпълнява функцията на администратор на автоматизирано работно място. Има открити уеб услуги за външни приложения (например уебсайт). Следователно е много логично, ако внедрим система за автоматизирано тестване, да го направим на Oracle.
Системата за лоялност в Sportmaster съществува повече от 7 години и е създадена от единични разработчици... Средният брой разработчици на нашия проект през тези 7 години беше 3-4 човека. Но през изминалата година екипът ни се разрасна значително и сега по проекта работят 10 души. Тоест в проекта идват хора, които не са запознати с типичните задачи, процеси и архитектура. И има повишен риск да пропуснем грешки.
Проектът се характеризира с липсата на специализирани тестери като персонал. Има, разбира се, тестване, но тестването се извършва от анализатори, в допълнение към другите им основни отговорности: комуникация с бизнес клиенти, потребители, разработване на системни изисквания и т.н. и т.н... Въпреки факта, че тестването се извършва много високо качество (това е особено подходящо да се спомене, тъй като някои от анализаторите могат да хванат окото на този доклад), ефективността на специализацията и концентрацията върху едно нещо не е отменена .
Като се има предвид всичко по-горе, за да се подобри качеството на доставения продукт и да се намали времето за разработка, идеята за автоматизиране на тестването на проект изглежда много логична. И на различни етапи от съществуването на системата за лоялност отделни разработчици положиха усилия да покрият своя код с модулни тестове. Като цяло това беше доста несвързан процес, като всеки използваше собствена архитектура и методи. Крайните резултати бяха общи за модулните тестове: тестовете бяха разработени, използвани известно време, съхранявани във файлово хранилище с версии, но в един момент те спряха да се изпълняват и бяха забравени. На първо място, това се дължи на факта, че тестовете бяха обвързани повече с конкретен изпълнител, а не с проекта.
utPLSQL идва на помощ
Знаете ли нещо за Стивън Фойерщайн?
Това е умен човек, който посвети голяма част от кариерата си на работа с Oracle и PL/SQL и е написал доста голям брой произведения по тази тема. Една от известните му книги се казва: „Oracle PL/SQL. За професионалисти." Стивън беше този, който разработи решението utPLSQL, или, както означава Unit Testing framework за Oracle PL/SQL. Решението utPLSQL е създадено през 2016 г., но продължава да се работи активно по него и излизат нови версии. Към момента на докладване последната версия датира от 24 март 2019 г.
Какво е. Това е отделен проект с отворен код. Тежи няколко мегабайта, включително примери и документация. Физически това е отделна схема в базата данни ORACLE с набор от пакети и таблици за организиране на модулно тестване. Инсталацията отнема няколко секунди. Отличителна черта на utPLSQL е неговата лекота на използване.
В световен мащаб utPLSQL е механизъм за провеждане на модулни тестове, където модулен тест се разбира като обикновени пакетни процедури на Oracle, чиято организация следва определени правила. В допълнение към стартирането, utPLSQL съхранява регистър на всичките ви тестови изпълнения и също така има вътрешна система за отчитане.
Нека да разгледаме пример за това как изглежда единичният тестов код, реализиран с помощта на тази техника.
И така, екранът показва кода за типична спецификация на пакета с единични тестове. Какви са задължителните изисквания? Пакетът трябва да има префикс "utp_". Всички процедури с тестове трябва да имат абсолютно същия префикс. Пакетът трябва да съдържа две стандартни процедури: “utp_setup” и “utp_teardown”. Първата процедура се извиква чрез рестартиране на всеки модулен тест, втората - след стартиране.
„utp_setup“, като правило, подготвя нашата система да изпълни единичен тест, например, създавайки тестови данни. “utp_teardown” - напротив, всичко се връща към първоначалните настройки и нулира резултатите от стартирането.
Ето пример за най-прост модулен тест, който проверява нормализирането на въведения клиентски телефонен номер към стандартната форма за нашата система за лоялност. Няма задължителни стандарти за това как да се пишат процедури с модулни тестове. По правило се извиква метод на тестваната система и резултатът, върнат от този метод, се сравнява с референтния. Важно е сравнението на референтния резултат и получения да става чрез стандартни utPLSQL методи.
Единичен тест може да има произволен брой проверки. Както може да се види от примера, ние правим четири последователни обаждания към тествания метод, за да нормализираме телефонния номер и оценяваме резултата след всяко обаждане. Когато разработвате модулен тест, трябва да вземете предвид, че има проверки, които не засягат системата по никакъв начин и след някои трябва да се върнете към първоначалното състояние на системата.
Например, в представения модулен тест просто форматираме въведения телефонен номер, което по никакъв начин не засяга системата за лоялност.
И ако пишем модулни тестове, използвайки метода за създаване на нов клиент, тогава след всеки тест в системата ще бъде създаден нов клиент, което може да повлияе на последващото стартиране на теста.
Това е начинът, по който се провеждат тестове на единици. Има две възможни опции за стартиране: изпълнение на всички модулни тестове от конкретен пакет или изпълнение на конкретен модулен тест в конкретен пакет.
Ето как изглежда примерна система за вътрешна отчетност. Въз основа на резултатите от единичния тест, utPLSQL изгражда малък отчет. В него виждаме резултата за всяка конкретна проверка и общия резултат от единичния тест.
6 правила за автотестове
Преди да започнем да създаваме нова система за автоматизирано тестване на системата за лоялност, заедно с ръководството определихме принципите, на които трябва да отговарят нашите бъдещи автоматизирани тестове.
- Автотестовете трябва да са ефективни и полезни. Имаме прекрасни разработчици, които определено трябва да бъдат споменати, защото някои от тях вероятно ще видят този доклад, а те пишат чудесен код. Но дори техният чудесен код не е съвършен и има, има и ще продължава да съдържа грешки. Необходими са автоматични тестове за намиране на тези грешки. Ако това не е така, тогава или пишем лоши автотестове, или сме стигнали до мъртва зона, която по принцип не се развива. И в двата случая правим нещо нередно и нашият подход просто няма смисъл.
- Трябва да се използват автотестове. Няма смисъл да отделяте много време и усилия за написването на софтуерен продукт, да го поставите в хранилище и да го забравите. Тестовете трябва да се провеждат възможно най-редовно.
- Автотестовете трябва да работят стабилно. Независимо от времето на деня, стартовата стойка и други системни настройки, тестовите пускания трябва да доведат до същия резултат. По правило това се осигурява от факта, че автотестовете работят със специални тестови данни с фиксирани системни настройки.
- Автотестовете трябва да работят със скорост, приемлива за вашия проект. Това време се определя индивидуално за всяка система. Някои хора могат да си позволят да работят цял ден, докато за други е изключително важно да го направят за секунди. Ще ви кажа малко по-късно какви стандарти за скорост постигнахме в нашия проект.
- Разработката на автотест трябва да бъде гъвкава. Не е препоръчително да отказваме да тестваме каквато и да е функционалност само защото не сме го правили преди или по друга причина. utPLSQL не налага никакви ограничения върху разработката и Oracle по принцип ви позволява да внедрявате различни неща. Повечето проблеми имат решение, това е просто въпрос на време и усилия.
- Възможност за разгръщане. Имаме няколко стенда, където трябва да проведем тестове. На всеки щанд дъмпът на данни може да се актуализира по всяко време. Необходимо е да се проведе проект с автоматични тестове по такъв начин, че да можете безболезнено да извършите пълното или частичното му инсталиране.
И във втория пост след няколко дни ще ви разкажа какво направихме и какви резултати постигнахме.
Източник: www.habr.com