टेस्टिंग के लिए बड़ा सिंथेटिक डेटासेट कैसे बनाया जाता है?
तीन फ़ैसलों से: आकार (फ़ील्ड, उनके टाइप और फ़ॉर्मेट — JSON, CSV, SQL, XML), आयतन (पेजिनेशन, इंडेक्स और इम्पोर्ट सीमाओं को परखने लायक पंक्तियाँ) और विविधता (बाउंड्री वैल्यू, नल, डुप्लिकेट, विशेष कैरेक्टर और वह इक्का-दुक्का विकृत पंक्ति जो असली एक्सपोर्ट में होती है)। स्थिर रैंडम सीड सेट को दोहराने योग्य बनाता है, ताकि फ़ेल टेस्ट उन्हीं पंक्तियों पर फिर चले। बड़े आयतन पर फ़ॉर्मेट के नियम मायने रखते हैं: कॉमा, कोट या लाइन-ब्रेक वाले CSV फ़ील्ड RFC 4180 के अनुसार कोट होने चाहिए, और एक विशाल JSON दस्तावेज़ उन्हीं पंक्तियों के JSON Lines रूप से बहुत अलग व्यवहार करता है।
गाइड पढ़ें: परफ़ॉर्मेंस टेस्टिंग क्या है?
API टेस्ट डेटा जेनरेटर कैसे इस्तेमाल करें
- इनपुट क्षेत्र में फ़ील्ड बताएँ (या JSON Schema / OpenAPI स्कीमा पेस्ट करें)।
- तय करें कि कितनी मान्य पंक्तियाँ चाहिए, आउटपुट फ़ॉर्मैट क्या हो, और boundary तथा अमान्य वेरिएंट शामिल करने हैं या नहीं।
- चाहें तो seed सेट करें ताकि हर बार वही डेटासेट बने।
- बनाएँ, प्रीव्यू और वेरिएंट तालिकाएँ देखें, फिर अपने टेस्ट runner के लिए फ़ाइलें कॉपी या डाउनलोड करें।
API टेस्ट डेटा जेनरेटर की खूबियाँ
- हर लाइन में एक फ़ील्ड वाले DSL (type, required, min/max, लंबाई, enum, pattern) में रिक्वेस्ट फ़ील्ड बताएँ, या JSON Schema, नमूना ऑब्जेक्ट या OpenAPI डॉक्युमेंट पेस्ट करें
- यथार्थवादी सिंथेटिक वैल्यू (example.com पर ईमेल, तारीख़ें, UUID, फ़ोन पैटर्न) के साथ 1,000 तक मान्य पंक्तियाँ बनाता है — seed से दोहराई जा सकती हैं
- अपेक्षित नतीजे के लेबल वाले boundary वेरिएंट: हर संख्यात्मक minimum और maximum, उसके एक क़दम अंदर और एक क़दम बाहर की वैल्यू के साथ; हर लंबाई और maxItems सीमा, उससे एक ज़्यादा के साथ; minItems − 1; और बिना सीमा वाले फ़ील्ड के लिए शून्य/ऋणात्मक/बहुत बड़ी या ख़ाली/सिर्फ़ स्पेस/Unicode वैल्यू
- अमान्य वेरिएंट: ज़रूरी फ़ील्ड ग़ायब, ग़लत type, ख़राब format, रेंज से बाहर की वैल्यू, अमान्य enum सदस्य, null और अतिरिक्त फ़ील्ड
- मान्य पंक्तियाँ JSON, JSON Lines या CSV में एक्सपोर्ट; सभी वेरिएंट डेटा-चालित runner के लिए एक साथ JSON में एक्सपोर्ट
- पूरी तरह ब्राउज़र में चलता है; कुछ भी अपलोड नहीं होता
API टेस्ट डेटा जेनरेटर का उदाहरण
साइन-अप डेटासेट
इनपुट:
email: email required
age: integer min=18 max=99
plan: enum(free|pro) requiredआउटपुट:
{"email":"harper.reed@example.com","age":31,"plan":"pro"} ← valid row
age = 17 → expected 4xx (minimum − 1 step)
missing "email" → expected 4xx (missing-required)API टेस्ट डेटा जेनरेटर के बारे में अक्सर पूछे जाने वाले सवाल
यह पेलोड जेनरेटर से कैसे अलग है?
यह डेटासेट पर केंद्रित है: फ़ील्ड सूची या स्कीमा से डेटा-चालित टेस्ट के लिए कई पंक्तियाँ, boundary और अमान्य वेरिएंट सहित।
क्या यह डेटा असली है?
नहीं — सब कुछ सिंथेटिक टेस्ट डेटा है जो कभी असली लोगों की नक़ल नहीं करता। ईमेल में आरक्षित example.* डोमेन इस्तेमाल होते हैं और पहचानकर्ता random होते हैं।
क्या मैं आउटपुट फ़ॉर्मैट चुन सकता हूँ?
हाँ, मान्य पंक्तियों के लिए JSON, JSON Lines और CSV सपोर्ट किए जाते हैं; वेरिएंट तालिकाओं के रूप में दिखते हैं और एक साथ JSON में एक्सपोर्ट होते हैं।
फ़ील्ड कैसे बताऊँ?
हर लाइन में एक: "email: email required", "age: integer min=18 max=99", "plan: enum(free|pro) required", "tags: array maxItems=5"। इसके बजाय आप JSON Schema, नमूना ऑब्जेक्ट या OpenAPI डॉक्युमेंट भी पेस्ट कर सकते हैं।
boundary वेरिएंट क्या होते हैं?
किसी मान्य पेलोड की ऐसी प्रतियाँ जिनमें सिर्फ़ एक फ़ील्ड बदला जाता है, और हर प्रति पर अपेक्षित API नतीजे का लेबल होता है। जिस संख्या की minimum और maximum दोनों सीमाएँ हों, उसे छह पंक्तियाँ मिलती हैं: हर सीमा, उसके एक क़दम अंदर की वैल्यू (स्वीकार होनी चाहिए) और एक क़दम बाहर की वैल्यू (अस्वीकार होनी चाहिए); integer के लिए क़दम 1 है, वरना multipleOf या 0.01। maxLength और maxItems को सीमा और उससे एक ज़्यादा, minLength को सीमा और उससे एक कम, और minItems को उससे एक कम वैल्यू मिलती है। बिना सीमा वाली संख्याओं को शून्य, ऋणात्मक और बहुत बड़ी वैल्यू, और साधारण string को ख़ाली, सिर्फ़ स्पेस वाली और Unicode वैल्यू मिलती है।
तकनीकी नोट्स
फ़ील्ड सूची को एक JSON Schema में बदला जाता है (type, format, minimum/maximum, minLength/maxLength, enum, pattern, items) और उसी पेलोड engine को दिया जाता है जो API पेलोड जेनरेटर इस्तेमाल करता है; boundary पंक्तियाँ उसी स्कीमा की संख्यात्मक, लंबाई और array संबंधी बाध्यताओं से निकाली जाती हैं।
संदर्भ
- RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) FilesCSV के आम नियम: कॉमा सेपरेटर, CRLF लाइन एंड, और कॉमा, कोट या लाइन ब्रेक वाले फ़ील्ड की क्वोटिंग।
- RFC 8259: The JavaScript Object Notation (JSON) Data Interchange FormatJSON का व्याकरण: ऑब्जेक्ट, ऐरे, स्ट्रिंग, नंबर, तीन लिटरल और इंटरचेंज एन्कोडिंग के रूप में UTF-8।
- JSON LinesJSON Lines परिपाटी: हर लाइन पर एक पूरा JSON वैल्यू, UTF-8, "\n" सेपरेटर, .jsonl एक्सटेंशन।
- Personal Data Protection Law (English translation)व्यक्तिगत डेटा पर सऊदी कानून — टेस्ट वातावरण में असली ग्राहक रिकॉर्ड की प्रतियों के बजाय सिंथेटिक डेटा क्यों इस्तेमाल करना चाहिए।