🖐🏻 👩🏾‍🤝‍👩🏼 🖋️ केवल अंत-2-अंत परीक्षणों के लिए नहीं 👩🏻‍🎨 🔲 ✍🏻

आपके पास शायद यह तब था जब आप और आपके दोस्त वास्तव में एक फिल्म देखना चाहते थे, और फिर पछतावा हुआ कि आपने इस पर समय बिताया। या हो सकता है कि आपको वह पल याद हो जब आपकी टीम ने सोचा था कि उसे "हत्यारे की सुविधा" मिल गई थी और उत्पाद के जारी होने के बाद ही उसे "नुकसान" हुआ था।

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

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

स्रोत

सिद्धांत में अंत-2-अंत परीक्षण

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

इसलिए, Google की दस चीजों की सूची में नंबर एक , जैसा कि हम जानते हैं, यह सच है: "सभी के ऊपर उपयोगकर्ताओं के हित।" इस प्रकार, वास्तविक उपयोगकर्ता परिदृश्यों पर ध्यान केंद्रित करने वाले अंत-2-अंत परीक्षणों का उपयोग करना एक महान विचार की तरह लगता है। इसके अतिरिक्त, यह रणनीति आमतौर पर प्रक्रिया में कई प्रतिभागियों के लिए आकर्षक है।

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

End-2-end

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

मान लीजिए कि एक टीम दस्तावेजों को ऑनलाइन संपादन के लिए एक सेवा बनाती है (उदाहरण के लिए, Google डॉक्स)। मान लेते हैं कि टीम के पास पहले से ही परीक्षण के लिए कुछ शानदार बुनियादी ढांचे हैं। हर रात:

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

समय सीमा तेजी से आ रही है। उत्पाद की गुणवत्ता के उच्च स्तर को बनाए रखने के लिए, हम कहते हैं कि हम तय करते हैं कि कम से कम 90% सफल एंड-टू-एंड परीक्षणों की आवश्यकता है ताकि हम विचार करें कि संस्करण तैयार है। मान लीजिए कि समय सीमा एक दिन में आती है।

कई समस्याओं के बावजूद, परीक्षणों ने अंततः वास्तविक त्रुटियों का खुलासा किया। उपयोगकर्ता को प्रभावित करने वाली त्रुटियों को

अच्छी तरह से जाना गया

और उनके पहुंचने से पहले ही उन्हें ठीक कर लिया गया।

कुछ गलत हो गया

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

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

परीक्षणों का सही मूल्य

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

यहाँ जवाब है: "एक असफल परीक्षण सीधे उपयोगकर्ता को लाभ नहीं पहुंचाता है।"

हालांकि यह कथन, पहली नज़र में, चौंकाने वाला लगता है, यह सच है। यदि उत्पाद काम करता है, तो यह काम करता है, भले ही परीक्षण यह कहे कि यह काम करता है या नहीं। यदि कोई उत्पाद टूट गया है, तो यह टूट गया है, भले ही परीक्षण यह कहे कि यह टूट गया है या नहीं। तो, यदि असफल परीक्षण उपयोगकर्ता को लाभ नहीं देते हैं, तो उससे क्या लाभ होता है?

बग फिक्स उपयोगकर्ता को सीधे लाभ पहुंचाता है।

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

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

सही प्रतिक्रिया का निर्माण

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

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

छोटा सोचो, बड़ा नहीं

तो हम यह सही प्रतिक्रिया पाश कैसे बनाते हैं? छोटे की सोच, बड़े की नहीं।

यूनिट परीक्षण

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

यूनिट परीक्षण त्वरित हैं। हमें कोड का एक छोटा सा ब्लॉक लिखना होगा और हम पहले से ही इसे टेस्ट कर सकते हैं। यूनिट परीक्षण आमतौर पर काफी छोटे होते हैं। वास्तव में, एक सेकंड का दसवां हिस्सा यूनिट परीक्षणों के लिए बहुत लंबा है।
. , , . , — , , — .
. , , , , .

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

एंड-2-एंड टेस्ट

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

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

एकीकरण टेस्ट

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

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

पिरामिड का परीक्षण करें

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

आपके परीक्षणों के थोक पिरामिड के तल पर इकाई परीक्षण हैं। जैसे-जैसे आप पिरामिड को आगे बढ़ाते हैं, आपके परीक्षण अधिक व्यापक होते जाते हैं, लेकिन उसी समय, परीक्षणों की संख्या (आपके पिरामिड की चौड़ाई) कम हो जाती है।

एक अच्छे तरीके से, Google एक 70/20/10 जुदाई प्रदान करता है: 70% इकाई परीक्षण, 20% एकीकरण परीक्षण और 10% अंत -2 परीक्षण। प्रत्येक टीम के लिए सटीक अनुपात अलग होगा, लेकिन सामान्य तौर पर इसे पिरामिड के आकार को बनाए रखना चाहिए। निम्नलिखित "रूपों" से बचने की कोशिश करें:

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

जिस तरह एक साधारण पिरामिड वास्तविक जीवन में सबसे स्थिर संरचना होता है, उसी तरह एक परीक्षण पिरामिड भी सबसे स्थिर परीक्षण रणनीति बन जाता है।

नौकरियां

यदि आप प्यार करते हैं और यूनिट टेस्ट लिखना जानते हैं, तो आपका स्वागत है! कंपनी LANIT ने DevOps टीम में जावा डेवलपर के लिए एक वैकेंसी खोली है , जहां आपको समान विचारधारा वाले लोग मिलेंगे।

केवल अंत-2-अंत परीक्षणों के लिए नहीं