अमूर्त

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

आपको घटक परीक्षणों की आवश्यकता क्यों है?

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

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

जाहिर है, आवश्यकता मध्यवर्ती परीक्षणों के लिए उठती है, जो इकाई और स्वीकृति परीक्षणों के बीच सुनहरा मतलब होगा। यह मध्य जमीन घटक परीक्षण हो सकता है।

घटक परीक्षण क्या हैं?

ये सार्वजनिक घटक एपीआई के लिए परीक्षण हैं। तदनुसार, वे घटक के रूप में एक ही भाषा में लिखे गए हैं। परीक्षण का उद्देश्य:

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

जाहिर है, घटक परीक्षणों से समझ में आता है जब आपके पास व्यापक इंटरफ़ेस वाले घटक होते हैं। उदाहरण के लिए, एक गतिशील पुस्तकालय या एक COM ऑब्जेक्ट। फिर घटक परीक्षण अधिकतम प्रभाव देंगे।

K- परीक्षणों के पेशेवरों:

• विकास को स्थिरता दें। जाहिर है, सार्वजनिक इंटरफेस की एक व्यापक जांच आपको घटक को अधिक या कम कुशल रूप में रखने की अनुमति देती है।
• समस्याओं का सटीक रूप से स्थानीयकरण करें। यहां तक ​​कि अगर घटक परीक्षण स्वयं काफी सामान्य है, तो इसे हमेशा गहराई से डीबग किया जा सकता है, जल्दी से युद्ध कोड में पहुंच सकता है। इस मामले में, परीक्षण का वातावरण न्यूनतम और स्वचालित रूप से कॉन्फ़िगर किया जाएगा।
• विकासकर्ताओं की महत्वपूर्ण संख्या के साथ विकास में तेजी लाना। प्रोग्रामर को घोड़ों की तरह जाना जाता है। यदि एक घोड़ा 1 लीटर की क्षमता के साथ एक गाड़ी खींचता है। s।, तब आठ घोड़ों को केवल 4 लीटर की क्षमता के साथ खींचा जाता है। एक। और टीम के लिए एक और डेवलपर के अलावा (विशेष रूप से परियोजना के अंत में) अक्सर न केवल तेजी लाता है, बल्कि इसे धीमा कर देता है। जबकि घटक परीक्षण डेवलपर का जोड़ हमेशा एक प्लस होता है, क्योंकि यह टीम के अपेक्षाकृत स्वतंत्र रूप से कार्य करता है: यह (अनिवार्य रूप से बाहरी) परीक्षण करता है, बिल्ड के निर्माण को गति देता है, विधानसभा फ़ाइलों का अनुकूलन करता है, आदि।
• ग्राहकों की आवश्यकताओं को स्पष्ट करें (और फिर सत्यापित करें)। चूंकि घटक परीक्षणों के डेवलपर कार्यान्वयन से बंधा नहीं है, इसलिए वह "मुझे पता है कि यह कैसे करना है" प्रभाव से कम प्रभावित होता है। एक अस्पष्ट आवश्यकता के मामले में, साधारण डेवलपर आसानी से (अधिक दिलचस्प, तेज, आसान) के रूप में करने के लिए इच्छुक है। जबकि इस मामले में ct-developer यह बताने के लिए इच्छुक है कि ग्राहक द्वारा वास्तव में क्या अपेक्षित है।
• अपेक्षाकृत स्थिर और अपेक्षाकृत तेज़ (उपयोगकर्ता इंटरफ़ेस के माध्यम से मैन्युअल परीक्षणों और स्वचालित परीक्षणों की तुलना में)।

K- परीक्षणों की विपक्ष:

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

सारांश १

घटक परीक्षण अच्छे हैं, लेकिन केवल अगर आपके पास उनके लिए सभी शर्तें हैं: एक व्यापक सार्वजनिक एपीआई, सही वर्कफ़्लो, और टीम में सही लोग।

SDET होना कैसा है?

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

एसडीईटी के साथ काम करने के लाभ:

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

एसडीईटी के साथ काम करने की विपक्ष:

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

सारांश २

एक व्यक्ति के रूप में, जिसने कई वर्षों तक डेवलपर के रूप में काम किया, फिर कई वर्षों के लिए एसडीईटी में गया, और फिर फिर से विकास पर लौटा, मैं निम्नलिखित कह सकता हूं।

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