QA इंजीनियरों के लिए डेटाबेस टेस्टिंग

डेटाबेस टेस्टिंग क्या कवर करती है

डेटाबेस तक पहुँचने वाले ज़्यादातर defects इंटरफ़ेस पर दिखते ही नहीं। ऑर्डर कन्फ़र्मेशन पेज बिलकुल सही दिख सकता है जबकि order row में गलत total हो, कोई payment गलत ऑर्डर से जुड़ा हो, या रद्द ऑर्डर के items अब भी reserved हों। यूज़र इन defects से बाद में मिलते हैं — मासिक स्टेटमेंट में, फ़ेल होते refund में, ऐसी रिपोर्ट में जिसके आँकड़े नहीं मिलते — जब इन्हें ढूँढना महँगा हो चुका होता है।

डेटाबेस टेस्टिंग कोई अलग test level नहीं है। यह जाँचों का एक सेट है जो integration, system और acceptance levels पर वहाँ लगाया जाता है जहाँ डेटा बनता या बदलता है। इसका oracle खुद डेटा मॉडल है: schema, उसके constraints, एक टेबल को दूसरी से जोड़ने वाले business rules, और वे आँकड़े जिन्हें मेल खाना चाहिए।

• Structural (schema) testing — टेबल, कॉलम, types, lengths, defaults, constraints और indexes डिज़ाइन और migration scripts से मेल खाते हैं।
• Functional data testing — UI या API जो भी create, read, update और delete करता है, वह ठीक वही rows छोड़ता है जो उसे छोड़नी चाहिए।
• Integrity testing — keys, uniqueness, NOT NULL, CHECK और foreign key नियम खराब डेटा को रोकते हैं, और जुड़े records सुसंगत रहते हैं।
• Logic testing — stored procedures, triggers, views और scheduled jobs सामान्य, boundary और error inputs पर सही नतीजे देते हैं।
• Transaction और concurrency testing — सब-या-कुछ-नहीं व्यवहार, और जब दो यूज़र एक ही डेटा एक साथ बदलें तब सही नतीजे (transactions और migrations पेज पर विस्तार से)।
• Migration testing — schema और data बदलाव वास्तविक वॉल्यूम पर सही चलते हैं और चल रहे ऐप्लिकेशन को काम करता रखते हैं।
• Non-functional testing — बड़ी टेबलों पर query performance, access control और personal data की सुरक्षा।

CRUD validation: प्रोडक्ट से करें, डेटाबेस में पुष्टि करें

मूल तकनीक सरल है: action वैसे ही करें जैसे यूज़र या क्लाइंट करता — UI या API से — फिर असर की पुष्टि के लिए डेटाबेस query करें। सीधे rows insert करके उसे फ़ीचर का टेस्ट कहना उसी ऐप्लिकेशन कोड को छोड़ देता है जिसे आपको टेस्ट करना है। सीधे inserts preconditions तैयार करने के लिए हैं, व्यवहार चलाने के लिए नहीं।

हर operation में target row और उसके आस-पास की rows जाँचें। Create को एक row लिखनी चाहिए जिसमें हर फ़ील्ड सही map हो, server-generated values (ids, timestamps, status) सेट हों और child rows बनी हों। Update को सिर्फ़ इच्छित कॉलम बदलने चाहिए और updated_at आगे बढ़ाना चाहिए। Delete को ठीक वही हटाना या soft-delete करना चाहिए जो requirement कहती है और child rows से डिज़ाइन के अनुसार निपटना चाहिए। Read को जो स्टोर है वही लौटाना चाहिए — अरबी टेक्स्ट, इमोजी, अधिकतम lengths और दशमलव सहित — बिना truncation या दोबारा rounding के।

उदाहरण के लिए, API से ऐसा ऑर्डर बनाने के बाद जिसमें 75.00 SAR वाले item की दो यूनिट और 40.00 SAR वाले item की एक यूनिट हो, इस section के अंत में दी गई query order row, item rows और server द्वारा सेट values की पुष्टि करती है। इस तरह की जाँच से पकड़े जाने वाले आम CRUD defects:

• Field mapping — API delivery_notes स्वीकार करती है, पर कॉलम NULL ही रहता है।
• Precision — 19.995 की राशि एक टेबल में 19.99 और दूसरी में 20.00 स्टोर होती है।
• Encoding — अरबी नाम “????” के रूप में सेव होते हैं क्योंकि कोई कॉलम या कनेक्शन non-Unicode character set इस्तेमाल करता है।
• Time zones — एक सर्विस created_at लोकल टाइम में और दूसरी UTC में स्टोर करती है।
• Partial writes — तीसरे item पर validation error के बाद order row मौजूद है पर उसके items नहीं।

-- After POST /api/orders returned order_id 1042 for customer 317
SELECT order_id, customer_id, status, total_amount, created_at, updated_at
FROM orders
WHERE order_id = 1042;

SELECT product_sku, quantity, unit_price
FROM order_items
WHERE order_id = 1042
ORDER BY order_item_id;

-- Expected: customer_id = 317, status = 'PENDING',
-- total_amount = 2 x 75.00 + 1 x 40.00 = 190.00,
-- exactly two item rows, created_at set by the server (UTC)

आज़माएँ: SQL फ़ॉर्मेटर आज़माएँ: SQL क्वेरी वैलिडेटर

Constraints: डेटाबेस जो नियम लागू करता है

Constraints डेटाबेस की आख़िरी रक्षा पंक्ति हैं: ऐप्लिकेशन validation में bug हो तब भी अच्छा schema मॉडल तोड़ने वाले डेटा को मना कर देता है। इन्हें टेस्ट करने के दो पहलू हैं। पहला, पुष्टि करें कि constraint मौजूद है — schema या migration पढ़ें, सिर्फ़ डिज़ाइन डॉक्युमेंट नहीं। दूसरा, पुष्टि करें कि ऐप्लिकेशन rejection को ठीक से संभालता है: साफ़ validation message या 4xx API response, न कि raw database error वाला 500।

Engines अलग होते हैं, इसलिए जिस पर आप ship करते हैं उसे जाँचें। MySQL CHECK constraints केवल 8.0.16 वर्ज़न से लागू करता है (पुराने वर्ज़न उन्हें parse करके अनदेखा करते थे), और SQLite foreign keys तभी लागू करता है जब कनेक्शन PRAGMA foreign_keys = ON से उन्हें चालू करे। जो constraint migration फ़ाइल में है पर runtime पर लागू नहीं होता, वह एक finding है।

• Primary key — हर row की अनूठी पहचान है। दोबारा भेजे गए request को उसी business event के लिए नए id वाली दूसरी row नहीं बनानी चाहिए; यह idempotency की समस्या है जिसे key अकेले हल नहीं करती।
• UNIQUE — एक ही ईमेल दो बार रजिस्टर करें, अलग letter case और आगे-पीछे spaces के साथ भी। टीम से तय करें कि Layla.H@example.com और layla.h@example.com एक ही ग्राहक हैं या नहीं, फिर जाँचें कि डेटाबेस भी यही मानता है।
• NOT NULL — फ़ील्ड को गायब, खाली और सिर्फ़ spaces के साथ भेजें। PostgreSQL और MySQL में खाली string NULL नहीं है, इसलिए NOT NULL अकेले खाली नाम नहीं रोकता।
• CHECK — quantity शून्य से ज़्यादा, राशियाँ ऋणात्मक नहीं, status अनुमत सेट में। Boundaries (0, 1, अधिकतम) और उनसे एक क़दम बाहर टेस्ट करें।
• FOREIGN KEY — ऐसे customer id के लिए ऑर्डर बनाएँ जो मौजूद नहीं है। Insert फ़ेल होना चाहिए और API को अर्थपूर्ण error लौटाना चाहिए।
• Defaults, types और lengths — छोड़े गए फ़ील्ड को documented default मिलता है, और हर कॉलम सबसे लंबा valid input संभालता है। जिस फ़ील्ड में UI 100 characters देता है उसके पीछे 50-character कॉलम truncation bug है जो होने का इंतज़ार कर रहा है।

आज़माएँ: बाउंड्री नंबर डेटासेट जनरेटर आज़माएँ: स्पेशल कैरेक्टर डेटासेट जनरेटर आज़माएँ: Unicode डेटासेट जनरेटर

Relationships, referential integrity और cascades

Referential integrity का मतलब है हर reference किसी मौजूद चीज़ की ओर इशारा करे: हर order item किसी मौजूद ऑर्डर का हो, हर payment किसी मौजूद ऑर्डर का, हर ऑर्डर किसी मौजूद ग्राहक का। Foreign keys घोषित हों तो डेटाबेस इसे लागू करता है। न हों — जो microservices में, sharded या legacy schemas में और batch jobs से भरी टेबलों में आम है — तो ऐप्लिकेशन को लागू करना पड़ता है, और orphan rows टेस्टर को मिलने वाले सबसे आम data defects में से एक बन जाती हैं।

Cascade नियम तय करते हैं कि parent डिलीट होने या उसकी key बदलने पर child rows का क्या हो। ON DELETE CASCADE parent के साथ children हटा देता है; RESTRICT या NO ACTION children रहते delete मना कर देता है; SET NULL child रखता है और reference खाली कर देता है। हर एक किसी relationship के लिए सही और किसी दूसरे के लिए ख़तरनाक है: ग्राहक का delete invoices तक cascade करना ऐसे records मिटा सकता है जिन्हें रखना व्यवसाय के लिए ज़रूरी है। हर relationship को requirement के सामने टेस्ट करें, इस बात के सामने नहीं कि schema संयोग से क्या करता है।

• प्रोडक्ट से कोई parent डिलीट करें, फिर हर child टेबल में ऐसी rows खोजें जो अब भी उसे reference करती हैं।
• Soft deletes जाँचें: deleted चिह्नित ग्राहक सूचियों से गायब होना चाहिए, जबकि उसके पुराने ऑर्डर पढ़ने लायक रहने पड़ सकते हैं।
• Batch imports, data migrations और फ़ेल jobs के बाद orphan-detection queries चलाएँ — SQL पेज LEFT JOIN … IS NULL पैटर्न दिखाता है।

Stored procedures, triggers और back-end नियम

जब business logic डेटाबेस में रहता है — महीना बंद करने वाली stored procedure, audit row लिखने वाला trigger, रिपोर्ट को डेटा देने वाला view — तो उसे किसी भी कोड की तरह मानें: inputs और expected outputs तय करें, और equivalence partitioning व boundary values से cases चुनें। तैयार डेटा वाले test database में procedures को सीधे call करें, और उन्हें उस ऐप्लिकेशन path से भी चलाएँ जो उन्हें इस्तेमाल करता है।

Triggers पर ख़ास ध्यान चाहिए क्योंकि वे चुपचाप काम करते हैं। जाँचें कि वे हर उस path पर fire होते हैं जहाँ होने चाहिए (insert, update और delete; single-row और bulk statements), दो बार fire नहीं होते, और trigger के अंदर की failure उस statement को rollback करती है जिसने उसे चलाया, न कि आधा काम छोड़ देती है।

• Audit trigger — ऑर्डर का status बदलने पर ठीक एक audit row लिखी जाती है जिसमें पुरानी और नई value, action करने वाला यूज़र और server timestamp हो।
• Procedure boundaries — month-end procedure को leap year के फ़रवरी के लिए और ऐसे महीने के लिए चलाएँ जिसमें कोई ऑर्डर नहीं।
• Back-end validation — UI में लागू नियम API में भी लागू है, और जहाँ डिज़ाइन कहता है वहाँ डेटाबेस में भी। पुष्टि के लिए सीधे API call करके UI को bypass करें।

सर्विसों, cache और search index के बीच data consistency

आधुनिक सिस्टम डेटा की कॉपियाँ रखते हैं: read replica, cache, search index, reporting warehouse, किसी दूसरी microservice का अपना डेटाबेस। हर कॉपी source of truth से भटक सकती है। डेटाबेस में अपडेट हुई कीमत जो अब भी cache में पुरानी है, ऑर्डर सर्विस में दिखता ऑर्डर जो invoicing में नहीं है, डिलीट हुआ ग्राहक जो search में अब भी मिलता है — ये consistency defects हैं, और ये कॉपियों की तुलना से मिलते हैं।

तकनीक है reconciliation: एक ही आबादी को दो जगह गिनें और जोड़ें, फिर तुलना करें। status और दिन के हिसाब से counts, राशियों के sums, और ऐसे ids की सूचियाँ जो एक तरफ़ हैं दूसरी तरफ़ नहीं — इनसे ज़्यादातर भटकाव पकड़ में आता है। जहाँ replication asynchronous है, वहाँ टीम से स्वीकार्य देरी तय करें — eventual consistency डिज़ाइन का फ़ैसला है, defect नहीं — और टेस्ट करें कि कॉपियाँ उसी अवधि में मिल जाती हैं, failures, retries और replays के बाद भी।

• आज बने ऑर्डर: ऑर्डर डेटाबेस, invoicing सर्विस और finance रिपोर्ट में count और total।
• Search index: डेटाबेस का हर active product id index में है, और कोई deleted id बचा नहीं है।
• Cache invalidation: कोई record अपडेट करें, फिर उसे API से तुरंत और cache की अवधि के बाद पढ़ें; अगर डिज़ाइन कहता है कि writes cache invalidate करते हैं, तो दोनों reads नई value लौटाएँ।
• Event-driven flows: consumer रोकें, records बनाएँ, उसे फिर चालू करें, और पुष्टि करें कि कुछ खोया नहीं और कुछ दो बार लागू नहीं हुआ।

आज़माएँ: SQL IN क्लॉज़ जनरेटर आज़माएँ: SQL VALUES जनरेटर

Test data: सिंथेटिक, seeded और reset करने योग्य

डेटाबेस टेस्ट को ज्ञात डेटा चाहिए — ज्ञात ग्राहक, ज्ञात ऑर्डर, ज्ञात totals — ताकि टेस्ट चलने से पहले expected result लिखा जा सके। इसे सोच-समझकर बनाएँ: एक seed script baseline बनाती है, हर टेस्ट अपनी ज़रूरत का डेटा जोड़ता है और सफ़ाई करता है या ऐसे transaction में चलता है जिसे rollback किया जाता है, और पूरा डेटाबेस मिनटों में baseline पर reset हो सकता है।

Production का personal data टेस्ट environments में कॉपी न करें। सऊदी अरब का Personal Data Protection Law (PDPL), जिसकी निगरानी SDAIA करता है, personal data की processing को नियंत्रित करता है, और असली ग्राहकों के नाम, राष्ट्रीय ID, फ़ोन नंबर और पते वाला टेस्ट environment production से कमज़ोर नियंत्रणों में personal data की processing है। डिफ़ॉल्ट रूप से सिंथेटिक डेटा इस्तेमाल करें। अगर production जैसे डेटा की सचमुच ज़रूरत हो, उदाहरण के लिए migration rehearsal में, तो तरीका अपने data protection officer से तय करें: masked डेटा भी personal data रह सकता है अगर उसे किसी व्यक्ति से जोड़ा जा सके।

• Generated SQL से seed करें: वास्तविक baseline के लिए CREATE TABLE और INSERT scripts, migrations के साथ version control में रखी हुई।
• कठिन values जान-बूझकर शामिल करें: अधिकतम lengths, शून्य राशियाँ, अरबी और देवनागरी टेक्स्ट, इमोजी, नामों में apostrophe, महीने और साल के अंत की तारीख़ें।
• Reset strategy चुनें: हर टेस्ट के बाद rollback, हर suite के लिए truncate और re-seed, snapshot या template database से restore, या हर pipeline run के लिए नया containerised डेटाबेस।
• Performance और migration टेस्ट के लिए production जैसी row counts पर डेटा generate करें, दस rows पर नहीं।

आज़माएँ: SQL डेटासेट जनरेटर आज़माएँ: SQL INSERT जनरेटर आज़माएँ: CSV से SQL आज़माएँ: JSON से SQL

टेस्टर के स्तर पर performance: indexes, query plans और N+1

डेटाबेस के performance defects ढूँढने के लिए आपको उसे tune करने की ज़रूरत नहीं। आम कारण सीधा होता है: जो query 200 test rows पर तेज़ थी, वह production में लाखों rows scan करती है क्योंकि जिस कॉलम पर वह filter करती है उस पर index नहीं है। वास्तविक वॉल्यूम के साथ टेस्ट करें, डेटा बढ़ने के साथ response times देखें, और कुछ धीमा हो तो query plan माँगें।

EXPLAIN दिखाता है कि डेटाबेस query को कैसे चलाने वाला है — index इस्तेमाल करेगा या पूरी टेबल scan करेगा, और किस क्रम में joins करेगा। PostgreSQL और MySQL EXPLAIN और EXPLAIN ANALYZE देते हैं; SQLite EXPLAIN QUERY PLAN देता है। EXPLAIN ANALYZE statement को सचमुच execute करता है, इसलिए इसे UPDATE या DELETE पर कभी ऐसे transaction के बाहर न चलाएँ जिसे आप rollback करेंगे। Plan की हर लाइन पढ़ना ज़रूरी नहीं: जो query कुछ ही rows लौटानी चाहिए उसमें बड़ी टेबल का full scan bug report के लायक है।

• N+1 queries — list पेज एक query से 50 ऑर्डर लोड करता है, फिर हर ऑर्डर का ग्राहक लाने के लिए एक और query चलाता है: एक-दो की जगह 51 round trips। यह query log या APM trace में लगभग एक जैसे statements की बौछार के रूप में दिखता है।
• Deep pagination — OFFSET-आधारित paging बड़ी टेबलों के पिछले पेजों पर धीमी हो जाती है; पेज 1 और पेज 5,000 दोनों टेस्ट करें।
• Unbounded queries — बिना limit वाले exports और reports जो पूरी टेबल memory में लोड करते हैं।
• Foreign keys पर और अक्सर चलने वाली queries के WHERE, JOIN और ORDER BY में इस्तेमाल कॉलमों पर गायब indexes।

Security: injection, privileges और personal data

SQL injection तब होता है जब यूज़र input को SQL टेक्स्ट में जोड़ दिया जाता है। OWASP के अनुसार बचाव है हर जगह parameterised queries (prepared statements), और उन हिस्सों के लिए allow-list validation जो parameter नहीं बन सकते, जैसे sort कॉलम का नाम। टेस्टर के रूप में exploit लिखने के बजाय अपेक्षा की पुष्टि करें: हर input में quotes, semicolons, comment markers और दूसरे SQL metacharacters वाली values डालें और उम्मीद करें कि वे अक्षरशः स्टोर और प्रदर्शित हों, बिना database error, stack trace या व्यवहार में बदलाव के। किसी भी response में database error message अपने आप में एक finding है। गहरी injection testing अधिकृत security assessment का काम है।

Least privilege गड़बड़ी होने पर नुकसान सीमित करता है। ऐप्लिकेशन अकाउंट के पास केवल ज़रूरी अधिकार हों — आम तौर पर अपनी टेबलों पर read और write, schema बदलाव नहीं, admin rights नहीं — और migrations अलग अकाउंट से चलें। टेस्टर और reporting tools read-only अकाउंट इस्तेमाल करें।

• पता करें कि ऐप्लिकेशन किस अकाउंट से कनेक्ट होता है और उसे क्या करने की अनुमति है; database owner के रूप में चलता production ऐप्लिकेशन एक finding है।
• Personal data वहाँ खोजें जहाँ उसे नहीं होना चाहिए: ऐप्लिकेशन logs, error messages, analytics events, CSV exports, shared drives पर backups और test environments।
• जाँचें कि passwords किसी dedicated password-hashing algorithm (जैसे Argon2id, bcrypt, scrypt या PBKDF2, जो हर password को salt करते हैं) से स्टोर हैं, किसी सामान्य तेज़ hash से नहीं, और tokens व दूसरे secrets डिज़ाइन के अनुसार hashed या encrypted हैं, कभी plain text में नहीं।
• Audit columns — created_at, updated_at, created_by, updated_by — सर्वर सेट करता है और क्लाइंट से स्वीकार नहीं होते; updated_at और updated_by record बदलने पर हर बार बदलते हैं, जबकि created_at और created_by insert के बाद कभी नहीं बदलते।

आज़माएँ: स्पेशल कैरेक्टर डेटासेट जनरेटर

आम defects, automation और CI

डेटाबेस जाँचें अच्छी तरह automate होती हैं क्योंकि उनके expected results सटीक होते हैं। Integrity और reconciliation queries को API tests वाली suite में ही रखें: API call करें, डेटाबेस query करें, assert करें। Suite को pipeline में ताज़ा migrate और ताज़ा seed किए डेटाबेस पर चलाएँ, ताकि हर build साबित करे कि migrations साफ़ लागू होते हैं और data rules अब भी टिके हैं। Read-only integrity queries का छोटा सेट — orphans, duplicates, न मिलने वाले totals — हर deployment के बाद और तय समय पर staging पर चलाने के लिए रखें।

जब कोई जाँच फ़ेल हो, तो उसकी लौटाई rows ही सबूत हैं: query और उसका output bug report में लगाएँ। इस तरह मिले defects आम तौर पर ऐसे दिखते हैं:

• “आख़िरी item पर discount लगने पर order total item lines के योग से अलग”
• “ग्राहक डिलीट करने पर orphan payment rows बचती हैं (payments.order_id पर foreign key नहीं)”
• “Register पर double-click करने से duplicate ग्राहक बनता है”
• “order_items.product_name में अरबी product नाम truncate होते हैं”
• “Search 24 घंटे से ज़्यादा पहले डिलीट हुए products अब भी लौटाता है”
• “Order history पेज हर ऑर्डर पर एक query चलाता है (N+1): 200 ऑर्डर पर 4 s”
• “ईमेल पहले से मौजूद होने पर API raw database error के साथ 500 लौटाती है”

अक्सर पूछे जाने वाले सवाल

संदर्भ

• Constraints — PostgreSQL DocumentationPostgreSQL Global Development Groupcheck, not-null, unique, primary key, foreign key और exclusion constraints — वे नियम जो डेटाबेस लागू करता है और टेस्टर जाँचता है।
• Transactions — PostgreSQL DocumentationPostgreSQL Global Development Grouptransaction क्या है: कई क़दम जो BEGIN, COMMIT और ROLLBACK से सब-या-कुछ-नहीं लागू होते हैं, commit होने तक दूसरों को नहीं दिखते।
• Transaction Isolation Levels — MySQL 8.4 Reference ManualOracle (MySQL)चार SQL isolation levels जैसे InnoDB उन्हें लागू करता है, जिसमें REPEATABLE READ डिफ़ॉल्ट है।
• OWASP Cheat Sheet Series: SQL Injection PreventionOWASP Foundationपैरामीटराइज़्ड क्वेरी, सुरक्षित रूप से इस्तेमाल stored procedure, allow-list वैलिडेशन और least privilege — वे बचाव जिन्हें डेटाबेस टेस्ट को पुष्ट करना चाहिए।
• SQL InjectionOWASP FoundationSQL इंजेक्शन कैसे काम करता है और स्ट्रिंग जोड़ने के बजाय पैरामीटराइज़्ड क्वेरी ही बचाव क्यों हैं।
• Personal Data Protection Law (English translation)सऊदी डेटा एवं AI प्राधिकरण (SDAIA) · 2023व्यक्तिगत डेटा पर सऊदी कानून — टेस्ट वातावरण में असली ग्राहक रिकॉर्ड की प्रतियों के बजाय सिंथेटिक डेटा क्यों इस्तेमाल करना चाहिए।
• ISO/IEC 9075-1:2023 — Information technology — Database languages SQL — Part 1: Framework (SQL/Framework)ISO/IEC · 2023अंतरराष्ट्रीय SQL मानक का framework भाग, जिसे PostgreSQL, MySQL, SQLite आदि की बोलियाँ अलग-अलग हद तक लागू करती हैं।
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।