Chmura usprawni testowanie
- Bogdan Bereza,
- 06.11.2012
Wirtualizacja sprawia, że do testów aplikacji nie trzeba budować złożonych środowisk testowych. Zwirtualizować można działanie aplikacji, a badać tylko jej fragmenty.
Wirtualne środowiska testowe pojawiły się jako osobne produkty niedawno, trzy lata temu. Na razie w niewielkiej skali, zainicjowane przez firmy średniej wielkości, Parasoft (oferuje narzędzie "Parasoft Virtualize") i ITKO (oferuje narzędzie "LISA").
Dziesiątki razy pytałem testerów, zespoły i działy testowania, z czym mają największe kłopoty. Co zajmuje im najwięcej czasu? Odpowiedzi są nużąco niezmienne: to środowiska testowe. Problemy z nimi naprawdę potrafią sparaliżować każdy projekt.
Zobacz również:
- 5 priorytetów, które obniżają koszty chmury i usprawniają operacje IT
- Tradycja i nowoczesność - połączenie klasycznych notatek ze światem cyfrowym
Kłopoty ze środowiskami testowymi
Oto typowe kłopoty ze środowiskami testowymi, które pochłaniają niekiedy nawet 50% czasu i budżetu projektów informatycznych.
Koszt środowiska
Środowisko testowe kosztuje. Płacimy za sprzęt, oprogramowanie, administrowanie, kopie zapasowe, a przede wszystkim za konieczność modyfikacji i dostosowywania do nowych potrzeb. Kiedy w skład środowiska wchodzą komputery typu mainframe i terabajtowe bazy danych - co jest typowe dla wszelkich systemów ERP, dla banków, dla firm ubezpieczeniowych - koszty mogą przebić "barierę dźwięku".
Odpowiedzialność za środowisko
Przykłady kłopotów:
- Testy automatyczne zaplanowane na weekend zostają przerwane już w sobotę, bo administrator systemu wykorzystuje weekend na… serwis serwera. Dział testów domaga się więc własnego serwera.
- Zespół testowy ma mnóstwo trudności z uzyskaniem odpowiednich konfiguracji, uprawnień, haseł. Wiecznie stoją, jako petenci, w kolejce do adminów!
- Różni użytkownicy, różne zespoły testowe niechcący psują sobie nawzajem środowisko testowe i jego konfigurację. Zajmuje to mnóstwo czasu i powoduje wiele złej krwi.
A przecież czas goni.
Dublowanie środowisk
Różnych środowisk, od środowiska programisty aż po docelowe (produkcyjne), może być nawet kilkanaście. Widuje się osobne środowiska do testów funkcjonalnych, do testów systemu A i do testów systemu B, do testów wydajności, do testów z danymi produkcyjnymi, do testów systemowych, środowisko przedprodukcyjne, kopię środowiska produkcyjnego, specjalne środowisko testów szybkiej ścieżki… Wszystko to generuje ogromne koszty.
Dostęp do środowiska
Przykłady:
- Zdalny dostęp powoduje kłopoty z nadzorowaniem, kto w danej chwili co robi, jakie zasoby wykorzystuje. Rozwiązaniem jest specjalna aplikacja, umożliwiająca rezerwację dostępu i sterowanie nim, czasochłonna w utrzymaniu, kłopotliwa w użyciu.
- Po zgłoszeniu pierwszych błędów coraz częstszymi gośćmi w laboratorium testowym stają się programiści - łowcy bugów. Odtworzyć przyczyny awarii mogą tylko w środowisku testowym. Ustalenie zasad współżycia społecznego zajmuje wtedy dużo czasu.
Symulacja
Stworzenie symulatora (emulatora) to zwykle osobny duży projekt, a jego nieustanne zmiany pochłaniają mnóstwo pracy. Co gorsza, każdorazowy negatywny wynik testu oznacza żmudną konieczność sprawdzenia, co działa niepoprawnie - testowana aplikacja czy symulator? Czasem w projekcie budowa symulatorów pochłania więcej wysiłku niż testowanie oprogramowania. Kiedy podsystem A buduje się i testuje w jednym miejscu, a podsystemy B i C w innych, to zespół piszący A posługuje się własnymi symulatorami B’ i C’, zespół B - symulatorami A’ i C" i tak dalej. Jest to kłopotliwe, kosztowne i powoduje mnóstwo błędów.
Projekty rozproszone, usługi internetowe, SOA i chmura
Każdy z terminów użytych w tytule tego akapitu oznacza, że opisane kłopoty wzmagają się jeszcze wielokrotnie.
Ratunek w wirtualizacji
Pomysł, aby brakujący czy kosztowny fragment środowiska testowego zastąpić jego wirtualną namiastką, nie jest niczym nowym. Ma tyle lat, ile informatyka i budowanie systemów. Tyle tylko, że w tradycyjnej formie jest to metoda kłopotliwa i kosztowna. Wirtualizację można jednak realizować o wiele prościej. I to jest właśnie nowość, która dziś jeszcze nie jest w pełni zrozumiana i doceniana, a za kilka lat trudno będzie sobie wyobrazić, jak kiedyś radziliśmy sobie bez niej.
Nie trzeba przecież naśladować działania całej aplikacji, tylko te jej fragmenty, które są potrzebne do wykonania niezbędnych testów. Nie trzeba symulować działania aplikacji, lecz wyłącznie jej interfejs, jej widoczne zachowanie się. To jest o wiele prostsze: symulator wie, jaki meldunek wysłać w odpowiedzi, ale nie powiela żadnych obliczeń, nie wykonuje przetwarzania wewnętrznego. Stąd nazwa: wirtualizacja zachowania się aplikacji (application-behaviour virtualization). Taka wirtualizacja jest prostsza, wydajniejsza, łatwiejsza do wdrożenia i modyfikowania niż symulacja pełna, tradycyjna.
Co więcej, aby stworzyć wirtualizację, niekoniecznie trzeba samemu w pocie czoła pisać program. Można bowiem posłużyć się dobrze znaną metodą: zarejestruj-odtwórz. Korzystając z krótkotrwałego dostępu do prawdziwej aplikacji, można przy pomocy wirtualizatora zarejestrować, jak komunikuje się ona z systemem, który testujemy, a później odtwarzać tę komunikację wielokrotnie, w potrzebnym do testowania miejscu i zakresie.
Dzięki wirtualnym środowiskom testowym można podczas integracji oraz testowania systemów znacznie złagodzić problemy wynikające z:
- brakujących lub niestabilnych komponentów;
- środowisk będących dopiero w trakcie budowy, niedostępnych lub kosztownych oraz systemów należących do firm trzecich;
- systemów zbyt kosztownych, skomplikowanych albo poufnych, by móc wykorzystać je w testach (mainframe, finansowe, ERP);
- zasobów - wewnętrznych i zewnętrznych - mających wielu użytkowników i właścicieli, co komplikuje dostęp i konfigurację;
- stosowania metodyk agile - wiele niezależnych zespołów pracujących w trybie agile i potrzebujących dostępu do własnego środowiska testowego;
- wielkiej liczby różnorodnych systemów, z którymi budowany system musi być zintegrowany.
- potrzeby dostępu do środowiska testowego z różnych lokalizacji rozproszonego projektu, w którego ramach budowany jest rozproszony system: wirtualne środowisko testowe można udostępnić w trybie chmury, prywatnej lub publicznej.
Jak działa wirtualizator
Nie wirtualizuje się całej funkcjonalności danego komponentu czy systemu - bazy danych, pakietu obliczeniowego, usługi internetowej (web service) podającej kursy walut czy aplikacji ERP - a tylko te ich działania (zachowania), które są potrzebne dla danych testów, przypadków użycia lub scenariuszy biznesowych.
Dane testowe to taki właśnie, na pozór drobny, ale przytłaczający w praktyce problem. Teoretycznie - prosty do rozwiązania, w projektach - ogromnie czasochłonny. Zbudowanie i utrzymanie bazy danych, wypełnienie jej danymi - to wielkie przedsięwzięcie. Aby go uniknąć, wystarczy zbudować, np. dla bazy danych SQL, tzw. wirtualną maszynę SQL - aplikację, która na określone zapytania SQL wysyła zdefiniowane odpowiedzi. Działanie takiego wirtualnego zasobu można sparametryzować tak, aby służył różnym testom, na różnych poziomach testowania, dla różnych zespołów, a nawet - jeśli udostępnimy go w chmurze - w różnych częściach świata!
Budowanie wirtualnego środowiska testowego składa się z trzech etapów:
Nagrywanie
Celem tej fazy jest rejestracja działania na poziomie protokołu i interfejsu komunikacyjnego, potrzebnego do integracji i testów aplikacji tak, aby móc je następnie, w fazie trzeciej, dostarczyć innym.
- Jeśli ma się dostęp do systemu, którego działanie chce się wirtualizować, narzędzie do wirtualizacji, skonfigurowane jako serwer pośredniczący (proxy), rejestruje strumienie wiadomości płynących do i z aplikacji i zapisuje je w celu późniejszego odtworzenia.
- Wirtualizator może też pozyskiwać zgromadzoną w logach transakcji informację o sekwencjach komunikatów (diagramy sekwencji) i na jej podstawie tworzyć scenariusze swojego działania.
- Jeśli system, którego zachowanie chce się wirtualizować, jeszcze nie istnieje, można to zachowanie i tak zdefiniować w wirtualizatorze, wykorzystując do tego specyfikację jego interfejsu.
Konfiguracja
Stworzony w fazie pierwszej wirtualny zasób można następnie udoskonalać i dostosowywać (kalibrować) do różnych zastosowań. Szczególnie przydatne może być konfigurowanie i symulowanie różnych awarii - niepoprawnych działań systemu, trudnych do zrealizowania na prawdziwym systemie, a niezbędnych do osiągnięcia pełnego pokrycia testowego wymagań.
Dostarczanie
Dostawa funkcjonalności wirtualnego zasobu (wirtualnego środowiska testowego) może być zarówno lokalna, jak i globalna. W globalnych, rozproszonych projektach jeden symulator - wirtualny zasób - można wykorzystywać zarówno do testów jednostkowych, systemowych -funkcjonalnych - jak i do testów wydajności
Wirtualne środowisko testowe może służyć zarówno do testów wykonywanych ręcznie, jak i automatycznych.
Nadchodzi zmiana
Jak każde duże usprawnienie wdrożenie wirtualnych środowisk testowych nie spotka się od początku z jednoznacznie entuzjastycznym przyjęciem. Jest armia ludzi przywykłych do obecnego stanu rzeczy, ba - czerpiących uzasadnioną, zawodową dumę z radzenia sobie wśród chaosu, trwogi i drżenia, potu, krwi i łez. Trzeba pamiętać jednak o tym, że rozwiązania wirtualne będą coraz powszechniejsze.
Wirtualne środowiska testowe znajdują się obecnie w takiej samej fazie rozwoju jak chmura obliczeniowa dziesięć lat temu. Dlatego warto wskoczyć do tego pociągu już dzisiaj, zanim na peronie zrobi się tłoczno.
Bogdan Bereza jest dyrektorem zarządzającym w firmie Victo.