मेन्यू

धूम्रपान परीक्षण बनाम स्वच्छता परीक्षण: उदाहरणों के साथ अंतर

smoke testing vs sanity testing

समस्याओं को खत्म करने के लिए हमारे साधन का प्रयास करें

उदाहरण के साथ विस्तार से स्मोक परीक्षण और स्वच्छता परीक्षण के बीच अंतर का पता लगाएं:

इस ट्यूटोरियल में, हम सीखेंगे कि सॉफ्टवेयर टेस्टिंग में स्वच्छता परीक्षण और धुआँ परीक्षण क्या है। हम सरल उदाहरणों के साथ स्वच्छता और धुआँ परीक्षण के बीच महत्वपूर्ण अंतर भी सीखेंगे।

ज्यादातर बार हम सनिटी टेस्टिंग और स्मोक टेस्टिंग के अर्थ के बीच भ्रमित हो जाते हैं। सबसे पहले, ये दो परीक्षाएं हैं ' भिन्न हो 'और एक परीक्षण चक्र के विभिन्न चरणों के दौरान किया जाता है।

धुआँ परीक्षण और स्वच्छता परीक्षण

आप क्या सीखेंगे:

स्वच्छता परीक्षण

सनिटी परीक्षण तब किया जाता है जब एक क्यूए के रूप में हमारे पास सभी परीक्षण मामलों को चलाने के लिए पर्याप्त समय नहीं होता है, यह हो क्रियात्मक परीक्षण , UI, OS या ब्राउज़र परीक्षण।

इसलिए, मैं परिभाषित करूंगा,

'एक परीक्षण निष्पादन के रूप में स्वच्छता परीक्षण जो प्रत्येक कार्यान्वयन और इसके प्रभाव को छूने के लिए किया जाता है लेकिन पूरी तरह से या गहराई से नहीं, इसमें कार्यान्वयन और इसके प्रभाव के आधार पर कार्यात्मक, UI, संस्करण, आदि परीक्षण शामिल हो सकते हैं।'

क्या हम सभी उस स्थिति में आते हैं जब हमें एक या दो दिन में हस्ताक्षर करना होता है, लेकिन परीक्षण के लिए निर्माण अभी भी जारी नहीं किया जाता है?

कुछ अच्छी एनीमे वेबसाइट क्या हैं

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

मैं कई बार पागल हो जाता था क्योंकि भले ही यह एक छोटी सी कार्यक्षमता थी, लेकिन इसका निहितार्थ जबरदस्त हो सकता है। और केक पर एक टुकड़े के रूप में, ग्राहक कभी-कभी अतिरिक्त समय देने से इनकार करते हैं। मैं कुछ ही घंटों में पूरे परीक्षण को कैसे पूरा कर सकता हूं, हर कार्यक्षमता को सत्यापित करें, कीड़े और इसे जारी करें?

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

इस तरह की सभी समस्याओं का जवाब बहुत सरल था, यानी उपयोग करने के अलावा कुछ नहीं स्वच्छता परीक्षण रणनीति।

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

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

मेरा अनुभव

सनिटी परीक्षण का अनुभव

सॉफ्टवेयर टेस्टिंग में मेरे 8+ साल के करियर में से 3 साल मैं इसमें काम कर रहा था चंचल विधि y और वह समय था जब मैंने ज्यादातर एक विवेक परीक्षण का उपयोग किया था।

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

इसलिए निम्नलिखित कुछ महत्वपूर्ण बिंदु हैं जिनका मैं इस तरह की परिस्थितियों में पालन करता था:

# 1) प्रबंधक और देव टीम के साथ बैठें जब वे कार्यान्वयन पर चर्चा कर रहे हैं क्योंकि उन्हें तेजी से काम करना है और इसलिए हम उनसे अलग से व्याख्या करने की उम्मीद नहीं कर सकते हैं।

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

#दो) जैसा कि आपके पास समय कम है, जब तक विकास टीम कार्यान्वयन पर काम कर रही है, तब तक आप एवरनोट आदि जैसे उपकरणों में मोटे तौर पर परीक्षण के मामलों को नोट कर सकते हैं, लेकिन सुनिश्चित करें कि आप उन्हें कहीं लिखते हैं ताकि आप उन्हें बाद में जोड़ सकें। परीक्षण मामले उपकरण।

# 3) कार्यान्वयन के अनुसार अपने परीक्षण को तैयार रखें और यदि आपको लगता है कि कुछ विशिष्ट डेटा निर्माण जैसे कोई लाल झंडे हैं यदि एक परीक्षण में समय लगेगा (और यह रिलीज के लिए एक महत्वपूर्ण परीक्षण है), तो उन झंडों को तुरंत उठाएं और अपने प्रबंधक को सूचित करें या चौराहे के बारे में पीओ।

सिर्फ इसलिए कि ग्राहक चाहते हैं कि इसका मतलब यह न हो कि कोई क्यूए आधे परीक्षण के बाद भी जारी करेगा।

# 4) अपनी टीम और प्रबंधक के साथ एक समझौता करें कि समय की कमी के कारण आप केवल बग को विकास टीम और जोड़ने की औपचारिक प्रक्रिया में संचार करेंगे, बग ट्रैकिंग टूल में विभिन्न चरणों के लिए कीड़े को चिह्नित करना बाद में समय बचाने के लिए किया जाएगा। ।

# 5) जब विकास टीम अपने अंत में परीक्षण कर रही है, तो उनके साथ जोड़ी बनाने की कोशिश करें (जिसे देव-क्यूए पेयरिंग कहा जाता है) और अपने सेटअप पर ही एक बुनियादी दौर करें, इससे निर्माण से बचने और फ्रॉस्ट करने में मदद मिलेगी यदि मूल कार्यान्वयन विफल हो रहा है ।

# 6) अब जब आपके पास बिल्ड है, व्यावसायिक नियमों और सभी उपयोग मामलों का पहले परीक्षण करें। आप परीक्षण को किसी क्षेत्र, नेविगेशन आदि के सत्यापन के लिए रख सकते हैं।

# 7) आपको जो भी कीड़े मिलते हैं, उन सभी को नोट करें और व्यक्तिगत रूप से रिपोर्ट करने के बजाय डेवलपर्स को एक साथ रिपोर्ट करने का प्रयास करें क्योंकि उनके लिए एक गुच्छा पर काम करना आसान होगा।

# 8) यदि आपके पास समग्र की आवश्यकता है प्रदर्शन का परीक्षण या तनाव या लोड परीक्षण, तो सुनिश्चित करें कि आपके पास उसी के लिए एक उचित स्वचालन ढांचा है। क्योंकि यह एक पवित्रता परीक्षण के साथ मैन्युअल रूप से परीक्षण करने के लिए असंभव के पास है।

# 9) यह सबसे महत्वपूर्ण हिस्सा है, और वास्तव में आपकी विवेक परीक्षण रणनीति का अंतिम चरण है - 'जब आप रिलीज़ ईमेल या दस्तावेज़ का मसौदा तैयार करते हैं, तो उन सभी परीक्षण मामलों का उल्लेख करें जिन्हें आपने निष्पादित किया था, एक स्थिति मार्कर के साथ पाए गए कीड़े और यदि कुछ भी छोड़ दिया गया था। बिना कारण के इसका उल्लेख करें ' अपने परीक्षण के बारे में एक कुरकुरा कहानी लिखने की कोशिश करें जो सभी को बताएगी कि क्या परीक्षण किया गया है, सत्यापित किया गया है और क्या नहीं किया गया है।

जब मैं इस परीक्षण का उपयोग कर रहा था तो मैंने इसका धार्मिक रूप से पालन किया।

मुझे अपना अनुभव साझा करने दें:

# 1) हम एक वेबसाइट पर काम कर रहे थे और यह कीवर्ड के आधार पर विज्ञापनों को पॉपअप करने के लिए इस्तेमाल करती थी। विज्ञापनदाता विशेष कीवर्ड के लिए बोली लगाते थे, जिसकी स्क्रीन उसी के लिए डिज़ाइन की गई थी। डिफ़ॉल्ट बोली मूल्य $ 0.25 के रूप में दिखाया जाता था, जिसे बोलीदाता भी बदल सकता था।

एक और जगह थी जहाँ यह डिफ़ॉल्ट बोली दिखाई देती थी और इसे अन्य मूल्य में भी बदला जा सकता था। ग्राहक डिफ़ॉल्ट मूल्य को $ 0.25 से $ 0.5 तक बदलने के अनुरोध के साथ आया था लेकिन उसने केवल स्पष्ट स्क्रीन का उल्लेख किया।

हमारे विचार-विमर्श के दौरान, हम इस दूसरी स्क्रीन के बारे में भूल गए (?) क्योंकि इसका उपयोग उस उद्देश्य के लिए बहुत अधिक नहीं किया गया था। लेकिन परीक्षण करते समय जब मैंने बोली के मूल मामले को $ 0.5 चलाया और अंत तक जांच की, तो मैंने पाया कि उसी के लिए क्रोनजॉब विफल हो रहा था क्योंकि एक स्थान पर यह $ 0.25 मिल रहा था।

मैंने अपनी टीम को इसकी सूचना दी और हमने बदलाव किया और उसी दिन इसे सफलतापूर्वक वितरित किया।

#दो) उसी परियोजना के तहत (ऊपर वर्णित), हमें बोली के लिए नोट्स / टिप्पणियों के लिए एक छोटा पाठ क्षेत्र जोड़ने के लिए कहा गया था। यह एक बहुत ही सरल कार्यान्वयन था और हमने उसी दिन इसे वितरित करने के लिए प्रतिबद्ध किया।

इसलिए जैसा कि ऊपर उल्लेख किया गया है, मैंने सभी व्यावसायिक नियमों का परीक्षण किया और इसके आसपास के मामलों का उपयोग किया और जब मैंने कुछ सत्यापन परीक्षण किया, तो मैंने पाया कि जब मैंने विशेष वर्णों के संयोजन में प्रवेश किया, तो पृष्ठ क्रैश हो गया।

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

# 3) हाल ही में, मैं एक मोबाइल ऐप परियोजना पर काम कर रहा था, और हमें समय क्षेत्र के अनुसार ऐप में दिखाए गए डिलीवरी के समय को अपडेट करने की आवश्यकता थी। यह न केवल ऐप में बल्कि वेब सेवा के लिए भी परीक्षण किया जाना था।

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

स्वच्छता परीक्षण बनाम प्रतिगमन परीक्षण

नीचे दिए गए दोनों के बीच कुछ अंतर हैं:


एस।		प्रतिगमन परीक्षण


स्वच्छता परीक्षण
।यह परीक्षण कई बार हफ्तों या महीने के लिए निर्धारित होता है।

यह ज्यादातर 2-3 दिनों में अधिकतम होता है।

एकप्रतिगमन परीक्षण यह सत्यापित करने के लिए किया जाता है कि पूरा सिस्टम और बग फिक्स ठीक काम कर रहे हैं।यह प्रमाणित करने के लिए कि प्रत्येक कार्यशीलता अपेक्षित रूप से काम कर रही है, सनिटी परीक्षण यादृच्छिक रूप से किया जाता है।
दोइस परीक्षण में हर सबसे नन्हा हिस्सा फिर से संगठित हो जाता है।
यह एक नियोजित परीक्षण नहीं है और केवल तभी किया जाता है जब कोई समय की कमी हो।
३
यह एक अच्छी तरह से विस्तृत और नियोजित परीक्षण है।

यह एक नियोजित परीक्षण नहीं है और केवल तभी किया जाता है जब कोई समय की कमी हो।

४इस परीक्षण के लिए उपयुक्त रूप से डिज़ाइन किए गए परीक्षण मामलों का सूट बनाया गया है।

हर बार परीक्षण मामलों को बनाना संभव नहीं हो सकता है; आमतौर पर परीक्षण मामलों का एक रफ सेट बनाया जाता है।

५इसमें कार्यक्षमता, यूआई, प्रदर्शन, ब्राउज़र / ओएस परीक्षण आदि की गहराई से सत्यापन शामिल है यानी सिस्टम का हर पहलू फिर से प्रभावित है।

इसमें मुख्य रूप से व्यावसायिक नियमों, कार्यक्षमता का सत्यापन शामिल है।

६यह एक व्यापक और गहन परीक्षण है।

यह एक विस्तृत और उथला परीक्षण है।

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

मोबाइल ऐप स्वच्छता परीक्षण

आप सोच रहे होंगे कि मैं यहां विशेष रूप से मोबाइल ऐप के बारे में क्यों उल्लेख कर रहा हूं?

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

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

'मोबाइल ऐप' पर सफलतापूर्वक इस परीक्षण को करने में आपकी मदद करने के लिए कुछ संकेत निम्न हैं: '

# 1) सबसे पहले, अपनी टीम के साथ कार्यान्वयन पर ओएस संस्करण के प्रभाव का विश्लेषण करें।

सवालों के जवाब खोजने की कोशिश करें, क्या व्यवहार संस्करणों में भिन्न होगा? कार्यान्वयन सबसे कम समर्थित संस्करण पर काम करेगा या नहीं? क्या संस्करणों के कार्यान्वयन के लिए प्रदर्शन के मुद्दे होंगे? क्या ओएस की कोई विशिष्ट विशेषता है जो कार्यान्वयन के व्यवहार को प्रभावित कर सकती है? आदि।

#दो) उपरोक्त नोट पर, फोन के मॉडल के लिए भी विश्लेषण करें यानी क्या फोन की कोई विशेषताएं हैं जो कार्यान्वयन को प्रभावित करेंगी? क्या जीपीएस के साथ व्यवहार-परिवर्तन का कार्यान्वयन है? क्या फोन के कैमरे के साथ कार्यान्वयन व्यवहार बदल रहा है? आदि यदि आप पाते हैं कि कोई प्रभाव नहीं है, तो विभिन्न फोन मॉडल पर परीक्षण से बचें।

# 3) जब तक कार्यान्वयन के लिए कोई UI परिवर्तन नहीं होते हैं, तो मैं कम से कम प्राथमिकता पर UI परीक्षण रखने की सलाह दूंगा, आप टीम को सूचित कर सकते हैं (यदि आप चाहते हैं) कि UI का परीक्षण नहीं किया जाएगा।

# 4) अपना समय बचाने के लिए, अच्छे नेटवर्क पर परीक्षण से बचें क्योंकि यह स्पष्ट है कि कार्यान्वयन एक मजबूत नेटवर्क पर अपेक्षित रूप से काम करने वाला है। मैं 4 जी या 3 जी नेटवर्क पर परीक्षण शुरू करने की सलाह दूंगा।

# 5) यह परीक्षण कम समय में किया जाना है लेकिन सुनिश्चित करें कि आप कम से कम एक फ़ील्ड परीक्षण करें जब तक कि यह केवल UI परिवर्तन न हो।

# 6) यदि आपको विभिन्न ओएस और उनके संस्करण के मैट्रिक्स के लिए परीक्षण करना होगा, तो मैं सुझाव दूंगा कि आप इसे स्मार्ट तरीके से करें। उदाहरण के लिए, परीक्षण के लिए निम्नतम, मध्यम और नवीनतम OS- संस्करण जोड़े चुनें। आप रिलीज़ दस्तावेज़ में उल्लेख कर सकते हैं कि हर संयोजन का परीक्षण नहीं किया गया है।

# 7) यूआई कार्यान्वयन विवेक परीक्षण के लिए एक समान लाइन पर, समय बचाने के लिए छोटे, मध्यम और बड़े स्क्रीन आकार का उपयोग करें। आप एक सिम्युलेटर और एमुलेटर का उपयोग भी कर सकते हैं।

एहतियाती उपाय

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

ऐसे मामलों में लिखित संचार की कमी, परीक्षण प्रलेखन और मिस आउट काफी सामान्य हैं।

यह सुनिश्चित करने के लिए कि आप इसके शिकार नहीं हैं, सुनिश्चित करें कि:

  • जब तक आपको क्लाइंट द्वारा साझा लिखित आवश्यकता नहीं दी जाती है, तब तक परीक्षण के लिए एक बिल्ड स्वीकार न करें। ऐसा होता है कि ग्राहक एक ईमेल में परिवर्तन या नए कार्यान्वयन को चैट या ईमेल में एक साधारण 1 लाइनर से संवाद करते हैं और हमसे अपेक्षा करते हैं कि वह एक आवश्यकता के रूप में व्यवहार करेगा। अपने क्लाइंट को कुछ बुनियादी कार्यक्षमता बिंदु और स्वीकृति मानदंड प्रदान करने के लिए मजबूर करें।
  • हमेशा अपने परीक्षण के मामलों और बगों के मोटे नोट बनाएं अगर आपके पास उन्हें बड़े करीने से लिखने के लिए पर्याप्त समय नहीं है। इन अनिर्दिष्ट को कभी मत छोड़ो। यदि कुछ समय है, तो इसे अपने लीड या टीम के साथ साझा करें ताकि अगर कुछ भी याद न हो तो वे इसे आसानी से इंगित कर सकें।
  • यदि आप और आपकी टीम के पास समय कम है, तो सुनिश्चित करें कि ईमेल में बग को उपयुक्त स्थिति में चिह्नित किया गया है? आप टीम को बगों की पूरी सूची ईमेल कर सकते हैं और देवों को उचित रूप से चिह्नित कर सकते हैं। गेंद को हमेशा दूसरे के दरबार में रखें।
  • यदि आपके पास है स्वचालन फ्रेमवर्क तैयार है, इसका उपयोग करें और करने से बचें मैनुअलटाइटिंग , इस तरह से कम समय में आप अधिक कवर कर सकते हैं।
  • '1 घंटे में रिलीज़' के परिदृश्य से बचें जब तक कि आप 100% सुनिश्चित न हों कि आप वितरित कर पाएंगे।
  • अंतिम लेकिन कम से कम नहीं, जैसा कि ऊपर उल्लेख किया गया है, विस्तृत परीक्षण ईमेल का मसौदा तैयार करें जो कि परीक्षण किया गया है, क्या बचा है, कारण, जोखिम, कौन से कीड़े हल किए गए हैं, ed बाद में 'आदि क्या हैं।

क्यूए के रूप में, आपको यह निर्धारित करना चाहिए कि कार्यान्वयन का सबसे महत्वपूर्ण हिस्सा कौन सा है जिसे परीक्षण करने की आवश्यकता है और वे कौन से भाग हैं जिन्हें छोड़ा जा सकता है या बुनियादी-परीक्षण किया जा सकता है।

थोड़े समय में भी, आप कैसे करना चाहते हैं, इसके बारे में एक रणनीति बनाएं और आप निश्चित समय सीमा में सर्वश्रेष्ठ हासिल कर सकेंगे।

धुआँ परीक्षण

स्मोक परीक्षण संपूर्ण परीक्षण नहीं है, लेकिन यह परीक्षण का एक समूह है जो यह सत्यापित करने के लिए निष्पादित किया जाता है कि क्या उस विशेष बिल्ड की बुनियादी कार्यक्षमताएं अपेक्षित रूप से ठीक काम कर रही हैं या नहीं। यह हमेशा build नए ’बिल्ड पर किया जाने वाला पहला परीक्षण होना चाहिए।

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

इस के प्रकाश में, क्यूए यह कैसे सुनिश्चित करेगा कि बुनियादी कार्यक्षमताएं ठीक काम कर रही हैं?

इसका उत्तर एक प्रदर्शन करना होगा धुआँ परीक्षण ।

धुआँ परीक्षण

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

सैद्धांतिक रूप से, स्मोक टेस्ट को सतह-स्तर परीक्षण के रूप में परिभाषित किया गया है ताकि यह प्रमाणित किया जा सके कि विकास टीम द्वारा क्यूए टीम को प्रदान किया गया निर्माण आगे के परीक्षण के लिए तैयार है। यह परीक्षण भी क्यूए टीम को बिल्ड जारी करने से पहले विकास टीम द्वारा किया जाता है।

हार्ड ड्राइव क्लोनिंग के लिए सबसे अच्छा सॉफ्टवेयर

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

धुआँ परीक्षण के उदाहरण

यह परीक्षण आम तौर पर एकीकरण, स्वीकृति और के लिए उपयोग किया जाता है सिस्टम परीक्षण ।

एक QA के रूप में मेरे करियर में, मैंने हमेशा एक निर्माण स्वीकार किया, जब मैंने एक धूम्रपान परीक्षण किया था। तो, आइए समझते हैं कि इन तीनों परीक्षाओं के परिप्रेक्ष्य से कुछ उदाहरणों के साथ धूम्रपान परीक्षण क्या है।

(1) स्वीकृति परीक्षण

जब भी कोई बिल्ड QA के लिए जारी किया जाता है, एक के रूप में धूम्रपान परीक्षण स्वीकृति परीक्षण किया जाना चाहिए।

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

आइए हम निम्नलिखित उदाहरणों को उन लोगों के लिए धूम्रपान परीक्षणों को समझने के लिए एक निर्माण में किए गए कार्यान्वयन के रूप में लेते हैं:

  • सफलतापूर्वक पंजीकृत ड्राइवरों को लॉग इन करने की अनुमति देने के लिए लॉगिन कार्यक्षमता को लागू किया।
  • उन मार्गों को दिखाने के लिए डैशबोर्ड की कार्यक्षमता को लागू किया गया है जो आज ड्राइवर को निष्पादित करना है।
  • एक उपयुक्त संदेश दिखाने के लिए कार्यक्षमता को कार्यान्वित किया जाता है यदि कोई मार्ग किसी दिए गए दिन के लिए मौजूद नहीं है।

उपरोक्त बिल्ड में, स्वीकृति स्तर पर, स्मोक टेस्ट का मतलब यह सत्यापित करना होगा कि मूल तीन कार्यान्वयन ठीक काम कर रहे हैं। यदि इन तीनों में से कोई भी टूट गया है, तो क्यूए को निर्माण को अस्वीकार करना चाहिए।

# 2) एकीकरण परीक्षण

यह परीक्षण आमतौर पर तब किया जाता है जब व्यक्तिगत मॉड्यूल कार्यान्वित और परीक्षण किए जाते हैं। में एकीकरण जांच स्तर, यह परीक्षण यह सुनिश्चित करने के लिए किया जाता है कि सभी बुनियादी एकीकरण और अंत से कार्यात्मकताएं अपेक्षा के अनुरूप ठीक काम कर रही हैं।

यह एक साथ दो मॉड्यूल या सभी मॉड्यूल का एकीकरण हो सकता है, इसलिए एकीकरण के स्तर के आधार पर धूम्रपान परीक्षण की जटिलता अलग-अलग होगी।

आइए इस परीक्षण के लिए एकीकरण कार्यान्वयन के निम्नलिखित उदाहरणों पर विचार करें:

  • मार्ग और स्टॉप मॉड्यूल के एकीकरण को लागू किया।
  • आगमन स्थिति अद्यतन के एकीकरण को लागू किया और स्टॉप स्क्रीन पर समान दर्शाते हैं।
  • वितरण कार्यक्षमता मॉड्यूल तक पूर्ण पिकअप के एकीकरण को लागू किया।

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

# 3) सिस्टम टेस्टिंग

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

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

यह आमतौर पर स्वचालन उपकरण की मदद से किया जाता है।

SCRUM पद्धति में महत्व

आजकल, परियोजना कार्यान्वयन में झरना पद्धति का पालन शायद ही करते हैं, ज्यादातर सभी परियोजनाएं फुर्तीली और जमघट केवल। पारंपरिक जलप्रपात विधि की तुलना में, धुआँ परीक्षण SCRUM और फुर्तीली में उच्च संबंध रखता है।

मैंने SCRUM में 4 साल काम किया । और जैसा कि हम जानते हैं कि एससीआरयूएम में, स्प्रिंट कम अवधि के होते हैं और इसलिए इस परीक्षण को करने के लिए अत्यधिक महत्व है, ताकि विफल बिल्ड को तुरंत विकास टीम को सूचित किया जा सके और साथ ही तय किया जा सके।

कुछ इस प्रकार हैं दूर करना SCRUM में इस परीक्षण के महत्व पर:

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

स्मोक टेस्ट बनाम बिल्ड स्वीकृति परीक्षण

स्मोक टेस्टिंग सीधे बिल्ड एक्सेप्टेंस टेस्टिंग (BAT) से संबंधित है।

बैट में, हम एक ही परीक्षण करते हैं - यह सत्यापित करने के लिए कि बिल्ड विफल नहीं हुआ है और सिस्टम ठीक काम कर रहा है या नहीं। कभी-कभी, ऐसा होता है कि जब कोई निर्माण होता है, तो कुछ समस्याएँ सामने आती हैं और जब इसे वितरित किया जाता है, तो बिल्ड QA के लिए काम नहीं करता है।

मैं कहूंगा कि बैट एक स्मोक चेक का एक हिस्सा है क्योंकि अगर सिस्टम विफल हो रहा है, तो आप क्यूए के रूप में परीक्षण के लिए बिल्ड को कैसे स्वीकार कर सकते हैं? केवल कार्यप्रणाली ही नहीं, सिस्टम को स्वयं QA की इन-डेप्थ टेस्टिंग से आगे बढ़ने से पहले काम करना पड़ता है।

स्मोक टेस्ट साइकिल

निम्नलिखित फ़्लोचार्ट धुआँ परीक्षण चक्र की व्याख्या करता है।

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

परीक्षण चक्र

स्मोक टेस्ट साइकिल

स्मोक टेस्ट किसे करना चाहिए?

कौन आइकॉन

सभी QA के समय की बर्बादी से बचने के लिए पूरी टीम इस प्रकार के परीक्षण में शामिल नहीं है।

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

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

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

हमें स्मोक टेस्ट को स्वचालित क्यों करना चाहिए?

यह परीक्षण विकास टीम द्वारा जारी बिल्ड पर किया जाने वाला पहला परीक्षण है। इस परीक्षण के परिणामों के आधार पर, आगे का परीक्षण किया जाता है (या निर्माण को अस्वीकार कर दिया जाता है)।

इस परीक्षण को करने का सबसे अच्छा तरीका एक स्वचालन उपकरण का उपयोग करना और एक नया निर्माण होने पर चलाने के लिए स्मोक सूट को शेड्यूल करना है। आप सोच रहे होंगे कि मैं ऐसा क्यों करूं 'धूम्रपान परीक्षण सूट को स्वचालित करें'?

आइए हम निम्नलिखित मामले को देखें:

मान लें कि आप अपनी रिलीज़ से एक सप्ताह दूर हैं और कुल 500 परीक्षण मामलों में से, आपके धूम्रपान परीक्षण सूट में 80-90 शामिल हैं। यदि आप इन सभी 80-90 परीक्षण मामलों को मैन्युअल रूप से निष्पादित करना शुरू करते हैं, तो कल्पना करें कि आपको कितना समय लगेगा? मुझे लगता है कि 4-5 दिन (न्यूनतम)।

लेकिन अगर आप स्वचालन का उपयोग करते हैं और इन सभी 80-90 परीक्षण मामलों को चलाने के लिए स्क्रिप्ट बनाते हैं, तो आदर्श रूप से, ये 2-3 घंटों में चलाए जाएंगे और आपके पास तुरंत परिणाम होंगे। क्या इससे आपका कीमती समय बचता है और आपको बिल्ड-इन के बारे में परिणाम बहुत कम समय में मिलते हैं?

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

इस परियोजना के लिए, मेरे पास 800 परीक्षण मामले थे और 250 धूम्रपान परीक्षण के मामले थे। सेलेनियम के उपयोग से, हम आसानी से 3-4 घंटों में उन 250 परीक्षण मामलों के परिणाम प्राप्त कर सकते हैं। इसने न केवल हमारा समय बचाया बल्कि शोस्टॉपर्स के बारे में हमें ASAP दिखाया।

इसलिए, जब तक कि स्वचालित करना असंभव नहीं है, इस परीक्षण के लिए स्वचालन की मदद लें।

फायदे और नुकसान

आइए सबसे पहले फायदों पर एक नज़र डालते हैं क्योंकि इसके कुछ नुकसानों की तुलना में यह बहुत अधिक है।

लाभ:

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

नुकसान:

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

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

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

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

धूम्रपान और स्वच्छता परीक्षण के बीच अंतर

ज्यादातर बार हम सनिटी टेस्टिंग और स्मोक टेस्टिंग के अर्थ के बीच भ्रमित हो जाते हैं। सबसे पहले, ये दो परीक्षाएं हैं ' भिन्न हो 'और एक परीक्षण चक्र के विभिन्न चरणों के दौरान प्रदर्शन किया।

एस।धुआँ परीक्षण

स्वच्छता परीक्षण

एक स्मोक परीक्षण का अर्थ है सत्यापित करना (मूल) कि निर्माण में किए गए कार्यान्वयन ठीक काम कर रहे हैं।सनिटी परीक्षण का अर्थ है कि नई जोड़ी गई कार्यक्षमता, बग आदि को सत्यापित करना ठीक काम कर रहा है।
दो प्रारंभिक बिल्ड पर यह पहला परीक्षण है।जब निर्माण अपेक्षाकृत स्थिर होता है, तो हो जाता है।
३ हर निर्माण पर किया।स्टेबल बिल्ड ऑन पोस्ट रिग्रेशन।

निम्नलिखित उनके अंतर का एक आरेखीय प्रतिनिधित्व है:

धूम्रपान करना

धूम्रपान परीक्षण

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

स्वच्छता परीक्षण

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

आशा है कि आप इन दो विशाल और महत्वपूर्ण सॉफ़्टवेयर परीक्षण प्रकारों के बीच अंतर के बारे में स्पष्ट हैं। नीचे टिप्पणी अनुभाग में अपने विचार साझा करने के लिए स्वतंत्र महसूस करें !!

अनुशंसित पाठ

^