Testy automatyczne
Jednym z istotnych etapów realizacji projektów informatycznych jest odpowiednie przetestowanie wymaganych funkcjonalności. Zaniedbanie tego kroku może prowadzić do niezgodnego z wymaganiami działania systemu końcowego, a co za tym idzie – opóźnień projektu oraz dodatkowych kosztów. Testy funkcjonalne pozwalają na zapewnienie sukcesu wdrożenia, gdyż stanowią nieodzowny element przyczyniający się do dostarczenia efektywnego rozwiązania zgodnego z założeniami przyjętymi w koncepcji biznesowej. Automatyzacja procesu testowania pozwala na jego usprawnienie, zmniejszenie praco- oraz czasochłonności i ograniczenie zaangażowania człowieka.
Integralnym narzędziem systemu SAP, które może zostać wykorzystane do testów automatycznych jest eCATT (ang. Extended Computer Aided Test Tool). Poprzez tworzenie skryptów testowych weryfikowana jest poprawności badanych programów. Skrypty mogą być uruchamiane automatycznie bez okna dialogowego użytkownika i nie muszą być wykonywane przez testerów. Przypadki testowe są zwykle tworzone przez nagrywanie transakcji.
Korzyści wynikające z testów automatycznych przy wykorzystaniu eCATT to:
- ograniczenie czasu testowania,
- zmniejszenie nakładów finansowych, poprzez ograniczenie siły roboczej potrzebnej do przeprowadzenia testów,
- zapewnienie jakości wdrażanych i rozwijanych aplikacji SAP, dzięki ograniczeniu błędów,
- w przyszłości możliwość ponownego wykorzystania przygotowanych testów podczas rozwijania lub tworzenia nowych powiązanych funkcjonalności.
Następca CATT
eCATT to następca niewspieranego już narzędzia CATT. Jako, że jest integralną częścią SAP, nie wymaga nakładu finansowego związanego z zakupem dodatkowej funkcjonalności czy wykupienia dodatkowej licencji. Narzędzie to jest zintegrowane z ABAP Development Workbench i jest dostępne od wersji 6.20 serwera aplikacyjnego WAS. Zakres działania narzędzia został poszerzony o możliwość testowania aplikacji webowych. Ograniczeniem jednak jest możliwość jego wykorzystania tylko w zakresie technologii SAP.
eCATT pozwala na testy:
- transakcji, raportów, programów dialogowych,
- wywołań BAPIs oraz modułów funkcyjnych,
- autoryzacji – profili użytkowników,
- aktualizacji (bazy danych, aplikacje, GUI),
- efektów zmian w dostosowywaniu ustawień,
- komunikatów systemowych,
- usług sieciowych,
- aplikacji internetowych w technologii Webdynpro.
Dodatkowo jest możliwość migracji z CATT do jego bardziej zaawansowanego następcy.
W celu przeprowadzania testów automatycznych przy wykorzystaniu eCATT, należy przygotować odpowiednio system oraz obiekty będące integralną częścią narzędzia.
Michał Jasiński, Manager Biura Projektów, All for One Poland
Potrzeba przetestowania poprawności działania systemu pojawia się nie tylko we wdrożeniu SAP „od zera”. Wymagają tego także projekty upgrade, gdzie kompleksowo należy sprawdzić działanie systemu po podniesieniu wersji, czy też rollout, gdzie testom podlega już wcześniej wdrożone rozwiązanie referencyjne. Wykonanie testów w sposób tradycyjny, np. przez użytkowników, pozwala lepiej zapoznać się z rozwiązaniem, ale zajmuje czas. Dlatego w niektórych przypadkach warto rozważyć wykorzystanie narzędzi do testów automatycznych, takich jak SAP eCATT (ang. Extended Computer Aided Test Tool). Szczególnie atrakcyjne może być wykorzystanie eCATT w przypadku działań powtarzalnych, takich jak testy regresji w środowiskach międzynarodowych, czy kontrola jakości przy comiesięcznych wydaniach (ang. release) nowych funkcji i zmian.
Michał Jasiński, Manager Biura Projektów, All for One Poland
Przygotowanie systemu
eCATT został zaprojektowany jako narzędzie zarządzane centralnie, operujące na jednym serwerze. Serwer eCATT komunikuje się z pozostałymi serwerami za pomocą standardowego protokołu RFC. Konieczne jest zapewnienie łączności sieciowej pomiędzy serwerami i konfiguracja połączeń zdalnych z systemu eCATT do pozostałych. W celu uniknięcia konieczności manualnego logowania na zdalnych systemach, należy wykorzystać zestawienie zaufanego połączenia RFC. Następnie należy zdefiniować kontener danych systemowych. Przechowuje on dane o systemach biorących udział w procesie testowania. Łączy ich logiczne nazwy z definicjami fizycznymi połączeń RFC.
Dzięki odseparowaniu informacji o powiązaniach i połączeniach od skryptów testowych zapewniono elastyczność i możliwość zmiany parametrów bez potrzeby ingerencji w ich strukturę.
Uruchomienie możliwości korzystania z tego narzędzia wymaga pracy ze strony administratorów systemu. W tabeli T100 należy zezwolić na korzystanie z narzędzia eCATT, a poprzez ustawienie parametrów zezwolić na korzystanie ze skryptów.
Narzędzie eCATT można uruchomić na platformie SAP Solution Manager. Dodatkowo platforma ta udostępnia bardziej nowoczesne i rekomendowane przez SAP narzędzie przeznaczone do automatycznych testów, jakim jest CBTA (ang. Component Based Test Automation). CBTA wspiera technologie SAP UI, między innymi takie jak: SAPGUI, WD-ABAP, CRM Web-Client, SAPUI5, Fiori oraz w przeciwieństwie do eCATT pozwala na testowanie aplikacji non-SAP. Został również przygotowany do wspierania implementacji dla S/4HANA. CBTA jest częścią Test Suit, który to zapewnia kompleksową kontrolę oraz optymalizację procesu testowania. Dzięki przechowywaniu dokumentacji na jednym serwerze oraz Business Process Change Analyzer, który analizuje wpływ zmian na proces biznesowy, tworzenie przypadków testowych oraz testy regresywne stają się jeszcze prostsze.
Obiekty eCATT
Tworzenie obiektów odbywa się z poziomu transakcji SECAAT. Rodzaje dostępnych obiektów to:
- kontener danych systemowych – zawiera definicję połączeń systemów biorących udział w testach. Bez kontenera danych systemowych nie można pisać skryptów testowych, które mają dostęp do innych systemów. Utrzymywane są niezależnie od skryptu testowego;
- kontener danych testowych – zawiera parametry, które definiują interfejs kontenera oraz warianty, które przechowują dane. Parametrami mogą być proste typy ABAP, struktury lub tabele. Kontener danych utrzymywany jest niezależnie od skryptu testowego, dzięki czemu możliwe jest jego użycie w kilku skryptach oraz eliminacja redundancji danych. Może być przygotowany również jako zewnętrzny plik, co znacznie ułatwia pracę z dużą ilością danych;
- skrypt testowy – w jego skład wchodzą atrybuty, parametry i komendy. Atrybuty to między innymi: nazwa, przypisanie do pakietu, osoba odpowiedzialna, komponent aplikacji oraz informacje o systemie i wersji. Skrypt testowy może istnieć w kilku wersjach. Należy do niego przypisać kontener danych systemowych. Parametry importu i eksportu definiują interfejs skryptu testowego, dzięki czemu można przekazywać wartości do skryptu. Istnieje możliwość tworzenia zmiennych lokalnych, które są używane tylko w danym skrypcie. Polecenia opisują test. Zazwyczaj skrypt zawiera jedną lub więcej zarejestrowanych transakcji z powiązanymi kontrolami i obliczeniami. Może zawierać tylko niektóre użyteczne funkcje, do których można odwoływać się z innego skryptu, lub może zawierać serię odniesień do innych skryptów w celu zbudowania bardziej złożonego testu z jednostek wielokrotnego użytku. Skrypty eCATT mogą być zawarte w katalogu testowym, który ma być wykonywany sekwencyjnie jednym kliknięciem lub być zaplanowany do wykonania według godzin, codziennie, co miesiąc lub co tydzień, w zależności od czasu wprowadzonego przez użytkownika;
- konfiguracja testu – powstaje z połączenia wyżej wymienionych obiektów eCATT. Można ją przypisać do katalogów oraz planów testowych, które umożliwiają łączenie skryptów na potrzeby wykonania ich w określonym ciągu. Konfigurację można następnie przypisać do poszczególnych użytkowników;
- profil startowy – zawiera opcje uruchamiania eCATT;
- obiekt walidacji – posiada jedynie parametry importu, które są parametrami wejściowymi skryptu zawierającego implementację. Pozwala na oddzielenie kodu do walidacji testu od logiki sprawdzanego.
Wszystkie obiekty eCATT są obiektami repozytorium, co oznacza, że można korzystać ze standardowych narzędzi transportowych SAP. Dodatkowo obiekty mogą być pobierane z systemu i do systemu jako pliki XML. Odseparowanie skryptów testowych od danych oraz definicji systemowych znacznie zwiększają możliwość ponownego wykorzystania tych elementów w przyszłości.
Ekran początkowy eCATT
Przygotowanie i przebieg testów
Po wykonaniu pracy administracyjnej i przygotowaniu systemu, można przejść do opracowania właściwych testów. Przystępując do ich definiowania, należy wcześniej prześledzić poszczególne kroki procesu i określić pożądane rezultaty. Dzięki tym informacjom możliwe będzie ustalenie przypadków testowych.
Pierwszym krokiem jest nagranie skryptu. Poprzez możliwość zarejestrowania przebiegu czynności użytkownika, tworzony jest skrypt odzwierciedlający rzeczywiste użycie. Dzięki ręcznym poprawkom kodu, możliwości wstawiania punktów kontrolnych czy poleceń zapisu do logu, skrypt może zostać odpowiednio dostosowany. Dobór początkowych wartości jest istotny, gdyż należy zadbać o zagwarantowanie bezbłędnego przejścia. Ze względu na wartości domyślne, których źródłem może być konfiguracja, domyślne warianty ekranu, ale również i wartości zachowane w profilu użytkownika, najlepiej przygotować na wszystkich systemach konto użytkownika przeznaczonego tylko do wykonywania testów automatycznych. Ustawienie tych samych wartości w profilu oraz zapewnienie spójności konfiguracji, pozwoli uniknąć błędów wynikających z rozbieżności wynikających z wartości domyślnych. W kolejnym kroku należy sparametryzować interfejs skryptu poprzez zmianę statycznych danych na parametry wejściowe i wyjściowe. Następnie poprzez użycie tych samych nazw w kontenerze danych, należy przygotować warianty, które będą zawierały wartości dla parametrów odzwierciedlających przypadek testowy. Mogą być one wprowadzone ręcznie lub zaimportowane z pliku zewnętrznego. Chociaż skrypt testowy może zostać wykonany bezpośrednio, zazwyczaj testowanie odbywa się poprzez konfigurację testu. Łączy ona skrypt z kontenerem danych i pozwala na uruchomienie testu w docelowej konfiguracji.
Podczas korzystania z eCATT ważna jest szczegółowa informacja na temat każdego wykonanego testu. Jeśli test przebiegł pomyślnie, oznacza to, że proces biznesowy został odwzorowany poprawnie. W przypadku testów zakończonych błędami, na podstawie analizy logu, w łatwy sposób możemy znaleźć przyczynę problemu. Weryfikacja komunikatów, wartości zmiennych i zapisów do baz danych pomoże w przygotowaniu koniecznej do wdrożenia poprawki.
Wynik przebiegu skryptu testowego
Korzyści z eCATT
Wdrożenie eCATT w środowisku SAP wiąże się z wieloma korzyściami. Raz zaimplementowane narzędzie może być ponownie wykorzystywane. Jeśli okaże się, że testowana funkcjonalność podlega sukcesywnemu rozwojowi, to przy niewielkim nakładzie pracy związanym z utrzymaniem automatycznych testów, może zostać ponownie wykorzystany, zapewniając ciągłe i poprawne działanie kluczowych procesów. Ponowne użycie testów może okazać się również przydatne, np. podczas podniesienia wersji, czy posłużyć w przypadku testów regresyjnych.
Dodatkowymi korzyściami wypływającymi z testów automatycznych jest skrócenie czasu procesu testowania (co za tym idzie zmniejszenie ryzyka projektowego, poprzez przyspieszenie gotowości rozwiązania do kolejnych czynności wdrożeniowych), poprawa jego jakości oraz łatwość w ponownym jego przeprowadzeniu. Nie bez znaczenia jest również uwolnienie zasobów wewnętrznych, zaangażowanych w żmudne czynności testowania, na rzecz innych, istotniejszych i bardziej rozwojowych zadań projektowych.