Еј Хабр!
Моето име е Максим Пономаренко и јас сум програмер во Sportmaster. Имам 10 годишно искуство во ИТ областа. Тој ја започна својата кариера во рачно тестирање, а потоа се префрли на развој на бази на податоци. Во последните 4 години, акумулирајќи го знаењето стекнато во тестирањето и развојот, го автоматизирам тестирањето на ниво на DBMS.
Јас сум во тимот на Sportmaster нешто повеќе од една година и развивам автоматско тестирање на еден од главните проекти. Во април, момците од Sportmaster Lab и јас зборувавме на конференција во Краснодар, мојот извештај беше наречен „Единица тестови во DBMS“ и сега сакам да го споделам со вас. Ќе има многу текст, па решив да го поделам извештајот на два поста. Во првата, ќе зборуваме за автотестови и тестирање воопшто, а во втората, ќе се задржам подетално на нашиот систем за тестирање на единици и резултатите од неговата примена.
Прво, малку досадна теорија. Што е автоматско тестирање? Станува збор за тестирање кое се врши со помош на софтвер, а во современата ИТ се повеќе се користи во развојот на софтвер. Ова се должи на фактот дека компаниите растат, нивните информациски системи растат и, соодветно, расте и количината на функционалност што треба да се тестира. Спроведувањето на рачно тестирање станува се поскапо.
Работев за голема компанија чии изданија излегуваат на секои два месеци. Во исто време, цел месец беше потрошен за дузина тестери рачно да ја проверат функционалноста. Благодарение на имплементацијата на автоматизацијата од страна на мал тим на програмери, успеавме да го намалиме времето на тестирање на 2 недели за година и половина. Не само што ја зголемивме брзината на тестирањето, туку и го подобривме неговиот квалитет. Редовно се лансираат автоматизирани тестови и тие секогаш го вршат целиот тек на проверки вклучени во нив, односно го исклучуваме човечкиот фактор.
Современата ИТ се карактеризира со фактот дека од развивачот може да се бара не само да напише код на производот, туку и да напише единечни тестови кои го проверуваат овој код.
Но, што ако вашиот систем се базира првенствено на логиката на серверот? Не постои универзално решение или најдобри практики на пазарот. Како по правило, компаниите го решаваат овој проблем со креирање на сопствен систем за тестирање самостојно напишано. Ова е наш сопствен автоматизиран систем за тестирање кој е создаден на нашиот проект и јас ќе зборувам за тоа во мојот извештај.
Тестирање на лојалноста
Прво, да зборуваме за проектот каде што распоредивме автоматизиран систем за тестирање. Нашиот проект е системот за лојалност Sportmaster (патем, веќе пишувавме за тоа во ).
Ако вашата компанија е доволно голема, тогаш вашиот систем за лојалност ќе има три стандардни својства:
- Вашиот систем ќе биде многу натоварен
- Вашиот систем ќе содржи сложени компјутерски процеси
- Вашиот систем активно ќе се подобрува.
Ајде да одиме по ред... Севкупно, ако ги земеме предвид сите брендови на Sportmaster, тогаш имаме повеќе од 1000 продавници во Русија, Украина, Кина, Казахстан и Белорусија. Секој ден во овие продавници се вршат околу 300 набавки. Односно, секоја секунда 000-3 проверки влегуваат во нашиот систем. Секако, нашиот систем за лојалност е многу оптоварен. И бидејќи активно се користи, мора да обезбедиме највисоки стандарди за неговиот квалитет, бидејќи секоја грешка во софтверот значи големи финансиски, репутациски и други загуби.
Во исто време, Sportmaster води повеќе од сто различни промоции. Има најразлични промоции: има промоции на производи, има такви посветени на денот во неделата, има такви врзани за одредена продавница, има промоции за износот на сметката, има за бројот на стоки. Во принцип, не е лошо. Клиентите имаат бонуси и промотивни кодови кои се користат при купување. Сето ова води до фактот дека пресметувањето на кој било ред е многу нетривијална задача.
Алгоритмот што ја имплементира обработката на нарачките е навистина страшен и комплициран. И сите промени на овој алгоритам се доста ризични. Се чинеше дека најнезначајните промени може да доведат до сосема непредвидливи ефекти. Но, токму таквите сложени пресметковни процеси, особено оние што спроведуваат критична функционалност, се најдобри кандидати за автоматизација. Рачното проверување на десетици слични случаи одзема многу време. И бидејќи влезната точка во процесот е непроменета, откако ја опишавте еднаш, можете брзо да креирате автоматски тестови и да бидете сигурни дека функционалноста ќе работи.
Бидејќи нашиот систем активно се користи, бизнисот ќе сака нешто ново од вас, ќе живее со времето и ќе биде ориентиран кон клиентите. Во нашиот систем за лојалност, изданијата излегуваат на секои два месеци. Тоа значи дека на секои два месеци треба да вршиме целосна регресија на целиот систем. Во исто време, природно, како и во секоја модерна ИТ, развојот не оди веднаш од развивачот до производство. Потекнува од колото на развивачот, потоа последователно поминува низ тест-клупата, ослободување, прифаќање и дури потоа завршува во производство. Најмалку, на кола за тестирање и ослободување, треба да извршиме целосна регресија на целиот систем.
Опишаните својства се стандардни за речиси секој систем на лојалност. Ајде да зборуваме за карактеристиките на нашиот проект.
Технолошки, 90% од логиката на нашиот систем за лојалност е базиран на сервер и имплементиран на Oracle. Постои клиент изложен во Делфи, кој ја извршува функцијата на автоматизиран администратор на работното место. Постојат изложени веб-услуги за надворешни апликации (на пример веб-локација). Затоа, многу е логично ако распоредиме автоматизиран систем за тестирање, тоа ќе го направиме на Oracle.
Системот за лојалност во Sportmaster постои повеќе од 7 години и е создаден од поединечни програмери... Просечниот број на програмери на нашиот проект во текот на овие 7 години беше 3-4 луѓе. Но, во текот на изминатата година, нашиот тим значително се зголеми, а сега има 10 луѓе кои работат на проектот. Односно, на проектот доаѓаат луѓе кои не се запознаени со типични задачи, процеси и архитектура. И постои зголемен ризик да пропуштиме грешки.
Проектот се карактеризира со отсуство на посветени тестери како кадровски единици. Има, се разбира, тестирање, но тестирањето го вршат аналитичарите, покрај другите нивни главни одговорности: комуникација со деловни клиенти, корисници, развивање системски барања итн. итн... И покрај фактот што тестирањето се врши со многу висок квалитет (ова е особено соодветно да се спомене, бидејќи некои од аналитичарите може да го привлечат вниманието на овој извештај), ефективноста на специјализацијата и концентрацијата на една работа не е откажана .
Имајќи го предвид сето горенаведено, за да се подобри квалитетот на испорачаниот производ и да се намали времето за развој, идејата за автоматизирање на тестирањето на проект изгледа многу логична. И во различни фази од постоењето на системот за лојалност, индивидуалните програмери вложија напори да го покријат својот код со единечни тестови. Генерално, тоа беше прилично разделен процес, при што секој користеше своја архитектура и методи. Конечните резултати беа вообичаени за единечните тестови: беа развиени тестови, користени некое време, складирани во верзии на складирање на датотеки, но во одреден момент тие престанаа да работат и беа заборавени. Пред сè, ова се должи на фактот што тестовите беа повеќе врзани за одреден изведувач, а не за проектот.
utPLSQL доаѓа на помош
Дали знаете нешто за Стивен Фоерштајн?
Ова е паметен човек кој посветил долг дел од својата кариера на работа со Oracle и PL/SQL и има напишано доста голем број дела на оваа тема. Една од неговите познати книги се вика: „Oracle PL/SQL. За професионалци“. Стивен беше тој што го разви решението utPLSQL, или, како што е тоа, рамка за тестирање на единици за 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