मोबाइल ऐप्लिकेशन में UI परीक्षण: यह क्या है, प्रकार और कैसे किया जाता है

UI परीक्षण क्या है?

UI परीक्षण एक प्रकार की स्वचालित जाँच है जिसमें परीक्षण कोड ऐप्लिकेशन के ग्राफ़िकल इंटरफ़ेस के साथ उसी तरह इंटरैक्ट करता है जैसे एक वास्तविक उपयोगकर्ता करेगा। परीक्षण स्क्रीन पर एक तत्व ढूँढता है — बटन, टेक्स्ट फ़ील्ड, सूची — उस पर कार्रवाई करता है और अपेक्षित इंटरफ़ेस प्रतिक्रिया की पुष्टि करता है। उदाहरण के लिए, गलत पासवर्ड दर्ज करने के बाद, UI परीक्षण जाँचता है कि स्क्रीन पर सही टेक्स्ट के साथ एक त्रुटि संदेश दिखाई दे।

UI परीक्षणों और अन्य प्रकार के ऑटोमेशन के बीच मुख्य अंतर यह है कि वे ऐप्लिकेशन के आंतरिक API के माध्यम से नहीं बल्कि ऑपरेटिंग सिस्टम की एक्सेसिबिलिटी परत के माध्यम से काम करते हैं। इसका मतलब है कि UI परीक्षण इंटरफ़ेस को ठीक वैसे ही देखते हैं जैसे एक उपयोगकर्ता और स्क्रीन रीडर देखते हैं। इसके लिए धन्यवाद, UI परीक्षण न केवल कार्यक्षमता बल्कि तत्वों की पहुँच — WCAG आवश्यकताओं के अनुपालन — की भी जाँच करते हैं।

JetBrains Developer Ecosystem 2023 सर्वेक्षण के अनुसार, 58% मोबाइल टीमें अपने CI/CD पाइपलाइन में UI परीक्षणों का उपयोग करती हैं। वाणिज्यिक परियोजनाओं में औसत UI परीक्षण कवरेज ऐप्लिकेशन स्क्रीन का 30–40% है। UI परीक्षणों वाली परियोजनाओं को इंटरफ़ेस क्रैश से संबंधित ऐप स्टोर में 25% कम नकारात्मक समीक्षाएँ मिलती हैं।

UI परीक्षण यूनिट परीक्षण से कैसे भिन्न है

UI परीक्षणों और यूनिट परीक्षणों के बीच मुख्य अंतर अमूर्तता का स्तर है। यूनिट परीक्षण Android या iOS फ्रेमवर्क से पृथक व्यक्तिगत कक्षाओं और फ़ंक्शनों के साथ काम करते हैं। वे एमुलेटर शुरू किए बिना JVM पर (Android के लिए) चलते हैं और मिलीसेकंड लेते हैं। UI परीक्षण वास्तविक डिवाइस या एमुलेटर पर चलते हैं, सिस्टम सेवाओं के साथ इंटरैक्ट करते हैं और प्रति परिदृश्य सेकंड या मिनट लेते हैं।

परीक्षणों का लक्षित दर्शक भी भिन्न होता है। UI परीक्षण एंड-टू-एंड उपयोगकर्ता परिदृश्यों की जाँच करते हैं — पंजीकरण, ऑर्डर देना, खोज। यूनिट परीक्षण व्यावसायिक तर्क को कवर करते हैं: गणना, सत्यापन, डेटा रूपांतरण। UI परीक्षण कर गणना की सटीकता की जाँच नहीं करता — वह जाँचता है कि कुल राशि स्क्रीन पर प्रदर्शित होती है। गणना स्वयं यूनिट परीक्षण द्वारा सत्यापित की जाती है।

Google Testing Blog (2020) के अनुसार, किसी परियोजना में परीक्षणों का इष्टतम अनुपात परीक्षण पिरामिड नियम का पालन करता है: 70% यूनिट परीक्षण, 20% एकीकरण परीक्षण और 10% UI परीक्षण। UI परीक्षणों के पक्ष में इस अनुपात का उल्लंघन करने से चलने का समय बढ़ जाता है और परीक्षण सूट नाजुक हो जाता है, क्योंकि UI परीक्षण स्क्रीन लेआउट में परिवर्तनों के प्रति संवेदनशील होते हैं।

UI परीक्षण के लिए फ्रेमवर्क

Android के लिए, प्रमुख फ्रेमवर्क Espresso है — Google की लाइब्रेरी जो AndroidX Test में निर्मित है। Espresso स्वचालित रूप से UI थ्रेड के साथ सिंक्रनाइज़ होता है, अगली जाँच से पहले एनिमेशन और पृष्ठभूमि कार्यों के पूरा होने की प्रतीक्षा करता है। Jetpack Compose के लिए, Compose UI Test एक्सटेंशन का उपयोग किया जाता है जो पारंपरिक व्यू पहचानकर्ताओं के बजाय सिमैंटिक नोड्स के माध्यम से काम करता है।

iOS के लिए, प्राथमिक उपकरण XCUITest है, जो Xcode का हिस्सा है। परीक्षण Swift में लिखे जाते हैं और तत्वों को खोजने के लिए एक्सेसिबिलिटी पहचानकर्ताओं का उपयोग करते हैं। XCUITest रिकॉर्ड फ़ंक्शन के माध्यम से परीक्षण रिकॉर्डिंग और xcodebuild के माध्यम से CI सिस्टम के साथ एकीकरण का समर्थन करता है। क्रॉस-प्लेटफ़ॉर्म परियोजनाओं के लिए, Appium का उपयोग किया जाता है, जो WebDriver प्रोटोकॉल पर आधारित है और न्यूनतम कोड परिवर्तनों के साथ Android और iOS पर समान परीक्षण चलाने की अनुमति देता है।

Espresso और Compose UI Test

Espresso onView और संसाधन id पहचानकर्ताओं के माध्यम से पारंपरिक व्यू सिस्टम के साथ काम करता है। Compose UI Test एक सिमैंटिक परत का उपयोग करता है, जिससे परीक्षण व्यू पदानुक्रम पर कम निर्भर होते हैं। उदाहरण के लिए, Espresso में बटन खोजना: onView(withId(R.id.submit)), Compose में: onNodeWithTag(“submit”)। Compose परीक्षण स्वचालित रूप से पुनर्संरचना को संभालते हैं और स्पष्ट निष्क्रिय स्थिति प्रतीक्षा की आवश्यकता नहीं होती।

iOS के लिए XCUITest

XCUITest प्रवेश बिंदु के रूप में XCUIApplication का उपयोग करता है। प्रत्येक इंटरफ़ेस तत्व एक्सेसिबिलिटी गुणों के माध्यम से पाया जाता है: प्रोग्रामेटिक पहुँच के लिए accessibilityIdentifier और VoiceOver के लिए accessibilityLabel। फ्रेमवर्क Xcode के रिकॉर्ड फ़ंक्शन के माध्यम से परीक्षण रिकॉर्डिंग का समर्थन करता है — डेवलपर सिम्युलेटर पर क्रियाएँ करता है, और Xcode परीक्षण कोड उत्पन्न करता है। तैयार परीक्षण xcodebuild test के माध्यम से चलाए जाते हैं।

क्रॉस-प्लेटफ़ॉर्म समाधान

Appium WebDriver प्रोटोकॉल पर आधारित है और किसी भी भाषा का समर्थन करता है: Java, Python, JavaScript। तत्व खोज रणनीतियों में id, xpath, class name और accessibility id शामिल हैं। Appium के लिए सर्वर स्थापना और Desired Capabilities — platformName, deviceName, appPackage — के कॉन्फ़िगरेशन की आवश्यकता होती है। एक विकल्प Maestro है, जो YAML परिदृश्यों का उपयोग करता है और परीक्षण कोड संकलन की आवश्यकता नहीं होती।

• Espresso — onView(withId(R.id.button)).perform(click()).check(matches(isDisplayed()))
• XCUITest — app.buttons[“loginButton”].tap(); XCTAssertTrue(app.staticTexts[“welcome”].exists)
• Appium — driver.findElement(By.id(“com.example:id/button”)).click()
• Detox — React Native के लिए Wix का फ्रेमवर्क, JS थ्रेड के साथ सिंक्रनाइज़ होता है
• Maestro — YAML परिदृश्यों वाला आधुनिक उपकरण जिसमें कोड लिखने की आवश्यकता नहीं है

UI परीक्षणों के लिए कोड उदाहरण

आइए तीन अलग-अलग फ्रेमवर्क पर एक ही परिदृश्य — ऐप्लिकेशन में लॉगिन — के लिए UI परीक्षण देखें: Android के लिए Espresso, iOS के लिए XCUITest और क्रॉस-प्लेटफ़ॉर्म दृष्टिकोण के लिए Appium। परिदृश्य: लॉगिन और पासवर्ड दर्ज करें, लॉगिन बटन दबाएँ, स्वागत संदेश के प्रदर्शन की पुष्टि करें।

Android: Espresso

Espresso परीक्षण किसी तत्व को उसके पहचानकर्ता द्वारा खोजने के लिए onView और कार्रवाई करने के लिए perform का उपयोग करता है। isDisplayed मैचर के साथ check विधि पुष्टि करती है कि तत्व स्क्रीन पर दिखाई दे रहा है।

@RunWith(AndroidJUnit4::class)
class LoginUiTest {

    @Rule
    @JvmField
    val composeTestRule = createComposeRule()

    @Test
    fun login_withValidCredentials_showsWelcome() {
        composeTestRule
            .onNodeWithTag("emailField")
            .performTextInput("user@example.com")
        composeTestRule
            .onNodeWithTag("passwordField")
            .performTextInput("secret123")
        composeTestRule
            .onNodeWithTag("loginButton")
            .performClick()
        composeTestRule
            .onNodeWithText("स्वागत है, उपयोगकर्ता!")
            .assertIsDisplayed()
    }
}

iOS: XCUITest

XCUITest एक्सेसिबिलिटी पहचानकर्ताओं के माध्यम से इंटरफ़ेस तत्वों तक पहुँचने के लिए XCUIApplication का उपयोग करता है। tap() और exists विधियाँ इंटरैक्शन और सत्यापन प्रदान करती हैं।

class LoginUITests: XCTestCase {
    let app = XCUIApplication()

    override func setUp() {
        continueAfterFailure = false
        app.launch()
    }

    func testLogin_withValidCredentials_showsWelcome() {
        app.textFields["emailField"].tap()
        app.textFields["emailField"].typeText("user@example.com")
        app.secureTextFields["passwordField"].tap()
        app.secureTextFields["passwordField"].typeText("secret123")
        app.buttons["loginButton"].tap()
        XCTAssertTrue(app.staticTexts["Welcome, User!"].exists)
    }
}

UI परीक्षण की सर्वोत्तम प्रथाएँ

पहला सिद्धांत — तत्वों को खोजने के लिए टेक्स्ट लेबल के बजाय एक्सेसिबिलिटी पहचानकर्ताओं का उपयोग करें। बटन का टेक्स्ट स्थानीयकरण के दौरान बदल सकता है, जबकि पहचानकर्ता स्थिर रहता है। Android में, यह contentDescription गुण है; iOS में — accessibilityIdentifier। यह दृष्टिकोण परीक्षणों को इंटरफ़ेस भाषा से स्वतंत्र बनाता है और कॉपीराइटिंग बदलने पर रखरखाव लागत कम करता है।

sleep() और निश्चित विलंब से बचें — फ्रेमवर्क के अंतर्निहित प्रतीक्षा तंत्र का उपयोग करें। Espresso स्वचालित रूप से एनिमेशन और पृष्ठभूमि कार्यों के पूरा होने की प्रतीक्षा करता है। XCUITest टाइमआउट के साथ XCTAssertTrue प्रदान करता है। स्पष्ट ठहराव परीक्षणों को धीमा और अस्थिर बनाते हैं, विशेषकर CI वातावरण में धीमे उपकरणों पर।

परीक्षणों को गंभीरता के अनुसार समूहित करें: स्मोक परीक्षण (3–5 प्रमुख परिदृश्य) प्रत्येक कमिट पर चलते हैं, पूर्ण UI परीक्षण सूट रिलीज़ से पहले चलता है। Google Testing Blog (2022) के अनुसार, CI में 30 मिनट से अधिक लेने वाले UI परीक्षण चलने की आवृत्ति को 40% कम कर देते हैं, जिससे प्रारंभिक रिग्रेशन डिटेक्शन टूल के रूप में उनकी प्रभावशीलता कम हो जाती है।

UI परीक्षणों की सीमाएँ और उन्हें कैसे दूर करें

UI परीक्षणों की कई सीमाएँ हैं। लेआउट परिवर्तनों के प्रति संवेदनशीलता: पहचानकर्ता, पदानुक्रम या तत्व प्रकार बदलने से परीक्षण टूट जाता है भले ही कार्यक्षमता अपरिवर्तित रहे। समाधान पेज ऑब्जेक्ट पैटर्न का उपयोग करना है, जो अलग-अलग कक्षाओं में तत्व चयनकर्ताओं को केंद्रीकृत करता है। लेआउट बदलने पर, दर्जनों परीक्षणों के बजाय एक पेज ऑब्जेक्ट फ़ाइल में संशोधन किया जाता है।

निष्पादन समय: वास्तविक डिवाइस या एमुलेटर पर चलने में यूनिट परीक्षण की तुलना में 10–50 गुना अधिक समय लगता है। समाधान Firebase Test Lab या AWS Device Farm के माध्यम से कई उपकरणों पर UI परीक्षणों को समानांतर चलाना है। अस्थिरता (flakiness) CI रन की एक सामान्य समस्या है जो एनिमेशन, नेटवर्क विलंब या एमुलेटर स्थिति के कारण होती है। अस्थिरता से निपटने के लिए, विफल परीक्षणों के स्वचालित पुनर्प्रयास और प्रत्येक परीक्षण परिदृश्य की स्थिरता विश्लेषण का उपयोग किया जाता है।