Appium Ønskede evner til Android emulator

Hvad er ønskede egenskaber

'Ønskede funktioner' hjælper os med at ændre serverens adfærd under automatisering. Appium Det er en hashmap, eller et nøgle-værdi-par, der bruges til at sende en kommando til Appium server, hvor hver klientkommando kører i konteksten af ​​en session.

For eksempel sender en klient en POST /session-anmodning, der indeholder et JSON-objekt, til Appium serveren.

Så for at sende en anmodning eller opretholde en session med serveren bruges et sæt nøgle- og værdipar. Dette kaldes 'ønskede funktioner'.

import io.appium.java_client.AppiumDriver;
import org.openqa.selenium.remote.DesiredCapabilities;
{
        DesiredCapabilities capabilities = new DesiredCapabilities();
        capabilities.setCapability("deviceName","Android Emulator");
        capabilities.setCapability("platformVersion", "4.4");
}

Vigtig rolle for ønsket evne

• 'DesiredCapabilities' hjælper brugeren med at kontrollere sessionsanmodningen med serveren. For eksempel, for en iOS-session sætter vi kapaciteten platformName = iOS, og for en Android sessionsplatformnavn = Android.
• 'DesiredCapabilities' bruges til at konfigurere WebDriver-instansen, for eksempel FirefoxDriver, ChromeDriver eller InternetExplorerDriver.
• DesiredCapability er meget nyttig til Selenium Grid. For eksempel bruges det til at køre forskellige testcases på en anden browser og et andet operativsystem. Baseret på den angivne funktion peger Grid-hubben på den tilsvarende node. Noder defineres ved hjælp af 'set'-egenskabsmetoderne:

  DesiredCapabilities obj = new DesiredCapabilities(); 
  obj.setBrowserName("firefox"); 
  obj.setVersion("18.0.1"); 
  obj.setPlatform(org.openqa.selenium.Platform.WINDOWS);					
  

• En ønsket funktion er en biblioteksdefineret pakke. Før 'DesiredCapabilities' kan bruges, skal den importeres fra biblioteket nedenfor.

  Org.openqa.selenium.remote.DesiredCapabilities

Appium understøtter begge dele Android og iOS, så der er et separat sæt af Appium serverfunktioner for hver platform.

Tabellen nedenfor viser nogle almindeligt anvendte Android evner og værdier, der skal anvendes.

BEMÆRK: se Appium dokumentation for at se mere Android kapaciteter.

Tabellen nedenfor viser nogle almindeligt anvendte iOS-funktioner og de værdier, der skal bruges.

BEMÆRK: se Appium vejledning til kapaciteter for at se flere iOS-funktioner.

Hvordan ønskede evner ændrede sig i Appium 2

Eksemplerne ovenfor stammer fra Appium 1 æra og viser stadig formen af ​​et evnesæt, men to regler er ændret, og begge vil forhindre en moderne session i at starte.

For det første definerer W3C WebDriver-specifikationen kun et lille sæt standardfunktioner, hvoraf platformName og browserName betyder noget her. Enhver anden funktion er en leverandørudvidelse og skal have et navnerumspræfiks, der ender på et kolon. Appium's præfiks er appium:. Så deviceName bliver appium:deviceName og platformVersion bliver appium:platformVersion. Appium 2 kræver også appium:automationName, fordi drivere installeres separat i stedet for at være bundtet med serveren.

For det andet bliver det kedeligt at gentage præfikset, så Appium accepterer en enkelt appium:options Funktion, hvis værdi er et objekt. Funktioner inden for det pågældende objekt behøver intet præfiks, og hvor et navn forekommer både inden for og uden for objektet, vinder den indre værdi.

{
    "platformName": "iOS",
    "appium:options": {
        "automationName": "XCUITest",
        "platformVersion": "16.0",
        "app": "/path/to/your.app",
        "deviceName": "iPhone 12",
        "noReset": true
    }
}

⚠️ Versionsnotat: på den Java side, Selenium 4 og Appium Java klient 8 udfasede DesiredCapabilities klasse vist tidligere. Driverspecifikke builders arvet fra BaseOptions udskift den – UiAutomator2Options forum Android og XCUITestOptions til iOS — med et en-til-en-kortping fra hver gammel setCapability opkald. Den originale kode ovenfor er bevaret her som et historisk eksempel.

ExtracInformation om pakker og aktiviteter

Pakker er bundtede filer eller klasser. De giver en organiseret struktur til modulær programmering. Java, forskellige pakker gemmes i en enkelt JAR-fil, og brugeren kan kalde den JAR-fil for fuld udførelse. Et lignende koncept følges i udvikling af mobilapplikationer.

I Android operativsystem, alle applikationer installeres i form af Java pakker. Så, for eksempeltract pakkestioplysninger, den Android PackageManager-klassen bruges.

Den henter pakke- og aktivitetsoplysninger for forudinstallerede og efterinstallerede applikationer på enheden.

Du kan få en instans af PackageManager-klassen ved at kalde getPackageManager(). Denne metode kan tilgå og manipulere pakkerne og relaterede tilladelser for de installerede applikationer.

For eksempel:

PackageManager pManager = getPackageManager();
List<ApplicationInfo> list = pManager.getInstalledApplications(PackageManager.GET_META_DATA)

Sådan finder du appPackage og appActivity med adb

PackageManager-ruten ovenfor fungerer indefra en applikation. Som tester har du normalt kun den installerede build, så den hurtigste vej er en forespørgsel over adb mod en tilsluttet enhed eller emulator.

Åbn applikationen på enheden manuelt, og kør derefter en af ​​kommandoerne nedenfor fra en terminal i mappen platform-tools. Kommandoen udskriver det vindue, der aktuelt har fokus, og værdien formateres som package/activity.

adb shell dumpsys window | find "mCurrentFocus"
adb shell dumpsys window windows | grep -i "mCurrentFocus"

Brug den første formular i Windows kommandoprompten og den anden i en Unix-shell eller Git Bash. Læs resultatet som to halvdele: alt før skråstregen er værdien for appPackage, og alt efter det er værdien for appActivity.

To forholdsregler gælder. Den fokuserede aktivitet er det, der er på skærmen i det øjeblik, hvilket ikke altid er den aktivitet, applikationen starter med – hvis en session mislykkes under driverinitialisering, skal du starte appen på ny og aflæse værdien igen. Og hvis der vises et velkomstskærmbillede først, vil indtastningsaktiviteten afvige fra den, du til sidst vil gøre krav på, hvilket netop er tilfældet. appWaitActivity findes for.

Et visuelt alternativ er uiautomatorviewer, som indfanger det aktuelle skærmhierarki og viser pakken og klassen for hver node.

Almindelige fejl vedrørende ønskede funktioner og hvordan man retter dem

De fleste mislykkedes Appium sessioner slutter, før et enkelt testtrin kører, og årsagen ligger næsten altid i funktionssættet snarere end i testen. Tabellen nedenfor knytter hver meddelelse til dens sædvanlige løsning.

Når en session nægter at starte, skal du læse Appium serverlog i stedet for klientstakken trace. Serveren angiver, hvilken funktion den ikke kunne opfylde, og den linje navngiver rettelsen.

Ofte Stillede Spørgsmål