Piramida automatyzacji testów
Piramida automatyzacji testów
Piramida automatyzacji testów zaproponowana przez Mike'a Cohna pomoże Ci znaleźć najlepsze podejście do automatyzacji testów.
16 maj 2019
2124
Other articles
Testowanie aplikacji za pomocą JUnit5 i JMock. Część 2
Jak przygotować się do certyfikacji IIBA. Wyzwania i hacki
Testowanie aplikacji za pomocą JUnit5 i Mockito. Część 2
Testowanie aplikacji za pomocą JUnit5 i Mockito. Część 1
Testowanie aplikacji za pomocą JUnit5 i EasyMock. Część 2
Testowanie aplikacji za pomocą JUnit5 i EasyMock. Część 1
Test Driven Development z użyciem JUnit 5. Część 6
Test Driven Development z użyciem JUnit 5. Część 5
Test Driven Development z użyciem JUnit 5. Część 4
Test Driven Development z uzyciem JUnit 5. Czesc 3
Piramida automatyzacji testów zaproponowana przez Mike'a Cohna pomoże Ci znaleźć najlepsze podejście do automatyzacji testów.
Najprostszym podejściem do automatyzacji testów jest wykonanie przypadków testowych stworzonych do ręcznego testowania i zautomatyzowanie ich na poziomie interfejsu użytkownika (GUI) za pomocą narzędzi takich jak Selenium. Niemniej jednak jest to najmniej skuteczne podejście. Zautomatyzowane testy GUI są dłuższe, podatne na wszelkie zmiany i trudne do utrzymania.
Piramida automatyzacji Mike'a Cohna stanowi doskonałą ilustrację bardziej efektywnego podejścia. Szerokość każdego poziomu piramidy pokazuje, ile testów powinno być w porównaniu z innymi poziomami.
Testy jednostkowe znajdują się na dolnym poziomie piramidy. Powinny reprezentować większość twoich testów. Na przykład, aby przetestować klasę, która oblicza odsetki w kwocie, należy utworzyć test jednostkowy renderujący stopę procentową x i bilans y. Oczekiwany wynik: poprawne obliczenie kwoty odsetek z wymaganą dokładnością.
Środkowy poziom odnosi się do testów weryfikujących zachowanie biznesowe (ale nie poprzez GUI!). Takie testy są czasami nazywane testami API. Jeśli korzystasz z metodologii rozwoju opartego na zachowaniu (BDD), automatyczne testy będą odnosić się do tego poziomu. Możesz potrzebować dość dużej liczby testów jednostkowych na tym poziomie, ale mniej niż testów jednostkowych. Takie testy mogą obejmować kilka komponentów jednocześnie i sprawdzać zachowanie produktu pod względem biznesowym. Przykład: Po obliczeniu odsetek od depozytu, wymagana kwota jest dodawana do salda.
Najwyższy poziom piramidy reprezentuje automatyczne testy, które bezpośrednio odnoszą się do interfejsu użytkownika. Ich liczba powinna być znacznie niższa. Przykład takiego testu: Po obliczeniu odsetek nowa poprawna kwota znajduje odzwierciedlenie w wyciągu bankowym.
Wisienką na torcie są testy ręczne. Niektóre typy testów nie mogą być zautomatyzowane, np. testowanie eksploracyjne lub testowanie użyteczności, ale idealnie powinniśmy zawsze starać się minimalizować ilość testów ręcznych.
Inne ważne zasady dotyczące piramidy automatyzacji testów:
Unikaj powielania testów na różnych poziomach. Nie ma potrzeby powtarzania tych samych testów na różnych poziomach. Na przykład, jeśli wartości graniczne zostały sprawdzone w testach jednostkowych, nie powinieneś ich powtarzać na poziomie GUI - nie otrzymasz żadnych nowych danych.
Ogólnie mówiąc, tam gdzie to możliwe, należy dążyć do przesunięcia testów na niższy poziom. Powiedzmy, że możesz sprawdzić obliczanie odsetek od ujemnej sumy na "średnim poziomie" lub nawet na poziomie testów jednostkowych. Dlaczego więc miałbyś to robić na poziomie interfejsu użytkownika? Automatyzacja testów na niższym poziomie jest bardziej wydajna, pozwala zidentyfikować wady wcześniej oraz zaoszczędzić czas i pieniądze.
Ilustracja z "More Agile Testing: Learning Journeys for the Whole Team" (Janet Gregory, Lisa Crispin)
Najprostszym podejściem do automatyzacji testów jest wykonanie przypadków testowych stworzonych do ręcznego testowania i zautomatyzowanie ich na poziomie interfejsu użytkownika (GUI) za pomocą narzędzi takich jak Selenium. Niemniej jednak jest to najmniej skuteczne podejście. Zautomatyzowane testy GUI są dłuższe, podatne na wszelkie zmiany i trudne do utrzymania.
Piramida automatyzacji Mike'a Cohna stanowi doskonałą ilustrację bardziej efektywnego podejścia. Szerokość każdego poziomu piramidy pokazuje, ile testów powinno być w porównaniu z innymi poziomami.
Testy jednostkowe znajdują się na dolnym poziomie piramidy. Powinny reprezentować większość twoich testów. Na przykład, aby przetestować klasę, która oblicza odsetki w kwocie, należy utworzyć test jednostkowy renderujący stopę procentową x i bilans y. Oczekiwany wynik: poprawne obliczenie kwoty odsetek z wymaganą dokładnością.
Środkowy poziom odnosi się do testów weryfikujących zachowanie biznesowe (ale nie poprzez GUI!). Takie testy są czasami nazywane testami API. Jeśli korzystasz z metodologii rozwoju opartego na zachowaniu (BDD), automatyczne testy będą odnosić się do tego poziomu. Możesz potrzebować dość dużej liczby testów jednostkowych na tym poziomie, ale mniej niż testów jednostkowych. Takie testy mogą obejmować kilka komponentów jednocześnie i sprawdzać zachowanie produktu pod względem biznesowym. Przykład: Po obliczeniu odsetek od depozytu, wymagana kwota jest dodawana do salda.
Najwyższy poziom piramidy reprezentuje automatyczne testy, które bezpośrednio odnoszą się do interfejsu użytkownika. Ich liczba powinna być znacznie niższa. Przykład takiego testu: Po obliczeniu odsetek nowa poprawna kwota znajduje odzwierciedlenie w wyciągu bankowym.
Wisienką na torcie są testy ręczne. Niektóre typy testów nie mogą być zautomatyzowane, np. testowanie eksploracyjne lub testowanie użyteczności, ale idealnie powinniśmy zawsze starać się minimalizować ilość testów ręcznych.
Inne ważne zasady dotyczące piramidy automatyzacji testów:
Unikaj powielania testów na różnych poziomach. Nie ma potrzeby powtarzania tych samych testów na różnych poziomach. Na przykład, jeśli wartości graniczne zostały sprawdzone w testach jednostkowych, nie powinieneś ich powtarzać na poziomie GUI - nie otrzymasz żadnych nowych danych.
Ogólnie mówiąc, tam gdzie to możliwe, należy dążyć do przesunięcia testów na niższy poziom. Powiedzmy, że możesz sprawdzić obliczanie odsetek od ujemnej sumy na "średnim poziomie" lub nawet na poziomie testów jednostkowych. Dlaczego więc miałbyś to robić na poziomie interfejsu użytkownika? Automatyzacja testów na niższym poziomie jest bardziej wydajna, pozwala zidentyfikować wady wcześniej oraz zaoszczędzić czas i pieniądze.
Zainteresowany ulepszeniem swoich umiejętności testowania oprogramowania?