یک همکار Collection پستمن را باز میکند، Environment را انتخاب میکند و Run میزند؛ ۱۸ Request سبز میشوند. اما نمیداند کدام نسخهٔ API، کدام داده و Role، چه پیششرطی و چه Oracleای اجرا شده است. Token سازنده روی سیستم او نیست، سه Variable همنام از Scopeهای مختلف حل میشوند، Mock بهجای Staging پاسخ داده و Cleanup اجرا نشده است. آیا این Workspace قابلتحویل است؟ نه؛ فقط روی زمینهٔ پنهان سازنده کار کرده است.
این راهنما Postman را از «ابزار Send» به یک Postman Workspace Handoff System تبدیل میکند: Purpose و Owner، Request Contract، Variable/Secret boundary، Example/Mock، Oracle، Data/State، Run Manifest، Evidence، Version/Review و Clean-room Handoff. هدف آموزش همهٔ دکمههای Postman یا ساخت Harness پیشرفته نیست؛ هدف این است که Receiver مستقل بتواند Artifact را نصب، اجرا، تفسیر، عیبیابی و ایمن نگهداری کند.
پاسخ کوتاه: Workspace قابلتحویل چه ویژگی دارد؟
Workspace زمانی قابلتحویل است که یک Receiver مجاز و تازهوارد، بدون حافظهٔ شفاهی سازنده بتواند نسخهٔ درست Collection/Environment را پیدا کند، Secret را از مسیر مجاز تأمین کند، دادهٔ مصنوعی را Setup کند، Selection مشخص را اجرا کند، Verdict را از Assertionهای معنادار بفهمد، Evidence پاکسازیشده را تحویل دهد، Cleanup را تأیید کند و یک تغییر نماینده را با Review/rollback مدیریت کند.
| Artifact | سؤال Handoff | شاهد | اگر غایب باشد |
|---|---|---|---|
| Collection | چه رفتار/ریسکی و با چه نسخهای؟ | Purpose، Contract، version/digest | HOLD |
| Environment | مقصد و Scope دقیق چیست؟ | Variable contract و unresolved check | INVALID Run |
| Secret | از کجا و برای چه Role/TTL؟ | reference، نه value | STOP/INVALID |
| Data/State | چه چیزی ساخته و پاک میشود؟ | seed، namespace، setup/cleanup receipt | INCONCLUSIVE |
| Oracle | چرا Pass/Fail؟ | Expected/Actual و source | NO VERDICT |
| Run | دقیقاً چه چیزی اجرا شد؟ | Manifest، selection، attempts، report | غیرقابلبازتولید |
| Change | چه کسی بازبینی/بازیابی میکند؟ | diff، review، target-fault، rollback | HOLD |
مرز این مقاله با آموزش Postman و تست API
برای ساخت Request، Environment، Assertion، Correlation، دادهٔ CSV و اجرای CLI، آموزش عملی تست API با Postman مالک موضوع است. مبانی HTTP، روشها و انواع آزمون در راهنمای تست API آمده و طراحی Oracle چندلایه، Idempotency، State، Side effect، Race و Harness در راهنمای API Test Harness پیشرفته پوشش داده میشود. این صفحه روی قابلیت تحویل و ادارهٔ Workspace تمرکز دارد.
Postman پادشاه یا ضرورت جهانی نیست
Postman یک Client/Collaboration/Automation option است، نه شرط فهم API یا جایگزین cURL، code-first harness، contract test یا observability. GUI شروع و Exploration را آسان میکند؛ در مقابل، Plan، Cloud policy، Export fidelity، review workflow، CLI compatibility، lock-in، دسترسی ایران و نگهداری Script هزینه دارند. انتخاب باید با Task و Handoff trial انجام شود، نه محبوبیت یا رزومه.
Workspace، Collection و Environment را نقشدار کنید
Workspace مرز همکاری و دسترسی است؛ Collection مجموعهٔ versioned Request/Script/Example و Documentation؛ Environment مجموعهٔ configuration برای یک context؛ Vault/Secret store مرز مقدار حساس؛ و Run artifact شاهد یک Execution. همه را یک فایل یا لینک واحد تصور نکنید.
WORKSPACE CHARTER workspace_id: PWH-SYN-042 purpose: بررسی Handoff جریان مصنوعی Checkout API audience: QA / developer / CI maintainer with approved access owner / backup / reviewer: authoritative_sources: OpenAPI digest + risk register + policy URLs included: collection, examples, non-secret environment template, runbook excluded: real token, production data, performance/load claim decision_supported: READY / HOLD for receiver execution access_roles: admin / editor / viewer review_at / retire_trigger: not_claimed: API quality, security, production readiness
Access را با کمترین اختیار بدهید
مستندات فعلی Postman برای Workspace نقشهای Admin، Editor و Viewer و برای Elementها نقشهای جدا تعریف میکند. Viewer ممکن است بتواند resource را ببیند، fork یا export کند؛ پس «فقط مشاهده» لزوماً به معنی عدم خروج داده نیست. Owner باید visibility، membership، export/public-doc/mock-log و حذف دسترسی را متناسب با داده کنترل کند.
Workspace عمومی یا لینک مستندات عمومی را با همکاری داخلی یکی نگیرید. Example، Header، Body و Mock call log ممکن است داده حساس حمل کنند. Inventory دسترسی، owner/backup، review دورهای و offboarding لازم است؛ تعداد collaborator شاخص کیفیت نیست.
Collection را بر Decision Flow سازمان دهید
درخت صرفاً Endpointمحور برای Handoff کافی نیست؛ Receiver باید بداند چرا و با چه ترتیب/استقلالی اجرا میشود. یک ساختار نمونه:
SYN Checkout Handoff ├── 00 Readiness (config, auth, dependency probes) ├── 10 Create order — happy + contract ├── 20 Payment callback — duplicate/late/reordered ├── 30 Authorization — role/tenant negatives ├── 40 Read model — eventual state ├── 90 Diagnostics — non-gating, explicitly selected └── 99 Cleanup — idempotent receipt
شمارهگذاری فقط ترتیب را نشان میدهد؛ وابستگی پنهان را حل نمیکند. هر Folder باید هدف، Entry، created state، consumed variables، Cleanup، selection label، gate effect و امکان اجرای مستقل را مستند کند.
برای هر Request یک Contract بنویسید
REQUEST CONTRACT request_id / version: question / risk / requirement source: actor / tenant / role / authority: method / URL template / protocol: headers and body schema/units: pre-state / setup / data lineage: expected response + state + side effects: forbidden response / forbidden effects: oracle sources and confidence: produced / consumed variables with scopes: evidence allowlist / redaction: cleanup / retry / idempotency rule: gate effect / owner / review_at: not_claimed:
GET همیشه safe یا بدون side effect نیست؛ POST همیشه create نیست؛ ۲۰۰ همیشه Success کسبوکار نیست و ۲۰۱ ذخیرهٔ پایدار را ثابت نمیکند. Contract محصول و semantics واقعی منبع انتظارند. Method/status را بهعنوان Signal بسنجید، نه Verdict کامل.
Request resolved را بررسی کنید، نه Template را
{{base_url}}/orders/{{order_id}} خواناست، اما چیزی که شبکه میبیند مقدار resolved است. Shadowing، مقدار خالی، whitespace، encoding، query duplicate، Header inheritance و Body type میتواند Request دیگری بسازد. پیش از Handoff، resolved method/host/path/query/header allowlist/body digest را در Run ثبت کنید؛ Secret را چاپ نکنید.
Variable Scope را قرارداد کنید
طبق مستندات فعلی Postman، Scopeها از broad به narrow شامل Global، Collection، Environment، Data و Local هستند و مقدار Scope نزدیکتر precedence میگیرد. نام یکسان در چند Scope ممکن است Run سازنده و Receiver را متفاوت کند. Global را تا حد ممکن حذف و هر Variable را ownerدار کنید.
| Variable | Scope | Source/TTL | Share/Export |
|---|---|---|---|
base_url | Environment | environment registry | template قابلاشتراک |
api_version | Collection | contract version | بله |
run_id | Local | هر Run | خیر |
order_id | Local/Collection runtime محدود | Setup؛ تا Cleanup | initial خالی |
product_id | Data | versioned fixture | فقط مصنوعی |
access_token | Vault/CI secret | issuer؛ کوتاهعمر | هرگز value |
Postman Variableها را String نگه میدارد؛ Object/Array باید serialize/parse شوند و عدد/Boolean در Body نباید ناخواسته quoted شوند. Contract شامل type، allowed pattern، producer/consumer، fallback، required/optional، empty handling و unset زمان پایان است.
Unresolved و Shadowed Variable باید Run را Invalid کند
اگر {{base_url}} حل نشده، Request نباید با URL عجیب ادامه یابد. اگر tenant_id هم در Global و هم Data وجود دارد، Manifest باید مقدار مؤثر و منبع Scope را بدون داده حساس نشان دهد. Default پنهان، Environment اشتباه یا selected-none نباید به PASS تبدیل شود.
Secret را Variable معمولی ننامید
مستندات امنیتی Postman استفاده از Local scope برای جلوگیری از sync، Secure variable و Vault برای API key/token/password را پیشنهاد میکند. این قابلیتها بخشی از کنترلاند، نه تضمین: Script، Console، Example، Export، Report، Mock log یا خطای API هنوز میتواند Secret را افشا کند.
SECRET CONTRACT secret_ref: checkout-test-token (never value) purpose / actor / role / tenant: issuer / retrieval channel: storage: local vault or approved CI store allowed consumers: TTL / rotation / revocation: log-export-example-mock policy: DENY VALUE redaction test / owner: missing-secret verdict: INVALID, never SKIP/PASS incident route:
برای مرزهای OAuth/OIDC از راهنمای تست OAuth ۲.۰ و OIDC استفاده کنید. Token Admin مشترک پوشش Role را از بین میبرد؛ Token واقعی مشتری و Production نیز دادهٔ تست نیست.
Import از cURL را مثل ورود داده حساس بررسی کنید
Copy as cURL از Browser ممکن است Cookie، Authorization، CSRF token، query PII، internal host و fingerprint Header را وارد کند. قبل از Import، فقط در محیط مجاز و با Redaction ساختاری کار کنید؛ سپس Auth را به Secret reference، host را به Environment و داده را به Fixture مصنوعی تبدیل کنید. Raw cURL را در Ticket/Chat/AI نگذارید.
Example، Test و Evidence سه چیزند
در Postman، Example جفت Request و Response ذخیرهشده برای نمایش یک use case است. Example میتواند Documentation یا Mock را تغذیه کند، اما اجرای زنده یا Assertion نیست و ممکن است drift کند. Test یک قاعدهٔ executable است؛ Evidence خروجی versioned یک Run مشخص. این سه را با Label و lifecycle جدا نگه دارید.
EXAMPLE CONTRACT example_id / request_id: scenario: success / validation / auth / conflict source: synthetic authored | captured then approved/redacted request/response contract version: status / headers allowlist / body schema: dynamic fields and placeholders: mock matching fields: documentation audience: freshness check / owner / expires_at: not_evidence_of: live backend behavior
Mock Server حقیقت Backend نیست
مستندات Postman توضیح میدهد Mock بر اساس Example و تطبیق method/path پاسخ میدهد. بنابراین Mock صحت پیادهسازی، State، Authorization، persistence، side effect، concurrency، performance یا failure recovery را ثابت نمیکند. Run Manifest باید target را MOCK/SIMULATOR/TEST/SANDBOX مشخص کند و Verdict را به همان Fidelity محدود سازد.
Mock call log نیز ممکن است Header/Body را نگه دارد؛ retention و دسترسی آن را بررسی کنید. API key خصوصی Mock را با Token محصول یکی نگیرید. اگر Mock پاسخ Success را به هر Body میدهد، Frontend demo ممکن است سبز باشد ولی Contract interaction آزموده نشده باشد.
Assertion را به Claim وصل کنید
مستندات رسمی Postman نشان میدهد Scriptهای Post-response میتوانند status، header، body، type و response time را Assert کنند و در Collection/Folder/Request سطحهای مختلف اجرا شوند. وجود Assertion به معنی کافیبودن Oracle نیست؛ نام Test باید Claim و Failure را توضیح دهد.
pm.test("order response identifies this run and canonical IRR amount", () => {
const body = pm.response.json();
pm.expect(body.run_id).to.eql(pm.variables.get("run_id"));
pm.expect(body.currency).to.eql("IRR");
pm.expect(body.amount).to.eql(Number(pm.iterationData.get("amount_irr")));
});
این Assertion هم هنوز persistence یا Ledger effect را ثابت نمیکند. Oracle را بر اساس ریسک در Response، State، side effect، Security و Evidence لایهبندی کنید. چرخهٔ هر Automated Check—از ارزش تا Retirement—در راهنمای lifecycle تست خودکار آمده است.
Status ۲۰۰ و Schema شرط لازماند، نه Pass کامل
API ممکن است ۲۰۰ و JSON معتبر بدهد اما سفارش کاربر دیگر، مبلغ تومان بهجای ریال، state قدیمی، effect تکراری یا error داخل body داشته باشد. برعکس، ۴۰۹ ممکن است Outcome قراردادی صحیح برای conflict باشد. Verdict باید از Request Contract و Oracle بیاید، نه رنگ سبز Status.
Response time زیر ۲۰۰ms ادعای Performance نیست
pm.response.responseTime اندازهٔ یک تعامل با مسیر/شبکه/بار مشخص است. Threshold ثابت ۲۰۰ms بدون percentile، warm-up، workload، region، dependency، sample size و baseline فقط Smoke observation است. برای SLO یا Regression عملکرد از آزمایش کنترلشده و توزیع استفاده کنید؛ یک Request پستمن جای Load Test نیست.
Script inheritance را آشکار کنید
Script سطح Collection، Folder و Request میتواند روی یک Request اجرا شود. Receiver باید order، helper dependency، mutation متغیر و cleanup را ببیند. Assertion مشترک content-type مفید است؛ اما Script والد نباید response نامربوط را parse یا Failure را catch و پنهان کند. نام/نسخهٔ Package یا helper و Compatibility CLI را ثبت کنید.
دادهٔ تست را با Run namespace بسازید
CSV/JSON صرفاً ورودی است؛ lineage، type، valid/invalid class، seed، owner، TTL و Cleanup هم لازماند. در سناریوی ایران، پول canonical با واحد صریح IRR ذخیره و تومان فقط presentation label باشد؛ اعداد فارسی/عربی/لاتین، ی/ی، ک/ک، ZWNJ و RTL/LTR را بهعنوان boundaryهای مصنوعی نسخهدار کنید.
DATA MANIFEST
dataset_id: SYN-CHECKOUT-FA-07
classification: fully synthetic / no customer / no PAN / no national ID
schema_version / digest:
seed: 140507
run_namespace: {{run_id}}
actors: customer-17, support-readonly, stranger-18
money: 1250000 IRR; display-only 125000 تومان
time: UTC instant; Asia/Tehran display; Jalali presentation only
state_factory / cleanup endpoint:
TTL / residual-data query:
not_representative_of: Iranian users, banking or production
Setup و Cleanup باید قابلمشاهده باشند
Setup پنهان در History یا حساب سازنده Handoff را میشکند. Readiness folder باید config، identity، dependency و test-data capability را بسنجد؛ Cleanup باید idempotent، مجاز و دارای receipt باشد. شکست Setup را Product FAIL ننامید و شکست Cleanup را با PASS اصلی پنهان نکنید.
Run Manifest را پیش از اجرا Freeze کنید
POSTMAN RUN MANIFEST run_id / attempt / triggered_by / started_at_utc: decision / risk / environment target: collection version + digest: environment template version + effective non-secret digest: runner + version / OS / network zone: data version + seed + rows: selection: folders/requests/tags; expected count: excluded / skipped / reason: actor/role/tenant references: secret refs and TTL (never values): mock/sandbox/test boundary: timeouts/retries/delay policy: reporters / evidence path / redaction policy: cleanup owner: not_claimed:
Manifest بعد از Run نباید بیردپا تغییر کند. Zero selected، Environment missing، Secret missing، dataset empty یا unsupported runner باید INVALID باشد، نه خروج موفق.
Verdict محصول را از سلامت Run جدا کنید
| وضعیت | معنا | اقدام |
|---|---|---|
| PASS | Oracleهای انتخابشده روی Run معتبر پاس | Claim محدود |
| FAIL | Expected/Actual معتبر ناسازگار | Finding/diagnosis |
| INCONCLUSIVE | Evidence برای Verdict کافی نیست | بررسی/تکرار مجاز |
| INVALID | Config/auth/data/selection/runner/redaction غلط | محصول قضاوت نشود |
| NOT_RUN | عمداً/ناخواسته اجرا نشده | Coverage gap |
| CANCELLED | Run پایان نیافته | اثر و Cleanup بررسی شود |
Retry نتیجهٔ Attempt اول را پاک نکند
Attempt ۱ FAIL و Attempt ۲ PASS برابر «PASS ساده» نیست. Run ID، Attempt، علت Retry، state reset، first result و final policy را جدا نگه دارید. Retry میتواند race، dependency، stale token یا Flaky Oracle را تشخیصپذیر کند؛ نباید آن را سبز و فراموش کند.
Evidence Bundle باید مفید و کمینه باشد
RUN EVIDENCE INDEX run/attempt/manifest digest: request_id + contract version: resolved method + URL template (no secret/query PII): request body digest / allowed sample: status + allowed headers + redacted response: assertion expected/actual: state/side-effect probe references: trace/correlation reference: runner exit code + report digest: cleanup receipt / residual state: verdict / confidence / limits: retention / access / deletion_at:
Console dump کامل Evidence خوب نیست. Authorization، Cookie، API key، PII و Body حساس را با Allowlist حذف کنید؛ Body بزرگ را digest و نمونهٔ محدود نگه دارید. برای تبدیل Failure به گزارش قابلبازتولید، قرارداد گزارش باگ و Evidence را ببینید.
Diagnosis را از Assertion name شروع کنید
«Test ۱ failed» Handoff نیست. Failure record باید Request/Assertion، expected/actual، API/Check/Data/Environment/Dependency/Configuration/Unknown classification، evidence، alternatives و confidence داشته باشد. ۴۰۱ در happy-path ممکن است Setup/Auth invalid باشد؛ همان ۴۰۱ در negative-auth test میتواند PASS باشد.
Collection Runner مساوی Regression Suite نیست
Runner فقط Collection و iterationها را اجرا میکند. Regression claim به Risk/coverage، version، independent Oracle، target-fault، data/state isolation، repeatability، valid selection، report و maintenance نیاز دارد. ۱۰۰ Request بدون Assertion مفید یا با Mock اشتباه، Regression evidence نیست.
CLI Handoff را روی Export واقعی بیازمایید
Postman CLI و Newman یکسان نیستند و Feature/Package/Vault/Cloud/report compatibility ممکن است فرق کند. مستندات Newman میگوید Exit code به CI متصل میشود و Reporter میتواند Run را export کند؛ اما command نمونه باید با Runner پینشدهٔ تیم اجرا شود.
# synthetic example; pin versions and use approved secret injection newman run checkout.collection.json \ -e staging.template.environment.json \ -d synthetic-orders.csv \ --reporters cli,junit \ --reporter-junit-export artifacts/postman.xml # gate separately verifies: # expected_request_count > 0 # environment/secret/data readiness # newman exit code # redaction scan # cleanup receipt
Secret را در command line، exported Environment یا CI log نگذارید. Process args ممکن است دیده شود. Inject را با Secret store و policy Runner طراحی کنید. CLI green با zero selection یا ignored exit code ممنوع است.
CI باید Collection را consumer باشد، نه حافظهٔ پنهان
Pipeline باید artifact/digest، runner version، selection، environment template، data، secret refs، network zone، reports، cleanup و retention را declarative کند. فایل Local اصلاحشدهٔ لپتاپ نباید authority باشد. Handoff موفق یعنی Clean runner بدون cache شخصی همان contract را اجرا کند.
Version Control داخلی Postman را با Review Contract کامل کنید
Postman برای Collection/Environment/Specification فرایند Fork، تغییر، Pull Request و Merge دارد. این قابلیت Diff و collaboration میدهد، اما review quality، branch policy، source authority، export snapshot و rollback را خودکار تضمین نمیکند.
WORKSPACE CHANGE RECORD change_id / parent version / proposed version: reason / affected contracts / risks: diff: request, script, example, variable, access, mock, docs secret scan / public exposure scan: target-fault expected to fail before and pass after: clean-room run + manifest + report: reviewer / decision / rationale: merge/export digest: rollback / compatibility / migration: docs and receiver notification: supersedes / retire_at:
مستندات زنده به freshness و drift control نیاز دارند؛ راهنمای مستندات تست زنده برای Authority، dependency و correction الگو میدهد.
Target-fault نشان میدهد Oracle واقعاً کار میکند
برای یک تغییر، پاسخ یا Simulator مصنوعی را طوری تغییر دهید که Fault هدف فعال شود: مبلغ IRR ده برابر کم، tenant اشتباه، duplicate side effect یا status سبز با state غلط. Test مرتبط باید به دلیل درست FAIL کند؛ پس از repair PASS شود. اگر همیشه سبز است، Handoff تعداد Request را تحویل داده نه قدرت کشف.
Clean-room Handoff آزمون نهایی Receiver است
- Receiver تازه با نقش حداقل و بدون cache/history سازنده وارد میشود.
- Runbook را فقط از Authority ثبتشده پیدا میکند.
- Collection/Environment template/dataset نسخهدار را دریافت و digest را تطبیق میدهد.
- Secret مجاز را از کانال مستقل و کوتاهعمر میگیرد.
- Readiness و expected selection count را اجرا میکند.
- Happy/negative/target-fault و Cleanup را با Manifest اجرا میکند.
- یک Failure را بدون تماس فوری با سازنده تشخیص میدهد.
- یک تغییر کوچک را Fork/Review/Merge یا فایلمحور با rollback انجام میدهد.
- Evidence redacted و limits را به Decision owner تحویل میدهد.
- Access/Secret موقت و داده را revoke/cleanup میکند.
اگر Receiver فقط با screen sharing سازنده موفق میشود، Knowledge transfer هنوز Artifact نشده است. برای معماری وسیعتر Handoff و Readiness اتوماسیون، نقشهٔ Automation Engineering Delivery را ببینید.
آزمایشگاه مصنوعی ایرانی: Workspace سبز اما غیرقابلتحویل
SYN-POSTMAN-HANDOFF-IR-01 کاملاً Offline و ساختگی است: Checkout، Order، PaymentAttempt، PSP Stub، Callback، Ledger و Reconciliation واقعی نیستند؛ دادهٔ مشتری، کارت، کد ملی، حساب، Token، شرکت یا Production وجود ندارد. IRR canonical و تومان presentation-only است؛ UTC برای Instant و Asia/Tehran/Jalali فقط نمایشاند.
SUPERFICIAL WORKSPACE 18 requests; all status assertions green response_time < 200ms on author laptop global base_url shadows staging environment shared admin token in exported environment mock URL accidentally selected order_id left from yesterday no dataset digest, expected selection or cleanup receipt example contains synthetic-looking but unlabeled customer data runner/version unknown; exit code ignored declaration: REGRESSION_READY_FOR_TEAM AUDIT RESULT target: HOLD causes: secret exposure, wrong target, hidden state, weak oracle, missing manifest/evidence/cleanup/version/receiver trial claim_limit: no real product, Postman account, API or incident
نسخهٔ اصلاحشده Global را حذف، base_url را Environment-owned، Token را Vault/CI reference، Dataset را versioned/seeded و target را TEST ثبت میکند؛ Response با Run ID/IRR/Role و State probe سنجیده، target-fault مبلغ غلط را میگیرد، expected count برابر ۱۸ و Cleanup receipt ثبت میشود. Receiver روی Clean runner اجرا میکند. خروجی فقط READY_FOR_POSTMAN_WORKSPACE_HANDOFF_REVIEW است، نه Regression یا Production readiness.
آزمایش تکرارپذیر: ۸۱۲ کنترل در برابر پنج علامت سبز
یک Validator مستقل و بدون dependency نوشتیم. ممیز سطحی «Postman پادشاه + Send=۲۰۰ + زیر ۲۰۰ms + Collection + Token مشترک» را آماده اعلام میکند؛ ممیز ساختاری ۵۸ گروه را با ۱۴ کنترل یکتا میسنجد.
$ node postman-workspace-handoff-validator.js POSTMAN_KING_SEND_200_FAST_COLLECTION_SHARED_TOKEN_REGRESSION_READY HOLD-812 NO_REAL_WORKSPACE_API_ACCOUNT_SECRET_PRODUCTION_RUN_PASS READY_FOR_POSTMAN_WORKSPACE_HANDOFF_REVIEW-0
خط اول عمداً غلط است. HOLD-812 نبود قراردادها را آشکار میکند. خط سوم تأیید میکند هیچ Workspace/API/account/secret/Production/customer/run/verdict واقعی استفاده نشده است. خروجی آخر فقط کاملبودن ساختاری Fixture اصلاحشده را نشان میدهد؛ نه صحت API، قدرت کافی Oracle، امنیت، performance، نبود نشت، سازگاری همهٔ Runnerها یا آمادگی Release.
ایران، Cloud و Offline fallback را واقعگرایانه بسنجید
دسترسی Postman Cloud، account، plan، package، mock، monitor، CLI download، registry یا API ثالث ممکن است بر اساس زمان/شبکه/سیاست تغییر کند؛ ادعای کلی «مسدود» یا «همیشه در دسترس» نکنید. با evidence تاریخدار بسنجید: آیا Collection/Environment بدون Secret export میشوند؟ آیا Runner/Dependency pin و mirror قانونی دارید؟ اگر Cloud unavailable شد، چه feature/coverage/history از دست میرود؟
Fallback میتواند cURL/code-first/local runner باشد، اما parity باید با target-fault و manifest آزموده شود. دورزدن دسترسی، حساب یا محدودیت Provider موضوع این مقاله نیست. داده/Secret/Artifact را بدون مجوز سازمانی به Cloud یا سرویس خارجی منتقل نکنید.
AI در Workspace: نویسنده نیست، پیشنهاددهنده است
Agent/AI میتواند Script، Example، Documentation یا test idea پیشنهاد دهد؛ اما خروجی را untrusted contribution بدانید. Prompt نباید Secret، cURL واقعی، customer body یا unpublished contract داشته باشد. انسان source/semantics، false-positive/negative، security، licence، maintainability و target-fault را بازبینی و Merge/Verdict را تأیید کند.
Retirement بخشی از Handoff است
Collection قدیمی بدون Owner خطرناکتر از نبود Collection است. Triggerهای Retirement: API version حذفشده، Oracle جایگزین، duplicate suite، unsupported Runner، Secret model ناامن، صفر usage، cost بالا یا انتقال به code-first. قبل از Archive، dependency/backlink/CI را پیدا، replacement و تاریخ را اعلام، Secret/access را revoke و Evidence لازم را طبق retention نگه دارید.
۲۸ ضدالگوی Postman Workspace
- Postman بهعنوان پادشاه/ضرورت جهانی
- حساب Cloud بهعنوان شرط ذخیرهٔ هر Collection
- Send و ۲۰۰ بهعنوان Test
- ۲۰۱ بهعنوان proof ذخیرهٔ واقعی
- Response زیر ۲۰۰ms بهعنوان Performance
- Runner بهعنوان Regression Suite
- Mock بهعنوان Backend proof
- Example بهعنوان Evidence زنده
- Global variable برای convenience
- نام یکسان در چند Scope بدون precedence audit
- Default پنهان برای Variable ضروری
- Token در Environment export
- Admin token مشترک
- Import cURL با Cookie/Auth
- Log کامل Request/Response
- Secret masking بهعنوان prevention کامل
- History سازنده بهعنوان Setup
- order_id باقیمانده از Run قبلی
- CSV بدون type/seed/version
- Chain طولانی بدون isolation
- Cleanup فقط در مسیر PASS
- Catch کردن Assertion و ادامهٔ سبز
- Retry تا سبز بدون Attempt history
- Zero selected با exit موفق
- تغییر مستقیم Collection بدون Review
- Documentation عمومی با Example حساس
- Handoff با جلسه بهجای clean-room trial
- Collection بدون Owner/expiry/retirement
چکلیست ۴۲ سؤالی تحویل Workspace
- Purpose/decision/not-claimed روشن است؟
- Owner، backup و receiver تعیین شده؟
- Workspace visibility و roles کمینهاند؟
- Export/public-doc/mock-log بررسی شده؟
- Authority source و version ثبت است؟
- Collection digest قابلتطبیق است؟
- Folderها flow/gate را نشان میدهند؟
- هر Request Contract دارد؟
- Method/URL/Header/Body semantics روشناند؟
- Resolved request بدون Secret ثبت میشود؟
- Global variable حذف شده؟
- Variable owner/type/scope/source/TTL روشن است؟
- Shadowing audit شده؟
- Unresolved variable Run را Invalid میکند؟
- Secret فقط reference دارد؟
- Role/Tenant/TTL/rotation مشخص است؟
- Log/export/example/mock redaction آزموده شده؟
- cURL imported پاکسازی شده؟
- Example مصنوعی/مجاز و versioned است؟
- Example از Evidence جداست؟
- Mock target و fidelity آشکار است؟
- Assertion به Claim وصل است؟
- Oracle فراتر از status/schema متناسب است؟
- Response time claim محدود است؟
- Script inheritance و helper version روشن است؟
- Dataset synthetic/type/seed/digest دارد؟
- Run namespace و State ownership روشن است؟
- Setup مستقل و observable است؟
- Cleanup idempotent و receiptدار است؟
- Manifest پیش از Run freeze شده؟
- Expected selection count غیرصفر است؟
- Attempt/Retry history حفظ میشود؟
- PASS/FAIL/INCONCLUSIVE/INVALID جداست؟
- Evidence allowlist/redaction/retention دارد؟
- Diagnosis alternatives/confidence دارد؟
- CLI/runner version پین شده؟
- Exit code و zero-selection gate کنترل میشوند؟
- Change diff/review/rollback دارد؟
- Target-fault به دلیل درست FAIL میشود؟
- Receiver clean-room run را کامل کرده؟
- Iran/Cloud/offline fallback و gap ثبت است؟
- Review/expiry/retirement فعال است؟
برنامهٔ ۳۰روزهٔ Handoff
روز ۱–۳: Charter، owner، inventory و access؛ روز ۴–۷: Request/Variable/Secret contracts؛ روز ۸–۱۰: Example/Mock cleanup و Source/version؛ روز ۱۱–۱۴: Oracle و target-fault؛ روز ۱۵–۱۸: Data/Setup/Cleanup/Manifest؛ روز ۱۹–۲۱: CLI/CI/Exit/Evidence؛ روز ۲۲–۲۴: Fork/Review/rollback؛ روز ۲۵–۲۷: Clean-room Receiver trial؛ روز ۲۸: gap repair؛ روز ۲۹: unavailable/offline drill؛ روز ۳۰: READY/HOLD/RETIRE review. تقویم ثابت نیست و ۳۰ روز readiness را تضمین نمیکند.
منابع رسمی و محدودیت استناد
- Postman Variables: Scope، precedence، String semantics و Vault reference در نسخهٔ فعلی؛ نه طراحی این Handoff.
- Postman Developer Security: Local/secure variables، Vault، access visibility و توصیههای امنیتی؛ نه تضمین عدم نشت.
- Postman Examples: تعریف Example و اتصال به docs/mock؛ نه Evidence یا صحت Backend.
- Postman Test Scripts: سطحهای Script و Post-response execution؛ نه کفایت Oracle.
- Postman Version Control: Fork/PR/review/merge قابلیت داخلی؛ نه جایگزین governance/rollback.
- Newman: Runner، reporter و exit-code integration؛ نه parity خودکار با همهٔ قابلیتهای Cloud/Postman CLI.
رابط، Plan و قابلیتهای Postman تغییر میکنند؛ مسیر تب و availability را با مستندات نسخهٔ خودتان تطبیق دهید. این مقاله تبلیغ یا ممیزی امنیتی Postman نیست و تجربهٔ ایران را بدون داده تعمیم نمیدهد.
جمعبندی: Artifact را تحویل دهید، نه حافظهٔ سازنده را
Workspace حرفهای با تعداد Request، رنگ سبز یا لینک Share سنجیده نمیشود. Contract را pin کنید، Scope و Secret را محدود کنید، Example/Mock/Test/Evidence را جدا نگه دارید، Manifest و Verdict روشن بسازید، target-fault اجرا کنید و Receiver را در Clean-room بیازمایید. اگر نفر دوم بدون شما نمیتواند اجرا و عیبیابی کند، Handoff هنوز HOLD است.
سوالات متداول
برای شروع Postman بهتر است مقالهٔ ۶۶۹ را بخوانم یا این صفحه را؟
اگر هنوز Request، Environment، Script، Correlation، Data Runner و CLI را نمیشناسید، ابتدا آموزش ۶۶۹ را اجرا کنید. این صفحه برای زمانی است که Artifact باید میان افراد/تیم/CI قابلبازتولید، reviewable و قابلنگهداری شود.
آیا ذخیره Token بهصورت Sensitive Variable کافی است؟
خیر. Mask/encryption بخشی از کنترل است؛ Script، Console، Export، Example، Report یا پاسخ API ممکن است آن را افشا کند. Vault/CI secret، کمترین Role، TTL/rotation، عدمچاپ، Redaction test و Incident route لازماند.
آیا Collection با همهٔ تستهای سبز آمادهٔ Regression است؟
نه لزوماً. باید Selection غیرصفر، Version/Data/Environment درست، Oracle متناسب، State/Cleanup سالم، target-fault، Attempts، Evidence و Runner معتبر باشد. Green روی Mock اشتباه یا state مانده، Regression evidence نیست.
Postman CLI بهتر است یا Newman؟
به feature، Plan، package/Vault، report، Cloud integration و محیط CI بستگی دارد. روی Collection نماینده و Fault هدف PoC بگیرید، نسخه را pin و Exit/report/secret parity را بسنجید؛ نام ابزار بهتنهایی تصمیم نیست.
چطور بفهمیم Handoff واقعاً موفق است؟
Receiver مجاز روی محیط Clean بدون cache/history سازنده، نسخهها را پیدا میکند، Secret را ایمن inject میکند، Run و target-fault و Cleanup را اجرا، Failure را تشخیص و یک تغییر را review/rollback میکند. جلسهٔ توضیح بهتنهایی شاهد Handoff نیست.
