Testy automatyczne Opcje

[Evinek]

Cześć.
Zajmuje się teraz testami automatycznymi w Selenium.
Jest to moja pierwsza styczność z tym tematem. Dotąd w firmie robiliśmy tylko testy jednostkowe.

Póki co jestem na etapie planowania, tj. co w jaki sposób testować. Wybrana technologia to Selenium oraz Python.

Kilka pytań do was:
1) jaką obrać strategię do tworzenia testów?
Czy wystarczy planować te testy, że sprawdzamy co byśmy sami testowali manualnie, a potem przepisać to do testów?
macie jakieś rady na projektowanie tych testów?

2) rejestracja z aktywacją przez email. Co robicie w takim przypadku?
Chciałbym przetestować pełną rejestrację i sprawdzić czy wszystkie usługi zostały utworzone poprawnie. W jaki sposób to rozwiązać?

3) macie jakieś dobre artykuły, które będą pomocne przy tworzeniu takich testów? o POM już czytałem. Bardziej chodzi mi o samo planowanie testów niż ich pisanie.

4) moje testy dzielą się na takie, które odczytują dane i zapisują dane. Z tego powodu też niektóre testy mogą działać tylko lokalnie i na wersji dev, ale na produkcji już nie.
Z drugiej strony są takie funkcje, które działają tylko na produkcji (np. takie jedno magiczne przekierowanie ).
Jak u was wygląda testowanie? jest środowisko dev + pre-prod do testowania? czy uruchamiacie testy na wersji produkcyjnej?

5) czy testy typu "rejestracja z za krótkim hasłem" tutaj powinny się znaleźć czy takie testy wystarczą po stronie Unit testów (testowanie walidacji formularza)?

6) chciałbym aby każdy test był od siebie niezależny. Więc w każdym teście muszę logować się na nowo aby zrobić jakąś akcję (np. sprawdź czy filtrowanie tabelki działa).
Czy takie podejście jest dobre?

7) czy przed takimi testami tworzycie dane (automatycznie przez skrypt lub manualnie), np. konta, przykładowe posty na forum, a potem testujecie CZY to wszystko robi test automatyczny przeklikując cały panel (moim zdaniem to zbyt mocno wydłuża czas trwania takich testów)?

8) czy jeden test case może sprawdzać kilka elementów strony? Np. czy 4 usługi działają poprawnie (w tym wysłanie rekordu, czekanie aż API zwróci dane) czy jednak większość testów powinna być jak najprostsza, najkrótsza?
Czyli czy wiele bardzo małych testów robić czy wystarczy mniej, ale gdzie 1 test sprawdza więcej rzeczy? Tutaj pojawia się problem z wykonywaniem takich testów, zbyt wiele małych testów może spowodować wydłużenie testów (np. zawsze musi się logować)

9) przykładowe pomysły na testy, bardzo ogólne:

usuwanie configu
- dodajemy nowy config ("Add a new LMS")
- wchodzimy w config
- klikamy "delete this LMS"
- sprawdzamy czy config zniknął z listy configów

rejestracja
- przechodzimy na "Sign up"
- wypełniamy dane
- rejestrujemy się
- sprawdzamy czy pojawił się alert z informacją o poprawnej rejestracji

sprawdzamy czy linki po hashu (#) działają (jest to test JS)
- przechodzimy na /PathA#/aaa
- sprawdzamy czy przeniosło nas od razu do /aaa w SEC
- przechodzimy na /PathB#/bbb
- sprawdzamy czy przeniosło nas od razu do /bbb w SEP

Czy takie testy wyglądają w porządku?

10) jak macie jakieś fajne uwagi jeszcze to z chęcią wysłucham

To tak na szybko pytania, pewnie w trakcie jeszcze jakieś wyjdą i was pomęczę. 

Ten post edytował Evinek 8.04.2018, 20:19:00

[batman]

1. Tworzysz testy pokrywające przypadki brzegowe oraz to, co testuje się ręcznie, przy czym dodajesz więcej przypadków testowych (bo możesz i nie zje to tyle czasu ile testowanie ręczne).

2. Przechodzisz przez całą ścieżkę i weryfikujesz na końcu czy pojawił się odpowiedni komunikat. Samo wysłanie maila mockujesz lub przechwytujesz wysłany email (gorsza opcja).

4. Nigdy nie uruchamiaj testów na produkcji, nigdy! Do testów przygotuj środowisko testowe będące kopią środowiska produkcyjnego. Przed wdrożeniem zmian na producji odpal w tym środowisku testy i jeśli wszystko jest ok, to masz zielone światło to aktualizacji produkcji.

5. Tak. Testy jednostkowe przetestują samą walidację, ale i tak dobrze sprawdzić czy nastąpi (bądź nie) przekierowanie, czy komunikat poprawnie się wyświetlił, itd.

6.Tak. Każdy test powinien być od siebie niezależny.

7. Tak. Nazywa się do fixtures (Django), seed (Laravel) lub tak jak autor danego rozwiązania wymyślił. W skrócie jest to sposób na zapełnienie bazy danymi, które będą pomocne w testowaniu. W zależności od rodzaju aplikacji można przygotować kilka zestawów danych, co jest pomocne w volume testing, ale to temat za zupełnie inny wątek.

8. Jeden test powinien pokrywać jeden przypadek użycia. Jest to dosyć szeroka definicja i wymaga nieco doświadczenia poprawnie jej zastosowanie. Na początek możesz przyjąć, że jeden test to logowanie + przejście do docelowej strony + weryfikacja wyniku.

9. Wygląda nieźle.

10. https://locust.io