Redakcja
Jak więc powinny wyglądać testy regresyjne? Powinny być jak najbardziej powtarzalne - nie mogą psuć środowiska/aplikacji. Powinno się dać je uruchomić na każdej instancji programu. Najprawdopodobniej będą się toczyły zgodnie ze scenariuszem:
- stwórz projekt
- konfiguruj projekt
- wykonaj operacje na projekcie
- usuń projekt.
Gdzieś pomiędzy wierszami zostanie umieszczona cała masa asercji, które będą odpowiadać za poprawność techniczną i biznesową programu. Kolejną ważną cechą jest prostota - jedną z często powtarzanych zasad jest: "testy powinny być krótkie i proste". Testy regresyjne nie muszą się jednak ściśle trzymać tej zasady. Regresja służy do potwierdzenia, że wszystko jest w porządku. Jeśli program nie przejdzie regresji, i tak zostaną użyte testy jednostkowe lub do akcji wkroczą developerzy.
Większość aplikacji jest podzielona na warstwy. Interface użytkownika, warstwa danych, warstwa biznesowa. Regresja dotyczy każdej z nich. Ale nie tylko - regresja powinna także sprawdzić komunikację pomiędzy warstwami. Ideałem byłoby rozpocząć od ludzkiej myśli i zakończyć na fizycznych akcjach, jednak ludzkie myśli ciężko się automatyzuje - zatrzymajmy się więc na warstwie interface'u użytkownika.
Do testów regresyjnych można podejść na wiele sposobów. Można przystosować testy jednostkowe, stworzyć bazę kopii aplikacji w różnych stanach i zdefiniować przejścia pomiędzy stanami. Jednak to podejście grozi olbrzymią bazą z masą redundantnej dokumentacji i olbrzymimi kosztami zarządzania. Można także zdefiniować scenariusze i użyć zasobów ludzkich do wykonywania testów na bazie scenariuszy. Takie podejście jest doskonałe, dopóki wykonywanie kolejnych iteracji testów regresyjnych mieści się w budżecie projektu. Jednak w sytuacji, gdy budżet projektu jest ograniczony, a użytkownicy końcowi odmawiają wykonania sto czterdziestej czwartej weryfikacji zmian, to znaczy, że czas na symulowanie użytkowników. Spróbuj zautomatyzować pracę, którą wykonaliby testerzy. Jak?
Akurat to jest proste. Spójrzmy na czynności testera: Znajduje obrazek - ikonkę, napis, guzik lub inny ustalony wzorzec. A następnie wykonuje na nim akcję - klika myszką, wpisuje jakiś tekst za pomocą klawiatury. Następnie sprawdza, czy aplikacja zachowała się zgodnie ze specyfikacją (czyli znów szukamy obrazka/napisu czy stanu danych). A potem czynność powtarzamy: wyszukanie wzorca, akcja, weryfikacja. Proste? To czemu nie zostało to dotychczas zaimplementowane? Zapewne dlatego, że wcześniej nie znano LordUI.
LordUI (www.lordui.com) to program to emulowania użytkowników końcowych (i nie tylko). Potrafi sprawdzić stan wyświetlanego obrazu na monitorze, wyszukać wzorce (okna, obrazki), przeczytać napisy przy pomocy OCR-u. Następnie wykonuje akcję - kliknięcie, wpisanie tekstu. Na koniec zaś wykonane jest sprawdzenie stanu aplikacji - można użyć ponownie rozpoznawania obrazu lub np. zintegrować aplikację z LordUI i sprawdzić spójność danych w dowolnym momencie testu.
LordUI powstało w języku Java i zawiera kompilator Java. Czyni to go tak wszechstronnym, jak język programowania Java. Z LordUI uzyskasz w pełni zautomatyzowane narzędzie, które będzie testowało Twoją aplikację każdego dnia. W przypadku znalezienia błędu, LordUI zawoła Cię dźwiękiem lub wyśle maila. Projekty LordUI nie mają czynników losowych - wiesz, jakie akcje zostaną wykonane. Test piszesz raz, a później uruchamiasz dowolną ilość razy.
Podsumowując, należy dbać o jakość projektu. Należy mieć pewność, że po każdej zmianie program spełnia założenia, które spełniał jeszcze przed zmianą. Użytkownicy to doceniają, a LordUI jest do tego idealnym narzędziem. Przetestuje każdą warstwę programu.
Autorem tekstu jest Krzysztof Mroczek, twórca aplikacji LordUI.
