Čau Habr!
Volám sa Maxim Ponomarenko a som vývojár v Sportmaster. Mám 10 ročné skúsenosti v IT oblasti. Svoju kariéru začal v manuálnom testovaní, potom prešiel na vývoj databáz. Posledné 4 roky, hromadiac poznatky získané pri testovaní a vývoji, automatizujem testovanie na úrovni DBMS.
V tíme Sportmaster som niečo vyše roka a vyvíjam automatizované testovanie na jednom z veľkých projektov. V apríli sme s chalanmi zo Sportmaster Lab hovorili na konferencii v Krasnodare, moja správa sa volala „Testy jednotiek v DBMS“ a teraz sa o ňu chcem s vami podeliť. Textu bude veľa, preto som sa rozhodol správu rozdeliť na dva príspevky. V prvom si povieme o autotestoch a testovaní všeobecne a v druhom sa podrobnejšie zastavím pri našom systéme unit testovania a výsledkoch jeho aplikácie.
Najprv trochu nudná teória. Čo je to automatizované testovanie? Ide o testovanie, ktoré sa vykonáva pomocou softvéru a v moderných IT sa čoraz viac využíva pri vývoji softvéru. Je to spôsobené tým, že firmy rastú, ich informačné systémy rastú a podľa toho rastie aj množstvo funkcionality, ktorú treba testovať. Manuálne testovanie je čoraz drahšie.
Pracoval som pre veľkú spoločnosť, ktorej správy vychádzajú každé dva mesiace. Zároveň sa celý mesiac venovalo tomu, aby tucet testerov manuálne skontroloval funkčnosť. Vďaka implementácii automatizácie malým tímom vývojárov sa nám podarilo skrátiť čas testovania na 2 týždne za rok a pol. Zvýšili sme nielen rýchlosť testovania, ale aj jeho kvalitu. Automatizované testy sú spúšťané pravidelne a vykonávajú vždy celý priebeh kontrol v nich zahrnutých, teda vylučujeme ľudský faktor.
Moderné IT sa vyznačuje tým, že od vývojára sa môže vyžadovať nielen písanie produktového kódu, ale aj písanie unit testov, ktoré tento kód kontrolujú.
Ale čo ak je váš systém založený predovšetkým na serverovej logike? Na trhu neexistuje univerzálne riešenie ani osvedčené postupy. Spoločnosti tento problém spravidla riešia vytvorením vlastného systému testovania. Toto je náš vlastný automatizovaný testovací systém, ktorý bol vytvorený na našom projekte a budem o ňom hovoriť v mojej správe.
Testovanie lojality
Najprv si povieme niečo o projekte, kde sme nasadili automatizovaný testovací systém. Naším projektom je vernostný systém Sportmaster (mimochodom, už sme o ňom písali v ).
Ak je vaša spoločnosť dostatočne veľká, váš vernostný systém bude mať tri štandardné vlastnosti:
- Váš systém bude vysoko zaťažený
- Váš systém bude obsahovať zložité výpočtové procesy
- Váš systém sa bude aktívne zlepšovať.
Poďme pekne po poriadku... Celkovo, ak vezmeme do úvahy všetky značky Sportmaster, tak máme viac ako 1000 predajní v Rusku, na Ukrajine, v Číne, Kazachstane a Bielorusku. Každý deň sa v týchto obchodoch uskutoční okolo 300 000 nákupov. To znamená, že každú sekundu vstúpia do nášho systému 3-4 kontroly. Prirodzene, náš vernostný systém je veľmi zaťažený. A keďže sa aktívne používa, musíme poskytovať najvyššie štandardy jeho kvality, pretože akákoľvek chyba v softvéri znamená veľké peňažné, reputačné a iné straty.
Zároveň Sportmaster prevádzkuje viac ako sto rôznych akcií. Existujú rôzne akcie: akcie na produkty, akcie venované dňu v týždni, akcie viazané na konkrétny obchod, akcie na sumu účtenky, akcie na počet tovaru. Vo všeobecnosti nie zlé. Klienti majú bonusy a propagačné kódy, ktoré sa používajú pri nákupoch. To všetko vedie k tomu, že výpočet akejkoľvek objednávky je veľmi netriviálna úloha.
Algoritmus, ktorý implementuje spracovanie objednávok, je skutočne hrozný a komplikovaný. A akékoľvek zmeny tohto algoritmu sú dosť riskantné. Zdalo sa, že tie zdanlivo bezvýznamné zmeny môžu viesť k celkom nepredvídateľným účinkom. Ale práve takéto zložité výpočtové procesy, najmä tie, ktoré implementujú kritické funkcie, sú najlepšími kandidátmi na automatizáciu. Ručná kontrola desiatok podobných prípadov je časovo veľmi náročná. A keďže vstupný bod do procesu je nezmenený, po jeho opísaní môžete rýchlo vytvoriť automatické testy a byť si istí, že funkcia bude fungovať.
Keďže náš systém je aktívne využívaný, podnik od vás bude chcieť niečo nové, žiť s dobou a byť orientovaný na zákazníka. V našom vernostnom systéme vychádzajú vydania každé dva mesiace. To znamená, že každé dva mesiace musíme vykonať úplnú regresiu celého systému. Zároveň, prirodzene, ako v každom modernom IT, vývoj nejde hneď od vývojára k výrobe. Vzniká na okruhu vývojára, potom postupne prechádza testovacou stolicou, vydaním, prijatím a až potom skončí vo výrobe. Minimálne na testovacích a uvoľňovacích obvodoch musíme vykonať úplnú regresiu celého systému.
Popísané vlastnosti sú štandardom takmer každého vernostného systému. Poďme hovoriť o vlastnostiach nášho projektu.
Technologicky je 90 % logiky nášho vernostného systému založeného na serveri a implementované na Oracle. V Delphi je vystavený klient, ktorý plní funkciu správcu automatizovaného pracoviska. Existujú vystavené webové služby pre externé aplikácie (napríklad webové stránky). Preto je veľmi logické, že ak nasadíme automatizovaný testovací systém, urobíme to na Oracle.
Vernostný systém v Sportmaster existuje už viac ako 7 rokov a vytvorili ho jednotliví vývojári... Priemerný počet vývojárov na našom projekte za týchto 7 rokov bol 3-4 ľudia. Ale za posledný rok sa náš tím výrazne rozrástol a teraz na projekte pracuje 10 ľudí. To znamená, že do projektu prichádzajú ľudia, ktorí nie sú oboznámení s typickými úlohami, procesmi a architektúrou. A je tu zvýšené riziko, že nám uniknú chyby.
Projekt je charakterizovaný absenciou špecializovaných testerov ako personálnych jednotiek. Samozrejme existuje testovanie, ale testovanie vykonávajú analytici, okrem ich ďalších hlavných povinností: komunikácia s podnikovými zákazníkmi, používateľmi, vývoj systémových požiadaviek atď. atď... Napriek tomu, že testovanie prebieha veľmi kvalitne (to je obzvlášť vhodné spomenúť, keďže niektorým analytikom môže táto správa padnúť do oka), efektivita špecializácie a koncentrácie na jednu vec nebola zrušená .
Vzhľadom na všetky vyššie uvedené skutočnosti, s cieľom zlepšiť kvalitu dodávaného produktu a skrátiť čas vývoja, sa myšlienka automatizácie testovania na projekte javí ako veľmi logická. A v rôznych fázach existencie vernostného systému sa jednotliví vývojári snažili pokryť svoj kód jednotkovými testami. Celkovo to bol dosť nesúrodý proces, pričom každý používal svoju vlastnú architektúru a metódy. Konečné výsledky boli spoločné pre unit testy: testy boli vyvinuté, nejaký čas používané, uložené v úložisku súborov s verziou, no v určitom momente prestali bežať a boli zabudnuté. V prvom rade to bolo spôsobené tým, že testy boli viazané viac na konkrétneho interpreta, a nie na projekt.
utPLSQL prichádza na záchranu
Viete niečo o Stephenovi Feuersteinovi?
Je to šikovný chlapík, ktorý dlhú časť svojej kariéry venoval práci s Oracle a PL/SQL a napísal na túto tému pomerne veľké množstvo prác. Jedna z jeho slávnych kníh sa volá: „Oracle PL/SQL. Pre profesionálov." Bol to Stephen, kto vyvinul riešenie utPLSQL, alebo, ako to znamená, rámec Unit Testing pre Oracle PL/SQL. Riešenie utPLSQL vzniklo v roku 2016, no naďalej sa na ňom aktívne pracuje a vychádzajú nové verzie. V čase nahlásenia je najnovšia verzia z 24. marca 2019.
Čo je to. Toto je samostatný open source projekt. Váži niekoľko megabajtov vrátane príkladov a dokumentácie. Fyzicky ide o samostatnú schému v databáze ORACLE so sadou balíkov a tabuliek na organizáciu unit testovania. Inštalácia trvá niekoľko sekúnd. Charakteristickým rysom utPLSQL je jednoduchosť použitia.
Globálne je utPLSQL mechanizmus na spúšťanie unit testov, kde unit test je chápaný ako bežné dávkové procedúry Oracle, ktorých organizácia sa riadi určitými pravidlami. Okrem spustenia utPLSQL ukladá protokol všetkých vašich testov a má tiež interný systém podávania správ.
Pozrime sa na príklad toho, ako vyzerá kód testovania jednotky implementovaný pomocou tejto techniky.
Obrazovka teda zobrazuje kód pre typickú špecifikáciu balíka s testami jednotiek. Aké sú povinné požiadavky? Paket musí mať predponu "utp_". Všetky postupy s testami musia mať presne rovnakú predponu. Balík musí obsahovať dva štandardné postupy: „utp_setup“ a „utp_teardown“. Prvý postup sa volá reštartovaním každého testu jednotky, druhý - po spustení.
„utp_setup“ spravidla pripraví náš systém na spustenie testu jednotky, napríklad vytvorenie testovacích údajov. “utp_teardown” – naopak, všetko sa vráti do pôvodných nastavení a resetuje výsledky spustenia.
Tu je príklad najjednoduchšieho unit testu, ktorý kontroluje normalizáciu zadaného telefónneho čísla zákazníka na štandardný formulár pre náš vernostný systém. Neexistujú žiadne povinné normy, ako písať postupy s jednotkovými testami. Spravidla sa zavolá metóda testovaného systému a výsledok vrátený touto metódou sa porovná s referenčnou metódou. Je dôležité, aby porovnanie referenčného výsledku a získaného prebiehalo prostredníctvom štandardných metód utPLSQL.
Jednotkový test môže mať ľubovoľný počet kontrol. Ako vidno z príkladu, na testovanú metódu vykonáme štyri po sebe idúce hovory, aby sme znormalizovali telefónne číslo a po každom hovore vyhodnotili výsledok. Pri vývoji unit testu musíte počítať s tým, že existujú kontroly, ktoré systém nijako neovplyvňujú a po niektorých sa treba vrátiť do pôvodného stavu systému.
Napríklad v prezentovanom unit teste jednoducho naformátujeme vstupné telefónne číslo, čo nijako neovplyvní vernostný systém.
A ak unit testy píšeme metódou vytvorenia nového klienta, tak po každom teste sa v systéme vytvorí nový klient, čo môže ovplyvniť následné spustenie testu.
Takto prebiehajú testy jednotiek. Existujú dve možné možnosti spustenia: spustenie všetkých testov jednotiek z konkrétneho balíka alebo spustenie špecifického testu jednotky v konkrétnom balíku.
Takto vyzerá príklad interného systému výkazníctva. Na základe výsledkov unit testu vytvorí utPLSQL malú správu. V ňom vidíme výsledok pre každú konkrétnu kontrolu a celkový výsledok unit testu.
6 pravidiel autotestov
Pred začatím tvorby nového systému pre automatizované testovanie vernostného systému sme spolu s manažmentom určili princípy, ktorým by naše budúce automatizované testy mali vyhovovať.
- Autotesty musia byť účinné a musia byť užitočné. Máme úžasných vývojárov, ktorých určite treba spomenúť, pretože niektorí z nich pravdepodobne uvidia túto správu a píšu úžasný kód. Ale ani ich úžasný kód nie je dokonalý a má, má a bude obsahovať chyby. Na nájdenie týchto chýb sú potrebné automatické testy. Ak to tak nie je, potom buď píšeme zlé autotesty, alebo sme sa dostali do mŕtvej oblasti, ktorá sa v zásade nerozvíja. V oboch prípadoch robíme niečo zle a náš prístup jednoducho nedáva zmysel.
- Mali by sa použiť autotesty. Nemá zmysel tráviť veľa času a úsilia napísaním softvérového produktu, vložiť ho do úložiska a zabudnúť. Testy by sa mali vykonávať čo najpravidelnejšie.
- Autotesty by mali fungovať stabilne. Bez ohľadu na dennú dobu, štartovací stojan a iné systémové nastavenia by skúšobné prevádzky mali viesť k rovnakému výsledku. Spravidla je to zabezpečené tým, že autotesty pracujú so špeciálnymi testovacími dátami s pevným nastavením systému.
- Autotesty by mali fungovať rýchlosťou prijateľnou pre váš projekt. Tento čas sa určuje individuálne pre každý systém. Niektorí ľudia si môžu dovoliť pracovať celý deň, zatiaľ čo iní považujú za dôležité urobiť to za pár sekúnd. O niečo neskôr vám poviem, aké rýchlostné štandardy sme v našom projekte dosiahli.
- Vývoj autotestu by mal byť flexibilný. Nie je vhodné odmietnuť testovanie akejkoľvek funkcionality len preto, že sme to predtým neurobili alebo z nejakého iného dôvodu. utPLSQL nekladie žiadne obmedzenia na vývoj a Oracle vám v zásade umožňuje implementovať rôzne veci. Väčšina problémov má riešenie, je to len otázka času a úsilia.
- Nasaditeľnosť. Máme niekoľko stánkov, kde potrebujeme vykonať testy. Na každom stojane je možné kedykoľvek aktualizovať výpis dát. Je potrebné vykonať projekt s automatickými testami tak, aby ste mohli bezbolestne vykonať jeho úplnú alebo čiastočnú inštaláciu.
A v druhom príspevku o pár dní vám poviem, čo sme urobili a aké výsledky sme dosiahli.
Zdroj: hab.com