Testujemy aplikacje

Jak przygotować środowisko testowe, by sprawdzić aplikację, wykryć ewentualne problemy, a jednocześnie nie narażać środowiska produkcyjnego? Przedstawiamy niełatwe zagadnienia związane z testowaniem oprogramowania.

Każda aplikacja przed oddaniem do eksploatacji musi być poddana testom. Proces ten musi być jednak zorganizowany w taki sposób, by minimalnie (lub wcale) wpływał na środowiska produkcyjne i zapewnił sprawdzenie funkcjonalności aplikacji oraz wykrycie niemal wszystkich błędów.

Testujemy na kopii

Najlepsze efekty testów można osiągnąć w prawdziwych warunkach możliwie zbliżonych do produkcyjnych. Wykorzystanie tej samej infrastruktury, takiej jak serwery, sieć czy baza danych, wpływa na obciążenie systemów produkcyjnych, co nie zawsze jest akceptowalne, ze względu na degradowanie jakości usługi świadczonej przez produkcyjny system. Najdroższym wyjściem, niekiedy stosowanym przez duże korporacje przy skomplikowanych aplikacjach, ale preferowanym przy znacznie mniejszych i prostszych, jest duplikowanie systemu produkcyjnego. Jeśli aplikacja pracuje w całości w środowisku wirtualizowanym, wystarczy sklonować maszyny wirtualne i przenieść na inny klaster, dzięki czemu środowisko testowe nie będzie obciążało produkcyjnego. Replika systemu produkcyjnego wydaje się najbezpieczniejszym rozwiązaniem, ale w miarę rozwoju aplikacji będą pojawiały się jej nowe wersje - testy trzeba przeprowadzić przed wdrożeniem obecnie obowiązującej wersji, należy sprawdzić wiele aspektów, w tym zgodność poszczególnych składników. Przy bardzo złożonych aplikacjach, gdzie liczba podsystemów od różnych producentów może osiągać nawet kilkadziesiąt i więcej, wykonanie takiej kopii z pełną repliką systemu jest praktycznie niemożliwe ze względów praktycznych. Nawet gdyby udało się ją uzyskać, to szybko kopia stanie się nieaktualna. Zazwyczaj poprawki wprowadzane do systemu produkcyjnego nie są przenoszone do systemu testowego, a zatem po stosunkowo krótkim czasie zmiany postawiłyby wiarygodność testów pod znakiem zapytania.

Dodatkowym problemem, poza skomplikowaniem systemu produkcyjnego, są potrzebne dodatkowe licencje, niekiedy bardzo kosztowne - zarówno na hypervisor, jak i na wszystkie składniki aplikacji: bazę danych, middleware, front-end. Ponadto taką kopię nie zawsze można wykonać - jeśli aplikacja działa bezpośrednio na sprzęcie lub korzysta ze specjalnych urządzeń, takich jak choćby akcelerator kryptograficzny lub moduł HSM przeznaczony do przechowywania krytycznych danych bezpieczeństwa (np. PIN do kart płatniczych lub dane uwierzytelnienia), to wykonanie kopii jest trudne lub wręcz niemożliwe bez dużych inwestycji w sprzęt.

Do testowania takich aplikacji bez ryzyka uszkodzenia danych można stosować różnego rodzaju emulatory lub zaślepki. Wirtualizacja aplikacji umożliwia emulowanie bardzo wielu aplikacji, w tym także tych bardzo skomplikowanych.

Prawdziwa aplikacja, próbne konta

Skąd wziąć dane

Testowanie aplikacji ma sens tylko wtedy, gdy odbywa się na puli danych prawdziwych, produkcyjnych albo możliwie zbliżonych do tego zestawu informacji, który potem aplikacja będzie przetwarzać. Najlepsze efekty osiąga się podczas testów na prawdziwych danych, ale niekiedy baza zawiera informacje, które nie mogą wyjść poza system produkcyjny, np. o kartach płatniczych, spisy transakcji bankowych, dane osobowe. Niezbędna jest wtedy anonimizacja lub maskowanie danych albo wygenerowanie specjalnych danych testowych. W tym drugim przypadku nie mamy gwarancji, że zachowanie aplikacji będzie identyczne z danymi produkcyjnymi, dotyczy to przede wszystkim wydajności.

W dużych aplikacjach praktycznym wyjściem jest wprowadzanie kont testowych. Metoda umożliwia sprawdzenie funkcjonalności aplikacji, ale dział odpowiedzialny za jej tworzenie może nieświadomie wprowadzić niewłaściwe lub nieistniejące transakcje, które będą przez taką aplikację traktowane tak samo jak prawdziwe. Istnieją sposoby, by takie transakcje dało się wychwycić i usunąć, ale operacja wcale nie jest łatwa. Konta testowe nie zabezpieczają również systemu produkcyjnego przed dodatkowym obciążeniem, które niekiedy może być bardzo duże, co dotyczy zwłaszcza raportów.

Która to wersja?

W przypadku testowania najnowszej wersji aplikacji jeszcze przed wdrożeniem jej do systemu produkcyjnego mogą pojawić się błędy wynikające stąd, że wnioski z wybranego etapu testu zostaną przypisane do niewłaściwej wersji. W takim przypadku całą pracę wykonuje się co najmniej dwa razy, a zmiany w kodzie wywołane zgłoszeniem z testów mogą wpłynąć na poprawność i stabilność aplikacji w przyszłości. Nawet jeśli błąd ten nie spowoduje uszkodzenia spójności danych, testowanie będzie mało efektywne. Przy dużych projektach nadal zdarzają się takie błędy, wynikłe z pośpiechu lub niedopatrzenia.

Nowy system, stary składnik

Konflikt wersji poszczególnych składników może iść znacznie dalej, co obserwuje się niekiedy przy testach systemów właśnie wdrażanych do produkcji. Jeśli równocześnie rozwijane są nowsze wersje dwóch zależnych od siebie aplikacji, które normalnie wymieniają ze sobą komunikaty, a każda z tych aplikacji jest wytworzona przez innego dostawcę, może pojawić się problem. Polega on na tym, że w systemie produkcyjnym nie znajduje się żadna z nowych wersji przeznaczonych do eksploatacji, a zatem żadne nowe komunikaty nie są obsługiwane. Testy przeprowadzane z użyciem specjalizowanych narzędzi nie przynoszą wtedy zadowalających rezultatów. Dodatkowo mogą wystąpić ograniczenia dostępu do systemu produkcyjnego, gdy trzeba testowo uruchomić nowy komponent. Nawet jeśli taką operację przeprowadza się w dokładnie określonym oknie serwisowym podczas minimalnego obciążenia, system produkcyjny trzeba na czas testów na chwilę wyłączyć, a jest to wysoce niepożądane.

Stara kopia

Nawet jeśli tworzy się aplikacje w środowisku zwirtualizowanym, gdzie kopiowanie maszyn jest najprostsze, bywają problemy z aktualnością systemu zreplikowanego. Utworzenie nowej repliki bądź emulacji zawsze wymaga nakładu pracy, dlatego w wielu przypadkach to zadanie jest wykonywane rzadko. W efekcie niezgodności wersji może się okazać, że stworzona i przetestowana w takim emulowanym lub zreplikowanym środowisku aplikacja nie będzie działać poprawnie po przekazaniu do produkcji i uruchomieniu w docelowym środowisku. Jeśli to tylko możliwe, należy często wykonywać taką replikę, by testy przeprowadzać w tej wymaganej, tej samej wersji oprogramowania.

Waga problemu zgodności rośnie, gdy gotowa aplikacja składa się z kilku komponentów, tworzonych przez różnych dostawców bez dostępu do oryginalnego systemu lub bez dokładnego uzgodnienia detali integracji, co do każdego interfejsu i komunikatu włącznie. W takim przypadku rośnie liczba błędów, a kontrola spójności pracy napotyka na istotne trudności. Jedyną radą na takie problemy jest dokładne ustalenie sposobu komunikacji i integracji oraz ścisłe przestrzeganie standardu przez wszystkich dostawców. Po przekazaniu każdego modułu powinien być on dokładnie przetestowany, najlepiej w konfiguracji identycznej z tą, w której będzie pracować w środowisku produkcyjnym.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200