Appium Önskad kapacitet för Android emulator

Vad är önskade förmågor

'Önskade funktioner' hjälper oss att modifiera serverns beteende under automatisering. Appium Det är en hashmapp, eller ett nyckel-värde-par, som används för att skicka ett kommando till Appium server, där varje klientkommando körs i kontexten av en session.

Till exempel skickar en klient en POST /session-förfrågan som innehåller ett JSON-objekt till Appium servern.

Så, för att skicka en förfrågan eller upprätthålla en session med servern används en uppsättning nyckel- och värdepar. Detta kallas "önskade 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");
}

Viktig roll för önskad förmåga

• 'DesiredCapabilities' hjälper användaren att kontrollera sessionsförfrågan med servern. Till exempel, för en iOS-session ställer vi in ​​kapaciteten platformName = iOS, och för en Android sessionsplattformnamn = Android.
• 'DesiredCapabilities' används för att konfigurera WebDriver-instansen, till exempel FirefoxDrivrutin, Chrome-drivrutin eller InternetExplorer-drivrutin.
• DesiredCapability är mycket användbart för Selenium Grid. Till exempel används det för att köra olika testfall i olika webbläsare och operativsystem. Baserat på den angivna funktionen pekar Grid-hubben på motsvarande nod. Noder definieras med hjälp av egenskapsmetoderna 'set':

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

• En önskad funktion är ett biblioteksdefinierat paket. Innan 'DesiredCapabilities' används bör det importeras från biblioteket nedan.

  Org.openqa.selenium.remote.DesiredCapabilities

Appium stöder båda Android och iOS, så det finns en separat uppsättning Appium serverkapacitet för varje plattform.

Tabellen nedan visar några vanligt förekommande Android förmågor och de värden som ska användas.

OBS: se Appium dokumentation för att se mer Android kapacitet.

Tabellen nedan visar några vanliga iOS-funktioner och de värden som ska användas.

OBS: se Appium funktionsguide för att se fler iOS-funktioner.

Hur önskade förmågor förändrades i Appium 2

Exemplen ovan kommer från Appium 1 era och visar fortfarande formen av en förmågoruppsättning, men två regler har ändrats och båda kommer att stoppa en modern session från att starta.

För det första definierar W3C WebDriver-specifikationen endast en liten uppsättning standardfunktioner, av vilka platformName och browserName spelar roll här. Alla andra funktioner är en leverantörsutökning och måste ha ett namnrymdsprefix som slutar med ett kolon. Appiums prefix är appium:. Så deviceName blir appium:deviceName och platformVersion blir appium:platformVersion. Appium 2 kräver också appium:automationName, eftersom drivrutiner installeras separat snarare än att medfölja servern.

För det andra blir det tråkigt att upprepa prefixet, så Appium accepterar en enda appium:options Funktion vars värde är ett objekt. Funktioner inuti det objektet behöver inget prefix, och om ett namn förekommer både inuti och utanför objektet vinner det inre värdet.

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

⚠️ Versionsnotering: på Java sida, Selenium 4 och Appium Java klient 8 avfärdade DesiredCapabilities klass som visats tidigare. Drivrutinsspecifika byggare ärvda från BaseOptions ersätt den — UiAutomator2Options för Android och XCUITestOptions för iOS — med en en-till-en-kartaping från varje gammal setCapability anrop. Den ursprungliga koden ovan behålls här som ett historiskt exempel.

ExtracInformation om paket och aktiviteter

Paket är paketerade filer eller klasser. De ger en organiserad struktur till modulär programmering. Java, lagras olika paket i en enda JAR-fil, och användaren kan anropa den JAR-filen för fullständig exekvering. Ett liknande koncept följs inom utveckling av mobilapplikationer.

I Android operativsystem, alla applikationer installeras i form av Java paket. Så, till exempeltract paketets sökvägsinformation, Android PackageManager-klassen används.

Den hämtar paket- och aktivitetsinformation för förinstallerade och efterinstallerade applikationer på enheten.

Du kan hämta en instans av PackageManager-klassen genom att anropa getPackageManager(). Den här metoden kan komma åt och manipulera paketen och relaterade behörigheter för de installerade applikationerna.

Till exempel:

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

Hur man hittar appPackage och appActivity med adb

PackageManager-rutten ovan fungerar inifrån en applikation. Som testare har du vanligtvis bara den installerade versionen, så den snabbare vägen är en fråga över adb mot en ansluten enhet eller emulator.

Öppna programmet på enheten manuellt och kör sedan ett av kommandona nedan från en terminal i mappen platform-tools. Kommandot skriver ut det fönster som för närvarande har fokus och värdet formateras som package/activity.

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

Använd den första formuläret i Windows kommandotolken och den andra i ett Unix-skal eller Git Bash. Läs resultatet som två halvor: allt före snedstrecket är värdet för appPackage, och allt efter det är värdet för appActivity.

Två försiktighetsåtgärder gäller. Den fokuserade aktiviteten är det som visas på skärmen just då, vilket inte alltid är den aktivitet som applikationen startar med – om en session misslyckas under drivrutininitieringen, starta appen på nytt och läs värdet igen. Och om en välkomstskärm visas först kommer inmatningsaktiviteten att skilja sig från den du slutligen vill göra anspråk på, vilket är exakt fallet. appWaitActivity finns för.

Ett visuellt alternativ är uiautomatorviewer, som fångar den aktuella skärmhierarkin och visar paketet och klassen för varje nod.

Vanliga fel gällande önskade funktioner och hur man åtgärdar dem

De flesta misslyckades Appium sessioner avslutas innan ett enda teststeg körs, och orsaken ligger nästan alltid i funktionsuppsättningen snarare än i testet. Tabellen nedan mappar varje meddelande till dess vanliga åtgärd.

När en session vägrar att starta, läs Appium serverloggen snarare än klientstacken trace. Servern anger vilken funktion den inte kunde uppfylla, och den raden anger lösningen.

Vanliga frågor