Wzorce automatyzacji interfejsu użytkownika i najlepsze praktyki dotyczące aplikacji komputerowych

tło

Obecnie automatyzuję niektóre testy wtyczki dla MS Office. Testy Coded UI tworzymy w VS 2010. Przypuszczam, że mógłbym użyć narzędzia „ Coded UI test builder ”, ale tak naprawdę nie pasuje to do mojego konkretnego przypadku.

Z tego powodu stworzyłem własną klasę mapy interfejsu użytkownika i metody rozszerzenia dla każdej kontrolki interfejsu / mapy interfejsu użytkownika, w której dodałem różne funkcje akcji. Na przykład naciśnij przyciski lub wprowadź niektóre wartości interfejsu użytkownika.

Scenariusze przypadków testowych znajdują się w klasach testowych.

Jestem nowy w tej dziedzinie, a także jestem nowy w pracy jako tester automatyzacji.

Pytanie

Czy ludzie byliby na tyle uprzejmi, aby podzielić się swoimi doświadczeniami i poradami dotyczącymi dobrych praktyk automatyzacji testów w aplikacjach komputerowych z punktu widzenia programowania / projektowania?

Najlepszą praktyką w testowaniu automatyzacji interfejsu użytkownika jest robienie jak najmniej. Interfejsy użytkownika zmieniają się często, co oznacza, że ​​stale musisz aktualizować swoją automatyzację. Zasadniczo lepiej jest ustrukturyzować kod produktu w sposób umożliwiający automatyczne testowanie bez automatyzacji interfejsu użytkownika.

To powiedziawszy, nie zawsze możesz pozbyć się Automatyzacji interfejsu użytkownika. Wspominasz o biurze, więc zakładam, że programujesz dla Windows i używasz .Net. W mojej obecnej pracy całkiem sporo. Oto niektóre rzeczy, których się nauczyłem.

1) Spójrz na biblioteki UIAutomation, które zostały wprowadzone w .Net 3.0. Zapewniają obszerną i dość prostą w użyciu bibliotekę do automatyzacji. (http://msdn.microsoft.com/en-us/library/ms753107.aspx)

2) Pobierz UISpy (http://msdn.microsoft.com/en-us/library/ms727247.aspx)

3) Ustaw interfejs użytkownika w swoim urządzeniu w sposób automatyczny.

3a) Jeśli jest to WPF, umieść AutomationIDs na wszystkim.

3b) Spróbuj utworzyć charakterystyczne nazwy kontrolne i nazwy klas okien (nazwy klas interfejsu użytkownika, a nie nazwa klasy kodu źródłowego). Jeśli nie wiesz, co mam na myśli, załaduj UI Spy i zacznij przeglądać okna. Zauważ, ile okien w różnych aplikacjach ma nazwę klasy # 32770. Jest to nazwa klasy dla okna dialogowego Windows. Każde okno, które rozszerza okno dialogowe i nie ustawia własnej nazwy, domyślnie jest to. Powoduje to wszelkiego rodzaju żal z punktu widzenia automatyzacji interfejsu użytkownika.

4) Unikaj instrukcji Thread.Sleep (). Zamiast tego spróbuj użyć Kelnerów (patrz dokumenty UIAutomation).

5) NIGDY nie mieszaj kodu testowego z kodem automatyzacji interfejsu użytkownika. Utwórz osobne biblioteki, aby wykonać automatyzację interfejsu użytkownika. Wywołaj te biblioteki ze swoich testów. Zmiana interfejsu użytkownika znacznie ułatwi aktualizację automatyzacji.

6) Zawsze rejestruj detektor dla zdarzenia interfejsu użytkownika przed wykonaniem czynności, która spowodowałaby uruchomienie zdarzenia. W praktyce oznacza to, że będziesz pracować z wątkami.

6a) Przykład: nie zaczynaj czekać na zdarzenie Otwarte okno po kliknięciu przycisku, aby otworzyć okno. Okno może się otworzyć przed zarejestrowaniem kelnera i nigdy nie uzyskać zdarzenia.

7) Nigdy nie zakładaj, że właśnie otwarte okno jest tym, którego chcesz. Wszystkie rodzaje okien mogą się nieoczekiwanie otworzyć w systemie Windows.

Mógłbym kontynuować, ale robi się to trochę dłużej.

Twórz testy funkcjonalne na podstawie przypadków wielokrotnego użytku

Gdy przyjdzie czas na przetestowanie aplikacji od końca do końca na miejscu, przeprowadzasz testy funkcjonalne. Zazwyczaj masz zestaw wymagań, na których testujesz, i możesz konstruować różne reprezentujące je przypadki użycia.

Jako przykład rozważ przypadek użycia „Zaloguj się jako użytkownik standardowy”. Twoja platforma testowa uruchamia aplikację, czeka na ekran logowania, wprowadza poświadczenia, klika przycisk logowania i sprawdza, czy odpowiedni ekran pokazuje, że logowanie się powiodło.

Po wykonaniu przypadku użycia „Zaloguj się jako użytkownik standardowy”, możesz na tym polegać, aby zrobić coś innego, na przykład przypadek użycia „Edytuj moje dane użytkownika”. Nie będziesz chciał powtarzać całego kodu z przypadku użycia „Zaloguj się jako użytkownik standardowy”, więc po prostu odwołaj się do kodu frameworka testowego, który to robi.

Oznacza to, że masz jakiś nadrzędny test funkcjonalny zawierający listę przypadków użycia. Te przypadki użycia zawierają metody ram testowych, które powodują zachowanie aplikacji (kliknij przycisk X) i weryfikują zachowanie (ekran zmienił kolor na niebieski).

Ogólnie rzecz biorąc, możesz zbudować zestaw przypadków wielokrotnego użytku, które są ukierunkowane na określone sekwencje i testują określone odpowiedzi, a następnie agregują je w różne testy funkcjonalne, które są ściśle powiązane z wymaganiami biznesowymi. Gdy już to zrobisz, będziesz w stanie zautomatyzować cały proces kompilacji .

Jeśli chcesz przeczytać dalej , napisałem o tym podejściu w innym miejscu, ale ten artykuł dotyczy aplikacji internetowych w Javie (wykorzystujących Maven i SeleniumRC), a nie aplikacji komputerowych, o które prosiłeś.