मेन्यू

ईटीएल और डेटा माइग्रेशन परियोजनाओं के लिए डेटा सत्यापन टेस्ट

  • मुख्य
  • अन्य
  • ईटीएल और डेटा माइग्रेशन परियोजनाओं के लिए डेटा सत्यापन टेस्ट

data validation tests

समस्याओं को खत्म करने के लिए हमारे साधन का प्रयास करें

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

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

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

ईटीएल और डेटा माइग्रेशन परियोजनाओं के लिए डेटा सत्यापन

जिन डेटा गुणवत्ता पहलुओं का परीक्षण किया जा सकता है, उनकी संख्या बहुत बड़ी है और नीचे दी गई सूची इस विषय का परिचय देती है।

आप क्या सीखेंगे:

डेटा सत्यापन क्या है?

आंकड़ा मान्यीकरण

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

उदाहरण: छात्र तालिका में एक छात्र का पता स्रोत प्रणाली में 2000 वर्णों का था। डेटा सत्यापन सत्यापित करता है कि क्या सटीक समान मान लक्ष्य प्रणाली में रहता है। यह जांचता है कि क्या डेटा छोटा किया गया था या यदि कुछ विशेष वर्ण हटा दिए गए हैं।

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

ईटीएल परियोजनाओं के लिए वैध डेटा क्यों?

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

यहां, डेटा सत्यापन की पुष्टि करने के लिए आवश्यक है कि जो डेटा लक्ष्य प्रणाली में लोड किया गया है वह पूर्ण, सटीक है और कोई डेटा हानि या विसंगतियां नहीं हैं।

लक्ष्य और स्रोत प्रणाली

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

साधारण डेटा सत्यापन परीक्षण यह देखना है कि CustomerRating की सही गणना की गई है।

एक अन्य परीक्षण यह सत्यापित करने के लिए है कि TotalDollarSpend को मानों या अधिकतम मूल्य के ओवरफ्लो को पूरा करने में कोई दोष नहीं है।

डेटा माइग्रेशन प्रोजेक्ट्स के लिए डेटा को मान्य क्यों करें?

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

ऐसी परियोजनाओं का प्राथमिक उद्देश्य स्रोत प्रणाली से लक्ष्य प्रणाली में डेटा को स्थानांतरित करना है, ताकि व्यवसाय में किसी भी व्यवधान या नकारात्मक प्रभाव के बिना लक्ष्य में डेटा अत्यधिक उपयोगी हो।

यहां फिर से, स्रोत पर डेटा की पुष्टि करने के लिए डेटा सत्यापन की आवश्यकता होती है जो आंदोलन के बाद लक्ष्य में समान है।

उदाहरण: ई-कॉमर्स एप्लिकेशन के लिए मान लें, 200 मिलियन पंक्तियों वाले आदेश तालिका को Azure पर लक्ष्य प्रणाली में माइग्रेट किया गया था। सरल डेटा सत्यापन परीक्षण लक्ष्य प्रणाली में उपलब्ध डेटा की सभी 200 मिलियन पंक्तियों को सत्यापित करने के लिए है।

एक अन्य परीक्षण यह पुष्टि करने के लिए हो सकता है कि स्रोत और लक्ष्य प्रणाली के बीच दिनांक प्रारूप मेल खाते हैं।

ऐसे कई पहलू हैं जो परीक्षक ऐसी परियोजनाओं में परीक्षण कर सकते हैं जैसे कार्यात्मक परीक्षण, प्रदर्शन परीक्षण, सुरक्षा परीक्षण, इन्फ्रा परीक्षण, E2E परीक्षण, प्रतिगमन परीक्षण, आदि।

अनुशंसित पढ़ना => डेटा माइग्रेशन परीक्षण , ETL टेस्टिंग डेटा वेयरहाउस टेस्टिंग ट्यूटोरियल

इस लेख में, हम केवल ETL और प्रवासन परियोजनाओं के लिए परीक्षण के डेटा पहलू को देखेंगे।

डाटा मैपिंग शीट

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

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

से एक खाका डाउनलोड करें सरलीकृत डेटा मानचित्रण शीट

डेटा सत्यापन टेस्ट

(1) डेटा एकरूपता

डेटा एकरूपता परीक्षण यह सत्यापित करने के लिए किया जाता है कि इकाई के वास्तविक मूल्य का विभिन्न स्थानों पर सटीक मेल है। हमारे यहाँ दो प्रकार के परीक्षण संभव हैं:

(i) एक ही स्कीमा के भीतर जाँच:

  • डेटा इकाई एक ही स्कीमा के भीतर दो तालिकाओं में मौजूद हो सकती है (या तो स्रोत प्रणाली या लक्ष्य प्रणाली)
  • उदाहरण: जैसा कि आप नीचे दी गई छवि में देख सकते हैं, ProductID ऑर्डरडेटेल और उत्पाद तालिका में मौजूद है। ProductDd के लिए ऑर्डरडेटेल बनाम उत्पाद तालिका में मौजूद सटीक मिलान सत्यापन करें।

सरलीकृत डेटा मानचित्रण Sheet1

(ii) स्कीमा भर में चेक:

  • डेटा इकाई को लक्ष्य स्कीमा में माइग्रेट किया जा सकता है यानी यह स्रोत प्रणाली में मौजूद है और साथ ही लक्ष्य प्रणाली
  • उदाहरण: जैसा कि आप उपरोक्त छवि में देख सकते हैं, ProductID स्रोत प्रणाली में उत्पाद तालिका में मौजूद है और लक्ष्य प्रणाली में उत्पाद तालिका। स्रोत प्रणाली में ProductId के लिए एक सटीक मिलान सत्यापन स्रोत प्रणाली में ProductId को लक्ष्य प्रणाली में उत्पाद तालिका में करें।

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

# 2) इकाई उपस्थिति

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

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

कभी-कभी विभिन्न तालिका नामों का उपयोग किया जाता है और इसलिए एक सीधी तुलना काम नहीं कर सकती है। हमें डेटा मैपिंग शीट में इस जानकारी को मैप करना होगा और विफलताओं के लिए इसे मान्य करना होगा।

एक और संभावना डेटा की अनुपस्थिति है। ऐसे मामले हैं जहां डेटा मॉडल की आवश्यकता होती है कि स्रोत प्रणाली (या स्तंभ) में एक तालिका में लक्ष्य प्रणाली (या इसके विपरीत) में एक समान उपस्थिति नहीं होती है। इसे मान्य करने के लिए परीक्षण करें।

  • उदाहरण: जैसा कि आप नीचे दी गई छवि में देख सकते हैं, CustDemographic Table लक्ष्य प्रणाली में मौजूद है न कि स्रोत प्रणाली में।
  • ग्राहक तालिका में CustomerType फ़ील्ड में केवल स्रोत सिस्टम में डेटा है न कि लक्ष्य प्रणाली में।

डार्ट (डेटा सटीकता)

# 3) डेटा सटीकता

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

डेटा अखंडता

(छवि स्रोत )

ध्यान दें: इस परीक्षण को लक्ष्य प्रणाली में चलाएं और किसी भी दोष के लिए स्रोत प्रणाली में बैकचेक करें।

(i) गैर-संख्यात्मक प्रकार: इस वर्गीकरण के तहत, हम गैर-संख्यात्मक सामग्री की सटीकता को सत्यापित करते हैं। उदाहरण ईमेल, पिन कोड, फोन एक वैध प्रारूप में हैं।

(ii) डोमेन विश्लेषण: इस प्रकार के परीक्षण में, हम डेटा के डोमेन चुनते हैं और त्रुटियों के लिए मान्य होते हैं। इसके लिए तीन समूह हैं:

  • मूल्य के आधार पर: यहां हम उन मानों की एक सूची बनाते हैं जो किसी फ़ील्ड (तालिका में स्तंभ) के लिए हो सकते हैं। तब मान्य करें यदि स्तंभ मान हमारी सूची का सबसेट है।
    • उदाहरण: सत्यापित करें कि लिंग स्तंभ में M या F सम्‍मिलित है।
  • रेंज के आधार पर: यहां हम तार्किक या व्यावसायिक तर्क के आधार पर, स्तंभ के लिए मान्य डेटा मानों के लिए न्यूनतम और अधिकतम सीमा निर्धारित करते हैं। यदि स्तंभ मान इस सीमा के भीतर आते हैं, तो हम तब मान्य करते हैं।
    • उदाहरण: आयु के लिए 0 से 120।
  • संदर्भ फ़ाइल : यहां सिस्टम एक बाहरी वैधता फ़ाइल का उपयोग करता है।
    • उदाहरण: क्या कंट्री कोड मान्य हैं, क्या वे संदर्भ फ़ाइल से सही मान लेते हैं, क्या देश कोड क्यूए और उत्पादन वातावरण के बीच समान हैं? यदि संदर्भ फ़ाइल में एक देश कोड अपडेट किया गया था, तो क्या यह DB में सही तरीके से अपडेट किया गया है?

# 4) मेटाडेटा सत्यापन

मेटाडेटा सत्यापन में, हम पुष्टि करते हैं कि लक्ष्य के लिए तालिका और स्तंभ डेटा प्रकार परिभाषाएँ सही ढंग से डिज़ाइन की गई हैं, और एक बार डिज़ाइन किए जाने के बाद उन्हें डेटा मॉडल डिज़ाइन विनिर्देशों के अनुसार निष्पादित किया जाता है।

यहां दो समूह हैं:

दो मेजबानों के बीच नेटवर्क के लिए उपयुक्त सबनेट मास्क क्या है

(i) मेटाडाटा डिजाइन: पहला चेक यह सत्यापित करने के लिए है कि लक्ष्य तालिका के लिए व्यावसायिक आवश्यकताओं के अनुसार डेटा मॉडल को सही ढंग से डिज़ाइन किया गया है। डेटा आर्किटेक्ट स्कीमा संस्थाओं को स्थानांतरित कर सकते हैं या जब वे लक्ष्य प्रणाली को डिज़ाइन करते हैं तो संशोधन कर सकते हैं।

अगला चेक यह सत्यापित करने के लिए होना चाहिए कि डेटा मॉडल का उपयोग करके सही स्क्रिप्ट बनाई गई थीं।

नीचे दी गई प्रत्येक श्रेणी के लिए, हम पहले यह सत्यापित करते हैं कि लक्ष्य प्रणाली के लिए निर्धारित मेटाडेटा व्यवसाय की आवश्यकता को पूरा करता है और दूसरी बात, यदि तालिकाओं और फ़ील्ड परिभाषाओं को सटीक रूप से बनाया गया था।

मेटाडेटा के कुछ चेक नीचे दिए गए हैं:

  • डेटा प्रकार की जाँच करें: उदाहरण: दशमलव (8, 16, या 20 बाइट्स) या डबल प्रकार के साथ कुल बिक्री सही ढंग से काम करेगी?
  • डेटा की लंबाई की जाँच : उदाहरण: क्या पता फ़ील्ड के लिए डेटा की लंबाई 500 वर्णों के साथ पर्याप्त होगी? यह एक ऐसा मामला हो सकता है जहां डेटा का माइग्रेशन किया जाता है क्योंकि कंपनी में नया भूगोल जोड़ा जा रहा है। नए भूगोल के पतों में एक अत्यधिक लंबा प्रारूप हो सकता है और मूल लंबाई से चिपके रहने से उपयोग के मामले में त्रुटि हो सकती है।
  • सूचकांक जांच: उदाहरण: क्या टार्गेट सिस्टम में ऑर्डरआईड कॉलम के लिए इंडेक्सिंग की जाती है? क्या होगा यदि कंपनियों का एक विलय हुआ, डेटा माइग्रेशन की आवश्यकता होती है और टारगेट सिस्टम में ऑर्डर तालिका आकार में 100 गुना बढ़ती है?
  • मेटाडाटा की जाँच करें व्यापक वातावरण: इस जाँच के तहत मेटाडाटा QA परीक्षण और उत्पादन वातावरण के बीच मेल खाता है। क्यूए वातावरण में टेस्ट पास हो सकते हैं लेकिन अन्य वातावरण में असफल हो सकते हैं।

(ii) डेल्टा परिवर्तन: ये परीक्षण उन दोषों को उजागर करते हैं जो परियोजना के प्रगति पर होते हैं और मध्य-मार्ग में स्रोत प्रणाली के मेटाडेटा में परिवर्तन होते हैं और लक्ष्य प्रणालियों में लागू नहीं होते हैं।

उदाहरण: नए फ़ील्ड CSI (ग्राहक संतुष्टि सूचकांक) को स्रोत में ग्राहक तालिका में जोड़ा गया था, लेकिन लक्ष्य प्रणाली में बनाए जाने में विफल रहा।

# 5) डेटा इंटीग्रिटी

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

माता-पिता की मेज

(छवि स्रोत )

विदेशी कुंजियों के लिए, हमें यह जांचने की आवश्यकता है कि क्या चाइल्ड टेबल में अनाथ रिकॉर्ड हैं जहां उपयोग की गई विदेशी कुंजी पैरेंट टेबल में मौजूद नहीं है।

डेटा पूर्णता जांच

उदाहरण: ग्राहक तालिका में CustomerID है जो एक प्राथमिक कुंजी है। आदेश तालिका में एक विदेशी कुंजी के रूप में CustomerID है। आदेश तालिका में एक CustomerID हो सकता है जो ग्राहक तालिका में नहीं है। हमें इस तरह की अखंडता के उल्लंघन को उजागर करने के लिए परीक्षण करने की आवश्यकता है। डेटा मैपिंग टेबल आपको स्पष्टता देगी कि इन बाधाओं का क्या तालमेल है।

ध्यान दें: इस परीक्षण को लक्ष्य प्रणाली में चलाएं और स्रोत प्रणाली में दोष होने पर बैकचेक करें।

# 6) डेटा पूर्णता

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

दो प्रकार के परीक्षण हैं:

(i) रिकॉर्ड गणना: यहां, हम स्रोत और लक्ष्य प्रणाली के बीच मिलान तालिकाओं के लिए रिकॉर्ड की कुल गणना की तुलना करते हैं। ईटीएल या माइग्रेशन जॉब के पोस्ट को सत्यापित करने के लिए यह क्विक सैनिटिटी चेक है। हमारे पास एक दोष है अगर गिनती मेल नहीं खाती है।

कई बार नौकरी चलाने के दौरान अस्वीकृत रिकॉर्ड होते हैं। इनमें से कुछ मान्य हो सकते हैं। लेकिन एक परीक्षक के रूप में, हम इसके लिए एक केस पॉइंट बनाते हैं।

(ii) कॉलम डेटा प्रोफाइलिंग: इस प्रकार की पवित्रता परीक्षण मूल्यवान है जब रिकॉर्ड मायने रखता है विशाल। यहां, हम डेटा के तार्किक सेट बनाते हैं जो रिकॉर्ड संख्या को कम करते हैं और फिर स्रोत और लक्ष्य के बीच तुलना करते हैं।

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

समयसीमा

# 7) डेटा परिवर्तन

ये परीक्षण परियोजना के मुख्य परीक्षण बनाते हैं। परिवर्तन आवश्यकताओं को समझने के लिए आवश्यकताओं के दस्तावेज़ की समीक्षा करें। विभिन्न परिवर्तन परिदृश्यों को प्रतिबिंबित करने के लिए स्रोत प्रणालियों में परीक्षण डेटा तैयार करें। इन परीक्षणों की एक भीड़ है और ईटीएल परीक्षण विषयों के तहत विस्तार से कवर किया जाना चाहिए।

नीचे दिए गए परीक्षणों की संक्षिप्त सूची इस प्रकार है:

(i) परिवर्तन:

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

(ii) एज मामले: सत्यापित करें कि परिवर्तन तर्क सीमाओं पर अच्छा है।

  • उदाहरण: क्या होता है जब कुल 1 ट्रिलियन के मान के साथ ईटीएल नौकरी के माध्यम से चलाया जाता है? क्या मामलों को समाप्त करने के लिए अंत काम करता है? उन क्षेत्रों की पहचान करें जिनमें संभवतः बड़े मूल्य हो सकते हैं और इन बड़े मूल्यों के साथ परीक्षण चला सकते हैं। उन्हें संख्यात्मक और गैर-संख्यात्मक मान शामिल करना चाहिए।
  • दिनांक फ़ील्ड के लिए, अपेक्षित तिथियों की पूरी श्रृंखला सहित - लीप वर्ष, फरवरी के लिए 28/29 दिन। अन्य महीनों के लिए 30, 31 दिन।

# 8) डेटा विशिष्टता या दोहराव

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

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

# 9) अनिवार्य

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

  • उदाहरण: यदि BillDate प्रविष्ट नहीं है, तो CurrentDate BillDate है।

# 10) समयबद्धता

हमेशा दस्तावेज़ परीक्षण जो यह सत्यापित करते हैं कि आप सहमत-समयावधि के डेटा के साथ काम कर रहे हैं।

  • उदाहरण: ProductDiscount को 15 दिन पहले और व्यावसायिक डोमेन को अपडेट किया गया था ProductDiscount हर सात दिनों में बदलता है। इसका मतलब है कि आपके परीक्षण सही छूट मूल्यों के साथ नहीं किए जा रहे हैं।
  • ग्राहक संतुष्टि सूचकांक के लिए एक भविष्य कहनेवाला विश्लेषण पिछले 1-सप्ताह के डेटा के साथ काम करने वाला था, जो वॉलमार्ट में बिक्री का प्रचार सप्ताह था। लेकिन ETL जॉब को 15 दिनों की आवृत्ति पर चलाने के लिए डिज़ाइन किया गया था। यह एक प्रमुख दोष है जिसे परीक्षक उजागर कर सकते हैं।

# 11) अशक्त डेटा

इस प्रकार के परीक्षण में, हम अशक्त डेटा और सत्यापन की वैधता पर ध्यान केंद्रित करते हैं कि महत्वपूर्ण स्तंभ शून्य नहीं हो सकता है।

  • उदाहरण: सभी अशक्त डेटा को फ़िल्टर करें और यदि शून्य अनुमति दी गई है, तो मान्य करें।
  • यदि व्यावसायिक निर्णयों के लिए महत्वपूर्ण स्तंभ हैं, तो सुनिश्चित करें कि नल मौजूद नहीं हैं।

# 12) रेंज जाँच

डेटा इकाई जहां पर्वतमाला व्यापार की समझ बनाती है उसका परीक्षण किया जाना चाहिए।

  • उदाहरण: सॉफ़्टवेयर श्रेणी में प्रति चालान आदेश मात्रा 5K से अधिक नहीं हो सकती है।
  • आयु 120 से अधिक नहीं होनी चाहिए।

# 13) व्यावसायिक नियम

फ़ील्ड के लिए किसी भी व्यावसायिक आवश्यकताओं को दस्तावेज़ित करें और उसी के लिए परीक्षण चलाएं।

  • उदाहरण: 20 वर्ष से कम आयु वाले संसाधन पात्र नहीं हैं। यदि यह नियम डेटा पर लागू होता है, तो डेटा सत्यापन जांच आवश्यक है।
  • यदि कर्मचारी सक्रिय स्थिति सत्य / अस्वीकृत है, तो समाप्ति की तारीख शून्य होनी चाहिए।
  • TO डेट से कम डेटा होना चाहिए।
  • आइटम-स्तर की खरीद मात्रा को ऑर्डर-स्तर की राशि के लिए योग करें

# 14) अलग कार्य

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

अक्सर स्रोत प्रणाली पर उपकरण लक्ष्य प्रणाली से अलग होते हैं। जांचें कि क्या दोनों उपकरण एक ही तरीके से कुल कार्यों को निष्पादित करते हैं।

# 15) डेटा ट्रंकेशन और राउंडिंग

इस प्रकार के परीक्षणों में, हम व्यापार से संबंधित ट्रंकेशन और राउंडिंग लॉजिक वाले क्षेत्रों की पहचान करते हैं। तब हम दस्तावेज़ बनाते हैं और उत्पाद मालिकों के साथ छंटनी और गोल तर्क पर साइनऑफ़ प्राप्त करते हैं और उत्पादन प्रतिनिधि डेटा के साथ उनका परीक्षण करते हैं।

# 16) टेस्ट को एनकोड करना

यदि स्रोत सिस्टम में एन्कोडेड मान हैं, तो सत्यापित करें और सत्यापित करें कि डेटा सही रूप से लक्षित प्रणाली में ETL या डेटा माइग्रेशन जॉब पोस्ट है।

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

# 17) प्रतिगमन टेस्ट

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

निष्कर्ष

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

संस्करणों में डेल्टा परिवर्तनों को बनाए रखने के लिए देखभाल की जानी चाहिए।

हम पाठकों से अनुरोध करते हैं कि वे परीक्षण के अन्य क्षेत्रों को साझा करें कि वे परीक्षक समुदाय को लाभ पहुंचाने के लिए अपने काम के दौरान आए हैं।

अनुशंसित पाठ

^