Erlang 21 - 15. Some Thoughts about Testing

15 परीक्षण के बारे में कुछ विचार




erlang

15 परीक्षण के बारे में कुछ विचार

15.1 लक्ष्य

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

15.2 क्या टेस्ट करना है

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

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

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

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

इसके अलावा, सब कुछ एक बार परीक्षण करने का लक्ष्य रखें, कोई कम नहीं, अधिक नहीं। यह प्रभावी नहीं है कि प्रत्येक परीक्षण का मामला केवल विफल हो क्योंकि इंटरफ़ेस में एक फ़ंक्शन बदल गया।