Appium — vad är det, funktionsprinciper och cross-platform-testning

Vad är Appium

Appium är ett ramverk med öppen källkod för automatisering av testning av mobila applikationer, byggt på en klient-server-arkitektur. Appium-servern tar emot kommandon från klienten via WebDriver-protokollet och vidarebefordrar dem till inbyggda drivrutiner: XCUITest för iOS, UiAutomator2 för Android och WinAppDriver för Windows.

Historia och community

Appium skapades 2013 och har sedan dess blivit industristandard för cross-platform-testning. Projektet hanteras av Appium Foundation och stöds av stora företag: Sauce Labs, HeadSpin, Microsoft. Varje månad använder över 500 000 testare världen över Appium.

Applikationstyper som stöds

Appium stöder tre typer av applikationer: inbyggda (iOS, Android, Windows), mobila webbläsare (Safari, Chrome) och hybridapplikationer (WebView i ett inbyggt skal). Varje typ använder sitt eget sammanhang: NATIVE_APP, WEBVIEW eller CHROMIUM.

Appium och WebDriver arkitektur

Appium-arkitekturen består av fyra lager: klientkod → Appium Client Library → Appium Server → inbyggd drivrutin. Klientbiblioteket implementerar WebDriver-protokollet och skickar HTTP-förfrågningar till servern. Servern omvandlar dem till kommandon för plattformens inbyggda drivrutin.

WebDriver-protokollet

WebDriver är W3C-standarden för webbläsarautomatisering, anpassad av Appium för mobila enheter. Varje åtgärd — att hitta ett element, klicka, skriva in text — skickas som en HTTP-förfrågan till servern. Till exempel skapar POST /session/{id}/element en ny testsession.

Sessioner och Desired Capabilities

Varje test börjar med att skapa en session via objektet Desired Capabilities. I detta anges: platformName, deviceName, appPath, automationName och ytterligare parametrar. Appium använder denna data för att välja lämplig inbyggd drivrutin och konfigurera enheten.

# Exempel på Desired Capabilities för Android
desired_caps = {
    'platformName': 'Android',
    'deviceName': 'Pixel_4',
    'app': '/path/to/app.apk',
    'automationName': 'UiAutomator2',
    'appPackage': 'com.example.app',
    'appActivity': '.MainActivity'
}
driver = webdriver.Remote('http://localhost:4723/wd/hub', desired_caps)

Installation och konfiguration av Appium

Installation av Appium görs via npm: npm install -g appium. Efter installation måste inbyggda drivrutiner konfigureras för varje plattform: appium driver install xcuitest och appium driver install uiautomator2. För iOS krävs Xcode och för Android — Android SDK.

Appium Inspector

Appium Inspector är ett grafiskt verktyg för inspektion av gränssnittselement. Det ansluter till den körda Appium-servern och visar hierarkin av UI-komponenter, deras attribut och lokaliserare. Inspector gör det möjligt att kontrollera väljaren innan testet skrivs.

Starta servern

Appium-servern startas med kommandot appium med valfria parametrar: port, adress, loggning. Som standard lyssnar servern på port 4723. För parallell körning av flera enheter används olika portar eller Appium-kluster.

# Starta Appium-servern med loggning
appium \
  --port 4723 \
  --log-level debug \
  --use-plugins images \
  --base-path /wd/hub

Skriva tester i Appium

Appium-tester använder Page Object-mönstret för kodorganisation. Varje skärm i applikationen beskrivs av en separat klass med elementlokaliserare och interaktionsmetoder. Page Object Model förenklar underhållet av tester vid gränssnittsändringar och återanvänder väljare mellan testscenarier.

Elementlokaliserare

Appium stöder många strategier för att hitta element: id, xpath, accessibilityId, className, androidUIAutomator och iOSClassChain. Mest att föredra är accessibilityId och id — de är stabila vid layoutförändringar. XPath bör endast användas när andra lokaliserare saknas.

// Page Object för inloggningsskärmen
public class LoginPage {
    private AppiumDriver driver;

    private MobileElement emailField =
        (MobileElement) driver.findElement(MobileBy.AccessibilityId("emailInput"));
    private MobileElement passwordField =
        (MobileElement) driver.findElement(MobileBy.AccessibilityId("passwordInput"));
    private MobileElement loginButton =
        (MobileElement) driver.findElement(MobileBy.AccessibilityId("loginButton"));

    public void login(String email, String password) {
        emailField.sendKeys(email);
        passwordField.sendKeys(password);
        loginButton.click();
    }
}

Arbeta med gester och åtgärder

Appium stöder komplexa gester via klassen TouchAction eller W3C Actions API: svep, multitouch, långa tryck, rullning till element. Det nya W3C Actions API rekommenderas för nya projekt eftersom det är standardiserat och fungerar stabilare på olika plattformsversioner.

Jämförelse av Appium med alternativ

Appium jämförs ofta med Detox, XCUITest och Espresso. Den främsta fördelen med Appium är cross-platform-förmågan: ett enda test kan köras på iOS och Android utan ändringar. Detox ger dock bättre synkronisering för React Native, och XCUITest/Espresso ger snabbare exekvering för inbyggda tester.

När ska man välja Appium

Appium passar för projekt som kräver ett enhetligt ramverk för iOS, Android och webb. Det är oumbärligt i team med testare som skriver i Java eller Python. För React Native-projekt med många E2E-tester är det bättre att överväga Detox på grund av automatisk synkronisering.

Appium Grid och molntestning

Appium Grid är ett tillägg för parallell körning av tester på flera enheter samtidigt. Appium Grid är byggt på Selenium Grid och gör det möjligt att distribuera tester mellan flera Appium-servrar, var och en med sin egen uppsättning enheter eller emulatorer. Detta är kritiskt för stora projekt där en regressionstest på en enda enhet tar timmar — Grid minskar tiden till minuter proportionellt mot antalet noder.

Grid-konfiguration

För att konfigurera Grid används en konfigurationsfil i JSON-format där noder (nodes) med enheter beskrivs. Varje nod specificerar: serverport, lista över enheter med plattform, OS-version och maximalt antal sessioner. Hub distribuerar tester till lediga noder och säkerställer maximal belastning av infrastrukturen.

{
  "capabilities": [
    {
      "browserName": "android",
      "platformName": "Android",
      "deviceName": "Pixel_4",
      "platformVersion": "14.0",
      "maxInstances": 2
    }
  ],
  "configuration": {
    "port": 4724,
    "registerCycle": 5000
  }
}

Molntjänster

Om den egna enhetsinfrastrukturen inte är tillgänglig finns molntjänster: Sauce Labs, BrowserStack, LambdaTest. De erbjuder hundratals riktiga enheter och emulatorer i molnet. Integrationen med Appium är minimal: det räcker att ange URL till moln-hubben och inloggningsuppgifter i Desired Capabilities istället för localhost.

Parallell körning

Appium stöder parallell körning av tester med TestNG (Java) eller pytest-xdist (Python). Parallellisering kräver unika portar för varje session och isolerade testdata. Varje tråd startar sin egen Appium-session på en separat enhet eller emulator. Vid användning av molntjänster är parallelliseringen automatisk — plattformen distribuerar själv testerna till tillgängliga enheter och frigör dem efter slutförande.

Diagnostik och felsökning av Appium

Vid problem med Appium är första steget att kontrollera serverloggen (appium --log-level debug). Typiska fel: porten är upptagen (ange annan --port), inkompatibel drivrutinsversion, saknad Android SDK eller Xcode. För iOS, se till att WebKitAgent körs och har åtkomst till simulatorn.

Problem med att hitta element

Om Appium inte hittar ett element, kontrollera: är sammanhanget korrekt (NATIVE_APP vs WEBVIEW), är elementet synligt på skärmen, kräver det rullning och är lokaliseraren korrekt. Använd Appium Inspector för interaktiv sökning och kontroll av XPath-uttryck innan du infogar dem i testet. Det är också användbart att aktivera väntan på elementets uppdykande via WebDriverWait — detta löser synkroniseringsproblem vid långsam UI-laddning.

Sessionhantering

Felaktig avslutning av sessioner är en vanlig orsak till instabilitet i Appium-tester. Stäng alltid drivrutinen i finally-blocket eller via AutoCloseable. Vid fel använd tvingad driver.quit(). För iOS, se till att WebKitAgent (WDA) startas om mellan sessionerna, annars kan felet session not created uppstå. För att övervaka sessionernas status i CI är det användbart att ansluta plugin-programmet Appium Dashboard som visualiserar status för alla pågående tester i realtid.

Stabilitetsflaggor

För att öka teststabiliteten, använd: shouldTerminateApp (avsluta applikationen mellan tester), noReset (behåll data mellan sessioner), autoGrantPermissions (automatisk beviljning av systemdialoger). Det rekommenderas också att inaktivera animationer på enheten via Developer Options.