डीप लिंक टेस्टिंग

यह क्यों ज़रूरी है

Deep links अहम पलों से जुड़े होते हैं: कोई campaign, password reset, delivery update। जब कोई link टूटता है तो failure चुपचाप होता है। User home screen पर पहुँचता है, "not found" कहने वाले web page पर, या इससे भी बुरा, किसी और के data पर, और team को support tickets से पता चलता है। कई कारण app के code से बाहर होते हैं: website पर कोई file, signing certificate, या email tool का जोड़ा हुआ redirect, इसलिए app के अंदर से शुरू होने वाले सामान्य UI tests इन्हें नहीं पकड़ते।

Deep link app के बाहर से आने वाला input भी है। कोई भी इसे बना सकता है, इसलिए app को इसे validate करना चाहिए, और सिर्फ़ इसलिए कि link ने कहा, कभी sign-in skip नहीं करना चाहिए या बिना confirmation कोई action नहीं करना चाहिए। Tester के लिए यह छोटा पर बहुत कीमती area है: जब आप जानते हैं कि कौन-सी states और platform rules मिलाने हैं, तो combinations का एक छोटा, सोच-समझकर चुना set असली risks cover कर लेता है।

Custom schemes, Android App Links और iOS Universal Links

Custom URL scheme link वह scheme इस्तेमाल करता है जो app अपने लिए register करता है, जैसे shop://orders/A-1042। यह आसान है, लेकिन कुछ भी साबित नहीं करता कि scheme आपके app का है: कोई दूसरा app वही scheme register कर सकता है, और जब कोई installed app उसे handle नहीं करता तो link बस fail हो जाता है। इसे अपने products के अंदर के links के लिए रखें, users को भेजे जाने वाले links के लिए नहीं।

Android App Links सामान्य https links हैं जिन्हें Android verify करता है। App intent filter (manifest का वह हिस्सा जो बताता है कि app कौन-से links खोल सकता है) में android:autoVerify="true" के साथ domain declare करता है, और website /.well-known/assetlinks.json publish करती है जिसमें app का package name और उसके signing certificate का SHA-256 fingerprint होता है। Verification सफल हो तो link सीधे app खोलता है। Android 12 से unverified https link default browser में खुलता है, जब तक user ने app की settings में उस domain को approve न किया हो।

iOS Universal Links भी इसी विचार पर चलते हैं। App अपने Associated Domains entitlement (applinks:shop.example.com) में domain लिखता है, और website एक apple-app-site-association file publish करती है जो app और उसके handle किए जाने वाले paths बताती है। iOS 14 से devices यह file Apple के content delivery network (CDN) से लेते हैं। CDN को कोई बदलाव उठाने में 24 घंटे तक लग सकते हैं, और device app install होते समय file download करता है और फिर लगभग हफ़्ते में एक बार ही update देखता है; इसलिए fix के बाद CDN का इंतज़ार करें और test device पर app दोबारा install करें। Safari के address bar में type किया गया universal link website खोलता है, और जब user Safari में उसी site पर हो तब same-domain link पर tap भी: यह platform का behaviour है, defect नहीं।

• दोनों files HTTPS पर valid certificate के साथ और बिना redirect के serve होती हैं; assetlinks.json content type application/json के साथ।
• हर Android build एक key से sign होता है, और fingerprint उस key के certificate की पहचान है। यह उस key से match होना चाहिए जिसने installed build sign किया: debug builds, release builds और Google Play App Signing से re-sign हुए builds के fingerprints अलग होते हैं, और file में कई fingerprints हो सकते हैं।
• iOS file का कोई .json extension नहीं होता, और उसके paths app के हर installed version पर लागू होते हैं, पुराने versions पर भी।
• Deferred deep linking, यानी store से app install करने के बाद target तक पहुँचना, platform feature नहीं है। Requirement इसे माँगे तो आपकी team या कोई third-party SDK इसे बनाता है, और इसके अपने tests चाहिए।

https://shop.example.com/.well-known/assetlinks.json  (Android App Links)
[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example.shop",
    "sha256_cert_fingerprints": ["14:6D:E9:...:2E:5F"]
  }
}]

https://shop.example.com/.well-known/apple-app-site-association  (iOS Universal Links)
{
  "applinks": {
    "details": [{
      "appIDs": ["ABCDE12345.com.example.shop"],
      "components": [{ "/": "/orders/*" }]
    }]
  }
}

आज़माएँ: JSON वैलिडेटर आज़माएँ: URL पार्सर

Installed है या नहीं, signed in है या नहीं

एक ही link को कई states में टेस्ट करें, क्योंकि हर state अलग रास्ता लेती है। Installed नहीं: custom-scheme link fail होता है, जबकि verified https link उसी URL पर website खोलता है, इसलिए वह URL असली page होना चाहिए, बेहतर हो कि app पाने का रास्ता भी दे, कभी 404 नहीं। Installed पर verified नहीं: app होते हुए भी website खुलती है, जो गलत fingerprint या टूटी association file का आम संकेत है। पुराना version installed: अनजाने path पर app को crash होने की बजाय किसी समझदार screen पर fallback करना चाहिए।

App किस हाल में चल रहा है, यह भी मायने रखता है। App बंद हो तब आया link उसे शुरू से start करता है; background में हो या कोई दूसरी screen दिखा रहा हो तब आया link अलग code से गुज़रता है। दोनों टेस्ट करें, और देखें कि बाद में Back कहाँ ले जाता है।

फिर user। Signed out: sign-in screen आती है और sign-in सफल होने के बाद linked screen खुलती है, home screen नहीं। Owner के रूप में signed in: सही record खुलता है। किसी दूसरे user के रूप में signed in: साफ़ not-available message और owner का कोई data नहीं, जिसे server enforce करे, सिर्फ़ app न छिपाए। Session expired या install के बाद पहला launch: re-authentication, onboarding या permission prompt link को निगल न जाए।

आज़माएँ: पेयरवाइज़ टेस्टिंग जनरेटर

Links चलाना और verification जाँचना

Links उन channels से tap करें जो users सच में इस्तेमाल करते हैं: email app, SMS, कोई chat app, camera से scan किया QR code, push notification। कुछ apps links अपने in-app browser में खोलते हैं, जो उन्हें आपके app को शायद न सौंपे, और email click tracking अक्सर link को किसी दूसरे domain से होकर जाने वाले redirect में लपेट देती है जो आपके app से associated नहीं है। Link ठीक वैसे टेस्ट करें जैसे वह भेजा जाता है, ticket में लिखा साफ़ URL नहीं।

तेज़ और दोहराने लायक checks के लिए platform tools इस्तेमाल करें। Android पर adb link fire करता है और handler चुनना system पर छोड़ता है, और Android 12 से domain verification दिखाता और दोबारा चलाता है। iOS Simulator पर simctl URL खोलता है; असली iPhone पर link को Notes या Messages में paste करके tap करें।

# Android: fire the link and let the system choose the app (no package name)
adb shell am start -W -a android.intent.action.VIEW \
  -c android.intent.category.BROWSABLE \
  -d "https://shop.example.com/orders/A-1042"

# Android 12+: domain verification state, then a fresh verification
adb shell pm get-app-links com.example.shop
adb shell pm verify-app-links --re-verify com.example.shop

# iOS Simulator: open the link through the system
xcrun simctl openurl booted "https://shop.example.com/orders/A-1042"

आज़माएँ: रीडायरेक्ट चेकर

Worked example: shipping email में order link

Requirement: "Shipping email में order का link है। App हो तो link order details खोलता है; app न हो तो website पर order page।" Link https://shop.example.com/orders/A-1042 है और order सारा का है। शुरुआत चार true/false conditions पर बनी decision table से करें: installed, verified, signed in और owner। Table का हर column इन चार conditions का एक combination है, साथ में वह screen जिस पर link को पहुँचना चाहिए, और ये columns मुख्य cases देते हैं; decision table testing का lesson बताता है कि table कैसे बनाएँ और उन columns को कैसे merge करें जिनमें कोई condition नतीजा नहीं बदलती। फिर हर चीज़ को गुणा करने की बजाय सबसे ज़्यादा risk वाले columns में running-state और channel variations जोड़ें।

• Installed, सारा signed in, app बंद: order A-1042 खुलता है, और Back तय किए मुताबिक orders list पर ले जाता है।
• वही, app background में cart screen पर: order A-1042 खुलता है और cart नहीं बदलता।
• Installed, signed out: sign-in screen आती है; सारा के sign in करने के बाद order A-1042 खुलता है, home screen नहीं।
• Installed, कोई दूसरा user signed in: not-available message, A-1042 का कोई data नहीं, और API उस order की request ठुकरा देता है।
• Installed नहीं: website पर order page खुलता है (web sign-in के बाद), store के link के साथ; कोई 404 नहीं।
• assetlinks.json में न दी गई key से signed build: website खुलती है और pm get-app-links domain को verified नहीं दिखाता। इसे screen के नहीं, configuration के ख़िलाफ़ report करें।
• अनजाना, खाली या बहुत लंबा id (/orders/A-9999, /orders/, 300 characters): साफ़ error screen, कोई crash नहीं।
• असली email, उसके click-tracking redirect के साथ, हर supported email app में: साफ़ link जैसा ही result।

आज़माएँ: डिसीज़न टेबल जनरेटर आज़माएँ: टेस्ट केस जनरेटर

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

संदर्भ

• About App LinksAndroid Developers (Google)Android App Links: आपकी अपनी वेबसाइट के deep links जिन्हें सिस्टम Digital Asset Links फ़ाइल (assetlinks.json) से verify करता है, ताकि वे सीधे ऐप में खुलें।
• Allowing apps and websites to link to your contentAppleApple प्लेटफ़ॉर्म पर universal links: सामान्य वेब लिंक जो ऐप इंस्टॉल होने पर — सिस्टम द्वारा आपकी वेबसाइट की एक फ़ाइल जाँचने के बाद — ऐप खोलते हैं, वरना वेबसाइट।
• OWASP Mobile Application Security Testing Guide (MASTG)OWASP FoundationMASVS के साथ चलने वाला टेस्टिंग मैनुअल: मोबाइल ऐप सुरक्षा जाँचने की तकनीकें और टेस्ट केस।
• OWASP Mobile Application Security Verification Standard (MASVS)OWASP Foundationमोबाइल ऐप के लिए OWASP की सुरक्षा आवश्यकताएँ, storage, cryptography, authentication, network और platform interaction जैसे नियंत्रण समूहों में।