टेस्ट ऑटोमेशन: विपक्ष

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



परीक्षण स्वचालन का अंतिम लक्ष्य ऑटोटेस्ट्स का एक सेट है, जो जब आप "गो!" बटन पर क्लिक करते हैं, तो एक के बाद एक लॉन्च किया जाएगा। यदि आवश्यक हो, तो ठीक है, या आप हमेशा किसी भी ऑटोटेस्ट को अलग से चला सकते हैं। प्रत्येक ऐसी स्क्रिप्ट एप्लिकेशन के एक निश्चित भाग के सही संचालन की जांच करती है और कुछ सही ढंग से काम नहीं करने पर त्रुटियों को ठीक करती है।

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

स्वचालन के लिए परीक्षणों का चयन

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

उदाहरण के लिए, यह असंभव है (पढ़ें: बहुत मुश्किल) इस तरह की चीजों के परीक्षण को स्वचालित करने के लिए:

• ऑपरेटिंग सिस्टम की स्थापना
• एक प्रिंटर द्वारा मुद्रित दस्तावेज़ की जाँच करना
• चित्र, वीडियो की सामग्री की जाँच करना

की लागत

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



स्वचालन पर खर्चों की एक अलग वस्तु ऑटोटेस्ट्स का समर्थन है।

समर्थन

ऑटो परीक्षणों को हमेशा समर्थन की आवश्यकता होती है। चूंकि ऑटोटैस्ट लिखना प्रोग्रामिंग है, इसलिए ऑटोटैस्ट के तर्क को बदलने / ठीक करने के लिए आपको स्रोत कोड में जाने की आवश्यकता होती है। ऐसा करने के लिए, आपको अतिरिक्त विशेषज्ञों को नियुक्त करने की आवश्यकता है जो लिखित लिपियों के साथ होंगे। ये नए खर्च हैं जिन्हें टाला नहीं जा सकता है और जो ऑटोटेस्ट की लागत में काफी वृद्धि करते हैं। 2 मुख्य मामले हैं जिनमें स्रोत कोड में हस्तक्षेप आवश्यक हो सकता है:

1. परीक्षण के लिए इनपुट बदलें

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

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

2. कार्यक्षमता में परिवर्तन

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

उदाहरण: कार्यक्रम के पुराने संस्करण में एक मेनू था "फ़ाइल -> विकल्प", नए संस्करण में यह आइटम दो में विभाजित किया गया था: "फ़ाइल -> सेटिंग्स" और "फ़ाइल -> विकल्प"। ऑटोटेस्ट अभी भी "विकल्प" आइटम की खोज करेगा, और यहां तक ​​कि अगर आप क्रैक करते हैं, तो यह "सेटिंग्स" नहीं मिलेगा।

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



दोनों मामलों में, डेवलपर्स पर बहुत कुछ निर्भर करता है: ऑटोटेस्ट लिखने की प्रक्रिया को किसी भी अन्य सॉफ़्टवेयर को बनाने की प्रक्रिया से कम ज्ञान और प्रयास की आवश्यकता नहीं होती है। इसलिए, विकास से जुड़ी सभी समस्याएं यहां प्रकट होती हैं: गुणवत्ता नियंत्रण और विश्वसनीयता की जटिलता, समय सीमा का स्थगन, बजट में बदलाव और कई अन्य।

और अभी तक

इन नुकसानों का मतलब यह नहीं है कि आपको हर कीमत पर ऑटोटेस्ट से बचना चाहिए। वे उपयोगी भी हैं।

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







स्वचालन के कुछ और लाभ:

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