परीक्षण: मैनुअल या स्वचालित?

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

मुझे लगता है कि अभी इसका उपयोग करने लायक है, जिसका उपयोग हमने किया है:

• लगभग 50% कवरेज के साथ इकाई परीक्षण
• यूनिट परीक्षणों (और बाद के एकीकरण), स्वचालित विधानसभा और रिलीज के रिलीज के साथ निरंतर एकीकरण
• स्क्रैम्बनएक्सपीपी नाम के तहत चंचलता का अंतर

जहां भी मैं परीक्षण स्वचालन के बारे में बात करूंगा, हम इंटरफ़ेस को बाहरी संसाधनों (DB, फ़ाइल सिस्टम, सेवाओं, आदि) से जोड़ने के परीक्षण के बारे में बात करेंगे।

चरण 1. कोई परीक्षक नहीं हैं।

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

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

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

दीवार के पीछे चिल्लाते हुए त्रुटि रिपोर्टें आईं। कीड़े के दौरान नुकसान नगण्य थे, हर कोई स्थिति से खुश था।

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

चरण 2. परीक्षण स्वचालन शुरू करें

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

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

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

परीक्षणों को रिकॉर्ड करने के लिए, हमने विभिन्न विकल्पों की कोशिश की, सेलेनियम पर बसे। सबसे पहले, परीक्षण सेलेनियम एपीआई पर ही लिखे गए थे। समय के साथ, निम्न-स्तरीय API पर एक आवरण बनाया जाने लगा और यह आवरण परीक्षण के लिए एक प्रकार के DSL में बदल गया।

जबकि परीक्षक परीक्षण स्वचालन प्रक्रिया के परीक्षण और स्थापना के लिए उत्पादों की छंटनी कर रहा था, विकास बंद नहीं हुआ। हमें प्रत्येक 1-2 पुनरावृत्तियों के बाद नए संस्करण जारी करने थे। परीक्षक प्रोग्रामरों का पीछा करने के चरण में लगातार था। उनका लक्ष्य 100% स्क्रिप्टेड था ताकि हम बग के डर के बिना चुपचाप नए संस्करण जारी कर सकें।

चरण 3. हरे परीक्षणों के लिए लड़ो

परीक्षण स्वचालन के साथ समस्याएं हमारे लिए अप्रत्याशित थीं। वास्तव में, हम उनके लिए तैयार नहीं थे।

लंबी प्रतिक्रिया

प्रणाली जितनी बड़ी होगी, उतने ही अधिक परीक्षण हमने लिखे। टेस्ट वास्तव में धीरे-धीरे काम करने लगे। यदि वे 14 घंटे में गुजर गए - यह अविश्वसनीय भाग्य था। समय के साथ, परीक्षण अंतिम दिन के 18.00 और वर्तमान दिन के 9.00 के बीच फिट हो गए। हमें परीक्षणों से प्रतिक्रिया नहीं मिली; यह भी हुआ कि रोशनी बंद कर दी गई या सर्वर ने रिबूट किया, तो समय की हानि बहुत बड़ी थी।

ग्रीन परीक्षण? नहीं, मैंने नहीं देखा

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

वे हरे क्यों नहीं थे? इसके कई कारण थे:

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

परीक्षणों की अस्थिरता और इस तथ्य के कारण कि हमारे पास उन्हें अपडेट करने का समय नहीं था, हमें यह करना था:

• डेवलपर को स्विच करें ताकि वह परीक्षकों को SpecFlow पर स्विच करने में मदद करे , अन्यथा परीक्षकों ने C # कोड में परीक्षणों की मात्रा नहीं रखी। उस समय परीक्षण विभाग के प्रमुख खीरे के लिए स्वीकृति परीक्षण के विषय पर एक रिपोर्ट बना रहे थे
• 70% समय, परीक्षकों ने सिस्टम फ़ंक्शन के वर्तमान सेट से मिलान करने के लिए स्वचालित परीक्षणों को फिर से लिखा। यानी यह परीक्षणों की खातिर खुद का काम था।
• उपरोक्त के परिणामस्वरूप, हमने परीक्षकों को भी काम पर रखा।

क्या लक्ष्य तक पहुँच गया है?

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

नतीजतन, वास्तविक परिस्थितियों में सिस्टम के पहले लॉन्च से पता चला कि ऑटोटेस्ट्स में बहुत सारे कीड़े हैं। हमें ये कीड़े मिले जब हमने सिस्टम को मैन्युअल रूप से पेक किया। मैनुअल परीक्षण के 10 मिनट में, सबसे महत्वपूर्ण कीड़े की खोज की गई थी।

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

वर्तमान स्थिति

फिलहाल, मेरी कंपनी में, हम परीक्षकों की टीम के दृष्टिकोण का पालन करते हैं: Google डॉक्स में मैन्युअल परीक्षण + लेखन स्क्रिप्ट। परीक्षक मैन्युअल रूप से भरने से पहले सभी लिपियों को छेदते हैं।

परीक्षण परिदृश्यों को परियोजना की कलाकृतियों का हिस्सा माना जाता है और ग्राहक को स्रोत कोड के साथ दिया जाता है।

वास्तव में, यह उत्कृष्ट परिणाम देता है। रिलीज में, हमारे पास केवल मामूली कीड़े, या कीड़े हैं जो वास्तव में विशेषताएं हैं।

परीक्षण स्वचालन के खिलाफ?

आपको स्वचालन का परीक्षण करने के लिए दृष्टिकोण की प्रयोज्यता की सीमाओं को समझने की आवश्यकता है। उदाहरण के लिए, यदि आप एक बग लिखते हैं जो लाइव सर्वर पर 404 और 500 त्रुटियों को पकड़ता है, तो श्रम लागत उचित है।

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

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

मुझे यह सुनकर खुशी होगी कि आपकी कंपनी में परीक्षण कैसे विकसित हुआ है।

---

संदर्भ

शीर्ष पाँच (गलत) कारण आप परीक्षक नहीं है , जोएल स्पोलस्की
द जोएल टेस्ट: 12 स्टेप्स टू बेटर कोड , जोएल स्पोलस्की
बंदर बनाम रोबोट। भाग I (TestLabs09) , मैक्सिम डोरोफीव
बंदर बनाम रोबोट। भाग II (TestLabs09) , मैक्सिम डोरोफीव
बंदर बनाम रोबोट। भाग III (TestLabs09) , मैक्सिम डोरोफीव
फुर्तीली टीम का काम: विकास + परीक्षण