Testowanie backendu aplikacji internetowej to kluczowy element procesu programowania i całości monitorowania. Zobacz też testowanie frontendu.
Programowanie oparte na testach
W programowaniu opartym na testowaniu wymagania dotyczące aplikacji są przekładane na przypadki testowe przed ich pełnym wdrożeniem. Testy te są pisane najpierw, a potem wdrażane w miarę tworzenia aplikacji. Jasne wymagania (np. przypadki testowe) gwarantują, że ostateczny kod będzie mieć odpowiednią strukturę, spełnia wszystkie wymagania i jest poprawny, co jest szczególnie ważne na wczesnych etapach programowania.
Tryb ciągłej integracji i testy automatyczne
Testy ciągłej integracji (CI) automatycznie przeprowadzają testy w przypadku wszelkich zmian w kodzie, na przykład podczas sprawdzania kodu lub po scaleniu kodu z Twoim repozytorium kodu. Zautomatyzowane testy poprawiają ogólną jakość i wiarygodność przesyłanego kodu, zmniejszając ryzyko awarii lub regresji w trakcie programowania. Zalecamy skonfigurowanie automatycznego systemu testowania w środowisku, który pozwoli kontrolować stan aplikacji. Używaj systemu obsługiwanego przez Twoją architekturę, platformę i język oraz płynnie zintegrowany z potokiem programowania. Możesz na przykład używać działań GitHub dla przepływu pracy CI lub niestandardowego potoku CI wbudowanego w chmurę dostosowanego do Twojej konfiguracji.
Dowiedz się więcej o zasadach testowania automatycznego i o tym, jak ulepszyć testy. Dowiedz się więcej o testowaniu ciągłej integracji oraz o sprawdzonych metodach wdrażania, konfigurowania i mierzenia skuteczności.
W kolejnym kroku rozważ zastosowanie automatycznego potoku ciągłego dostarczania (CD), który umożliwia automatyczne wdrażanie zmian i aktualizacji w aplikacji.
Testowanie jednostkowe
Testowanie jednostkowe oznacza testowanie w izolacji małych, samodzielnych części kodu. Użyj platformy testowania jednostkowego, która jest zalecana i popularna w przypadku Twojego języka lub platformy backendu. Na przykład w przypadku monolitycznej aplikacji opartej na Javie użyj JUnit lub aplikacji bezserwerowej opartej na języku JavaScript (w tym Dart lub TypeScript) i użyj platformy do testowania JavaScriptu, takiej jak Jest.
Większość nowoczesnych platform backendu ma dedykowane zasoby do testowania. Rozważ integrację tych funkcji z potokiem CI, aby zautomatyzować testowanie. Upewnij się, że testy jednostkowe zapewniają dobre pokrycie kodu aplikacji. Większość platform do testowania zawiera funkcje umożliwiające analizowanie i raportowanie zasięgu testów oraz umożliwia integrację z potokiem kompilacji.
Testowanie integracji
Testowanie integracji oznacza testowanie większych modułów lub części aplikacji razem. W odróżnieniu od testowania jednostkowego (skupiającego się na poszczególnych częściach kodu) testowanie integracji koncentruje się na integracji poszczególnych części architektury. Może to też obejmować kompleksowe procesy obejmujące wiele kroków i modułów w aplikacji.
Testy integracji mogą obejmować różne moduły aplikacji, które mogą wymagać interakcji z usługami zewnętrznymi, np. pamięcią danych, systemami plików czy płatnościami. Rozważ taką strukturę aplikacji, aby obsługiwała abstrakcje tych usług przez wstrzykiwanie zależności lub podobne funkcje udostępniane przez platformę backendu.
Testy behawioralne i funkcyjne
Gdy patrzysz na backend (lub poszczególne moduły bądź komponenty) jako nieprzezroczyste pole, testy działania skupiają się na danych wejściowych i wyjściowych systemu. Testowanie behawioralne może być częstsze w przypadku frontendu, ale odgrywa też kluczową rolę w potwierdzaniu pełnej integralności systemu backendu. Tego typu testy potwierdzają, że system reaguje i działa zgodnie z oczekiwaniami na różne dane wejściowe.
Testowanie regresji
Testy regresji to testy, które potwierdzają, że aplikacja nadal działa zgodnie z oczekiwaniami. Wcześniejsze testy są kontynuowane w przypadku wszelkich nowych zmian, aby upewnić się, że zmiany nie spowodowały wprowadzenia zmian z powodu poprzednich problemów. Po naprawieniu błędów w aplikacji należy dodawać testy jednostkowe lub integracyjne, aby błąd się nie powtarzał. Testy regresji należy zintegrować ze zwykłymi testami i tworzyć potok.
Testy dymne
Testy dymne, nazywane też testowaniem weryfikacji kompilacji, koncentrują się na weryfikacji najważniejszych funkcji aplikacji backendu. Testy dymne obejmują krytyczne przypadki użycia aplikacji, wykraczające poza testowanie integracji, które obejmuje niektóre funkcje i zależności zewnętrzne. Testy dymne mogą stanowić dodatkową warstwę weryfikacji przed awansowaniem aplikacji do środowiska testowego, aby zapewnić dokładne działanie. Testy dymne mogą składać się z automatycznych testów jednostkowych lub ręcznych testów funkcjonalnych prowadzonych przez zespół kontroli jakości.
Środowiska produkcyjne i przejściowe
Środowisko testowe to kopia środowiska produkcyjnego, umieszczona w piaskownicy, aby ułatwić testowanie. Specjalne wdrożenie zmniejsza ryzyko problemów w środowisku produkcyjnym i ułatwia przeprowadzanie kontroli jakości. Środowisko testowe umożliwia przetestowanie systemu w pobliżu aktywnego środowiska produkcyjnego.
Utworzenie kopii środowiska produkcyjnego typu „1:1” może być niemożliwe ze względu na takie czynniki jak koszt czy złożoność architektury backendu. Zastanów się, które części backendu są najważniejsze, i zoptymalizuj je pod kątem środowiska testowego.
Testowanie z wykorzystaniem danych używanych w środowisku produkcyjnym daje ogromne korzyści przy sprawdzaniu, jak aplikacja zachowuje się na podstawie rzeczywistych danych. Uwzględnij kwestie związane z ochroną prywatności i zapotrzebowaniem na miejsce na dane w takim środowisku testowym. Starannie zaprojektuj dane używane przez system backendu. Dostęp do takiego środowiska należy kontrolować, zwłaszcza jeśli używane są dane produkcyjne.
Weź pod uwagę skalę swojego systemu i zastanów się, czy miejsce, w którym stoi Twoja aplikacja, jest odpowiednie dla Twojej aplikacji. Środowiska przejściowe, które można wdrażać automatycznie za pomocą systemu ciągłego dostarczania, dają też dodatkowe możliwości testowania codziennych lub cotygodniowych kompilacji i dokładniej je sprawdzają przed opublikowaniem.
Innym sposobem jest w większym stopniu poleganie na testach ciągłej integracji i automatycznych systemach, a nie na w pełni wdrożonym środowisku przejściowym. Weź pod uwagę przepływ pracy zespołu, stan systemu, zasięg kodu i wymagania techniczne.