Zyski:
- Możliwość tworzenia solidnego kodu testowego interfejsu użytkownika przy użyciu sztucznej inteligencji, w tym testowania danych, otwierania oczekiwania i potwierdzania, które weryfikują rzeczywisty wynik użytkownika
- Możliwość uniknięcia delikatnych testów (zły selektor, ślepe oczekiwanie) i ułatwienie utrzymania testów w strukturze Modelu Obiektowego Strony
- Możliwość testowania każdego testu interfejsu użytkownika powstałego poprzez złamanie kodu oraz wykrycia i naprawienia testów, które zostały fałszywie zaliczone
Każde kliknięcie, każde wypełnienie formularza, każde przejście strony dokonane przez użytkownika w przeglądarce nie może być wielokrotnie testowane ręcznie — dlatego istnieje automatyzacja testów interfejsu użytkownika (interfejs użytkownika; testy te naśladują zachowanie użytkownika poprzez programowe sterowanie prawdziwą przeglądarką). Selenium, Playwright i Cypress to najczęstsze narzędzia do tej pracy. Sztuczna inteligencja (AI) ma duże umiejętności w pisaniu kodu dla tych narzędzi: opisujesz przypadek testowy, sztuczna inteligencja daje ci wersję roboczą wykonalnego skryptu automatyzacji. Ale tutaj ponownie pojawia się główne ostrzeżenie tego modułu: kod testowy interfejsu użytkownika generowany przez sztuczną inteligencję często może być delikatnymi testami, które „świecą na zielono, ale weryfikują niewłaściwą rzecz” lub trzepoczą na wietrze. Twoim zadaniem nie jest uruchomienie tego kodu, ale upewnienie się, że faktycznie weryfikuje on właściwą rzecz.
W tej jednostce staramy się tworzyć solidne, łatwe w utrzymaniu i naprawdę sprawdzające testy interfejsu użytkownika z wykorzystaniem sztucznej inteligencji; Nauczysz się unikać delikatnych testów.
Trzy filary solidnego testowania interfejsu użytkownika
1. Prawidłowy lokalizator elementów. Test używa selektora, aby znaleźć element na stronie. Sztuczna inteligencja często tworzy kruche selektory: długie ścieżki XPath (adres nadmiernie zależny od struktury strony), selektory oparte na nazwach klas CSS (przerwanie przy zmianach projektu). Niezawodnym sposobem są stabilne atrybuty, takie jak data-testid, które programista dodał do testów. Wyraźnie nałóż to na sztuczną inteligencję.
2. Wyraźne oczekiwanie. Najważniejszym źródłem podatności w testowaniu interfejsu użytkownika jest czas. Ciągłe uśpienie(3) (czekanie na ślepo) jest złą praktyką: czasem to nie wystarczy, czasem marnuje czas. Poprawnym sposobem jest użycie jawnego oczekiwania, które mówi „poczekaj, aż pojawi się ten element”. Dramaturg robi to w dużej mierze automatycznie; W Selenium musisz wyraźnie o to poprosić.
3. Znaczące twierdzenie. Test powinien zweryfikować wynik, który faktycznie zobaczy użytkownik – np. „na ekranie pojawił się numer zamówienia”, a nie tylko „załadowanie strony”. Jeżeli test opracowany przez sztuczną inteligencję nie zawiera twierdzenia lub jest nieistotny, test ten daje wynik pseudo-pozytywny (1. jednostka).
Uwaga: kiedy po raz pierwszy zobaczysz test interfejsu użytkownika wygenerowany przez sztuczną inteligencję, sprawdź co najwyżej trzy rzeczy: czy selektory zostały zatwierdzone (test-test), czy trwają oczekiwania (bez ślepego uśpienia) i czy asercja weryfikuje rzeczywisty wynik użytkownika? Jeśli te trzy są w porządku, test jest prawdopodobnie solidny.
Model obiektowy strony
W miarę jak testy stają się coraz większe, pisanie selektorów w każdym teście staje się koszmarem w utrzymaniu. Page Object Model (POM — wzorzec projektowy, który gromadzi selektory i akcje dla każdej strony/ekranu w jedną klasę) utrzymuje selektor w jednym miejscu; Kiedy interfejs się zmienia, aktualizujesz go w jednym pliku. Niech sztuczna inteligencja wyprodukuje testy w strukturze POM, a nie bezpośrednio; Dzięki temu konserwacja jest radykalnie łatwiejsza.
Słaba zachęta/silna zachęta
Słabe: „Napisz test Selenium dla strony logowania”.
Strong: „Napisz test przepływu logowania za pomocą Playwright (TypeScript). Selektory używają tylko data-testid; nie kontroluj tego, co widzi użytkownik, a nie tytułu strony”.
Potężny monit; Narzędzie podaje język, politykę selektora, strategię oczekiwania, architekturę (POM) i ekspresyjne potwierdzanie oczekiwań.
Testuj niezależność danych i środowiska
Solidny test interfejsu użytkownika jest nie tylko poprawnie napisany, ale także buduje i czyści własne dane testowe. Testy generowane przez sztuczną inteligencję często łączą się z użytkownikiem lub rekordem, który, jak się zakłada, już istnieje w środowisku („zaloguj się jako użytkownik administracyjny”). Założenie to załamuje się, gdy test jest uruchamiany w innym środowisku lub po innym teście (problem zależności kolejności w jednostce 9). Prawda jest taka, że każdy test tworzy potrzebne dane na początku testu (lub przygotowuje je za pomocą wywołania API) i czyści je na końcu. Wyraźnie poinstruuj sztuczną inteligencję, aby „ustawiła w ramach testu wszelkie dane, od których zależy ten test; nie zakładaj, że są to gotowe dane z zewnątrz”.
Kolejnym krytycznym punktem jest nie przeprowadzanie testów interfejsu użytkownika na prawdziwych danych użytkownika. Jeżeli w środowisku testowym używana jest produkcyjna kopia bazy danych, rekordy te są danymi prawdziwych osób; zrzuty ekranu i nagrania testowe mogą ujawnić te dane. Używaj syntetycznych (fikcyjnych) kont testowych; chroni to zarówno poufność, jak i sprawia, że testy są powtarzalne. Przeprowadzanie testu „anulowania zamówienia” przy użyciu prawdziwego konta klienta jest błędem zarówno etycznym, jak i operacyjnym.
Wskazówka: staraj się, aby testy interfejsu użytkownika były jak najmniejsze; Rzeczywistą weryfikację zostaw API i testom jednostkowym, które są szybkie i stabilne. Testowanie interfejsu użytkownika jest drogie i kruche — używaj go tylko do sprawdzania prawdziwie kompleksowego przepływu użytkowników (logika piramidy testowej).
Porównanie pojazdów
funkcja
selen
dramaturg
cyprys
języki
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/TypeScript
automatyczny tryb gotowości
Nie (ręcznie)
Tak (silny)
Tak
Wiele przeglądarek
szeroki
Chromium/Firefox/WebKit
Dominuje chrom
skłonność do kruchości
Wysoki (ręczny tryb czuwania)
niski
niski
Łatwość uczenia się
średni
łatwe
łatwe
praca równoległa
Wymagana siatka
wbudowany
Mieszkaniec/płatny
Prosząc o kod od AI, wyraźnie określ, do jakiego pojazdu należy; W przeciwnym razie może powstać mylący i niedziałający kod.
Cztery szablony do kopiowania
1) Generowanie testu Solid UI:
Twoja rola: starszy inżynier automatyzacji testów. Napisz testy za pomocą [narzędzie + język] dla następującego przepływu: [przepływ]. Reguły: - Selektory tylko data-testid; Korzystanie z klasy XPath/CSS. - Żadnego ślepego snu; Użyj jawnego/automatycznego oczekiwania. - Zastosuj model obiektowy strony. - Niech każde twierdzenie zweryfikuje rzeczywisty wynik użytkownika. Na początku każdego testu skomentuj kryteria akceptacji, które sprawdzasz.
2) Kontrola kruchości:
Sprawdź następujący test interfejsu użytkownika pod kątem kruchości: - Czy istnieje niestabilny selektor (long
3) Konwersja na obiekt strony:
Przekonwertuj następujący zwykły kod testowy na strukturę modelu obiektu strony. Przenieś selektory i akcje do klas stron; Pozwól, aby plik testowy odczytywał tylko przepływ scenariusza. [Narzędzie/język]. Kod: [wklej kod]
4) Dowód pseudoprzejścia:
Udowodnij, że ten test interfejsu użytkownika rzeczywiście sprawdza: jaką pojedynczą zmianę wprowadzę w kodzie aplikacji, która zmieni kolor tego testu na CZERWONY? Jeśli nie możesz znaleźć zmiany, która złamie test, oznacza to, że test jest nieodpowiedni; dodaj brakujące potwierdzenia.Test: [wklej test]
trzy mini etui
Przypadek 1 — Wyzwolenie od kruchego selektora. Z 40 testów opracowanych przez jeden zespół przy użyciu sztucznej inteligencji 70% zostało uszkodzonych po aktualizacji interfejsu; żaden z nich nie był rzeczywistym błędem, wszystkie były delikatnymi selektorami XPath. Zespół przekształcił testy w bazę danych z szablonem „kontroli kruchości”. W ciągu kolejnych trzech aktualizacji interfejsu liczba fałszywych awarii spadła do zera; czas konserwacji został skrócony z 6 godzin do 30 minut tygodniowo.
Przypadek 2 – Fałszywy test interfejsu użytkownika. AI przeprowadziła test „dodaj do koszyka”; test był zielony. Po uruchomieniu szablonu „fałszywego potwierdzenia przejścia” test sprawdzał jedynie kliknięcie przycisku i tytuł strony, nigdy nie sprawdzając, czy licznik koszyka wzrósł, czy nie. Nawet jeśli logika wózka została całkowicie zepsuta, test przeszedł pomyślnie. Dodano prawdziwe potwierdzenie (znaczek koszyka to „1”).
Przypadek 3 – Ślepa pułapka czekania. W teście Selenium wykonanym przez sztuczną inteligencję po każdym kroku następował sen(2); 60 testów trwało 14 minut i nadal czasami się psuło. Po przejściu na tryb open wait (czekaj, aż element będzie klikalny) czas spadł do 5 minut, a kruchość zniknęła. Oczekiwanie na ślepo było powolne i zawodne.
Typowe błędy
- Zgoda na kruche selektory. Korzystanie z długich ścieżek XPath generowanych przez sztuczną inteligencję w obecnej postaci; Testy ulegają awarii przy pierwszej zmianie interfejsu.
- Pozostawiając ślepy „sen”. „Rozwiązywanie” problemu czasu ze stałym oczekiwaniem; zarówno powolny, jak i niezdecydowany.
- Trywialne twierdzenie. Po prostu sprawdź, czy strona się załadowała; brak sprawdzania rzeczywistego wyniku użytkownika (fałszywe hasło).
- Rozwijaj się bez POM. Rozdaj selektory do każdego testu; Ręczna aktualizacja dziesiątek plików w przypadku zmiany interfejsu.
- Nie określając narzędzia. Nie mówienie AI, jakiego narzędzia/języka chcesz; coraz niechlujny, niedziałający kod.
- Zaufanie, gdy uruchomisz wygenerowany kod i przejdziesz. Nie testowanie poprzez łamanie kodu.
Podsumowując
Automatyzacja testów interfejsu użytkownika weryfikuje zachowanie użytkownika, sterując rzeczywistą przeglądarką za pomocą programu. Sztuczna inteligencja generuje ten kod szybko, ale istnieją dwie duże pułapki: kruche testy (zły selektor, ślepe oczekiwanie) i testy fałszywe (niekompletne/trywialne potwierdzenie). Trzy filary solidnego testowania interfejsu użytkownika to selektor zatwierdzeń (data-testid), jawne oczekiwanie i potwierdzenie, które weryfikuje rzeczywisty wynik użytkownika. Posiadanie testów wygenerowanych w Modelu Obiektowym Strony radykalnie upraszcza konserwację. Przetestuj każdy wygenerowany test za pomocą pytania „Jaka zmiana to przerwie?”
Zadanie aplikacji
Wybierz przepływ użytkownika z własnego projektu (np. zaloguj się lub wyszukaj). Poproś sztuczną inteligencję o zapisanie testów za pomocą szablonu „solidnej generacji testów interfejsu użytkownika”. Następnie: (1) sprawdź i napraw selektory i poczekaj z „kontrolą kruchości”, (2) udowodnij, że każdy test faktycznie sprawdza się za pomocą „pseudo-pozytywnego dowodu”, (3) złam kod i zaobserwuj, że test zmienia kolor na czerwony. Zgłaszaj liczbę wyprodukowanych i poprawionych testów oraz liczbę znalezionych luk i pseudo-passów.
lista kontrolna
- [ ] Jasno dałem AI narzędzie, język, zasady selektora i architekturę (POM).
- [ ] Sprawdziłem, że selektory są testowane na podstawie danych.
- [ ] Upewniłem się, że zamiast ślepego snu użyję jawnego/automatycznego oczekiwania.
- [ ] Sprawdziłem, że każde potwierdzenie weryfikuje rzeczywisty wynik użytkownika.
- [ ] Przetestowałem każdy test, łamiąc kod; Widziałem, że zrobiło się czerwone.
- [ ] Testy zebrałem w strukturze Page Object Model.