Redakcja
MTM daje możliwość stworzenia dokładnego planu testów włączając w to ‘Traceability’ - mamy możliwość śledzenia zmian, które zaszły w nowej wersji i przypisania odpowiednich scenariuszy do konkretnego buildu. Dzięki temu możemy wykonać tylko te testy, na które wprowadzona zmiana miała wpływ, mamy również zapewnione powiązanie pomiędzy wynikami poszczególnych testów a wersjami tworzonego oprogramowania. Dodatkowo istnieje możliwość tworzenia scenariuszy testowych (ciekawą funkcją jest opcja stworzenia testów parametryzowanych - nie musimy wtedy tworzyć kilku scenariuszy sprawdzających te samą funkcjonalność, ale z różnym zestawem danych - mamy możliwość podania odpowiedniego zestawu danych jako parametrów scenariusza. Podobnie jak inne narzędzia, również tutaj mamy moduł odpowiedzialny za wykonywania scenariuszy (Microsoft Manual Test Runner). Po uruchomieniu MTR otwiera się okno, które wyświetla kolejne kroki scenariusza oraz rezultaty, jakie oczekujemy czy też inne informacje, które są związane z aktualnie wykonywaną czynnością.
Dodatkową możliwością, jaka została wprowadzona jest nagrywanie akcji, które są wykonywane i które później mogą zostać załączone jako wyniki testu lub zgłoszenia błędu.
Zgłoszenie nowego błędu jest bardzo intuicyjne. Wystarczy wybrać z listy ‘Create bug’ i na podstawie aktualnego kroku, danych o środowisku, wykonującym test oraz planie testowym zostanie stworzone nowe zgłoszenie zawierające informacje, które można automatycznie wygenerować. Dane takie jak tytuł i wszelkie dodatkowe informacje leżą w gestii użytkownika.
Dodatkową korzyścią z nagrywana wykonywanych akcji jest możliwość automatycznego odtworzenia wybranych kroków scenariusza (Fast Forward Manual Testing) po jego wykonaniu. Jest to tylko odtworzenie akcji, które zostały wykonane wcześniej, wyniki nie są w żaden sposób weryfikowane, a ich ocena należy do testera, który wykonuje dany scenariusz. Oczywiście MTM daje również możliwość zarządzania scenariuszami testowymi (np. tworzenie grup, przypisywanie osób odpowiedzialnych za dany scenariusz). Z poziomu MTM mamy również możliwość zarządzania środowiskami testowymi.
Tak pokrótce można scharakteryzować nowy produkt Microsoftu. Z pewnością nie jest to jeszcze narzędzie idealne, ale widać, że posiada duże możliwość i może być dużym ułatwieniem w procesie testowana dla wszystkich zespołów pracujących w oparciu o technologie oferowane przez Microsoft. Chciałbym bardziej skupić się na tym, co Microsoft dostarcza w ramach automatyzacji testów, ponieważ jest to bardziej interesujący dla mnie temat.
Do automatyzacji można wykorzystać wspomnianą wcześniej technikę ‘Fast Forward Manual Testing’, jednak jest to tylko odtwarzanie kolejnych kroków bez weryfikacji poprawności ich wykonania, co i tak wymaga ręcznego potwierdzania wyników. Aby zautomatyzować proces testowania interfejsów użytkownika, Microsoft oferuje nam dwie możliwości - wykorzystać wcześniej nagrane kroki i na ich podstawie stworzyć nowy projekt ‘Code UI Tests’ lub stworzyć całkowicie nowy projekt „Code UI Tests”. Code UI Tests jest jedną z nowych funkcjonalności, które pojawiły się w VS2010. Pozwala on na całkowicie automatyczne testowanie działania i zachowania interfejsów użytkownika.
Co dokładnie oferuje ‘Code UI Test’?
Według Microsoftu zapewnione jest pełne wsparcie dla:
IE7, IE8, dla IE9 możliwe jest odtwarzanie wcześniej nagranych akcji, WinForms 2.0 i wyżej, WPF 3.5 i wyższe, Silverlight 4, Dynamics CRM Web client, częściowe wsparcie dla Win32, MFC jak również dla kontrolek firm trzecich jak np. Infragistic (wsparcie dla firma trzecich realizowane jest we współpracy z tymi nimi, dlatego w dużej mierze to od nich zależy, kiedy pojawi się wsparcie dla stworzonych przez nich komponentów).
Aby utworzyć nowy projekt zawierający nasz ‘Code UI Test ’ tworzymy nowy ‘Test Project’ w Visual Studio, a następnie dodajemy jako referencję ‘Code UI’. Po dodaniu i załadowaniu wszystkich referencji wyświetlone zostaje pytanie, w jakim trybie ma być utworzony test. Do wyboru mamy dwie opcje:
- utworzenie całkowicie nowego testu,
- wykorzystanie już istniejącego, np. pochodzącego z MTM.
Po wybraniu opcji nagrania nowego testu uruchamia się ‘Code UI Test Builder’, natomiast do naszego projektu zostaje dodany plik ‘CodedUITest1.cs’, w którym będą znajdowały się nasze klasy testowe, metody, asercje. Kod dla naszego testu może być generowany w C# lub Visual Basicu. Można powiedzieć, że z jednej strony jest to zaletą, gdyż otrzymujemy dostęp do wszystkich narzędzi oraz usług, które oferuje platforma .NET, czyli w praktyce otrzymujemy podobny zestaw narzędzi, jakim dysponuje deweloper. Według producenta możliwe jest włączenie kodu testowego jako części tworzonego oprogramowania, co daje możliwość wykonania testów wraz z tworzeniem nowego buildu. Z drugiej strony mam wrażenie, że jest to w pewnym stopniu przerost formy nad treścią - dla osób, które nie znają Visual Studio i struktury projektów może być dość uciążliwe.
Kiedy mamy już gotowe środowisko możemy zacząć nagrywanie naszego skryptu.
W ramach przetestowania możliwości wykorzystałem aplikacje dostępne na Windows Client, Asp.net, na początek ‘Adding Annotations to Flow Documents’, stworzonej przy wykorzystaniu WPF.
Po wybraniu opcji ‘Start Recording’ rozpoczyna się rejestracja każdej naszej czynność. Po zakończeniu nagrywania, kiedy klikniemy na ‘Genrate Code’, pokazuje się nam nowe okienko, w którym możemy podać nazwę metody, która będzie zawierać nasze akcje.
Po wygenerowaniu kodu do naszego projektu zostają dodane:
UIMap.uitest - plik XML, który zawiera model UIMap.cs wraz z parametrami
UIMap.Designer.cs - zawiera odniesienia do kodu XML zawartego w pliku UIMap.uitest file.
UIMap.cs - jest to mapa elementów zawierających elementy interfejsu użytkownika, do rozpoznawania elementów. Jeśli chcemy dodać jakieś nowe elementy możemy to zrobić właśnie w tym pliku.
Mając nagrany skrypt możemy spróbować odtworzyć go. W tym celu wybieramy ‘Run test in current contex’ i już na samym początku okazuje się, że nie udaje się odtworzyć wcześniej nagranego testu. W przypadku błędu dostajemy ‘bardzo dokładny’ komunikat, co poszło nie tak, dodatkowo mamy również udostępniony ‘stack trace’, co może ułatwić debugowanie naszego skryptu.
Po bliższym przyjrzeniu się informacji możemy wyczytać, że kontrolka została przyblokowana przez inne okienko. Uruchamiam ponownie i po raz kolejny okazuje się, że nie można odtworzyć testu. Tym razem jest to wina rozpoznawania położenia na podstawie koordynatu ekranu. Uruchommy więc skrypt w trybie debug i zobaczmy, co się stanie.
Debugownie wygląda tak samo jak w przypadku każdej innej aplikacji tworzonej w Visual Studio - dostajemy bardzo rozbudowany tryb debug, w którym mamy możliwość bieżącego śledzenia tego, co się dzieje - zarówno w skrypcie, jak i w aplikacji mamy możliwość podglądu i monitorowania wartości zmiennych. Daje to duże możliwości do analizy tego czemu skrypt się nie wykonał, co wpłynęło na takie lub inne działanie, czy błąd był po naszej stronie, czy może coś działo się ze środowiskiem. Jednak tak jak wcześniej wspominałem, nie wiem czy taka ilość informacji jest potrzebna - nie zawsze mamy potrzebę śledzenia każdej zmiennej w systemie, a chcemy tylko konkretnej informacji dlaczego lub w którym miejscu coś nie zadziałało. Czasami może się okazać, że przebijanie się przez każdą linię może okazać się mało efektywne i czas, który poświęcamy na znalezienie źródła błędu nie jest adekwatny do jego wagi.
Jeśli chodzi o walidację, to z poziomu Test Buildera możemy uzyskać informacje o danej kontrolce czy polu przeciągając na nią symbol celownika. Otwierane jest wtedy okienko zawierające wszystkie właściwości, jakie udało się odczytać z danego elementu. Właściwości zostały podzielone na trzy grupy :
‘Search’ - zawiera informacje o danej kontrolce,
‘Control Specific’ - jak sama nazwa wskazuje, zawiera konkretne informacje o kontrolce,
‘Generic’ – zawiera ogólne informacje o typie.
Dla każdej właściwości możemy dodać walidację, jednak opiera to się na porównywaniu wartości, która została pobrana z kontrolki. Nie jest to zbyt duży wachlarz możliwości, jednak w przypadku wielu aplikacji może okazać się wystarczający. Walidując zachowanie mamy możliwość monitorowania zdarzeń, które mogą się pojawić w trakcie pracy aplikacji, np. otwarcie nowego okna czy pojawienie się wskaźnika progresu. Możemy to zrobić używając odpowiednich metod z pakietu UITestControl.WaitForControlXXX (), gdzie xxx to nazwa konkretnej metody np. WaitForControlNotExist(), czyli czekanie na zniknięcie kontrolki. Jeśli nasz skrypt jest tworzony z akcji, które zostały nagrane podczas ręcznego wykonywania scenariusza i, w przypadku tego scenariusza, były wykorzystywane parametry wejściowe, to mamy do nich dostęp. Możemy wykorzystać tę możliwość do definiowania różnych przypadków bez potrzeby modyfikowania kodu. Sama walidacja jest dość uboga, brakuje choćby możliwości porównywania obrazów - co prawda jest to możliwe, jednak musimy użyć do tego zewnętrznej biblioteki ‘TestApi’ dostępnej na codeplex. Sama identyfikacja kontrolek też nie zawsze działa tak jak powinna. Dotyczy to zwłaszcza kontrolek firm trzecich np. Infragistics (pomimo że podczas nagrywania skryptu Visual studio potrafi rozpoznać kontrolkę i wygenerować obsługę np. kliknięcia w dane pole, to już przy próbie dodania walidacji dla tego pola całe Visual studio potrafi się zawiesić - w takich przypadkach pozostaje czekać na dodanie obsługi przez firmy zewnętrzne).
Podsumowując można stwierdzić, że jak każde narzędzie również to ma swoje wady i zalety, a przewaga jednych czy drugich będzie wynikać z rodzaju projektu i tego, co ma być testowane. Jeśli tworzymy aplikacje webowe, testy Code UI działają dobrze, nie ma problemu z rozpoznawaniem elementów, pobieraniem wartości, czy klikaniem w określone elementy (chociaż tutaj pojawia się problem kliknięć po koordynatach ekranowych, co przy zmianie położenia będzie stanowić problem). Jak wspomniałem, nie do końca wystarczająca może być też walidacja. Często nie ma możliwości sprawdzenia tego, co dzieje się z aplikacją jak przez porównanie zawartości okna, co przy statycznym interfejsie możemy zrobić porównując bitmapy czy korzystając z innych rodzajów metod walidacji, które nie są dostępne w Visual studio. Z drugiej strony mamy duże możliwość rozszerzenia standardowego produktu. Biorąc pod uwagę to, jak szybko zmieniają się interfejsy, Microsoft przyjął taktykę przerzucenia części wsparcia obiektów na użytkowników zamiast implementacji tego w standardowym produkcie - daje to duże możliwości tworzenia niestandardowych rozwiązań, ale też wymaga dodatkowej pracy. Czy jest to słuszne rozwiązanie czy nie to już kwestia dyskusji. Tworząc testy możliwość wykorzystania potężnej platformy, jaką jest .Net, integracja tworzonych tak testów interfejsów z cyklem oprogramowania może dać możliwość szybszego testowania i tworzenia nowych wersji, co na pewno będzie zaletą. Musimy często wydawać uaktualnienia produktu, ale niekoniecznie dużo zmienia się w jego interfejsie. Narzędzie Microsoftu na pewno posiada duże możliwości i warto się im przyjrzeć w kontekście tworzonego oprogramowania. Może okazać się, że przy niewielkim wysiłku możemy stworzyć testy automatyczne, które w przypadku innych narzędzi pochłonęłyby dużo więcej czasu, a ich wykorzystanie nie byłoby możliwe za każdym razem.
Autor: Łukasz Jabcoń
