Hej Habra!
Nazywam się Maxim Ponomarenko i jestem programistą w Sportmaster. Posiadam 10-letnie doświadczenie w branży IT. Rozpoczął karierę od testów manualnych, następnie zajął się tworzeniem baz danych. Przez ostatnie 4 lata gromadząc wiedzę zdobytą podczas testowania i rozwoju, zajmuję się automatyzacją testów na poziomie DBMS.
Jestem w zespole Sportmaster od nieco ponad roku i opracowuję automatyczne testy w jednym z dużych projektów. W kwietniu rozmawiałem z chłopakami ze Sportmaster Lab na konferencji w Krasnodarze, mój raport nosił tytuł „Testy jednostkowe w systemie DBMS” i teraz chcę się nim z wami podzielić. Tekstu będzie dużo, dlatego postanowiłam podzielić relację na dwa posty. W pierwszym omówimy ogólnie autotesty i testowanie, a w drugim bardziej szczegółowo omówię nasz system testów jednostkowych i wyniki jego zastosowania.
Na początek trochę nudna teoria. Co to jest testowanie automatyczne? Jest to testowanie przeprowadzane przez oprogramowanie, które we współczesnym IT jest coraz częściej wykorzystywane przy tworzeniu oprogramowania. Dzieje się tak dlatego, że firmy się rozwijają, rozrastają się ich systemy informatyczne, a co za tym idzie, rośnie ilość funkcjonalności wymagających przetestowania. Przeprowadzanie testów manualnych staje się coraz droższe.
Pracowałem dla dużej firmy, której wydawnictwa ukazują się co dwa miesiące. Jednocześnie przez cały miesiąc kilkunastu testerów ręcznie sprawdzało funkcjonalność. Dzięki wdrożeniu automatyzacji przez niewielki zespół programistów udało nam się skrócić czas testów do 2 tygodni w ciągu półtora roku. Nie tylko zwiększyliśmy szybkość testów, ale także poprawiliśmy ich jakość. Regularnie uruchamiane są automatyczne testy, które zawsze realizują cały objęty nimi cykl kontroli, czyli wykluczamy czynnik ludzki.
Współczesne IT charakteryzuje się tym, że od programisty może być wymagane nie tylko napisanie kodu produktu, ale także napisanie testów jednostkowych sprawdzających ten kod.
Co jednak, jeśli Twój system opiera się przede wszystkim na logice serwerowej? Na rynku nie ma uniwersalnego rozwiązania ani najlepszych praktyk. Z reguły firmy rozwiązują ten problem, tworząc własny, samodzielnie napisany system testowania. Jest to nasz autorski system do automatycznego testowania, który powstał w ramach naszego projektu i opowiem o nim w moim raporcie.
Testowanie lojalności
Na początek porozmawiajmy o projekcie, w którym wdrożyliśmy zautomatyzowany system testowania. Naszym projektem jest system lojalnościowy Sportmaster (swoją drogą pisaliśmy o tym już w ).
Jeśli Twoja firma jest wystarczająco duża, Twój system lojalnościowy będzie miał trzy standardowe właściwości:
- Twój system będzie bardzo obciążony
- Twój system będzie zawierał złożone procesy obliczeniowe
- Twój system będzie aktywnie udoskonalany.
Przejdźmy do porządku... W sumie, jeśli weźmiemy pod uwagę wszystkie marki Sportmaster, to mamy ponad 1000 sklepów w Rosji, Ukrainie, Chinach, Kazachstanie i Białorusi. Codziennie dokonuje się w nich około 300 000 zakupów. Oznacza to, że co sekundę do naszego systemu trafiają 3-4 czeki. Naturalnie nasz system lojalnościowy jest bardzo obciążony. A ponieważ jest aktywnie wykorzystywane, musimy zapewnić najwyższe standardy jego jakości, ponieważ każdy błąd w oprogramowaniu oznacza duże straty pieniężne, reputacyjne i inne.
Jednocześnie Sportmaster prowadzi ponad sto różnych promocji. Promocji jest wiele: są promocje produktowe, są dedykowane dniu tygodnia, są powiązane z konkretnym sklepem, są promocje na kwotę paragonu, są na liczbę towarów. Ogólnie nie jest źle. Klienci mają do dyspozycji bonusy i kody promocyjne, które wykorzystują podczas dokonywania zakupów. Wszystko to prowadzi do tego, że obliczenie dowolnego zamówienia jest zadaniem bardzo nietrywialnym.
Algorytm realizujący przetwarzanie zamówień jest naprawdę okropny i skomplikowany. A wszelkie zmiany w tym algorytmie są dość ryzykowne. Wydawało się, że najbardziej pozornie nieistotne zmiany mogą prowadzić do zupełnie nieprzewidywalnych skutków. Ale to właśnie takie złożone procesy obliczeniowe, zwłaszcza te, które realizują krytyczną funkcjonalność, są najlepszymi kandydatami do automatyzacji. Ręczne sprawdzanie dziesiątek podobnych spraw jest bardzo czasochłonne. A ponieważ punkt wejścia do procesu pozostaje niezmienny, po jednorazowym opisaniu można szybko stworzyć automatyczne testy i mieć pewność, że funkcjonalność będzie działać.
Ponieważ nasz system jest aktywnie wykorzystywany, firma będzie chciała od Ciebie czegoś nowego, żyć z duchem czasu i być zorientowana na klienta. W naszym systemie lojalnościowym aktualizacje ukazują się co dwa miesiące. Oznacza to, że co dwa miesiące musimy przeprowadzić pełną regresję całego systemu. Jednocześnie, oczywiście, jak w każdym nowoczesnym IT, rozwój nie przechodzi od razu od programisty do produkcji. Pochodzi z obwodu wywoływacza, następnie sukcesywnie przechodzi przez stanowisko testowe, wydanie, akceptację i dopiero wtedy trafia do produkcji. Przynajmniej na obwodach testowym i wyzwalającym musimy przeprowadzić pełną regresję całego systemu.
Opisane właściwości są standardem dla niemal każdego systemu lojalnościowego. Porozmawiajmy o cechach naszego projektu.
Technologicznie 90% logiki naszego systemu lojalnościowego jest oparte na serwerze i zaimplementowane na platformie Oracle. W Delphi wystawiony jest klient, który pełni funkcję administratora zautomatyzowanego miejsca pracy. Istnieją odsłonięte usługi sieciowe dla aplikacji zewnętrznych (na przykład strony internetowej). Dlatego bardzo logiczne jest, że jeśli wdrożymy system automatycznego testowania, zrobimy to na Oracle.
System lojalnościowy w Sportmaster istnieje od ponad 7 lat i został stworzony przez pojedynczych programistów... Średnia liczba programistów na naszym projekcie w ciągu tych 7 lat to 3-4 osoby. Jednak przez ostatni rok nasz zespół znacznie się powiększył i obecnie nad projektem pracuje 10 osób. Oznacza to, że do projektu przychodzą ludzie, którzy nie są zaznajomieni z typowymi zadaniami, procesami i architekturą. I istnieje zwiększone ryzyko, że przeoczymy błędy.
Projekt charakteryzuje się brakiem dedykowanych testerów jako jednostek personalnych. Oczywiście istnieje testowanie, ale testowanie jest przeprowadzane przez analityków, oprócz innych głównych obowiązków: komunikacji z klientami biznesowymi, użytkownikami, opracowywania wymagań systemowych itp. itd... Pomimo faktu, że badania są przeprowadzane na bardzo wysokim poziomie (warto o tym szczególnie wspomnieć, ponieważ niektórzy analitycy mogą zwrócić uwagę na ten raport), skuteczność specjalizacji i koncentracji na jednej rzeczy nie została anulowana .
Biorąc to wszystko pod uwagę, aby poprawić jakość dostarczonego produktu i skrócić czas rozwoju, pomysł automatyzacji testów na projekcie wydaje się bardzo logiczny. Natomiast na różnych etapach istnienia systemu lojalnościowego poszczególni programiści starali się pokryć swój kod testami jednostkowymi. Ogólnie rzecz biorąc, był to dość chaotyczny proces, w którym każdy stosował własną architekturę i metody. Ostateczne wyniki były wspólne dla testów jednostkowych: testy zostały opracowane, używane przez pewien czas, przechowywane w wersjonowanym magazynie plików, ale w pewnym momencie przestały działać i zostały zapomniane. Przede wszystkim wynikało to z faktu, że testy były przywiązane bardziej do konkretnego wykonawcy, a nie do projektu.
utPLSQL przychodzi na ratunek
Czy wiesz coś o Stephenie Feuersteinie?
To mądry facet, który dużą część swojej kariery poświęcił pracy z Oracle i PL/SQL i napisał całkiem sporo prac na ten temat. Jedna z jego znanych książek nosi tytuł: „Oracle PL/SQL. Dla profesjonalistów.” To Stephen opracował rozwiązanie utPLSQL, czyli po prostu framework do testów jednostkowych dla Oracle PL/SQL. Rozwiązanie utPLSQL powstało w 2016 roku, jednak nadal trwają nad nim aktywne prace i wydawane są nowe wersje. W momencie sporządzania raportu najnowsza wersja pochodzi z 24 marca 2019 r.
Co to jest. Jest to odrębny projekt open source. Waży kilka megabajtów, łącznie z przykładami i dokumentacją. Fizycznie jest to odrębny schemat w bazie ORACLE z zestawem pakietów i tabel do organizacji testów jednostkowych. Instalacja zajmuje kilka sekund. Charakterystyczną cechą utPLSQL jest łatwość użycia.
Globalnie utPLSQL jest mechanizmem do uruchamiania testów jednostkowych, przy czym test jednostkowy rozumiany jest jako zwykłe procedury wsadowe Oracle, których organizacja opiera się na określonych zasadach. Oprócz uruchamiania utPLSQL przechowuje dziennik wszystkich przebiegów testów, a także posiada wewnętrzny system raportowania.
Spójrzmy na przykład, jak wygląda kod testu jednostkowego zaimplementowany przy użyciu tej techniki.
Zatem ekran pokazuje kod typowej specyfikacji pakietu z testami jednostkowymi. Jakie są wymagania obowiązkowe? Pakiet musi być poprzedzony „utp_”. Wszystkie procedury z testami muszą mieć dokładnie ten sam przedrostek. Pakiet musi zawierać dwie standardowe procedury: „utp_setup” i „utp_teardown”. Pierwsza procedura wywoływana jest poprzez ponowne uruchomienie każdego testu jednostkowego, druga – po uruchomieniu.
„utp_setup” z reguły przygotowuje nasz system do uruchomienia testu jednostkowego, np. tworzenia danych testowych. „utp_teardown” - wręcz przeciwnie, wszystko wraca do oryginalnych ustawień i resetuje wyniki uruchamiania.
Oto przykład najprostszego testu jednostkowego sprawdzającego normalizację wprowadzonego numeru telefonu klienta do standardowego formularza dla naszego systemu lojalnościowego. Nie ma obowiązkowych standardów pisania procedur z testami jednostkowymi. Z reguły wywoływana jest metoda testowanego systemu, a wynik zwrócony tą metodą porównywany jest z wynikiem referencyjnym. Ważne jest, aby porównanie wyniku referencyjnego z uzyskanym odbyło się standardowymi metodami utPLSQL.
Test jednostkowy może obejmować dowolną liczbę kontroli. Jak widać na przykładzie, wykonujemy cztery kolejne wywołania testowanej metody, aby znormalizować numer telefonu i ocenić wynik po każdym połączeniu. Opracowując test jednostkowy, należy wziąć pod uwagę, że istnieją kontrole, które w żaden sposób nie wpływają na system, a po niektórych trzeba przywrócić system do pierwotnego stanu.
Przykładowo w prezentowanym teście jednostkowym po prostu formatujemy wprowadzony numer telefonu, co nie wpływa w żaden sposób na system lojalnościowy.
A jeśli napiszemy testy jednostkowe metodą tworzenia nowego klienta, to po każdym teście w systemie zostanie utworzony nowy klient, co może mieć wpływ na późniejsze uruchomienie testu.
W ten sposób przeprowadzane są testy jednostkowe. Istnieją dwie możliwe opcje uruchomienia: uruchomienie wszystkich testów jednostkowych z określonego pakietu lub uruchomienie określonego testu jednostkowego w określonym pakiecie.
Tak wygląda przykładowy system raportowania wewnętrznego. Na podstawie wyników testu jednostkowego utPLSQL tworzy mały raport. Widzimy w nim wynik każdej konkretnej kontroli i ogólny wynik testu jednostkowego.
6 zasad autotestów
Przed przystąpieniem do tworzenia nowego systemu do automatycznego testowania systemu lojalnościowego wspólnie z zarządem ustaliliśmy zasady, jakimi powinny kierować się nasze przyszłe automatyczne testy.
- Autotesty muszą być skuteczne i przydatne. Mamy wspaniałych programistów, o których zdecydowanie trzeba wspomnieć, ponieważ niektórzy z nich prawdopodobnie zobaczą ten raport i piszą wspaniały kod. Ale nawet ich wspaniały kod nie jest doskonały i zawiera, zawiera i nadal będzie zawierał błędy. Aby znaleźć te błędy, wymagane są autotesty. Jeśli tak nie jest, to albo piszemy złe autotesty, albo doszliśmy do martwego obszaru, który w zasadzie nie jest rozwijany. W obu przypadkach robimy coś złego i nasze podejście po prostu nie ma sensu.
- Należy stosować autotesty. Nie ma sensu spędzać dużo czasu i wysiłku na pisaniu oprogramowania, umieszczać go w repozytorium i zapominać. Testy należy przeprowadzać tak regularnie, jak to możliwe.
- Autotesty powinny działać stabilnie. Niezależnie od pory dnia, stanowiska startowego i innych ustawień systemu, przebiegi testowe powinny dać ten sam wynik. Z reguły zapewnia to fakt, że autotesty działają ze specjalnymi danymi testowymi przy stałych ustawieniach systemu.
- Autotesty powinny działać z prędkością akceptowalną dla Twojego projektu. Czas ten ustalany jest indywidualnie dla każdego systemu. Niektórzy ludzie mogą sobie pozwolić na pracę przez cały dzień, podczas gdy dla innych najważniejsze jest, aby zrobić to w ciągu kilku sekund. Nieco później opowiem jakie standardy prędkości osiągnęliśmy w naszym projekcie.
- Rozwój autotestów powinien być elastyczny. Nie zaleca się odmawiania przetestowania jakiejkolwiek funkcjonalności tylko dlatego, że nie robiliśmy tego wcześniej lub z innego powodu. utPLSQL nie nakłada żadnych ograniczeń na rozwój, a Oracle w zasadzie pozwala na implementację różnych rzeczy. Większość problemów ma rozwiązanie, to tylko kwestia czasu i wysiłku.
- Możliwość wdrożenia. Mamy kilka stanowisk, na których musimy przeprowadzić testy. Na każdym stanowisku można w każdej chwili dokonać aktualizacji zrzutu danych. Konieczne jest przeprowadzenie projektu wraz z automatycznymi testami w taki sposób, aby można było bezboleśnie przeprowadzić jego pełną lub częściową instalację.
A w drugim poście za kilka dni opowiem co zrobiliśmy i jakie osiągnęliśmy rezultaty.
Źródło: www.habr.com