वेब फ़ॉर्म टेस्टिंग

Mutqan Soft QA टीम द्वारा · अपडेट 6 अक्टूबर 2026 · 19 मिनट · शुरुआती

Web form user का input इकट्ठा करके server को भेजता है: sign-up, checkout, booking, contact। उसे टेस्ट करने का मतलब है यह जाँचना कि हर field वह स्वीकार करे जो उसे करना चाहिए और वह reject करे जो नहीं, हर rejection अपनी वजह बताए, submit ठीक एक बार एक ही काम करे, और server वही store करे जो user ने भरा।

Form का input आम तौर पर दो layers में जाँचा जाता है। Client-side validation browser में, कुछ भी भेजे जाने से पहले चलता है: Email खाली छोड़ें और browser आपको रोक देता है। Server-side validation request पहुँचने पर चलता है: सिर्फ़ server जानता है कि यह email पहले से registered है। Tester दोनों जाँचता है।

यह क्यों ज़रूरी है

Forms वह जगह हैं जहाँ users अपना data और पैसा सौंपते हैं। Apostrophe वाला सही नाम reject करने वाला form customer खो देता है; double click पर दो बार booking करने वाला form seats खत्म कर देता है या दो बार पैसे काटता है। ऐसे defects तब छूट जाते हैं जब सिर्फ़ कुछ साफ़-सुथरी values ही आज़माई जाती हैं।

Client-side checks को bypass करना भी आसान है। OWASP Input Validation Cheat Sheet validation server पर माँगती है, क्योंकि browser में होने वाले किसी भी check से बचा जा सकता है। सख़्त दिखने वाला form ऐसे server पर टिका हो सकता है जो कुछ भी स्वीकार कर ले, और यह सिर्फ़ वही tester पता करता है जो browser को bypass करके देखता है।

Client-side और server-side validation

Client-side validation HTML for testers वाले lesson की HTML constraints इस्तेमाल करता है, जैसे required, type="email" और maxlength, साथ में page scripts जो field को type करते समय या छोड़ते समय जाँचती हैं। यह तेज़ feedback देता है, सुरक्षा नहीं: कोई भी attribute हटा सकता है, JavaScript बंद कर सकता है या page के बिना request भेज सकता है।

Server-side validation असली enforcement है। इसे हर client rule दोहराना चाहिए, और stored data वाले rules, जैसे unique email या बची हुई seats, सिर्फ़ यही जाँच सकता है। हर rule को form के ज़रिए, user experience के लिए, और उसके बाहर से, enforcement के लिए टेस्ट करें, उस system पर जिसे टेस्ट करने की अनुमति हो:

DevTools में required या maxlength हटाएँ, या browser के built-in checks बंद करने के लिए <form> में novalidate जोड़ें, फिर submit करें। Edit सिर्फ़ आपके tab में रहता है; request असली होती है।
या Network panel से request को cURL के रूप में copy करें, एक value बदलें और test account के साथ terminal से या API Request Builder से फिर भेजें; cURL Parser command को method, URL, headers और body में बाँट देता है। Expected: 422 जैसा 4xx response, field का नाम, कुछ save नहीं।
दोनों rule sets की तुलना करें। Page से सख़्त server (page 100 characters देता है, database column में 50 आते हैं) 500 या चुपचाप कटे text के रूप में दिखता है; server से सख़्त page (+ reject करने वाला email pattern) असली users को रोकता है।

खाली required field browser में ही, किसी request से पहले रुक जाता है; पहले से registered email और invalid values वाली replay की गई request को सिर्फ़ server reject करता है।

Form के ज़रिए
- यूज़र
- ब्राउज़र client-side validation
- सर्वर server-side validation
1. 1 यूज़र से ब्राउज़र तक: Full name खाली छोड़कर Register click करता है
2. 2 ब्राउज़र आंतरिक रूप से: required fail: कोई request नहीं जाती
3. 3 ब्राउज़र से यूज़र तक: Full name के पास message जवाब
4. 4 यूज़र से ब्राउज़र तक: नाम ठीक करके फिर Register click करता है Email sara@example.com, पहले से registered
5. 5 ब्राउज़र आंतरिक रूप से: Client-side checks पास
6. 6 ब्राउज़र से सर्वर तक: Registration भेजता है POST /events/42/registrations
7. 7 सर्वर आंतरिक रूप से: Rules दोहराता है, stored registrations जाँचता है सिर्फ़ server जानता है कि email पहले से है
8. 8 सर्वर से ब्राउज़र तक: 422: email पहले से registered जवाब {"field":"email","code":"already_registered"}
9. 9 ब्राउज़र से यूज़र तक: Email के नीचे message, input बना रहता है जवाब
परिणाम: Browser तुरंत feedback देता है; stored data वाले rules सिर्फ़ server पर जाँचे जाते हैं।
Form के बाहर से
- टेस्टर
- ब्राउज़र client-side validation
- सर्वर server-side validation
1. 1 टेस्टर से सर्वर तक: Page के बिना request replay करता है cURL के रूप में copy: spaces वाला नाम, 5 tickets {"name":" ","tickets":5}
2. 2 सर्वर आंतरिक रूप से: हर client rule दोहराता है नाम trim करता है, 1 से 4 tickets की अनुमति
3. 3 सर्वर से टेस्टर तक: 422, दोनों fields के नाम, कुछ save नहीं जवाब पास
परिणाम: Expected: server खुद reject करता है। यहाँ 201 का मतलब होगा कि वह browser पर भरोसा करता है, जो एक defect है।

आज़माएँ: cURL पार्सर आज़माएँ: API रिक्वेस्ट बिल्डर

Required fields और positive व negative inputs

जाँचें कि हर required field screen पर और markup में marked है, और हर छूटा field report होता है। Browsers के built-in messages आम तौर पर एक बार में सिर्फ़ पहला invalid field दिखाते हैं; अगर requirement सारी errors एक साथ माँगती है, तो page को उन्हें list करने वाली अपनी script चाहिए। सिर्फ़ spaces वाला text field browser का required check पास कर लेता है, इसलिए server को उसे trim करके reject करना होगा। खाली छोड़े गए optional fields खाली ही store हों, null text के रूप में नहीं; और शर्त वाले required fields, जैसे सिर्फ़ business accounts के लिए VAT number, की दोनों states टेस्ट करें।

फिर field दर field positive और negative testing लागू करें। असली valid data developers की उम्मीद से कहीं ज़्यादा विविध होता है:

Positive: O'Brien, Al-Harbi, Arabic और Devanagari में नाम, sara+events@example.com, spaces के साथ paste किया गया phone number जैसे +966 50 123 4567।
Negative: खाली, सिर्फ़ spaces, maximum से एक character ज़्यादा, sara@, number field में letters, और जहाँ minimum 1 हो वहाँ 0।
<b>Sara</b> जैसा markup जैसा दिखने वाला text ठीक वैसा ही store और display हो जैसा type हुआ, कभी bold में render न हो; web security basics वाला lesson इसे आगे ले जाता है।
Phone field में ٠٥٠١٢٣٤٥٦٧ जैसे Arabic-Indic digits: requirement के अनुसार convert हों या साफ़ message के साथ reject हों। Requirement चुप हो तो पूछें।

आज़माएँ: वैलिडेशन टेस्ट जनरेटर आज़माएँ: नेगेटिव टेस्ट जनरेटर आज़माएँ: Unicode डेटासेट जनरेटर

Error messages, submission और double submit

Error message expected result का हिस्सा है: वह अपने field के पास दिखे, बताए कि क्या करना है ("name@example.com जैसा email डालें", न कि "Invalid input"), user का भरा हुआ बनाए रखे, और field ठीक होते ही हट जाए। Server errors client errors जैसे ही दिखें और page की भाषा में हों; browser के built-in messages browser की भाषा में आते हैं। Errors कैसे announce हों, यह accessible forms वाली guide में है।

Submit को एक काम एक बार करना चाहिए: progress दिखे, success पर confirmation दिखे और ठीक एक record store हो, और failure पर, connection टूटने समेत, input बना रहे। Single-line field में Enter दबाने से भी आम तौर पर form submit हो जाता है। RFC 9110 POST को idempotent के रूप में परिभाषित नहीं करता: दो एक जैसी POST requests का असर एक request से ज़्यादा हो सकता है, इसलिए वही form दो बार जाने पर दो records बन सकते हैं। DevTools में network throttle करके आज़माएँ:

Submit पर double-click करें, या Enter दो बार दबाएँ।
Confirmation page reload करें: browser data दोबारा भेजने का विकल्प देता है। कई sites POST के बाद GET से load होने वाले page पर redirect करके इसे रोकती हैं।
Back जाकर फिर submit करें, या वही form दो tabs से submit करें।
Expected: एक record, एक email। Disabled button ज़्यादातर double clicks रोकता है, पर reload, दूसरा tab या replay की गई request नहीं, इसलिए server को duplicate पकड़ने का अपना check चाहिए।

आज़माएँ: Mock एरर पेलोड जनरेटर

Autofill और password managers

कई users type करते ही नहीं: browser या password manager saved data से form भर देता है। autocomplete attribute उसे बताता है कि हर field क्या है, HTML standard के tokens से, जैसे name, email, tel और new-password; WCAG 2.2 का success criterion 1.3.5 Identify Input Purpose user की जानकारी लेने वाले fields पर इनकी अपेक्षा करता है। एक अलग browser profile में test data save करें, फिर जाँचें कि:

हर value सही field में जाए, "First name" में पूरा नाम नहीं।
Validation और Submit button भरी गई values पर react करें: JavaScript for testers वाले lesson की तरह, सिर्फ़ key presses सुनने वाला check autofill के बाद कभी नहीं चलता।
Sign-in fields paste और password managers स्वीकार करें। इन्हें रोकने से लोगों को passwords याद से type करने पड़ते हैं, जिसे रोकने के लिए WCAG 2.2 का success criterion 3.3.8 Accessible Authentication (Minimum) बना है।

आज़माएँ: फ़ेक यूज़र जनरेटर आज़माएँ: फ़ेक फ़ोन नंबर जनरेटर

Worked example: event registration form

Requirement: "Free event में register करने के लिए Full name (required, 2 से 60 characters), Email (required, हर email से एक registration), Mobile (required, 05 और 8 digits), Company (optional) और Tickets (1 से 4, बची हुई seats के भीतर) भरें। Register reference number दिखाता है और email भेजता है।" Browser presence, length, format और range जाँच सकता है; कौन-से emails registered हैं और कितनी seats बची हैं, यह सिर्फ़ server जानता है।

RF-01, positive: valid data → reference number, एक record, एक email।
RF-02, positive: نورة القحطاني, nora+expo@example.com, company नहीं → स्वीकार, और जैसा भरा वैसा ही दिखे।
RF-03, negative, browser: सारे fields खाली छोड़कर Register → हर required field report हो, और Network panel में कोई request न दिखे।
RF-04, negative, server: "name": " " और "tickets": 5 के साथ replay की गई request → 422, दोनों fields के नाम, कुछ save नहीं।
RF-05, negative, सिर्फ़ server: पहले से registered email → Email के नीचे message, बाक़ी input बना रहे।
RF-06, double submit: throttled connection पर Register पर double-click → एक record, एक email।
RF-07, autofill: saved phone +966501234567 → 0501234567 के रूप में store हो, या format message के साथ reject हो; requirement को बताना होगा कि कौन-सा।

आम गलतियाँ

Validation सिर्फ़ form के ज़रिए टेस्ट करना और कभी न जाँचना कि server वही rules लागू करता है।
Response और stored data जाँचने के बजाय screen पर दिखे message पर भरोसा करना।
सिर्फ़ साफ़-सुथरा test data: न apostrophe, न Arabic text, न emails में +, न paste की गई values।
खाली submit के पहले message पर रुक जाना, बजाय यह जाँचने के कि हर छूटा field report होता है।
तेज़ connection पर Submit एक बार click करके मान लेना कि double submit हो ही नहीं सकता।
Autofill या password manager कभी न आज़माना, जबकि बहुत-से असली users forms ऐसे ही भरते हैं।

QA का नज़रिया

Form testing refinement में शुरू होती है। हर field के लिए पूछें: rule क्या है, उसे कौन लागू करता है (browser, server या दोनों), message ठीक-ठीक क्या है, और success, failure और दूसरे submit पर क्या होता है। जो rules सिर्फ़ developer के दिमाग़ में रहते हैं, वे page और server के बीच mismatch बन जाते हैं।

Test data के रूप में field table रखें: हर field की एक row, valid और invalid values और हर rule जाँचने वाली layer के साथ; बाद में यही automated checks को data देती है। Bug report में layer का नाम लें: "page emails में + reject करता है, API उसे स्वीकार करती है" developer को सही code तक ले जाता है। Validation bypass और double submit सिर्फ़ उन environments पर टेस्ट करें जिनकी अनुमति हो, test accounts के साथ।

अभ्यास

Support request form के tests plan करें

आपका काम

Support page पर नीचे वाला form है। Requirement: "Name और Email required हैं। Order number optional है; अगर दिया जाए तो ORD- और 6 digits। Message required है, 20 से 1,000 characters। एक screenshot, PNG या JPG, 5 MB तक, attach किया जा सकता है। Send एक ticket बनाता है और उसका number दिखाता है।" Markup की requirement से तुलना करें, फिर tests plan करें।

List तैयार होने पर उसकी तुलना Validation Test Generator के output से करें।

सामग्री

<form action="/support" method="post">
  <label for="name">Name *</label>
  <input id="name" name="name" required>
  <label for="email">Email *</label>
  <input id="email" name="email" type="text" required>
  <label for="order">Order number</label>
  <input id="order" name="order" pattern="ORD-[0-9]{5}">
  <label for="msg">Message *</label>
  <textarea id="msg" name="message" minlength="20" maxlength="2000"></textarea>
  <label for="shot">Screenshot</label>
  <input id="shot" name="shot" type="file" accept=".png,.jpg,.pdf">
  <button>Send</button>
</form>

चरण

Markup और requirement के बीच के mismatches लिखें।
हर field के positive और negative inputs लिखें, और वह layer जिसे हर negative input reject करना चाहिए।
Error messages, double submit और autofill के tests जोड़ें।
Product owner के लिए अपने सवाल लिखें।

मॉडल उत्तर दिखाएँ

मॉडल उत्तर

Mismatches: Email type="text" है, इसलिए browser कोई format नहीं जाँचता। Order का pattern 6 की जगह 5 digits माँगता है। Message पर required नहीं है, और maxlength="2000" limit का दोगुना है। accept में .pdf जुड़ा है, और वैसे भी वह सिर्फ़ file picker को filter करता है। Requirement से अलग, Name और Email पर autocomplete tokens नहीं हैं। HTML file size सीमित नहीं कर सकता, इसलिए 5 MB हर हाल में server का काम है।

Positive: apostrophe वाला नाम और Arabic नाम; sara+help@example.com; order number खाली; ORD-123456, जिसे गलत pattern अभी reject करता है, यह defect है; 20 और 1,000 characters के messages; एक JPG और ठीक 5 MB का PNG। Negative जिसे browser और server दोनों reject करें: खाली Name या Email, 19 characters का message। सिर्फ़ server reject करे, क्योंकि यह page उन्हें जाने देता है: sara@, ORD-12345, खाली message, 20 spaces, 1,001 characters, PDF, 5 MB से एक byte बड़ी image, .png में rename की गई text file।

साथ में: हर error अपने field के नीचे दिखे और बाक़ी input बना रहे; throttled connection पर Send पर double-click करें और confirmation page reload करें, expected एक ticket; autocomplete="name" और autocomplete="email" जोड़ने के बाद autofill Name और Email भरे।

सवाल: क्या values के आसपास के spaces trim होते हैं? Arabic text और emoji में characters कैसे गिने जाते हैं? 5 MB का मतलब 5,000,000 bytes है या 5,242,880, और क्या .jpeg file भी JPG गिनी जाएगी? दूसरे tab से भेजा गया वही message नया ticket है या duplicate? Upload fail होने पर user क्या देखता है?

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

अगर server सब कुछ जाँचता है, तो client-side validation टेस्ट ही क्यों करें?

क्योंकि वह user experience का हिस्सा है। Client-side checks server तक जाए बिना तुरंत और साफ़ feedback देते हैं। अगर वे गलत हों, तो valid users को server से पूछे जाने से पहले ही रोक देते हैं, या गलतियों को धीमे और धुँधले server error तक जाने देते हैं। हर layer का अपना काम है, इसलिए दोनों टेस्ट करें।

क्या browser को bypass करना security test है?

यह बुनियादी functional check है कि server अपने rules खुद लागू करता है, और हर tester को उन systems पर यह करना चाहिए जिन्हें टेस्ट करने की अनुमति हो। Server को जानबूझकर तोड़ने की कोशिश, जैसे injection payloads भेजना, security testing है: वह roadmap में आगे आती है और उसके लिए लिखित अनुमति चाहिए।

अपना data इस्तेमाल किए बिना autofill कैसे टेस्ट करें?

एक अलग browser profile बनाएँ और उसमें test data save करें: नकली नाम, example.com जैसे reserved domain पर email address, और test phone number। Fake User Generator और Fake Phone Number Generator ऐसा data बनाते हैं। Test system पर अपनी असली personal या payment details कभी इस्तेमाल न करें।

क्या Submit button disable करने से double submit रुक जाता है?

सिर्फ़ कुछ हद तक। यह उसी page पर दूसरा click रोकता है, पर POST का reload, दूसरे tab में वही form या replay की गई request नहीं। भरोसेमंद सुरक्षा server पर होती है, जैसे ऐसा check जो दूसरी एक जैसी registration reject करे। दोनों टेस्ट करें।

संदर्भ

HTML Living StandardWHATWGHTML भाषा, नामित कैरेक्टर रेफ़रेंस (एंटिटी) और ब्राउज़रों के पार्सिंग नियमों सहित।
OWASP Cheat Sheet Series: Input ValidationOWASP Foundationअलाउ-लिस्ट वैलिडेशन, सिंटैक्टिक बनाम सेमांटिक जाँच, और क्लाइंट-साइड वैलिडेशन कभी सुरक्षा नियंत्रण क्यों नहीं है।
RFC 9110: HTTP SemanticsIETF · 2022HTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।
Client-side form validation — MDNMDN Web Docs (Mozilla)ब्राउज़र में built-in और स्क्रिप्ट से होने वाला form validation, और क्यों यह उपयोगकर्ता की मदद करता है पर server पर validation की जगह कभी नहीं लेता।

वेब फ़ॉर्म टेस्टिंग

यह क्यों ज़रूरी है

Client-side और server-side validation

Required fields और positive व negative inputs

Error messages, submission और double submit

Autofill और password managers

Worked example: event registration form

आम गलतियाँ

QA का नज़रिया

अभ्यास

Support request form के tests plan करें

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

संदर्भ

Mutqan tools से अभ्यास करें

वैलिडेशन टेस्ट जनरेटर

नेगेटिव टेस्ट जनरेटर

cURL पार्सर

API रिक्वेस्ट बिल्डर

Unicode डेटासेट जनरेटर

फ़ेक यूज़र जनरेटर

और गहराई से

इस topic में आपकी प्रगति

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics

यह क्यों ज़रूरी है

Client-side और server-side validation

Required fields और positive व negative inputs

Error messages, submission और double submit

Autofill और password managers

Worked example: event registration form

आम गलतियाँ

QA का नज़रिया

अभ्यास

Support request form के tests plan करें

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

संदर्भ

Mutqan tools से अभ्यास करें

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics