Jak testować aplikacje internetowe

w branży oprogramowania każdy w jakiś sposób testuje swoje aplikacje. Wiele zespołów programistów ma rozbudowane Schematy testowania, które są dobrze zintegrowane z potokami ciągłej integracji, ale nawet ci, którzy nie mają automatycznych testów, nadal muszą wymyślić sposoby sprawdzenia, czy ich kod działa zgodnie z przeznaczeniem.

budowanie strony internetowej i klikanie przez nią ręcznie za pomocą przeglądarki to wiele testów. Choć nie jest to najbardziej wyrafinowany, to jednak się liczy. To samo dotyczy uruchamiania cURL w konsoli i wysyłania syntetycznego żądania do utworzonego właśnie punktu końcowego API.

w tym poście omówimy, jak zautomatyzować ręczne testy, które wykonujemy już przed przejściem do różnych typów testów i metodologii.

automatyzacja testów

testy ręczne są wystarczające dla małych aplikacji, ale gdy te aplikacje rosną, ich powierzchnia do testowania rośnie wraz z nimi, powodując dwa problemy.

po pierwsze, gdy ludzie muszą przeprowadzać testy za każdym razem, gdy nowa wersja aplikacji jest zakończona, mogą pojawić się niespójności. Jest to szczególnie prawdziwe, jeśli istnieje wiele testów. Po drugie, osoba wykonująca testy nie może wykonywać innych zadań. W przypadku dużych aplikacji testowanie może potrwać kilka dni.

najbardziej logicznym sposobem rozwiązania tych dwóch problemów jest automatyzacja tych ręcznych zadań. Istnieją dwa główne typy testów dla aplikacji internetowych: testy interfejsu użytkownika i testy API. Dwa narzędzia mogą je zautomatyzować.

testy UI

testy UI mogą być wykonywane za pomocą narzędzia o nazwie Puppeteer. Puppeteer pozwala na automatyzację ręcznego testu UI przy użyciu JavaScript. Jest instalowany przez NPM za pomocą następującego polecenia:

 $ npm i puppeteer

następnie możesz napisać skrypt, który steruje bezgłową wersją Chrome, aby uruchomić testy. Ten skrypt może wyglądać następująco:

(async () => { const browser = await puppeteer.launch(); const page = await browser.newPage(); await page.goto('https://google.com', {waitUntil: 'networkidle2'}); const heading = await page.$('h1'); await browser.close(); if(!heading) console.log('No heading found!');})();

w tym skrypcie uruchamiamy bezgłowy przykład Chrome ‘ a, przechodząc do example.com, i szukam pierwiastka h1. Jeśli nie istnieje, rejestrowany jest komunikat o błędzie.

testy API

testy API mogą być zautomatyzowane przez listonosza. Postman jest wyposażony w graficzny interfejs do budowania żądań HTTP, które można zapisać. Żądania te można wykonać później jednym kliknięciem myszy.

aby rozpocząć, Pobierz i zainstaluj interfejs użytkownika listonosza. Aby utworzyć i zapisać żądanie, należy wykonać następujące kroki:

1. kliknij Utwórz kolekcję po lewej stronie
2. wpisz moją kolekcję jako nazwę kolekcji
3. kliknij Utwórz
4. kliknij elipsę (…) mojej kolekcji po lewej stronie
5. wybierz Dodaj zapytanie
6. wpisz moją prośbę jako nazwę zapytania
7. kliknij Zapisz do mojej kolekcji

żądanie pojawia się na lewym pasku bocznym pod nowo utworzoną kolekcją.

jeśli go wybierzesz, będziesz musiał wprowadzić example.com jako URL i Dodaj test. Aby dodać test, kliknij Tests na pasku kart Pod polem wprowadzania adresu URL.

pojawi się obszar tekstowy, w którym możesz napisać test w języku JavaScript. Poniżej znajduje się przykład testu:

pm.test("Status code is 200", () => { pm.response.to.have.status(200);});

jeśli klikniesz Zapisz w prawym górnym rogu ekranu i wyślesz zaraz po nim, twoje żądanie zostanie wysłane. Następnie zostanie uruchomiony skrypt testowy, aby określić, czy odpowiedź miała status 200.

rodzaje testów

istnieją trzy różne rodzaje testów. Zrozumienie ich umożliwia wybór odpowiedniego rodzaju testów dla różnych części stosu oprogramowania.

testy jednostkowe

testy jednostkowe są najprostszym rodzajem testu. Sprawdzają poprawność małych części kodu. Test jednostkowy zazwyczaj obejmuje jedno wywołanie funkcji lub jeden sposób użycia klasy.

test jednostkowy jest zwykle pierwszym “użytkownikiem” Twojego kodu. Niektóre metody testowe wymagają nawet napisania testu przed wdrożeniem rzeczywistego kodu aplikacji.

testy jednostkowe mogą być używane zarówno w rozwoju backendu, jak i frontendu. Niektóre zespoły programistyczne używają testów jednostkowych do sprawdzania renderowanego wyjścia DOM małych części kodu, takich jak formularze lub menu. W backendzie testy jednostkowe są często używane do testowania kodu między serwerem HTTP a bazą danych lub innymi interfejsami API.

trzy powszechnie używane biegacze testowe do testów jednostkowych to:

‐ Jest—Jest najczęściej używany w rozwoju frontendu, ponieważ ma unikalne funkcje, takie jak testowanie migawek, które pomagają w problemach, takich jak regresje interfejsu użytkownika. Tutorial Jest można znaleźć tutaj.

‐ AVA—AVA jest preferowana w rozwoju backendu, ponieważ specjalizuje się w wysoce równoległym wykonywaniu testów. Tutorial AVA można znaleźć tutaj.

‐ PHPUnit—PHPUnit jest popularnym frameworkiem do testów jednostkowych w PHP. Tutorial PHPUnit można znaleźć tutaj.

jeśli test jednostkowy wymaga pewnych zewnętrznych zasobów, takich jak Połączenia sieciowe lub bazy danych, prawdopodobnie piszesz test integracyjny. Ten rodzaj testu jest objęty następnym.

testy integracyjne

z punktu widzenia implementacji testy integracyjne wyglądają jak testy jednostkowe. Różnica polega na tym, że testy integracyjne testują wiele części stosu razem. Na przykład mogą sprawdzić, czy klient i serwer używają tego samego protokołu lub, w architekturze mikroserwisów, czy usługi działają poprawnie.

sprawdzenia, które zwykle kończą się w wielu niezależnych testach jednostkowych, można połączyć w jeden test integracyjny, który określa, czy wszystko działa dobrze razem.

testy integracyjne są używane zarówno w rozwoju frontendu, jak i backendu. Są one czasami używane do sprawdzania, czy obie części współdziałają prawidłowo, ale mogą być również używane do określenia, czy różne moduły jednej części współpracują ze sobą zgodnie z przeznaczeniem.

możesz używać tych samych biegaczy testowych do testów integracyjnych, których używałeś do testów jednostkowych. Jednak Postman, narzędzie UI użyte powyżej do automatyzacji ręcznych testów API, jest również wyposażone w narzędzie CLI o nazwie Newman, które można zintegrować z potokiem CI / CD.

Newman może uruchamiać wyeksportowane Kolekcje listonosza, co pozwala na tworzenie żądań i testów za pomocą interfejsu listonosza i uruchamianie ich później przez CLI. Tutorial Newmana można znaleźć tutaj.

jeśli test integracji wymaga interakcji z interfejsem użytkownika, nazywa się to testem interfejsu użytkownika-adresowany dalej.

testy UI

testy UI to najbardziej zaawansowane testy. Starają się emulować zachowanie użytkownika w sposób zautomatyzowany, aby testerzy nie musieli ręcznie klikać każdej części aplikacji.

testy UI często pomagają uchwycić określoną interakcję, która doprowadziła do błędu użytkownika. Po przechwyceniu można go odtworzyć za pomocą jednego kliknięcia, aby naprawić błąd i zapobiec jego ponownemu pojawieniu się w nowej wersji.

tutaj można korzystać z wymienionych wcześniej biegaczy testowych Jest i AVA, ale zwykle potrzebujesz dodatkowej biblioteki, aby ułatwić interakcję z interfejsem użytkownika za pośrednictwem przeglądarki. Dwie główne biblioteki obecnie używane do tego procesu to:

‐ Puppeteer—Puppeteer jest biblioteką JavaScript, która pochodzi z implementacją Chrome bez głowy, która umożliwia uruchamianie testów interfejsu użytkownika programowo w tle. Tutorial lalkarza można znaleźć tutaj.

‐ Selenium—Selenium to framework, który umożliwia zdalne sterowanie przeglądarką za pośrednictwem biblioteki o nazwie WebDriver. Samouczek Selenium można znaleźć tutaj.

istnieje więcej rodzajów testów niż te wymienione tutaj. Inne mogą mieć różne cele; na przykład testy obciążenia próbują znaleźć wąskie gardła wydajności. Należy pamiętać, że opisane tutaj testy mają czasami różne nazwy. Trzy typy przedstawione powyżej są niezbędne do wdrożenia na początku. Korzystanie z jednego z nich jest lepsze niż korzystanie z żadnego automatycznego testowania.

metody testowania

metody testowania to sposoby myślenia o testowaniu. Trzy opisane poniżej są najczęściej stosowanymi.

Test Driven Development (TDD)

TDD jest najczęściej stosowaną metodologią i najbardziej techniczną. Zaleca napisanie testów przed napisaniem kodu, który chcesz przetestować. Ponieważ musisz napisać test tylko dla części kodu, którą implementujesz, typ testu, który napiszesz, jest testem jednostkowym.

testy jednostkowe są raczej ziarniste, więc z czasem zastosowanie tej metodologii skutkuje akumulacją wielu testów. Ta rzeczywistość, w połączeniu z faktem, że początkujący praktykujący TDD mają tendencję do pisania trywialnych testów, może prowadzić do stworzenia stosu bezużytecznych testów. Aby tego uniknąć, ważne jest, aby aktualizować i czyścić testy, gdy zespół lepiej zaznajomi się z TDD i ogólnie z testami.

ważne jest, aby często uruchamiać testy, nie tylko w potoku CI/CD, ale także lokalnie na maszynie programistycznej. Napisz test, uruchom go, zobacz, że nie, zaimplementuj tyle, aby test przeszedł i powtórz proces.

aby dowiedzieć się więcej, sprawdź opis TDD Agile Alliance.

Acceptance Test Driven Development (ATDD)

ATDD jest modyfikacją TDD, która koncentruje się bardziej na przypadkach biznesowych, a mniej na wdrożeniu technicznym. Typy testów, które są używane w tej metodologii są głównie testy integracyjne, ponieważ, często, wiele części systemu muszą być używane w połączeniu w celu rozwiązania potrzeby biznesowej.

ponieważ testy są mniej techniczne, wskazane jest również włączenie do procesu testowania osób nie zorientowanych technicznie. Właściciele produktów i klienci mogą pomóc w zdefiniowaniu przypadków biznesowych, aby programista mógł napisać dla nich test. Jeśli test nie może zostać pomyślnie uruchomiony, oczywiste jest, że należy zaimplementować więcej funkcji.

ATDD działa na innym poziomie abstrakcji niż TDD, więc obie metody mogą być używane razem.

aby dowiedzieć się więcej, sprawdź opis TDD Agile Alliance.

Behavior Driven Development (BDD)

BDD jest mieszanką TDD i ATDD, a jego celem jest wykorzystanie najlepszych z obu światów, aby ogólny system był bardziej stabilny. BDD próbuje określić system z testami ilustrującymi jego użycie.

podobnie jak ATDD, BDD próbuje uchwycić przypadki biznesowe. Jednak wymaga to również kwestionowania tych przypadków użycia za pomocą “5 whys”, ponieważ “whys” są brakującą częścią ATDD. Jasne, lepiej zapytać klientów, czego chcą, zamiast polegać wyłącznie na wkładzie programistów. Ale ważne jest również kwestionowanie założeń obu tych grup.

BDD jest również mieszanką TDD i ATDD w sensie poziomów abstrakcji. TDD testuje tylko małe części aplikacji, a ATDD testuje tylko to, jak te części współpracują ze sobą. BDD wymaga od Ciebie zastosowania tej metodologii do dużej całości Twojej aplikacji i jej małych części, dzięki czemu BDD jest bardziej holistycznym podejściem do testowania.

więcej informacji znajdziesz w opisie Agile Alliance BDD.

wniosek

chociaż żadne testowanie nie jest straszne, testowanie ręczne jest lepsze, a testowanie automatyczne jest najlepsze.

w zależności od wielkości aplikacji, test ręczny może zablokować członkom zespołu programistów pracę nad innymi projektami przez kilka dni, a nawet tygodni, co kosztuje czas i pieniądze Twojej firmy. Ponadto monotonne zadanie wykonywania tych samych interakcji w kółko może prowadzić do poślizgów, które często przejawiają się w nieuważnych błędach.

komputery są bardzo dobre w powtarzaniu tego samego zadania w kółko, więc dobrym pomysłem jest delegowanie testów na skrypt i zwolnienie czasu programistów. Jeśli te testy są zintegrowane z potokiem CI / CD, już napisane testy mogą działać domyślnie, gdy nowy commit wyląduje w Twoich repozytoriach.

dobrym pomysłem jest wczesne zastosowanie metodologii testowania, ponieważ często dużymi problemami na początku są “co” i “kiedy” przetestować. Metody te mogą pomóc w wyjaśnieniu procesu, który sprawia, że pisanie testów jest bardziej spójne dla wszystkich członków zespołu.