एक होमवर्क प्रश्न की तरह खुशबू आ रही है।
क्या सॉफ्टवेयर क्षेत्र में परीक्षण की आवश्यकता है?
हाँ। पूर्ण रूप से। सभी स्तरों पर। कुछ विशेष डोमेन के बाहर, हम अभी तक एक ऐसे चरण में नहीं हैं जहां हम गणितीय रूप से साबित कर सकते हैं कि हमारा कोड विशिष्ट बग के खिलाफ सही है (कम से कम एक उचित समय सीमा में नहीं), इसलिए हमें यह देखने के लिए चट्टानों को फेंकना होगा कि क्या और जहां यह टूट जाता है।
यदि हम बहुत सावधानी से एक सॉफ्टवेयर बनाते हैं, तो हमें परीक्षण क्यों करना चाहिए?
परीक्षण कोडिंग त्रुटियों को खोजने के बारे में नहीं है। यह सुनिश्चित करने के बारे में भी है कि आप अपनी सभी आवश्यकताओं को पूरा कर चुके हैं, और यह कि समग्र प्रणाली अपेक्षित रूप से प्रदर्शन करती है। अगर मेरी आवश्यकता है कि एक विफल लेनदेन को एक विशिष्ट त्रुटि कोड वापस करना होगा, तो मुझे दोनों को सत्यापित करने के लिए एक परीक्षण लिखने की आवश्यकता है कि कार्यक्षमता मौजूद है और यह सही तरीके से काम करता है।
और यह सब मानता है कि विनिर्देश और डिजाइन पूर्ण, सही और आंतरिक रूप से सुसंगत हैं, जो अक्सर ऐसा नहीं होता है। यहां तक कि अगर आप पत्र को विनिर्देश पूरा करते हैं और अंतिम डॉट और अर्धविराम के लिए डिज़ाइन का पालन करते हैं, अगर कल्पना या डिज़ाइन खराब है, तो एकीकरण समय पर समस्याएं होने वाली हैं। अक्सर, सिस्टम या एकीकरण परीक्षण तब होता है जब आपको पता चलता है कि विनिर्देश स्वयं छोटी गाड़ी है और इसे संशोधित किया जाना है (नीचे युद्ध की कहानी देखें)।
परीक्षण करने के बाद क्या हम यह सुनिश्चित कर सकते हैं कि हमने यह लक्ष्य प्राप्त कर लिया है (उत्पाद / सॉफ्टवेयर इरादा के अनुसार काम करता है) क्योंकि हमने इसके लिए परीक्षण किया है? क्या यह संभव है?
नहीं, 100% तक नहीं। हम किसी भी लेकिन सरलतम कोड में इनपुट या निष्पादन के रास्तों के हर बोधगम्य संयोजन का परीक्षण नहीं कर सकते हैं। हम सभी पर्यावरणीय कारकों का हिसाब नहीं दे सकते। हम सभी संभावित विफलता मोड की कल्पना नहीं कर सकते।
हम एक बिंदु है जहां हम कर रहे हैं करने के लिए परीक्षण कर सकते हैं यथोचित कोई बड़ी समस्या नहीं हैं सुनिश्चित करें। फिर, यही कारण है कि हमें सभी स्तरों पर परीक्षण करने की आवश्यकता है। यह सुनिश्चित करने के लिए कि आपके कोड में किनारे की स्थिति ठीक से खराब हो (खराब इनपुट, अप्रत्याशित परिणाम, अपवाद, आदि) सुनिश्चित करने के लिए परीक्षणों का एक सूट लिखें। इकाई परीक्षण यह सत्यापित करने के लिए कि आपका कोड इसकी आवश्यकताओं को पूरा करता है। एंड-टू-एंड प्रोसेसिंग को सत्यापित करने के लिए सिस्टम टेस्ट। यह सत्यापित करने के लिए कि सभी घटक एक-दूसरे से सही तरीके से बात करते हैं, एकीकरण परीक्षण। यह सुनिश्चित करने के लिए प्रयोज्य परीक्षण करें कि पूरी चीज़ इस तरह से काम करती है कि ग्राहक आपको गोली नहीं मारना चाहते।
वास्तविक दुनिया का परिदृश्य - मैं एक बैक-एंड सिस्टम पर काम कर रहा था जो कभी-कभी स्क्रीन पर एक तालिका में प्रदर्शन के लिए GUI सेवा को अपडेट भेजता है। प्रोजेक्ट के दौरान, फ़िल्टरिंग को डिस्प्ले में जोड़ने के लिए एक आवश्यकता जोड़ी गई थी (उदाहरण के लिए, ऑपरेटर तालिका में प्रविष्टियों का सबसेट प्रदर्शित कर सकता है)। डिजाइन गलती # 1 - फ़िल्टरिंग जीयूआई सेवा द्वारा किया जाना चाहिए था (मेरे पास यह विचित्र, पुरातन धारणा है कि प्रदर्शन प्रबंधन कार्य प्रदर्शन प्रबंधन सॉफ्टवेयर की जिम्मेदारी होनी चाहिए), लेकिन राजनीति और मेरी असमर्थता के कारण समस्याओं को पहचानने से पहले समस्याओं , कि आवश्यकता बैक-एंड सेवा पर रखी गई थी। खैर, ठीक है, कोई बात नहीं, मैं ऐसा कर सकता हूं। फ़िल्टर स्थिति में परिवर्तन होता है, मुझे एक संदेश मिलता है, और फिर मैं एक संदेश बनाता हूं या हटाता हूंतालिका में प्रत्येक पंक्ति , क्योंकि यह है कि इंटरफ़ेस कैसे काम करता है (डिजाइन गलती # 2 - एक संदेश में कई पंक्तियों में अपडेट भेजने का कोई तरीका नहीं है; हम एक "स्पष्ट" या "हटाएं" संदेश भी साफ नहीं कर सकते हैं पूरी मेज)।
खैर, विकास के दौरान कुछ भी ठीक काम करता है; यूनिट, सिस्टम और इंटीग्रेशन टेस्टिंग से पता चलता है कि मैं सही जानकारी भेजता हूँ और फ़िल्टर परिवर्तनों को सही ढंग से संभालता हूँ। तब हमें प्रयोज्य परीक्षण करने के लिए मिलता है, और पूरी चीज मुश्किल से गिरती है , क्योंकि डेटा की मात्रा भारी थी। मेरी बैकएंड सेवा और GUI के बीच नेटवर्क विलंबता .15 से .25 सेकंड के आदेश पर थी। बुरा नहीं यदि आपको केवल एक दर्जन पंक्तियों के लिए अपडेट भेजना है। घातक जब आपको कई सौ के लिए अपडेट भेजना होता है। हमें बग रिपोर्टें मिलनी शुरू हो गईं कि फ़िल्टर राज्य बदलने के बाद GUI फ्रीज हो गया; अच्छा, नहीं, जो हो रहा था वह कई मिनटों के क्रम पर हो रहा था प्रदर्शन को अद्यतन करने के लिए क्योंकि हड्डी-आधारित अपडेट-वन-रो-ए-इन-टाइम संदेश प्रोटोकॉल वास्तविक-विश्व परिदृश्य को संभाल नहीं सका।
ध्यान दें कि सभी को हो सकता था और उस चाहिए सभी तरह थोड़ा वर्ष मेरे लिए नीचे प्रधानमंत्री ठेकेदार से हर किसी के द्वारा अनुमानित किया गया है अगर हम पहले से भी सबसे बुनियादी विश्लेषण करने के लिए परेशान करता था। एकमात्र बचाव जो मैं पेश करूंगा वह यह है कि हम छह महीने की परियोजना के दूसरे वर्ष को बंद कर रहे थे जो कि डिलीवरी के तुरंत बाद रद्दी होने वाली थी, और हम सभी इसके पीछे देखने के लिए बेताब थे।
जो हमें परीक्षण करने के लिए अंतिम कारण के लिए लाता है - CYA। वास्तविक दुनिया की परियोजनाएं कई कारणों से विफल होती हैं, उनमें से कई राजनीतिक हैं, और हर कोई अच्छे विश्वास में काम नहीं करता है जब चीजें गलत हो जाती हैं। उंगलियां उठाई जाती हैं, आरोप लगाए जाते हैं, और दिन के अंत में आपको एक रिकॉर्ड दिखाने में सक्षम होने की आवश्यकता होती है जो यह दर्शाता है कि कम से कम आपका सामान काम करता है जैसा कि यह माना जाता था।
If we create a software with care in during its development period then why should we go for Test?- क्योंकि कोई बात नहीं, यहां तक कि सबसे कुशल प्रोग्रामर भी गलतियां करता है।