Čau Habr!
Jmenuji se Maxim Ponomarenko a jsem vývojář ve společnosti Sportmaster. Mám 10 let praxe v IT oboru. Svou kariéru začal v manuálním testování, poté přešel na vývoj databází. Poslední 4 roky, hromadění znalostí získaných při testování a vývoji, automatizuji testování na úrovni DBMS.
V týmu Sportmaster jsem něco málo přes rok a vyvíjím automatizované testování na jednom z hlavních projektů. V dubnu jsme s kluky ze Sportmaster Lab hovořili na konferenci v Krasnodaru, moje zpráva se jmenovala „Testy jednotek v DBMS“ a nyní se o ni chci s vámi podělit. Textu bude hodně, proto jsem se rozhodl rozdělit zprávu do dvou příspěvků. V prvním si povíme něco o autotestech a testování obecně a ve druhém se podrobněji zastavím u našeho systému unit testing a výsledků jeho aplikace.
Nejprve trochu nudná teorie. Co je to automatizované testování? Jedná se o testování, které se provádí pomocí softwaru a v moderních IT se stále více používá při vývoji softwaru. Je to dáno tím, že firmy rostou, jejich informační systémy rostou a podle toho roste i množství funkčnosti, kterou je potřeba testovat. Provádění ručního testování je stále dražší.
Pracoval jsem pro velkou společnost, jejíž zprávy vycházejí každé dva měsíce. Celý měsíc přitom trvalo, než tucet testerů ručně zkontroloval funkčnost. Díky implementaci automatizace malým týmem vývojářů se nám podařilo zkrátit dobu testování na 2 týdny za rok a půl. Testování jsme nejen zrychlili, ale také zkvalitnili. Automatizované testy jsou spouštěny pravidelně a provádějí vždy celý průběh kontrol v nich zahrnutých, tedy vylučujeme lidský faktor.
Moderní IT se vyznačuje tím, že od vývojáře může být požadováno nejen psaní kódu produktu, ale také psaní unit testů, které tento kód kontrolují.
Ale co když je váš systém založen primárně na logice serveru? Na trhu neexistuje univerzální řešení ani osvědčené postupy. Společnosti tento problém zpravidla řeší vytvořením vlastního samopsaného testovacího systému. Toto je náš vlastní automatizovaný testovací systém, který byl vytvořen na našem projektu a budu o něm mluvit ve své zprávě.
Testování loajality
Nejprve si povíme něco o projektu, kde jsme nasadili automatizovaný testovací systém. Naším projektem je věrnostní systém Sportmaster (mimochodem, již jsme o něm psali v ).
Pokud je vaše společnost dostatečně velká, bude mít váš věrnostní systém tři standardní vlastnosti:
- Váš systém bude velmi zatížen
- Váš systém bude obsahovat složité výpočetní procesy
- Váš systém bude aktivně vylepšován.
Pojďme popořadě... Celkem, když vezmeme v úvahu všechny značky Sportmaster, tak máme více než 1000 prodejen v Rusku, na Ukrajině, v Číně, Kazachstánu a Bělorusku. Každý den se v těchto obchodech uskuteční asi 300 000 nákupů. To znamená, že každou sekundu do našeho systému vstupují 3-4 kontroly. Náš věrnostní systém je přirozeně velmi nabitý. A protože je aktivně používán, musíme poskytovat nejvyšší standardy jeho kvality, protože jakákoli chyba v softwaru znamená velké peněžní, reputační a jiné ztráty.
Sportmaster zároveň provozuje více než sto různých akcí. Existují různé akce: existují akce na produkty, jsou tam ty, které se věnují dni v týdnu, jsou ty vázané na konkrétní obchod, jsou tam akce na částku účtenky, jsou na počet zboží. Obecně to není špatné. Klienti mají bonusy a propagační kódy, které se používají při nákupech. To vše vede k tomu, že výpočet jakékoli objednávky je velmi netriviální úkol.
Algoritmus, který implementuje zpracování objednávek, je opravdu hrozný a komplikovaný. A jakékoli změny tohoto algoritmu jsou docela riskantní. Zdálo se, že ty zdánlivě nevýznamné změny mohou vést k docela nepředvídatelným účinkům. Ale právě takové složité výpočetní procesy, zejména ty, které implementují kritické funkce, jsou nejlepšími kandidáty na automatizaci. Ruční kontrola desítek podobných případů je časově velmi náročná. A protože vstupní bod do procesu je nezměněn, po jeho popisu můžete rychle vytvořit automatické testy a být si jisti, že funkce bude fungovat.
Vzhledem k tomu, že je náš systém aktivně využíván, bude po vás firma chtít něco nového, žít s dobou a orientovat se na zákazníka. V našem věrnostním systému vychází novinky každé dva měsíce. To znamená, že každé dva měsíce musíme provést kompletní regresi celého systému. Zároveň přirozeně, jako v každém moderním IT, vývoj nejde hned od vývojáře k výrobě. Vzniká na vývojářském okruhu, poté postupně prochází testovací stolicí, vydáváním, přijímáním a teprve poté končí ve výrobě. Minimálně na testovacích a spouštěcích obvodech musíme provést úplnou regresi celého systému.
Popsané vlastnosti jsou standardní pro téměř jakýkoli věrnostní systém. Pojďme si promluvit o vlastnostech našeho projektu.
Technologicky je 90 % logiky našeho věrnostního systému založeno na serveru a je implementováno na Oracle. V Delphi je vystaven klient, který plní funkci správce automatizovaného pracoviště. Existují vystavené webové služby pro externí aplikace (například webové stránky). Proto je velmi logické, že pokud nasadíme automatizovaný testovací systém, budeme to dělat na Oracle.
Věrnostní systém ve Sportmaster existuje více než 7 let a byl vytvořen jednotlivými vývojáři... Průměrný počet vývojářů na našem projektu za těchto 7 let byl 3-4 lidé. Ale za poslední rok se náš tým výrazně rozrostl a nyní na projektu pracuje 10 lidí. To znamená, že do projektu přicházejí lidé, kteří nejsou obeznámeni s typickými úkoly, procesy a architekturou. A je zvýšené riziko, že nám chyby uniknou.
Projekt je charakterizován absencí specializovaných testerů jako personálních jednotek. Testování samozřejmě existuje, ale testování provádějí analytici, kromě jejich dalších hlavních povinností: komunikace s firemními zákazníky, uživateli, vývoj systémových požadavků atd. atd... Navzdory tomu, že testování je prováděno velmi kvalitně (to je zvláště vhodné zmínit, protože některým z analytiků může tato zpráva padnout do oka), efektivita specializace a koncentrace na jednu věc nebyla zrušena .
Vzhledem ke všemu výše uvedenému se pro zlepšení kvality dodávaného produktu a zkrácení doby vývoje zdá myšlenka automatizace testování na projektu velmi logická. A v různých fázích existence věrnostního systému se jednotliví vývojáři snažili pokrýt svůj kód jednotkovými testy. Celkově to byl poměrně nesourodý proces, kdy každý používal svou vlastní architekturu a metody. Konečné výsledky byly společné pro testy jednotek: testy byly vyvinuty, nějakou dobu používány, uloženy v úložišti souborů s verzí, ale v určitém okamžiku přestaly běžet a byly zapomenuty. V první řadě to bylo dáno tím, že testy byly vázány spíše na konkrétního interpreta, a ne na projekt.
utPLSQL přichází na pomoc
Víte něco o Stephenu Feuersteinovi?
Jde o chytráka, který dlouhou část své kariéry zasvětil práci s Oracle a PL/SQL a napsal na toto téma poměrně velké množství prací. Jedna z jeho slavných knih se jmenuje: „Oracle PL/SQL. Pro profesionály." Byl to Stephen, kdo vyvinul řešení utPLSQL, nebo, jak to znamená, framework Unit Testing pro Oracle PL/SQL. Řešení utPLSQL vzniklo v roce 2016, ale nadále se na něm aktivně pracuje a vycházejí nové verze. V době hlášení pochází nejnovější verze z 24. března 2019.
Co je to. Jedná se o samostatný open source projekt. Váží několik megabajtů, včetně příkladů a dokumentace. Fyzicky se jedná o samostatné schéma v databázi ORACLE se sadou balíčků a tabulek pro organizaci unit testování. Instalace trvá několik sekund. Charakteristickým rysem utPLSQL je jeho snadné použití.
Globálně je utPLSQL mechanismus pro spouštění unit testů, kdy unit test je chápán jako běžné dávkové procedury Oracle, jejichž organizace se řídí určitými pravidly. Kromě spuštění utPLSQL ukládá protokol všech vašich testovacích běhů a má také interní systém hlášení.
Podívejme se na příklad toho, jak vypadá testovací kód jednotky, implementovaný pomocí této techniky.
Obrazovka tedy zobrazuje kód pro typickou specifikaci balíčku s testy jednotek. Jaké jsou povinné požadavky? Paket musí mít předponu "utp_". Všechny procedury s testy musí mít přesně stejnou předponu. Balíček musí obsahovat dvě standardní procedury: „utp_setup“ a „utp_teardown“. První procedura je volána restartováním každého testu jednotky, druhá - po spuštění.
„utp_setup“ zpravidla připravuje náš systém na spuštění unit testu, například vytvořením testovacích dat. “utp_teardown” - naopak vše se vrátí do původního nastavení a resetuje výsledky spuštění.
Zde je příklad nejjednoduššího jednotkového testu, který kontroluje normalizaci zadaného telefonního čísla zákazníka do standardního formuláře pro náš věrnostní systém. Neexistují žádné povinné normy, jak psát procedury s jednotkovými testy. Zpravidla se zavolá metoda testovaného systému a výsledek vrácený touto metodou se porovná s referenční. Je důležité, aby porovnání referenčního výsledku a získaného probíhalo pomocí standardních metod utPLSQL.
Jednotkový test může mít libovolný počet kontrol. Jak je patrné z příkladu, provedeme čtyři po sobě jdoucí volání testované metody pro normalizaci telefonního čísla a vyhodnocení výsledku po každém volání. Při vývoji unit testu musíte počítat s tím, že existují kontroly, které systém nijak neovlivňují a po některých je třeba se vrátit do původního stavu systému.
Například v prezentovaném unit testu jednoduše naformátujeme vstupní telefonní číslo, což nijak neovlivňuje věrnostní systém.
A pokud budeme psát unit testy metodou vytvoření nového klienta, tak po každém testu se v systému vytvoří nový klient, což může ovlivnit následné spuštění testu.
Takto probíhají testy jednotek. Existují dvě možné možnosti spuštění: spuštění všech testů jednotek z určitého balíčku nebo spuštění konkrétního testu jednotek v konkrétním balíčku.
Takto vypadá příklad systému interního reportingu. Na základě výsledků unit testu vytvoří utPLSQL malou sestavu. V něm vidíme výsledek pro každou konkrétní kontrolu a celkový výsledek unit testu.
6 pravidel autotestů
Před zahájením tvorby nového systému pro automatizované testování věrnostního systému jsme společně s vedením stanovili principy, kterým by naše budoucí automatizované testy měly vyhovovat.
- Autotesty musí být účinné a musí být užitečné. Máme skvělé vývojáře, které je určitě potřeba zmínit, protože někteří z nich pravděpodobně uvidí tuto zprávu a píší úžasný kód. Ale ani jejich úžasný kód není dokonalý a má, má a bude obsahovat chyby. K nalezení těchto chyb jsou vyžadovány automatické testy. Pokud tomu tak není, pak buď píšeme špatné autotesty, nebo jsme se dostali do mrtvé oblasti, která se v zásadě nevyvíjí. V obou případech děláme něco špatně a náš přístup prostě nedává smysl.
- Měly by být použity autotesty. Nemá smysl trávit spoustu času a úsilí psaním softwarového produktu, ukládat jej do úložiště a zapomenout na něj. Testy by měly být spouštěny a spouštěny tak pravidelně, jak je to jen možné.
- Autotesty by měly fungovat stabilně. Bez ohledu na denní dobu, spouštěcí stojan a další nastavení systému by zkušební běhy měly vést ke stejnému výsledku. Zpravidla je to zajištěno tím, že autotesty pracují se speciálními testovacími daty s pevným nastavením systému.
- Autotesty by měly fungovat rychlostí přijatelnou pro váš projekt. Tato doba je stanovena individuálně pro každý systém. Někteří lidé si mohou dovolit pracovat celý den, zatímco pro jiné je důležité to udělat během několika sekund. O něco později vám řeknu, jakých rychlostních standardů jsme v našem projektu dosáhli.
- Vývoj autotestu by měl být flexibilní. Nedoporučuje se odmítat testovat jakoukoli funkčnost jen proto, že jsme to dříve neudělali nebo z nějakého jiného důvodu. utPLSQL neklade žádná omezení na vývoj a Oracle v zásadě umožňuje implementovat různé věci. Většina problémů má řešení, je to jen otázka času a úsilí.
- Nasaditelnost. Máme několik stánků, kde potřebujeme provést testy. Na každém stojanu lze kdykoliv aktualizovat výpis dat. Je nutné provést projekt s automatickými testy tak, abyste mohli bezbolestně provést jeho úplnou nebo částečnou instalaci.
A ve druhém příspěvku vám za pár dní řeknu, co jsme udělali a jakých výsledků jsme dosáhli.
Zdroj: www.habr.com