क्या सत्यापन और सत्यापन परीक्षण प्रक्रिया का हिस्सा है?


9

कई स्रोतों के आधार पर, मुझे विश्वास नहीं है कि परीक्षण का उद्देश्य सरल परिभाषा है, जितना संभव हो उतने कीड़े ढूंढना है - हम यह सुनिश्चित करने के लिए परीक्षण करते हैं कि यह काम करता है या यह नहीं करता है। उदाहरण के लिए परीक्षण प्रपत्र ISTQB के लक्ष्य हैं:

  1. निर्धारित करें कि (सॉफ़्टवेयर उत्पाद) निर्दिष्ट आवश्यकताओं को पूरा करते हैं (मुझे लगता है कि इसका सत्यापन)

  2. प्रदर्शित करें कि (सॉफ़्टवेयर उत्पाद) उद्देश्य के लिए फिट हैं (मुझे लगता है कि सत्यापन है)

  3. दोषों का पता लगाना

    मैं सहमत हूँ कि परीक्षण सत्यापन, सत्यापन और दोष का पता लगाने वाला है। क्या वो सही है?


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

निश्चित के अनुसार, सत्यापन सुनिश्चित करता है कि आवश्यकताओं को पूरा किया गया था। दरअसल, किताबें सॉफ्टवेयर की गुणवत्ता को मापने की प्रक्रिया के रूप में परीक्षण को परिभाषित करती हैं। इसलिए यदि आप जाँच कर रहे हैं कि सिस्टम काम कर रहा है (सकारात्मक) तो यह देखने के इरादे से कि क्या यह काम करता है, यह परीक्षण नहीं कर रहा है क्योंकि आप बग नहीं खोज रहे हैं? :) विकिपीडिया पर: टेस्ट तकनीकों में शामिल हैं, लेकिन इन तक सीमित नहीं हैं, सॉफ्टवेयर बग ढूंढने के इरादे से किसी प्रोग्राम या एप्लिकेशन को क्रियान्वित करने की प्रक्रिया
जॉन वी

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

एक "अच्छा सवाल" बोनस :)
एंड्रयू

जवाबों:


1

मुझे लगता है कि आपको यह बिल्कुल सही लगा।

  1. सत्यापन और सत्यापन अलग-अलग चीजें हैं और वास्तव में बहुत अच्छी तरह से परिभाषित हैं। हालाँकि मुझे दस्तावेज़ बहुत पसंद नहीं है क्योंकि ISO 9000ff, QA के लिए अत्यधिक प्रासंगिक है और सत्यापन को इसकी आवश्यकताओं और सत्यापन के साथ किसी उत्पाद की तुलना करने के रूप में परिभाषित करता है कि क्या यह वास्तव में ग्राहक / उपयोगकर्ता की आवश्यकताओं के अनुरूप है और हम सभी जानते हैं कि यह भिन्न हो सकता है ।

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

  3. एक सिद्धांत के आधार पर, मुझे लगता है कि कोई भी तर्क कर सकता है कि पहले दो द्वारा कवर कोई बग नहीं है और इसलिए बग को एक अलग लक्ष्य के रूप में खोजने से कोई मतलब नहीं है। लेकिन मुझे लगता है कि ऐसी चीजें हैं जो आप वास्तव में सत्यापित या सत्यापित नहीं कर सकते हैं। उदाहरण के लिए सुरक्षा: आप कैसे सत्यापित या सत्यापित करते हैं कि एक सॉफ्टवेयर सिस्टम हमलों के खिलाफ सुरक्षित है? इसके बजाय आप कमजोरियों को खोजने की कोशिश करते हैं। यदि यह समस्याएँ खोजने में विफल रहता है, तो यह खोज किसी चीज़ को सत्यापित या मान्य नहीं करती है, लेकिन यदि यह सफल हो जाती है, तो यह बग ढूंढ लेती है।


मुद्दा यह है कि कई स्रोतों का उल्लेख है कि सत्यापन केवल स्थिर है, जबकि सत्यापन गतिशील है। इसकी बहुत उलझन है। तब कार्यात्मक परीक्षण क्या होगा? मैं कहूंगा कि इसका गतिशील सत्यापन ..
जॉन वी।

1
सत्यापन और सत्यापन की इस परिभाषा का उपयोग कौन से स्रोत करते हैं? दूसरी ओर मैं किसी भी स्पष्ट नहीं जानता और आम तौर पर अंत में किसी भी चीज की परिभाषा पर सहमत हूं। इसलिए मैं वास्तव में नहीं जानता कि आपके लिए एक कार्यात्मक परीक्षण क्या है।
जेन्स स्काउडर

खैर जैसे आईएसओ 12207 एक सत्यापन के रूप में परीक्षण को प्रतिबंधित करता है केवल असफल।
जॉन वी।

3

विकिपीडिया से: "... दूसरे शब्दों में, सत्यापन यह सुनिश्चित करता है कि उत्पाद वास्तव में उपयोगकर्ता की आवश्यकताओं को पूरा करता है , और यह कि विनिर्देश पहले स्थान पर सही थे , जबकि सत्यापन यह सुनिश्चित कर रहा है कि उत्पाद आवश्यकताओं और डिजाइन विनिर्देशों के अनुसार बनाया गया है। सत्यापन सुनिश्चित करता है कि "आपने सही चीज़ का निर्माण किया है"। सत्यापन सुनिश्चित करता है कि "आपने इसे सही तरीके से बनाया है"। सत्यापन यह पुष्टि करता है कि उत्पाद, जैसा कि प्रदान किया गया है, अपने इच्छित उपयोग को पूरा करेगा। "

आप उपयोगकर्ता की जरूरतों का परीक्षण नहीं कर सकते हैं और जांच सकते हैं कि क्या विनिर्देश कोड द्वारा सही थे। इसलिए परीक्षण द्वारा सत्यापन नहीं किया जाता है।

सत्यापन यह बताता है कि आपकी आवश्यकताएं और डिज़ाइन सही हैं, इसलिए आप इसे कोड (परीक्षण) लिखकर परीक्षण कर सकते हैं।


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

वास्तव में आप सही हैं। परीक्षण प्रक्रिया में स्वीकार करना परीक्षण भी शामिल है लेकिन मैंने यूनिट, एकीकरण और सिस्टम परीक्षण के बारे में बात की। अगर हम परीक्षण प्रक्रिया के बारे में सोचते हैं, तो परीक्षण द्वारा सत्यापन और सत्यापन किया जाता है।
मर्ट अक्ककाया

1

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

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


1

सत्यापन और सत्यापन की कई परिभाषाएँ हैं। बहुत से लोग एक ही गतिविधि में दोनों को समूह में V & V टैग का उपयोग करते हैं। उद्देश्य यह सुनिश्चित करना है कि सॉफ्टवेयर सही चीजें बनाता है और चीजों को सही बनाता है। चाहे वह आवश्यकताओं के अनुपालन की जांच करना हो या बग्स को खोजने की कोशिश करना इस स्तर पर आवश्यक नहीं है।

परीक्षण सत्यापन और सत्यापन के लिए कई तकनीकों में से एक है, दूसरे तरीके से नहीं। कोड की समीक्षा एक और एक है, और औपचारिक सत्यापन, गणितीय प्रमाणों के साथ अभी तक एक और।

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

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

एक महान परीक्षक सॉफ्टवेयर को तोड़ने के बारे में भावुक होता है, न कि इसे सुरक्षित तरीके से प्रयोग करने के बारे में।


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

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

म्यूवीकल: ऑक्सीमोरोन? मुझे ऐसा नहीं लगता है, स्थैतिक परीक्षण का मतलब निष्पादन के बिना संभावित दोषों की जांच करना है, जो पूरी तरह से संभव है (आवश्यकताओं के मुद्दे, डिजाइन की खामियां ..)। आवश्यकताओं को सत्यापित करने और बग्स के लिए जाँच करने के लिए यह समान नहीं है: आपको यह परीक्षण करना चाहिए कि कोई फ़ील्ड int32 मान रख सकता है। Thats परीक्षण है कि यह काम करता है। फिर आप उच्च मूल्यों में प्रवेश करने की कोशिश कर सकते हैं, जो कि बग के लिए परीक्षण कर रहा है ..
जॉन वी।

1

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

तो सवाल के उस भाग के लिए, बग ढूंढना और सत्यापन करना एक ही प्रक्रिया के दो पहलू हो सकते हैं:

  • परीक्षण विफल: दोष पाया गया

  • परीक्षण पास: सत्यापन किया गया (कम से कम, कुछ हद तक, यदि आप पर्याप्त और सही परीक्षण प्रदान करते हैं)

सत्यापन के बारे में: जैसा कि @Mert ने बताया है, सत्यापन स्वीकृति परीक्षण द्वारा किया जा सकता है, लेकिन परीक्षण के अन्य रूपों द्वारा नहीं। इस प्रकार सामान्य रूप से परीक्षण का कोई कारण नहीं होता है, केवल जब कुछ संभावित उपयोगकर्ताओं द्वारा स्वीकृति परीक्षण के रूप में किया जाता है।


0

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


0

सॉफ्टवेयर परीक्षण क्यूए के समान नहीं है। आपको लगता है कि सही मिला। सॉफ्टवेयर परीक्षण समग्र रूप से अपने आप में कई चरणों (धुआं, इकाई, प्रतिगमन, एकीकरण, उपयोगकर्ता स्वीकृति आदि) को शामिल करता है।

इस प्रकार, यह आश्वस्त करने के लिए कि सॉफ़्टवेयर आवश्यकताओं के अनुसार काम करता है, क्यूए का आदमी लक्ष्य है (गुणवत्ता आश्वासन विशेषज्ञ - उर्फ ​​वर्षों पहले केवल परीक्षक कहा जाता था)। हालांकि, यह सिर्फ परीक्षण नहीं है । क्यूए यह सुनिश्चित करता है कि प्रश्न में उत्पाद की गुणवत्ता की जांच करने के लिए प्रक्रियाओं का उचित सेट जगह में है, या कम से कम परियोजना के डिजाइन चरण में लिया गया है।

इस प्रकार, आदर्श रूप से आप अपेक्षा करेंगे कि आपके क्यूए आवश्यकताओं के सेट के खिलाफ आवेदन को सत्यापित करें और न केवल सॉफ़्टवेयर को तोड़कर और दोषों का पता लगाकर इसका परीक्षण करने का प्रयास करें।


क्यूए सिर्फ परीक्षण नहीं है। क्यूए विकास प्रक्रियाओं की गुणवत्ता से संबंधित है ..
जॉन वी।

क्यूए आवश्यकताओं के सेट के खिलाफ आवेदन की पुष्टि करता है।
युसुबोव
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.