नेगेटिव API टेस्टिंग

Q: Invalid value पर 400 मिलना चाहिए या 422?

RFC 9110 400 को ऐसी request के लिए परिभाषित करता है जिसे server client error मानता है, और 422 को ऐसे content के लिए जो well-formed है पर process नहीं हो सकता। कई APIs malformed syntax के लिए 400 और invalid values के लिए 422 इस्तेमाल करती हैं, जैसा इस lesson में है; कुछ दोनों के लिए 400। जब contract इसे लिखे और हर endpoint उसे follow करे, तो दोनों ठीक हैं। 500 या 200 कभी ठीक नहीं।

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

Negative API testing वे requests भेजती है जिन्हें API contract के अनुसार reject होना चाहिए, और जाँचती है कि हर एक सही तरह reject हो: सही 4xx status code, documented format में error body, और data में कोई बदलाव नहीं। यह वही negative testing है जो आप जानते हैं, बस उस level पर जहाँ user को रोकने वाला कोई form नहीं: कोई भी client किसी endpoint पर कुछ भी भेज सकता है।

उदाहरण: POST /api/v1/cart/items 1 से 10 तक की quantity स्वीकार करता है। "quantity": 0 वाली request को 422 मिलना चाहिए, body में quantity का नाम होना चाहिए, और बाद में GET /api/v1/cart में cart पहले जैसा दिखना चाहिए। 201, 500, या body में error message के साथ 200 — यह defect है।

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

Mobile apps, partner systems और scripts API को उसके user interface से गुज़रे बिना call करते हैं, इसलिए API को हर rule ख़ुद लागू करना होगा। जब API अपने input पर भरोसा करती है, तो वह corrupt data save करती है, 500 के साथ crash होती है, stack traces leak करती है, या client को ऐसी properties set करने देती है जो उसके control में नहीं होनी चाहिए, जैसे price। OWASP API Security Top 10 2023 इस आख़िरी case को API3, Broken Object Property Level Authorization में रखता है।

Error responses भी एक interface हैं: clients status और error body पढ़कर तय करते हैं कि क्या दिखाना है और retry करना है या नहीं, इसलिए error format बदलना उन्हें success response बदलने जितना ही तोड़ता है। Tester के लिए contract हर rejection का exact expected result देता है, इसलिए negative API tests precise और automate करने में आसान होते हैं।

Invalid requests की classes और हर एक का सही status

Negative API tests वैसे design करें जैसे equivalence partitioning में invalid partitions: हर test में एक class, और request का बाकी हर हिस्सा valid, ताकि failure एक ही rule की ओर इशारा करे। Codes RFC 9110 और REST APIs वाले lesson से आते हैं; जहाँ HTTP विकल्प छोड़ता है, जैसे invalid values के लिए 400 या 422, वहाँ contract तय करता है।

Malformed syntax: कटी हुई body, आख़िर में extra comma, JSON बताई गई खाली body → 400 Bad Request।
Missing fields: हर required field बारी-बारी से हटाएँ, फिर उसे null और "" के रूप में भेजें, जिन्हें API अलग-अलग handle कर सकती है → field के नाम के साथ 400 या 422।
Wrong types: 2 की जगह "2", integer में 2.5, object की जगह array → 400 या 422, silent conversion नहीं।
Invalid values: अनजान enum value, 2026-02-30 जैसी date, ऐसी property जिसे client set नहीं कर सकता, जैसे "price": 0.01 → 422 या 400, या contract कहे तो ignore, पर कभी apply नहीं।
Wrong media type: JSON body पर Content-Type: text/plain → 415 Unsupported Media Type।
Wrong method: सिर्फ़ GET और POST वाले path पर PUT → Allow header के साथ 405 Method Not Allowed। Supported method जिसे यह caller इस्तेमाल नहीं कर सकता, उसका जवाब 403 है, जैसा authorization testing वाले lesson में देखा।
Bad authentication: missing, malformed या expired credential → WWW-Authenticate के साथ 401, जैसा API authentication वाले lesson में देखा।
Unknown resource: GET /api/v1/cart/items/99999 → 404 Not Found।

Cart API को भेजी गई invalid requests की आठ classes, हर एक के लिए उसके contract का ज़रूरी status, और एक गलत जवाब जो API के validation में defect दिखाता है।

Invalid request class	उदाहरण	Expected status	Report करने लायक गलत जवाब
Malformed syntax	`{"productId": 42,`	`400`पास	`500`: parser error handle नहीं हुआफ़ेल
Missing field	`{"quantity": 2}`	`422`pointer `#/productId`पास	`500`, या खाली value save होकर `201`फ़ेल
Wrong type	`"quantity": "2"`	`422`पास	`201`: string चुपचाप convert हो गईफ़ेल
Invalid value	`"quantity": 11`	`422`पास	`201`: 10 की limit सिर्फ़ UI में check होती हैफ़ेल
Wrong media type	`Content-Type: text/plain`	`415`पास	`500`, या HTML error pageफ़ेल
Wrong method	`PUT /api/v1/cart/items`	`405Allow: GET, POST` के साथपास	`404` या `500`, `Allow` header के बिनाफ़ेल
Bad authentication	`Authorization` header के बिना	`401WWW-Authenticate` के साथपास	Field errors के साथ `422`: body पहले पढ़ी गईफ़ेल
Unknown resource	`GET /api/v1/cart/items/99999`	`404`पास	खाली body के साथ `200`, या `500`फ़ेल

Status codes RFC 9110 के अनुसार हैं। यह contract malformed syntax के लिए 400 और invalid values के लिए 422 लेता है; दूसरा contract दोनों के लिए 400 ले सकता है। हर row में error body documented format में है और कोई data नहीं बदलता।

आज़माएँ: नेगेटिव टेस्ट जनरेटर आज़माएँ: API टेस्ट डेटा जेनरेटर

APIs के लिए boundary testing

Boundary value analysis API पर वैसे ही काम करती है जैसे form पर, बस boundaries OpenAPI schema में लिखी होती हैं। JSON Schema के keywords minimum, maximum, minLength, maxLength, minItems और maxItems (और उनके exclusive रूप) में से हर एक एक boundary और उसके पड़ोसी देता है। Query parameters की भी boundaries होती हैं: 1 से 100 तक का page size limit 0, 1, 100 और 101 देता है। RFC 9110 422 को request content के लिए परिभाषित करता है, इसलिए कई APIs invalid query parameter पर 400 लौटाती हैं, भले ही body values के लिए 422 इस्तेमाल करें, जैसा नीचे के example में है; फ़ैसला contract करता है।

Contract को यह भी बताना चाहिए कि limit के बाहर क्या होगा: request reject होगी, या value clamp होगी, जैसे limit=500 को 100 माना जाए। दोनों testable हैं; तय न किया गया behaviour team के लिए सवाल है। कुछ limits schema में कभी लिखी ही नहीं जातीं: OWASP API4:2023, Unrestricted Resource Consumption, per page records और maximum upload size जैसी missing limits गिनाता है।

बड़े integers: RFC 8259 बताता है कि implementations JSON integers की exact value पर सिर्फ़ -9007199254740991 और 9007199254740991 (2^53 - 1) के बीच सहमत होते हैं, इसलिए उससे बड़ी ID को JavaScript client चुपचाप round कर सकता है।
Body size: documented limit के ठीक नीचे और ठीक ऊपर, ऊपर 413 Content Too Large (RFC 9110) की उम्मीद के साथ, ऐसे environment पर जिस पर load डालने की अनुमति हो।

quantity (body):  { "type": "integer", "minimum": 1, "maximum": 10 }
  0 -> 422      1 -> 201      10 -> 201      11 -> 422

limit (query):    integer, 1..100, default 20
  0 -> 400      1 -> 200      100 -> 200     101 -> 400 (reject)
                                             101 -> 200, at most 100 items (clamp)

आज़माएँ: बाउंड्री वैल्यू जनरेटर आज़माएँ: OpenAPI → टेस्ट केस

Error response contract: RFC 9457 problem details

Negative test को सिर्फ़ status नहीं, expected error body भी चाहिए। RFC 9457, Problem Details for HTTP APIs, जिसने RFC 7807 की जगह ली, इसका format देता है: media type application/problem+json और पाँच standard members वाला JSON object। API field errors की list जैसे extension members जोड़ सकती है, और clients को अनजान extensions ignore करने होते हैं। नीचे के example में, RFC की तरह, हर field error में एक pointer है: request body के field की ओर इशारा करने वाला JSON Pointer (RFC 6901), जो URI fragment रूप #/quantity में लिखा है।

आपकी team के लिए RFC 9457 ज़रूरी नहीं, पर हर endpoint को एक documented format follow करना चाहिए। उन errors को भी शामिल करें जो application code ख़ुद नहीं बनाता, जैसे router से 404 या proxy से 413: इन्हीं के दूसरे format में, कभी-कभी HTML page के रूप में, आने की संभावना सबसे ज़्यादा है।

type: problem के प्रकार का URI। Clients और tests इसी पर फ़ैसला करते हैं, title के शब्दों पर नहीं। यह न हो तो इसकी value about:blank मानी जाती है।
title: type का छोटा summary, जो translation को छोड़कर हर occurrence में एक जैसा रहता है।
status: अगर हो तो status line वाला ही code, जैसा RFC 9457 ज़रूरी बताता है।
detail: इस occurrence की व्याख्या, जो client को request सुधारने में मदद के लिए लिखी हो, server debug करने के लिए नहीं।
instance: optional, इस occurrence का URI reference, जो logs में उसे ढूँढने में काम आता है।
कोई internals नहीं: न stack trace, न SQL, न file path, न version number, और न कोई password या token echo हो। RFC 9457 ऐसे leak से सावधान करता है, और OWASP API8:2023 इन्हें security misconfiguration गिनता है।

HTTP/1.1 422 Unprocessable Content
Content-Type: application/problem+json

{
  "type": "https://api.example.com/problems/validation-error",
  "title": "The request contains invalid fields.",
  "status": 422,
  "detail": "quantity must be between 1 and 10.",
  "errors": [
    { "pointer": "#/quantity", "detail": "must be between 1 and 10" }
  ]
}

आज़माएँ: Mock एरर रिस्पॉन्स जनरेटर आज़माएँ: API रिस्पॉन्स वैलिडेटर

Worked example: cart item जोड़ने के negative tests

Contract: POST /api/v1/cart/items के लिए Bearer token और JSON body चाहिए, जिसमें productId (integer, कम से कम 1) और quantity (integer, 1 से 10) हों। Path GET और POST support करता है; unknown properties reject होती हैं। Errors application/problem+json में आते हैं: malformed body पर 400, invalid values पर 422। हर test खाली cart से शुरू होता है, और product 42 मौजूद है।

हर test एक rule तोड़ता है, और उसके बाद GET /api/v1/cart को खाली cart ही लौटाना चाहिए: सही status के साथ stored item भी failed test ही है।

NA-04 quantity के चार boundary tests में से एक है: "quantity": 0 को भी 422 लौटाना चाहिए, और उसके positive साथी "quantity": 1 और "quantity": 10 को 201 लौटाना चाहिए।
NA-09 precedence टेस्ट करने के लिए जानबूझकर दो rules तोड़ता है: team ने तय किया कि credentials body से पहले check होंगे, ताकि anonymous callers को validation rules कभी पता न चलें।
अगर NA-05 ने 1.00 SAR की line price के साथ 201 लौटाया, तो यह critical defect है: price client ने तय किया।

ID     Request (one rule broken)                      Expected
NA-01  {"productId": 42, "quantity": 2,               400, problem+json
NA-02  {"quantity": 2}                                422, pointer #/productId
NA-03  {"productId": 42, "quantity": "2"}             422, pointer #/quantity
NA-04  {"productId": 42, "quantity": 11}              422, pointer #/quantity
NA-05  {"productId": 42, "quantity": 2, "price": 1}   422, pointer #/price
NA-06  valid body, Content-Type: text/plain           415
NA-07  PUT /api/v1/cart/items                         405, Allow: GET, POST
NA-08  valid body, no Authorization header            401, WWW-Authenticate: Bearer
NA-09  no Authorization header, {"quantity": 0}       401, not 422

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

आम गलतियाँ

सिर्फ़ "status 4xx है" assert करना: जहाँ contract 401 कहता है वहाँ 400 देर से चलने वाले authentication check को छिपा देता है।
Response जाँचना पर data नहीं: API ने 422 लौटाया, फिर भी item save हो गया। हर rejected write के बाद एक read करें।
एक request में कई rules तोड़ना, जिससे साफ़ नहीं होता कि API ने कौन-सा rule लागू किया, सिवाय जानबूझकर किए गए precedence test के।
सिर्फ़ application code के errors टेस्ट करना और router, framework व proxy के errors भूल जाना।
500 को इसलिए accept करना कि "कम से कम reject तो हुआ": client की गलती पर 5xx का मतलब है कि validation missing है।

QA का नज़रिया

Endpoint बनने से पहले, refinement में ही error contract माँगें: हर class का status, body format, unknown properties reject होंगी या ignore, limit से बाहर की values reject होंगी या clamp, और credentials, method, media type व body किस क्रम में check होंगे। जवाब OpenAPI document में लिखवाएँ, जिसे developers, client teams और tests सब पढ़ते हैं। उससे generate हुए cases अच्छी शुरुआत हैं; risk के हिसाब से ज़रूरी classes और boundaries आप ही चुनते हैं।

Negative API tests data-driven automation के लिए सही हैं: हर class या boundary value की एक row, जिसमें request, expected status और expected type हो, और जो हर change पर चले। Bug report में exact request (cURL command सबसे अच्छा), पूरा response, टूटा हुआ contract rule और कोई भी side effect हो। गलत शब्दों वाला title minor है; corrupt data, client का तय किया price या leak हुआ stack trace गंभीर है। Invalid requests सिर्फ़ उन्हीं systems को भेजें जो आपके हैं या जिन्हें टेस्ट करने की लिखित अनुमति आपके पास है।

अभ्यास

Appointments API के छह error responses परखें

आपका काम

एक clinic booking API का contract नीचे है, और एक साथी ने छह negative tests के नतीजे paste किए हैं। हर एक का expected response लिखें, तय करें कि test pass हुआ या नहीं, और हर failure के लिए एक line का bug title लिखें।

फिर date और notes के छूटे हुए boundary tests, expected status के साथ, लिखें।

सामग्री

Contract: POST /api/v1/appointments    (the path supports GET and POST)
Auth:     Bearer token, checked before the body
Body:     doctorId  integer >= 1, required
          date      "YYYY-MM-DD", from today to 60 days ahead, required
          notes     string, at most 500 characters, optional
Errors:   application/problem+json; malformed body 400; invalid values 422
Today:    2026-11-01; tests #1 to #5 send a valid token

#1{"doctorId": 7, "date": "2026-11-05", "notes": "Back pa      (body cut off)
    -> 500  Content-Type: text/html, an error page with a stack trace
#2  {"date": "2026-11-05"}
    -> 422  problem+json, errors: [{"pointer": "#/doctorId", "detail": "is required"}]
#3  {"doctorId": "7", "date": "2026-11-05"}
    -> 201  {"id": 5521, "doctorId": 7, "date": "2026-11-05"}
#4  {"doctorId": 7, "date": "2026-11-05", "notes": "<501 characters>"}
    -> 422  problem+json, {"status": 400, "title": "Bad Request", ...}
#5  DELETE /api/v1/appointments
    -> 404  problem+json, {"title": "Not Found"}
#6  no Authorization header, body {"date": "tomorrow"}
    -> 422  problem+json, errors for #/doctorId and #/date

चरण

हर request जो rule तोड़ती है वह खोजें, और expected status व body लिखें।
Actual status line, Content-Type और body की तुलना करें, status member समेत।
हर test को pass या fail mark करें; हर failure का bug title लिखें।
Contract से छूटी हुई boundary values निकालें।

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

मॉडल उत्तर

#1 fail: कटा हुआ JSON malformed syntax है, इसलिए application/problem+json के साथ 400 expected था; stack trace वाला HTML 500 internals leak करता है। Bug: "POST /api/v1/appointments पर कटा हुआ JSON stack trace के साथ 500 लौटाता है"।

#2 pass: 422, documented format और missing field की ओर pointer। पक्का करें कि कुछ create नहीं हुआ।

#3 fail: "7" string है, इसलिए pointer #/doctorId के साथ 422 expected था; API ने उसे convert करके appointment 5521 बना दिया, जिसे साफ़ करना होगा। Bug: "String के रूप में भेजा गया doctorId accept होकर appointment बना देता है"।

#4 fail, minor: 422 सही है, पर status member 400 कहता है, जबकि RFC 9457 दोनों का मेल ज़रूरी बताता है। Bug: "लंबे notes के problem details 422 response में status 400 बताते हैं"।

#5 fail: path GET और POST support करता है, इसलिए DELETE को Allow: GET, POST के साथ 405 मिलना चाहिए। Bug: "DELETE /api/v1/appointments 405 की जगह 404 लौटाता है"।

#6 fail: credentials पहले check होते हैं, इसलिए WWW-Authenticate: Bearer के साथ 401 expected था; 422 anonymous caller को validation rules बता देता है। Bug: "बिना authentication की appointment request को 401 की जगह field errors मिलते हैं"।

छूटी boundaries: date के लिए 2026-10-31 → 422, 2026-11-01 → 201, 2026-12-31 (60 दिन आगे) → 201, 2027-01-01 → 422; notes के लिए 500 characters → 201, साथ में "" और null, जिन्हें contract में cover होना चाहिए। doctorId 0 → 422 भी जोड़ें, और ऐसा doctorId जो मौजूद नहीं, जिसका expected status (404 या 422) team के लिए सवाल है।

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

Invalid value पर 400 मिलना चाहिए या 422?

RFC 9110 400 को ऐसी request के लिए परिभाषित करता है जिसे server client error मानता है, और 422 को ऐसे content के लिए जो well-formed है पर process नहीं हो सकता। कई APIs malformed syntax के लिए 400 और invalid values के लिए 422 इस्तेमाल करती हैं, जैसा इस lesson में है; कुछ दोनों के लिए 400। जब contract इसे लिखे और हर endpoint उसे follow करे, तो दोनों ठीक हैं। 500 या 200 कभी ठीक नहीं।

क्या हर API को RFC 9457 इस्तेमाल करना ज़रूरी है?

नहीं। RFC 9457 IETF का standards-track format है जिसे कोई API अपना सकती है, यह HTTP की शर्त नहीं है। पहले से मौजूद format भी ठीक है अगर वह documented हो और लगातार एक जैसा इस्तेमाल हो। RFC 9457 का फ़ायदा यह है कि generic tools और libraries application/problem+json पहचानती हैं, इसलिए clients को कम custom code चाहिए।

एक field को कितने negative tests चाहिए?

उस field पर लागू होने वाली हर invalid class (missing, null, wrong type, invalid format) के लिए एक test और हर limit के आसपास की boundary values से शुरू करें। फिर risk के हिसाब से priority तय करें: price या quantity को free-text comment से ज़्यादा tests चाहिए। OpenAPI document से cases generate करने वाले tools पूरी list जल्दी दे देते हैं; कौन-सी rows रखनी हैं, यह आप तय करते हैं।

क्या API को invalid requests भेजना safe है?

सिर्फ़ उन्हीं systems को जो आपके हैं या जिन्हें टेस्ट करने की लिखित अनुमति आपके पास है, बेहतर हो कि test environment में। इस lesson के payload ideas non-destructive हैं, पर बहुत बड़ी bodies या बहुत सारी requests फिर भी availability पर असर डाल सकती हैं, इसलिए पहले team के साथ limits तय करें।

संदर्भ

RFC 9110: HTTP SemanticsIETF · 2022HTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।
RFC 9457: Problem Details for HTTP APIsIETF · 2023मशीन-रीडेबल API एरर के लिए application/problem+json फ़ॉर्मेट (type, title, status, detail, instance)।
OWASP API Security Top 10 (2023)OWASP Foundation · 2023API की दस सबसे आम कमज़ोरियाँ: ऑब्जेक्ट-लेवल ऑथराइज़ेशन का टूटना, ऑथेंटिकेशन का टूटना, अनियंत्रित रिसोर्स खपत और अन्य।
JSON Schema SpecificationJSON SchemaJSON दस्तावेज़ की संरचना का वर्णन और वैलिडेशन करने की शब्दावली (टाइप, आवश्यक प्रॉपर्टी, फ़ॉर्मेट)।

नेगेटिव API टेस्टिंग

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

Invalid requests की classes और हर एक का सही status

APIs के लिए boundary testing

Error response contract: RFC 9457 problem details

Worked example: cart item जोड़ने के negative tests

आम गलतियाँ

QA का नज़रिया

अभ्यास

Appointments API के छह error responses परखें

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

संदर्भ

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

REST API टेस्टर

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

API टेस्ट डेटा जेनरेटर

OpenAPI → टेस्ट केस

API रिस्पॉन्स वैलिडेटर

Mock एरर रिस्पॉन्स जनरेटर

और गहराई से

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

इस topic से पहले

अगले topics

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

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

Invalid requests की classes और हर एक का सही status

APIs के लिए boundary testing

Error response contract: RFC 9457 problem details

Worked example: cart item जोड़ने के negative tests

आम गलतियाँ

QA का नज़रिया

अभ्यास

Appointments API के छह error responses परखें

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

संदर्भ

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

और गहराई से

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

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

इस topic से पहले

अगले topics

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