सेलेनियम बनाम प्लेव्राइट बनाम पुपपीटर: पूर्ण तुलना

सेलेनियम बनाम प्लेव्राइट बनाम पुपपीटर

स्क्रेपलेस एजेंट ब्राउज़र प्रबंधित ब्राउज़र सत्रों को प्रकट करता है जो आधुनिक स्वचालन ढांचों के साथ काम करते हैं, इसलिए टीमें सेलेनियम बनाम प्लेव्राइट बनाम पुपपीटर की तुलना कर सकती हैं और पुस्तकालय के चयन को ब्राउज़र अवसंरचना से अलग कर सकती हैं।

TL;DR

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

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

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

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

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

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

सेलेनियम बनाम प्लेव्राइट बनाम पुपपीटर एक नज़र में

नीचे दी गई मैट्रिक्स वर्तमान आधिकारिक क्षमता सीमाओं और रोज़मर्रा के इंजीनियरिंग परिणामों पर ध्यान केंद्रित करती है।

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

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

टेबल को सार्वभौमिक स्कोर में न बदलें। प्रत्येक पंक्ति को उन भाषाओं, ब्राउज़रों, सीआई वातावरण, परीक्षण संपत्तियों, और निष्कर्षण कार्यभार के खिलाफ वजन करें जो टीम पहले से ही सेलेनियम बनाम प्लेव्राइट बनाम पुपपीटर के संदर्भ में रखती है।

संरचना, प्रतीक्षा, और ब्राउज़र नियंत्रण

ब्राउज़र स्वचालन की विश्वसनीयता इस पर निर्भर करती है कि क्लाइंट ब्राउज़र के साथ कैसे संवाद करता है और यह कैसे तय करता है कि एक तत्व या पृष्ठ स्थिति किस संदर्भ में तैयार है, Selenium बनाम Playwright बनाम Puppeteer के संदर्भ में।

लोकेटर-आधारित APIs क्रियान्वयन के समय तत्वों को हल कर सकते हैं और कार्रवाई की स्थिति की जांच कर सकते हैं, जबकि WebDriver पारिस्थितिकी प्रणाली विक्रेता कार्यान्वयनों के संदर्भ में मानकीकृत ब्राउज़र नियंत्रण को उजागर करती है, Selenium बनाम Playwright बनाम Puppeteer के संदर्भ में। प्रोटोकॉल विवरण डिबगिंग और संगतता को प्रभावित करता है, लेकिन आवेदन स्तर पर निष्पादन अभी भी तय करता है कि क्या इच्छित स्थिति हासिल की गई थी, Selenium बनाम Playwright बनाम Puppeteer के संदर्भ में।

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

कौन सा फ्रेमवर्क किस टीम के अनुकूल है?

एक निर्णय गाइड को उस वातावरण का नाम देना चाहिए जो प्रत्येक विकल्प को समझदारी बनाता है।

Selenium चुनें

मानक-आधारित ब्राउज़र कवरेज, व्यापक भाषा आवश्यकताएँ, और मौजूदा ग्रिड निवेश निर्णय की दिशा में ले जाते हैं।

Playwright चुनें

एक नई टीम एकीकृत परीक्षण, लोकेटर, ट्रेस, और बार-बार चलने वाले क्रॉस-इंजन APIs चाहती है।

Puppeteer चुनें

एक Node सेवा को बिना बड़े परीक्षण ढांचे के एक केंद्रित Chrome या Firefox स्वचालन पुस्तकालय की आवश्यकता है।

अलग होस्टिंग

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

उपरोक्त मामले प्रारंभिक बिंदु हैं, स्थायी लेबल नहीं। डेटा स्रोत, ब्राउज़र मैट्रिक्स, मॉडल व्यवहार, अनुपालन सीमा, या टीम स्वामित्व बदलने पर Selenium बनाम Playwright बनाम Puppeteer का पुनर्मूल्यांकन करें। एक प्रोटोटाइप अक्सर सेटअप गति को अनुकूलित करता है, जबकि एक उत्पादन प्रणाली को सबूत, पहुंच नियंत्रण, पूर्वानुमानित विफलता, और समर्थन योग्यता के लिए अनुकूलित करना चाहिए, Selenium बनाम Playwright बनाम Puppeteer के संदर्भ में। चयन को संक्षिप्त निर्णय रिकॉर्ड में कैद करें ताकि अग migration प्राचीन बंधन पर आधारित हो rather than लोककथा, Selenium बनाम Playwright बनाम Puppeteer के संदर्भ में।

स्थानांतरण लागत में सहायक पुस्तकालय, फ़िक्स्चर, रिपोर्टिंग, ग्रिड कॉन्फ़िगरेशन, टीम ज्ञान, और डिबगिंग आदतें शामिल हैं—केवल Selenium बनाम Playwright बनाम Puppeteer के संदर्भ में फिर से लिखे गए API कॉल नहीं। एक प्रतिनिधि सूट को बनाए रखें और सबूत की तुलना करें, प्रदर्शन की लंबाई नहीं।

तुलनात्मक जाल और स्थानांतरण जोखिम

फ्रेमवर्क की तुलना भ्रामक हो जाती है जब वे पुराने क्षमता अनुमानों का उपयोग करते हैं या Selenium बनाम Playwright बनाम Puppeteer के संदर्भ में पुस्तकालय और होस्टिंग समस्याओं को मिलाते हैं।

  • एक लोकप्रियता रैंकिंग का उपयोग करना। टीम की बाधाएं और मौजूदा संपत्तियाँ फिट को निर्धारित करती हैं।
  • पुराने ब्राउज़र समर्थन की तुलना करना। Puppeteer और Selenium क्षमताओं में बदलाव होते हैं; वर्तमान आधिकारिक तालिकाओं का उपयोग करें।
  • सभी प्रतीक्षा को समान मानते हुए। API कॉल की संख्या के बजाय उपयोगकर्ता-दृश्यमान तत्परता को मापें।
  • गैर-परीक्षण कार्यभार की अनदेखी करना। PDF, स्क्रीनशॉट, स्क्रैपिंग, एक्सटेंशन, और प्रोटोकॉल निरीक्षण सुविधाओं को अलग तरीके से तौलते हैं।
  • यह मान लेना कि एक पुस्तकालय संचालन शामिल करता है। क्यू, ब्राउज़र क्षमता, प्रॉक्सियां, सत्र, और निगरानी अलग प्रणालियां हैं।

प्रत्येक Selenium बनाम Playwright बनाम Puppeteer का जाल एक अवलोकनीय जांच से मेल खाना चाहिए। अंतिम पृष्ठ या स्रोत पहचान को मान्य करें, आवश्यक फ़ील्ड की जाँच करें, स्थिति कोड पर भरोसा करने के बजाय, तैयार परिणाम उत्पन्न करने के लिए सटीक कॉन्फ़िगरेशन को बनाए रखें, और Selenium बनाम Playwright बनाम Puppeteer के संदर्भ में अधिग्रहण को रूपांतरण से अलग रखें। यह उपकरणों के बारे में एक तर्क को एक विफल अनुबंध के बारे में निदान में बदलता है। यह व्यापक परिवर्तनों को पहले टूटे हुए सीमा को छिपाने से भी रोकता है।

सुरक्षा और अनुपालन को Selenium बनाम Playwright बनाम Puppeteer डिज़ाइन के भीतर बनाए रखें। अधिकृत सार्वजनिक स्रोतों का उपयोग करें, लागू शर्तों और क्रॉलर की प्राथमिकताओं का सम्मान करें, रखे गए डेटा को न्यूनतम करें, और लॉग और सामग्री के बाहर क्रेडेंशियल्स को बनाए रखें, Selenium बनाम Playwright बनाम Puppeteer के संदर्भ में। एक तकनीकी रूप से सक्षम ब्राउज़र, स्क्रैपर, एजेंट, या API क्लाइंट अनुमति नहीं देता है। ऑपरेटर लक्षित दायरे, डेटा हैंडलिंग, कार्यभार सीमाएँ, और महत्वपूर्ण कार्यों के लिए मानव स्वीकृति के लिए जिम्मेदार होता है, Selenium बनाम Playwright बनाम Puppeteer के संदर्भ में।

एक निष्पक्ष अवधारणा प्रमाण चलाएं

प्रत्येक उम्मीदवार का मूल्यांकन समान छोटे कार्यक्षेत्रों और स्वीकृति जांच के खिलाफ करें।

  1. आधिकारिक समर्थन तालिकाओं से वर्तमान फ्रेमवर्क और ब्राउज़र संस्करण पिन करें।
  2. लॉगिन-मुक्त नेविगेशन, गतिशील सामग्री, एक नया टैब, एक डाउनलोड, और प्रासंगिक रूप से विफल नियंत्रण लागू करें, Selenium बनाम Playwright बनाम Puppeteer के संदर्भ में।
  3. समान उपयोगकर्ता-फेसिंग लोकेटर और तत्परता की शर्तें का उपयोग करें।
  4. ट्रेस, स्क्रीनशॉट, कंसोल आउटपुट, नेटवर्क सबूत, और अंतिम सत्यापन कैद करें।
  5. स्थानीय रूप से और इच्छित CI या दूरस्थ-ब्राउज़र वातावरण में चलाएं।
  6. देखभाल, ब्राउज़र कवरेज, रनटाइम सबूत, और स्थानांतरण प्रयास को अलग से स्कोर करें।

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

एक प्रमाण अवधारणा को गलत पृष्ठ पर स्पष्ट रूप से विफल होना चाहिए। यदि प्रत्येक उपकरण जानबूझकर अमान्य चयनकर्ता या पृष्ठ मार्कर के खिलाफ सफलता की रिपोर्ट करता है, तो परीक्षण हार्नेस स्क्रिप्ट पूर्णता को माप रहा है, न कि Selenium बनाम Playwright बनाम Puppeteer के संदर्भ में सहीता।

पूरी ऑटोमेशन अनुबंध को मापें

निष्पादन गति उपयोगी है, लेकिन स्थिर साक्ष्य और बनाए रखने की क्षमता आमतौर पर Selenium बनाम Playwright बनाम Puppeteer के संदर्भ में दीर्घकालिक ब्राउज़र परियोजनाओं का निर्णय लेते हैं।

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

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

प्राथमिक सन्दर्भ तुलना को संलग्न करते हैं: Selenium WebDriver दस्तावेज़, Playwright ऑटो-इंतज़ार दस्तावेज़, और Puppeteer आधिकारिक एफएक्यू।. ये स्रोत तकनीकों को परिभाषित करते हैं; ये तुलना पृष्ठों के बीच की गई विशेषताओं की तालिकाओं की तुलना में अधिक मजबूत साक्ष्य हैं। संस्करण-विशिष्ट विवरणों की फिर से जांच की जानी चाहिए जब कार्यान्वयन उन्नत हो।

उस पारिस्थितिकी तंत्र को चुनें जो बाधा से मेल खाती है

Selenium बनाम Playwright बनाम Puppeteer के लिए, आवश्यक ब्राउज़र कवरेज, भाषा, निदान, और मौजूदा संपत्तियों में से चुनें, फिर प्रतिनिधि कार्यप्रवाहों पर चयन को प्रमाणित करें। बुनियादी ढांचे और डेटा स्वीकृति को अलग अनुबंध के रूप में बनाए रखें।

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

क्या आप दूरस्थ रूप से ब्राउज़र स्वचालन चलाने के लिए तैयार हैं?

अपने चुने हुए ढांचे को एजेंट ब्राउज़र से कनेक्ट करें और अपने अनुप्रयोग स्तर के दावे बनाए रखें।

आज साइन अप करें और पाएं $5 मुफ्त क्रेडिटकोई क्रेडिट कार्ड आवश्यक नहीं.

अपने $5 क्रेडिट का दावा करें →

एफएक्यू

कौन सा ब्राउज़र स्वचालन ढांचा सबसे तेज है?

कोई स्थायी सार्वभौमिक विजेता नहीं है। ब्राउज़र संस्करण, पृष्ठ व्यवहार, इंतज़ार, प्रक्रिया मॉडल, CI संसाधन, और कार्यभार सरल बेंचमार्क परिणामों को प्रभावित करते हैं।

क्या ये ढांचे बॉट पहचान को रोकते हैं?

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

क्या कोई टीम दूरस्थ ब्राउज़र का उपयोग कर सकती है?

हाँ। समर्थित दूरस्थ कनेक्शन विधियाँ क्लाइंट लाइब्रेरी को कहीं और चल रहे ब्राउज़र को नियंत्रित करने की अनुमति देती हैं।

क्या मौजूदा सूट को फिर से लिखा जाना चाहिए?

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

क्या ढांचे के परीक्षण स्क्रैपिंग मान्यता के लिए पर्याप्त हैं?

नहीं। स्क्रैपिंग के लिए अंतिम URL, पृष्ठ पहचान, चयनकर्ता गिनती, फील्ड कवरेज, स्कीमा चेक, और स्वीकार किए गए रिकॉर्डों के लिए साक्ष्य की भी आवश्यकता होती है।

सन्दर्भ