Appium वांछित क्षमताएं Android एमुलेटर

वांछित क्षमताएं क्या हैं?

'वांछित क्षमताएं' हमें स्वचालन के दौरान सर्वर के व्यवहार को संशोधित करने में मदद करती हैं। Appium यह एक हैशमैप या कुंजी-मान युग्म है, जिसका उपयोग किसी कमांड को भेजने के लिए किया जाता है। Appium सर्वर, जहां प्रत्येक क्लाइंट कमांड एक सत्र के संदर्भ में चलता है।

उदाहरण के लिए, एक क्लाइंट JSON ऑब्जेक्ट युक्त POST /session अनुरोध भेजता है। Appium सर्वर.

इसलिए, सर्वर के साथ अनुरोध भेजने या सत्र बनाए रखने के लिए, कुंजी और मान युग्मों के एक समूह का उपयोग किया जाता है। इसे 'वांछित क्षमताएं' कहा जाता है।

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");
}

वांछित क्षमता की महत्वपूर्ण भूमिका

• 'DesiredCapabilities' उपयोगकर्ता को सर्वर के साथ सत्र अनुरोध को नियंत्रित करने में मदद करती हैं। उदाहरण के लिए, iOS सत्र के लिए हम platformName = iOS क्षमता सेट करते हैं, और एक अन्य सत्र के लिए Android सत्र platformName = Android.
• 'DesiredCapabilities' का उपयोग WebDriver इंस्टेंस को सेट अप करने के लिए किया जाता है, उदाहरण के लिए Firefoxड्राइवर, क्रोम ड्राइवर या इंटरनेट एक्सप्लोरर ड्राइवर।
• DesiredCapability बहुत उपयोगी है Selenium ग्रिड। उदाहरण के लिए, इसका उपयोग विभिन्न ब्राउज़रों और विभिन्न ऑपरेटिंग सिस्टमों पर अलग-अलग परीक्षण मामलों को चलाने के लिए किया जाता है। बताई गई क्षमता के आधार पर, ग्रिड हब संबंधित नोड को इंगित करता है। नोड्स को 'सेट' प्रॉपर्टी विधियों का उपयोग करके परिभाषित किया जाता है:

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

• वांछित क्षमता एक लाइब्रेरी-परिभाषित पैकेज है। 'DesiredCapabilities' का उपयोग करने से पहले, इसे नीचे दी गई लाइब्रेरी से आयात किया जाना चाहिए।

  Org.openqa.selenium.remote.DesiredCapabilities

Appium दोनों का समर्थन करता है Android और iOS, इसलिए एक अलग सेट है Appium प्रत्येक प्लेटफ़ॉर्म के लिए सर्वर क्षमताएँ।

नीचे दी गई तालिका में कुछ सामान्य रूप से उपयोग किए जाने वाले उदाहरण दिखाए गए हैं। Android क्षमताओं और उपयोग किए जाने वाले मूल्यों का निर्धारण।

नोट: कृपया देखें Appium दस्तावेज़ीकरण और अधिक देखने के लिए Android क्षमताओं.

नीचे दी गई तालिका में iOS की कुछ सामान्य रूप से उपयोग की जाने वाली क्षमताएं और उनके उपयोग के लिए मान दर्शाए गए हैं।

नोट: कृपया देखें Appium क्षमता मार्गदर्शिका iOS की और अधिक क्षमताओं को देखने के लिए।

वांछित क्षमताओं में किस प्रकार परिवर्तन आया Appium 2

ऊपर दिए गए उदाहरण निम्नलिखित से लिए गए हैं: Appium एक युग अभी भी क्षमता समूह का आकार दिखाता है, लेकिन दो नियम बदल गए हैं और दोनों ही आधुनिक सत्र को शुरू होने से रोकेंगे।

सबसे पहले, W3C वेबड्राइवर विनिर्देश केवल कुछ ही मानक क्षमताओं को परिभाषित करता है, जिनमें से platformName और browserName यहां ध्यान देने वाली बात यह है कि अन्य सभी क्षमताएं विक्रेता द्वारा विस्तारित की गई हैं और उनमें एक कॉलन पर समाप्त होने वाला नेमस्पेस उपसर्ग होना चाहिए। Appium's उपसर्ग है appium:. इतना deviceName हो जाता है appium:deviceName और platformVersion हो जाता है appium:platformVersion. Appium 2 की भी आवश्यकता है appium:automationNameक्योंकि ड्राइवर सर्वर के साथ बंडल होने के बजाय अलग से इंस्टॉल किए जाते हैं।

दूसरा, उपसर्ग को दोहराना थकाऊ हो जाता है, इसलिए Appium एकल स्वीकार करता है appium:options एक ऐसी क्षमता जिसका मान एक ऑब्जेक्ट है। उस ऑब्जेक्ट के भीतर की क्षमताओं को किसी उपसर्ग की आवश्यकता नहीं होती है, और जहां ऑब्जेक्ट के अंदर और बाहर दोनों जगह नाम दिखाई देता है, वहां आंतरिक मान मान्य होता है।

{
    "platformName": "iOS",
    "appium:options": {
        "automationName": "XCUITest",
        "platformVersion": "16.0",
        "app": "/path/to/your.app",
        "deviceName": "आईफोन 12",
        "noReset": true
    }
}

⚠️ संस्करण नोट: पर Java पक्ष, Selenium 4 और Appium Java क्लाइंट 8 ने इसे अप्रचलित कर दिया DesiredCapabilities पहले दिखाई गई क्लास। ड्राइवर-विशिष्ट बिल्डर्स से विरासत में प्राप्त। BaseOptions इसे बदल दें — UiAutomator2Options एसटी Android और XCUITestOptions iOS के लिए — एक-से-एक मानचित्र के साथping प्रत्येक पुराने से setCapability कॉल। ऊपर दिया गया मूल कोड ऐतिहासिक उदाहरण के रूप में यहां रखा गया है।

Extracपैकेज और गतिविधियों की जानकारी

पैकेज बंडल की गई फाइलें या क्लास होती हैं। वे मॉड्यूलर प्रोग्रामिंग को एक संगठित संरचना प्रदान करते हैं। Javaविभिन्न पैकेजों को एक ही JAR फ़ाइल में संग्रहित किया जाता है, और उपयोगकर्ता पूर्ण निष्पादन के लिए उस JAR को कॉल कर सकता है। मोबाइल एप्लिकेशन विकास में भी इसी तरह की अवधारणा का पालन किया जाता है।

में Android ऑपरेटिंग सिस्टम में, सभी एप्लिकेशन इस रूप में स्थापित होते हैं: Java पैकेज। तो, पूर्व के लिएtracटी पैकेज पथ जानकारी, Android पैकेज मैनेजर वर्ग का उपयोग किया जाता है।

यह डिवाइस पर पहले से इंस्टॉल किए गए और बाद में इंस्टॉल किए गए एप्लिकेशन के लिए पैकेज और गतिविधि की जानकारी प्राप्त करता है।

आप getPackageManager() मेथड को कॉल करके PackageManager क्लास का इंस्टेंस प्राप्त कर सकते हैं। यह मेथड इंस्टॉल किए गए एप्लिकेशन के पैकेज और संबंधित अनुमतियों तक पहुंच और उनमें बदलाव कर सकता है।

उदाहरण के लिए:

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

adb का उपयोग करके appPackage और appActivity कैसे खोजें

ऊपर दिया गया PackageManager तरीका किसी एप्लिकेशन के अंदर से काम करता है। एक टेस्टर के रूप में आपके पास आमतौर पर केवल इंस्टॉल किया गया बिल्ड होता है, इसलिए तेज़ तरीका क्वेरी के माध्यम से होता है। एशियाई विकास बैंक किसी कनेक्टेड डिवाइस या एमुलेटर के विरुद्ध।

एप्लिकेशन को डिवाइस पर मैन्युअल रूप से खोलें, फिर platform-tools फ़ोल्डर में टर्मिनल से नीचे दिए गए कमांड में से एक को चलाएँ। यह कमांड वर्तमान में फ़ोकस में मौजूद विंडो का मान प्रिंट करता है, और मान को इस प्रकार फ़ॉर्मेट किया जाता है। package/activity.

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

पहले फॉर्म का प्रयोग करें Windows कमांड प्रॉम्प्ट में और दूसरे को यूनिक्स शेल या गिट बैश में पढ़ें। परिणाम को दो भागों में पढ़ें: स्लैश से पहले का सब कुछ मान है। appPackageऔर इसके बाद जो कुछ भी है, वह उसका मूल्य है। appActivity.

दो सावधानियां लागू होती हैं। फोकस की गई गतिविधि वह है जो उस समय स्क्रीन पर होती है, जो हमेशा वह गतिविधि नहीं होती जिससे एप्लिकेशन शुरू होता है - यदि ड्राइवर आरंभीकरण के दौरान कोई सत्र विफल हो जाता है, तो ऐप को नए सिरे से लॉन्च करें और मान को दोबारा पढ़ें। और यदि पहले स्प्लैश स्क्रीन दिखाई देती है, तो प्रवेश गतिविधि उस गतिविधि से भिन्न होगी जिसके विरुद्ध आप अंततः दावा करना चाहते हैं, और यही स्थिति है। appWaitActivity के लिए मौजूद है।

एक दृश्य विकल्प यह है uiautomatorviewerजो वर्तमान स्क्रीन पदानुक्रम को कैप्चर करता है और प्रत्येक नोड के पैकेज और क्लास को दिखाता है।

वांछित क्षमताओं से संबंधित सामान्य त्रुटियाँ और उन्हें ठीक करने के तरीके

अधिकांश असफल Appium एक भी टेस्ट स्टेप चलने से पहले ही सेशन समाप्त हो जाते हैं, और इसका कारण लगभग हमेशा टेस्ट की बजाय कैपेबिलिटी सेट में होता है। नीचे दी गई तालिका प्रत्येक संदेश को उसके सामान्य समाधान से जोड़ती है।

जब कोई सेशन शुरू होने से मना कर दे, तो पढ़ें Appium क्लाइंट स्टैक के बजाय सर्वर लॉग tracई. सर्वर बताता है कि वह किस क्षमता को पूरा नहीं कर सका, और उस पंक्ति में समाधान का नाम दिया गया है।

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