संबंधपरक डेटाबेस प्रतिगमन परीक्षण में डेटा गुणवत्ता


9

मैं एक ओपन सोर्स म्यूजियम कलेक्शंस मैनेजमेंट वेब एप्लिकेशन पर काम कर रहा हूं, जिसका इस्तेमाल किसी म्यूजियम के एक्सेसिनेटेड, डोनेटेड, लोन वाले या अन्यथा हासिल किए गए आर्टिफैक्ट्स पर नज़र रखने के लिए किया जाना है।

इसमें एक बड़ा डेटाबेस तैयार करना (मेरे पिछले अनुभवों के संबंध में) शामिल है, जो सभी प्रकार की बदलती जानकारी (कलाकृतियों की जानकारी, स्थान की जानकारी बदलने, व्यक्तिगत संपर्क जानकारी, चित्र आदि) को संग्रहीत करता है, जो लचीली और आसानी से विस्तार योग्य होनी चाहिए। ।

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

मैंने डेटाबेस परीक्षण पर पढ़ा है और कुछ लेखों में आया हूं जो डेटाबेस के संबंध में प्रतिगमन परीक्षण का उल्लेख करते हैं लेकिन मुझे पूरी तरह से समझ में नहीं आता है कि इसमें क्या शामिल है। Dr.Dobbs के इस लेख को पढ़ने से मैं समझता हूं कि एक प्रकार का परीक्षण जो मुझे करने की आवश्यकता होगी, यह मान्य है कि डेटाबेस में तर्क सही है। इसलिए मैं परीक्षण बनाऊंगा जो डेटाबेस में कुछ डेटा सम्मिलित करता है और फिर यह सुनिश्चित करने के लिए कि मैं डेटाबेस से सही डेटा प्राप्त कर रहा हूं (यह सुनिश्चित करना कि सभी उपयुक्त ट्रिगर या विचार काम कर रहे हैं) का पालन करें।

भ्रम "डेटा गुणवत्ता" के लिए परीक्षण के उल्लेख के साथ आता है। लेखक ऊपर लेख में उल्लेख करता है कि आप परीक्षण के साथ निम्नलिखित को मान्य करना चाहते हैं:

  • कॉलम डोमेन मान नियम
  • कॉलम डिफ़ॉल्ट मान नियम
  • मूल्य अस्तित्व के नियम
  • पंक्ति मूल्य नियम
  • आकार के नियम

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

जवाबों:


3

इस प्रश्न का पूरा उत्तर बहुत लंबा होगा। मैं मुख्य बिंदुओं का उल्लेख करने की कोशिश करूंगा।

चिंताओं को अलग करने के लिए, आप परीक्षणों को देख सकते हैं:

ए - डेटाबेस डिज़ाइन को मान्य करें।

B - सत्यापित करें कि प्रोग्राम (s) डेटाबेस के साथ सही तरीके से बातचीत कर रहे हैं।

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

अपने निर्दिष्ट प्रश्नों के उत्तर देने के लिए:

कॉलम डोमेन मान नियम

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

उदाहरण के लिए:

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

  • क्या आप उस स्तंभ में ऋणात्मक मान संग्रहीत कर सकते हैं, जहाँ व्यवसाय की आवश्यकता होती है?

कॉलम डिफ़ॉल्ट मान नियम

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

मूल्य अस्तित्व के नियम

जैसा कि मैं यह समझता हूं, आप डेटाबेस में अपेक्षित डेटा डाले गए या अपडेट किए गए शो को सत्यापित करते हैं।

पंक्ति मूल्य नियम

मैं इस बारे में स्पष्ट नहीं हूं कि इसका वास्तव में क्या मतलब है।

आकार के नियम

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

कैसे / कहाँ शुरू करने के लिए दिशा निर्देश

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

  • क्या स्तंभ को परिभाषित प्रकार का माना जाता है (इंट के रूप में नाम बनाने का कोई मतलब नहीं)।

  • क्या आकार व्यावसायिक आवश्यकताओं के अनुरूप है?

  • क्या डेटाबेस में व्यावसायिक आवश्यकताओं के सभी कॉलम पाए जाते हैं?

  • क्या नल के स्तंभ वास्तव में वैकल्पिक हैं?

  • आदि।

अगला, आप ऊपर परीक्षण करने के लिए परीक्षण मामलों को डिजाइन कर सकते हैं। आप अधिकांश परीक्षणों को करने के लिए GUI का उपयोग कर सकते हैं।

अन्य महत्वपूर्ण डेटाबेस परीक्षण हैं जिनका आपने उल्लेख नहीं किया है। उन लोगों के साथ सौदा:

1 - परीक्षण करना कि प्राथमिक कुंजी वास्तव में व्यावसायिक दृष्टिकोण से अद्वितीय है।

2 - परीक्षण जो अद्वितीय अनुक्रमित (पीके के अलावा) वास्तव में व्यापार के दृष्टिकोण से अद्वितीय हैं।

3 - परीक्षण विदेशी कुंजी बाधाओं काम करते हैं।

4 - जब एक पंक्तियों को हटा दिया जाता है और संबंधित पंक्तियों पर इसका प्रभाव होता है, तो परीक्षण करना।

5 - विशेष डेटाबेस के संबंध में अन्य परीक्षण जैसे कि CHEKC, ट्रिगर जैसे मौजूद हैं।

6 - सही टेबल सामान्यीकरण और सामान्यीकृत कॉलम सही मान रखते हैं।

ऊपर एक पूरी सूची नहीं है, लेकिन यह आपको आरंभ करना चाहिए।


आपके उत्तर में विस्तार के लिए धन्यवाद और परीक्षण के विकास के लिए आपके सुझाव एक अच्छी जगह की तरह लगते हैं। आपकी सहायता के लिए धन्यवाद।
क्रिस्टन डी।

KristenD। @Songo मैं प्रतिक्रिया की सराहना करता हूं।
NoChance

1

मुझे लगता है कि आप इस गलत तरीके से संपर्क कर रहे हैं।

किसी भी डेटाबेस को मैं जानता हूं कि इसे टेबल में डालने से पहले डेटा को सत्यापित करता है - यह इसे प्रत्येक कॉलम की परिभाषा के खिलाफ सत्यापित करता है। आप एक SMALLINT (3) कॉलम में एक 80 कैरेक्टर स्ट्रिंग दर्ज नहीं कर सकते हैं - डेटाबेस उस प्रयास को विफल कर देगा और आपको बताएगा कि आपने एक त्रुटि की है। आपको डेटा सम्मिलित करके और फिर उसे पुनः प्राप्त करके स्वयं के लिए परीक्षण करने की आवश्यकता नहीं है।

डेटाबेस में भेजे जाने से पहले आप जो चाहते हैं, वह डेटा पर सत्यापन / फ़िल्टरिंग नियम हैं ।

  • यह सुनिश्चित करना कि डेटा प्रत्येक कॉलम के लिए स्वीकृत प्रकारों और सीमा को फिट करता है, और अवांछित सामग्री को फ़िल्टर करता है
  • त्रुटियों से बचने के लिए इसे ठीक से बचाना सुनिश्चित करें (और यदि आपके पास एक सार्वजनिक इंटरफ़ेस है, तो संभावित SQL इंजेक्शन)

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

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


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