Testy jednostkowe w DBMS - jak to robimy w Sportmaster, część druga

Pierwsza część - tutaj.

Wyobraź sobie sytuację. Stoisz przed zadaniem opracowania nowej funkcjonalności. Masz doświadczenie swoich poprzedników. Zakładając, że nie masz żadnych moralnych zobowiązań, co byś zrobił?

Najczęściej wszystkie stare wydarzenia są zapominane i wszystko zaczyna się od nowa. Nikt nie lubi grzebać w czyimś kodzie, a jeśli masz czas, dlaczego nie zacząć tworzyć własnego systemu? Jest to typowe podejście i pod wieloma względami słuszne. Ale w naszym projekcie działaliśmy inaczej. Przyszły zautomatyzowany system testowania oparliśmy na rozwoju testów jednostkowych na utPLSQL od naszych poprzedników, a następnie przystąpiliśmy do pracy w kilku równoległych kierunkach.

1. Przywracanie starych testów jednostkowych. Recovery oznacza dostosowanie testów do istniejącego stanu systemu lojalnościowego oraz dostosowanie testów do standardów utPLSQL.
2. Rozwiązywanie problemu ze zrozumieniem, a co dokładnie, jakimi metodami i procesami objęliśmy autotestami. Musisz albo zachować te informacje w głowie, albo wyciągać wnioski bezpośrednio na podstawie kodu autotestów. Dlatego postanowiliśmy stworzyć katalog. Każdemu autotestowi przypisaliśmy unikalny kod mnemoniczny, stworzyliśmy opis i poprawiliśmy ustawienia (na przykład, w jakich warunkach powinien zostać uruchomiony lub co powinno się stać, jeśli test się nie powiedzie). Zasadniczo wypełniliśmy metadane dotyczące autotestów i umieściliśmy te metadane w standardowych tabelach schematu utPLSQL.
3. Definicja strategii ekspansji, tj. wybór funkcjonalności, która podlega weryfikacji autotestami. Postanowiliśmy zwrócić uwagę na trzy rzeczy: nowe usprawnienia systemu, incydenty z produkcji oraz kluczowe procesy systemu. Tym samym rozwijamy się równolegle z wydaniem, dbając o jego wyższą jakość, jednocześnie poszerzając zakres regresji i zapewniając niezawodność systemu w krytycznych miejscach. Pierwszym takim wąskim gardłem był proces dystrybucji zniżek i premii czekiem.
4. Oczywiście zaczęliśmy opracowywać nowe autotesty. Jednym z pierwszych zadań wydania była ocena wydajności predefiniowanych próbek systemu lojalnościowego. Nasz projekt ma blok sztywno ustalonych zapytań sql, które wybierają klientów zgodnie z warunkami. Na przykład uzyskaj listę wszystkich klientów, których ostatni zakup miał miejsce w określonym mieście, lub listę klientów, których średnia kwota zakupów przekracza określoną wartość. Po napisaniu autotestów sprawdziliśmy predefiniowane próbki, ustaliliśmy parametry wydajnościowe benchmarków, a dodatkowo otrzymaliśmy testy obciążeniowe.
5. Praca z autotestami powinna być wygodna. Dwie najczęstsze czynności to uruchamianie autotestów i generowanie danych testowych. W ten sposób w naszym systemie pojawiły się dwa moduły pomocnicze: moduł uruchamiania oraz moduł generowania danych.

   Program uruchamiający jest reprezentowany jako jedna ogólna procedura z jednym parametrem tekstu wejściowego. Jako parametr można przekazać mnemoniczny kod autotestu, nazwę pakietu, nazwę testu, ustawienie autotestu lub zarezerwowane słowo kluczowe. Procedura wybiera i uruchamia wszystkie autotesty spełniające warunki.

   Moduł generowania danych przedstawiony jest jako pakiet, w którym dla każdego obiektu testowanego systemu (tabela w bazie danych) została utworzona specjalna procedura, która wstawia tam dane. W tej procedurze wartości domyślne są wypełnione do maksimum, co zapewnia tworzenie obiektów dosłownie za jednym kliknięciem palca. A dla łatwości obsługi stworzono szablony dla generowanych danych. Na przykład utwórz klienta w określonym wieku z telefonem testowym i dokonanym zakupem.

6. Autotesty powinny działać i działać w rozsądnym czasie dla twojego systemu. W związku z tym zorganizowano codzienny nocny start, na podstawie którego generowany jest raport z wynikami, który wysyłany jest pocztą korporacyjną do całego zespołu deweloperskiego. Po przywróceniu starych autotestów i utworzeniu nowych, całkowity czas pracy wyniósł 30 minut. Taki występ odpowiadał wszystkim, gdyż premiera odbywała się poza godzinami pracy.

   Musieliśmy jednak popracować nad optymalizacją szybkości pracy. System lojalnościowy produkcji jest aktualizowany w nocy. W ramach jednej z premier musieliśmy pilnie wprowadzić zmiany w nocy. Półgodzinne oczekiwanie na wyniki autotestów o trzeciej nad ranem nie uszczęśliwiło osoby odpowiedzialnej za wydanie (gorące pozdrowienia dla Aleksieja Wasiukowa!), a następnego ranka padło wiele ciepłych słów pod adresem naszego systemu. Ale w rezultacie ustalono 5-minutowy standard pracy.

   Aby przyspieszyć działanie, zastosowaliśmy dwie metody: uruchomiliśmy autotesty w trzech równoległych wątkach, ponieważ jest to bardzo wygodne ze względu na architekturę naszego systemu lojalnościowego. I zrezygnowaliśmy z podejścia, gdy autotest nie tworzy dla siebie danych testowych, ale próbuje znaleźć coś odpowiedniego w systemie. Po wprowadzeniu zmian całkowity czas działania został skrócony do 3-4 minut.

7. Projekt z autotestami powinien dać się wdrożyć na różnych stanowiskach. Na początku drogi były próby napisania własnych plików wsadowych, ale stało się jasne, że samodzielnie napisana zautomatyzowana instalacja to kompletny horror i zwróciliśmy się w stronę rozwiązań przemysłowych. Ze względu na to, że projekt ma bezpośrednio dużo kodu (przede wszystkim przechowujemy kod autotestów) i bardzo mało danych (główne dane to metadane o autotestach), okazało się, że jest bardzo łatwy do zintegrowania z Projekt Liquibase.

   Jest to niezależna od bazy danych biblioteka typu open source do śledzenia, zarządzania i stosowania zmian w schemacie bazy danych. Zarządzane za pomocą wiersza poleceń lub frameworków, takich jak Apache Maven. Zasada działania Liquibase jest dość prosta. Mamy projekt zorganizowany w określony sposób, który składa się ze zmian lub skryptów, które należy wtoczyć na serwer docelowy oraz plików kontrolnych, które określają, w jakiej kolejności iz jakimi parametrami te zmiany powinny zostać zainstalowane.

   Na poziomie DBMS tworzona jest specjalna tabela, w której Liquibase przechowuje dziennik zmian. Każda zmiana ma obliczony skrót, który jest porównywany za każdym razem między projektem a stanem w bazie danych. Dzięki Liquibase możemy łatwo wprowadzać zmiany w naszym systemie do dowolnego obwodu. Autotesty są teraz uruchamiane w pętlach testowych i wydawniczych, a także w kontenerach (pętle osobiste programistów).

Porozmawiajmy więc o wynikach zastosowania naszego systemu testów jednostkowych.

1. Oczywiście przede wszystkim jesteśmy przekonani, że zaczęliśmy tworzyć lepsze oprogramowanie. Autotesty przeprowadzane są codziennie i znajdują dziesiątki błędów w każdym wydaniu. Co więcej, niektóre z tych błędów są tylko pośrednio związane z funkcjonalnością, którą naprawdę chcieliśmy zmienić. Istnieją poważne wątpliwości, czy błędy te zostały wykryte podczas testów ręcznych.
2. Zespół nabrał pewności, że poszczególne funkcjonalności działają poprawnie... Dotyczy to przede wszystkim naszych krytycznych procesów. Na przykład w ciągu ostatnich sześciu miesięcy nie mieliśmy problemów z dystrybucją rabatów i premii czekiem, pomimo zmian wprowadzanych co publikację, chociaż w poprzednich okresach błędy pojawiały się z pewną częstotliwością
3. Udało nam się zmniejszyć liczbę iteracji testowania. Ze względu na to, że autotesty są pisane pod kątem nowych funkcjonalności, analitycy i testerzy w niepełnym wymiarze godzin otrzymują kod o wyższej jakości, ponieważ zostało to już zweryfikowane.
4. Część rozwoju testów automatycznych jest wykorzystywana przez programistów. Na przykład dane testowe dotyczące kontenerów są tworzone za pomocą modułu generowania obiektów.
5. Ważne jest, że wypracowaliśmy sobie „akceptację” automatycznego systemu testowania przez programistów. Istnieje zrozumienie, że jest to ważne i pożyteczne. I z własnego doświadczenia mogę powiedzieć, że jest to dalekie od przypadku. Autotesty trzeba pisać, utrzymywać i rozwijać, analizować wyniki, a często te koszty czasowe po prostu nie są tego warte. Znacznie łatwiej jest przejść do produkcji i tam rozwiązywać problemy. W naszym kraju programiści ustawiają się w kolejce i proszą o pokrycie ich funkcjonalności autotestami.

Co dalej

Porozmawiajmy o planach rozwoju projektu testów automatycznych.

Oczywiście, dopóki system lojalnościowy Sportmaster żyje i rozwija się, autotesty również można rozwijać niemal w nieskończoność. Dlatego głównym kierunkiem rozwoju jest poszerzanie zasięgu.

Wraz ze wzrostem liczby autotestów łączny czas ich pracy będzie się systematycznie wydłużał i znów będziemy musieli wrócić do kwestii wydajności. Najprawdopodobniej rozwiązaniem będzie zwiększenie liczby wątków równoległych.

Ale to oczywiste drogi rozwoju. Jeśli mówimy o czymś bardziej nietrywialnym, podkreślamy następujące kwestie:

1. Teraz autotesty są zarządzane na poziomie DBMS, tj. do pomyślnej pracy wymagana jest znajomość języka PL/SQL. W razie potrzeby zarządzanie systemem (na przykład uruchamianie lub tworzenie metadanych) może zostać przejęte przez jakiś panel administracyjny za pomocą Jenkinsa lub czegoś podobnego.
2. Wszyscy uwielbiają wskaźniki ilościowe i jakościowe. Do testów automatycznych takim uniwersalnym wskaźnikiem jest Code Coverage lub metryka pokrycia kodu. Za pomocą tego wskaźnika możemy określić, jaki procent kodu testowanego przez nas systemu jest objęty autotestami. Począwszy od wersji 12.2 Oracle zapewnia możliwość obliczania tej metryki i sugeruje użycie standardowego pakietu DBMS_PLSQL_CODE_COVERAGE.

   Nasz system autotestów ma nieco ponad rok i być może nadszedł czas, aby ocenić zasięg. W moim ostatnim projekcie (nie projekt Sportmaster) tak się stało. Rok po pracy nad autotestami kierownictwo postawiło sobie za zadanie ocenić, jaki procent kodu pokryliśmy. Przy pokryciu większym niż 1% kierownictwo byłoby zadowolone. My, twórcy, spodziewaliśmy się wyniku na poziomie około 10%. Spieprzyliśmy zasięg kodu, zmierzyliśmy go i uzyskaliśmy 20%. Aby to uczcić, poszliśmy po nagrodę, ale jak to zrobiliśmy i gdzie poszliśmy później, to zupełnie inna historia.

3. Autotesty mogą testować odsłonięte usługi sieciowe. Oracle pozwala to zrobić i nie napotkamy już wielu problemów.
4. I oczywiście nasz zautomatyzowany system testowania można zastosować w innym projekcie. Rozwiązanie, które otrzymaliśmy jest uniwersalne i wymaga jedynie użycia Oracle. Słyszałem, że jest zainteresowanie automatycznymi testami w innych projektach Sportmaster i być może się do nich zgłosimy.

odkrycia

Podsumujmy. Na projekcie systemu lojalnościowego w Sportmaster udało nam się zaimplementować automatyczny system testujący. Jego podstawą jest rozwiązanie utPLSQL autorstwa Stephena Feuersteina. Wokół utPLSQL znajduje się kod do autotestów i pomocniczych, samodzielnie napisanych modułów: programu uruchamiającego, modułu generowania danych i innych. Autotesty odbywają się codziennie i co najważniejsze działają i przynoszą korzyści. Jesteśmy przekonani, że rozpoczęliśmy wydawanie oprogramowania o wyższej jakości. Jednocześnie powstałe rozwiązanie jest uniwersalne i może być dowolnie zastosowane do dowolnego projektu, w którym konieczne jest zorganizowanie automatycznych testów na Oracle DBMS.

PS Ten artykuł okazał się mało konkretny: jest dużo tekstu i praktycznie żadnych technicznych przykładów. Jeśli temat jest globalnie interesujący, to jesteśmy gotowi kontynuować go i wrócić z kontynuacją, w której opowiemy, co się zmieniło przez ostatnie sześć miesięcy i podamy przykłady kodu.

Napisz komentarze, jeśli są kwestie, które należy podkreślić w przyszłości, lub pytania, które wymagają ujawnienia.

W ankiecie mogą brać udział tylko zarejestrowani użytkownicy. Zaloguj się, Proszę.

Napiszemy o tym więcej?

• Tak, oczywiście

• Nie, dziękuję

Głosowało 12 użytkowników. 4 użytkowników wstrzymało się od głosu.

Źródło: www.habr.com