🙎 📁 👚 मोबाइल एप्लिकेशन परीक्षण प्रक्रिया ⚠️ 💰 👩🏽‍🔬

मोबाइल एप्लिकेशन के विकास में परीक्षण एक महत्वपूर्ण चरण है।

मोबाइल एप्लिकेशन को जारी करने में त्रुटि की लागत अधिक है। कई हफ्तों के लिए ऐपस्टोर में एप्लिकेशन कुछ घंटों के भीतर Google Play पर पहुंच जाते हैं। यह पता नहीं है कि उपयोगकर्ताओं को कब तक अपडेट किया जाएगा। त्रुटियों के कारण तूफानी नकारात्मक प्रतिक्रिया होती है, उपयोगकर्ता कम रेटिंग और हिस्टेरिकल समीक्षा छोड़ देते हैं। नए उपयोगकर्ता, इसे देखकर, एप्लिकेशन इंस्टॉल नहीं करते हैं।

मोबाइल परीक्षण एक जटिल प्रक्रिया है: दर्जनों विभिन्न स्क्रीन रिज़ॉल्यूशन, हार्डवेयर अंतर, ऑपरेटिंग सिस्टम के कई संस्करण, विभिन्न प्रकार के इंटरनेट कनेक्शन, अचानक डिस्कनेक्ट।

इसलिए, परीक्षण विभाग में, हमारे पास 8 लोग (प्रति प्रोग्रामर 0.5 परीक्षक) हैं, एक समर्पित परीक्षण लीड इसके विकास और प्रक्रियाओं की निगरानी करता है।

कट के तहत, मैं आपको बताऊंगा कि हम मोबाइल एप्लिकेशन का परीक्षण कैसे करते हैं ।

आवश्यकताओं का परीक्षण

विकास से पहले परीक्षण शुरू होता है। डिज़ाइन विभाग नेविगेशन स्कीम और स्क्रीन लेआउट को परीक्षकों को पास करता है; प्रोजेक्ट मैनेजर - आवश्यकताएं जो डिज़ाइन के लिए अदृश्य हैं। यदि डिज़ाइन ग्राहक द्वारा प्रदान किया जाता है, तो परीक्षण विभाग को भेजे जाने से पहले मॉडल हमारे डिजाइनरों द्वारा जांचे जाते हैं।

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

आवश्यकताओं की कमजोरियों पर परियोजना प्रबंधक, डेवलपर्स और डिजाइनरों के साथ चर्चा की जाती है। 2-3 पुनरावृत्तियों के बाद, पूरी टीम परियोजना को बेहतर ढंग से समझती है, भूली हुई कार्यक्षमता को याद करती है, विवादास्पद मुद्दों पर निर्णय को ठीक करती है।

मूल रूप से, बेसकैंप का उपयोग इस स्तर पर किया जाता है।

जब आवश्यकताएं पूर्ण और सुसंगत होती हैं, तो परीक्षक स्रोत डेटा को कवर करते हुए धुआँ परीक्षण और कार्यात्मक परीक्षण संकलित करता है। टेस्ट को विभिन्न प्लेटफार्मों के लिए सामान्य और विशिष्ट में विभाजित किया गया है। भंडारण और परीक्षण रन के लिए हम साइटचुओ का उपयोग करते हैं ।

उदाहरण के लिए, इस स्तर पर ट्रावा परियोजना के लिए 1856 परीक्षण लिखे गए थे।

परीक्षण का पहला चरण पूरा हो गया है। परियोजना विकास में जाती है।

सर्वर बनाएँ

हमारी सभी परियोजनाएं टीमसिटी बिल्ड सर्वर पर एकत्र की जाती हैं।

यदि प्रोजेक्ट मैनेजर "परीक्षण के लिए" टिक करता है, तो परीक्षकों को परीक्षण के लिए नई विधानसभा के बारे में एक पत्र प्राप्त होगा। उसका नंबर परीक्षकों के कार्यालय में मॉनिटर पर प्रदर्शित होता है। अंतिम दिन में निर्मित बिल्ड लाल रंग में प्रदर्शित किए जाते हैं, उन्हें सफेद लोगों की तुलना में अधिक सक्रिय रूप से परीक्षण करने की आवश्यकता होती है।

"मैजिक मॉनिटर" के बिना (वैसे, यह एंड्रॉइड पर काम करता है), पुराने बिल्ड अक्सर परीक्षण किए जाते थे। बग के साथ एक नया निर्माण ग्राहक को मारा। अब, परीक्षण मामलों को चलाने से पहले, बस मॉनिटर को देखें, भ्रम को हल किया गया था।

परीक्षण बिल्ड त्वरित और पूर्ण है।

त्वरित परीक्षण

यदि विधानसभा जारी नहीं करता है, तो विकास पुनरावृत्ति पूरा होने के बाद त्वरित परीक्षण किया जाता है।

शुरू करने के लिए, धूम्रपान परीक्षण यह समझने के लिए आयोजित किया जाता है कि क्या यह विधानसभा का परीक्षण करने के लिए समझ में आता है।

फिर, सभी पूर्ण किए गए कार्यों और जीरा से पुनरावृत्ति के लिए निश्चित कीड़े को लिया जाता है और सावधानीपूर्वक जांच की जाती है कि परिणाम कार्य विवरण से मेल खाता है। यदि कार्य में नए इंटरफ़ेस तत्व शामिल हैं, तो इसे लेआउट के साथ सामंजस्य के लिए डिजाइनरों को भेजा जाता है।

गलत तरीके से किए गए कार्यों को फिर से खोजा जाता है। जीरा में कीड़े घुस जाते हैं। गैर-यूआई बग को स्मार्टफोन से लॉग इन करना होगा। यूआई बग्स के लिए, नोट्स वाले स्क्रीनशॉट जो गलत है।

उसके बाद, इस पुनरावृत्ति के कार्यात्मक परीक्षण किए जाते हैं। यदि बग पाए जाते हैं जो परीक्षण मामलों द्वारा कवर नहीं किए जाते हैं, तो एक नया परीक्षण मामला बनाया जाता है।

Android अनुप्रयोगों के लिए, बंदर परीक्षण शुरू किए जाते हैं।

adb shell monkey -p ru.stream.droid --throttle 50 --pct-syskeys 0 --pct-ap pswitch 0 -v 5000

परीक्षण के अंत में, "बग परीक्षण पारित" चेकबॉक्स को बिल्ड सर्वर में डाल दिया जाता है (हाँ, टिक का नाम बहुत सही नहीं है :)।

यदि परीक्षण प्रक्रिया के दौरान कोई अवरोधक, महत्वपूर्ण और प्रमुख बग नहीं पाए गए, तो चेकबॉक्स "ग्राहक को दिखाया जा सकता है" चेक किया गया है। परीक्षण विभाग की स्वीकृति के बिना कोई भी निर्माण ग्राहक को नहीं भेजा जाता है। (ग्राहक के साथ अनुबंध करके, प्रमुख बग के साथ निर्माण कभी-कभी भेजे जाते हैं)।

बग की महत्वपूर्णता तालिका द्वारा निर्धारित की जाती है।

परीक्षण पूरा होने पर, पीएम को एक विस्तृत रिपोर्ट पत्र प्राप्त होता है।
परीक्षण पूरा होने की रिपोर्ट

पूर्ण परीक्षण

पूर्ण परीक्षण रिलीज से पहले किया जाता है। त्वरित परीक्षण, प्रतिगमन परीक्षण, 100 उपकरणों पर बंदर परीक्षण और परीक्षण अद्यतन शामिल हैं।

प्रतिगमन परीक्षण में परियोजना के लिए सभी परीक्षण मामले चलाना शामिल है। परीक्षण मामले न केवल अंतिम पुनरावृत्ति के लिए, बल्कि सभी पिछले और सामान्य परीक्षण मामलों के लिए आवश्यकताओं के अनुसार। यह प्रोजेक्ट के आधार पर एक या तीन डिवाइस प्रति दिन लेता है।

अद्यतनों का परीक्षण एक बहुत महत्वपूर्ण कदम है। लगभग सभी एप्लिकेशन डेटा को स्थानीय रूप से संग्रहीत करते हैं (भले ही वह एक लॉगिन कुकी हो) और यह सुनिश्चित करना महत्वपूर्ण है कि एप्लिकेशन को अपडेट करने के बाद सभी उपयोगकर्ता डेटा सहेजे जाएंगे। परीक्षक बाजार से बिल्ड को डाउनलोड करता है, संग्रहीत डेटा (लॉगिन, प्लेलिस्ट, वित्तीय लेखांकन लेनदेन) बनाता है, आवेदन को टेस्ट असेंबली में अपडेट करता है और सत्यापित करता है कि सब कुछ जगह में है। फिर स्मोक टेस्ट चलाता है। प्रक्रिया 2-3 उपकरणों पर दोहराई जाती है।

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

हम Appthwack सेवा का उपयोग करके 10 iOS और 80 Android उपकरणों पर एक बंदर परीक्षण शुरू कर रहे हैं।

पूर्ण परीक्षण के अंत में, पत्र के अलावा, एक विस्तृत रिपोर्ट मैन्युअल रूप से तैयार की जाती है।

विधानसभा सभी परीक्षण मामलों के 100% पूरा होने के साथ ही रिलीज होती है।

बाहरी सेवाओं का परीक्षण

Google Analytics, Flurry, या ग्राहक आँकड़ों के साथ परीक्षण एकीकरण आसान नहीं है। ऐसा हुआ कि गैर-कार्यशील Google Analytics के साथ निर्माण जारी हुआ और किसी ने भी इस पर ध्यान नहीं दिया।

इसलिए, बाहरी सेवाओं के लिए एक अनिवार्य क्रम में, एक परीक्षण खाता बनाया जाता है और इसे पूर्ण परीक्षण के साथ जांचा जाता है। इसके अलावा, आंकड़े भेजने को लॉग में दर्ज किया जाता है, जो परीक्षकों द्वारा जांचे जाते हैं। जारी होने पर, परीक्षण खाते को एक लड़ाकू खाते से बदल दिया जाता है।

समय ट्रैकिंग

समय परीक्षक एक अलग जीरा परियोजना में दर्ज किए जाते हैं। परीक्षण मामलों की तैयारी के लिए, परीक्षण रन, परियोजना पर रिपोर्ट लिखना, एक अलग कार्य निर्धारित किया गया है और इसमें मानक समय व्यतीत किए गए समय को चिह्नित करता है।

UPD: हमें बताएं कि परीक्षण आपके लिए कैसे काम करता है, प्रति डेवलपर कम से कम कितने परीक्षक हैं

हमारे habr- ब्लॉग की सदस्यता लें। हर गुरुवार, मोबाइल विकास, विपणन और मोबाइल स्टूडियो व्यवसाय के बारे में उपयोगी लेख।

मोबाइल एप्लिकेशन परीक्षण प्रक्रिया