Przygotowywanie testów appium do przekazania

Artykuł
03/17/2024

Ważne

Program Visual Studio App Center ma zostać wycofany 31 marca 2025 r. Mimo że możesz nadal używać programu Visual Studio App Center do momentu jej pełnego wycofania, istnieje kilka zalecanych alternatyw, do których można rozważyć migrację.

Dowiedz się więcej o osiach czasu pomocy technicznej i alternatywach.

Kroki przygotowywania aplikacji i jej zestawu testów do przekazywania różnią się w zależności od struktury testowej. W tym przewodniku przedstawiono sposób przygotowywania testów appium przy użyciu języka Java z narzędziem JUnit do przekazywania do centrum aplikacji. Aby uzyskać wskazówki dotyczące tworzenia testów appium, zobacz dokumentację aplikacji Appium.

Zwróć uwagę na następujące ograniczenia dotyczące obsługi aplikacji Appium:

Uwaga

Kontekst elementu WebView, testowanie przeglądarki Chrome i przeglądarki Chrome z browserName możliwością są obsługiwane!

Brak obsługi testNG (obsługiwane są tylko testy JUnit).
Brak obsługi systemu Android 4.2 lub wcześniejszego. Brak obsługi przestarzałego sterownika UIAutomator.
Brak obsługi systemu iOS 9.2.1 lub wcześniejszego. Brak obsługi przestarzałego sterownika UIAutomation dla systemu iOS.
Brak obsługi programu JUnit @Category attribute. (Zamiast tego może używać opcji Dołączanie/wykluczanie )
Wersja narzędzia Maven musi być co najmniej 3.3.9.
Bieżąca wersja appium to 1.22.0. Jest on regularnie aktualizowany wraz z nowymi wersjami.
Obsługiwana jest wersja JUnit 4.9 — 4.12; Nie obsługujemy JUnit 5.
Testy muszą dotyczyć dokładnie jednej aplikacji. (MobileCapabilityType.FULL_RESET jest obsługiwany)

Uwaga

W niektórych przypadkach testy mogą nadal działać w usłudze App Center, jeśli są używane nieobsługiwane narzędzia lub funkcje. Jednak ta nieobsługiwana funkcja nie jest dostępna w przyszłych aktualizacjach i może zostać przerwana bez ostrzeżenia.

Wymagania wstępne

Testy będą uruchamiane przy użyciu narzędzia Maven Surefire, co wymaga, aby testy przestrzegały określonych konwencji nazewnictwa:

"**/Test*.java" - includes all of its subdirectories and all Java filenames that start with "Test".
"**/*Test.java" - includes all of its subdirectories and all Java filenames that end with "Test".
"**/*Tests.java" - includes all of its subdirectories and all Java filenames that end with "Tests".
"**/*TestCase.java" - includes all of its subdirectories and all Java filenames that end with "TestCase".

Przed podjęciem próby przekazania do testu usługi App Center upewnij się, że uruchamianie testów lokalnie na maszynie przy użyciu narzędzia Maven działa:

➜  AppiumTest git:(main) ✗ mvn verify
...
Running MainTest
started: SimpleTest (MainTest)
Setting up capabilities
failed
finished
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.728 sec <<< FAILURE!
SimpleTest(MainTest)  Time elapsed: 0.594 sec  <<< ERROR!
...

Jeśli nie możesz uruchomić testów przy użyciu wiersza polecenia lokalnie, testy również nie będą działać w usłudze App Center Test.

1. Zmiany w systemie kompilacji

Krok 1. Dodawanie zależności

Musisz dodać zależność dla rozszerzeń testowych appium:

<dependency>
    <groupId>com.microsoft.appcenter</groupId>
    <artifactId>appium-test-extension</artifactId>
    <version>1.6</version>
</dependency>

Ten kod zapewni, że ulepszone sterowniki systemu Android i iOS są dostępne w czasie kompilacji. Ulepszone sterowniki są udostępniane głównie w celu włączenia label tej funkcji. Aby uzyskać więcej informacji na temat label funkcji, zobacz Krok 4.

Krok 2. Dodawanie profilu przekazywania

Skopiuj ten fragment kodu do elementu pom.xml w tagu <profiles> . Jeśli nie <profiles> ma sekcji w swoim pom, utwórz je. Po aktywowaniu profil spakuje klasy testowe i wszystkie zależności do target/upload folderu, które będą gotowe do przekazania do testu.

2. Zmiany w testach

Krok 1. Dodawanie importu

Zaimportuj te pakiety do klas testowych:

import com.microsoft.appcenter.appium.Factory;
import com.microsoft.appcenter.appium.EnhancedAndroidDriver;
import org.junit.rules.TestWatcher;
import org.junit.Rule;

Krok 2. Utworzenie wystąpienia elementu TestWatcher

Wstaw tę deklarację w każdej z klas testów:

    @Rule
    public TestWatcher watcher = Factory.createWatcher();

Krok 3. Aktualizowanie deklaracji sterownika

Zastąp deklarację ciągiem AndroidDriver<MobileElement> lub IOSDriver<MobileElement> ciągiem EnhancedAndroidDriver<MobileElement>EnhancedIOSDriver<MobileElement>

    private static EnhancedAndroidDriver<MobileElement> driver;

Krok 4. Aktualizowanie wystąpień sterownika

Zastąp sposób tworzenia wystąpienia sterownika, tak aby wiersze w postaci:

    driver = new AndroidDriver<MobileElement>(url, capabilities);

... są zmieniane na:

    driver = Factory.createAndroidDriver(url, capabilities);

Użycie tych sterowników pozwoli nadal uruchamiać testy lokalnie bez dodatkowych modyfikacji, ale umożliwia "etykietowanie" kroków testowych w wykonaniu testu przy użyciu polecenia driver.label("text"). Tekst i zrzut ekranu z urządzenia będą widoczne w raporcie testowym w centrum aplikacji.

Zalecane jest wywołanie driver.label metody @After , która tworzy zrzut ekranu przedstawiający stan końcowy aplikacji. Przykładowa @After metoda testu może wyglądać następująco:

    @After
    public void TearDown(){
        driver.label("Stopping App");
        driver.quit();
    }

3. Przekazywanie do testu centrum aplikacji

Kroki przekazywania testu:

Wygeneruj polecenie przekazywania testowego w usłudze App Center, korzystając z instrukcji podczas uruchamiania przebiegu testu.
Spakuj klasy testowe i wszystkie zależności do target/upload folderu:
```
mvn -DskipTests -P prepare-for-upload package
```

Uruchom polecenie przekazywania:

appcenter test run appium --app "APP_ID" --devices "DEVICE_SET_ID" --app-path PATH_TO_FILE.apk  --test-series "main" --locale "en_US" --build-dir target/upload

4. Rozwiązywanie problemów z wydajnością

Testy na urządzeniach w usłudze App Center będą wykonywane nieco wolniej niż na urządzeniu lokalnym. Zwykle wolniejsze wykonywanie jest przeważane przez posiadanie większej liczby dostępnych urządzeń, co pozwala na równoległe przebiegi testów.

Istnieją trzy główne źródła wolniejszych przebiegów testów: ponowne podpisywanie, ponowne instalowanie i zadania sieciowe.

Ponowne podpisywanie (w systemie iOS)

Przed zainstalowaniem na urządzeniu z systemem iOS aplikacja przechodzi przez proces o nazwie ponowne podpisywanie. Ten proces jest niezbędny do dopasowania profilu aprowizacji do urządzenia w chmurze. Ponowne podpisywanie trwa trochę czasu, zazwyczaj ok. 1–2 minuty. Rzadko ponowne podpisywanie powoduje również obniżenie wydajności, ponieważ ponownie podpisane aplikacje są buforowane. Czasochłonny proces będzie uruchamiany tylko raz na plik binarny.

Jeśli konfiguracja ciągłego dostarczania aktualizuje wersję ipA przed kompilowaniem i testowaniem, dane binarne będą inne dla każdego testu, a kara za ponowne podpisywanie będzie występować częściej.

Ponownej instalacji

W chmurze udostępnionej urządzenia ważne jest, aby zagwarantować, że urządzenia są czyszczone między poszczególnymi testami. Następny klient korzystający z urządzenia może być osobą z innej organizacji. W aplikacji App Center Test aplikacja zostanie automatycznie odinstalowana po zakończeniu przebiegu testu.

Istnieje możliwość pominięcia MobileCapabilityType.FULL_RESET i ustawienia MobileCapabilityType.NO_RESET w celu true przyspieszenia wykonywania testów. Aby uzyskać szczegółowe informacje, zobacz Strategie resetowania .

Zadania sieciowe

Zadania sieci lokalnej są szybsze, ponieważ serwer jest bliżej i bardziej dedykowany do hosta zdalnego.

Udostępnij za pośrednictwem