मोबाइल एप्लिकेशन में इंटरप्ट परीक्षण
थॉमस हैमिल्टन
⚡ स्मार्ट सारांश
इंटरप्ट टेस्टिंग यह जांच करती है कि कॉल, अलार्म, नोटिफिकेशन या नेटवर्क ड्रॉप होने पर मोबाइल एप्लिकेशन कैसे व्यवहार करता है, और क्या रुकावट समाप्त होने के बाद एप्लिकेशन अपनी पिछली स्थिति में वापस आ जाता है।
इंटरप्ट परीक्षण क्या है?
व्यवधान परीक्षण मोबाइल एप्लिकेशन टेस्टिंग की एक शाखा है जो इस बात से संबंधित है कि कोई एप्लिकेशन किसी रुकावट पर कैसे प्रतिक्रिया करता है और अपनी पिछली स्थिति में कैसे वापस आता है। रुकावट एप्लिकेशन के बाहर से आती है — ऑपरेटिंग सिस्टम, हार्डवेयर या किसी अन्य ऐप से — और यह परीक्षण सत्यापित करता है कि नियंत्रण वापस आने पर कोई डेटा, स्क्रीन स्थिति या प्रगति पर चल रहा लेनदेन नष्ट नहीं होता है।
इंटरप्ट टेस्टिंग किसी भी प्रकार के एप्लिकेशन पर लागू होती है — वेब, मोबाइल, स्टैंडअलोन, इत्यादि। उपकरणों, नेटवर्कों और कॉन्फ़िगरेशन की विविधता इसे और भी अधिक महत्वपूर्ण बनाती है। मोबाइल अन्य अनुप्रयोगों की तुलना में इनके लिए अधिक आवेदन हैं।
आपको इंटरप्ट परीक्षण की आवश्यकता क्यों है?
मीटिंग के दौरान लगभग हमेशा क्या होता है? कोई न कोई आपको बीच में टोक देता है, है ना? ऐसा होने पर कुछ लोग पलक भी नहीं झपकाते, कुछ को स्थिति समझने में एक मिनट लग जाता है, और कुछ लोग अपनी बात पूरी तरह से भूल जाते हैं। सरल शब्दों में कहें तो, इंटरप्ट टेस्टिंग यह पता लगाने की कोशिश करती है कि आपका एप्लिकेशन ऐसा ही व्यवहार दिखाता है।
कुछ देर के लिए तकनीकी शब्दों को दरकिनार रखते हुए एक वास्तविक स्थिति पर विचार करें। मान लीजिए आपके पास एक टॉर्च है और आप उसे चालू करते हैं। बैटरी खत्म हो जाती है, जिससे उसकी सक्रियता बाधित हो जाती है। बैटरी बदलें और उसे फिर से चालू करें। टॉर्च सामान्य रूप से चालू हो जानी चाहिए। यही इसका उदाहरण है। परीक्षण की वह विधा जो इस बात पर केंद्रित होती है कि ऐसा होता है या नहीं, उसे इंटरप्ट टेस्टिंग कहते हैं।
इसका व्यावसायिक पहलू सीधा-सादा है। रुकावट सबसे खराब समय पर आती है—भुगतान के बीच में, अपलोड के बीच में, फॉर्म भरने के बीच में—और जिस उपयोगकर्ता का काम बर्बाद हो जाता है, वह शायद ही दोबारा कोशिश करता है। दोबारा शुरू करने पर क्रैश होना, खाली स्क्रीन, लेन-देन की डुप्लीकेट कॉपी और फॉर्म में दर्ज जानकारी का खो जाना, ये सभी ऐसी खामियां हैं जो केवल रुकावट आने पर ही सामने आती हैं, इसीलिए ये खामियां बिना किसी रुकावट के काम करती रहती हैं।
मोबाइल एप्लीकेशन में रुकावट के प्रकार
व्यवधानों को कुछ परिचित समूहों में बांटा जा सकता है, जिन्हें नीचे दिए गए चित्र में संक्षेप में दर्शाया गया है।
हम सभी सामान्य रूप से होने वाली रुकावटों से परिचित हैं। यहाँ उनमें से कुछ के उदाहरण दिए गए हैं:
- कम बैटरी
- बैटरी पूरी तरह चार्ज हो रही है
- आने वाली फ़ोन कॉल
- इनकमिंग एसएमएस
- किसी अन्य मोबाइल एप्लिकेशन से आने वाली सूचना
- चार्जिंग के लिए प्लग इन करें
- चार्जिंग से प्लग आउट
- डिवाइस बंद हो गया
- एप्लिकेशन अपडेट अनुस्मारक
- अलार्म
- नेटवर्क कनेक्शन हानि
- नेटवर्क कनेक्शन बहाली
यह सूची संपूर्ण नहीं है, लेकिन इसमें सबसे आम स्थितियाँ शामिल हैं। इसे व्यवस्थित करने का एक व्यावहारिक तरीका उत्पत्ति के आधार पर है: डिवाइस-आधारित घटनाएँ जैसे बैटरी और चार्जिंग, उपयोगकर्ता द्वारा शुरू की गई घटनाएँ जैसे कॉल का जवाब देना या ऐप्स स्विच करना, और बाहरी घटनाएँ जैसे लिफ्ट या सुरंग में सिग्नल खो जाना।
व्यवधान की स्थिति में समाधान
इन व्यवधानों की स्थिति में अपेक्षित व्यवहार निम्नलिखित चार में से एक होगा:
- पृष्ठभूमि में चलो: व्यवधान शुरू हो जाता है और एप्लिकेशन कुछ समय के लिए निष्क्रिय हो जाता है। व्यवधान समाप्त होने पर एप्लिकेशन फिर से सक्रिय हो जाता है। उदाहरण के लिए, iBooks (या इसी तरह के किसी एप्लिकेशन) पर डिजिटल पुस्तक पढ़ते समय आप किसी फ़ोन कॉल या फेसटाइम कॉल का जवाब देते हैं। जब उपयोगकर्ता फ़ोन उठाता है, तो iBooks कॉल समाप्त होने तक प्रतीक्षा करता है और कॉल समाप्त होने पर फिर से सक्रिय हो जाता है।
- चेतावनी दिखाएँ: अलर्ट गायब हो जाता है और आप सामान्य रूप से काम करते रहते हैं। हेडर में "एसएमएस प्राप्त हुआ" संदेश दिखाई देता है। उपयोगकर्ता इस पर ध्यान नहीं देता और सामान्य रूप से एप्लिकेशन का उपयोग जारी रखता है। फेसबुक पर नए मित्र अनुरोध या व्हाट्सएप संदेश जैसे अन्य मोबाइल ऐप अलर्ट भी इसी श्रेणी में आते हैं। लेकिन यदि उपयोगकर्ता संदेश पढ़ने का निर्णय लेता है, तो बिंदु 1 में वर्णित व्यवहार का पालन किया जाता है। यदि अलर्ट को अनदेखा किया जाता है, तो एप्लिकेशन की स्थिति अपरिवर्तित रहती है।
- कार्यवाई के लिए बुलावा: काम जारी रखने से पहले अलार्म बंद करना या स्नूज़ करना ज़रूरी है। ऐप अपडेट संदेशों के लिए भी यही नियम लागू होता है। आगे बढ़ने से पहले आपको बदलावों को रद्द करना या स्वीकार करना होगा। एक और उदाहरण है कम बैटरी अलर्ट - आप चाहें तो सामान्य रूप से काम जारी रख सकते हैं या डिवाइस की अनुमति होने पर लो पावर मोड में जा सकते हैं।
- कोई प्रभाव नहीं: उदाहरण के लिए, नेटवर्क कनेक्शन उपलब्ध होने पर आपका डिवाइस उससे कनेक्ट हो जाता है। साथ ही, जब आप अपने डिवाइस को चार्जिंग के लिए प्लग इन करते हैं, तो किसी अलर्ट या कार्रवाई की आवश्यकता नहीं होती है। यह संभवतः अपना काम तब तक करता रहेगा जब तक आप अपने एप्लिकेशन का उपयोग करते रहेंगे।
इसलिए, आप जिस व्यवधान का परीक्षण कर रहे हैं, उसके आधार पर व्यवहार को समझें और देखें कि आपका एप्लिकेशन उसे पूरा करता है या नहीं। साथ ही, ऊपर वर्णित व्यवहार सभी एप्लिकेशन और डिवाइस के लिए समान नहीं हो सकता है। अपने मोबाइल ऐप के लिए विशिष्ट विवरण अवश्य प्राप्त करें।
अपेक्षित परिणामों सहित इंटरप्ट टेस्टिंग टेस्ट केस
एक बार अपेक्षित समाधान पर सहमति हो जाने के बाद, प्रत्येक व्यवधान एक ट्रिगर, एक क्रिया और एक सत्यापन योग्य परिणाम के साथ एक सामान्य परीक्षण मामला बन जाता है। नीचे दी गई तालिका दर्शाती है कि ऊपर दिए गए चार समाधान ठोस परिदृश्यों में कैसे परिवर्तित होते हैं।
| व्यवधान | परीक्षण परिदृश्य | अपेक्षित परिणाम |
| आने वाली फ़ोन कॉल | जब फॉर्म आधा भरा हो, तब कॉल ट्रिगर करें, कॉल का जवाब दें और फिर कॉल समाप्त कर दें। | एप्लिकेशन बैकग्राउंड में चला जाता है और दर्ज किए गए डेटा के साथ उसी स्क्रीन पर फिर से खुल जाता है। |
| आने वाला एसएमएस या पुश अलर्ट | वीडियो अपलोड करते समय मैसेज भेजें और बैनर को अनदेखा करें। | बैनर दिखाई देता है और गायब हो जाता है; एप्लिकेशन की स्थिति अपरिवर्तित रहती है। |
| अलार्म | किसी सक्रिय सत्र के दौरान निर्धारित अलार्म बजने दें और फिर उसे बंद कर दें। | अलार्म बजने पर पहले कार्रवाई करने का अनुरोध किया जाता है, उसके बाद एप्लिकेशन वहीं से फिर से शुरू होता है जहां वह रुका था। |
| कम बैटरी चेतावनी | लेनदेन के दौरान डिवाइस की बैटरी को चेतावनी सीमा तक खाली करें। | चेतावनी दिखाई देती है, लेन-देन रद्द नहीं होता है, और कम पावर मोड से स्क्रीन खराब नहीं होती है। |
| नेटवर्क कनेक्शन हानि | अनुरोध के दौरान कनेक्टिविटी को अक्षम करें, फिर उसे बहाल करें। | एक स्पष्ट संदेश प्रदर्शित होता है, कोई क्रैश नहीं होता है, और पुनर्स्थापना पर अनुरोध सुरक्षित रूप से पूरा हो जाता है या विफल हो जाता है। |
| चार्जिंग प्लग में लगी हो या न लगी हो | चालू सत्र के दौरान चार्जर को कनेक्ट और डिस्कनेक्ट करें | कोई प्रभाव नहीं - एप्लिकेशन बिना किसी स्पष्ट बदलाव के जारी है |
| एप्लिकेशन अपडेट रिमाइंडर | एप्लिकेशन के उपयोग में होने पर अपडेट प्रॉम्प्ट दिखाएँ | उपयोगकर्ता रद्द या स्वीकार कर सकता है, और दोनों ही विकल्पों के बावजूद मूल स्क्रीन अपरिवर्तित रहती है। |
पूरे एप्लिकेशन के लिए प्रत्येक व्यवधान के लिए एक पंक्ति रखने के बजाय, प्रत्येक महत्वपूर्ण स्क्रीन के लिए एक व्यवधान की एक पंक्ति रखें। भुगतान स्क्रीन, लॉगिन स्क्रीन और एक लंबा फॉर्म, तीनों अलग-अलग तरह से विफल होते हैं, और एक सामान्य केस इसे छिपा देता है।
अब जब हम समझ गए हैं कि इंटरप्ट टेस्टिंग क्या है और इसे करते समय क्या सत्यापित करना है, तो यह बात करने का समय है कि इसे कैसे किया जाए।
इंटरप्ट टेस्टिंग कैसे करें
इस कथन पर गौर करें: जब उपयोगकर्ता को कोई इनकमिंग फोन कॉल आती है तो iBooks को पृष्ठभूमि में चलना पड़ता है।
क्या आप इसे आईबुक्स ऐप की एक कार्यात्मक आवश्यकता नहीं कहेंगे? मुझे तो यही लगता है।
तो, इंटरप्ट परीक्षण का एक उपसमुच्चय है क्रियात्मक परीक्षण मोबाइल एप्लिकेशन के लिए इंटरप्ट टेस्टिंग करने के लिए, आप उन्हीं मोबाइल एप्लिकेशन टेस्ट फ्रेमवर्क और टूल्स का उपयोग करते हैं। इन परिदृश्यों की कल्पना करना परीक्षकों का कौशल है। एक बार यह हो जाने के बाद, आप टेस्ट केस डिज़ाइन करते हैं और उन्हें किसी भी अन्य टेस्ट की तरह ही निष्पादित करते हैं।
व्यवहार में यह क्रम छोटा और दोहराने योग्य होता है:
- उपयोगकर्ता के महत्वपूर्ण चरणों की सूची बनाएं — लॉगिन, भुगतान, अपलोड, लंबे फॉर्म, मीडिया प्लेबैक।
- ऊपर दी गई सूची में से प्रत्येक संभावित बाधा को प्रत्येक यात्रा पर अंकित करें।
- प्रत्येक पेयरिंग के लिए अपेक्षित समाधान पर प्रोडक्ट ओनर के साथ सहमति बनाएं, क्योंकि कोई सार्वभौमिक डिफ़ॉल्ट समाधान नहीं है।
- व्यवधान को सबसे जोखिम भरे क्षण में लागू करें, निष्क्रियता के क्षण में नहीं, और फिर पुनः आरंभ करें।
- एप्लिकेशन के पुनः चालू होने के बाद उसकी स्थिति, डेटा, सत्र और मेमोरी की पुष्टि करें, न कि केवल यह कि एप्लिकेशन अभी भी खुला है।
इस विषय के व्यापक अध्ययन के बारे में अधिक जानकारी के लिए, देखें मोबाइल परीक्षण ट्यूटोरियल और नमूना मामलों में मोबाइल ऐप परीक्षण.
व्यवधानों का अनुकरण करने के लिए उपकरण और तकनीकें
ऊपर बताए गए परिदृश्यों को प्रतीक्षा करने के बजाय मांग पर ही तैयार किया जाना चाहिए, और प्रत्येक प्लेटफ़ॉर्म ऐसा करने का एक तरीका प्रदान करता है।
- Android एमुलेटर विस्तारित नियंत्रण: एमुलेटर का साइड पैनल आने वाली कॉल, एसएमएस, बैटरी लेवल और चार्जर की स्थिति, और सेलुलर सिग्नल की मजबूती का अनुकरण करता है, इसलिए अधिकांश व्यवधान सूची को दूसरे हैंडसेट के बिना ही उठाया जा सकता है।
- आईओएस सिम्युलेटर और Xcode: सिम्युलेटर और डिवाइस सेटिंग्स से कनेक्टिविटी और हार्डवेयर स्थितियों को बदला जा सकता है, जबकि एक युग्मित भौतिक डिवाइस उन कॉल परिदृश्यों को कवर करता है जिन्हें सिम्युलेटर उत्पन्न नहीं कर सकता है।
- एक दूसरा भौतिक उपकरण: किसी दूसरे हैंडसेट से परीक्षण किए जा रहे डिवाइस पर कॉल करना या मैसेज भेजना, विशेष रूप से समय-संवेदनशील मामलों के लिए, वास्तविक व्यवधान को पुन: उत्पन्न करने का सबसे सटीक तरीका है।
- उपकरण सेटिंग्स: एयरप्लेन मोड, वाई-फाई टॉगल, डू नॉट डिस्टर्ब, बैटरी सेवर और शेड्यूल्ड अलार्म जैसी सुविधाएं वास्तविक हार्डवेयर पर कनेक्टिविटी और बिजली की रुकावटों को कवर करती हैं।
- स्वचालन ढाँचे: आपके फंक्शनल सूट के बाकी हिस्सों के लिए उपयोग किया जाने वाला वही ऑटोमेशन स्टैक रुकावट से पहले और बाद में एप्लिकेशन को चला सकता है, इसलिए रिज्यूम चेक को अनुमान के बजाय सुनिश्चित किया जाता है।
- वास्तविक-उपकरण क्लाउड: होस्टेड डिवाइस फ़ार्म निर्माताओं और ऑपरेटिंग सिस्टम संस्करणों में कवरेज को बढ़ाता है, जो महत्वपूर्ण है क्योंकि व्यवधान प्रबंधन उन क्षेत्रों में से एक है जहां विक्रेता अनुकूलन सबसे अधिक भिन्न होते हैं।
प्रक्रिया चाहे जो भी हो, परीक्षण मामले में रुकावट के सटीक क्षण को रिकॉर्ड करें। "अपलोड के दौरान रुकावट" और "अपलोड के बाद रुकावट" अलग-अलग परीक्षण हैं जिनमें विफलता के अलग-अलग तरीके होते हैं।
इंटरप्ट टेस्टिंग के लिए सर्वोत्तम पद्धतियाँ
कुछ आदतें एक उपयोगी इंटरप्ट सूट को केवल खानापूर्ति करने वाली प्रक्रिया से अलग करती हैं।
- सबसे खराब समय पर हस्तक्षेप करना: Target जैसे ही कोई लेन-देन पूरा होता है या कोई फ़ाइल लिखी जा रही होती है, उसी क्षण स्थिति सबसे नाजुक होती है।
- रिज्यूमे की जांच करें, व्यवधान की नहीं: यह दोष लगभग हमेशा नियंत्रण वापस आने के बाद ही प्रकट होता है, इसलिए अभिकथन पुनर्स्थापित स्क्रीन पर होने चाहिए।
- नेटवर्क परिवर्तन की दोनों दिशाओं को कवर करें: कनेक्शन का टूटना और फिर से जुड़ना दो अलग-अलग मामले हैं, और दूसरे मामले को अक्सर नजरअंदाज कर दिया जाता है।
- अवधि को बदलें: दो सेकंड का अलर्ट और दस मिनट की कॉल एप्लिकेशन को मेमोरी से हटाए जाने सहित विभिन्न जीवनचक्र पथों से गुजारती है।
- ऑपरेटिंग सिस्टम के विभिन्न संस्करणों और निम्न-स्तरीय हार्डवेयर में व्याप्त: सीमित क्षमताओं वाले उपकरणों पर बैकग्राउंड इविक्शन कहीं अधिक आक्रामक होता है, जिससे फ्लैगशिप हैंडसेट में छिपी हुई खामियां उजागर हो जाती हैं।
- दोहराए जाने वाले कार्यों को स्वचालित करें: कनेक्टिविटी और बैटरी संबंधी रुकावटें सुचारू रूप से स्वचालित हो जाती हैं, जिससे कॉल और अलार्म की स्थितियों के लिए मैन्युअल प्रयास की आवश्यकता नहीं रह जाती है।
- संसाधनों के उपयोग के साथ-साथ स्थिति पर भी नजर रखें: मेमोरी लीक होने या बैटरी खत्म होने की समस्या उत्पन्न होने पर भी, स्क्रीन सही दिखने पर भी यह एक दोष है, जो इस कार्य को इससे जोड़ता है। मोबाइल ऐप प्रदर्शन परीक्षण.
क्या इंटरप्ट परीक्षण, रिकवरी परीक्षण के समान नहीं है?
नहीं ऐसा नहीं है। पुनर्प्राप्ति परीक्षण यह विफलता से पुनर्स्थापना को मान्य करता है। व्यवधान आवश्यक रूप से विफलता नहीं है - यह केवल एक रुकावट है।traction।
यह अंग्रेज़ी में अल्पविराम और पूर्णविराम के अंतर जैसा है। यह अंतर केवल तकनीकी है, लेकिन मूल बात स्पष्ट है। रिकवरी टेस्टिंग यह जाँचती है कि किसी समस्या के उत्पन्न होने के बाद एप्लिकेशन पुनः चालू हो सकता है या नहीं; इंटरप्ट टेस्टिंग यह जाँचती है कि जब कोई अन्य एप्लिकेशन मुख्य रूप से कार्य करने लगता है तो क्या कोई समस्या उत्पन्न होती है।
इंटरप्ट टेस्टिंग शुरू करने के लिए यही सब जानना आवश्यक है — जो मोबाइल एप्लिकेशन टेस्टिंग की एक महत्वपूर्ण और सहज शाखा है।
