Strategie testowania

Automatyczne testowanie pomaga na wiele sposobów poprawić jakość aplikacji. Pomaga na przykład w przeprowadzaniu weryfikacji, wykrywaniu regresji i sprawdzaniu zgodności. Dobra strategia testowania pozwala korzystać z automatycznych testów, aby skupić się na ważnej korzyści: wydajności deweloperów.

Zespoły osiągają wyższy poziom produktywności, gdy stosują systematyczne podejście do testowania w połączeniu z ulepszeniami infrastruktury. Dzięki temu możesz na bieżąco otrzymywać informacje zwrotne o działaniu kodu. Dobra strategia testowania:

• Wykrywa problemy jak najwcześniej.
• Szybkie wykonywanie.
• Wyraźnie wskazuje, kiedy coś wymaga poprawy.

Na tej stronie dowiesz się, jakie rodzaje testów warto przeprowadzać, gdzie i jak często.

android skills add testing-setup

Piramida testów

Testy w nowoczesnych aplikacjach możesz kategoryzować według rozmiaru. Małe testy skupiają się tylko na niewielkiej części kodu, dzięki czemu są szybkie i niezawodne. Duże testy mają szeroki zakres i wymagają bardziej złożonych konfiguracji, które są trudne w utrzymaniu. Duże testy są jednak bardziej wiarygodne* i mogą wykryć znacznie więcej problemów za jednym razem.

*Wierność odnosi się do podobieństwa środowiska wykonawczego testu do środowiska produkcyjnego.

Większość aplikacji powinna mieć wiele małych testów i stosunkowo niewiele dużych. Rozkład testów w każdej kategorii powinien tworzyć piramidę, w której podstawę stanowią liczne małe testy, a wierzchołek – mniej liczne duże testy.

Minimalizowanie kosztów związanych z błędem

Dobra strategia testowania maksymalizuje produktywność programistów, a jednocześnie minimalizuje koszty znajdowania błędów.

Rozważmy przykład strategii, która może być nieefektywna. Liczba testów według rozmiaru nie tworzy piramidy. Jest zbyt wiele dużych testów kompleksowych i zbyt mało testów interfejsu komponentów:

Oznacza to, że przed scaleniem przeprowadzono zbyt mało testów. Jeśli wystąpi błąd, testy mogą go nie wykryć do czasu uruchomienia nocnych lub tygodniowych testów kompleksowych.

Warto zastanowić się, jakie ma to znaczenie dla kosztów identyfikowania i naprawiania błędów oraz dlaczego warto skupiać się w testach na mniejszych i częstszych testach:

• Gdy błąd zostanie wykryty przez test jednostkowy, zwykle jest naprawiany w ciągu kilku minut, więc koszt jest niski.
• W przypadku testu kompleksowego wykrycie tego samego błędu może zająć kilka dni. Może to zaangażować wielu członków zespołu, co zmniejszy ogólną produktywność i może opóźnić publikację. Koszt tego błędu jest wyższy.

Niemniej jednak nieefektywna strategia testowania jest lepsza niż brak jakiejkolwiek strategii. Gdy błąd trafi do środowiska produkcyjnego, jego naprawienie i wdrożenie na urządzeniach użytkowników zajmuje dużo czasu, czasami nawet tygodnie, więc pętla opinii jest najdłuższa i najdroższa.

skalowalną strategię testowania,

Piramida testów jest tradycyjnie podzielona na 3 kategorie:

• Testy jednostkowe
• Testy integracji
• testy kompleksowe,

Nie mają one jednak precyzyjnych definicji, więc zespoły mogą chcieć zdefiniować swoje kategorie w inny sposób, np. używając 5 warstw:

• Test jednostkowy jest przeprowadzany na komputerze hosta i weryfikuje pojedynczą jednostkę funkcjonalną logiki bez zależności od platformy Android.
  • Przykład: weryfikowanie błędów o 1 w funkcji matematycznej.
• Test komponentu weryfikuje funkcjonalność lub wygląd modułu lub komponentu niezależnie od innych komponentów w systemie. W przeciwieństwie do testów jednostkowych obszar testu komponentu obejmuje wyższe abstrakcje niż poszczególne metody i klasy.
  • Przykład: Test zrzutu ekranu w przypadku niestandardowego przycisku
• Test funkcji weryfikuje interakcję co najmniej 2 niezależnych komponentów lub modułów. Testy funkcji są większe i bardziej złożone, a zwykle działają na poziomie funkcji.
  • Przykład: testy działania interfejsu, które weryfikują zarządzanie stanem na ekranie.
• Test aplikacji weryfikuje działanie całej aplikacji w postaci pliku binarnego, który można wdrożyć. Są to duże testy integracji, które jako testowany system wykorzystują plik binarny z możliwością debugowania, np. kompilację deweloperską, która może zawierać punkty zaczepienia testowania.
  • Przykład: test zachowania interfejsu, który weryfikuje zmiany konfiguracji na urządzeniu składanym, testy lokalizacji i ułatwień dostępu
• Test wersji kandydującej do publikacji sprawdza działanie kompilacji do publikacji. Są one podobne do testów aplikacji, z tą różnicą, że binarny plik aplikacji jest zminimalizowany i zoptymalizowany. Są to duże testy integracyjne typu end-to-end, które są przeprowadzane w środowisku jak najbardziej zbliżonym do produkcyjnego, ale bez udostępniania aplikacji publicznym kontom użytkowników ani publicznym backendom.
  • Przykład: krytyczne ścieżki użytkownika, testy wydajności

Podział ten uwzględnia zgodność, czas, zakres i poziom odizolowania. Możesz przeprowadzać różne rodzaje testów na wielu warstwach. Na przykład warstwa testu aplikacji może zawierać testy zachowania, zrzutów ekranu i wydajności.

Wybierz kategorię testu

Zasadniczo należy brać pod uwagę najniższą warstwę piramidy, która może zapewnić zespołowi odpowiedni poziom informacji zwrotnych.

Weźmy na przykład testowanie implementacji tej funkcji: interfejsu użytkownika procesu logowania. W zależności od tego, co chcesz przetestować, wybierz odpowiednie kategorie:

W niektórych przypadkach przynależność do danej kategorii może być subiektywna. Istnieją dodatkowe powody, dla których test może zostać przesunięty w górę lub w dół, np. koszt infrastruktury, niestabilność i długi czas trwania testu.

Pamiętaj, że kategoria testu nie określa jego typu i nie wszystkie funkcje muszą być testowane w każdej kategorii.

Testy ręczne mogą być również częścią Twojej strategii testowania. Zwykle testy wersji kandydującej przeprowadzają zespoły ds. kontroli jakości, ale mogą one też brać udział w innych etapach. Na przykład testowanie eksploracyjne pod kątem błędów w funkcji bez skryptu.

Infrastruktura testowa

Strategia testowania musi być wspierana przez infrastrukturę i narzędzia, które pomagają deweloperom stale przeprowadzać testy i egzekwować reguły gwarantujące, że wszystkie testy zostaną zaliczone.

Możesz podzielić testy na kategorie według zakresu, aby określić, kiedy i gdzie mają być przeprowadzane poszczególne testy. Na przykład zgodnie z modelem 5-warstwowym:

• Testy jednostkowe i komponentów są uruchamiane w systemie ciągłej integracji w przypadku każdego nowego zatwierdzenia, ale tylko w przypadku modułów, których dotyczy zmiana.
• Wszystkie testy jednostkowe, komponentów i funkcji są przeprowadzane przed scaleniem lub przesłaniem zmiany.
• Testy aplikacji są przeprowadzane po scaleniu.
• Testy Release Candidate są przeprowadzane codziennie w nocy na telefonie, urządzeniu składanym i tablecie.
• Przed wydaniem wersji Release Candidate testy są przeprowadzane na dużej liczbie urządzeń.

Te zasady mogą się zmieniać z czasem, gdy liczba testów wpływa na produktywność. Jeśli na przykład przeniesiesz testy do harmonogramu nocnego, możesz skrócić czas kompilacji CI i testów, ale możesz też wydłużyć pętlę opinii.