मैं सिर्फ इसलिए जोड़ना चाहता था कि हमारे पास इन स्तरों का परीक्षण क्यों है, उदाहरण के साथ उनका वास्तव में क्या मतलब है
माइक कोहन ने अपनी पुस्तक "एग्ज़ीक्यूटिंग विद एजाइल" को प्रोजेक्ट्स में स्वचालित परीक्षण का तरीका बताने के लिए "टेस्टिंग पिरामिड" के साथ पेश किया। इस मॉडल की विभिन्न व्याख्याएं हैं। मॉडल बताता है कि किस प्रकार के स्वचालित परीक्षणों को बनाने की आवश्यकता है, वे परीक्षण के तहत आवेदन पर कितनी तेजी से प्रतिक्रिया दे सकते हैं और इन परीक्षणों को कौन लिखता है। मूल रूप से किसी भी परियोजना के लिए आवश्यक स्वचालित परीक्षण के 3 स्तर हैं और वे निम्नानुसार हैं।
यूनिट टेस्ट-
ये आपके सॉफ़्टवेयर एप्लिकेशन के सबसे छोटे घटक का परीक्षण करते हैं। यह कोड में शाब्दिक रूप से एक फ़ंक्शन हो सकता है जो कुछ इनपुट के आधार पर एक मूल्य की गणना करता है। यह फ़ंक्शन हार्डवेयर / सॉफ़्टवेयर कोडबेस के कई अन्य कार्यों का हिस्सा है जो एप्लिकेशन बनाता है।
उदाहरण के लिए - आइए एक वेब आधारित कैलकुलेटर एप्लिकेशन लें। इस एप्लिकेशन के सबसे छोटे घटक जिन्हें यूनिट की जांच करने की आवश्यकता होती है, एक ऐसा फ़ंक्शन हो सकता है जो जोड़-घटाव करता है, एक और जो घटाव और इतने पर करता है। इन सभी छोटे कार्यों को एक साथ रखा जाता है, जिससे कैलकुलेटर एप्लिकेशन तैयार होता है।
ऐतिहासिक रूप से डेवलपर इन परीक्षणों को लिखते हैं क्योंकि वे आमतौर पर उसी प्रोग्रामिंग भाषा में सॉफ़्टवेयर एप्लिकेशन के रूप में लिखे जाते हैं। यूनिट परीक्षण चौखटे जैसे कि JUnit और NUnit (जावा के लिए), MSTest (C # और .NET के लिए) और जैस्मीन / मोचा (जावास्क्रिप्ट के लिए) का उपयोग इस उद्देश्य के लिए किया जाता है।
यूनिट परीक्षणों का सबसे बड़ा लाभ यह है कि वे यूआई के नीचे बहुत तेजी से चलते हैं और हम आवेदन के बारे में त्वरित प्रतिक्रिया प्राप्त कर सकते हैं। इसमें आपके स्वचालित परीक्षणों में से 50% से अधिक शामिल होना चाहिए।
एपीआई / एकीकरण टेस्ट-
ये सॉफ्टवेयर सिस्टम के विभिन्न घटकों को एक साथ परखते हैं। घटकों में परीक्षण डेटाबेस, एपीआई (एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस), 3 पार्टी उपकरण और सेवाएं शामिल हो सकती हैं।
उदाहरण के लिए - ऊपर हमारे कैलकुलेटर उदाहरण में, वेब एप्लिकेशन मानों को संग्रहीत करने के लिए एक डेटाबेस का उपयोग कर सकता है, कुछ सर्वर साइड सत्यापन करने के लिए एपीआई का उपयोग कर सकता है और इसे अलग-अलग उपलब्ध कराने के लिए क्लाउड पर परिणाम प्रकाशित करने के लिए एक 3 पार्टी टूल / सेवा का उपयोग कर सकता है। प्लेटफार्मों।
ऐतिहासिक रूप से एक डेवलपर या तकनीकी क्यूए इन परीक्षणों को पोस्टमैन, सोपुई, जेमीटर और टेस्टिम के अन्य उपकरणों जैसे विभिन्न उपकरणों का उपयोग करके लिखेंगे।
ये यूआई परीक्षणों की तुलना में बहुत तेज चलते हैं क्योंकि वे अभी भी हुड के नीचे चलते हैं, लेकिन यूनिट परीक्षणों की तुलना में थोड़ा अधिक समय का उपभोग कर सकते हैं क्योंकि इसमें सिस्टम के विभिन्न स्वतंत्र घटकों के बीच संचार की जांच करना और यह सुनिश्चित करना है कि उनका सहज एकीकरण है। इसमें और अधिक शामिल होना चाहिए कि स्वचालित परीक्षणों का 30%।
UI टेस्ट-
अंत में, हमारे पास परीक्षण हैं जो एप्लिकेशन के UI को मान्य करते हैं। इन परीक्षणों को आमतौर पर आवेदन के माध्यम से प्रवाह के अंत परीक्षण के लिए लिखा जाता है।
उदाहरण के लिए - कैलकुलेटर एप्लिकेशन में, एंड टू फ्लो का अंत हो सकता है, ब्राउज़र को खोलना-> कैलकुलेटर एप्लिकेशन को एंटर करना url -> यूजरनेम / पासवर्ड के साथ लॉग इन करना -> कैलकुलेटर एप्लिकेशन को खोलना -> कैलकुलेटर पर कुछ ऑपरेशन करना -> यूआई से उन परिणामों की पुष्टि -> आवेदन से बाहर लॉगिंग। यह एक अंत से अंत प्रवाह हो सकता है जो UI स्वचालन के लिए एक अच्छा उम्मीदवार होगा।
ऐतिहासिक रूप से, तकनीकी क्यूए या मैनुअल परीक्षक यूआई परीक्षण लिखते हैं। वे सेलेनियम या यूआई परीक्षण प्लेटफार्मों जैसे ओपन सोर्स फ्रेमवर्क का उपयोग करते हैं जैसे कि टेस्टिम से लेखक तक, परीक्षण निष्पादित और बनाए रखना। ये परीक्षण अधिक दृश्य प्रतिक्रिया देते हैं क्योंकि आप देख सकते हैं कि परीक्षण कैसे चल रहे हैं, स्क्रीनशॉट और लॉग के माध्यम से अपेक्षित और वास्तविक परिणामों के बीच का अंतर, परीक्षण रिपोर्ट।
यूआई परीक्षणों की सबसे बड़ी सीमा इकाई और एपीआई स्तर परीक्षणों की तुलना में अपेक्षाकृत धीमी है। तो, इसमें समग्र स्वचालित परीक्षणों का केवल 10-20% शामिल होना चाहिए।
अगले दो प्रकार के परीक्षण आपके प्रोजेक्ट के आधार पर भिन्न हो सकते हैं लेकिन विचार यह है कि-
स्मोक टेस्ट
यह परीक्षण के उपरोक्त 3 स्तरों का एक संयोजन हो सकता है। विचार यह है कि इसे हर कोड जांच के दौरान चलाया जाए और यह सुनिश्चित किया जाए कि सिस्टम की महत्वपूर्ण कार्यक्षमताएं अभी भी अपेक्षित रूप से काम कर रही हैं; नए कोड परिवर्तन के बाद मर्ज किए गए हैं। विफलताओं पर तेजी से प्रतिक्रिया पाने के लिए उन्हें आमतौर पर 5 - 10 मिनट तक दौड़ने की आवश्यकता होती है
प्रतिगमन परीक्षण
वे आमतौर पर दिन में कम से कम एक बार चलाए जाते हैं और सिस्टम की विभिन्न कार्यक्षमता को कवर करते हैं। वे सुनिश्चित करते हैं कि आवेदन अभी भी उम्मीद के मुताबिक काम कर रहा है। वे धुएं के परीक्षण से अधिक विवरण हैं और गैर-महत्वपूर्ण लोगों सहित आवेदन के अधिक परिदृश्यों को कवर करते हैं।
