تست جعبه خاکستری؛ راهنمای Gray-box Testing

کاربر روی «پرداخت» می‌زند، پاسخ دیر می‌رسد و دوباره تلاش می‌کند. از بیرون شاید فقط یک پیام موفق دیده شود؛ اما شما می‌دانید سیستم از Order Service، Outbox، Payment Orchestrator و callback درگاه تشکیل شده و کلید Idempotency باید از ساخت اثر مالی تکراری جلوگیری کند. همین دانش معماری باعث می‌شود Timeout، Retry و callback تکراری را هدف بگیرید و با Trace و یک نمای Read-only بررسی کنید واقعاً یک Order، یک Payment و یک Ledger effect ساخته شده است.

این نمونه تست جعبه خاکستری (Gray-box Testing) است: رفتار را از Interface معتبر آزمایش می‌کنید، اما برای انتخاب Test، ساخت State و تقویت Oracle از بخشی از دانش یا مشاهده‌پذیری داخلی کمک می‌گیرید. Gray-box نه «نصف Black-box + نصف White-box» است، نه یک سطح تست و نه مجوز دسترسی نامحدود به کد و داده.

پاسخ کوتاه: تست جعبه خاکستری چیست؟

واژه‌نامه رسمی NIST CSRC Gray-box Testing را روشی تعریف می‌کند که مقداری دانش از ساختار داخلی و جزئیات پیاده‌سازیِ موضوع ارزیابی را فرض می‌گیرد. این دانش ممکن است شامل معماری، Contract API، مدل داده، State machine، تنظیمات، بخشی از کد، حساب‌های نقش‌دار یا Telemetry باشد.

ویژگی تعیین‌کننده، میزان اطلاعات در اختیار طراح تست است. Test می‌تواند همچنان از API یا UI عمومی اجرا شود، ولی انتخاب ورودی، Failure mode و Oracle با آگاهی فنی هدفمندتر می‌شود.

سند فعلی ISTQB Security Test Engineer v1.۰.۱ نیز با اتکا به NIST همین تعریف را به کار می‌برد و نمونه اطلاعات Gray-box را بخشی از نقشه شبکه، مستند معماری، حساب کاربری یا دسترسی به یک ماشین داخلی می‌داند. این نمونه‌ها Context امنیتی‌اند و باید با مجوز و Scope همان ارزیابی تفسیر شوند.

Gray-box چه چیزی نیست؟

ترکیب درصدی Black و White نیست

نمی‌توان گفت یک Test «۳۰٪ سفید و ۷۰٪ سیاه» است. بهتر است دقیق بنویسیم چه اطلاعاتی در اختیار داریم، از کدام Interface استفاده می‌کنیم و چه مشاهده‌ای مجاز است.

سطح تست نیست

Gray-box را می‌توان در Component integration، System integration، System، Acceptance یا Security assessment به کار برد. Unit، Integration و System «سطح» هستند؛ Black/Gray/White بیشتر زاویه اطلاعات و Test basis را توصیف می‌کنند.

تکنیک مستقل و ثابت نیست

Equivalence Partitioning، Boundary Value، Decision Table، State Transition، Contract testing، Fault injection یا Exploratory testing می‌توانند با اطلاعات Gray-box طراحی شوند. «Matrix testing» یا «Pattern testing» به‌خودی‌خود تکنیک استاندارد Gray-box نیستند.

مجوز دسترسی نیست

دانستن نام Table یا مسیر سرویس، اجازه Query، تغییر داده، دورزدن Authorization یا اجرای تست مخرب نمی‌دهد. Authorization، محیط، Account، داده، Stop condition و Rules of Engagement باید جدا و کتبی باشند.

چهار محور یک تست Gray-box سالم

محور	سؤال	نمونه
Knowledge	چه اطلاعات داخلی داریم؟	معماری، State model، Schema، retry policy، Code slice
Access	به چه چیزی مجازیم نگاه کنیم؟	حساب Test، Trace، Log پاک‌سازی‌شده، Read-only view
Control	چه شرایطی را مجازیم بسازیم؟	Clock، Sandbox callback، Feature flag آزمایشی، Fault proxy
Oracle	درستی را از کجا می‌سنجیم؟	Response، State، Event، DB invariant، نبود Side effect

این چهار مورد را در Test case ثبت کنید. عبارت «تستر به Backend دسترسی دارد» هم مبهم است و هم از نظر امنیتی خطرناک.

Black-box، Gray-box و White-box را دقیق مقایسه کنیم

معیار	Black-box	Gray-box	White-box
دانش پیاده‌سازی	برای طراحی لازم نیست	جزئی و هدفمند	ساختار/کد مبنای مستقیم طراحی است
Test basis معمول	Requirement، Contract، رفتار بیرونی	رفتار بیرونی + Architecture/Data/State/Telemetry	Code، CFG، Branch/Condition/Data flow
Interface اجرا	عمومی یا قراردادی	عمومی به‌علاوه Hook/Observation مجاز	تابع، کلاس، Module یا Instrumentation داخلی
Oracle	Output و رفتار مشاهده‌پذیر	Output + Invariant/Trace/State داخلی	نتیجه + مسیر/ساختار کد
Coverage	Requirement/Rule/State/Risk	همان‌ها و در صورت Instrumentation بخشی ساختاری	Statement/Branch/Condition/Path و معیارهای ساختاری
ریسک اصلی	Gap داخلی دیده نشود	Overfit، دسترسی اضافی و Oracle وابسته به Implementation	تمرکز زیاد بر Code و ندیدن نیاز/رفتار کاربر

هیچ ستون ذاتاً «بهتر» یا «بی‌طرف‌تر» نیست. انتخاب به Risk، سؤال تست، Testability و هزینه شواهد بستگی دارد. برای مبانی دو سر طیف، راهنمای تست جعبه سیاه و راهنمای تست جعبه سفید و پوشش کد را ببینید.

Gray-box چه زمانی ارزش دارد؟

سیستم توزیع‌شده است و نتیجه نهایی چند Side effect دارد؛
رفتار به Cache، Queue، Retry، Idempotency یا eventual consistency وابسته است؛
خطا متناوب است و بدون Correlation/Trace بازتولید دشوار می‌شود؛
Authorization بر Role، ownership و State متکی است؛
Migration یا Backward compatibility باید هم از Interface و هم از داده سنجیده شود؛
Performance issue نیازمند ربط‌دادن Journey به Query/Dependency است؛
Feature flag یا Configuration مسیرهای متفاوت می‌سازد؛
Security assessment با اطلاعات محدود داخلی و حساب‌های مشخص انجام می‌شود؛
Change impact از Architecture یا Code diff برای Regression selection استفاده می‌کند.

چه زمانی Black-box را حفظ کنیم؟

وقتی Contract بیرونی خودِ موضوع ارزیابی است، استقلال از Implementation ارزش دارد یا تیم مصرف‌کننده واقعاً هیچ دانش داخلی ندارد. یک Consumer contract test نباید به Tableهای Provider وابسته شود.

چه زمانی White-box لازم است؟

وقتی هدف Branch/Condition/Data-flow coverage، صحت الگوریتم داخلی، Memory safety یا Mutation مشخص کد است. Gray-box جای Unit و Structural testing را نمی‌گیرد.

منابع دانش Gray-box

مستندات و مدل‌ها

Context/Container/Sequence diagram؛
API/AsyncAPI/Schema contract؛
State machine و Business rules؛
ERD یا Data dictionary؛
Retry، Timeout، Circuit breaker و Cache policy؛
Feature flag و Configuration matrix؛
Runbook، Incident و Known failure modes.

کد و تغییرات

گاهی Test designer بخشی از Pull request، Dependency graph یا Config را می‌خواند تا Impact area را پیدا کند، اما Test را از Interface عمومی اجرا می‌کند. این دانش Gray-box است؛ اگر Test مستقیماً Branch و Statement را هدف بگیرد و با Instrumentation پوشش را بسنجد، به Structural/White-box نزدیک می‌شویم.

Telemetry

Log، Trace و Metric می‌توانند مسیر واقعی Request، Retry، Dependency و Error را نشان دهند. Telemetry باید Correlation پایدار، دسترسی محدود و Redaction داشته باشد. نبود Log لزوماً نبود رفتار نیست؛ Sampling، Buffer و Delay را در Oracle لحاظ کنید.

دانش قدیمی خطرناک است

Architecture diagram منقضی می‌تواند Test را به مسیر اشتباه هدایت کند. هر منبع باید Owner، نسخه/Commit، تاریخ بازبینی و محیط معتبر داشته باشد. رفتار Production ممکن است با Branch یا محیط Test فرق کند.

قرارداد دسترسی و کنترل

قابلیت	نمونه امن	مرز
حساب	دو کاربر مصنوعی با Role و ownership متفاوت	بدون Credential واقعی یا Privilege نامرتبط
پایگاه داده	View پاک‌سازی‌شده و Read-only	بدون UPDATE/DELETE مستقیم برای Pass کردن Test
Observability	جست‌وجو با Correlation ID در محیط Test	Retention، RBAC و حذف PII
Feature flag	Namespace مختص Test و Audit	عدم تغییر Cohort واقعی یا Flag عمومی
Fault injection	Sandbox/Proxy با Scope و Stop condition	بدون اثر بر کاربر، سرویس مشترک یا طرف ثالث
Clock/Event	Fake clock و test-only event collector	Hook احرازشده و غیرفعال/حذف‌شده در Production

یک حساب Admin عمومی به نام «QA» راه‌حل Testability نیست. Least privilege، Audit، Expiry و تفکیک وظایف برای ابزار تست نیز لازم است.

فرآیند ۹ مرحله‌ای طراحی Gray-box Test

Risk و سؤال: دقیقاً چه شکست کسب‌وکاری یا فنی را می‌جوییم؟
System boundary: Componentها، Dependencyها و طرف ثالث داخل/خارج Scope را مشخص کنید.
Knowledge inventory: اطلاعات داخلی، نسخه و سطح اعتماد آن را ثبت کنید.
Access/RoE: Account، Query، Trace، Hook، محیط و اعمال ممنوع را تعیین کنید.
Hypothesis: دانش داخلی را به فرضیه قابل رد تبدیل کنید.
Test design: تکنیک، داده، State، Failure mode و Coverage را انتخاب کنید.
Layered oracle: نتیجه بیرونی، Invariant داخلی و نبود Side effect را تعریف کنید.
Execution/evidence: Correlation، Build، Config و Artifact حداقلی را ثبت کنید.
Review/cleanup: Failure را طبقه‌بندی، داده را پاک و Knowledge/Model را اصلاح کنید.

مثال کامل: Retry پرداخت و callback تکراری

معماری شناخته‌شده

Checkout API
  → Order DB
  → Transactional Outbox
  → Payment Orchestrator
  → Gateway Sandbox
  → Callback Handler
  → Ledger

Rule: برای یک order_id و idempotency_key، Retry درخواست و callback تکراری نباید بیش از یک اثر مالی نهایی بسازد.

دانش در اختیار تیم

Contract درخواست Checkout و callback؛
Stateهای Order و Payment؛
وجود Outbox و Retry policy؛
Invariant یکتایی اثر مالی؛
فرمت Correlation/Trace ID؛
View خواندنی پاک‌سازی‌شده برای Order/Payment/Ledger.

دسترسی مجاز

Gateway Sandbox و حساب‌های مصنوعی؛
ارسال درخواست از API عمومی Test؛
تکرار callback فقط در Sandbox؛
خواندن Trace و View مخصوص QA؛
عدم Mutation مستقیم DB یا Queue؛
عدم اجرای تست روی Production/درگاه واقعی.

ماتریس سناریوهای پرداخت

ID	محرک	دانش Gray-box	Oracle
G1	پرداخت موفق عادی	مسیر پایه Outbox→Gateway→Ledger	یک Order، Payment و Ledger effect
G2	Timeout کلاینت، Retry با همان Key	Idempotency scope و response replay	همان نتیجه؛ بدون Order/Payment دوم
G3	Retry با Key متفاوت برای همان Intent	Policy dedup دامنه‌ای	طبق Contract: رد، Merge یا Intent جدا؛ نه رفتار مبهم
G4	callback موفق دو بار	Gateway event identity	یک State transition و یک Ledger effect
G5	callback دیررس پس از Pending	State machine و reconciliation	رسیدن کنترل‌شده به Paid یا مسیر بررسی
G6	Outbox consumer موقتاً unavailable	Retry/backoff و DLQ policy	بدون از‌دست‌رفتن Event؛ بازیابی پس از رفع Fault
G7	callback با مبلغ/Order ناسازگار	Validation و ownership mapping	رد امن، Alert/Review و بدون اثر مالی

درخواست نمونه با Correlation

POST /api/checkout
Idempotency-Key: qa-g2-20260806-001
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
Content-Type: application/json

{
  "cart_id": "QA-CART-104",
  "gateway": "sandbox"
}

استاندارد W3C Trace Context قالب Headerهای انتشار Context میان سرویس‌ها را تعریف می‌کند. از Trace ID تستی برای Correlation استفاده کنید، اما مقدار تولیدی و سیاست Sampling را مطابق سیستم خود بسنجید.

Oracle چندلایه برای G2

لایه بیرونی

هر دو درخواست نتیجه قراردادی و قابل فهم دارند؛
Order ID یکسان یا رفتار مستند Idempotency برمی‌گردد؛
کاربر بین «نامشخص»، Pending و Paid گم نمی‌شود؛
Secret یا جزئیات داخلی در Error افشا نمی‌شود.

لایه State و داده

Expected invariant:
count(final_payment_effect where order_id = QA-ORDER-104) = 1
sum(captured_amount) = order.payable_amount
order.status is consistent with payment.status

بهتر است یک View تستی این Invariant را ارائه دهد. Test به Table name و joinهای شکننده Production وابسته نشود.

لایه Event/Trace

دو HTTP attempt با یک Intent قابل Correlate هستند؛
یک Logical payment flow نهایی داریم؛
Retry policy و Duplicate handling قابل مشاهده است؛
Trace یا Log حاوی شماره کارت، Token یا PII نیست.

نبود Side effect

فقط 200 و یک Row کافی نیست. پیامک، Inventory reservation، Coupon consumption، Commission و Notification تکراری را طبق Scope بررسی کنید.

Gray-box در تست API

دانش Schema، Versioning، Idempotency، Rate limit، ownership و Error mapping باعث طراحی Negative test بهتر می‌شود. اما Test از Contract اجرا و خروجی مصرف‌کننده را Assert می‌کند.

نمونه‌های مفید

Enum تازه‌ای که Client قدیمی نمی‌شناسد؛
فیلد Optional که Backend در یک مسیر Null می‌کند؛
Object ID متعلق به کاربر Test دوم؛
Retry پس از ۵۰۲ در نقطه‌ای که Side effect شاید ایجاد شده باشد؛
Pagination cursor وابسته به Sort داخلی؛
Cache key که Locale یا Role را جا انداخته است.

برای طراحی Contract، Authorization و Assertion از راهنمای تست API استفاده کنید.

Gray-box در یکپارچه‌سازی سرویس‌ها

دانش Queue topic، Retry، Timeout و Schema compatibility کمک می‌کند Failure modeهای مرزی را هدف بگیریم:

Producer جدید با Consumer قدیمی؛
Event تکراری، دیررس یا خارج از ترتیب؛
Dependency کند و Circuit breaker؛
Partial failure میان DB commit و publish؛
DLQ و Re-drive بدون Side effect تکراری؛
Correlation گمشده بین Sync و Async hop.

Test doubles، Contract و Boundaryهای Component/System integration در راهنمای Integration Testing آمده‌اند.

Gray-box و پایگاه داده

Read-only observation

برای سنجش Integrity می‌توان از View محدود یا Query Read-only استفاده کرد:

SELECT
  order_id,
  final_payment_count,
  captured_amount,
  payable_amount,
  reconciliation_status
FROM qa_payment_observation
WHERE test_run_id = :test_run_id;

View باید داده لازم را حداقلی، پاک‌سازی‌شده و مستقل از جزئیات بی‌ربط ارائه دهد. Query باید Timeout/Limit و Account فقط‌خواندنی داشته باشد.

Direct DB mutation چرا خطرناک است؟

UPDATE کردن State برای رسیدن سریع به سناریو ممکن است Validation، Event و Audit طبیعی را دور بزند و State غیرواقعی بسازد. ترجیح با API/Fixture factory معتبر است. اگر Migration test ذاتاً به DB نیاز دارد، Script و Scope جدا، Backup/restore و Cleanup تعریف کنید.

Implementation coupling

Assert کردن تعداد Row در هر Table می‌تواند با Refactor سالم بشکند. Oracle را روی Invariant دامنه‌ای مانند «یک اثر مالی نهایی» نگه دارید. الگوهای Transaction، Constraint، Migration و Restore در راهنمای تست پایگاه داده توضیح داده شده‌اند.

Gray-box در Session، Cache و Authorization

Session

دانستن TTL، refresh rotation و server-side invalidation سناریوهای دقیق می‌سازد: Logout از یک دستگاه، Token replay، تغییر Role و Timeout. Test باید با حساب‌های مصنوعی و Clock کنترل‌شده باشد.

Cache

اگر Cache key از user_id + locale + permission_version ساخته می‌شود، Hypothesis بسازید: آیا تغییر Role یا Locale محتوای کاربر قبلی را نشان می‌دهد؟ Test از UI/API اجرا و با دو Account/Locale نتیجه را مقایسه می‌کند؛ خواندن Cache فقط برای Diagnosis مجاز است.

Authorization

دانش Resource ownership و Policy engine کمک می‌کند ماتریس Role×Action×Owner×State ساخته شود. UI پنهان‌شدن دکمه کافی نیست؛ API باید Deny کند. تست IDOR و Privilege escalation فقط در Scope و با داده Test انجام شود.

Gray-box در تست امنیت

OWASP Web Security Testing Guide Gray-box را حالتی می‌داند که تستر بخشی از اطلاعات برنامه را دارد؛ برای مثال آگاهی از Session management می‌تواند ارزیابی Logout و Timeout را دقیق‌تر کند. این آگاهی باید در Rules of Engagement ثبت شود.

RoE حداقلی

Target و Environment دقیق؛
Account/Role و داده مجاز؛
زمان اجرا و Contact اضطراری؛
تکنیک‌های ممنوع مانند DoS یا Destructive payload؛
Rate و Stop condition؛
Evidence، Encryption، Retention و Disclosure؛
طرف ثالث‌های خارج Scope؛
Cleanup و Retest.

دانستن Source یا Schema مجوز Exploit روی Production نیست. چرخه امن Security testing و Finding handling در راهنمای تست امنیت نرم‌افزار آمده است.

Gray-box در Performance و Reliability

دانش داخلی برای ساخت فرضیه و Diagnosis مفید است:

Query پرهزینه یا N+۱ محتمل؛
Pool اندازه‌دار و Queue saturation؛
Cache warm/cold و TTL؛
Retry amplification؛
Dependency budget و Critical path؛
Memory pressure یا Compaction.

اما Workload model، SLO و نتیجه کاربر همچنان باید نماینده و بیرونی باشند. دستکاری مستقیم Metric یا اجرای یک Query داخلی جای Performance test نیست. Gray-box می‌گوید کجا را مشاهده و چه Failure را فرض کنیم، نه اینکه هر Profiling را Test end-to-end بنامیم.

Observability به‌عنوان Test interface

ویژگی‌های لازم

Correlation ID پایدار میان Request، Event و Job؛
Timestamp و Clock source روشن؛
Build/config/feature flag قابل شناسایی؛
رویداد دامنه‌ای با نام و Schema نسخه‌دار؛
Redaction و عدم ثبت Secret/PII؛
RBAC، Audit و Retention؛
قابلیت جست‌وجوی محدوده Test بدون نویز مشترک.

Log متن آزاد Oracle شکننده است

Assert روی جمله دقیق Log با هر Refactor می‌شکند. Event یا Field ساخت‌یافته مانند payment.duplicate_ignored=true پایدارتر است. با این حال، Event داخلی نیز باید به Outcome دامنه‌ای وصل شود؛ Log «موفق شد» اثبات اثر مالی درست نیست.

Sampling و تأخیر

Trace ممکن است Sample نشود و Metric با Delay برسد. برای Test critical می‌توان Sampling کنترل‌شده در محیط Test یا Event collector اختصاصی داشت. Timeout انتظار Evidence باید از Pipeline observability بیاید، نه Sleep دلخواه.

Testability hook امن

Hook خوب Test را قابل کنترل می‌کند بدون اینکه Backdoor بسازد:

Clock قابل تنظیم فقط در Process/Environment تست؛
Gateway Sandbox با callback امضاشده؛
Fault proxy محدود به Namespace تست؛
Fixture API احرازشده و Auditشده؛
Read-only observation view؛
Test event collector با داده پاک‌سازی‌شده؛
Feature flag مخصوص Account/Cohort مصنوعی.

Guardrail

Hook باید Default-off، دارای Authentication/Authorization، Rate limit و Build-time/runtime guard باشد. وجود یا قابل‌کشف‌بودن آن در Production باید بررسی امنیتی شود. «فقط QA URL را می‌داند» کنترل امنیتی نیست.

تکنیک‌های طراحی در Gray-box

تکنیک	دانش داخلی چه کمکی می‌کند؟	محدودیت
EP/BVA	Partitionهای واقعی Validation/Storage را آشکار می‌کند	مرز باید با Contract سازگار باشد، نه فقط نوع ستون
Decision table	Policy/ownership/flagهای پنهان را وارد Rule می‌کند	Sequence و Race را پوشش نمی‌دهد
State transition	State و Event داخلی را دقیق می‌کند	State غیرقابل مشاهده به Testability نیاز دارد
Pairwise/t-way	Constraintهای Configuration را واقعی‌تر می‌کند	Journey حیاتی و higher-order risk باید Seed شود
Fault injection	نقطه Failure و Expected containment روشن می‌شود	مجوز، Blast radius و Stop condition لازم است
Change-based regression	Dependency/Code diff Scope را هدفمند می‌کند	Impact تحلیل‌نشده و Side effect سراسری ممکن است جا بماند
Exploratory	Architecture و Incident به Charter عمق می‌دهد	دانش داخلی می‌تواند Confirmation bias بسازد

Coverage را نام‌گذاری کنید

Gray-box خودش معیار Coverage نیست. یکی یا چند مورد را انتخاب کنید:

Requirement و Acceptance criteria؛
Risk و Critical journey؛
Role×Action×Owner×State؛
API/Message contract و Version pair؛
State/Transition و Invalid transition؛
Failure mode و Recovery path؛
Data invariant و Migration state؛
Configuration/Feature flag interaction؛
Incident regression؛
Statement/Branch فقط اگر Instrumentation و Scope ساختاری دارید.

دانش بیشتر ممکن است Test بهتری بسازد، اما «پوشش بهتر» فقط با معیار و Denominator قابل اثبات است. ۱۰۰٪ Branch نیز نبود باگ یا پوشش Requirement را تضمین نمی‌کند.

سوگیری‌های Gray-box

Implementation bias

تیم فقط مسیرهایی را تست می‌کند که در Diagram یا Code می‌بیند و نیاز گمشده کاربر را فراموش می‌کند. برای مقابله، Testهای Black-box مستقل و Charter اکتشافی حفظ کنید.

Confirmation bias

فرض می‌کنیم Cache علت است و فقط Evidence تأییدکننده جمع می‌کنیم. Hypothesis رقیب، آزمایش تفکیک‌کننده و مشاهده Pass/Fail لازم است.

Authority bias

Diagram معمار را حقیقت قطعی می‌گیریم. رفتار Build، Config و Trace واقعی را با مدل مقایسه کنید و Model drift را Issue قابل اقدام بدانید.

Oracle duplication

اگر Expected را از همان تابع یا Rule engine Production بخوانیم، خطای مشترک می‌تواند Test را سبز کند. Oracle مستقل از Requirement، Invariant یا حساب مرجع بسازید.

تشخیص Failure و Evidence

Failure محصول یا مشاهده‌پذیری؟

نشانه	فرضیه‌ها	اقدام
UI Fail، State درست	Presentation/cache/read-model lag	API، read model و Trace را مقایسه کنید
API موفق، Side effect غایب	Async failure/outbox/consumer	Event lifecycle و recovery را بررسی کنید
Outcome درست، Trace ناقص	Sampling/export delay/instrumentation gap	Observability defect را جدا ثبت کنید
DB invariant Fail، UI موفق	Partial commit یا Observation view stale	Read consistency و source را Verify کنید
فقط با Log debug Pass	Timing/Heisenbug	Trace سبک‌تر و آزمایش تکراری طراحی کنید

برای رخداد متناوب، ماتریس محیط، Correlation و احتمال تکرار را طبق راهنمای بازتولید باگ متناوب ثبت کنید.

محیط و داده تست

نسخه Service، Schema، Config و Dependency را ثبت کنید؛
حساب/Order/Correlation منحصر به Test run بسازید؛
State را از API/Fixture معتبر ایجاد کنید؛
داده واقعی مشتری را Query یا کپی نکنید؛
Queue/DB مشترک را با Namespace/tenant جدا کنید؛
Cleanup و Retention برای Event/Trace تعریف کنید؛
Read-after-write consistency و Delay را در Wait لحاظ کنید؛
Fault را فقط در Dependency/namespace مجاز تزریق کنید.

آمادگی Version، Dependency، Secret و Smoke در چک‌لیست محیط تست آمده است.

یک قالب Test case Gray-box

Title:
[Payment/Retry] same idempotency key creates one financial effect

Risk:
duplicate charge/order after client timeout

Knowledge:
architecture v3.2; idempotency rule REF-PAY-14;
state model commit abc123

Authorized access/control:
gateway sandbox; QA accounts; read-only observation view;
trace search by test_run_id; callback replay max=2

Forbidden:
production; real gateway; direct DB/queue mutation; load > 1 RPS

Setup:
synthetic cart and unique test_run_id

Actions:
1. submit checkout
2. cut client response after server acceptance
3. retry with the same key
4. replay successful sandbox callback

External oracle:
same logical order; clear status; no sensitive error

Internal invariant:
one final payment effect; one captured amount; consistent state

Evidence:
request IDs, sanitized response, trace link, invariant result

Cleanup:
expire synthetic account/order and remove artifacts per retention

یک Pilot چهار هفته‌ای

هفته ۱: Risk و Testability

یک Journey مانند Checkout/Refund انتخاب کنید؛
Architecture و State source معتبر را مشخص کنید؛
Access، RoE و داده مصنوعی را تصویب کنید؛
یک Invariant و Correlation end-to-end تعریف کنید.

هفته ۲: Observation و Tests

View فقط‌خواندنی یا Event ساخت‌یافته بسازید؛
سه سناریوی normal، retry و duplicate event اجرا کنید؛
Evidence و Cleanup را Verify کنید؛
Oracleهای وابسته به Table/Log متن آزاد را حذف کنید.

هفته ۳: Failure و Recovery

یک Fault مجاز و محدود تزریق کنید؛
Stop condition و Recovery را تمرین کنید؛
Timeout، retry، DLQ و reconciliation را اندازه بگیرید؛
Product failure را از telemetry gap جدا گزارش کنید.

هفته ۴: سنجش و تصمیم

Defect/Gap، زمان Localization و Flake را مرور کنید؛
Privilege و Hookهای بلااستفاده را حذف کنید؛
Knowledge source و Diagramهای غلط را اصلاح کنید؛
تصمیم گسترش، تغییر یا توقف را با هزینه نگهداری ثبت کنید.

معیارهای اثربخشی

Risk/Failure modeهای هدف با Test و Oracle مشخص؛
میانه و p95 زمان از Failure تا Localization؛
نرخ Product defect، Test defect، Environment و Observability gap؛
Incidentهای Retry/State/Data که به Regression تبدیل شده‌اند؛
Knowledge artifactهای منقضی یا بدون Owner؛
Testهای وابسته به Privilege/Hook و تاریخ بازبینی آن‌ها؛
Read-only query یا Artifact دارای PII/Secret؛
Flake ناشی از eventual consistency و Evidence delay؛
Structural/contract/state/risk coverage با Denominator مستقل؛
زمان Cleanup و داده/حساب باقی‌مانده پس از Suite.

تعداد Query، Trace یا باگ KPI فردی نیست. هدف، Evidence دقیق‌تر و تصمیم سریع‌تر با کمترین Privilege است.

اشتباه‌های رایج

تعریف Gray-box به‌عنوان میانگین Black و White؛
معرفی آن به‌عنوان سطح تست یا نقش شغلی ثابت؛
ساخت فهرست تکنیک‌های اختصاصی و بی‌تعریف؛
فرض اینکه دانش بیشتر همیشه Coverage و بی‌طرفی را بالا می‌برد؛
برابر دانستن Architecture knowledge با مجوز Backend؛
دسترسی Write به DB برای سریع‌ساختن State؛
استفاده از Admin account عمومی و بدون Audit؛
Assertion روی Table/Log جزئی به‌جای Invariant دامنه‌ای؛
کپی Oracle از همان منطق Production؛
نادیده‌گرفتن Sampling، Delay و eventual consistency؛
ذخیره Token، شماره تماس یا داده پرداخت در Trace؛
Fault injection بدون Scope، Stop condition و Recovery؛
اجرای Security test بدون Rules of Engagement؛
Overfit شدن Regression suite به Implementation فعلی؛
اعتماد به Diagram قدیمی و ندیدن Config drift؛
ادعای ۱۰۰٪ Coverage یا کاهش قطعی هزینه؛
حذف Testهای Black-box مستقل و Exploratory؛
باقی‌گذاشتن Hook تست در Production بدون Guardrail.

چک‌لیست Gray-box Testing

Risk، سؤال و System boundary روشن است.
Knowledgeهای داخلی با Version، Owner و سطح اعتماد ثبت شده‌اند.
Access و Control از Knowledge جدا شده‌اند.
RoE، Environment، Account، Rate و اعمال ممنوع مکتوب‌اند.
Hypothesis قابل رد و Test تفکیک‌کننده داریم.
Technique و Coverage criterion نام‌گذاری شده‌اند.
External outcome، Internal invariant و نبود Side effect Oracle دارند.
Correlation میان Request/Event/Job برقرار است.
Telemetry ساخت‌یافته، حداقلی و بدون Secret/PII است.
DB access فقط‌خواندنی و محدود به View/داده Test است.
State از Interface/Fixture معتبر ساخته می‌شود.
Fault injection دارای Blast radius، Stop و Recovery است.
Test hook در Production غیرفعال/محافظت‌شده است.
Gray-box suite با Black-box، White-box و Exploratory مکمل شده است.
Cleanup، Retention و بازبینی Privilege اجرا می‌شوند.

پرسش‌های متداول

آیا Gray-box یعنی تستر بخشی از Source code را می‌بیند؟

ممکن است، اما الزامی نیست. دانش معماری، Contract، State model، Schema، حساب داخلی یا Telemetry نیز Gray-box است. دقیقاً بنویسید چه اطلاعاتی در اختیار بوده و Test از چه Interfaceای اجرا شده است.

آیا Query کردن پایگاه داده همیشه Gray-box Testing است؟

خیر. Query فقط یک روش Observation است. اگر برای سنجش Invariant و با دسترسی Read-only مجاز استفاده شود، می‌تواند بخشی از Test Gray-box باشد. Mutation مستقیم State ممکن است Workflow واقعی را دور بزند و Test نامعتبر یا ناامن بسازد.

تفاوت Gray-box و Integration Testing چیست؟

Integration یک سطح/هدف درباره تعامل Componentها یا Systemهاست؛ Gray-box زاویه اطلاعات است. Integration test می‌تواند Black-box، Gray-box یا White-box طراحی شود. این دو اصطلاح جای هم نیستند.

آیا Gray-box در تست امنیت همان Pentest با Credential است؟

Credential می‌تواند بخشی از اطلاعات/دسترسی باشد، اما Gray-box Security scope بزرگ‌تری دارد: Architecture، Config، Code slice یا accountهای نقش‌دار. هر فعالیت باید RoE، مجوز، Target، تکنیک ممنوع و Evidence handling روشن داشته باشد.

آیا Gray-box پوشش بیشتری از Black-box تضمین می‌کند؟

خیر. دانش داخلی می‌تواند Gap و Failure mode تازه آشکار کند، اما Coverage فقط نسبت به معیار مشخص مانند Rule، State، Risk، Contract یا Branch سنجیده می‌شود. مدل ناقص یا سوگیری Implementation حتی می‌تواند نیاز کاربر را پنهان کند.

جمع‌بندی

تست جعبه خاکستری استفاده مسئولانه از دانش جزئی برای طراحی فرضیه و Oracle بهتر است. ارزش آن در «دیدن Backend» نیست؛ در پیوند نتیجه کاربر با State، Event و Invariant قابل اعتماد است. Knowledge، Access، Control و Oracle را جدا مستند کنید، Least privilege و Rules of Engagement را رعایت کنید و Test را به جزئیات شکننده Implementation قفل نکنید. در سیستم‌های APIمحور و توزیع‌شده—از Retry پرداخت تا Authorization، Cache و Migration—این رویکرد می‌تواند Localization را سریع‌تر و شواهد را دقیق‌تر کند، اما همچنان به Black-box مستقل، White-box ساختاری و تست‌های مکمل نیاز دارد.

تست نرم افزار, سطوح تست

تست جعبه خاکستری چیست؟ راهنمای Gray-box با مثال