मोबाइल टेस्ट ऑटोमेशन की व्याख्या

मोबाइल पर क्या ऑटोमेट करें

Test pyramid मोबाइल पर भी किसी और प्रोडक्ट की तरह लागू होता है (manual vs automated testing गाइड कारण बताती है): ज़्यादातर checks UI के नीचे होने चाहिए, जहाँ वे तेज़ और स्थिर हैं। Android पर local unit टेस्ट development मशीन के JVM पर सेकंडों में चलते हैं, जबकि instrumented टेस्ट डिवाइस या emulator पर चलते हैं; iOS पर XCTest एक ही Xcode प्रोजेक्ट से unit और UI टेस्ट चलाता है। बिज़नेस नियम, validation और गणनाएँ unit टेस्ट और बैक एंड के API टेस्ट में होनी चाहिए। UI टेस्ट उन journeys के लिए हैं जो कभी टूटनी नहीं चाहिए — साइन-इन, onboarding, search, checkout, ऐप का मुख्य फ़ीचर — और स्क्रीन के बीच की wiring के लिए।

• Unit टेस्ट — view models, formatters, validation, लोकल डेटाबेस queries; हर commit पर चलें।
• Instrumented या integration टेस्ट — वह कोड जिसे प्लेटफ़ॉर्म चाहिए: storage, लोकल डेटाबेस, बैकग्राउंड काम; emulator या simulator पर चलें।
• API टेस्ट — ऐप जिस बैक एंड को कॉल करता है, error responses और पुराने client के साथ compatibility समेत।
• UI टेस्ट — हर प्लेटफ़ॉर्म के लिए critical journeys का छोटा सेट, CI में emulator पर और रिलीज़ से पहले असली डिवाइस पर।
• मैन्युअल और exploratory टेस्टिंग — gestures, असली इंटरप्शन, look and feel, असली डिवाइस का व्यवहार (मैन्युअल रहने वाले हिस्से वाला सेक्शन देखें)।

Espresso, XCUITest और Appium की तुलना

कोई सार्वभौमिक विजेता नहीं है। अगर टेस्ट developers के हैं और प्लेटफ़ॉर्म अलग-अलग टीमें बनाती हैं, तो नेटिव फ़्रेमवर्क सबसे उपयुक्त हैं: सबसे तेज़ feedback, सबसे कम flakiness, ऐप वाली ही भाषा। अगर एक अलग automation टीम साझा flows के साथ दोनों प्लेटफ़ॉर्म कवर करती है, या टेस्ट को source access के बिना release जैसे builds पर चलना है, तो Appium का एक codebase और भाषा की आज़ादी ज़्यादा मायने रखती है। कई टीमें दोनों मिलाती हैं: developer pipeline में स्क्रीन-स्तर के टेस्ट के लिए नेटिव फ़्रेमवर्क, और end-to-end journeys के लिए छोटा cross-platform Appium suite।

• Espresso — सिर्फ़ Android; टेस्ट Kotlin या Java में; ऐप के process के अंदर instrumentation टेस्ट के रूप में चलता है। यह ऐप के UI thread के साथ अपने-आप sync होता है, इसलिए सिर्फ़ तब action लेता है जब UI idle हो; जो बैकग्राउंड काम इसे नहीं दिखता वह idling resources के ज़रिए रजिस्टर होता है। तेज़ और स्थिर; आम तौर पर Android developers कोड के साथ लिखते हैं। यह ऐप के बाहर के सिस्टम UI तक नहीं पहुँचता — उसके लिए UI Automator है।
• XCUITest — सिर्फ़ iOS; टेस्ट Swift या Objective-C में, Xcode में XCTest के साथ लिखे जाते हैं (Apple अब UI testing API को XCUIAutomation नाम से document करता है)। test runner एक अलग process है जो accessibility layer के ज़रिए ऐप को वैसे चलाता है जैसे यूज़र। यह interact करने से पहले ऐप के स्थिर होने का इंतज़ार करता है और सिस्टम alerts सँभाल सकता है। आम तौर पर iOS developers या Xcode में काम करने वाले automation engineers लिखते हैं।
• Appium — Android, iOS और दूसरे प्लेटफ़ॉर्म; किसी भी ऐसी भाषा में टेस्ट जिसका WebDriver client हो (Java, Python, JavaScript, C#, Ruby…)। client W3C WebDriver commands Appium सर्वर को भेजता है, जो डिवाइस पर action के लिए प्लेटफ़ॉर्म driver इस्तेमाल करता है — जैसे Android पर UiAutomator2 driver और iOS पर XCUITest driver। यह ऐप को black box मानता है, हाइब्रिड ऐप के WebView context में जा सकता है, और मोबाइल ब्राउज़र ऑटोमेट कर सकता है। हर step ज़्यादा परतें पार करता है, इसलिए यह नेटिव फ़्रेमवर्क से धीमा है।

Espresso: process के अंदर और synchronised

Espresso टेस्ट matcher से view ढूँढता है, उस पर action करता है, और assertion जाँचता है। हर action और assertion से पहले Espresso UI thread की message queue के idle होने तक इंतज़ार करता है, जिससे वह ज़्यादातर waiting कोड हट जाता है जो दूसरे टूल्स को चाहिए। जो काम कहीं और चलता है — कस्टम thread pool, या ऐसी network library जिसे Espresso नहीं जानता — उसे idling resource के रूप में रजिस्टर करना होगा, वरना टेस्ट उससे race करेगा। Jetpack Compose से बनी स्क्रीन Compose के अपने testing APIs से टेस्ट होती हैं, जो इसी सिद्धांत पर चलते हैं।

@RunWith(AndroidJUnit4::class)
class LoginTest {
    @get:Rule
    val activityRule = ActivityScenarioRule(LoginActivity::class.java)

    @Test
    fun wrongPasswordShowsError() {
        onView(withId(R.id.email)).perform(typeText("layla.h@example.com"), closeSoftKeyboard())
        onView(withId(R.id.password)).perform(typeText("wrong-pass-1"), closeSoftKeyboard())
        onView(withId(R.id.sign_in)).perform(click())
        onView(withText(R.string.error_invalid_credentials)).check(matches(isDisplayed()))
    }
}

XCUITest: accessibility के ज़रिए black-box

XCUITest टेस्ट ऐप को अलग process के रूप में लॉन्च करता है और उसके element tree को type और identifier से query करता है: buttons, text fields, static texts। Developers हर उस एलिमेंट पर accessibilityIdentifier लगाते हैं जिसकी टेस्ट को ज़रूरत है; accessibility label के उलट, identifier VoiceOver नहीं बोलता, इसलिए यह स्थिर तकनीकी नाम हो सकता है। Launch arguments और environment variables ऐप को टेस्ट स्थिति में डालते हैं — mock server URL, reset data store, बंद animations — बिना विशेष builds के। async काम के बाद दिखने वाले एलिमेंट के लिए fixed sleep के बजाय waitForExistence(timeout:) इस्तेमाल करें।

final class LoginUITests: XCTestCase {
    func testWrongPasswordShowsError() {
        let app = XCUIApplication()
        app.launchArguments += ["-uiTesting", "-resetState"]
        app.launch()

        let email = app.textFields["login.email"]
        email.tap()
        email.typeText("layla.h@example.com")

        let password = app.secureTextFields["login.password"]
        password.tap()
        password.typeText("wrong-pass-1")

        app.buttons["login.submit"].tap()

        XCTAssertTrue(app.staticTexts["login.error"].waitForExistence(timeout: 5))
    }
}

Appium: मोबाइल के लिए WebDriver

Appium एक सर्वर है। आपका टेस्ट, जो WebDriver client library से लिखा गया है, capabilities भेजकर session खोलता है — कौन सा प्लेटफ़ॉर्म, कौन सा automation driver, कौन सा ऐप, कौन सा डिवाइस — और फिर find element, click और send keys जैसे commands भेजता है। Appium 2 से drivers सर्वर से अलग इंस्टॉल होते हैं, इसलिए प्रोजेक्ट ठीक-ठीक बताता है कि वह कौन से driver वर्ज़न इस्तेमाल करता है। जो capabilities W3C मानक का हिस्सा नहीं हैं उन पर appium: prefix लगता है। क्योंकि Appium ऐप को बाहर से चलाता है, वही टेस्ट emulator पर debug build और device farm के फ़ोन पर release candidate दोनों पर चल सकता है।

from appium import webdriver
from appium.options.android import UiAutomator2Options
from appium.webdriver.common.appiumby import AppiumBy
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

caps = {
    "platformName": "Android",
    "appium:automationName": "UiAutomator2",
    "appium:deviceName": "Pixel_Test",
    "appium:app": "/builds/shop-4.0.0-debug.apk",
    "appium:autoGrantPermissions": True,
}
driver = webdriver.Remote("http://127.0.0.1:4723", options=UiAutomator2Options().load_capabilities(caps))
try:
    driver.find_element(AppiumBy.ACCESSIBILITY_ID, "login.email").send_keys("layla.h@example.com")
    driver.find_element(AppiumBy.ACCESSIBILITY_ID, "login.password").send_keys("wrong-pass-1")
    driver.find_element(AppiumBy.ACCESSIBILITY_ID, "login.submit").click()
    WebDriverWait(driver, 10).until(
        EC.presence_of_element_located((AppiumBy.ACCESSIBILITY_ID, "login.error")))
finally:
    driver.quit()

मोबाइल पर locators

Locator वह तरीक़ा है जिससे टेस्ट एलिमेंट ढूँढता है, और मोबाइल पर इसका चुनाव स्थिरता और गति दोनों तय करता है। Developers के साथ identifier की naming convention तय करें (जैसे screen.element: login.submit), टेस्ट जिन एलिमेंट को छूते हैं उन सब पर identifiers लगाएँ, और "test identifiers मौजूद हैं" को definition of done का हिस्सा बनाएँ। सामान्य सिद्धांत locator strategies गाइड में हैं; मोबाइल की ख़ास बातें नीचे हैं।

• Accessibility id — Appium की पसंदीदा strategy। iOS पर यह accessibilityIdentifier से मेल खाता है, जिसे VoiceOver नहीं पढ़ता, इसलिए यह तकनीकी नाम हो सकता है। Android पर यह content description से मेल खाता है, जिसे TalkBack ज़ोर से पढ़ता है — इसलिए Android पर यह असली इंसानी label होना चाहिए, वरना resource id इस्तेमाल करें।
• Resource id (Android) — जैसे com.example.shop:id/sign_in; तब तक स्थिर जब तक developers ids न बदलें।
• प्लेटफ़ॉर्म-नेटिव queries — UiAutomator2 के लिए UiSelector, iOS पर predicate strings और class chains — जब ऊपर वाले फ़िट न हों; XPath से तेज़।
• दिखने वाला टेक्स्ट — ऐप localize होने पर टूट जाता है (अरबी और अंग्रेज़ी builds अलग टेक्स्ट दिखाते हैं); सिर्फ़ हर locale के resources के साथ इस्तेमाल करें।
• XPath — आख़िरी उपाय: मोबाइल पर धीमा क्योंकि पूरी view hierarchy serialise करनी पड़ती है, और layout बदलने पर नाज़ुक।
• Cross-platform फ़्रेमवर्क (React Native, Flutter) अपनी test-id property देते हैं; उस पर locators बनाने से पहले जाँचें कि वह हर प्लेटफ़ॉर्म पर किससे map होती है।

मोबाइल UI टेस्ट flaky क्यों होते हैं — और क्या करें

Flaky टेस्ट एक ही कोड पर कभी पास और कभी फ़ेल होता है। मोबाइल आम कारणों (asynchrony, shared state, remote services, समय) में अपने कारण जोड़ता है, और बेतरतीब फ़ेल होने वाला suite जल्दी नज़रअंदाज़ होने लगता है। flaky tests गाइड पहचान और quarantine कवर करती है; ये मोबाइल-विशेष स्रोत हैं।

• Animations और transitions — टेस्ट डिवाइस और emulator पर इन्हें बंद करें (नीचे की तीन animation scale settings), या iOS पर launch arguments से।
• ऐसी asynchrony जो फ़्रेमवर्क को नहीं दिखती — Espresso में idling resources रजिस्टर करें, बाक़ी हर जगह शर्तों (एलिमेंट मौजूद है, enabled है) का इंतज़ार करें; fixed sleep कभी नहीं।
• सिस्टम डायलॉग — permission prompts, "app isn’t responding", कीबोर्ड टिप्स, OS update prompts। जहाँ टेस्ट permissions के बारे में नहीं है वहाँ पहले से permission दें, और अपेक्षित सिस्टम alerts को स्पष्ट रूप से सँभालें।
• टेस्ट के बीच state का रिसना — साइन-इन session, लोकल डेटा, feature flags। हर टेस्ट पर reset करें: ऐप डेटा clear करें (Android Test Orchestrator टेस्ट के बीच package data clear कर सकता है) या iOS पर reset argument के साथ लॉन्च करें।
• असली नेटवर्क और साझा बैक एंड — mock server या seeded test environment इस्तेमाल करें, और हर run के लिए unique डेटा generate करें।
• अगले एलिमेंट को ढकने वाला soft keyboard, और ऐसे एलिमेंट जिन्हें दिखाने के लिए scroll चाहिए।
• डिवाइस और emulator की सेहत — धीमा boot, भरा storage, कम बैटरी या गर्म farm डिवाइस। health checks जोड़ें; retry सिर्फ़ infrastructure स्तर पर, असली विफलता छिपाने के लिए कभी नहीं।
• मैट्रिक्स के डिवाइसों के बीच locale, timezone और घड़ी का अंतर।

# Android — turn off animations on a test device or emulator
adb shell settings put global window_animation_scale 0
adb shell settings put global transition_animation_scale 0
adb shell settings put global animator_duration_scale 0

आज़माएँ: Mock API रिस्पॉन्स जनरेटर आज़माएँ: API स्टेटस कोड सिम्युलेटर आज़माएँ: Mock एरर रिस्पॉन्स जनरेटर आज़माएँ: फ़ेक यूज़र जनरेटर

Device farm और CI pipeline

Android emulator Linux, Windows या macOS CI मशीनों पर चलते हैं और तेज़ होने के लिए hardware acceleration चाहते हैं (Linux पर KVM); iOS simulator के लिए macOS ज़रूरी है। लंबे suites को shards में बाँटें जो कई emulator या डिवाइस पर समानांतर चलें। क्लाउड device farm आपका ऐप और test package लेकर आपके चुने असली डिवाइस पर चलाता है और वीडियो, screenshots और logs के साथ नतीजे लौटाता है; वही डिवाइस आम तौर पर मैन्युअल session के लिए भी मिलते हैं। farm डिवाइस अपने डिवाइस मैट्रिक्स से चुनें, और secondary parameters (भाषा, orientation, font size) के लिए runs गुणा करने के बजाय pairwise चयन इस्तेमाल करें।

नतीजे ऐसे फ़ॉर्मेट में publish करें जिसे CI सर्वर समझता हो (JUnit XML आम है) और हर फ़ेल टेस्ट के artefacts रखें। बिना वीडियो और डिवाइस log वाला red build ऐसा build है जिसे कोई ठीक करने के बजाय दोबारा चला देगा।

नीचे का उदाहरण (illustrative) pipeline की एक संभावित लय दिखाता है: हर pull request पर unit टेस्ट, ऐप और test package का build, हर प्लेटफ़ॉर्म के एक emulator/simulator पर 10–20 critical टेस्ट का smoke suite, और staging बैक एंड के ख़िलाफ़ API contract टेस्ट। हर रात emulators और simulators पर shards में बँटा पूरा UI suite, और device farm में Tier 1 और Tier 2 डिवाइस। रिलीज़ से पहले release candidate को Tier 1 और Tier 2 डिवाइस पर चलाया जाता है (बड़ी रिलीज़ से पहले Tier 3 पर भी), असली डिवाइस पर exploratory session होता है, और ऐप का सबसे पुराना सपोर्टेड वर्ज़न नए बैक एंड के ख़िलाफ़ चलता है। Tiers वही हैं जो मोबाइल टेस्टिंग पिलर गाइड के उदाहरण वाले डिवाइस मैट्रिक्स में हैं। हर फ़ेल टेस्ट के लिए: वीडियो, screenshots, डिवाइस log और JUnit XML।

Example mobile pipeline

on every pull request
  1. unit tests (JVM / XCTest unit)
  2. build the app and the test package (test APK / UI test bundle)
  3. UI smoke: 10–20 critical tests on one Android emulator and one iOS simulator
  4. API contract tests against the staging back end
nightly
  5. full UI suite, sharded across emulators and simulators
  6. Tier 1 and Tier 2 real devices in a device farm
before release
  7. release candidate on the Tier 1 and Tier 2 devices (Tier 3 too before a major release)
     + exploratory session on real devices
  8. oldest supported app version against the new back end (API smoke)
for every failed test: video, screenshots, device log, JUnit XML

आज़माएँ: पेयरवाइज़ टेस्टिंग जनरेटर आज़माएँ: API स्कीमा वैलिडेटर

क्या मैन्युअल रहता है

ऑटोमेशन वही जाँचता है जो पूछना आप पहले से जानते हैं। मोबाइल पर कई अहम सवालों का सबसे अच्छा जवाब अब भी असली डिवाइस वाला इंसान देता है: gestures इस्तेमाल में कैसे लगते हैं, जिस डिवाइस के लिए किसी ने script नहीं लिखी उस पर layout ठीक दिखता है या नहीं, असली नेटवर्क पर असली फ़ोन कॉल के दौरान क्या होता है, और क्या ऐप screen reader के साथ इस्तेमाल लायक है। दोनों प्लेटफ़ॉर्म पर ऑटोमेटेड एक्सेसिबिलिटी checks मौजूद हैं — Espresso टेस्ट के दौरान accessibility checks चला सकता है, और XCUITest accessibility audit चला सकता है — और वे missing labels, छोटे touch targets और कम contrast पकड़ते हैं, पर TalkBack या VoiceOver session की जगह नहीं लेते।

• हर release candidate के लिए असली डिवाइस पर exploratory sessions।
• असली इंटरप्शन: कॉल, Bluetooth, दूसरे ऐप के notifications।
• डिवाइसों पर visual review, जब तक आप screenshot टेस्ट maintain नहीं करते।
• Screen reader और बड़े टेक्स्ट वाले sessions।
• सबसे कमज़ोर डिवाइस पर बैटरी, गर्मी और परफ़ॉर्मेंस।
• स्टोर builds: स्टोर या beta channel से ठीक वैसे इंस्टॉल करना जैसे यूज़र करते हैं।

आज़माएँ: टेस्ट डेटा फ़ैक्टरी

अक्सर पूछे जाने वाले सवाल

संदर्भ

• Appium DocumentationAppium (OpenJS Foundation)iOS और Android पर नेटिव, हाइब्रिड और मोबाइल-वेब ऐप के ऑटोमेशन का आधिकारिक दस्तावेज़।
• EspressoAndroid Developers (Google)Android का UI टेस्टिंग फ़्रेमवर्क, जो टेस्ट एक्शन को ऐप के UI थ्रेड के साथ अपने-आप सिंक्रोनाइज़ करता है।
• XCUIAutomationAppleUI टेस्ट के लिए Apple का API जो ऐप लॉन्च करके उसके एलिमेंट से यूज़र की तरह इंटरैक्ट करता है (XCUITest का आधार)।
• XCTestAppleiOS और अन्य Apple प्लेटफ़ॉर्म पर Xcode प्रोजेक्ट के unit, performance और UI टेस्ट के लिए Apple का फ़्रेमवर्क।
• Test apps on AndroidAndroid Developers (Google)Android की आधिकारिक टेस्टिंग गाइडेंस: टेस्ट के प्रकार और दायरा, local बनाम instrumented टेस्ट, और बेहतरीन तरीके।
• Eradicating Non-Determinism in Tests (Martin Fowler)martinfowler.com · 2011flaky टेस्ट सूट का मूल्य क्यों नष्ट करते हैं, उनके आम कारण (isolation, asynchrony, remote services, समय, resource leak) और जवाब के रूप में quarantine।
• Certified Tester Advanced Level Test Automation Engineering (CTAL-TAE) v2.0ISTQB · 2024टेस्ट ऑटोमेशन समाधान और उनकी आर्किटेक्चर के डिज़ाइन, कार्यान्वयन और रखरखाव पर ISTQB का advanced पाठ्यक्रम।
• Certified Tester Mobile Application Testing (CT-MAT)ISTQB · 2019मोबाइल टेस्टिंग पर ISTQB का specialist पाठ्यक्रम: ऐप के प्रकार, डिवाइस व प्लेटफ़ॉर्म की चुनौतियाँ, टेस्ट प्रकार और टूल।