Kiedy utrzymujesz swoje Oracle BRM (Billing and Revenue Management), zaczynasz zdawać sobie sprawę, że liczba skonfigurowanych podmiotów stale rośnie. Jest bardzo prawdopodobne, że do tego czasu opracowałeś również pewne dostosowania i zintegrowałeś się z dodatkowymi rozwiązaniami. Ewolucja środowiska prowadzi do powstania złożonego klastra powiązanych ze sobą obiektów. Nadchodzi moment, w którym Ty lub Twój klient decydujecie się coś zmienić. Nowa funkcja może początkowo wydawać się łatwa do opracowania. Prawda jest jednak taka, że najprawdopodobniej będzie ona kolidować z istniejącą funkcją lub będzie wymagać aktualizacji istniejącej konfiguracji. To, co wydawało się prostą zmianą, wpływa na cały system. Czasami trudno jest uniknąć takich zdarzeń, ale przygotowanie się na nie może zaoszczędzić wielu kłopotów. Funkcjonalne scenariusze testowe i wszechstronność testowania mogą zmienić zasady gry.
Spis treści
Ciągły przepływ rozwoju
W Tridens ustanowiliśmy ciągły przepływ rozwoju. Wszystkie nasze konfiguracje BRM, dostosowania i inne zintegrowane komponenty są odpowiednio wersjonowane i śledzone w rozproszonym systemie kontroli wersji (Git). Ta praktyka pozwala naszym programistom sprawdzić wymagane wersje komponentów w dowolnym momencie i rozpocząć pracę. Do tego momentu wszystko jest w porządku, ale jak radzimy sobie z możliwością, że nowe funkcje zepsują bieżącą kompilację?
Mamy skonfigurowany przepływ wdrażania i testowania, który śledzi zdalne repozytoria naszych źródeł. W rezultacie za każdym razem, gdy programista zatwierdza i przesyła zmiany do kontroli wersji, inicjuje to proces testowania. Przepływ wdrażania buduje obrazy docker dla wszystkich odpowiednich komponentów z ich najnowszymi wersjami w środowisku lokalnym (lub zdalnym), a automatyczne testy są wykonywane w celu zapewnienia, że kompilacja jest stabilna. Dopiero gdy testy zakończą się pomyślnie, możemy wydać nowe wersje do produkcji. Ten proces pomaga nam upewnić się, że nowe funkcje działają płynnie z istniejącymi. Wykonywane testy są częścią opracowanego przez nas zestawu narzędzi Oracle BRM TestToolkit. BRM TestToolkit ma predefiniowane kroki i scenariusze z kodem kleju w tle. Kroki są bardzo opisowe i przyjazne dla użytkownika, umożliwiając naszym programistom lub innym użytkownikom szybkie pisanie nowych scenariuszy testowych. Przykład scenariuszy testowych znajduje się na poniższym obrazku.
BRM TestToolkit do testów automatycznych
To, co zaczęło się jako proste scenariusze testowe dla tworzenia kont i zakupów produktów, stanowi dziś główny szkielet naszego testowania BRM TestToolkit. Aby to wyjaśnić, mamy teraz kilka różnych przypadków testowych i scenariuszy pobocznych, aby zapewnić maksymalne pokrycie wdrożonych funkcji. Zautomatyzowane testy pozwalają naszym programistom skupić się na wykonywanym zadaniu i nie poświęcać ogromnej ilości czasu na ręczne testowanie. Oczywiście czasami zdarza się, że opracowujemy nową funkcję, która nie jest jeszcze objęta scenariuszami testowymi. W takich przypadkach definicje kroków testowych i ich kod tła są implementowane jako część tej funkcji - do wykorzystania również w przyszłości.
TestToolkit może komunikować się z różnymi komponentami, umożliwiając szybkie dostosowanie również do innych systemów. Używamy również przeprojektowanych wersji naszego BRM TestToolkit dla innych naszych komponentów. Jedną z najnowszych funkcji, które dodaliśmy, była modułowość, w której programiści mogą oznaczać różne scenariusze testowe jako części grupy. Każda grupa ma następnie swoje skrypty i oddzielną logikę, co pozwala, w razie potrzeby, na równoległe wykonywanie tylko określonej liczby testów. Co więcej, modułowość pozwala nam oddzielić testy oceny prepaid od testów oceny postpaid lub testy zakupu dodatków od różnych zakupów. Przepływ testów można zobaczyć na poniższym obrazku.
Pokrycie scenariusza testowego
BRM TestToolkit komunikuje się z naszym API, które zintegrowaliśmy z Oracle BRM w celu uproszczenia bardziej złożonych operacji. TestToolkit może również wchodzić w interakcje z interfejsem BRM RestBridgenasze rozwiązanie BRM wrapper, które ułatwia komunikację z BRM, umożliwiając korzystanie z formatu JSON lub XML za pośrednictwem interfejsu API REST. Definicje kroków testowych obsługują między innymi następujące operacje:
- Tworzenie konta i zarządzanie nim
- Zakup transakcji i inne operacje związane z transakcjami
- Odzyskiwanie i sprawdzanie salda
- Generowanie ruchu - zdarzenia użytkowania
- Wywołania API
- CDR drop-off
- narzędzia ruchu w czasie rzeczywistym (protokół Diameter)
- Ocena kontrolna
- BRM TestToolkit porównuje różne zdarzenia użytkowania i zakupy z oczekiwanymi wartościami
- Każdy inny plan lub produkt może mieć swój własny zestaw plików ratingowych, zapewniając wszechstronność w złożonych konfiguracjach produktów.
Tworząc przyjazne dla użytkownika kroki testowe, każdy programista może napisać scenariusze dla opracowywanej funkcji. W wielu przypadkach nasi programiści decydują się na wcześniejsze skonfigurowanie scenariuszy testowych - przed opracowaniem funkcji. Przygotowywanie scenariuszy z wyprzedzeniem jest zgodne ze wzorcem Behaviour Driven Development (BDD). BDD zasadniczo oznacza, że scenariusze dyktują przepływ rozwoju i powinny istnieć z wyprzedzeniem. Scenariusze te opisują, jak powinien zachowywać się system, a programiści muszą opracowywać nowe funkcje w taki sposób, aby pasowały do tych scenariuszy. Każdy scenariusz testowy może być wykonywany oddzielnie, co skutkuje raportem w określonym formacie. Poniżej znajduje się przykład raportu HTML.
Raportowanie
Gdy system uruchamia scenariusze testowe jako część nowej kompilacji rozwojowej, zwykle wykonuje je w pełnym zakresie - w tym wszystkie testy. W zależności od środowiska może to zająć trochę czasu, ale zapewnia szeroki obraz tego, jak nowa funkcja mogła wpłynąć na inne istniejące implementacje. Możemy ocenić stabilność kompilacji na podstawie raportu z testów, który BRM TestToolkit generuje po zakończeniu testu. Raporty z testów zawierają szczegółowe informacje dla każdego scenariusza testowego, ale także dostarczają pewnych statystyk i analiz dotyczących wszystkich testów w ogóle. Możemy użyć tej analizy, aby znaleźć różnice między kompilacjami i upewnić się, że kompilacja działa poprawnie. Poniżej znajduje się przykład raportu.
Wnioski
Posiadanie odpowiedniego rozwiązania testowego może zaoszczędzić ogromne ilości czasu i zapobiec wystąpieniu niepotrzebnych błędów. Dlatego też, jeśli zmagasz się z jakimikolwiek trudnościami wymienionymi w tym artykule lub jeśli jesteś zainteresowany naszym zestawem narzędzi do testowania BRM, skontaktuj się z nami. Chętnie opowiemy więcej o naszym rozwiązaniu i opracujemy optymalny plan usprawnienia procesu wdrażania i testowania.
