نوشته های Nastooh

Postman Script

Nastooh — Sat, 27 Jun 2026 22:51:55 +0330

فقط اسم فیلدها و Status Code را عوض می‌کنی.1) Pre-request عمومی برای Create موفقconst uniqueSuffix = Date.now().toString().slice(-6); pm.environment.set("requestDateTime", new Date().toISOString()); pm.environment.set("idempotencyKey", pm.variables.replaceIn("{{$guid}}")); pm.environment.set("baseTitle", "Test Title " + uniqueSuffix); pm.environment.set("baseCode", uniqueSuffix); Body نمونه:{ "title": "{{baseTitle}}", "code": "{{baseCode}}" } 2) Pre-request برای Duplicate Titleconst uniqueSuffix = Date.now().toString().slice(-6); pm.environment.set("requestDateTime", new Date().toISOString()); pm.environment.set("idempotencyKey", pm.variables.replaceIn("{{$guid}}")); pm.environment.set("fixedTitle", "Duplicate Title"); pm.environment.set("baseCode", uniqueSuffix); Body:{ "title": "{{fixedTitle}}", "code": "{{baseCode}}" } 3) Pre-request برای Duplicate Codeconst uniqueSuffix = Date.now().toString().slice(-6); pm.environment.set("requestDateTime", new Date().toISOString()); pm.environment.set("idempotencyKey", pm.variables.replaceIn("{{$guid}}")); pm.environment.set("baseTitle", "Test Title " + uniqueSuffix); pm.environment.set("fixedCode", "DUP-CODE-001"); Body:{ "title": "{{baseTitle}}", "code": "{{fixedCode}}" } 4) Pre-request برای Header تاریخ قدیمیconst uniqueSuffix = Date.now().toString().slice(-6); pm.environment.set("requestDateTime", "2020-01-01T00:00:00.000Z"); pm.environment.set("idempotencyKey", pm.variables.replaceIn("{{$guid}}")); pm.environment.set("baseTitle", "Test Title " + uniqueSuffix); pm.environment.set("baseCode", uniqueSuffix); 5) Test موفق Createconst response = pm.response.json(); pm.test("Status Code is 201", function () { pm.response.to.have.status(201); }); pm.test("ResultData exists", function () { pm.expect(response.resultData).to.not.be.null; }); pm.test("No errors returned", function () { pm.expect(response.errorList).to.be.an("array").that.is.empty; }); pm.test("Title matches request", function () { pm.expect(response.resultData.title).to.eql(pm.environment.get("baseTitle")); }); pm.test("Code matches request", function () { pm.expect(response.resultData.code).to.eql(pm.environment.get("baseCode")); }); if (pm.response.code === 201) { pm.environment.set("savedCode", response.resultData.code); pm.environment.set("savedTitle", response.resultData.title); } 6) Test خطای عمومیconst response = pm.response.json(); pm.test("Status Code is expected error", function () { pm.response.to.have.status(400); // change to 409, 401, 403, 404 if needed }); pm.test("ResultData is null", function () { pm.expect(response.resultData).to.be.null; }); pm.test("ErrorList exists", function () { pm.expect(response.errorList).to.be.an("array").that.is.not.empty; }); 7) Test Duplicate Titleconst response = pm.response.json(); pm.test("Status Code is 409", function () { pm.response.to.have.status(409); }); pm.test("Duplicate title error exists", function () { const error = response.errorList .flatMap(e => e.details || []) .find(d => d.field === "title"); pm.expect(error).to.not.be.undefined; }); 8) Test Duplicate Codeconst response = pm.response.json(); pm.test("Status Code is 409", function () { pm.response.to.have.status(409); }); pm.test("Duplicate code error exists", function () { const error = response.errorList .flatMap(e => e.details || []) .find(d => d.field === "code"); pm.expect(error).to.not.be.undefined; }); 9) Test خطای Headerconst response = pm.response.json(); pm.test("Status Code is 400", function () { pm.response.to.have.status(400); }); pm.test("Header error exists", function () { const errorText = JSON.stringify(response.errorList); pm.expect(errorText).to.match(/header|RequestDateTime|Idempotency|تاریخ|زمان/i); }); 10) Test ذخیره مقدار برای Chain Requestconst response = pm.response.json(); pm.test("Status Code is success", function () { pm.response.to.be.success; }); if (response.resultData && response.resultData.code) { pm.environment.set("savedCode", response.resultData.code); } در Request بعدی:{ "parentCode": "{{savedCode}}" } 11) Test برای GET By Codeconst response = pm.response.json(); pm.test("Status Code is 200", function () { pm.response.to.have.status(200); }); pm.test("ResultData exists", function () { pm.expect(response.resultData).to.not.be.null; }); pm.test("Returned code matches saved code", function () { pm.expect(response.resultData.code).to.eql(pm.environment.get("savedCode")); }); 12) Test برای PUT / Updateconst response = pm.response.json(); pm.test("Status Code is 200", function () { pm.response.to.have.status(200); }); pm.test("Updated title returned", function () { pm.expect(response.resultData.title).to.eql(pm.environment.get("updatedTitle")); }); Pre-request برای Update:const uniqueSuffix = Date.now().toString().slice(-6); pm.environment.set("requestDateTime", new Date().toISOString()); pm.environment.set("idempotencyKey", pm.variables.replaceIn("{{$guid}}")); pm.environment.set("updatedTitle", "Updated Title " + uniqueSuffix); 13) Test برای DELETEconst response = pm.response.json(); pm.test("Status Code is 200 or 204", function () { pm.expect([200, 204]).to.include(pm.response.code); }); 14) Test بعد از DELETEconst response = pm.response.json(); pm.test("Deleted item should not be found", function () { pm.expect([404, 410]).to.include(pm.response.code); }); توضیحات ساختار:ابتدا در Pre-request Script داده داینامیک مثل requestDateTime، idempotencyKey، title و code تولید می‌کنم تا تست قابل تکرار باشد. سپس Request را با Body و Header معتبر ارسال می‌کنم. در Tests، ابتدا Status Code را بررسی می‌کنم، سپس ساختار Response مثل resultData و errorList را اعتبارسنجی می‌کنم. در سناریوهای موفق، مقادیر برگشتی مثل code را در Environment ذخیره می‌کنم تا در Requestهای بعدی برای Chain Request استفاده شود. در سناریوهای منفی، انتظار دارم resultData مقدار null داشته باشد و errorList شامل خطای مرتبط با همان فیلد یا Header باشد. این مجموعه قابل تغییر برای تقریباً هر API است.

Session Management (Authentication & Authorization with Cookie & Token)postman

Nastooh — Fri, 26 Jun 2026 10:14:05 +0330

جمع‌بندی آزمونی سرفصلSession Management چیست؟Session Management فرآیند مدیریت وضعیت (State) کاربر بین درخواست‌های مختلف HTTP است.چون HTTP به‌صورت پیش‌فرض Stateless است، باید با مکانیزم‌هایی مثل Cookie یا Token هویت کاربر را حفظ کنیم.مفهوم مهم پایهAuthentication → شناسایی کاربر (Who are you?)Authorization → تعیین دسترسی (What can you do?)روش‌های Session Management1. Cookie-based Sessionدر این مدل، سرور یک Session ID ایجاد کرده و در Cookie مرورگر ذخیره می‌شود.Flow:LoginServer → ایجاد SessionClient → ذخیره Cookieهر request → Cookie ارسال می‌شودمثال:Cookie: sessionId=abc123 ویژگی‌ها:Statefulوابسته به Serverذخیره در Browserمناسب Web applicationsمزایا:سادهکنترل کامل روی sessionمعایب:مقیاس‌پذیری سختوابستگی به سرورمشکل در Microservices2. Token-based Authenticationدر این روش، سرور یک Token (مثل JWT) صادر می‌کند و Client آن را در هر request ارسال می‌کند.مثال:Authorization: Bearer eyJhbGciOi... ویژگی‌ها:Statelessقابل استفاده در API و Microservicesقابل انتقال بین سیستم‌هامزایا:مقیاس‌پذیرمناسب موبایل و SPAبدون نیاز به session serverمعایب:مدیریت revoke سخت‌ترامنیت وابسته به token handlingCookie vs TokenAuthentication vs AuthorizationAuthentication:بررسی هویت کاربرLogin processAuthorization:بررسی سطح دسترسیRole-based accessنکات مهم آزمونی (L7 → L8)1. HTTP is Statelessهر request مستقل استsession باید جدا مدیریت شود2. Cookie-based risksession hijackingCSRF attacksserver memory overload3. Token-based risktoken leakageno immediate revocationJWT misuse4. Secure ImplementationHTTPS الزامیtoken expirationrefresh token mechanism5. API Testing FocusBackend Tester باید بررسی کند:آیا Authorization header enforce شده؟آیا cookie session معتبر است؟آیا expired token reject می‌شود؟آیا unauthorized request → 401 می‌دهد؟آیا forbidden access → 403 می‌دهد؟خطاهای رایج در آزموناشتباه گرفتن Authentication و Authorizationفکر کردن Cookie و Token هر دو stateless هستندنادیده گرفتن HTTPS requirementعدم درک session persistenceconfusion بین 401 و 403نکته امتحانی مهمدر پاسخ کامل باید این کلیدواژه‌ها باشند:Session Management, Authentication, Authorization, Cookie, Session ID, Token, JWT, Bearer Token, Stateless, Stateful, HTTP Statelessness, Securityنمونه پاسخ کامل کوتاهSession Management در API برای مدیریت وضعیت کاربر بین درخواست‌ها استفاده می‌شود، زیرا HTTP ذاتاً stateless است. در روش Cookie-based، سرور یک session ایجاد کرده و آن را در cookie ذخیره می‌کند (stateful). در روش Token-based، سرور یک token مانند JWT صادر می‌کند و client آن را در هر request ارسال می‌کند (stateless). Authentication برای شناسایی کاربر و Authorization برای تعیین سطح دسترسی استفاده می‌شود.کلیدواژه‌هاSession Management Authentication Authorization Cookie Session ID Token JWT Bearer Token Stateless Stateful API Security HTTP Statelessness Login SessionSession Management (مدیریت وضعیت کاربر): برای حفظ هویت کاربر بین درخواست‌های HTTP استفاده می‌شود.Cookie-based Authentication (احراز هویت مبتنی بر کوکی): session در سمت سرور ذخیره می‌شود و در cookie ارسال می‌گردد.Token-based Authentication (احراز هویت مبتنی بر توکن): از token مانند JWT برای احراز هویت stateless استفاده می‌شود.جمع‌بندی ذهنیSession یعنی:👉 “چطور سیستم بفهمد این درخواست از همان کاربر قبلی است”

Documentation + Collaboration (Postman)

Nastooh — Fri, 26 Jun 2026 01:17:36 +0330

جمع‌بندی آزمونی سرفصلDocumentation in PostmanDocumentation چیست؟در Postman، Documentation یعنی مستندسازی کامل APIها به‌صورت قابل فهم برای:DeveloperTesterProduct teamExternal consumersبخش‌های Documentation1. Request Descriptionتوضیح هر API Request:هدف endpointورودی‌هاخروجی‌هاstatus codeهامثال:این API برای ایجاد customer جدید استفاده می‌شود.2. Collection Descriptionتوضیح کل مجموعه APIها:هدف سیستمدامنه APIنحوه استفاده از collectionمثال:مجموعه APIهای مدیریت مشتریان بانک3. Example Requestذخیره یک نمونه واقعی از request و response.مثال:POST /customers { "name": "Ali" } کاربرد Documentationکاهش وابستگی به تیم backendافزایش فهم APIاستفاده در onboardingکاهش miscommunicationکمک به contract understandingنکته آزمونی مهم:👉 Documentation = “API as a readable product”Collaboration in PostmanCollaboration چیست؟قابلیتی برای اشتراک‌گذاری و هماهنگ‌سازی API collections بین تیم‌هاروش‌های Collaboration1. Sharing Collectionsاشتراک مستقیم collection با تیمlink sharingworkspace sharing2. Syncing Collectionsهمگام‌سازی تغییرات بین اعضای تیمreal-time updatesversion consistencyshared environment3. Workspacesمحیط همکاری تیمی در PostmanTeam WorkspacePrivate WorkspacePublic Workspaceکاربرد Collaborationهماهنگی بین QA و Developerجلوگیری از اختلاف نسخه APIshared testing environmentteamwork در automation testingنکته آزمونی مهم:👉 Collaboration = “single source of truth for API testing”تفاوت Documentation vs Collaborationنکات مهم آزمونی (L7 → L8)1. API as ProductDocumentation باعث می‌شود API مثل یک محصول قابل استفاده باشد.2. Contract UnderstandingDocumentation کمک می‌کند:SwaggerRequest/ResponseStatus codeبه درستی فهمیده شود.3. Team ConsistencyCollaboration باعث می‌شود:همه یک نسخه API را ببیننداختلاف بین QA و Dev کاهش یابد4. Risk in Collaborationتغییر بدون اطلاع تیمversion conflictoverwrite شدن environment variables5. Automation Impactshared collections در CI/CD استفاده می‌شوندNewman از shared workspace اجرا می‌شودخطاهای رایج در آزمونندانستن تفاوت Documentation و Swaggerفکر کردن documentation فقط متن استاشتباه گرفتن collaboration با version controlعدم توجه به sync issuesاستفاده نکردن از examples در API understandingنکته امتحانی مهمدر پاسخ کامل باید این کلیدواژه‌ها باشند:Documentation, Request Description, Collection Description, Example Request, Collaboration, Sharing, Syncing, Workspace, Team API Testing, Contract Understandingنمونه پاسخ کامل کوتاهDocumentation در Postman شامل توضیح Requestها، Collectionها و نمونه‌های واقعی از درخواست و پاسخ است که باعث درک بهتر API و کاهش وابستگی به تیم توسعه می‌شود. Collaboration نیز قابلیت اشتراک‌گذاری و همگام‌سازی Collectionها بین اعضای تیم است که امکان کار گروهی، جلوگیری از اختلاف نسخه و اجرای تست‌های مشترک را فراهم می‌کند.کلیدواژه‌هاDocumentation Request Description Collection Description Example Request Collaboration Sharing Syncing Workspace Team Testing API Contract Postman Team Version ConsistencyDocumentation (مستندسازی API): برای توضیح ساختار و رفتار API به کاربران و تیم استفاده می‌شود.Collaboration (کار تیمی در Postman): برای اشتراک و همگام‌سازی collection بین تیم‌های QA و Development استفاده می‌شود.جمع‌بندی ذهنیDocumentation + Collaboration یعنی:👉 “API قابل فهم + API قابل اشتراک + کار تیمی بدون سردرگمی”

Importing (cURL, OpenAPI/Swagger) in Postman

Nastooh — Fri, 26 Jun 2026 01:10:19 +0330

جمعبندی آزمونی سرفصلImporting چیست؟Importing در Postman یعنی وارد کردن APIها یا Requestها از منابع خارجی به داخل Postman برای تست، مدیریت و اجرای سریعتر.این قابلیت باعث میشود به جای ساخت دستی Requestها، آنها را از منابع استاندارد وارد کنیم.انواع Import در Postman1. Import cURLدر این حالت یک cURL command به Postman تبدیل میشود.مثال:curl -X GET "https://api.com/customers/1" \ -H "Authorization: Bearer token" نتیجه در Postman:Method: GETURL: /customers/1Header: Authorizationکاربرد:تبدیل سریع command به requestDebuggingReproduce API callsتست API بدون نوشتن دستینکته مهم آزمونی:👉 cURL = Raw HTTP Request → Postman = Visual Request2. Import OpenAPI / Swaggerدر این حالت یک API Contract کامل وارد Postman میشود.فرمتها:JSONYAMLمثال ساختار OpenAPI:paths: /customers: get: summary: Get customers در Postman چه اتفاقی میافتد؟تمام endpoints ساخته میشوندmethods (GET, POST, …) اضافه میشوندschema و parameters وارد میشوندdocumentation قابل استفاده میشودکاربرد:تست API بدون نیاز به دستی ساختن requestContract-based testingIntegration با تیم backendکاهش خطای انسانیImport Flow در Postmanمراحل:Import Buttonانتخاب:cURLFile (Swagger JSON/YAML)LinkParseGenerate CollectionReady for Testingنکات مهم آزمونی (L7 → L8)1. Contract-first TestingSwagger → تعریف Contract → تست مستقیم API2. cURL = Real-world Debug Toolسریعبدون UIمناسب troubleshooting3. Swagger Import AdvantageAuto-generated testsConsistency with backendSchema validation base4. Risk in Importingoutdated swagger → false test casesincomplete cURL → missing headers/bodymismatch between spec and implementation5. Testing StrategyBackend Tester باید بررسی کند:آیا Swagger با API واقعی match است؟آیا imported requests قابل اجرا هستند؟آیا schema صحیح آمده؟آیا authentication درست منتقل شده؟خطاهای رایج در آزمونimport ناقص cURL (missing -H / -d)swagger قدیمیmismatch بین endpoint و implementationنبود authentication در importعدم شناخت schema mappingنکته امتحانی مهمدر پاسخ کامل باید این کلیدواژهها دیده شوند:Import, cURL, OpenAPI, Swagger, Contract, Request Generation, Collection, Schema, API Testing, Automationنمونه پاسخ کامل کوتاهImporting in Postman فرآیند وارد کردن APIها از منابع خارجی مانند cURL یا OpenAPI/Swagger به داخل Postman است. با Import cURL، یک HTTP request به صورت مستقیم به Postman تبدیل میشود، در حالی که Import Swagger/OpenAPI یک مجموعه کامل از endpoints و schemaها را بر اساس Contract ایجاد میکند. این قابلیت برای تست سریع، کاهش خطا، و اجرای تستهای مبتنی بر Contract استفاده میشود.کلیدواژههاImporting cURL OpenAPI Swagger Contract Testing API Specification Schema Collection Generation Request Parsing Automation TestingImporting (وارد کردن API به Postman): برای تبدیل منابع خارجی به requestهای قابل تست استفاده میشود.cURL Import (تبدیل command به request): برای debug و اجرای سریع API استفاده میشود.Swagger/OpenAPI Import (وارد کردن Contract کامل API): برای تولید خودکار مجموعه APIها بر اساس specification استفاده میشود.جمعبندی ذهنیImport یعنی:👉 “از دنیای بیرون، API آماده بیار داخل Postman و سریع تست کن”

Exporting cURL of Request (Postman)

Nastooh — Fri, 26 Jun 2026 01:01:45 +0330

جمع‌بندی آزمونی سرفصلcURL چیست؟cURL (Client URL) یک ابزار خط فرمان (CLI) است که برای ارسال درخواست‌های HTTP به API استفاده می‌شود.در Postman می‌توان هر Request را به cURL command تبدیل کرد تا همان درخواست در محیط‌های دیگر (Terminal, CI/CD, Debugging) اجرا شود.Export cURL در Postman چیست؟قابلیتی در Postman است که یک HTTP Request را به شکل دستور قابل اجرا در Terminal تبدیل می‌کند.مثال:curl -X GET "https://api.com/customers/123" \ -H "Authorization: Bearer token" \ -H "Accept: application/json" ساختار cURLیک request cURL معمولاً شامل:Method → GET / POST / PUT / DELETEURLHeadersBodyAuthenticationQuery Paramsمثال کامل cURLcurl -X POST "https://api.com/customers" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer token123" \ -d '{ "name": "Ali", "age": 30 }' کاربردهای Export cURL1. Debuggingبرای بررسی مشکل API خارج از Postman2. Reproducing Requestsاجرای دقیق همان request در:TerminalLinux / Mac / Windows CLI3. Integration with DevOpsاستفاده در:CI/CD pipelinesJenkinsGitHub Actions4. Sharing Requestsارسال سریع request به:DeveloperQASupport team5. Automation Testingاستفاده در اسکریپت‌ها یا تست‌های backendنکات مهم آزمونی (L7 → L8)1. Exact replicationcURL باید دقیقاً:HeadersBodyMethodرا replicate کند2. Security ConcernToken در cURL قابل مشاهده استنباید در public logs ذخیره شود3. Debugging advantageحذف Postman layerبررسی مستقیم API behavior4. Common issueescape کردن JSON اشتباهmissing headerswrong content-typeencoding problems5. Integration use caseتبدیل Postman → cURL → CI/CD pipelineخطاهای رایج در آزمونفراموش کردن Content-Typeارسال body بدون -dاشتباه در quoting JSONmismatch بین Postman و cURLعدم توجه به authentication headerنکته امتحانی مهمدر پاسخ کامل باید این کلیدواژه‌ها دیده شوند:cURL, CLI, HTTP Request, Headers, Body, Debugging, Automation, CI/CD, Reproduction, Terminalنمونه پاسخ کامل کوتاهcURL یک ابزار خط فرمان برای ارسال HTTP request است که در Postman می‌توان هر request را به آن تبدیل کرد. Export cURL برای debugging, automation, CI/CD integration و reproducing requests استفاده می‌شود. این دستور شامل method، URL، headers و body است و امکان اجرای همان request خارج از Postman را در terminal فراهم می‌کند.کلیدواژه‌هاcURL Client URL CLI HTTP Request Headers Body Debugging Automation Testing CI/CD Terminal Request Reproduction Postman ExportcURL (Client URL) (ابزار خط فرمان برای ارسال HTTP request): برای تست و اجرای API در terminal استفاده می‌شود.Export cURL (تبدیل request به command): برای اجرای همان request خارج از Postman استفاده می‌شود.CLI (Command Line Interface) (محیط خط فرمان): محیطی برای اجرای دستورات متنی مانند cURL.Debugging (عیب‌یابی API): برای بررسی رفتار واقعی API بدون Postman استفاده می‌شود.جمع‌بندی ذهنیcURL یعنی:👉 “همان API، بدون UI، مستقیم در خط فرمان”

Postman Variables (local, environment, global, collection) + Precedence + Dynamic Variables-Postman

Nastooh — Fri, 26 Jun 2026 00:48:52 +0330

Variables در Postman چیست؟Variables مقادیر قابل استفاده مجدد هستند که برای جلوگیری از Hardcoding در Requestها استفاده می‌شوند.مثال:{{baseUrl}}/customers {{token}} انواع Variables در Postman1. Global Variablesمتغیرهایی که در تمام Collections و Environments قابل استفاده هستند.ویژگی‌ها:عمومی‌ترین سطحقابل استفاده در کل workspaceمناسب داده‌های مشترکمثال:baseUrl = https://api.com 2. Collection Variablesمتغیرهایی که فقط داخل یک Collection قابل استفاده هستند.ویژگی‌ها:Scope محدود به Collectionمناسب داده‌های مرتبط با یک API سیستممثال:token = abc123 3. Environment Variablesمتغیرهای وابسته به محیط اجرا (Dev / QA / Prod).ویژگی‌ها:تغییر رفتار API در محیط‌های مختلفپرکاربرد در تست واقعیمثال:baseUrl = https://dev.api.com 4. Local Variablesمتغیرهایی که فقط در یک Request یا Script استفاده می‌شوند.ویژگی‌ها:کوتاه‌مدتفقط در runtimeoverride موقتمثال:pm.variables.set("tempToken", "123") Variable Precedence (اولویت متغیرها)وقتی چند variable با یک نام وجود داشته باشد، Postman از این ترتیب استفاده می‌کند:ترتیب اولویت:Local VariableData Variable (Runner)Environment VariableCollection VariableGlobal Variableمثال مهم آزمونی:اگر همه این‌ها وجود داشته باشند:{{baseUrl}} و مقدارها:Global: ACollection: BEnvironment: CLocal: D👉 مقدار نهایی: D (Local)نکته مهم:👉 هرچه scope محدودتر باشد → اولویت بالاتر داردDynamic Variables (متغیرهای پویا)تعریف:Dynamic Variables متغیرهایی هستند که Postman به صورت خودکار مقدار آن‌ها را در زمان اجرا تولید می‌کند.مثال‌های مهم:1. UUID{{$guid}} 2. Random Email{{$randomEmail}} 3. Random Number{{$randomInt}} 4. Current Timestamp{{$timestamp}} 5. Random Name{{$randomFirstName}} کاربرد Dynamic Variablesتست داده‌های تصادفیجلوگیری از duplicate dataتست concurrency scenariosautomation testingload-like simulationنکات مهم آزمونی (L7 → L8)1. Scope Awarenessتستر باید بداند variable در چه سطحی تعریف شده:Global = sharedEnvironment = context-basedCollection = system-specificLocal = runtime only2. Security RiskToken در Global variable خطرناک استباید در Environment یا Secret store باشد3. Debugging Issueاگر مقدار اشتباه بود:مشکل از precedence است نه request4. Automation UsageNewman + CLI از Environment variables استفاده می‌کندCI/CD pipelines به Environment dependency دارند5. Dynamic Data Advantageحذف نیاز به manual inputمناسب regression testingجلوگیری از collision dataخطاهای رایج در آزموناشتباه گرفتن Collection vs Environment variableندانستن precedenceاستفاده از Global برای sensitive dataعدم استفاده از dynamic variables در test datahardcoding به جای variablesنکته امتحانی مهمدر پاسخ کامل باید این کلیدواژه‌ها باشند:Variables, Global, Environment, Collection, Local, Precedence, Scope, Dynamic Variables, Hardcoding, Runtime, CI/CD, Newmanنمونه پاسخ کامل کوتاهدر Postman، Variables برای جلوگیری از hardcoding استفاده می‌شوند و شامل Global, Collection, Environment و Local هستند. ترتیب اولویت آن‌ها به صورت Local > Data > Environment > Collection > Global است. Dynamic Variables نیز مقادیر تصادفی یا زمان‌محور مانند UUID و timestamp را در زمان اجرا تولید می‌کنند و برای تست‌های automation و جلوگیری از داده‌های تکراری استفاده می‌شوند.کلیدواژه‌هاPostman Variables Global Variable Environment Variable Collection Variable Local Variable Variable Precedence Scope Dynamic Variables Hardcoding Runtime Data Newman CI/CD IntegrationGlobal Variable (متغیر عمومی): برای داده‌های مشترک در کل پروژه استفاده می‌شود.Environment Variable (متغیر محیطی): برای مدیریت تنظیمات Dev / QA / Prod استفاده می‌شود.Collection Variable (متغیر سطح کالکشن): فقط داخل یک مجموعه API قابل استفاده است.Local Variable (متغیر محلی): فقط در یک request یا script معتبر است.Variable Precedence (اولویت متغیرها): تعیین می‌کند در صورت تداخل چند variable کدام مقدار استفاده شود.Dynamic Variables (متغیرهای تولیدشده خودکار): برای تولید داده تصادفی یا زمان‌محور در تست استفاده می‌شوند.جمع‌بندی ذهنیVariables یعنی:👉 “کنترل هوشمند داده‌ها در API بدون تکرار و بدون hardcode”

Environments (Postman)

Nastooh — Fri, 26 Jun 2026 00:25:09 +0330

جمع‌بندی آزمونی سرفصلEnvironment در Postman چیست؟Environment مجموعه‌ای از Variables است که برای مدیریت تغییرات بین محیط‌های مختلف تست استفاده می‌شود.به جای hardcode کردن URL یا Token، از Environment استفاده می‌کنیم تا تست‌ها قابل انتقال بین محیط‌ها (Dev / QA / Prod) باشند.ساختار Environmentیک Environment شامل:Variables (Key-Value pairs)Values (Current / Initial)Secrets (Sensitive Data)Base URLsTokensمثال سادهbaseUrl = https://dev.api.com token = abc123 استفاده در request:{{baseUrl}}/customers انواع Environment در Postman1. Development Environmentبرای توسعه‌دهنده‌هاداده‌های تستیURLهای dev2. QA / Testing Environmentبرای تسترهاداده نزدیک به productionمناسب regression testing3. Staging Environmentمشابه productionبرای final validation4. Production Environmentواقعی‌ترین داده‌هابسیار حساسمعمولاً فقط read-only تستVariable Types در Environment1. Initial Valueمقدار پیش‌فرضقابل sync با تیم2. Current Valueمقدار local برای اجرابرای secret ها استفاده می‌شوداستفاده از Environment Variablesدر Postman:{{baseUrl}} {{token}} {{userId}} اهمیت Environment در API Testingجلوگیری از hardcodingتغییر سریع بین محیط‌هاکاهش خطای انسانیافزایش reuse تست‌هامناسب برای CI/CDEnvironment Switchingتستر می‌تواند بین محیط‌ها switch کند:Dev → QA → Staging → Prodبدون تغییر در requestهاEnvironment + Collection IntegrationCollections می‌توانند از Environment variables استفاده کنند:GET {{baseUrl}}/customers/{{customerId}} نکات مهم آزمونی (L7 → L8)1. Environment = Execution ContextEnvironment تعیین می‌کند API روی چه سیستم و داده‌ای اجرا شود.2. No Hardcoding Ruleدر API Testing نباید:URLTokenIDshardcode شوند.3. Security ConcernSensitive data نباید در Initial Value عمومی باشدToken باید در Current Value نگهداری شود4. CI/CD UsageEnvironmentها در:NewmanJenkinsGitHub Actionsبرای اجرای تست در محیط‌های مختلف استفاده می‌شوند.5. Debugging Advantageتغییر سریع baseUrlتست روی چند environment بدون تغییر requestخطاهای رایج در آزموناستفاده از URL ثابت به جای variableعدم تفکیک dev/prod environmentذخیره token در repositoryاشتباه در variable precedenceعدم sync environment بین تیمنکته امتحانی مهمدر پاسخ کامل باید این کلیدواژه‌ها دیده شوند:Environment, Variables, Base URL, Dev / QA / Prod, Current Value, Initial Value, CI/CD, Newman, Hardcoding, Token Managementنمونه پاسخ کامل کوتاهEnvironment در Postman مجموعه‌ای از Variables است که برای مدیریت تنظیمات مختلف مانند Base URL، Token و IDs در محیط‌های مختلف (Dev, QA, Staging, Production) استفاده می‌شود. این قابلیت باعث جلوگیری از hardcoding، افزایش reuse تست‌ها و امکان اجرای تست‌ها در چند محیط بدون تغییر requestها می‌شود. Environmentها در اتوماسیون تست و CI/CD نیز نقش مهمی دارند.کلیدواژه‌هاPostman Environment Variables Base URL Dev Environment QA Environment Staging Production Initial Value Current Value Hardcoding CI/CD Newman Token Management API Testing ContextEnvironment (محیط اجرا): برای مدیریت تنظیمات و متغیرهای تست در محیط‌های مختلف استفاده می‌شود.Variables (متغیرها): برای جلوگیری از hardcoding و افزایش انعطاف تست‌ها استفاده می‌شوند.Base URL (آدرس پایه API): برای تغییر سریع بین محیط‌های مختلف بدون تغییر request استفاده می‌شود.CI/CD (یکپارچگی و استقرار مداوم): برای اجرای خودکار تست‌ها در pipeline استفاده می‌شود.جمع‌بندی ذهنیEnvironment یعنی:👉 “یک API، چند محیط، بدون تغییر در تست‌ها”

Collections and Organizing Requests (Postman)

Nastooh — Thu, 25 Jun 2026 23:17:23 +0330

جمع‌بندی آزمونی سرفصلCollection در Postman چیست؟Collection مجموعه‌ای از درخواست‌های API است که برای سازماندهی، نگهداری و اجرای منظم تست‌ها استفاده می‌شود.در واقع Collection مثل یک Test Suite در API Testing عمل می‌کند.ساختار Collectionیک Collection می‌تواند شامل:Requests (GET, POST, PUT, DELETE…)Folders (برای دسته‌بندی منطقی)VariablesScripts (Pre-request / Tests)DocumentationExamplesاهمیت Collections در API Testingسازماندهی تست‌هااجرای گروهی تست‌هاReusabilityAutomationRegression TestingCollaboration بین تیم‌هاFolder در CollectionFolder برای دسته‌بندی منطقی Requestها استفاده می‌شود.مثال:Customer APIs ├── Create Customer ├── Get Customer ├── Update Customer Collection Runner چیست؟ابزاری در Postman برای اجرای کل یا بخشی از Collection به صورت پشت سر هم.کاربرد:اجرای Regression Testاجرای Smoke Testاجرای batch requestاجرای بخشی از Collectionمی‌توان:فقط یک Collectionیا فقط یک Folder خاصرا اجرا کرد.👉 این قابلیت برای تست‌های ماژولار بسیار مهم است.Environment IntegrationCollections می‌توانند با Environment Variables کار کنند.مثال:{{baseUrl}}/customers کاربرد:تغییر سریع بین Dev / QA / Prodجلوگیری از hardcode شدن URLافزایش انعطاف تست‌هاVariables در Collectionدر Collection می‌توان از Variable استفاده کرد:Collection VariablesEnvironment VariablesGlobal VariablesLocal Variablesمثال:{{token}} Variable Precedence (اولویت‌ها)ترتیب اولویت:Local VariableData Variable (Runner)Environment VariableCollection VariableGlobal VariableData-driven Testingاجرای یک Collection با داده‌های مختلف (CSV / JSON)کاربرد:تست چندین کاربرتست سناریوهای مختلفافزایش coverageChaining Requestsاستفاده از خروجی یک Request در Request بعدی.مثال:Login → گرفتن tokenاستفاده از token در Request بعدی{{token}} Collection Runnerویژگی مهم Postman برای:اجرای sequential requestsاستفاده از data fileاجرای regression suiteRegression Packمجموعه تست‌هایی که برای اطمینان از عدم خراب شدن سیستم استفاده می‌شود.کاربرد:بعد از تغییرات سیستمقبل از releaseSmoke Packمجموعه تست‌های سبک و سریع برای بررسی سلامت سیستم.کاربرد:بررسی سریع deploymentsanity checkExport / Import CollectionExport: ذخیره Collection به JSONImport: وارد کردن Collection از فایل یا Swagger/cURLنکات مهم آزمونی (L7 → L8)1. Collection = Test Suiteدر سطح سازمانی برای مدیریت API test cases2. Execution ModelsSingle request executionFolder executionFull collection executionData-driven execution3. Automation LayerCollection RunnerNewman (CLI)CI/CD integration4. Test Design StrategyRegression Pack → کاملSmoke Pack → سریعData-driven → coverage بالا5. Real-world Testing FlowSetup EnvironmentRun Login → get tokenChain requestsValidate responseRun regression suiteخطاهای رایج در آزمونعدم تفکیک Collection و Folderاستفاده نکردن از environmentعدم درک variable precedenceنداشتن chaining logicعدم استفاده از data-driven testingاجرای تست بدون regression strategyنکته امتحانی مهمدر پاسخ کامل باید این کلیدواژه‌ها دیده شوند:Collection, Folder, Runner, Environment, Variables, Chaining, Data-driven Testing, Regression Pack, Smoke Pack, Automation, Newmanنمونه پاسخ کامل کوتاهCollections in Postman مجموعه‌ای از API requests هستند که برای سازماندهی، اجرای گروهی و اتوماسیون تست‌ها استفاده می‌شوند. Collections شامل Requestها، Folderها، Variables و Scripts هستند و می‌توان آن‌ها را از طریق Collection Runner یا Newman اجرا کرد. همچنین امکان Data-driven Testing، Chaining Requests و تعریف Regression Pack و Smoke Pack برای مدیریت تست‌ها وجود دارد.کلیدواژه‌هاPostman Collection Folder Collection Runner Environment Variables Variable Precedence Data-driven Testing Chaining Requests Regression Pack Smoke Pack Automation Newman Test Suite API Testing StrategyCollection (مجموعه‌ای از API requests): برای سازماندهی و اجرای گروهی تست‌ها استفاده می‌شود.Folder (دسته‌بندی داخل Collection): برای گروه‌بندی منطقی درخواست‌ها استفاده می‌شود.Collection Runner (اجرای گروهی تست‌ها): برای اجرای sequential test cases و regression testing استفاده می‌شود.Environment (محیط اجرا): برای مدیریت متغیرها در محیط‌های مختلف مثل Dev و Prod استفاده می‌شود.Variables (متغیرها): برای جلوگیری از hardcode و افزایش انعطاف تست‌ها استفاده می‌شوند.Data-driven Testing (اجرای تست با داده‌های مختلف): برای افزایش coverage و تست سناریوهای متعدد استفاده می‌شود.Chaining Requests (وابستگی بین درخواست‌ها): استفاده از خروجی یک request در request بعدی.Regression Pack (مجموعه تست کامل سیستم): برای اطمینان از عدم شکست سیستم بعد از تغییرات استفاده می‌شود.Smoke Pack (تست سریع سلامت سیستم): برای بررسی سریع deploy یا sanity check استفاده می‌شود.جمع‌بندی ذهنیCollections یعنی:👉 “مدیریت حرفه‌ای تست‌ها + اجرای قابل اتوماسیون + آماده‌سازی برای پروژه واقعی”

Postman - Content Types of Request Body (JSON, XML, form-data, x-www-form-urlencoded, multipart/form-data)

Nastooh — Thu, 25 Jun 2026 23:09:14 +0330

Content Type of Body چیست؟Content-Type (در Body) مشخص می‌کند داده داخل HTTP Request Body با چه ساختاری به سرور ارسال شده است.Server بر اساس این مقدار تصمیم می‌گیرد چگونه داده را Parse و پردازش کند.اگر Content-Type اشتباه باشد → معمولاً باعث Contract Mismatch یا خطای 415 Unsupported Media Type می‌شود.انواع رایج Body Content Typesraw JSON (application/json)فرمت استاندارد و مدرن برای APIهای REST.ویژگی‌ها:ساختار Key-Valueخوانا و سبکمناسب APIهای مدرنقابل استفاده در CRUDمثال:{ "name": "Ali", "age": 30 } کاربرد:Create / UpdateREST APIهاMicroservicesXML (application/xml)فرمت قدیمی‌تر با ساختار Tag-based.ویژگی‌ها:سنگین‌تر از JSONدارای تگ‌های nestedپیچیده‌تر در parsingمثال: Ali 30 کاربرد:Legacy systemsEnterprise integrationsسیستم‌های بانکی قدیمیx-www-form-urlencodedفرمت ساده key-value در Body.ویژگی‌ها:داده به شکل query-like ارسال می‌شودفقط متن (no file)encode شدهمثال:username=ali&password=123 کاربرد:Login formsToken requestفرم‌های سادهform-dataفرمت multipart ساده برای ارسال داده + فایل.ویژگی‌ها:Key-valueقابلیت ارسال فایلهر part جداگانه ارسال می‌شودمثال:name: Alifile: image.jpgکاربرد:Upload imageUpload documentForms with filemultipart/form-dataنسخه کامل و استاندارد برای ارسال چند بخش مختلف.ویژگی‌ها:هر part جداگانه با boundaryپشتیبانی از فایل + داده همزمانبسیار رایج در uploadمثال:--boundary Content-Disposition: form-data; name="file" (binary) کاربرد:File uploadComplex formsMulti-part data submissionتفاوت مهم آزمونینکات مهم تستی (L7 → L8)1. Contract Mismatchاگر Content-Type اشتباه باشد:Server نمی‌تواند parse کندمعمولاً → 400 / 4152. Security RiskXML → ممکن است XXE attack داشته باشدform-data → file injection riskJSON → injection via parsing errors3. Validation BehaviorMissing required fields → 400Wrong type → 400Wrong Content-Type → 4154. API Design RuleREST → JSON preferredfile upload → multipart/form-datalogin → x-www-form-urlencoded یا JSON (modern)5. Performance ConsiderationJSON سبک‌تر از XMLXML parsing سنگین‌ترmultipart overhead بیشتر داردخطاهای رایج در آزمونارسال JSON با Content-Type اشتباهاستفاده از x-www-form-urlencoded برای file uploadاستفاده از XML بدون نیاز واقعیعدم تعریف boundary در multipartmismatch بین Swagger و request bodyنکته امتحانی مهمدر پاسخ کامل باید این کلیدواژه‌ها دیده شوند:Content-Type, Request Body, JSON, XML, form-data, multipart/form-data, x-www-form-urlencoded, Contract, Parsing, Validation, 415 Unsupported Media Typeنمونه پاسخ کامل کوتاهContent Types of Body مشخص می‌کند داده داخل Request Body با چه ساختاری به Server ارسال می‌شود و چگونه باید parse شود. رایج‌ترین انواع شامل JSON (استاندارد REST)، XML (سیستم‌های legacy)، x-www-form-urlencoded (فرم‌های ساده)، form-data (ارسال فایل ساده) و multipart/form-data (ارسال فایل و داده پیچیده) هستند. انتخاب Content-Type صحیح برای جلوگیری از Contract Mismatch و خطاهایی مانند 400 Bad Request و 415 Unsupported Media Type ضروری است.کلیدواژه‌هاContent-Type Request Body JSON XML form-data multipart/form-data x-www-form-urlencoded Parsing Contract Validation File Upload REST API Legacy Systems 415 ErrorJSON (JavaScript Object Notation) (فرمت سبک و استاندارد API): برای انتقال داده در REST APIهای مدرن استفاده می‌شود.XML (Extensible Markup Language) (فرمت ساختاری مبتنی بر تگ): در سیستم‌های قدیمی و enterprise استفاده می‌شود.x-www-form-urlencoded (فرمت ساده key-value در body): برای فرم‌های ساده و login استفاده می‌شود.form-data (فرمت multipart ساده برای ارسال فایل): برای آپلود فایل و فرم‌های همراه با فایل استفاده می‌شود.multipart/form-data (فرمت پیشرفته چندبخشی): برای ارسال همزمان فایل و داده‌های پیچیده استفاده می‌شود.جمع‌بندی ذهنیContent-Type یعنی:👉 “سرور با این داده دقیقاً چطور رفتار کند؟”

Postman- Contents of HTTP Headers (Content-Type, Accept, Authorization, Custom Headers)

Nastooh — Thu, 25 Jun 2026 22:51:34 +0330

جمع‌بندی آزمونی سرفصلHTTP Headers چیست؟Headers بخشی از HTTP Request / Response هستند که اطلاعات کنترلی (Metadata) درباره ارتباط بین Client و Server را منتقل می‌کنند.Headers داده اصلی نیستند، بلکه نحوه پردازش، امنیت، فرمت و رفتار API را کنترل می‌کنند.دسته‌بندی مهم Headers در APIContent-Typeمشخص می‌کند داده داخل Request Body چه فرمی دارد.مثال:Content-Type: application/json کاربرد:تعیین فرمت داده ارسالیکنترل parsing در Serverجلوگیری از mismatch در contractفرمت‌های رایج:application/jsonapplication/xmlmultipart/form-datax-www-form-urlencodedAcceptمشخص می‌کند Client چه نوع Response Format را انتظار دارد.مثال:Accept: application/json کاربرد:تعیین نوع خروجی APInegotiation بین Client و Serverکنترل نسخه response formatAuthorizationبرای احراز هویت (Authentication) و سطح دسترسی (Authorization) استفاده می‌شود.مثال:Authorization: Bearer eyJhbGciOi... کاربرد:کنترل دسترسی به APIجلوگیری از دسترسی غیرمجازارسال Token (JWT / OAuth2)انواع رایج:Bearer TokenBasic AuthAPI Key (گاهی در header)Custom HeadersHeaderهای سفارشی که توسط سیستم یا بیزینس تعریف می‌شوند.مثال:X-Correlation-Id: 12345 X-Client-Version: 2.1 X-Request-Source: mobile کاربرد:Tracking درخواست‌ها (Traceability)DebuggingLoggingFeature FlagAnalyticsIdempotency-Key (در سیستم‌های مالی)تفاوت مهم آزمونی HeadersHeaderنقش اصلیContent-Typeفرمت Request BodyAcceptفرمت ResponseAuthorizationامنیت و دسترسیCustom Headersکنترل‌های بیزینسی و سیستمینکات مهم تستی (L7 → L8)1. Contract Enforcementاگر Content-Type اشتباه باشد → معمولاً 415 Unsupported Media Typeاگر Accept پشتیبانی نشود → ممکن است 406 Not Acceptable2. Security Validationنبود Authorization → باید 401 UnauthorizedToken نامعتبر → 403 Forbidden3. Header Injection RiskCustom Headers اگر validate نشوند می‌توانند:باعث bypass شونداطلاعات حساس leak کنندbehavior سیستم را تغییر دهند4. Content NegotiationAccept و Content-Type باید با هم سازگار باشندmismatch → contract failure5. Idempotency & ReliabilityCustom headers مثل:Idempotency-Keyبرای جلوگیری از duplicate transaction استفاده می‌شوند.خطاهای رایج در APIMissing Content-TypeUnsupported Media Type (415)Invalid Accept header (406)Missing Authorization (401)Invalid Token (403)Custom header not validatedContract mismatch between request/response formatنکته مهم آزمونیدر پاسخ کامل باید این کلیدواژه‌ها وجود داشته باشد:Headers, Metadata, Content-Type, Accept, Authorization, Custom Headers, Authentication, Authorization, Content Negotiation, Contract, Token, Bearer, Securityنمونه پاسخ کامل کوتاهHTTP Headers اطلاعات متادیتا در درخواست و پاسخ هستند که رفتار API را کنترل می‌کنند. Content-Type فرمت داده ارسالی در Request Body را مشخص می‌کند، در حالی که Accept فرمت Response مورد انتظار را تعیین می‌کند. Authorization برای احراز هویت و کنترل دسترسی استفاده می‌شود. همچنین Custom Headers برای نیازهای بیزینسی مانند tracing، logging و کنترل‌های خاص سیستم استفاده می‌شوند. عدم تطابق در Headers می‌تواند باعث Contract Mismatch و خطاهایی مانند 401, 403, 415, 406 شود.کلیدواژه‌هاHTTP Headers Content-Type Accept Authorization Bearer Token Authentication Authorization Custom Headers Metadata Content Negotiation Contract Token Validation API Security Request Validation Response FormatContent-Type (تعیین فرمت داده ارسالی در Request Body): برای مشخص کردن نوع داده مثل JSON یا XML استفاده می‌شود.Accept (تعیین فرمت Response مورد انتظار): برای negotiation بین Client و Server استفاده می‌شود.Authorization (ارسال اطلاعات احراز هویت): برای کنترل دسترسی و امنیت API استفاده می‌شود.Custom Headers (Headerهای سفارشی): برای tracking، logging و نیازهای خاص سیستم استفاده می‌شوند.Content Negotiation (تطبیق فرمت Request و Response): فرآیند توافق بین Client و Server برای نوع داده.Bearer Token (نوعی از توکن احراز هویت): معمول‌ترین روش ارسال JWT در Authorization header.Contract (توافق بین Client و Server): تعیین می‌کند Headers و Body باید چه ساختاری داشته باشند.جمع‌بندی ذهنیHeaders = کنترل + امنیت + فرمت + رفتارنه داده اصلی، بلکه “قوانین بازی API”

Postman - Endpoint Structure (HTTP/HTTPS, URL vs URI)

Nastooh — Thu, 25 Jun 2026 22:35:19 +0330

جمع‌بندی آزمونی سرفصلEndpoint چیست؟Endpoint نقطه دسترسی یک API است که Client از طریق آن با Server ارتباط برقرار می‌کند.Endpoint معمولاً شامل Protocol + Domain + Path + Parameters است و نشان می‌دهد درخواست دقیقاً به کدام Resource ارسال می‌شود.مثال:https://api.bank.com/v1/customers/12345 HTTP vs HTTPSHTTP (HyperText Transfer Protocol)یک پروتکل برای انتقال داده بین Client و Server است.ویژگی‌ها:داده‌ها بدون Encryption منتقل می‌شوندامنیت پایینمناسب محیط‌های غیرحساس (تست / داخلی)مثال:http://example.com/api/customers HTTPS (HTTP Secure)نسخه امن HTTP است که از SSL/TLS Encryption استفاده می‌کند.ویژگی‌ها:داده‌ها Encrypted هستندجلوگیری از Man-in-the-Middle Attackمناسب سیستم‌های حساس (بانکی، مالی، لاگین)مثال:https://api.bank.com/customers تفاوت مهم آزمونی HTTP vs HTTPSURL vs URIURI (Uniform Resource Identifier)یک شناسه کلی برای Resource است.URI می‌تواند:Location (URL)یا Name (URN)باشد.URL (Uniform Resource Locator)نوعی از URI است که محل دقیق Resource را مشخص می‌کند.رابطه مهم آزمونی:👉 URL ⊂ URIیعنی:هر URL یک URI استاما هر URI الزاماً URL نیستمثال ساده:URI:customers/12345 URL:https://api.bank.com/customers/12345 تفاوت URL و URIEndpoint Structure (ساختار Endpoint)یک Endpoint کامل معمولاً شامل این بخش‌هاست:https://api.example.com:443/v1/customers/123?active=true اجزا:1. Protocolhttps نوع ارتباط (HTTP یا HTTPS)2. Domainapi.example.com آدرس سرور3. Port (اختیاری)443 پورت ارتباط4. Path/ v1 / customers / 123 مسیر Resource5. Query Parameter?active=true فیلتر یا کنترل رفتار درخواستنکات مهم آزمونی (L7 → L8)1. Endpoint = Resource LocatorEndpoint باید:یک Resource را مشخص کندقابل فهم باشدRESTful باشد2. REST Design Ruleاستفاده از noun نه verb:❌ /getCustomer✅ /customers/1233. HTTPS اهمیت امنیتیدر APIهای مالی:استفاده از HTTP = ریسک شدیدHTTPS = استاندارد الزامی4. URI vs URL در تستBackend Tester باید بداند:Swagger معمولاً URL را نمایش می‌دهدContract ممکن است URI-level design داشته باشدتست باید URL واقعی را validate کند5. Common Failureهااستفاده از HTTP به جای HTTPSEndpoint اشتباه (404)Path mismatchQuery injectionIncorrect routingBroken versioning in path (/v1/ vs /v2/)نکته کلیدی آزمونیدر پاسخ کامل باید این کلیدواژه‌ها دیده شوند:Endpoint, HTTP, HTTPS, SSL/TLS, URL, URI, Resource, Path, Query Parameter, Domain, Protocol, Port, RESTful Designنمونه پاسخ کامل کوتاهEndpoint آدرس دسترسی به یک Resource در API است که شامل Protocol (HTTP/HTTPS)، Domain، Path و Parameters می‌باشد. HTTP پروتکل بدون امنیت است، در حالی که HTTPS با استفاده از SSL/TLS داده‌ها را رمزنگاری می‌کند. URL نوعی از URI است که محل دقیق Resource را مشخص می‌کند، در حالی که URI یک شناسه کلی برای Resource است. در طراحی API باید از ساختار RESTful و استفاده از HTTPS برای امنیت و از URLهای استاندارد برای دسترسی به منابع استفاده شود.کلیدواژه‌هاEndpoint HTTP HTTPS SSL/TLS URL URI Resource Path Query Parameter Domain Port RESTful API API Structure Secure Communication

postman - HTTP Verbs (GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS)

Nastooh — Thu, 25 Jun 2026 22:21:06 +0330

HTTP Verbs چیست؟HTTP Verbs (Methods) تعیین می‌کنند که یک Client روی یک Resource چه عملیاتی انجام می‌دهد.این متدها بخش اصلی طراحی REST API هستند و رفتار سیستم را از نظر Create / Read / Update / Delete (CRUD) مشخص می‌کنند.GETکاربرد:دریافت داده از سرور بدون تغییر در state سیستم.ویژگی‌ها:Safe (تغییری در دیتا ایجاد نمی‌کند)Idempotent (چند بار اجرا → نتیجه یکسان)قابل Cacheمثال:GET /customers/123 POSTکاربرد:ایجاد یک Resource جدید یا اجرای یک عملیات غیر-idempotent.ویژگی‌ها:غیر Idempotentمعمولاً باعث ایجاد رکورد جدیدقابل Cache نیستمثال:POST /customers PUTکاربرد:آپدیت کامل یک Resource یا جایگزینی کامل آن.ویژگی‌ها:Idempotentاگر چند بار ارسال شود → نتیجه یکسانکل resource جایگزین می‌شودمثال:PUT /customers/123 PATCHکاربرد:آپدیت جزئی یک Resource.ویژگی‌ها:معمولاً Partial Updateممکن است idempotent باشد (بسته به طراحی)فقط بخشی از داده تغییر می‌کندمثال:PATCH /customers/123 DELETEکاربرد:حذف یک Resource.ویژگی‌ها:Idempotentچند بار حذف → نتیجه نهایی یکسان (resource حذف شده)مثال:DELETE /customers/123 HEADکاربرد:مشابه GET ولی بدون Body Response.ویژگی‌ها:فقط Headers برمی‌گرددبرای بررسی وجود resource یا metadataمناسب برای performance optimizationمثال:HEAD /customers/123 OPTIONSکاربرد:مشخص کردن capabilityهای یک endpoint.ویژگی‌ها:برمی‌گرداند:Allowed MethodsCORS policyبرای preflight request در browser استفاده می‌شودمثال:OPTIONS /customers مقایسه آزمونی مهمنکات امتحانی مهم (L7 → L8)1. Safe vs IdempotentSafe → تغییر در data ندارد (GET, HEAD)Idempotent → چند بار اجرا نتیجه یکسان دارد (GET, PUT, DELETE)2. اشتباه رایج طراحی APIاستفاده از GET برای عملیات تغییر دیتا ❌استفاده از POST برای update بدون دلیل ❌عدم رعایت idempotency در PUT ❌3. Status Code ارتباطی مهمGET → 200POST → 201 CreatedPUT → 200 / 204PATCH → 200 / 204DELETE → 204 No ContentOPTIONS → 200HEAD → 200 (بدون body)4. تستر باید چه چیزهایی را بررسی کند؟آیا method درست انتخاب شده؟آیا idempotency رعایت شده؟آیا GET باعث تغییر state نشده؟آیا DELETE دوبار اجرا شود رفتار درست دارد؟آیا PATCH partial update درست انجام می‌دهد؟آیا OPTIONS درست CORS را برمی‌گرداند؟آیا HEAD همان resource را بدون body پاسخ می‌دهد؟5. دید معماری (L8 نکته مهم)GET برای caching و performancePOST برای command-based actionsPUT برای deterministic replacementPATCH برای partial mutationDELETE برای state removalکلیدواژه‌هاHTTP Methods REST Verb CRUD Safe Method Idempotent GET POST PUT PATCH DELETE HEAD OPTIONS Cacheable Resource State Change API Design CORS Preflight RequestHTTP Verbs (متدهای تعیین‌کننده نوع عملیات روی Resource): برای تعریف رفتار API در معماری REST استفاده می‌شوند.GET (دریافت داده بدون تغییر state): برای خواندن اطلاعات و caching استفاده می‌شود و Safe و Idempotent است.POST (ایجاد Resource یا اجرای عملیات): برای ساخت داده جدید استفاده می‌شود و معمولاً Idempotent نیست.PUT (جایگزینی کامل Resource): برای آپدیت کامل استفاده می‌شود و Idempotent است.PATCH (آپدیت جزئی Resource): برای تغییر بخشی از داده استفاده می‌شود و معمولاً Partial Update محسوب می‌شود.DELETE (حذف Resource): برای حذف داده استفاده می‌شود و Idempotent است.HEAD (دریافت فقط Header): برای بررسی وجود Resource بدون دریافت Body استفاده می‌شود.OPTIONS (بررسی قابلیت‌های API): برای CORS و دریافت Allowed Methods استفاده می‌شود.تگ‌ها#APITesting#HTTPMethods#RESTAPI#BackendTesting#APIDesign

Postman -All Types of Parameters (Query, Path, Header, Body, Form, Cookie)

Nastooh — Thu, 25 Jun 2026 19:08:07 +0330

Parameter چیست؟در Postman / API Testing، Parameter داده‌ای است که Client برای کنترل رفتار API Request به Server ارسال می‌کند. این پارامترها تعیین می‌کنند API روی چه داده‌ای کار کند، چه فیلترهایی اعمال شود و چه خروجی برگردد.انواع Parameters در APIPath Parameterپارامتری که داخل URL Path قرار می‌گیرد و معمولاً برای مشخص کردن یک Resource مشخص استفاده می‌شود.مثال:GET /customers/12345 در اینجا 12345 یک Path Parameter است.کاربرد:دریافت یک رکورد خاص (Get By ID)حذف یا آپدیت یک Resource مشخصQuery Parameterپارامتری که بعد از ? در URL می‌آید و برای Filtering / Searching / Sorting استفاده می‌شود.مثال:GET /customers?status=ACTIVE&city=Tehran کاربرد:فیلتر کردن دادهجستجوpagination (limit, offset)sortingHeader Parameterپارامترهایی که در HTTP Header ارسال می‌شوند و بیشتر برای Metadata / Security / Control استفاده می‌شوند.مثال:Authorization: Bearer token123 Content-Type: application/json Accept: application/json کاربرد:AuthenticationAuthorizationتعیین فرمت دادهکنترل رفتار APIRequest Body Parameterداده‌ای که داخل Body درخواست ارسال می‌شود (معمولاً در POST/PUT/PATCH).مثال:{ "firstName": "Ali", "lastName": "Ahmadi" } کاربرد:ایجاد داده (Create)ویرایش داده (Update)ارسال payloadهای پیچیدهForm Data Parameterپارامترهایی که به صورت فرم ارسال می‌شوند و می‌توانند شامل فایل هم باشند.مثال:key-value pairsfile uploadکاربرد:آپلود فایلارسال فرم‌های HTMLارسال داده همراه فایلx-www-form-urlencodedفرم ساده به شکل key=value که در body ارسال می‌شود.مثال:username=ali&password=123 کاربرد:LoginToken requestفرم‌های ساده بدون فایلCookie Parameterپارامترهایی که در Cookie مرورگر یا client ذخیره می‌شوند و همراه request ارسال می‌شوند.مثال:Cookie: sessionId=abc123 کاربرد:Session ManagementAuthentication stateTrackingمقایسه سریع انواع ParametersPath → مشخص کردن Resource (ID-based)Query → فیلتر و جستجوHeader → امنیت و metadataBody → داده اصلی عملیاتForm-data → فایل + دادهx-www-form-urlencoded → فرم سادهCookie → session و stateنکات مهم تستی (Exam Focus)در Backend/API Testing باید بررسی شود:آیا Path Parameter اجباری درست validate می‌شود؟آیا Query Parameter باعث تغییر درست در نتیجه می‌شود؟آیا Missing Parameter باعث 400 می‌شود؟آیا Header Authorization درست enforce شده؟آیا Body Schema مطابق Contract است؟آیا File Upload در form-data درست کار می‌کند؟آیا Cookie-based session قابل bypass نیست؟خطاهای رایجMissing Path Param → 404Invalid Query Param → 400Missing Authorization Header → 401Invalid Token → 403Invalid Body Schema → 400Unsupported Content-Type → 415نکته امتحانی مهمدر پاسخ باید این کلیدواژه‌ها دیده شوند:Path Parameter, Query Parameter, Header, Body, Form-data, x-www-form-urlencoded, Cookie, Authentication, Filtering, Resource Identification, Request Payloadنمونه پاسخ کامل کوتاهدر API Testing پارامترها شامل Path Parameter برای شناسایی Resource، Query Parameter برای فیلتر و جستجو، Header Parameter برای کنترل و امنیت، و Body Parameter برای ارسال داده اصلی هستند. همچنین Form-data برای ارسال فایل، x-www-form-urlencoded برای فرم‌های ساده و Cookie برای مدیریت session استفاده می‌شود. هر نوع پارامتر نقش خاصی در Request دارد و باید از نظر validation، contract و security تست شود.کلیدواژه‌هاPath Parameter Query Parameter Header Parameter Request Body Form-data x-www-form-urlencoded Cookie Authentication Authorization Session Management Filtering Resource Identification Payload HTTP Request Structure API Contractتوضیح کوتاه پستمرور فشرده‌ی انواع API Parameters در Postman شامل Path, Query, Header, Body, Form-data, Cookie و نقش آن‌ها در طراحی و تست API.تگ‌ها#APITesting#Postman#APIParameters#BackendTesting#RESTAPI

API -Schema Validation of Request / Response Body (OpenAPI, JSON Schema)

Nastooh — Thu, 25 Jun 2026 18:30:48 +0330

Schema Validation چیست؟Schema Validation یعنی بررسی اینکه Request Body یا Response Body دقیقاً مطابق ساختار (Schema) تعریف‌شده در Contract باشد.Schema مشخص می‌کند چه فیلدهایی وجود دارند، نوع داده هر فیلد چیست، کدام فیلدها Required هستند، چه محدودیت‌هایی دارند و چه مقادیر مجازی قابل قبول است.در تست API، فقط بررسی Status Code کافی نیست؛ بلکه باید اطمینان حاصل شود که Schema نیز کاملاً رعایت شده است.Schema چیست؟Schema یک قرارداد ساختاری (Structural Contract) بین Client و Server است که مشخص می‌کند:چه فیلدهایی باید وجود داشته باشند.نوع هر فیلد چیست.کدام فیلدها اجباری (Required) هستند.مقدار مجاز هر فیلد چیست.ساختار Objectها و Arrayها چگونه است.مثال:{ "customerId": 123, "firstName": "Ali", "isActive": true } در Schema ممکن است تعریف شود:customerId → IntegerfirstName → StringisActive → Booleanاگر API مقدار زیر را برگرداند:{ "customerId": "123" } از نظر Schema Validation خطاست؛ چون Integer به String تبدیل شده است.Request Schema Validationدر Request Validation بررسی می‌شود که داده ارسالی Client مطابق Schema باشد.نمونه مواردی که باید بررسی شوند:وجود تمام Required Fieldsنوع صحیح داده (Type Validation)طول رشته (MinLength / MaxLength)بازه عدد (Minimum / Maximum)فرمت (Format) مانند email یا dateمقدارهای مجاز (Enum)ساختار Object و Arrayاگر Request با Schema مطابقت نداشته باشد، معمولاً API باید 400 Bad Request برگرداند.Response Schema Validationدر Response Validation بررسی می‌شود که خروجی API دقیقاً مطابق Contract باشد.نمونه موارد:همه فیلدهای مورد انتظار وجود داشته باشند.نوع داده‌ها صحیح باشد.فیلد اضافه یا حذف نشده باشد.ساختار Response تغییر نکرده باشد.Nested Objectها صحیح باشند.OpenAPI SpecificationOpenAPI Specification (OAS) استاندارد مستندسازی API است که Contract کامل API را تعریف می‌کند.در OpenAPI مشخص می‌شود:PathsHTTP MethodsParametersHeadersRequest BodyResponseSchemasStatus CodesAuthenticationدر تست API، OpenAPI یکی از مهم‌ترین Test Basisها محسوب می‌شود.JSON SchemaJSON Schema استانداردی برای تعریف ساختار فایل‌های JSON است.به کمک آن می‌توان مشخص کرد:نوع دادهRequired بودنحداقل و حداکثرPatternEnumObjectArrayنمونه:{ "type": "object", "required": ["customerId","firstName"], "properties": { "customerId": { "type": "integer" }, "firstName": { "type": "string" } } } تفاوت Schema Validation و Business ValidationSchema Validation بررسی می‌کند داده از نظر ساختاری صحیح باشد.مثلاً:{ "age": 25 } از نظر Schema صحیح است چون Integer است.اما اگر Business Rule بگوید:سن مشتری باید حداقل 18 سال باشد.آن‌وقت بررسی این شرط دیگر Business Validation است، نه Schema Validation.چه چیزهایی در Schema Validation بررسی می‌شوند؟Required Fieldsمثلاً:{ "required": ["firstName","nationalCode"] } اگر nationalCode ارسال نشود:400 Bad Request Type Validationدرست:{ "amount": 500 } اشتباه:{ "amount": "500" } Format Validationمثلاً:{ "email":"ali@test.com" } صحیح است.ولی:{ "email":"alitest" } در صورت تعریف format=email نامعتبر است.Enum Validationمثلاً:status: ACTIVE INACTIVE BLOCKED اگر ارسال شود:{ "status":"UNKNOWN" } باید خطا برگردد.Array Validationبررسی می‌شود:نوع اعضاتعداد اعضاEmpty بودنNested ObjectهاAdditional Propertiesگاهی Schema مشخص می‌کند:additionalProperties:false در این صورت:{ "firstName":"Ali", "age":30 } اگر age در Schema تعریف نشده باشد، Request باید رد شود.Contract Validationدر تست حرفه‌ای فقط Body بررسی نمی‌شود؛ بلکه باید بررسی کنیم:SchemaHeadersStatus CodesContent-TypeRequired HeadersAuthenticationResponse Structureهمگی مطابق Contract باشند.Schema Evolutionدر نسخه‌های جدید API ممکن است Schema تغییر کند.مثلاً:نسخه اول:{ "firstName":"Ali" } نسخه دوم:{ "firstName":"Ali", "mobile":"0912..." } اگر mobile اختیاری باشد، Breaking Change نیست.اما اگر:firstName حذف شود، معمولاً Breaking Change است.Failureهای رایج SchemaMissing Required FieldWrong Data TypeInvalid EnumInvalid FormatMissing PropertyUnexpected PropertyNested Schema ErrorArray Type ErrorNullable ErrorContract Mismatchتست‌های مهمBackend Tester باید بررسی کند:تمام Required FieldهاType ValidationEnum ValidationFormat ValidationAdditional PropertiesNested ObjectsArraysNullable FieldsEmpty ObjectEmpty ArrayMissing Response FieldUnexpected Response Fieldاهمیت این سرفصل برای Backend TesterBackend Tester باید بتواند:OpenAPI / Swagger را به‌عنوان Test Basis تحلیل کند.Request Schema و Response Schema را اعتبارسنجی کند.تفاوت Schema Validation و Business Validation را بداند.تغییرات Schema را از نظر Backward Compatibility بررسی کند.Failureهای ناشی از Contract Mismatch را تشخیص دهد.مطمئن شود Response دقیقاً مطابق Contract تولید شده است.نکته امتحانی مهمدر پاسخ امتحانی فقط نگویید:Schema Validation یعنی بررسی ساختار JSON.پاسخ کامل باید این کلیدواژه‌ها را داشته باشد:Contract, OpenAPI Specification, JSON Schema, Request Validation, Response Validation, Required Fields, Type Validation, Format Validation, Enum, Additional Properties, Contract Mismatch, Schema Evolution, Backward Compatibilityنمونه پاسخ کامل کوتاهSchema Validation فرآیند بررسی تطابق Request Body و Response Body با Contract تعریف‌شده در OpenAPI Specification یا JSON Schema است. در این فرآیند مواردی مانند Required Fields، Data Type، Format، Enum، Nested Object، Array Structure و Additional Properties بررسی می‌شوند. تفاوت مهم آن با Business Validation این است که Schema فقط ساختار و نوع داده را کنترل می‌کند، در حالی که Business Validation قوانین کسب‌وکار را بررسی می‌کند. Backend Tester باید علاوه بر Status Code، تطابق کامل Schema با Contract و عدم وجود Contract Mismatch را نیز اعتبارسنجی کند.کلیدواژه‌هاSchema Validation Request Schema Response Schema JSON Schema OpenAPI Specification Swagger Contract Contract Validation Required Fields Type Validation Format Validation Enum Validation Additional Properties Nested Object Array Validation Nullable Schema Evolution Contract Mismatch Business Validation Backward CompatibilitySchema Validation (اعتبارسنجی ساختار Request یا Response): برای بررسی تطابق داده با Contract و جلوگیری از ناسازگاری بین Client و Server استفاده می‌شود.Request Schema (ساختار مورد انتظار Request Body): نوع داده، Required بودن، Format و سایر محدودیت‌های ورودی را مشخص می‌کند.Response Schema (ساختار مورد انتظار Response Body): مشخص می‌کند Response باید چه فیلدها و چه نوع داده‌ای داشته باشد.JSON Schema (استاندارد تعریف ساختار JSON): برای تعریف نوع داده، Required Fields، Enum، Pattern و سایر محدودیت‌های ساختاری استفاده می‌شود.OpenAPI Specification (استاندارد مستندسازی API): شامل Contract کامل API شامل Paths، Methods، Schemas، Responses و Authentication است.Swagger (ابزار نمایش و تست OpenAPI): برای مشاهده و اعتبارسنجی Contract و اجرای تست‌های API استفاده می‌شود.Contract (توافق بین Client و Server): رفتار، ساختار و قوانین تبادل داده را مشخص می‌کند.Contract Validation (بررسی تطابق API با Contract): برای اطمینان از رعایت Schema، Status Code، Headers و سایر اجزای API انجام می‌شود.Required Fields (فیلدهای اجباری): فیلدهایی که نبودن آن‌ها باید باعث خطای اعتبارسنجی شود.Type Validation (بررسی نوع داده): کنترل می‌کند مقدار ارسال‌شده از نوع صحیح مانند String، Integer یا Boolean باشد.Format Validation (اعتبارسنجی قالب داده): برای بررسی قالب‌هایی مانند Email، Date، UUID و URI استفاده می‌شود.Enum Validation (بررسی مقادیر مجاز): اطمینان می‌دهد مقدار فقط یکی از گزینه‌های تعریف‌شده باشد.Additional Properties (فیلدهای اضافی خارج از Schema): در صورت ممنوع بودن، وجود آن‌ها باید باعث رد شدن Request شود.Nested Object (شیء تو در تو): برای اعتبارسنجی ساختارهای چندسطحی در Request یا Response استفاده می‌شود.Array Validation (اعتبارسنجی آرایه): نوع اعضا، تعداد و ساختار Array را بررسی می‌کند.Nullable (قابل Null بودن فیلد): مشخص می‌کند یک فیلد مجاز است مقدار Null داشته باشد یا خیر.Schema Evolution (تغییر تدریجی Schema بین نسخه‌های API): برای مدیریت تغییرات بدون ایجاد Breaking Change استفاده می‌شود.Contract Mismatch (عدم تطابق رفتار واقعی API با Contract): یکی از رایج‌ترین علت‌های Failure در تست API است.Business Validation (اعتبارسنجی قوانین کسب‌وکار): قوانین منطقی سیستم را بررسی می‌کند و با Schema Validation متفاوت است.Backward Compatibility (سازگاری نسخه‌های جدید با Clientهای قدیمی): بررسی می‌کند تغییرات Schema باعث خرابی نسخه‌های قبلی API نشده باشد.تگ‌ها#APITesting#SchemaValidation#OpenAPI#BackendTesting#JSONSchema

API - Mocking & Virtualization

Nastooh — Thu, 25 Jun 2026 17:48:17 +0330

جمع‌بندی سرفصلMocking چیست؟Mocking یعنی شبیه‌سازی رفتار یک Dependency یا External System به‌جای استفاده از نمونه واقعی آن، تا بتوانیم API یا سیستم خودمان را در شرایط کنترل‌شده تست کنیم.به زبان ساده، وقتی یک سرویس برای کار کردن به سرویس دیگری وابسته است ولی آن سرویس واقعی در دسترس نیست، آماده نیست، هزینه‌بر است، کند است یا نمی‌خواهیم در تست به آن وابسته باشیم، از Mock استفاده می‌کنیم.مثلاً اگر Customer Service برای استعلام کد پستی به یک External Address API وصل می‌شود، در تست می‌توانیم به‌جای سرویس واقعی، یک Mock Response برگردانیم.Virtualization / Service Virtualization چیست؟Service Virtualization از Mocking گسترده‌تر و حرفه‌ای‌تر است.در Virtualization ما فقط یک پاسخ ساده جعلی برنمی‌گردانیم؛ بلکه یک سرویس شبیه‌سازی‌شده می‌سازیم که می‌تواند رفتارهای مختلف یک سیستم وابسته را تقلید کند، مثل:Success ResponseError ResponseTimeoutSlow Response / LatencyInvalid PayloadDifferent Status CodesStateful Behaviorیعنی Virtual Service می‌تواند مثل یک Dependency واقعی رفتار کند، نه فقط یک جواب ثابت.چرا این سرفصل مهم است؟در تست Web API، خیلی وقت‌ها سرویس ما به این موارد وابسته است:DatabasePayment GatewaySMS ServiceNotification ServiceCore Banking SystemIdentity ProviderPartner APIFraud Detection Serviceاگر این وابستگی‌ها همیشه واقعی باشند، تست مشکل می‌شود چون:سرویس واقعی ممکن است آماده نباشدداده واقعی ممکن است نداشته باشیمپاسخ‌ها قابل کنترل نباشندتست flaky شودهزینه یا ریسک بالا برودسناریوهای خطا را نتوانیم راحت بازتولید کنیماینجاست که Mocking و Service Virtualization وارد می‌شوند.تفاوت Mocking و VirtualizationMockمعمولاً ساده‌تر است و برای شبیه‌سازی یک Response یا رفتار محدود استفاده می‌شود.مثلاً:GET /external/customer-score/123 به‌جای سرویس واقعی، یک Mock Server همیشه این را برگرداند:{ "score": 700 } Virtual Serviceپیشرفته‌تر است و می‌تواند بسته به Request یا شرایط، رفتارهای مختلف نشان دهد.مثلاً:اگر customerId = 123 → 200 OKاگر customerId = 999 → 404 Not Foundاگر header خاصی وجود نداشت → 401 Unauthorizedاگر سناریوی delay فعال بود → پاسخ با 5 ثانیه تأخیراگر سرویس پایین فرض شده → 503 Service UnavailableTest Double چیست؟در این سرفصل خوب است اسم Test Double را هم بدانی.Test Double یک اصطلاح کلی برای هر جایگزین تستیِ dependency واقعی است. انواع معروف آن:DummyStubFakeSpyMockدر آزمون لازم نیست تفاوت همه را خیلی عمیق بدانی، ولی بدانی Mock یکی از انواع Test Double است، خوب است.Stub چیست؟Stub معمولاً داده‌ی ثابت برمی‌گرداند و رفتار پیچیده ندارد.مثلاً همیشه برای استعلام مشتری:{ "customerId": 123, "status": "ACTIVE" } را برمی‌گرداند.Mock چیست؟Mock علاوه بر برگرداندن داده، می‌تواند برای Verification هم استفاده شود؛ یعنی بررسی کند که آیا dependency با پارامتر درست، تعداد دفعات درست یا ترتیب درست صدا زده شده یا نه.مثلاً:آیا Payment Service دقیقاً یک‌بار صدا زده شد؟آیا SMS Service بعد از ثبت تراکنش صدا زده شد؟آیا Header درست ارسال شد؟Fake چیست؟Fake یک پیاده‌سازی سبک ولی واقعی‌تر از dependency است.مثلاً به‌جای PostgreSQL از یک In-memory DB برای تست استفاده کنیم.Service Virtualization چه چیزی را شبیه‌سازی می‌کند؟یک Virtual Service می‌تواند این موارد را تقلید کند:HTTP Status CodesResponse BodyHeadersLatency / DelayTimeoutConnection FailureMalformed ResponseBusiness ErrorStateful ScenarioRate Limiting / 429Authentication Failureمثال واقعیفرض کن API زیر را داریم:POST /v1/transfers این API بعد از ثبت انتقال وجه باید به Fraud Detection Service درخواست بزند.اگر Fraud Service واقعی در دسترس نباشد، برای تست می‌توانیم یک Virtual Service بسازیم که این سناریوها را برگرداند:سناریوی 1 — موفق200 OK { "fraud": false } سناریوی 2 — مشکوک200 OK { "fraud": true } سناریوی 3 — Timeoutپاسخ بعد از 10 ثانیهسناریوی 4 — خرابی سرویس503 Service Unavailable سناریوی 5 — Payload نامعتبر400 Bad Request این یعنی می‌توانیم بدون وابستگی به سرویس واقعی، رفتار سیستم خودمان را در همه این سناریوها تست کنیم.Mock ServerMock Server ابزاری است که درخواست API را دریافت می‌کند و پاسخ‌های از پیش تعریف‌شده برمی‌گرداند.در تست API، Mock Server برای این کارها مفید است:شبیه‌سازی سرویس وابستهتوسعه قبل از آماده‌شدن سرویس واقعیتست سناریوهای خطاتست contract بین سرویس‌هاتست شرایط نادر مثل Timeout یا 500چه زمانی از Mocking استفاده می‌کنیم؟وقتی dependency واقعی آماده نیستوقتی dependency ناپایدار استوقتی هزینه استفاده از dependency واقعی زیاد استوقتی می‌خواهیم سناریوی خاص را دقیق کنترل کنیموقتی تست باید سریع و repeatable باشدوقتی می‌خواهیم خطاهای خاص را بازتولید کنیمچه زمانی Mocking کافی نیست؟اگر فقط یک Mock Response ثابت داشته باشیم، ممکن است خیلی از ریسک‌های واقعی را نبینیم.مثلاً اگر همیشه Fraud Service فقط 200 OK برگرداند، این‌ها را از دست می‌دهیم:Timeout429 Too Many RequestsMalformed JSON500 Internal Server ErrorSlow ResponseSchema ChangeAuthentication Failureبرای همین در تست حرفه‌ای، فقط happy path mock کافی نیست.Contract Testing و ارتباطش با Mockingوقتی از Mock یا Virtual Service استفاده می‌کنیم، یک ریسک مهم داریم:ممکن است Mock با سرویس واقعی هم‌خوان نباشد.مثلاً Mock می‌گوید:{ "customerName": "Ali" } ولی سرویس واقعی در اصل این را می‌دهد:{ "fullName": "Ali" } در این حالت تست روی Mock پاس می‌شود ولی در محیط واقعی سیستم Fail می‌کند.برای همین باید Mock یا Virtual Service با Contract / Swagger / OpenAPI سرویس واقعی هم‌راستا باشد.مزایای Mocking & Virtualizationکاهش وابستگی به سیستم‌های خارجیسریع‌تر شدن تستقابل‌تکرار شدن تستامکان تست سناریوهای خطاکاهش هزینهتوسعه موازی تیم‌هاتست زودتر از آماده‌شدن dependency واقعیکنترل کامل روی responseهاریسک‌ها و محدودیت‌هاممکن است Mock با واقعیت متفاوت باشدممکن است فقط happy path را پوشش دهدممکن است latency، concurrency یا رفتار واقعی را دقیق شبیه‌سازی نکنداگر به Mock بیش از حد اعتماد کنیم، integration bugها دیر کشف می‌شوندممکن است تست روی Mock سبز باشد ولی روی سیستم واقعی fail شوددر تست چه چیزهایی را باید با Mock / Virtual Service بررسی کنیم؟باید فقط سناریوی موفق را Mock نکنیم. این سناریوها مهم‌اند:200 Success400 Bad Request401 / 403404409 Conflict429 Too Many Requests500 / 503TimeoutSlow ResponseMalformed ResponseUnexpected Field / Missing FieldSchema MismatchMocking در چه لایه‌هایی استفاده می‌شود؟Unit TestComponent / Service TestAPI TestIntegration Test سبکConsumer-driven Contract Testحتی در UI Test اگر backend واقعی آماده نباشدMocking در Postman / API Testingدر دنیای API Testing، Mocking می‌تواند برای این استفاده شود:ساخت Mock Server برای endpointهاتست frontend قبل از آماده‌شدن backendتست backend قبل از آماده‌شدن سرویس وابستهشبیه‌سازی سناریوهای خاصساخت data setهای قابل‌کنترلاهمیت این سرفصل برای Backend TesterBackend Tester باید بتواند:تشخیص دهد کجا باید از Mock استفاده کند و کجا از real dependencyبداند Mocking جایگزین کامل Integration Testing نیستسناریوهای error handling را با virtual service تست کندبررسی کند API در برابر timeout, 500, 429, invalid payload چه رفتاری داردContract mismatch بین mock و سرویس واقعی را در نظر بگیردتشخیص دهد failure از API خودش است یا از dependency mock‌شده/واقعینکته امتحانی مهمدر پاسخ امتحانی فقط نگویید:Mocking یعنی شبیه‌سازی سرویس.این جواب ناقص است. پاسخ خوب باید این کلیدواژه‌ها را داشته باشد:Dependency, External Service, Mock Server, Virtual Service, Stub, Test Double, Controlled Response, Error Simulation, Timeout, Latency, Contract Alignment, Integration Riskنمونه پاسخ کامل کوتاهMocking یعنی جایگزین کردن یک Dependency یا External Service واقعی با یک نمونه شبیه‌سازی‌شده تا بتوان سیستم را در شرایط کنترل‌شده تست کرد. Service Virtualization شکل پیشرفته‌تری از این مفهوم است که علاوه بر برگرداندن Response ثابت، می‌تواند رفتارهایی مثل Timeout، Latency، Error Response، Invalid Payload و سناریوهای stateful را شبیه‌سازی کند. این رویکرد برای تست APIهایی که به سرویس‌های خارجی مثل Payment Gateway، Fraud Service یا Notification Service وابسته‌اند بسیار مهم است. با این حال، Mocking جایگزین کامل Integration Testing نیست و باید مطمئن شد که Mock با Contract سرویس واقعی هم‌خوان است.کلیدواژه‌هاMocking Service Virtualization Mock Server Virtual Service Test Double Stub Fake Spy Dependency External Service Controlled Response Error Simulation Timeout Latency Malformed Response Contract Testing Contract Alignment Integration Risk Happy Path Error PathMocking (شبیه‌سازی یک dependency یا external service به‌جای نمونه واقعی): برای تست سیستم در شرایط کنترل‌شده و بدون وابستگی به سرویس واقعی استفاده می‌شود.Service Virtualization (شبیه‌سازی پیشرفته یک سرویس وابسته): برای تقلید رفتارهای مختلف سرویس واقعی مثل success, error, timeout, latency و stateful behavior استفاده می‌شود.Mock Server (سروری که Request تستی را دریافت و Response از پیش تعریف‌شده برمی‌گرداند): برای تست API و شبیه‌سازی dependencyها استفاده می‌شود.Virtual Service (سرویس شبیه‌سازی‌شده با رفتار نزدیک‌تر به سیستم واقعی): برای تست حرفه‌ای‌تر سناریوهای dependency به‌کار می‌رود.Test Double (نام کلی برای جایگزین تستی dependency واقعی): شامل Dummy, Stub, Mock, Fake و Spy است.Stub (جایگزینی که معمولاً داده ثابت برمی‌گرداند): برای تست ساده‌ی رفتار سیستم در برابر یک dependency استفاده می‌شود.Fake (پیاده‌سازی سبک ولی کاربردی‌تر از dependency): مثل In-memory DB به‌جای دیتابیس واقعی.Spy (شیء تستی برای ثبت و مشاهده تعاملات): برای بررسی اینکه متدها با چه پارامتر و چند بار صدا زده شده‌اند استفاده می‌شود.Dependency (سیستم یا مؤلفه‌ای که API به آن وابسته است): مثل Database, Payment Gateway, Notification Service یا Fraud Service.External Service (سرویس بیرونی وابسته به API): برای مثال سرویس بانکی، سرویس احراز هویت یا سرویس پیامک.Controlled Response (پاسخ از پیش کنترل‌شده): برای ساخت سناریوهای قابل پیش‌بینی در تست استفاده می‌شود.Error Simulation (شبیه‌سازی خطاهای سرویس وابسته): مثل 500, 503, timeout, invalid payload و 429.Timeout (پاسخ‌ندادن dependency در زمان مورد انتظار): یکی از سناریوهای مهم برای تست error handling و resiliency سیستم است.Latency (تأخیر در پاسخ dependency): برای بررسی رفتار API در برابر کندی سرویس‌های وابسته تست می‌شود.Malformed Response (پاسخ با ساختار خراب یا ناسازگار): برای تست robustness و validation در API استفاده می‌شود.Contract Testing (بررسی سازگاری بین Consumer و Provider بر اساس Contract): برای جلوگیری از mismatch بین mock و سرویس واقعی مهم است.Contract Alignment (هم‌راستایی mock با Swagger/OpenAPI یا قرارداد واقعی سرویس): برای معتبر ماندن نتایج تست ضروری است.Integration Risk (ریسک اختلاف بین رفتار mock و سرویس واقعی): اگر dependency فقط با mock تست شود، ممکن است در محیط واقعی failure رخ دهد.Happy Path (سناریوی موفق عادی): فقط یکی از سناریوهایی است که باید mock شود و به‌تنهایی کافی نیست.Error Path (سناریوهای خطا و failure): مثل timeout، 500، invalid response و unauthorized که باید با virtualization پوشش داده شوند.توضیح کوتاه پستمرور فشرده‌ی Mocking و Service Virtualization در تست API با تمرکز بر شبیه‌سازی dependencyها، Mock Server، سناریوهای خطا مثل timeout و 500، و ریسک اختلاف بین mock و سرویس واقعی.تگ‌ها#APITesting#Mocking#ServiceVirtualization#BackendTesting#WebAPI

API -Rate Limiting & Throttling

Nastooh — Thu, 25 Jun 2026 17:08:57 +0330

جمع‌بندی سرفصلRate Limiting چیست؟Rate Limiting مکانیزمی برای محدود کردن تعداد Requestهایی است که یک Client یا User می‌تواند در یک بازه زمانی مشخص به API ارسال کند.هدف اصلی آن محافظت از API در برابر بار زیاد، جلوگیری از Abuse، Brute Force Attack، DoS و مصرف ناعادلانه منابع سیستم است.مثلاً اگر Contract بگوید:هر Client حداکثر 100 Request در دقیقه مجاز است.بعد از درخواست شماره 100، API باید درخواست‌های بعدی را تا پایان بازه زمانی رد کند.Throttling چیست؟Throttling مکانیزمی است که سرعت پردازش Requestها را کنترل می‌کند. برخلاف Rate Limiting که معمولاً درخواست اضافی را رد می‌کند، Throttling ممکن است:درخواست را با تأخیر پردازش کند.سرعت پاسخ را کاهش دهد.یا بعد از رسیدن به حد مجاز، درخواست را Reject کند.بنابراین:Rate Limiting → محدود کردن تعداد RequestThrottling → کنترل نرخ یا سرعت پردازش Requestتفاوت Rate Limiting و Throttlingچرا این سرفصل مهم است؟اگر Rate Limiting وجود نداشته باشد ممکن است:یک Client هزاران Request ارسال کند.منابع Server مصرف شوند.کاربران عادی نتوانند از سرویس استفاده کنند.حملات Brute Force روی Login انجام شود.حملات DoS یا API Abuse رخ دهد.429 Too Many Requestsمهم‌ترین Status Code این سرفصل است.اگر تعداد Requestها از حد مجاز بیشتر شود، API معمولاً پاسخ زیر را برمی‌گرداند:HTTP/1.1 429 Too Many Requests این Status Code نشان می‌دهد Client باید مدتی صبر کند و سپس دوباره درخواست ارسال کند.Retry-After Headerمعمولاً همراه 429 ارسال می‌شود.مثال:Retry-After: 60 یعنی Client باید 60 ثانیه صبر کند.در تست باید بررسی شود:Header وجود دارد؟مقدار آن صحیح است؟بعد از پایان زمان، API دوباره درخواست را قبول می‌کند؟روش‌های رایج اعمال Rate Limitingبر اساس IP Addressهر IP تعداد مشخصی Request مجاز دارد.مثال:100 Requests / Minute / IP بر اساس Userهر کاربر محدودیت جداگانه دارد.مثلاً:1000 Requests / Hour / User بر اساس API Keyهر API Key سهمیه مشخصی دارد.مثلاً:5000 Requests / Day / API Key بر اساس Access Tokenدر APIهای مبتنی بر OAuth2 معمولاً محدودیت بر اساس Access Token اعمال می‌شود.الگوریتم‌های رایج Rate Limitingدر آزمون لازم نیست الگوریتم‌ها را عمیق بدانید، اما نام آن‌ها مهم است.رایج‌ترین الگوریتم‌ها:Fixed WindowSliding WindowSliding LogToken BucketLeaky Bucketدر سطح آزمون کافی است بدانید:Token Bucket برای کنترل Burst مناسب است.Leaky Bucket نرخ خروج Requestها را یکنواخت نگه می‌دارد.تست Rate LimitingBackend Tester باید بررسی کند:قبل از رسیدن به Limit همه Requestها موفق باشند.دقیقاً بعد از رسیدن به Limit پاسخ 429 برگردد.Headerهای Rate Limit درست باشند.بعد از پایان بازه زمانی دوباره Request پذیرفته شود.Rate Limit فقط روی Client مربوطه اعمال شود.سایر کاربران تحت تأثیر قرار نگیرند.Headerهای مهمبعضی APIها این Headerها را برمی‌گردانند:X-RateLimit-Limit: 100 X-RateLimit-Remaining: 5 X-RateLimit-Reset: 1710000123 X-RateLimit-Limitحداکثر تعداد Request مجاز.X-RateLimit-Remainingتعداد Request باقی‌مانده.X-RateLimit-Resetزمان Reset شدن محدودیت.در تست باید بررسی شود این مقادیر درست کاهش پیدا می‌کنند.سناریوهای تست مهمباید تست شوند:ارسال Request کمتر از Limitارسال دقیقاً برابر Limitارسال بیشتر از LimitReset شدن Limitچند User هم‌زمانچند API Keyچند Access TokenRetry بعد از Retry-AfterParallel RequestsBurst Requestsارتباط با امنیتRate Limiting یکی از کنترل‌های مهم امنیتی است.کاربردها:جلوگیری از Brute Force Loginجلوگیری از Credential Stuffingجلوگیری از API Abuseجلوگیری از DoSجلوگیری از مصرف بیش از حد منابعاهمیت این سرفصل برای Backend TesterBackend Tester باید بتواند:رفتار API بعد از رسیدن به Limit را بررسی کند.429 Too Many Requests را تست کند.Headerهای مربوط به Rate Limit را اعتبارسنجی کند.عملکرد Retry-After را بررسی کند.تفاوت Rate Limiting و Throttling را بداند.تست‌های هم‌زمان (Concurrency) و Burst Traffic طراحی کند.بررسی کند Rate Limit روی User، Token، API Key یا IP درست اعمال شده است.نکته امتحانی مهمدر پاسخ امتحانی فقط نگویید:Rate Limiting یعنی محدود کردن تعداد Requestها.پاسخ کامل باید این کلیدواژه‌ها را داشته باشد:429 Too Many Requests, Retry-After, Burst Traffic, API Abuse, Brute Force, DoS, Concurrency, Rate Limit Headers, IP-based Limiting, User-based Limiting, API Key Limiting, Token Bucket, Leaky Bucketنمونه پاسخ کامل کوتاهRate Limiting مکانیزمی برای محدود کردن تعداد Requestهای مجاز در یک بازه زمانی است تا از API Abuse، Brute Force و مصرف بیش از حد منابع جلوگیری شود. در صورت عبور از حد مجاز، API معمولاً 429 Too Many Requests همراه با Retry-After برمی‌گرداند. Throttling علاوه بر محدودسازی، نرخ پردازش Requestها را نیز کنترل می‌کند و ممکن است به‌جای Reject کردن، درخواست‌ها را با تأخیر پردازش کند. Backend Tester باید رفتار API قبل و بعد از رسیدن به Limit، Headerهای Rate Limit، Reset شدن محدودیت، درخواست‌های هم‌زمان و سناریوهای امنیتی را بررسی کند.کلیدواژه‌هاRate Limiting Throttling 429 Too Many Requests Retry-After Rate Limit Burst Traffic API Abuse Brute Force Credential Stuffing DoS Concurrency Rate Limit Headers X-RateLimit-Limit X-RateLimit-Remaining X-RateLimit-Reset Fixed Window Sliding Window Token Bucket Leaky Bucket IP-based Limiting User-based Limiting API Key Limiting Access Token LimitingRate Limiting (محدود کردن تعداد Requestهای مجاز در یک بازه زمانی): برای محافظت از API در برابر استفاده بیش از حد، حملات و مصرف ناعادلانه منابع استفاده می‌شود.Throttling (کنترل سرعت پردازش Requestها): برای کاهش فشار روی سیستم، درخواست‌ها را با تأخیر پردازش یا در صورت نیاز Reject می‌کند.429 Too Many Requests (کد وضعیت عبور از حد مجاز درخواست): زمانی برمی‌گردد که Client از Rate Limit تعیین‌شده عبور کرده باشد.Retry-After (Header تعیین‌کننده زمان مجاز برای ارسال مجدد Request): معمولاً همراه پاسخ 429 ارسال می‌شود.Rate Limit (حداکثر تعداد Request مجاز): مقدار مجاز Requestها در یک بازه زمانی مشخص را تعیین می‌کند.Burst Traffic (ارسال ناگهانی تعداد زیادی Request): برای بررسی رفتار API در بار لحظه‌ای و تست Throttling استفاده می‌شود.API Abuse (استفاده غیرمجاز یا بیش از حد از API): یکی از اهداف اصلی پیاده‌سازی Rate Limiting جلوگیری از این رفتار است.Brute Force (حمله حدس زدن مکرر رمز عبور): Rate Limiting یکی از راهکارهای کاهش این حمله است.Credential Stuffing (استفاده از نام کاربری و رمزهای افشاشده برای ورود): با محدودسازی تعداد درخواست‌های Login کنترل می‌شود.DoS (حمله محروم‌سازی از سرویس): با محدود کردن نرخ درخواست‌ها اثر آن کاهش می‌یابد.Concurrency (ارسال هم‌زمان چند Request): برای بررسی عملکرد صحیح Rate Limiting و جلوگیری از Race Condition تست می‌شود.Rate Limit Headers (Headerهای نمایش وضعیت سهمیه درخواست): اطلاعات مربوط به Limit، تعداد باقی‌مانده و زمان Reset را به Client می‌دهند.X-RateLimit-Limit (حداکثر Request مجاز): مقدار کل سهمیه Requestها را نشان می‌دهد.X-RateLimit-Remaining (تعداد Request باقی‌مانده): تعداد درخواست‌های قابل استفاده تا پایان بازه را نشان می‌دهد.X-RateLimit-Reset (زمان Reset شدن سهمیه): زمان شروع مجدد سهمیه Requestها را مشخص می‌کند.Fixed Window (الگوریتم محدودسازی با بازه زمانی ثابت): تعداد Requestها را در بازه‌های زمانی مشخص کنترل می‌کند.Sliding Window (الگوریتم محدودسازی با پنجره متحرک): نسبت به Fixed Window دقت بیشتری در محاسبه تعداد Requestها دارد.Token Bucket (الگوریتم مبتنی بر سطل توکن): امکان Burst محدود را فراهم می‌کند و برای کنترل نرخ Request بسیار رایج است.Leaky Bucket (الگوریتم خروج یکنواخت Requestها): نرخ پردازش Requestها را ثابت نگه می‌دارد.IP-based Limiting (اعمال Rate Limit بر اساس IP): برای کنترل مصرف هر IP استفاده می‌شود.User-based Limiting (اعمال Rate Limit بر اساس کاربر): سهمیه Requestها را برای هر User به‌صورت مستقل مدیریت می‌کند.API Key Limiting (اعمال Rate Limit بر اساس API Key): برای سرویس‌های عمومی و Partner APIها استفاده می‌شود.Access Token Limiting (اعمال Rate Limit بر اساس Access Token): در APIهای مبتنی بر OAuth2 برای کنترل مصرف هر Token استفاده می‌شود.تگ‌ها#APITesting#RateLimiting#BackendTesting#RESTAPI#SecurityTesting

API - Versioning Approaches (URL, Header, Query Parameter, Media Type)

Nastooh — Thu, 25 Jun 2026 16:52:31 +0330

API Versioning چیست؟API Versioning یعنی مدیریت نسخه‌های مختلف یک API به‌گونه‌ای که تغییرات جدید باعث خراب شدن Clientهای قدیمی نشود. با Versioning می‌توان نسخه‌های مختلف API را به‌صورت هم‌زمان پشتیبانی کرد تا سیستم‌های قدیمی بدون تغییر به کار خود ادامه دهند و Clientهای جدید از قابلیت‌های نسخه جدید استفاده کنند.در سیستم‌های بزرگ و بانکی، حذف یا تغییر مستقیم یک API بدون Versioning می‌تواند باعث از کار افتادن Mobile App، Web Application یا سرویس‌های وابسته شود؛ بنابراین Versioning یکی از اصول مهم Backward Compatibility است.چرا Versioning مهم است؟در توسعه API، ممکن است:فیلد جدید اضافه شود.نام یک فیلد تغییر کند.ساختار Response تغییر کند.Business Logic تغییر کند.فیلدی حذف شود.اگر این تغییرات بدون Versioning انجام شوند، Clientهای قدیمی دیگر قادر به استفاده از API نخواهند بود.روش‌های رایج API VersioningURL Versioningدر این روش شماره نسخه داخل URL قرار می‌گیرد.مثال:GET /api/v1/customers/123 نسخه جدید:GET /api/v2/customers/123 مزایاساده و قابل فهممشاهده نسخه در URLمناسب برای مستندسازی و Swaggerرایج‌ترین روش در REST APIمعایببا هر نسخه URL تغییر می‌کند.Endpointهای بیشتری ایجاد می‌شود.Header Versioningدر این روش نسخه داخل Header ارسال می‌شود.مثال:GET /customers/123 API-Version: 2 یاX-API-Version: 2 مزایاURL ثابت باقی می‌ماند.نسخه از Resource جدا می‌شود.Endpoint تغییر نمی‌کند.معایبدر URL قابل مشاهده نیست.تست و Debug کمی سخت‌تر است.Media Type Versioning (Accept Header Versioning)در این روش نسخه داخل Header Accept مشخص می‌شود.مثال:Accept: application/vnd.bank.customer.v2+json مزایاکاملاً مطابق RESTنسخه در Representation مشخص می‌شود.URL ثابت باقی می‌ماند.معایبپیچیده‌تر از URL Versioningخوانایی کمتربرای افراد تازه‌کار سخت‌تر است.Query Parameter Versioningدر این روش نسخه به‌صورت پارامتر ارسال می‌شود.مثال:GET /customers/123?version=2 مزایاپیاده‌سازی سادهURL تقریباً ثابتمعایبکمتر استفاده می‌شود.از نظر REST بهترین روش محسوب نمی‌شود.Backward CompatibilityBackward Compatibility چیست؟یعنی نسخه جدید API نباید باعث خراب شدن Clientهایی شود که هنوز از نسخه قدیمی استفاده می‌کنند.مثلاً:نسخه اول:{ "firstName": "Ali" } نسخه دوم:{ "firstName": "Ali", "nationalCode": "0012345678" } اگر فقط فیلد جدید اضافه شود، معمولاً Backward Compatible است.اما اگر:{ "name": "Ali" } به‌جای firstName برگردد، احتمالاً Client قدیمی دچار Failure می‌شود.Breaking ChangeBreaking Change چیست؟هر تغییری که باعث شود Client قبلی دیگر نتواند با API کار کند.نمونه‌ها:حذف فیلدتغییر نام فیلدتغییر نوع دادهتغییر ساختار Responseتغییر Status Codeحذف Endpointتغییر Business Ruleاین تغییرات معمولاً نیاز به نسخه جدید API دارند.Non-breaking Changeتغییراتی که Clientهای قدیمی را خراب نمی‌کنند.مثلاً:اضافه شدن یک فیلد اختیاریاضافه شدن Endpoint جدیداضافه شدن Header جدیداضافه شدن مقدار جدید به Enum (در بعضی طراحی‌ها)Deprecated APIگاهی نسخه قدیمی حذف نمی‌شود، بلکه Deprecated می‌شود.یعنی:هنوز کار می‌کند.ولی توصیه می‌شود Clientها به نسخه جدید مهاجرت کنند.معمولاً زمان حذف نیز اعلام می‌شود.Version Migrationبعد از انتشار نسخه جدید:نسخه قدیمی مدتی پشتیبانی می‌شود.Clientها به نسخه جدید منتقل می‌شوند.در نهایت نسخه قدیمی حذف می‌شود.تست VersioningBackend Tester باید بررسی کند:هر نسخه Contract مخصوص خودش را دارد.نسخه قدیمی هنوز درست کار می‌کند.نسخه جدید رفتار مورد انتظار را دارد.تغییرات فقط در نسخه جدید اعمال شده‌اند.Response نسخه‌ها با Contract همان نسخه سازگار است.Swagger/OpenAPI هر نسخه مستقل باشد.Client قدیمی دچار Failure نشود.سناریوهای تست مهمباید تست شوند:درخواست بدون VersionVersion نامعتبرVersion پشتیبانی‌نشدهVersion قدیمیVersion جدیدHeader Version اشتباهURL Version اشتباهContract Version MismatchBackward CompatibilityDeprecated APIاهمیت این سرفصل برای Backend TesterBackend Tester باید بتواند:تشخیص دهد API از چه روش Versioning استفاده می‌کند.بین URL Versioning، Header Versioning، Media Type Versioning و Query Parameter Versioning تفاوت قائل شود.Backward Compatibility را تست کند.Breaking Change را شناسایی کند.رفتار نسخه‌های مختلف API را با Contract همان نسخه مقایسه کند.اطمینان حاصل کند که Release جدید باعث خرابی Clientهای قدیمی نشده است.نکته امتحانی مهمدر پاسخ امتحانی فقط نگویید:Versioning یعنی نسخه‌بندی API.پاسخ کامل باید این کلیدواژه‌ها را داشته باشد:Backward Compatibility, Breaking Change, Non-breaking Change, Contract, URL Versioning, Header Versioning, Media Type Versioning, Query Parameter Versioning, Deprecated API, Migrationنمونه پاسخ کامل کوتاهAPI Versioning روشی برای مدیریت نسخه‌های مختلف API است تا تغییرات جدید باعث از کار افتادن Clientهای قدیمی نشود. رایج‌ترین روش‌ها شامل URL Versioning، Header Versioning، Media Type Versioning و Query Parameter Versioning هستند. مهم‌ترین هدف Versioning حفظ Backward Compatibility است. تغییراتی مانند حذف فیلد، تغییر نام فیلد یا تغییر ساختار Response از نوع Breaking Change هستند و معمولاً نیاز به نسخه جدید API دارند. Backend Tester باید نسخه‌های مختلف را از نظر Contract، Compatibility و رفتار API به‌صورت مستقل تست کند.کلیدواژه‌هاAPI Versioning URL Versioning Header Versioning Media Type Versioning Accept Header Query Parameter Versioning Backward Compatibility Breaking Change Non-breaking Change Deprecated API Migration API Contract Contract Compatibility Swagger Versioning OpenAPI Specification Client CompatibilityAPI Versioning (مدیریت هم‌زمان نسخه‌های مختلف API): برای جلوگیری از خراب شدن Clientهای قدیمی هنگام انتشار نسخه جدید استفاده می‌شود.URL Versioning (قرار دادن شماره نسخه در URL): رایج‌ترین روش Versioning در REST API است.Header Versioning (ارسال نسخه در Header): باعث ثابت ماندن URL و جداسازی نسخه از Resource می‌شود.Media Type Versioning (مشخص کردن نسخه در Header Accept): نسخه را در نوع محتوای Response مشخص می‌کند و مطابق معماری REST است.Accept Header (Header مشخص‌کننده نوع Response مورد انتظار): در Media Type Versioning برای تعیین نسخه نیز استفاده می‌شود.Query Parameter Versioning (ارسال نسخه به‌صورت پارامتر): روشی ساده ولی کم‌کاربردتر برای مدیریت نسخه API است.Backward Compatibility (سازگاری با نسخه‌های قبلی): تضمین می‌کند Clientهای قدیمی بعد از انتشار نسخه جدید همچنان بدون تغییر کار کنند.Breaking Change (تغییری که باعث خرابی Client قبلی شود): مانند حذف فیلد، تغییر نام فیلد، تغییر نوع داده یا حذف Endpoint.Non-breaking Change (تغییری که Clientهای قبلی را خراب نکند): مانند اضافه کردن فیلد اختیاری یا Endpoint جدید.Deprecated API (نسخه‌ای که هنوز فعال است اما قرار است حذف شود): برای اطلاع‌رسانی و مهاجرت تدریجی Clientها استفاده می‌شود.Migration (فرآیند انتقال Clientها به نسخه جدید): برای حذف تدریجی نسخه‌های قدیمی انجام می‌شود.API Contract (توافق بین Client و Server برای هر نسخه API): باید برای هر Version مستقل حفظ شود.Contract Compatibility (سازگاری Contract بین نسخه‌ها): برای بررسی اینکه تغییرات باعث Failure در Clientهای قبلی نشده‌اند استفاده می‌شود.Swagger Versioning (مستندسازی نسخه‌های مختلف در Swagger): برای تست و نگهداری مستقل هر نسخه API کاربرد دارد.OpenAPI Specification (استاندارد مستندسازی API): مشخص می‌کند هر نسخه API چه Endpoint، Schema و Contractی دارد.Client Compatibility (سازگاری Client با نسخه API): بررسی می‌کند Clientهای قدیمی و جدید با نسخه مناسب API بدون Failure کار می‌کنند.توضیح کوتاه پستمرور فشرده‌ی API Versioning با تمرکز بر روش‌های URL، Header، Media Type و Query Parameter، همراه با مفاهیم Backward Compatibility، Breaking Change و مدیریت نسخه‌های مختلف API.تگ‌ها#APITesting#RESTAPI#Versioning#BackendTesting#OpenAPI

API- Pagination & Filtering

Nastooh — Thu, 25 Jun 2026 16:14:17 +0330

Pagination چیست؟Pagination یعنی شکستن خروجی یک API به صفحه‌های کوچک‌تر، به‌جای اینکه همه‌ی داده‌ها یک‌جا برگردند.مثلاً اگر سیستم ۱۰۰ هزار مشتری دارد، نباید همه را با یک GET /customers برگرداند؛ چون باعث کندی، فشار روی Database، مصرف زیاد Memory و افزایش Latency می‌شود.چرا Pagination مهم است؟در API Testing، Pagination فقط موضوع نمایش صفحه‌ای نیست؛ روی Performance، Data Consistency، User Experience و Correctness اثر دارد.اگر درست پیاده‌سازی نشود ممکن است:بعضی رکوردها نمایش داده نشوندبعضی رکوردها تکراری برگردندترتیب داده‌ها به‌هم بریزددر زمان اضافه/حذف شدن داده، خروجی صفحات ناپایدار شودAPI با حجم زیاد داده کند یا ناپایدار شودLimit / Offset PaginationLimit / Offset چیست؟در این مدل، limit تعداد رکوردهای برگشتی را مشخص می‌کند و offset می‌گوید از چندمین رکورد به بعد داده برگردد.مثال:GET /customers?limit=10&offset=0 یعنی ۱۰ رکورد اول را برگردان.GET /customers?limit=10&offset=10 یعنی ۱۰ رکورد بعدی را برگردان.کاربرد Limit / Offsetاین مدل ساده، قابل‌فهم و رایج است و برای لیست‌های کوچک یا متوسط خوب جواب می‌دهد.مثلاً:لیست مشتریانلیست تراکنش‌هالیست درخواست‌هاصفحات مدیریتیریسک‌های Limit / Offsetدر دیتای بزرگ یا دیتایی که مرتب تغییر می‌کند، offset pagination ممکن است مشکل‌ساز شود.مثلاً اگر بین صفحه اول و دوم یک رکورد جدید اضافه شود، ممکن است بعضی داده‌ها تکراری یا گم شوند.از نظر Performance هم offsetهای بزرگ می‌توانند برای Database سنگین باشند.Cursor-based PaginationCursor-based Pagination چیست؟در این مدل به‌جای offset، از یک cursor استفاده می‌شود. Cursor معمولاً نشانه‌ای از آخرین رکورد دیده‌شده یا موقعیت فعلی در لیست است.مثال:GET /transactions?limit=20&cursor=eyJpZCI6MTAwMjN9 یعنی از جایی که این cursor مشخص می‌کند، ۲۰ رکورد بعدی را برگردان.کاربرد Cursor-based Paginationاین مدل برای داده‌های بزرگ، real-time یا پرتغییر بهتر است.مثلاً:تراکنش‌های بانکیلاگ‌هاپیام‌هاactivity feedلیست‌هایی با حجم بالامزیت Cursor-basedبرای دیتای بزرگ بهتر از offset استاحتمال رکورد تکراری یا گم‌شده کمتر می‌شودبرای infinite scroll و داده‌های جدید مناسب‌تر استدر سیستم‌های پرترافیک پایدارتر استFiltering چیست؟Filtering یعنی محدود کردن خروجی API بر اساس شرط‌های مشخص.مثال:GET /customers?status=ACTIVE&city=Tehran یعنی فقط مشتریان فعال شهر تهران را برگردان.یا:GET /transactions?fromDate=2026-01-01&toDate=2026-01-31&status=SUCCESS یعنی تراکنش‌های موفق در بازه تاریخی مشخص را برگردان.نکات تستی مهم در Filteringدر تست Filtering فقط نباید ببینی API جواب می‌دهد؛ باید بررسی کنی خروجی واقعاً مطابق فیلتر است.باید تست کنی:فیلتر معتبرفیلتر نامعتبرچند فیلتر هم‌زمانمقدار خالیمقدار خارج از دامنهcase sensitivityفیلتر روی تاریخفیلتر روی statusفیلتر روی مقدار عددیترکیب filter + paginationPagination + Filtering با همدر APIهای واقعی، معمولاً Pagination و Filtering با هم استفاده می‌شوند.مثال:GET /customers?status=ACTIVE&city=Tehran&limit=20&offset=0 در تست باید مطمئن شوی:اول فیلتر درست اعمال شدهبعد pagination روی نتیجه‌ی فیلترشده اعمال شدهتعداد رکوردها از limit بیشتر نیستصفحه بعدی ادامه‌ی همان دیتای فیلترشده استترتیب داده‌ها بین صفحات ثابت استSorting کنار Paginationبرای اینکه Pagination قابل اعتماد باشد، معمولاً باید Sorting مشخص داشته باشیم.مثال:GET /customers?limit=10&offset=0&sort=createdAt,desc اگر sorting مشخص نباشد، خروجی صفحات ممکن است ناپایدار شود.در تست حرفه‌ای باید بگویی pagination بدون sort پایدار، ریسک duplicate/missing records دارد.Status Codeهای مهماگر پارامترهای pagination یا filtering نامعتبر باشند، معمولاً انتظار خطای 4xx داریم.مثلاً:limit منفیoffset منفیlimit خیلی بزرگdate format نامعتبرstatus خارج از مقدارهای مجازپاسخ مناسب معمولاً 400 Bad Request یا طبق Contract است.اهمیت این سرفصل برای Backend TesterBackend Tester باید بتواند بررسی کند:limit و offset درست اعمال می‌شوندcursor درست تولید و مصرف می‌شودصفحه‌ها رکورد تکراری یا گم‌شده ندارندفیلترها دقیقاً روی داده اعمال می‌شوندترکیب pagination + filtering + sorting درست کار می‌کندAPI در برابر پارامترهای نامعتبر خطای مناسب می‌دهددر حجم داده زیاد، رفتار API از نظر Performance قابل قبول استنکته امتحانی مهمدر پاسخ امتحانی فقط نگویید:Pagination یعنی صفحه‌بندی و Filtering یعنی فیلتر کردن.پاسخ خوب باید این کلیدواژه‌ها را داشته باشد:limit, offset, cursor, page size, next cursor, filter criteria, sorting, stable order, missing records, duplicate records, performance risk, 400 Bad Request, contract validationنمونه پاسخ کامل کوتاهPagination در API یعنی تقسیم خروجی بزرگ به بخش‌های کوچک‌تر با روش‌هایی مثل limit/offset یا cursor-based pagination. در روش limit/offset تعداد رکورد و نقطه شروع مشخص می‌شود، اما در داده‌های بزرگ یا پرتغییر ممکن است باعث رکورد تکراری یا گم‌شده شود. در روش cursor-based، API با یک cursor ادامه‌ی لیست را مشخص می‌کند و برای داده‌های real-time یا حجیم پایدارتر است. Filtering یعنی محدود کردن خروجی بر اساس شرط‌هایی مثل status, date range یا customer type. در تست باید ترکیب pagination + filtering + sorting، پارامترهای نامعتبر، ترتیب ثابت داده‌ها و نبودن رکورد تکراری یا جاافتاده بررسی شود.کلیدواژه‌هاPagination Filtering Limit Offset Cursor Cursor-based Pagination Page Size Next Cursor Previous Cursor Total Count Filter Criteria Sorting Stable Order Duplicate Records Missing Records Performance Risk 400 Bad Request Contract ValidationPagination (تقسیم خروجی API به صفحه‌های کوچک‌تر): برای کنترل حجم response، بهبود performance و مدیریت لیست‌های بزرگ استفاده می‌شود.Filtering (محدود کردن خروجی بر اساس شرط): برای جستجو و نمایش داده‌های مرتبط مثل مشتریان فعال یا تراکنش‌های یک بازه زمانی استفاده می‌شود.Limit (تعداد رکوردهای برگشتی در هر درخواست): برای تعیین اندازه صفحه یا page size استفاده می‌شود.Offset (تعداد رکوردهایی که باید از ابتدای نتیجه رد شوند): در مدل limit/offset pagination برای رفتن به صفحه‌های بعدی استفاده می‌شود.Cursor (نشانه‌ی موقعیت فعلی در لیست داده): در cursor-based pagination برای گرفتن بخش بعدی داده استفاده می‌شود.Cursor-based Pagination (صفحه‌بندی بر اساس cursor به‌جای offset): برای داده‌های بزرگ، پرتغییر و real-time مناسب‌تر است.Page Size (تعداد آیتم‌های هر صفحه): معمولاً با limit مشخص می‌شود و باید حد مجاز داشته باشد.Next Cursor (cursor برگشتی برای صفحه بعد): در response برگردانده می‌شود تا client بتواند ادامه داده را بگیرد.Previous Cursor (cursor برای صفحه قبلی): در بعضی APIها برای برگشت به صفحه قبل استفاده می‌شود.Total Count (تعداد کل رکوردهای مطابق فیلتر): برای نمایش تعداد کل نتایج استفاده می‌شود، اما در دیتای بزرگ ممکن است محاسبه آن سنگین باشد.Filter Criteria (شرط‌های فیلتر مثل status، date، type): برای محدود کردن نتیجه API استفاده می‌شود.Sorting (مرتب‌سازی خروجی بر اساس فیلد مشخص): برای پایداری pagination و جلوگیری از جابه‌جایی داده بین صفحات مهم است.Stable Order (ترتیب ثابت و قابل تکرار داده‌ها): در pagination ضروری است تا رکوردها گم یا تکراری نشوند.Duplicate Records (رکوردهای تکراری بین صفحات): یکی از failureهای رایج در pagination ضعیف است.Missing Records (رکوردهای جاافتاده بین صفحات): وقتی pagination یا sorting ناپایدار باشد رخ می‌دهد.Performance Risk (ریسک کندی یا فشار روی DB/API): در offsetهای بزرگ، فیلترهای سنگین یا total countهای پرهزینه دیده می‌شود.400 Bad Request (خطای درخواست نامعتبر): برای پارامترهای نامعتبر مثل limit منفی، offset منفی یا date format غلط استفاده می‌شود.Contract Validation (بررسی رفتار API طبق Swagger/OpenAPI یا مستندات): برای اطمینان از نام پارامترها، نوع داده، مقدارهای مجاز و خطاهای مورد انتظار استفاده می‌شود.توضیح کوتاه پستمرور فشرده‌ی Pagination و Filtering در API با تمرکز بر limit/offset، cursor-based pagination، ترکیب با sorting و ریسک‌هایی مثل رکورد تکراری، رکورد جاافتاده و فشار روی دیتابیس.تگ‌ها#APITesting#Pagination#Filtering#BackendTesting#RESTAPI

API -Content types of body

Nastooh — Thu, 25 Jun 2026 16:03:38 +0330

Content-Type of Body چیست؟Content-Type در Header مشخص می‌کند بدنه‌ی Request با چه فرمتی ارسال شده و Server باید آن را با چه parser و چه منطق پردازشی بخواند.در تست API، فهم Content-Type خیلی مهم است چون اگر Header و Body با هم سازگار نباشند، ممکن است 400 Bad Request، 415 Unsupported Media Type، Validation Error یا حتی Contract Mismatch رخ دهد.نکته‌ی اصلی این سرفصل این است که در تست API فقط خود Body مهم نیست؛ باید نوع Body + Header مربوط به آن + رفتار Parsing سمت Server را با هم ببینی.raw JSON چیست؟در این حالت، بدنه‌ی درخواست به‌صورت JSON خام ارسال می‌شود و معمولاً Header به این شکل است:Content-Type: application/json نمونه:{ "firstName": "Ali", "lastName": "Ahmadi", "age": 30 } JSON رایج‌ترین فرمت در REST APIهاست و برای ارسال داده‌های ساختاریافته، آبجکت‌ها، آرایه‌ها و مدل‌های پیچیده استفاده می‌شود.نکات تستی مهم برای raw JSONبررسی کن Header = application/json درست ست شده باشد.بررسی کن Schema و ساختار JSON درست باشد.نوع داده‌ها را تست کن: عدد، رشته، بولین، nullفیلد اجباری / اختیاری را تست کن.Malformed JSON را تست کن؛ مثل براکت جاافتاده، کوتیشن اشتباه، comma اضافیاگر Content-Type درست باشد ولی JSON خراب باشد، معمولاً 400 Bad Request منطقی است.اگر Body اصلاً JSON نباشد ولی Content-Type: application/json باشد، باز هم باید رفتار Validation / Parsing بررسی شود.XML چیست؟در این حالت، بدنه‌ی درخواست به‌صورت XML ارسال می‌شود و معمولاً Header این است:Content-Type: application/xml نمونه: Ali Ahmadi 30 XML نسبت به JSON ساختار متنی با tag دارد و در بعضی سیستم‌های قدیمی، بانکی، SOAP-محور یا یکپارچه‌سازی‌های سازمانی هنوز زیاد دیده می‌شود.نکات تستی مهم برای XMLبررسی کن API اصلاً XML را پشتیبانی می‌کند یا نه.درست بودن Content-Type: application/xml را چک کن.Well-formed بودن XML را تست کن؛ مثل بسته شدن tagها، nesting درست، quote درست attributeهااگر سیستم XSD یا XML schema validation دارد، Schema Validation را تست کن.کاراکترهای خاص، encoding و داده‌های null/empty را تست کن.اگر API فقط JSON قبول کند و XML بفرستی، پاسخ مناسب معمولاً 415 Unsupported Media Type یا طبق Contract است.form-data چیست؟form-data معمولاً برای ارسال داده‌های فرم به‌همراه فایل استفاده می‌شود و معمولاً Header به این شکل است:Content-Type: multipart/form-data در form-data، هر فیلد به‌صورت یک part جداگانه ارسال می‌شود و هر part می‌تواند متن یا فایل باشد.مثلاً برای ثبت کاربر همراه با عکس کارت ملی، رزومه، امضا یا فایل ضمیمه از این نوع استفاده می‌شود.نمونه‌ی مفهومی:firstName = AlilastName = Ahmadiavatar = profile.jpgنکات تستی مهم برای form-data / multipartوجود فیلدهای متنی و فایل را هم‌زمان تست کن.فرمت فایل، حجم فایل، پسوند فایل و MIME type را تست کن.سناریوهای فایل خالی، فایل خراب، فایل خیلی بزرگ، پسوند ممنوع را تست کن.بررسی کن اگر فیلد فایل required است، نبود آن چه خطایی می‌دهد.اگر سیستم روی نام فایل یا نوع فایل Validation دارد، حتماً تست منفی طراحی کن.در تست امنیتی، آپلود فایل مخرب / executable / script هم از جنس ریسک‌های مهم است.x-www-form-urlencoded چیست؟این نوع برای ارسال داده‌های فرم بدون فایل استفاده می‌شود و معمولاً Header آن این است:Content-Type: application/x-www-form-urlencoded در این حالت داده‌ها به‌صورت key=value و با & به هم متصل می‌شوند.نمونه:username=ali&password=123456&rememberMe=true این نوع معمولاً در فرم‌های login قدیمی، OAuth token request، بعضی gatewayها و برخی سرویس‌های ساده‌تر دیده می‌شود.نکات تستی مهم برای x-www-form-urlencodedبررسی کن API این نوع Content-Type را می‌پذیرد یا نه.Encoding کاراکترها، فاصله، کاراکتر فارسی، +، % و کاراکترهای special را تست کن.سناریوهای پارامتر تکراری، پارامتر خالی، پارامتر جاافتاده را تست کن.اگر Body باید form-urlencoded باشد ولی JSON بفرستی، باید رفتار API را از نظر Contract بررسی کنی.برای endpointهایی مثل login یا token generation، این نوع خیلی مهم است.multipart/form-data چیست؟multipart/form-data در واقع همان فرمت استاندارد form-data برای ارسال چند بخش مجزا در بدنه است.یعنی وقتی در ابزارهایی مثل Postman نوع form-data را انتخاب می‌کنی، در سطح HTTP معمولاً Content-Type واقعی می‌شود:Content-Type: multipart/form-data; boundary=... پس از نظر مفهومی:form-data = مدل کاری در ابزار تستmultipart/form-data = فرمت HTTP واقعی که Request با آن ارسال می‌شودکاربرد اصلی multipartآپلود فایلارسال هم‌زمان فایل + داده متنیفرم‌های پیچیده با چند فیلد و چند ضمیمهنکته مهم امتحانیاگر در سؤال از form-data و multipart جداگانه نام برده شد، بهتر است بگویی:form-data در عمل معمولاً با multipart/form-data روی HTTP ارسال می‌شود.تفاوتش با x-www-form-urlencoded این است که multipart برای فایل و بخش‌های مجزا مناسب است، ولی x-www-form-urlencoded برای فیلدهای متنی ساده و بدون فایل.تفاوت اصلی raw JSON / XML / form-data / x-www-form-urlencoded / multipart1) از نظر ساختارJSON → داده‌ی ساختاریافته، شیء/آرایه، رایج در RESTXML → داده‌ی ساختاریافته مبتنی بر tagx-www-form-urlencoded → جفت‌های key=value برای فرم‌های سادهmultipart/form-data → چند بخش جداگانه، مناسب فایل و فرم پیچیده2) از نظر کاربردJSON → APIهای مدرن، عملیات Create / Update / SearchXML → سیستم‌های قدیمی‌تر، SOAP، بعضی سرویس‌های سازمانیx-www-form-urlencoded → فرم‌های ساده، login / token / authmultipart/form-data → file upload، آپلود تصویر، سند، ضمیمه3) از نظر تستدر JSON/XML بیشتر روی schema, validation, parsing, data type تمرکز می‌کنیدر multipart علاوه بر فیلدها باید فایل، سایز، نوع فایل، امنیت فایل را هم تست کنیدر x-www-form-urlencoded باید روی encoding، پارامترهای خالی، تکراری، missing تمرکز کنیخطاهای رایج مرتبط با Content types of body1) Header و Body با هم سازگار نیستندمثلاً:Content-Type: application/json ولی بدنه XML است.این می‌تواند باعث 400، 415 یا Parsing Failure شود.2) API فرمت را پشتیبانی نمی‌کندمثلاً API فقط JSON قبول می‌کند ولی XML یا multipart می‌فرستی.اینجا معمولاً 415 Unsupported Media Type مطرح می‌شود.3) Body از نظر ساختاری خراب استمثلاً:JSON خرابXML بدفرمmultipart ناقصform-urlencoded با encoding خرابدر این حالت معمولاً 400 Bad Request یا خطای validation دیده می‌شود.4) فایل آپلودی از نظر امنیت یا اعتبار مشکل دارددر multipart باید این ریسک‌ها را ببینی:فایل بیش از حد بزرگفرمت فایل ممنوعفایل اسکریپتی / اجرایینام فایل غیرمجازMIME type spoofingاهمیت این سرفصل برای Backend TesterBackend Tester باید بتواند تشخیص دهد:هر endpoint چه Body Typeای می‌پذیردچه Content-Typeای باید ست شوداگر Header و Body mismatch باشند چه خطایی منطقی استخطا مربوط به Contract است یا Parser یا Validation یا Business Ruleدر سناریوهای file upload چه ریسک‌های functional و security وجود دارداین سرفصل مستقیماً در طراحی API Test Case، Negative Testing، Contract Testing، Security Testing و Bug Analysis استفاده می‌شود.نکته امتحانی مهمدر پاسخ امتحانی فقط نگویید «JSON برای داده، form-data برای فایل».پاسخ خوب باید این کلیدواژه‌ها را داشته باشد:Content-Type، Request Body، Parser، Schema Validation، Malformed Payload، 415 Unsupported Media Type، 400 Bad Request، multipart/form-data، x-www-form-urlencoded، file upload، contract mismatch، server-side validationنمونه پاسخ کامل کوتاهدر API Testing، نوع Body مشخص می‌کند داده با چه فرمتی به سرور ارسال می‌شود و سرور باید آن را با چه parser و چه validationای پردازش کند. raw JSON معمولاً با Content-Type: application/json برای APIهای REST استفاده می‌شود، XML بیشتر در سرویس‌های قدیمی‌تر یا SOAP دیده می‌شود، x-www-form-urlencoded برای فرم‌های ساده و درخواست‌های login/token کاربرد دارد و multipart/form-data برای ارسال فایل یا ترکیب فایل و داده‌ی متنی استفاده می‌شود. در تست این سرفصل باید سازگاری Header و Body، درستی schema/format، رفتار API در برابر malformed payload و خطاهای 400 و 415 بررسی شود.کلیدواژه‌هاContent-Type Request Body Payload Media Type Parser Serialization Deserialization JSON XML form-data multipart/form-data x-www-form-urlencoded Schema Validation Malformed Payload File Upload MIME Type Boundary Encoding 400 Bad Request 415 Unsupported Media Type Contract Mismatch Server-side ValidationContent-Type (هدر مشخص‌کننده‌ی نوع داده‌ی بدنه‌ی Request): برای تعیین فرمت Body مثل application/json یا multipart/form-data استفاده می‌شود.Request Body (بدنه‌ی درخواست HTTP): داده‌ی اصلی ارسالی از Client به Server که در POST / PUT / PATCH کاربرد دارد.Payload (محتوای واقعی داده‌ی ارسالی در بدنه‌ی Request): در تست API برای بررسی ساختار، داده و اعتبار ورودی استفاده می‌شود.Media Type (نوع استاندارد داده در HTTP مثل application/json یا application/xml): در تحلیل Content-Type و Accept و تست Contract استفاده می‌شود.Parser (ماژول یا منطق خواندن و تبدیل داده‌ی ورودی به ساختار قابل‌فهم برای سیستم): در خطاهای JSON/XML parsing و تحلیل 400 Bad Request کاربرد دارد.Serialization (تبدیل آبجکت یا داده‌ی داخلی برنامه به فرمت قابل ارسال مثل JSON/XML): در طراحی API و تولید Request/Response استفاده می‌شود.Deserialization (تبدیل داده‌ی متنی ورودی مثل JSON/XML به آبجکت یا ساختار داخلی سیستم): در سمت Server و هنگام پردازش Request Body کاربرد دارد.JSON (فرمت متنی سبک و رایج برای تبادل داده در REST API): در بیشتر Web APIها برای Create / Update / Search استفاده می‌شود.XML (فرمت متنی مبتنی بر tag برای تبادل داده): در SOAP، سیستم‌های قدیمی‌تر و برخی یکپارچه‌سازی‌های سازمانی استفاده می‌شود.form-data (روش ارسال داده‌ی فرم، معمولاً همراه فایل): در ابزارهایی مثل Postman برای تست file upload و ارسال فیلدهای متنی + فایل استفاده می‌شود.multipart/form-data (فرمت HTTP چندبخشی برای ارسال فایل و چند بخش مجزا در یک Request): در آپلود فایل، تصویر، سند و فرم‌های پیچیده استفاده می‌شود.x-www-form-urlencoded (فرمت فرم ساده به‌صورت key=value): در login، token request و فرم‌های بدون فایل استفاده می‌شود.Schema Validation (بررسی ساختار و قواعد مجاز داده‌ی ورودی یا خروجی): برای JSON/XML، فیلدهای اجباری، نوع داده و ساختار مورد انتظار کاربرد دارد.Malformed Payload (بدنه‌ی خراب یا بدفرم مثل JSON یا XML ناقص): در Negative Testing و بررسی رفتار API در برابر ورودی خراب استفاده می‌شود.File Upload (ارسال فایل از طریق Request): در تست multipart/form-data و سناریوهای آپلود تصویر، سند و ضمیمه کاربرد دارد.MIME Type (شناسه‌ی نوع فایل/داده مثل image/png یا application/pdf): در تست upload، Content-Type و اعتبارسنجی نوع فایل استفاده می‌شود.Boundary (مرزبندی بین بخش‌های مختلف در multipart/form-data): در سطح HTTP برای جدا کردن partهای مختلف بدنه استفاده می‌شود.Encoding (نحوه‌ی کدگذاری کاراکترها و داده‌ها): در x-www-form-urlencoded، XML، داده‌های فارسی و کاراکترهای خاص اهمیت دارد.400 Bad Request (کد خطایی که نشان می‌دهد درخواست از نظر ساختار یا داده نامعتبر است): در malformed JSON/XML، داده‌ی اشتباه یا validation error استفاده می‌شود.415 Unsupported Media Type (کد خطایی که نشان می‌دهد نوع داده‌ی ارسالی توسط API پشتیبانی نمی‌شود): در تست Content-Type و ناسازگاری Body format با Contract استفاده می‌شود.Contract Mismatch (عدم تطابق بین رفتار واقعی API و قرارداد تعریف‌شده در مستندات): وقتی API برخلاف Swagger/OpenAPI نوع داده یا رفتار دیگری نشان می‌دهد استفاده می‌شود.Server-side Validation (اعتبارسنجی داده در سمت سرور): برای جلوگیری از پذیرش Body نامعتبر، فایل غیرمجاز یا دور زدن Client-side validation استفاده می‌شود.تگ‌ها#APITesting#HTTP#ContentType#BackendTesting#Postman

API - Caching چیست؟

Nastooh — Thu, 25 Jun 2026 16:01:08 +0330

Caching چیست؟Caching یعنی ذخیرهسازی موقت داده یا Response در یک لایهی میانی یا محلی، بهطوری که برای درخواستهای بعدی لازم نباشد همان داده دوباره از منبع اصلی مثل Database، Server یا Origin خوانده شود.هدف اصلی Caching افزایش Performance، کاهش Latency، کاهش بار روی Backend و بهبود Scalability است.در تست API و Backend، Caching فقط موضوع سرعت نیست؛ بلکه یک موضوع مهم درستی داده هم هست. چون اگر Cache درست مدیریت نشود، ممکن است دادهی قدیمی (stale data) برگردد، تغییرات جدید دیده نشود، یا بین DB و Response ناسازگاری ایجاد شود.چرا این سرفصل مهم است؟چون خیلی از باگهای واقعی در سیستمهای Backend و بانکی فقط از خود Business Logic نیستند؛ از Cache behavior میآیند.مثلاً:اطلاعات مشتری در DB تغییر کرده ولی API هنوز مقدار قبلی را از Cache برمیگرداندکاربر Logout کرده ولی Client-side cache هنوز دادهی حساس را نگه داشتهفایل JS/CSS جدید deploy شده ولی CDN هنوز نسخهی قبلی را سرو میکندETag یا Cache-Control اشتباه باعث میشود کلاینت دادهی بهروز نگیردپس تستر باید بفهمد:داده از کدام لایه cache میشودچه زمانی cache معتبر است و چه زمانی باید invalidate شودچه HTTP caching headerهایی رفتار cache را کنترل میکنندCaching در چه لایههایی اتفاق میافتد؟Caching را در این سرفصل میتوان در سه لایهی اصلی دید:Client-side cachingServer-side cachingProxy / CDN cachingClient-side cachingClient-side caching چیست؟در این مدل، داده در سمت Client یا User Agent ذخیره میشود؛ یعنی در Browser، Mobile App یا محیط کلاینت.هدف این است که کلاینت برای هر بار نمایش یا هر بار درخواست، دوباره همهچیز را از سرور نگیرد.انواع مهم Client-side cachingBrowser Cacheمرورگر فایلها یا پاسخها را بهصورت محلی ذخیره میکند تا در درخواستهای بعدی سریعتر استفاده شوند.معمولاً برای اینها زیاد استفاده میشود:ImagesCSSJavaScriptگاهی API responses یا فایلهای HTMLاگر Cache-Control، ETag یا Expires درست تنظیم شده باشند، مرورگر میتواند تصمیم بگیرد که از نسخهی محلی استفاده کند یا دوباره با سرور چک کند.CookiesCookie یک دادهی کوچک است که در سمت مرورگر ذخیره میشود و معمولاً برای session, authentication, tracking یا preference استفاده میشود.Cookie ذاتاً cache به معنای classic caching نیست، ولی چون دادهای را در سمت کلاینت نگه میدارد، در این سرفصل کنار client-side storage دیده میشود.از دید تست:آیا اطلاعات حساس در Cookie ذخیره شده؟آیا HttpOnly / Secure / SameSite رعایت شده؟آیا بعد از logout یا session expiry، دادهی قدیمی هنوز معتبر است؟localStoragelocalStorage یک فضای ذخیرهسازی سمت مرورگر است که داده را بهصورت key-value نگه میدارد و حتی بعد از بستن مرورگر هم باقی میماند.معمولاً برای:preferenceهابعضی دادههای UIdraftهاtoken یا دادههای موقتاز دید تست:آیا دادهی حساس مثل Access Token یا اطلاعات شخصی در localStorage نگهداری شده؟آیا بعد از logout یا reset session داده پاک میشود؟آیا دادهی قدیمی باعث نمایش stale UI میشود؟Service WorkersService Worker اسکریپتی در مرورگر است که بین Browser و Network قرار میگیرد و میتواند درخواستها را intercept کند، فایلها را cache کند و تجربهی offline یا PWA را ممکن سازد.مثلاً ممکن است:فایلهای static را cache کندresponseهای خاص را ذخیره کنددر حالت offline نسخهی cached را برگردانداز دید تست:آیا بعد از release جدید، فایلهای قدیمی هنوز از service worker برمیگردند؟آیا دادهی offline و online درست sync میشود؟آیا cache invalidation در PWA درست انجام میشود؟Server-side cachingServer-side caching چیست؟در این مدل، داده در سمت Server یا در یک لایهی نزدیک به backend ذخیره میشود تا برای درخواستهای بعدی لازم نباشد دوباره محاسبه یا از Database خوانده شود.این مدل معمولاً برای:API responsesQuery resultssession datacomputed resultsreference dataاستفاده میشود.API Response Cachingگاهی پاسخ یک endpoint در سرور cache میشود.مثلاً اگر endpoint مربوط به لیست شعب بانک یا لیست کد کشورها باشد، لازم نیست هر بار از DB خوانده شود؛ میتوان response را مدتی cache کرد.مزیت:کاهش فشار روی DBافزایش سرعت پاسخبهبود throughputریسک:اگر داده تغییر کند ولی cache invalidate نشود، API stale response میدهدMemory Cacheدر این مدل داده در حافظهی RAM خود اپلیکیشن یا سرویس ذخیره میشود.مثلاً:mapهای درونبرنامهایin-process cacheobject cacheمزیت:بسیار سریعساده برای دادههای سبک و پرتکرارمحدودیت:معمولاً بین چند instance مشترک نیستبا restart سرویس از بین میروددر سیستم distributed میتواند باعث cache inconsistency بین instanceها شودRedisRedis یکی از رایجترین ابزارهای in-memory cache و key-value store است.در Backend از Redis برای این موارد زیاد استفاده میشود:caching API resultsession storagerate limitingtoken blacklisttemporary business datadistributed lockمزیتهای Redis:سریعمناسب برای حجم زیاد درخواستTTL و expiration دارددر معماری distributed کاربردی استاز دید تست:آیا داده بعد از update در DB در Redis invalidate میشود؟آیا TTL درست تنظیم شده؟آیا cache key درست طراحی شده؟آیا دادهی قدیمی از Redis برمیگردد؟Cache InvalidationCache Invalidation چیست؟یعنی وقتی دادهی اصلی تغییر میکند، Cache باید بهروز، حذف یا refresh شود تا دادهی قدیمی برنگردد.این یکی از مهمترین بخشهای تست caching است.مثال:نام مشتری در DB تغییر میکندولی GET /customers/123 هنوز نام قبلی را از Redis برمیگردانداین یعنی stale cache یا failure در cache invalidationProxy / CDN cachingCDN چیست؟CDN یا Content Delivery Network شبکهای از سرورهای توزیعشده است که محتوای static را نزدیکتر به کاربر cache و سرو میکند.معمولاً برای اینها استفاده میشود:imagesCSSJavaScriptfontsو گاهی بعضی responseهای cacheableهدف:کاهش latencyکاهش بار روی origin serverافزایش سرعت لودProxy Cacheگاهی بین Client و Server یک Proxy یا Gateway وجود دارد که responseها را cache میکند.این لایه میتواند:درخواستهای تکراری را سریعتر پاسخ دهدبار backend را کم کندولی اگر نادرست تنظیم شود، دادهی قدیمی یا اشتباه بدهددر تست چه ریسکهایی داریم؟فایل JS/CSS جدید deploy شده ولی CDN نسخهی قبلی را میدهدتصویر یا asset جدید به کاربر نمایش داده نمیشودendpointی که نباید cache شود، اشتباهی cache شدهresponse مخصوص یک کاربر به کاربر دیگر leak شود اگر cache policy اشتباه باشدHTTP Caching Headersبخش خیلی مهم این سرفصل همینجاست.این Headerها تعیین میکنند Client، Proxy یا CDN چگونه و تا چه مدت response را cache کنند.Cache-ControlCache-Control چیست؟مهمترین Header برای کنترل رفتار cache است.با Cache-Control مشخص میکنیم:آیا response cacheable هست یا نهکجا cache شودچه مدت معتبر بماندآیا قبل از استفاده باید revalidate شود یا نهمثال:Cache-Control: max-age=3600 یعنی response تا 3600 ثانیه معتبر است و میتواند از cache استفاده شود.directiveهای مهم Cache-Controlmax-ageمدت اعتبار response در cache را مشخص میکند.مثال:Cache-Control: max-age=600 یعنی تا 10 دقیقه response میتواند از cache استفاده شود.no-cacheاسمش گمراهکننده است.no-cache لزوماً یعنی «اصلاً cache نکن» نیست؛ یعنی قبل از استفاده از نسخهی cached باید با سرور revalidate شود.no-storeیعنی response اصلاً نباید ذخیره شود؛ نه در browser cache، نه در proxy cache.برای دادههای حساس مثل:اطلاعات حساباطلاعات شخصیپاسخهای امنیتیخیلی مهم است.publicیعنی response میتواند در cacheهای shared مثل CDN یا proxy هم ذخیره شود.privateیعنی response مخصوص یک کاربر است و نباید در cacheهای shared ذخیره شود؛ فقط cache خصوصی client مجاز است.برای responseهای شخصی یا auth-based خیلی مهم است.ETagETag چیست؟ETag یک شناسهی نسخه یا fingerprint برای یک resource است.Server همراه response یک ETag میدهد، مثلاً:ETag: "v1-customer-123" بعد در درخواست بعدی، Client میتواند بگوید:If-None-Match: "v1-customer-123" اگر resource تغییر نکرده باشد، Server میتواند بهجای برگرداندن کل body، فقط 304 Not Modified بدهد.مزیت ETagکاهش حجم responserevalidation هوشمندتشخیص تغییر یا عدم تغییر resourceاز دید تسترباید بررسی کنی:آیا بعد از تغییر داده، ETag هم تغییر میکند؟آیا If-None-Match درست کار میکند؟آیا در صورت unchanged بودن resource، 304 برمیگردد؟Last-ModifiedLast-Modified چیست؟زمان آخرین تغییر resource را نشان میدهد.مثال:Last-Modified: Wed, 25 Jun 2026 10:00:00 GMT بعد Client میتواند در request بعدی بگوید:If-Modified-Since: Wed, 25 Jun 2026 10:00:00 GMT اگر از آن زمان چیزی تغییر نکرده باشد، Server میتواند 304 Not Modified بدهد.تفاوت ETag و Last-ModifiedLast-Modified مبتنی بر زمان آخرین تغییر استETag مبتنی بر نسخه/شناسهی محتواست و معمولاً دقیقتر استExpiresExpires چیست؟یک Header قدیمیتر برای مشخصکردن زمان انقضای cache است.مثال:Expires: Wed, 25 Jun 2026 12:00:00 GMT یعنی تا آن زمان response میتواند از cache استفاده شود.امروزه معمولاً Cache-Control مهمتر و رایجتر از Expires است، ولی ممکن است هر دو را ببینی.304 Not Modifiedاین Status Code در caching خیلی مهم است.وقتی Client با If-None-Match یا If-Modified-Since درخواست میفرستد و resource تغییر نکرده، Server میتواند 304 Not Modified بدهد؛ یعنی:body جدید لازم نیستاز نسخهی cached استفاده کنStale DataStale Data چیست؟یعنی دادهای که از cache برگشته ولی دیگر نسخهی بهروز سیستم نیست.مثلاً:مشتری آدرسش را تغییر دادهدر DB درست ذخیره شدهولی API هنوز آدرس قبلی را از cache برمیگردانداین یکی از مهمترین failureهای مرتبط با caching است.Cache Hit / Cache MissCache Hitدرخواست از cache پاسخ گرفته و لازم نبوده به منبع اصلی برود.Cache Missداده در cache نبوده یا منقضی شده و سیستم مجبور شده از DB، origin یا backend داده را دوباره بگیرد.این دو مفهوم برای تحلیل performance و debugging مهماند.اهمیت این سرفصل برای Backend TesterBackend Tester باید بتواند:تشخیص دهد داده از DB آمده یا از Cacheریسک stale data را در سناریوهای update و read بررسی کندCache-Control, ETag, Last-Modified, Expires را تحلیل کندفرق client-side, server-side و CDN caching را بداندبعد از تغییر داده، invalidation و refresh را تست کندتشخیص دهد چه responseهایی private هستند و نباید shared cache شوندنکته امتحانی مهمدر پاسخ امتحانی فقط نگویید:caching برای افزایش سرعت است.این جواب ضعیف است. پاسخ خوب باید این کلیدواژهها را داشته باشد:client-side cache, server-side cache, CDN/proxy cache, stale data, cache invalidation, Cache-Control, ETag, Last-Modified, Expires, 304 Not Modified, performance vs data freshnessنمونه پاسخ کامل کوتاهCaching مکانیزمی برای ذخیرهسازی موقت داده یا response در لایههای مختلف سیستم است تا درخواستهای بعدی سریعتر پاسخ داده شوند و بار روی backend کاهش یابد. Cache میتواند در سمت Client مثل browser cache، localStorage و service worker، در سمت Server مثل memory cache یا Redis، یا در لایههای Proxy/CDN انجام شود. در تست API، caching فقط مسئلهی performance نیست، بلکه مسئلهی data freshness و جلوگیری از stale response هم هست. برای کنترل caching در HTTP از Headerهایی مثل Cache-Control, ETag, Expires و Last-Modified استفاده میشود و تستر باید بررسی کند که بعد از تغییر داده، cache درست invalidate شود و response قدیمی برنگردد.کلیدواژههاCaching Client-side Cache Browser Cache Cookies localStorage Service Worker Server-side Cache Redis Memory Cache CDN Proxy Cache Cache Invalidation Stale Data Cache-Control ETag Expires Last-Modified If-None-Match If-Modified-Since 304 Not Modified Cache Hit Cache Miss Performance Latency Data FreshnessCaching (ذخیرهسازی موقت داده یا response برای استفادهی سریعتر در درخواستهای بعدی): برای بهبود Performance، کاهش Latency و کاهش بار روی Backend استفاده میشود.Client-side Cache (ذخیرهسازی داده در سمت Client مثل Browser یا App): برای کاهش درخواستهای تکراری و بهبود سرعت نمایش داده در سمت کاربر استفاده میشود.Browser Cache (کش داخلی مرورگر برای فایلها و responseها): برای ذخیرهی CSS، JS، Image و گاهی responseهای API استفاده میشود.Cookies (دادههای کوچک ذخیرهشده در مرورگر): برای session، authentication، tracking یا preference استفاده میشوند و باید از نظر امنیتی و ماندگاری بررسی شوند.localStorage (فضای ذخیرهسازی key-value در مرورگر): برای نگهداری دادههای UI، draftها یا بعضی tokenها استفاده میشود و ریسک نگهداری دادهی حساس دارد.Service Worker (اسکریپت واسط بین Browser و Network): برای offline support، PWA caching و intercept کردن requestها استفاده میشود.Server-side Cache (کش در سمت سرور یا لایه نزدیک به backend): برای ذخیرهی API response، query result یا دادههای پرتکرار بهکار میرود.Redis (in-memory key-value store پرکاربرد برای caching): برای API response caching، session storage، rate limiting و دادههای موقت استفاده میشود.Memory Cache (کش داخل حافظهی اپلیکیشن): برای دسترسی سریع به دادههای پرتکرار استفاده میشود ولی معمولاً بین چند instance مشترک نیست.CDN (شبکهی توزیع محتوا برای cache و تحویل سریعتر فایلهای static): برای image، CSS، JS و کاهش latency در کاربران جغرافیایی مختلف استفاده میشود.Proxy Cache (کش در لایهی میانی بین Client و Server): برای کاهش بار backend و پاسخ سریعتر به درخواستهای تکراری استفاده میشود.Cache Invalidation (حذف یا بهروزرسانی cache پس از تغییر دادهی اصلی): برای جلوگیری از stale data و ناسازگاری بین cache و DB حیاتی است.Stale Data (دادهی قدیمیای که هنوز از cache برمیگردد): یکی از failureهای مهم در تست API و backend است.Cache-Control (Header اصلی برای کنترل رفتار cache): برای تعیین max-age، no-store، no-cache، public و private استفاده میشود.ETag (شناسه یا fingerprint نسخهی یک resource): برای cache revalidation و تشخیص تغییر یا عدم تغییر resource استفاده میشود.Expires (زمان انقضای response در cache): Header قدیمیتر برای تعیین زمان اعتبار cache است.Last-Modified (زمان آخرین تغییر resource): برای conditional request و تشخیص تغییر resource استفاده میشود.If-None-Match (Header درخواست برای ارسال ETag قبلی به سرور): در revalidation استفاده میشود تا اگر resource تغییر نکرده بود، 304 برگردد.If-Modified-Since (Header درخواست بر اساس زمان آخرین تغییر): برای conditional request بر مبنای Last-Modified استفاده میشود.304 Not Modified (Status Code مربوط به unchanged بودن resource): به Client میگوید از نسخهی cached استفاده کند و body جدید لازم نیست.Cache Hit (پاسخگرفتن از cache): نشان میدهد داده از cache برگشته و نیازی به مراجعه به منبع اصلی نبوده است.Cache Miss (نبودن داده در cache یا منقضی شدن آن): باعث میشود سیستم از DB، backend یا origin داده را دوباره بگیرد.Performance (کارایی و سرعت پاسخگویی سیستم): یکی از مهمترین اهداف استفاده از caching است.Latency (زمان تأخیر در پاسخ): caching با نزدیکتر کردن داده به مصرفکننده، latency را کاهش میدهد.Data Freshness (بهروز بودن دادهی نمایشدادهشده): در تست caching باید مطمئن شد cache باعث نمایش دادهی قدیمی نشده است.تست کیس های مربوط به cashing : TC — Sensitive Data Cache PolicyInput / Action:GET /v1/customers/12345 با token معتبر.Expected API/Cache /strong>Response نباید Cache-Control: public داشته باشد. برای داده حساس باید no-store یا حداقل private باشد.Expected Client/CDN /strong>CDN/Proxy نباید response مشتری را cache کند.Risk Covered:Data leakage از shared cache.کلیدواژههای جدیدCache Busting: تغییر نام یا version فایل static برای مجبور کردن browser/CDN به گرفتن نسخه جدید.Stale Response: پاسخ قدیمی که از cache برگشته و با DB هماهنگ نیست.Cache Consistency: هماهنگی بین دادهی cache و منبع اصلی مثل DB.Shared Cache: cache مشترک مثل CDN/Proxy که نباید دادهی شخصی در آن ذخیره شود.no-store: یعنی response اصلاً ذخیره نشود؛ مناسب دادههای حساس.