Jak używać Checksum do ciągłego testowania E2E w CI/CD

Uruchamianie testów kompleksowych (E2E) w środowisku CI/CD działa tylko wtedy, gdy zestaw testów może rozwijać się wraz z aplikacją. W miarę zmian w produkcie ręczne tworzenie nowych testów i naprawianie tych, które przestały działać, może szybko stać się wąskim gardłem spowalniającym każde wydanie.

Checksum został zaprojektowany tak, aby zautomatyzować znaczną część tego procesu. 

W tym przewodniku pokażemy, jak połączyć Checksum ze swoim środowiskiem i repozytorium, generować i uruchamiać testy Playwright w potoku CI/CD oraz włączyć autonomiczne utrzymanie testów w miarę rozwoju aplikacji.

Jak Checksum wspiera ciągłe testowanie E2E

Checksum obsługuje ciągłe testowanie E2E za pomocą ciągłego przepływu pracy:

1. Konfiguracja: Łączy repozytorium ze środowiskiem testowym.
2. Wykrywanie: Analizuje aplikację i identyfikuje najważniejsze przepływy użytkownika do przetestowania.
3. Generowanie: Tworzy gotowe do użycia w środowisku produkcyjnym testy Playwright i dostarcza je do repozytorium w formie żądań scalenia.
4. Uruchamianie: Wykonuje te testy lokalnie lub w potoku CI/CD, a mechanizm automatycznego odzyskiwania próbuje rozwiązać tymczasowe błędy podczas wykonywania.
5. Naprawianie: Aktualizuje uszkodzone testy Playwright po zmianach w aplikacji i otwiera żądanie scalenia z proponowaną poprawką.
6. Monitorowanie: Śledzi stan testów i powiadamia zespół, gdy problemy wymagają uwagi.

Ponieważ każdy test jest standardowym kodem Playwright, zachowujesz pełną kontrolę i możesz uruchamiać zestaw testów z użyciem Checksum lub bez niego.

Wymagania wstępne dotyczące ciągłego testowania E2E w Checksum

Przed skonfigurowaniem Checksum do ciągłego testowania E2E upewnij się, że poniższe elementy są gotowe.

Środowisko testowe lub podobne do produkcyjnego

Checksum testuje działającą aplikację, dlatego potrzebujesz dostępnego środowiska testowego lub podobnego do produkcyjnego z adresem środowiska. Jeśli aplikacja wymaga uwierzytelniania, skonfiguruj adres logowania i podaj dane uwierzytelniające użytkownika testowego, których Checksum może użyć do zalogowania się i przeanalizowania przepływów użytkownika w aplikacji.

Połączone repozytorium i potok CI

Połącz repozytorium GitHub lub GitLab, aby Checksum mógł przeanalizować bazę kodu i tworzyć żądania scalenia zawierające wygenerowane lub zaktualizowane testy Playwright. Jeśli testy znajdują się w osobnym repozytorium, połączenie zarówno repozytorium źródłowego, jak i repozytorium testów zwiększa dokładność wykrywania przepływów.

Będziesz również potrzebować platformy CI do uruchamiania testów. Checksum zapewnia wbudowaną obsługę GitHub Actions i GitLab CI/CD, natomiast inne platformy CI można zintegrować za pomocą interfejsu wiersza poleceń Checksum lub publicznego interfejsu API.

Projekt Checksum i klucz API

Utwórz projekt Checksum w aplikacji internetowej i wygeneruj klucz API projektu w sekcji Ustawienia projektu. Klucz API uwierzytelnia interfejs wiersza poleceń Checksum i umożliwia potokowi CI pobranie zmiennych środowiskowych wymaganych do uruchomienia testów.

Jeśli chcesz dokładniej zapoznać się z początkowym procesem konfiguracji, możesz również odwiedzić stronę Checksum „Pierwsze kroki”.

Jak przeprowadzać ciągłe testowanie E2E w Checksum

Poniższe kroki zakładają, że utworzyłeś projekt Checksum i masz pod ręką klucz API.

Krok 1. Połącz środowisko i repozytorium

W kreatorze konfiguracji aplikacji internetowej ustaw adres środowiska (np. https://staging.myapp.com) i adres logowania, a następnie dodaj dane uwierzytelniające użytkownika testowego, których Checksum użyje do uwierzytelnienia. 

Następnie zainstaluj aplikację Git dla GitHub lub GitLab, aby Checksum mógł odczytywać kod i otwierać żądania scalenia. Jeśli testy będą znajdować się razem z kodem źródłowym, połącz to samo repozytorium w obu celach.

Krok 2. Zainicjalizuj repozytorium testów

Utwórz (lub wyznacz) repozytorium dla swoich testów i zainicjuj je za pomocą interfejsu wiersza poleceń:

mkdir my-checksum-tests && cd my-checksum-tests

npm init -y

npm install @checksum-ai/runtime playwright

npx checksumai init

Spowoduje to utworzenie folderu checksum/ z konfiguracją, konfiguracją Playwrighta i przykładowym testem. Zanim przejdziesz dalej, sprawdź poprawność konfiguracji:

npm install

npx playwright install --with-deps

npx checksumai dotenv --download --api-key=<YOUR_API_KEY>

npx checksumai test -g "example"

Przykładowy test potwierdza, że logowanie działa w Twoim środowisku. Zielony wynik oznacza, że możesz rozpocząć wykrywanie rzeczywistych przepływów.

Krok 3. Pozwól agentowi wykryć krytyczne przepływy użytkownika

Uruchom sesję wykrywania i pozwól agentowi E2E przeanalizować aplikację w celu zidentyfikowania ważnych przepływów użytkownika. Po zakończeniu wykrywania przejrzyj zaproponowane przepływy i nadaj priorytet tym, które są najbardziej istotne dla Twojego wydania, zanim wygenerujesz testy.

Krok 4. Wygeneruj gotowe do użycia w środowisku produkcyjnym testy Playwrighta

Wygeneruj testy Playwrighta dla wybranych przepływów. 

Agent planuje, implementuje, przegląda i weryfikuje każdy test, zanim otworzy żądanie ściągnięcia zawierające czytelny dla człowieka plik z opisem oraz test Playwrighta. 

Przejrzyj żądanie ściągnięcia tak jak każdą inną zmianę w kodzie, a następnie scal testy, które chcesz dodać do swojego zestawu.

Krok 5. Podłącz testy do potoku CI/CD

W przypadku GitHub Actions przechowuj klucz API i wartości środowiskowe jako sekrety repozytorium, a następnie dodaj przepływ pracy, który zainstaluje Playwrighta, pobierze plik środowiskowy Checksum i uruchomi zestaw testów:

name: Uruchamianie testów Checksum
on:
  workflow_dispatch:        # ręczne wyzwolenie uruchomienia
  # schedule:
  #   - cron: '0 0 * * *'   # co noc, po weryfikacji
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Instalowanie zależności npm
        run: npm install
      - name: Instalowanie Playwrighta wraz z zależnościami
        run: npx playwright install --with-deps
      - name: Pobieranie pliku .env z Checksum
        run: npx checksumai dotenv --download --api-key="${{ secrets.CHECKSUM_API_KEY }}"
      - name: Uruchamianie testów Checksum
        run: npx checksumai test
        env:
          CHECKSUM_API_KEY: ${{ secrets.CHECKSUM_API_KEY }}
          USERNAME: ${{ secrets.USERNAME }}
          PASSWORD: ${{ secrets.PASSWORD }}
          LOGIN_URL: ${{ secrets.LOGIN_URL }}
          BASE_URL: ${{ secrets.BASE_URL }}
          CI: true

GitLab CI/CD ma taki sam schemat w pliku .gitlab-ci.yml. Zacznij od ręcznego wyzwalacza (workflow_dispatch / when: manual), aby potwierdzić poprawność uruchomienia, a następnie przejdź do harmonogramu nocnych kontroli poprawności działania lub wyzwalacza scalania, aby przeprowadzać weryfikację po wdrożeniach.

Krok 6. Dodaj uruchomienia dla każdego żądania ściągnięcia i włącz autonomiczne naprawianie

Jeśli chcesz, aby Checksum uruchamiał testy dla każdego żądania ściągnięcia, użyj oficjalnej akcji GitHub zamiast samodzielnie uruchamiać interfejs wiersza poleceń na własnym wykonawcy. Jest to przydatne do weryfikowania zmian wprowadzonych w każdym żądaniu ściągnięcia.

name: Testy Checksum
on: pull_request
permissions:
  contents: read
  pull-requests: read
jobs:
  checksum:
    runs-on: ubuntu-latest
    steps:
      - uses: checksum-ai/test-run-action@v1
        with:
          api-key: ${{ secrets.CHECKSUM_API_KEY }}
          grep: 'checkout'
          auto-heal: true

Opcja grep filtruje uruchamiane testy według nazwy, natomiast auto-heal: true włącza automatyczne naprawianie w przypadku niepowodzenia testu. 

Domyślnie przepływ pracy kończy działanie po zaakceptowaniu uruchomienia i publikuje wyniki jako komentarz w żądaniu ściągnięcia. Jeśli chcesz, aby przepływ pracy oczekiwał na ostateczny wynik i odpowiednio kończył się powodzeniem lub niepowodzeniem, ustaw wait: true.

Przy włączonej funkcji automatycznego naprawiania Checksum podejmuje próbę odzyskania działania w czasie rzeczywistym podczas uruchomienia testu. Jeśli test nadal zakończy się niepowodzeniem, aktualizuje test Playwright, otwiera żądanie pull request z proponowaną poprawką i publikuje postęp jako komentarz w oryginalnym żądaniu pull request. 

Twój zespół może następnie przejrzeć i scalić zmiany tak jak każdy inny wkład w kod.

Jak wygląda skuteczne ciągłe testowanie E2E

Po zintegrowaniu Checksum z potokiem CI/CD powinny być widoczne następujące elementy:

• Twój zestaw testów E2E uruchamia się automatycznie na podstawie skonfigurowanego wyzwalacza, w tym żądań pull request, zaplanowanych uruchomień i wdrożeń.
• Nowe przepływy użytkownika są wykrywane i konwertowane na testy Playwright bez konieczności ręcznego tworzenia każdego testu.
• Niepowodzenia testów spowodowane zmianami w aplikacji są rozwiązywane za pomocą automatycznego odzyskiwania lub automatycznego naprawiania, zanim konieczne będą ręczne aktualizacje.
• Twój zespół poświęca mniej czasu na utrzymywanie testów Playwright, a więcej na przeglądanie istotnych zmian w testach dostarczanych za pośrednictwem żądań pull request.

Aby mierzyć kondycję implementacji, monitoruj współczynnik pomyślnie zakończonych testów, odsetek testów naprawionych automatycznie, średni czas rozwiązywania niepowodzeń testów oraz współczynnik fałszywie dodatnich wyników. 

Te dane pomagają zrozumieć, jak niezawodnie działa zestaw testów E2E w miarę rozwoju aplikacji. Aby porównać swoje wyniki z punktami odniesienia dla środowisk produkcyjnych, Raport porównawczy QA Checksum zawiera dane dotyczące tych wskaźników na podstawie ponad 1 mln rzeczywistych uruchomień produkcyjnych.

Typowe błędy w ciągłym testowaniu E2E i porady ekspertów

Nawet przy odpowiedniej konfiguracji kilka typowych błędów może negatywnie wpłynąć na jakość, wykonywanie i utrzymanie testów. Oto kwestie, na które należy zwrócić uwagę, oraz sposoby ich unikania.

Uruchamianie testów w niestabilnym środowisku

Jeśli wyniki testów są niespójne lub testy kończą się niepowodzeniem, zanim rozpocznie się właściwe wykonywanie testu, środowisko testowe może nie być gotowe. Upewnij się, że środowisko pomostowe lub środowisko podobne do produkcyjnego jest stabilne, dane uwierzytelniające użytkownika testowego działają prawidłowo oraz że przykładowy test przechodzi pomyślnie przed wygenerowaniem dodatkowego pokrycia.

Generowanie zbyt wielu przepływów użytkownika

Checksum może początkowo zidentyfikować więcej przepływów użytkownika, niż potrzebujesz. Generowanie testów dla każdego kandydata wydłuża czas wykonywania i zwiększa nakład pracy związany z przeglądem. Zacznij od przepływów pracy o największym znaczeniu dla wydań, a następnie z czasem rozszerzaj pokrycie.

Scalanie wygenerowanych testów bez przeglądu

Wygenerowane i naprawione testy są dostarczane jako żądania pull request, dzięki czemu Twój zespół może zweryfikować każdą zmianę, zanim stanie się ona częścią zestawu testów. Na wczesnych etapach wdrażania dokładnie przeglądaj nowe testy i z czasem buduj zaufanie do procesu generowania.

Zbyt wczesna automatyzacja potoku

Przed zaplanowaniem uruchomień lub wyzwalaniem testów dla każdego żądania pull request potwierdź, że potok działa stabilnie podczas ręcznych uruchomień. Gdy zaczniesz regularnie uzyskiwać niezawodne wyniki, możesz z większą pewnością zautomatyzować przepływ pracy.

Blokowanie każdego żądania pull request

Włączenie opcji wait: true powoduje, że przepływ pracy czeka na zakończenie uruchomienia testów przed ukończeniem. Używaj jej tylko w przepływach pracy, które muszą blokować scalanie. We wszystkich pozostałych przypadkach domyślny komentarz w żądaniu pull request przekazuje informacje zwrotne bez zajmowania wykonawców CI.

Podsumowanie

Wiesz już, jak Checksum wpisuje się w ciągły przepływ pracy testowania E2E — od połączenia środowiska i repozytorium, przez generowanie testów Playwright i zintegrowanie ich z potokiem CI/CD, po włączenie autonomicznego utrzymania. 

W miarę rozwoju aplikacji Checksum pomaga utrzymać niezawodność zestawu testów E2E bez konieczności zwiększania zakresu ręcznego utrzymania.

Jeśli chcesz dokładniej poznać platformę, możesz przeczytać naszą szczegółową recenzję Checksum, aby dowiedzieć się więcej o jej możliwościach, lub sprawdzić, jak Checksum działa z Twoją aplikacją, łącząc się bezpośrednio z ich zespołem.