Prezentowanie dostępnej funkcjonalności aplikacji w postaci diagramów wygenerowanych przez skrypty automatyczne

Prezentowanie dostępnej funkcjonalności aplikacji w postaci diagramów wygenerowanych przez skrypty automatyczne
Dobrze prowadzony projekt powinien mieć, wcześniej czy później, zaraportowane przypadki testowe. Pokazują one dostępną funkcjonalność aplikacji oraz wyniki ich uruchomienia na aplikacji w poszczególnych etapach projektu. Funkcjonalność podlega jednak ciągłym zmianom, przykładowo narzucanych przez klienta. To z kolei wymusza zmianę wcześniej napisanych przypadków testowych. Jeżeli przypadki testowe mają swoje odzwierciedlenie w skryptach automatycznych, to trzeba na dodatek zmienić również skrypty. Aby zaoszczędzić czas warto przerzucić ciężar zmian przypadków testowych na automat. Skoro funkcjonalność dynamicznie się zmienia, to musimy też często zmieniać dokumentację przypadków testowych. Najszybciej zrobi to automat.


Pisząc dowolny skrypt automatyczny warto pomyśleć o tym, aby skrypt samodzielnie rejestrował użycie przypadku testowego i zapisywał go do pliku. Jeżeli na przykład automat wybiera odpowiednią pozycję menu aplikacji, to jest to przypadek testowy, a wynik tej akcji, pozytywny lub negatywny, jest jego rezultatem. Obie te informacje skrypt powinien zapisać do pliku. Podobnie gdy wykonywana jest akcja np. kliknięcie myszką na przycisku formularza. Traktujemy to np. jako krok przypadku testowego i wraz z wynikiem pozytywnym/negatywnym zapisujemy do pliku. Jeżeli w wyniku pojawia się incydent, to przechwytywana i zapisywana do pliku jest również treść komunikatu błędu. Wspomniany plik ma zazwyczaj format XML lub CSV, ze względu na możliwość importu do narzędzia zarządzania testowaniem jak HP ALM.

Dane zapisane do pliku można następnie wizualizować w postaci diagramu (patrz poniżej). Takie diagramy są czytelne i pomagają w lokalizacji miejsca incydentu. Są też rodzajem diagramu stanów naszej aplikacji, pseudoUML-owym zapisem przypadków użycia oraz formą dokumentacji. Są też obrazem, który możemy automatycznie porównać z innym, wcześniejszym.

Diagramy są łatwym i czytelnym sposobem prezentacji tego, co testy automatyczne robią. Są wizualnym udokumentowaniem testów. Klient może dzięki nim zobaczyć, że za każdym diagramem stoi fizyczne wykonanie, czyli pokrycie automatem funkcjonalności.

Poniższe diagramy to krótkie przykłady przebiegu testów dla prawdziwej aplikacji webowej tworzonej w ADMD Roche Polska.

 

Przykład 1.

 

 

Przykład 2.

 

Przykład 3.

 

 

O autorze

Marcin Jędras jest zatrudniony w ADMD Roche Polska na stanowisku Senior Test Specialist. Zajmuje się pisaniem skryptów automatycznych do aplikacji webowych oraz desktop. Wykorzystuje między innymi Ruby/Watir, webdriver 2.0, AutoIt, CasperJS oraz metody rozpoznawania obrazów do lokalizacji obiektów i wyszukiwania zmian na screen shotach aplikacji.

 

Od redakcji: Jeśli tak jak Marcin chcesz podzielić się swoją wiedzą z innymi testerami, czekamy na Twój artykuł, film, komentarz, pracę dyplomową czy inną formę treści, jaką chcesz opublikować na naszych łamach.

 

To powinno Cię zainteresować