Cześć, Habr!
Nazywam się Maksym Ponomarenko i jestem programistą w Sportmasterze. Mam dziesięcioletnie doświadczenie w branży IT. Swoją karierę zacząłem w obszarze manualnego testowania, a następnie przeszedłem do tworzenia baz danych. Przez ostatnie 4 lata, kumulując wiedzę zdobytą w testowaniu i programowaniu, zajmuję się automatyzacją testów na poziomie systemów zarządzania bazami danych.
W zespole Sportmastera jestem od nieco ponad roku i w jednym z dużych projektów zajmuję się tworzeniem automatyzacji testów. W kwietniu wystąpiliśmy z chłopakami z Sportmaster Lab na konferencji w Krasnodarze, a mój wykład nosił tytuł „Testy jednostkowe w systemach zarządzania bazami danych”, i teraz chcę się nim z wami podzielić. Tekstu będzie dużo, dlatego postanowiłem podzielić wykład na dwa posty. W pierwszym porozmawiamy o automatyzacji testów i testowaniu w ogóle, a w drugim szczegółowo omówię nasz system testów jednostkowych oraz wyniki jego zastosowania.
Na początku trochę nudnej teorii. Czym jest automatyczne testowanie? To testowanie, które przeprowadza się przy pomocy oprogramowania, i w nowoczesnym IT jest coraz częściej stosowane w procesie tworzenia oprogramowania. Wynika to z faktu, że firmy rozwijają się, ich systemy informacyjne również, a co za tym idzie, rośnie również liczba funkcji, które trzeba testować. Przeprowadzanie ręcznych testów staje się coraz bardziej kosztowne i czasochłonne.
Pracowałem w dużej firmie, której wydania odbywały się co dwa miesiące. Przy tym cały miesiąc poświęcano na ręczne sprawdzanie funkcjonalności przez dziesięciu testerów. Dzięki wprowadzeniu automatyzacji, małym zespołem programistów udało nam się w ciągu półtora roku skrócić czas testowania do 2 tygodni. Nie tylko zwiększyliśmy szybkość testowania, ale również poprawiliśmy jego jakość. Testy automatyczne są uruchamiane regularnie i zawsze wykonują pełny zestaw wbudowanych kontroli, co eliminuje czynnik ludzki.
Dla współczesnego IT charakterystyczne jest to, że od programisty może być wymagane nie tylko pisanie kodu produktu, ale także pisanie testów jednostkowych, które weryfikują ten kod.
Co zrobić, jeśli Twój system opiera się głównie na logice serwerowej? Nie ma uniwersalnego rozwiązania ani ogólnych praktyk w tej dziedzinie. Zazwyczaj firmy rozwiązują ten problem, tworząc własny system testowania. Taki autorski system zautomatyzowanego testowania został stworzony w naszym projekcie, o czym opowiem w swoim wystąpieniu.
Testujemy lojalność
Na początek porozmawiajmy o projekcie, w którym wdrożyliśmy system zautomatyzowanego testowania. Nasz projekt to system lojalnościowy Sportmastera (zresztą, już pisaliśmy o tym w ).
Jeśli Twoja firma jest dostatecznie duża, Twój system lojalnościowy będzie miał trzy standardowe cechy:
- Twój system będzie intensywnie wykorzystywany
- Twój system będzie zawierać złożone procesy obliczeniowe
- Twój system będzie aktywnie rozwijany.
Zacznijmy od początku... Łącznie, jeśli spojrzeć na wszystkie marki Sportmastera, na terytorium Rosji, Ukrainy, Chin, Kazachstanu i Białorusi mamy ponad 1000 sklepów. W tych sklepach dziennie odbywa się około 300 000 zakupów. Oznacza to, że co sekundę do naszego systemu trafia 3-4 paragonów. Oczywiście, nasz system lojalnościowy jest intensywnie wykorzystywany. A ponieważ jest często używany, musimy zapewniać najwyższe standardy jego jakości, ponieważ każdy błąd w oprogramowaniu to znaczące straty finansowe, reputacyjne i inne.
Jednocześnie w Sportmasterze działa ponad sto różnych promocji. Promocje są bardzo zróżnicowane: są produktowe, są związane z dniem tygodnia, są przypisane do konkretnych sklepów, są promocje na kwotę paragonu, są na ilość produktów. W skrócie, to nie jest mała sprawa. Klienci mają bonusy, są kody promocyjne, które są używane przy zakupach. Wszystko to prowadzi do tego, że rozliczenie każdego zamówienia to dość złożone zadanie.
Algorytm obsługi zamówień jest naprawdę skomplikowany i trudny do zrozumienia. Jakiekolwiek zmiany w tym algorytmie mogą wiązać się z dużym ryzykiem. Nawet drobne zmiany mogą prowadzić do nieprzewidywalnych konsekwencji. A to właśnie takie skomplikowane procesy obliczeniowe, szczególnie realizujące krytyczne funkcje, są najlepszymi kandydatami do automatyzacji. Ręczne sprawdzanie dziesiątek podobnych przypadków zajmuje zbyt dużo czasu. A ponieważ punkt wejścia do procesu pozostaje niezmienny, można go raz opisać i dość szybko wygenerować automatyczne testy, mając pewność co do działania funkcjonalności.
Ponieważ nasz system jest aktywnie wykorzystywany, biznes będzie oczekiwał od Ciebie nowości, dostosowując się do zmieniających się czasów i stawiając na obsługę klienta. W naszym systemie lojalności wydania odbywają się co dwa miesiące. Oznacza to, że co dwa miesiące musimy przeprowadzać pełny regres całego systemu. Przy tym, jak w każdym nowoczesnym IT, rozwój nie trafia od razu od programisty na produkcję. Powstaje najpierw w obszarze programisty, następnie przechodzi przez testowy, wydaniowy, akceptacyjny, a dopiero potem trafia na produkcję. Co najmniej na obszarze testowym i wydaniowym musimy przeprowadzać pełny regres całego systemu.
Opisane właściwości są standardowe dla praktycznie każdego systemu lojalności. Porozmawiajmy o szczególnościach naszego projektu.
Technologicznie w 90% logika naszego systemu lojalności działa na serwerze i jest zrealizowana na Oracle. Mamy klienta wystawionego na Delphi, który pełni funkcję APM-administratora. Są dostępne usługi internetowe dla aplikacji zewnętrznych (na przykład strony internetowej). Dlatego też całkowicie logiczne jest, że jeśli zdecydujemy się na rozwój systemu automatyzacji testów, to będziemy to robić na Oracle.
System lojalności w Sportmasterze istnieje od ponad 7 lat i został stworzony przez pojedynczych programistów… Średnia liczba programistów pracujących nad naszym projektem w ciągu tych 7 lat wynosiła 3-4 osoby. Jednak w ostatnim roku nasz zespół znacznie się powiększył i teraz nad projektem pracuje 10 osób. Oznacza to, że do projektu dołączają ludzie, którzy nie są zaznajomieni ze standardowymi zadaniami, procesami, architekturą. Istnieje więc zwiększone ryzyko, że będziemy pomijać błędy.
W projekcie brakuje wydzielonych testerów jako etatowych pracowników. Testowanie, oczywiście, jest przeprowadzane, ale zajmują się nim analitycy oprócz swoich innych głównych obowiązków: komunikacji z biznesowymi zleceniodawcami, użytkownikami, opracowywaniem wymagań do systemu itd. Mimo że testowanie jest realizowane w sposób bardzo jakościowy (szczególnie warto to podkreślić, ponieważ niektórzy z analityków mogą zobaczyć ten raport), nikt nie podważa efektywności specjalizacji i koncentracji na czymś jednym.
Biorąc pod uwagę wszystkie powyższe, aby poprawić jakość dostarczanego produktu i skrócić czas rozwoju, pomysł automatyzacji testów w projekcie wydaje się bardzo logiczny. Na różnych etapach istnienia systemu lojalności niektórzy programiści podejmowali próby pokrycia swojego kodu testami jednostkowymi. Był to w zasadzie dość rozproszony proces, w którym każdy używał swojej architektury i metod. Wspólnym rezultatem dla testów jednostkowych były końcowe wyniki: testy były opracowywane, przez pewien czas używane, przechowywane w wersjonowanym repozytorium plików, ale w pewnym momencie przestawały działać i były zapominane. W pierwszej kolejności działo się tak, ponieważ testy były bardziej związane z konkretnym wykonawcą, a nie projektem.
Z pomocą przychodzi utPLSQL
Czy wiesz coś o Stephenie Feuersteinie?
To inteligentny facet, który dużą część swojej kariery poświęcił pracy z Oracle i PL/SQL, napisał na ten temat wystarczającą ilość prac. Jedna z jego znanych książek nosi tytuł: „Oracle PL/SQL. Dla profesjonalistów”. To właśnie Stephen jest twórcą rozwiązania utPLSQL, czyli frameworka do testowania jednostkowego dla Oracle PL/SQL. Rozwiązanie utPLSQL zostało stworzone w 2016 roku, ale prace nad nim trwają nadal i regularnie wydawane są nowe wersje. W momencie wystąpienia ostatnia wersja datowana była na 24 marca 2019 roku.
Czym to jest? To osobny projekt open source. Ma kilka megabajtów, łącznie z przykładami i dokumentacją. Fizycznie stanowi osobną schemę w bazie danych ORACLE z zestawem pakietów i tabel dla organizacji testów jednostkowych. Instalacja zajmuje kilka sekund. Charakterystyczną cechą utPLSQL jest jego prostota użytkowania.
Ogólnie rzecz biorąc, utPLSQL to mechanizm do uruchamiania testów jednostkowych, gdzie przez test jednostkowy rozumiemy zwykłe procedury pakietowe Oracle, których organizacja odpowiada pewnym zasadom. Oprócz uruchamiania utPLSQL przechowuje log wszystkich Twoich uruchomień testowych, a także ma wewnętrzny system raportowania.
Zobaczmy na przykładzie, jak wygląda kod testu jednostkowego zrealizowanego zgodnie z tą metodą.
Na ekranie przedstawiony jest kod typowej specyfikacji pakietu z testami jednostkowymi. Jakie są wymagania obowiązkowe? Pakiet musi mieć prefiks „utp_”. Taki sam prefiks powinny mieć wszystkie procedury testowe. W pakiecie koniecznie muszą znaleźć się dwie standardowe procedury: „utp_setup” i „utp_teardown”. Pierwsza procedura jest wywoływana przed każdym testem jednostkowym, druga — po jego uruchomieniu.
„utp_setup” zazwyczaj przygotowuje nasz system do uruchomienia testu jednostkowego, na przykład tworzy dane testowe. „utp_teardown” — przeciwnie, wszystko przywraca do pierwotnych ustawień i resetuje wyniki uruchomienia.
Oto przykład najprostszego testu jednostkowego, który sprawdza normalizację wprowadzonego numeru telefonu klienta do standardowego formatu naszego systemu lojalnościowego. Nie ma obowiązkowych standardów dotyczących pisania procedur z testami jednostkowymi. Zazwyczaj wywołuje się jakąś metodę testowanego systemu, a wynik zwrócony przez tę metodę porównuje się z referencyjnym. Ważne jest, aby porównanie wyniku referencyjnego z uzyskanym odbywało się za pomocą standardowych metod utPLSQL.
W teście jednostkowym może być dowolna liczba sprawdzeń. Jak widać w przykładzie, wykonujemy cztery sekwencyjne wywołania testowanej metody normalizacji numeru telefonu i po każdym wywołaniu oceniamy wynik. Podczas pisania testu jednostkowego należy mieć na uwadze, że są sprawdzenia, które w żaden sposób nie wpływają na system, natomiast po niektórych należy przywracać stan początkowy systemu.
Na przykład w przedstawionym teście jednostkowym po prostu formatujemy wejściowy numer telefonu, co w żaden sposób nie wpływa na system lojalnościowy.
A jeśli piszemy testy jednostkowe dla metody tworzenia nowego klienta, to po każdym sprawdzeniu w systemie zostanie stworzony nowy klient, co może wpłynąć na kolejne uruchomienie testu.
Tak uruchamiane są testy jednostkowe. Akceptowalne są dwa sposoby uruchamiania: uruchomienie wszystkich testów jednostkowych z konkretnego pakietu lub uruchomienie konkretnego testu jednostkowego w danym pakiecie.
Oto jak wygląda przykład wewnętrznego systemu raportowania. Na podstawie wyników działania testu jednostkowego utPLSQL generuje mały raport. W nim widzimy wyniki dla każdego konkretnego sprawdzenia oraz ogólny wynik wykonania testu jednostkowego.
6 zasad autotestów
Zanim przystąpiliśmy do tworzenia nowego systemu automatycznego testowania systemu lojalnościowego, wspólnie z kierownictwem określiliśmy zasady, którym nasze przyszłe autotesty powinny odpowiadać.
- Automatyczne testy muszą być skuteczne i przynosić korzyści. Mamy wspaniałych programistów, o których warto wspomnieć, ponieważ z pewnością ktoś z nich zobaczy ten raport, a oni piszą doskonały kod. Mimo to, nawet ich wspaniały kod nie jest doskonały i zawierał, zawiera i będzie zawierać błędy. Automatyczne testy muszą je znajdować. Jeśli tak nie jest, to albo piszemy złe automatyczne testy, albo trafiliśmy do martwego obszaru, który de facto nie jest rozwijany. W obu przypadkach robimy coś źle, a nasze podejście jest po prostu bezsensowne.
- Automatyczne testy powinny być używane. Nie ma sensu trwonić mnóstwo czasu i sił na napisanie produktu programowego, złożenie jego repozytorium i zapomnienie o nim. Testy powinny być uruchamiane, a uruchamiane jak najczęściej.
- Automatyczne testy muszą działać stabilnie. Bez względu na porę dnia, środowisko uruchomieniowe i inne ustawienia systemu, wyniki testów powinny być zawsze takie same. Zawsze zapewnia to to, że automatyczne testy działają z użyciem specjalnych danych testowych oraz ustalonych ustawień systemu.
- Automatyczne testy muszą działać z akceptowalną dla Twojego projektu szybkością. Czas ten określa się indywidualnie dla każdego systemu. Ktoś może sobie pozwolić na działanie przez cały dzień, a dla kogoś innego kluczowe jest zmieszczenie się w sekundach. Jakie normy szybkości osiągnęliśmy w naszym projekcie, opowiem za chwilę.
- Tworzenie automatycznych testów musi być elastyczne. Niepożądane jest rezygnowanie z weryfikacji jakiejkolwiek funkcjonalności tylko dlatego, że wcześniej tego nie robiliśmy lub z innych powodów. utPLSQL nie nakłada żadnych ograniczeń na rozwój, a Oracle w ogóle pozwala na realizację najróżniejszych rzeczy. Większość zadań ma rozwiązanie, kwestia tylko czasu i wydanych wysiłków.
- Wdrażalność. Mamy kilka środowisk, w których wymagane jest uruchamianie testów. Na każdym z tych środowisk w każdej chwili może być zaktualizowany zrzut danych. Należy prowadzić projekt z automatycznymi testami w taki sposób, aby mieć możliwość bezproblemowego przeprowadzenia jego pełnej lub częściowej instalacji.
A w drugim poście za kilka dni opowiem, co zrobiliśmy i jakie osiągnęliśmy wyniki.
Źródło: habr.com
