Co to jest testowanie automatyczne?
W tej lekcji dowiesz się więcej na temat zalet zautomatyzowanego testowania i rodzajów testów, które można wykonać. Dowiesz się również, co sprawia, że test jest dobry i wprowadzasz do niektórych dostępnych narzędzi do testowania.
Co to jest testowanie automatyczne?
Testowanie automatyczne używa oprogramowania do wykonywania kodu i porównywania rzeczywistych wyników z oczekiwanymi wynikami. Porównaj to z testami eksploracyjnymi lub ręcznymi, gdzie człowiek zwykle wykonuje instrukcje w planie testowym, aby sprawdzić, czy oprogramowanie działa zgodnie z oczekiwaniami.
Testowanie ręczne ma swoje zalety. Jednak w miarę wzrostu rozmiaru bazy kodu testowanie wszystkich funkcji ręcznie (w tym przypadków brzegowych) może stać się powtarzalne, żmudne i podatne na błędy. Zautomatyzowane testowanie może pomóc wyeliminować niektóre z tych obciążeń i umożliwić testerom ręcznym skupienie się na tym, co robią najlepiej: zapewnienie użytkownikom pozytywnego doświadczenia w oprogramowaniu.
Piramida testowa
Gdy myślimy o testowaniu automatycznym, często dzielimy testy na warstwy. Mike Cohn proponuje tę koncepcję, znaną jako piramida testowa, w swojej książce Powodzenie z Agile.
Chociaż jest to uproszczona wersja modelu Cohna, koncepcja ilustruje, że większość wysiłku polega na pisaniu testów, które weryfikują podstawowe poziomy oprogramowania (objaśnienie 1 w piramidzie), takie jak funkcje, klasy i metody. Stopniowo zmniejszasz nakład pracy, ponieważ funkcje są łączone, na przykład w warstwie interfejsu użytkownika (objaśnienie 2 w ostrosłupie). Chodzi o to, że jeśli można sprawdzić, czy każdy składnik niższego poziomu działa zgodnie z oczekiwaniami w izolacji, testy na wyższych poziomach wymagają tylko sprawdzenia, czy wiele składników współdziała ze sobą, aby uzyskać oczekiwany wynik.
Kiedy należy pisać testy?
Odpowiedź zależy głównie od potrzeb i doświadczenia w pisaniu testów.
Nigdy nie jest za późno, aby rozpocząć dodawanie testów dla kodu, który został już napisany i wdrożony. Dotyczy to szczególnie funkcji, które często przerywają lub wymagają największego wysiłku ze strony zespołu testowego.
W przypadku powiązania testowania z potokami ciągłej integracji i ciągłego dostarczania poznasz dwie koncepcje, o których będziesz wiedzieć, to ciągłe testowanie i przesuwanie w lewo.
Testowanie ciągłe oznacza, że testy są uruchamiane na wczesnym etapie procesu tworzenia, ponieważ każda zmiana przechodzi przez potok. Przesunięcie w lewo oznacza rozważenie jakości oprogramowania i testowania wcześniej w procesie programowania.
Deweloperzy często dodają przypadki testowe podczas opracowywania funkcji i uruchamiania całego zestawu testów przed przesłaniem zmiany do potoku. Takie podejście pomaga zapewnić, że kompilowane funkcje działają zgodnie z oczekiwaniami i że nie przerywa istniejących funkcji.
Oto krótkie wideo, w którym Abel Wang, ambasador chmury w firmie Microsoft, wyjaśnia, jak zapewnić jakość w planie DevOps.
Zapytaj Abela
Przesunięcie w lewo często wymaga, aby testerzy uczestniczyli w procesie projektowania, nawet zanim zostanie napisany jakikolwiek kod funkcji. Porównaj je z modelem "przekazywania", w którym zespół testowy przedstawia nowe funkcje do testowania dopiero po zaprojektowaniu i napisaniu oprogramowania. Wykryta usterka pod koniec procesu może mieć wpływ na harmonogram dostarczania zespołu, a usterki mogą zostać odnalezione kilka tygodni, a nawet miesięcy po utworzeniu funkcji przez dewelopera.
Kompromis
W przypadku testowania automatycznego istnieje kompromis. Mimo że zautomatyzowane testowanie umożliwia testerom skoncentrowanie czasu na weryfikowaniu środowiska użytkownika końcowego, deweloperzy mogą poświęcić więcej czasu na pisanie i konserwowanie kodu testowego.
Jednak celem zautomatyzowanego testowania jest zapewnienie, że testerzy otrzymują tylko kod najwyższej jakości, kod, który został sprawdzony zgodnie z oczekiwaniami. W związku z tym deweloperzy mogą odzyskać jakiś czas, muszą obsługiwać mniej usterek lub unikać ponownego zapisywania kodu z powodu przypadków brzegowych, które nie zostały pierwotnie uwzględnione.
Dodano korzyści
Dokumentacja i możliwość refaktoryzacji kodu są dwiema zaletami zautomatyzowanego testowania.
Dokumentacja
Plany testów ręcznych mogą służyć jako rodzaj dokumentacji, jak oprogramowanie powinno zachowywać się i dlaczego istnieją pewne funkcje.
Testy automatyczne mogą obsługiwać ten sam cel. Kod testów automatycznych często używa formatu czytelnego dla człowieka. Podany zestaw danych wejściowych reprezentuje wartości, które użytkownicy mogą wprowadzić. Każde skojarzone dane wyjściowe określa wynik, który użytkownicy powinni oczekiwać.
W rzeczywistości wielu deweloperów stosuje metodę programowania opartego na testach (TDD), pisząc kod testowy przed zaimplementowaniem nowej funkcji. Chodzi o napisanie zestawu testów, często nazywanych specyfikacjami, które początkowo kończą się niepowodzeniem. Następnie deweloper przyrostowo pisze kod w celu zaimplementowania funkcji do momentu ukończenia wszystkich testów. Nie tylko specyfikacje dokumentują wymagania, ale proces TDD pomaga zapewnić, że tylko wymagana ilość kodu jest zapisywana w celu zaimplementowania tej funkcji.
Refaktoryzacja
Załóżmy, że masz dużą bazę kodu, którą chcesz refaktoryzować, aby niektóre części działały szybciej. Jak wiesz, że działania refaktoryzacji nie spowodują przerwania części aplikacji?
Testy automatyczne służą jako typ kontraktu. Oznacza to, że należy określić dane wejściowe i oczekiwane wyniki. Jeśli masz zestaw testów, możesz lepiej eksperymentować i refaktoryzować kod. Gdy wprowadzisz zmianę, wystarczy uruchomić testy i sprawdzić, czy nadal przechodzą. Po osiągnięciu celów refaktoryzacji możesz przesłać zmianę do potoku kompilacji, aby wszyscy mogli korzystać, ale z niższym ryzykiem wystąpienia problemu.
Jakie są typy testów automatycznych?
Istnieje wiele typów testów automatycznych. Każdy test służy oddzielnemu celowi. Na przykład można uruchomić testy zabezpieczeń, aby sprawdzić, czy tylko autoryzowani użytkownicy mogą uzyskać dostęp do oprogramowania lub jednej z jego funkcji.
Gdy wspominamy o ciągłej integracji i potoku kompilacji, zwykle odnosimy się do testowania programistycznego. Testowanie programistyczne odnosi się do testów, które można uruchomić przed wdrożeniem aplikacji w środowisku testowym lub produkcyjnym.
Na przykład testowanie lint, forma analizy statycznego kodu, sprawdza kod źródłowy, aby określić, czy jest zgodny z przewodnikiem stylu zespołu. Kod sformatowany spójnie ułatwia wszystkim odczytywanie i konserwację.
W tym module będziesz pracować z testowaniem jednostkowym i testowaniem pokrycia kodu.
Testowanie jednostkowe sprawdza najbardziej podstawowe składniki programu lub biblioteki, takie jak pojedyncza funkcja lub metoda. Należy określić jeden lub więcej danych wejściowych wraz z oczekiwanymi wynikami. Moduł uruchamiający testy wykonuje każdy test i sprawdza, czy rzeczywiste i oczekiwane wyniki są zgodne.
Załóżmy na przykład, że masz funkcję, która wykonuje operację arytmetyczną obejmującą dzielenie. Możesz określić kilka wartości, które mają zostać wprowadzone przez użytkowników wraz z wartościami wielkości liter krawędzi, takimi jak 0 i -1. Jeśli określone dane wejściowe generują błąd lub wyjątek, możesz sprawdzić, czy funkcja generuje ten sam błąd.
Testowanie pokrycia kodu oblicza procent kodu objętego testami jednostkowymi. Testowanie pokrycia kodu może obejmować gałęzie warunkowe w kodzie, aby upewnić się, że funkcja jest objęta.
Im większa wartość procentowa pokrycia kodu, tym większa pewność, że nie zostanie później wykryta usterka w kodzie, która nie została w pełni przetestowana. Nie musisz osiągać 100-procentowego pokrycia kodu. W rzeczywistości, po rozpoczęciu, prawdopodobnie okaże się, że masz niski procent, ale daje to punkt wyjścia, z którego można dodać dodatkowe testy, które obejmują problematyczny lub często używany kod.
Zachowaj izolowanie testów jednostkowych
Podczas nauki o testowaniu jednostkowym możesz usłyszeć takie terminy jak makiety, wycinki i wstrzykiwanie zależności.
Pamiętaj, że test jednostkowy powinien zweryfikować pojedynczą funkcję lub metodę, a nie sposób interakcji wielu składników. Ale jeśli masz funkcję, która wywołuje bazę danych lub serwer internetowy, jak to zrobić?
Nie tylko wywołuje izolację usługi zewnętrznej, ale może spowolnić działanie. Jeśli baza danych lub serwer internetowy ulegnie awarii lub jest w inny sposób niedostępna, wywołanie może również zakłócić przebieg testu.
Korzystając z technik, takich jak pozorowanie i wstrzykiwanie zależności, można tworzyć składniki, które naśladują tę funkcjonalność zewnętrzną. W dalszej części tego modułu uzyskasz przykład.
Później możesz uruchomić testy integracji, aby sprawdzić, czy aplikacja działa prawidłowo z rzeczywistą bazą danych lub serwerem internetowym.
Co sprawia, że dobry test?
Będziesz w stanie lepiej zidentyfikować dobry test, ponieważ uzyskasz doświadczenie w pisaniu własnych testów i odczytywaniu testów napisanych przez inne osoby. Oto kilka wskazówek dotyczących rozpoczynania pracy:
- Nie testuj ze względu na testowanie: Testy powinny służyć celowi poza tym, że element listy kontrolnej zostanie przekroczony. Napisz testy sprawdzające, czy kod krytyczny działa zgodnie z oczekiwaniami i nie przerywa istniejących funkcji.
- Zachowaj krótkie testy: testy powinny zakończyć się tak szybko, jak to możliwe, zwłaszcza te, które mają miejsce w fazach programowania i kompilacji. Gdy testy są uruchamiane, gdy każda zmiana przechodzi przez potok, nie chcesz, aby były wąskim gardłem.
- Upewnij się, że testy są powtarzalne: przebiegi testów powinny generować te same wyniki za każdym razem, niezależnie od tego, czy są uruchamiane na komputerze, komputerze współpracownika, czy w potoku kompilacji.
- Należy skupić się na testach: Typowe błędne przekonanie polega na tym, że testy mają obejmować kod napisany przez inne osoby. Zazwyczaj testy powinny obejmować tylko twój kod. Jeśli na przykład używasz biblioteki grafiki typu open source w projekcie, nie musisz testować tej biblioteki.
- Wybierz odpowiedni stopień szczegółowości: na przykład w przypadku przeprowadzania testów jednostkowych pojedynczy test nie powinien łączyć ani testować wielu funkcji ani metod. Przetestuj każdą funkcję oddzielnie i później zapisuj testy integracji, które sprawdzają, czy wiele składników działa prawidłowo.
Jakie typy narzędzi do testowania są dostępne?
Używane narzędzia do testowania zależą od typu kompilowania aplikacji i typu testów, które chcesz wykonać. Na przykład można użyć selenium do przeprowadzania testów interfejsu użytkownika na wielu typach przeglądarek internetowych i systemów operacyjnych.
Bez względu na język, w którym aplikacja jest napisana, wiele narzędzi testowych jest dostępnych do użycia.
Na przykład w przypadku aplikacji Java możesz wybrać pozycję Checkstyle, aby przeprowadzić testowanie lint i narzędzie JUnit w celu przeprowadzenia testów jednostkowych.
W tym module użyjemy narzędzia NUnit do testowania jednostkowego, ponieważ jest on popularny w społeczności platformy .NET.