تست سیستم

تست سیستم توزیع‌شده؛ از History تا Replay

انتشار در تاریخ توسط محمد عسکری

سه Replica سبز هستند، Contract testها پاس شده‌اند و Trace یک درخواست موفق را نشان می‌دهد؛ اما یک مشتری پس از Timeout دوباره پرداخت را می‌فرستد، پاسخ اول گم شده، Leader عوض می‌شود و دو Consumer یک پیام را پردازش می‌کنند. آیا سامانه درست رفتار کرده است؟ از داشبورد سبز نمی‌دانیم. تست سیستم‌های توزیع‌شده وقتی قابل‌ممیزی می‌شود که عملیات، پیام‌ها، زمان، Fault و نتیجه در یک Distributed Execution Record قرار گیرند و History با Oracle مشخص بررسی و Schedule تا حد ممکن Replay شود.

خلاصه اجرایی: واحد تست یک History است

  • Subject فقط «سرویس Checkout» نیست؛ Artifact، Configuration، Schema، Topology، Deployment و Dependencyهای دقیق است.
  • هر Operation دست‌کم Invocation و Completion دارد؛ Timeout می‌تواند نتیجه‌ای نامعلوم باشد، نه Failure قطعی.
  • Wall clock برای ترتیب علّی کافی نیست؛ Local sequence، Monotonic time و Logical/causal relation را نگه دارید.
  • Consistency model مجموعه Historyهای مجاز است؛ «داده‌ها سازگارند» بدون مدل و Scope ادعا نیست.
  • Trace و Log نمونه‌ای از مشاهده‌اند و ممکن است Sampling، Drop، Clock skew یا Context gap داشته باشند.
  • Fault injection بدون Workload، Oracle، Guardrail و Recovery evidence فقط رخداد عملیاتی است.
  • Replay باید Subject، Seed، Fault schedule و نخستین Divergence را ثبت کند؛ تکرار URL یک Replay نیست.

سیستم توزیع‌شده در این راهنما چیست؟

هر سامانه‌ای که State یا تصمیم آن میان Process، Node، Zone، Region، Queue، Database یا سرویس مستقل توزیع شده و ارتباطش از مرزی با Delay، Loss یا استقلال خرابی عبور می‌کند، مسئله توزیع‌شده دارد. Microservice فقط یکی از شکل‌هاست. یک Monolith با Database Replica، Job queue و Cache نیز می‌تواند History توزیع‌شده بسازد.

مرز این صفحه با خوشه‌های تخصصی سایت

این صفحه مالک Distributed Execution Record و History/Oracle/Replay است. طراحی Failure mode و Recovery به راهنمای تست تاب‌آوری، آزمایش کنترل‌شده Fault به مهندسی آشوب، سبد Microservice به تست میکروسرویس، Pact به تست قرارداد API، Verdict آماری به تست سیستم غیرقطعی و بازتولید Incident متناوب به راهنمای Cannot Reproduce تعلق دارد.

Distributed Execution Record چیست؟

این رکورد Claim را به نسخه سامانه، Topology، Workload، Event history، Fault schedule، Time model، Oracle، Result، Replay و Evidence متصل می‌کند. هدف ساخت یک «واقعیت جهانی کامل» نیست؛ هدف شفاف‌کردن آن چیزی است که ابزارها توانسته‌اند مشاهده و استنتاج کنند.

DistributedExecutionRecord {
  record_id, claim_id, subject_id, topology_id, run_id,
  workload_id, model_id, invariant_ids[], fault_schedule_id,
  raw_history_digest, normalized_history_digest,
  time_model, trace_coverage, oracle_results[],
  counterexamples[], replay_ids[], limitations[],
  evidence_ids[], decision, correction_of
}

Claim را پیش از ساخت Cluster بنویسید

«سیستم توزیع‌شده پایدار است» قابل‌آزمون نیست. نمونه محدود: «در Release و Topology مشخص، Register تک‌کلیدی برای Clientهای موفق، طی Partition تعریف‌شده، History مشاهده‌شده Linearizable است؛ Operationهای Timeoutشده با Completion policy معین تحلیل می‌شوند؛ این نتیجه درباره Transaction چندکلیدی، Availability دائمی یا Production نیست.» Scope، Strength، Decision use و Not-claimed را Pin کنید.

Subject و Deployment را تثبیت کنید

Commit به‌تنهایی کافی نیست. Artifact digest هر Node، Build، Dependency lock، Feature flag، Config، Database/Queue schema، Migration، Container image، Deployment manifest و Secret reference بدون خود Secret را ثبت کنید. Drift میان Nodeها می‌تواند علت رفتار باشد؛ نام Release آن را پنهان می‌کند.

Topology را یک Artifact نسخه‌دار بدانید

Node، Role، Region/Zone، Replica، Shard، Leader، Quorum، Link، Route، Load balancer و Dependency graph را با زمان اثر ثبت کنید. Topology در طول Run عوض می‌شود؛ Snapshot آغاز و Eventهای Join/Leave/Promotion/Rebalance لازم‌اند.

NodeIdentity {
  node_id, role, region, zone, boot_id, process_id,
  artifact_digest, config_digest, term, epoch,
  joined_at_event, left_at_event, clock_source
}

Operation: Invocation و Completion را جدا کنید

یک Operation با Invocation آغاز و با Completion پایان می‌یابد. ClientID، SessionID، Object، Type، Argument، Result/Error و دو زمان را ذخیره کنید. اگر Client Timeout کرده اما Server Commit کرده باشد، نتیجه UNKNOWN_OUTCOME است؛ برچسب Failed می‌تواند History را تحریف و Retry را خطرناک کند.

Message identity را از Delivery attempt جدا کنید

یک پیام منطقی ممکن است چند بار Deliver شود. logical_message_id را از message_id و attempt جدا کنید؛ Producer، Consumer، Topic/Partition/Offset، Schema version، Payload digest و Created/Sent/Received/Processed/Acked را ثبت کنید. CorrelationID برای گروه‌بندی و CausationID برای علت مستقیم است؛ یکی جای دیگری نیست.

Exactly-once را به اثر کسب‌وکاری ترجمه کنید

Broker می‌تواند Delivery semantics خاصی داشته باشد، اما اثر End-to-end به Producer، Transaction boundary، Consumer، Side effect و Retry وابسته است. به‌جای شعار Exactly-once، Invariant بنویسید: «برای هر EventID پذیرفته‌شده، حداکثر یک Ledger posting موثر و یک رسید نهایی وجود دارد.» سپس Dedup key، Idempotency scope، Retention و Reprocessing را آزمایش کنید.

زمان فیزیکی، یکنواخت و منطقی

زمانکاربردمرز
Wall clockزمان تقویمی و هم‌بستگی بیرونیSkew، Jump و اصلاح NTP
Monotonic clockDuration محلیمیان Nodeها قابل‌مقایسه نیست
Logical clockترتیب سازگار با causalityزمان واقعی یا Duration نیست
Vector/causal metadataتشخیص رابطه یا هم‌زمانیهزینه و Scope دارد

مقاله کلاسیک Time, Clocks and the Ordering of Events رابطه happens-before را به‌صورت Partial order صورت‌بندی می‌کند. Timestamp کوچک‌تر به‌تنهایی علت را اثبات نمی‌کند. Clock source، Offset، Uncertainty، Drift و Sync event را در Run نگه دارید.

Event history را چگونه بسازیم؟

هر Event باید EventID، Node/BootID، Local sequence، Operation/Message link، Logical time، Wall/Monotonic time، Type، Source و Payload digest داشته باشد. Raw history را تغییر ندهید؛ Normalizer نسخه‌دار Duplicate، Late event، Missing pair و Clock correction را به History مشتق تبدیل کند.

Missing event با رخ‌ندادن Event یکی نیست

نبود Span یا Log می‌تواند از Sampling، Buffer overflow، Export failure، Crash، Network یا Instrumentation gap باشد. برای هر Source نرخ Drop، Sequence gap و Export health را ثبت کنید. Oracle نباید سکوت Telemetry را Success تفسیر کند.

Trace حقیقت کامل سامانه نیست

Trace مسیر مشاهده‌شده Instrumentation را نشان می‌دهد. Parent/Link اشتباه، Batch، Queue، Fan-out، Retry و Async work می‌توانند ساختار را ناقص کنند. مستندات OpenTelemetry برای Messaging Span میان Create/Send/Receive/Process و Linkها تمایز می‌گذارد. TraceID را با MessageID، OperationID و Payload digest پیوند دهید و Sampling flag را حفظ کنید.

Workload یک قرارداد است

Generator version، Seed، Actorها، Key distribution، Operation mix، Rate model، Session policy، Warmup/Cooldown، Duration و Stop condition را Pin کنید. Workload یکنواخت ممکن است Hot key، Long session، Skew، Retry storm یا Read-after-write را اصلاً نسازد.

Safety، Liveness و Availability را جدا کنید

  • Safety: «اتفاق بد رخ نمی‌دهد»؛ مانند دو Leader موثر در یک Term.
  • Liveness: «در شرایط تعریف‌شده سرانجام پیشرفت رخ می‌دهد»؛ بدون Bound زمانی الزاماً Latency نیست.
  • Availability: برای کدام Request واجدشرایط، در چه Window و Deadline، چه Resultی Success است.
  • Durability: کدام Ack و Failure model باید State را حفظ کند.
  • Performance: Distribution زمان/Throughput زیر Workload و Environment مشخص.

Consistency model را با Scope انتخاب کنید

Linearizability، Sequential consistency، Causal، Read-your-writes، Monotonic reads، Serializability، Snapshot isolation و Strict serializability یکی نیستند. Scope می‌تواند Key، Object، Partition، Transaction یا Session باشد. مرجع مدل‌های سازگاری Jepsen مدل را مجموعه‌ای از Historyهای مجاز تعریف و رابطه برخی مدل‌ها را نشان می‌دهد؛ بعضی مدل‌ها نیز قابل‌مقایسه کامل نیستند.

Linearizability دقیقاً چه می‌پرسد؟

برای Scope مشخص می‌پرسد آیا Operationها را می‌توان طوری اتمی و ترتیبی دید که Real-time order Operationهای غیرهم‌زمان و قوانین Sequential object حفظ شود. صفحه رسمی Linearizability در Jepsen همین مرز Single-object و Real-time را روشن می‌کند. «آخرین Timestamp برنده است» به‌تنهایی Checker خطی‌پذیری نیست.

Eventual consistency یک Oracle کامل نیست

«سرانجام همگرا می‌شود» باید مشخص کند پس از قطع Update، تحت چه Network/Failure assumption، در چه Observation window، کدام Replica و با چه Equality/Conflict rule. Staleness bound، Monotonic reads و Read-your-writes خواص جداگانه‌اند. عبارت Eventual نباید Lost update یا Resurrection را توجیه کند.

CAP را به انتخاب دائمی C یا A تقلیل ندهید

پرسش عملی در حضور Partition و برای Operation مشخص است: کدام Requestها پاسخ می‌گیرند، کدام Consistency property حفظ می‌شود، Timeout/Reject چگونه شمرده می‌شود و پس از Heal چه رخ می‌دهد. یک سامانه می‌تواند برای Object یا Operationهای مختلف رفتار متفاوت داشته باشد. CAP جایگزین مدل History، Availability denominator یا Recovery test نیست.

Oracle از Dashboard ساخته نمی‌شود

Oracle می‌تواند Reference state machine، Consistency checker، Invariant، Metamorphic relation یا Reconciliation باشد. Input آن Raw/Normalized history و Completion policy است. Result باید PASS / VIOLATION / UNKNOWN / INCONCLUSIVE / CHECKER_ERROR باشد. برای طراحی Expected result به راهنمای Test Oracle رجوع کنید.

Operation ناقص را چگونه تحلیل کنیم؟

اگر Invocation دیده شده ولی Completion نداریم، ممکن است Operation اعمال شده یا نشده باشد. Checker باید Completionهای ممکن را طبق Policy بررسی کند یا نتیجه Unknown بدهد. حذف Operation ناقص می‌تواند History نامعتبر را ظاهراً سالم کند؛ فرض «Timeout یعنی Abort» نیز باید با Protocol اثبات شود.

Fault model را پیش از تزریق بنویسید

Crash-stop، Pause، Restart، Process kill، Disk full، I/O error، Clock skew، Link delay/loss/duplication/reorder، Directional partition، DNS/TLS failure و Corruption اثر یکسان ندارند. Target، Trigger، Start/end event، Duration، Parameters، Blast radius، Guardrail، Abort و Recovery action را ثبت کنید. این صفحه Schedule را ثبت می‌کند؛ طراحی ایمن Experiment همچنان متعلق به صفحه Chaos است.

Partition جهت و Scope دارد

Partition لزوماً دو نیمه متقارن نیست. A→B ممکن است قطع و B→A برقرار باشد؛ Client→Leader با Replica→Leader فرق دارد. Data plane، Control plane، Health check و DNS نیز مسیرهای جدا هستند. ماتریس Link و Ruleهای Proxy/Firewall را Evidence کنید.

Leader، Term، Epoch و Fencing

دو Process که خود را Leader می‌دانند الزاماً دو Leader موثر نیستند؛ Term/Epoch و Fencing token تعیین می‌کند کدام Side effect پذیرفته می‌شود. History باید Election، Lease، Quorum، Promotion، Step-down و Reject شدن Writer قدیمی را نشان دهد. Wall-clock lease بدون Clock-bound ادعای ضعیفی است.

Retry، Timeout و Backoff را با هم تست کنید

Timeout یک Observation سمت Caller است، نه Cancellation تضمینی. Retry ممکن است بار را چندبرابر، صف را متراکم و Recovery را کند کند. Per-attempt و End-to-end deadline، Backoff، Jitter، Retry budget، Idempotency key و Stop condition را ثبت کنید. Test باید Timeout-before/after-commit و پاسخ دیررس پس از Retry را بسازد.

Queue و Stream: Offset معادل اثر نیست

Ack، Commit offset، Processing و Side effect چهار رویدادند. Crash میان آن‌ها Duplicate یا Loss می‌سازد. Partition reassignment، Consumer rebalance، Poison message، DLQ، Out-of-order و Backfill را به History اضافه کنید. Lag کم به معنای Correctness نیست.

Cache و Replica read را با Session بررسی کنید

Client ممکن است پس از Write به Replica عقب‌مانده Route و مقدار قدیمی ببیند. Cache invalidation، TTL، Negative cache، Failover و Session stickiness را در Workload بسازید. Oracle جداگانه Read-your-writes، Monotonic reads و Staleness را بسنجد.

Transaction و Saga را با Compensation یکی ندانید

Compensation معمولاً یک Business action تازه است، نه Undo اتمی. StepID، Attempt، Forward effect، Compensation trigger/result، Irreversible effect و Manual intervention را ثبت کنید. Oracle باید Invariant نهایی و Stateهای میانی مجاز را جدا کند.

Contract test چه چیزی را ثابت نمی‌کند؟

Contract سازگاری Request/Response و Expectation نسخه‌دار را بررسی می‌کند؛ ترتیب پیام، Retry، Concurrency، Deployment wiring، داده واقعی، Latency یا Consistency end-to-end را خودکار تضمین نمی‌کند. Provider verification مکمل Integration/History test است، نه جایگزین همه تعامل واقعی.

E2E بیشترین اطمینان مطلق نمی‌دهد

یک E2E ممکن است مسیر Happy path را در یک Schedule ببیند و میلیاردها Interleaving را نبیند. ارزش آن پوشش Wiring و Journey خاص است. Contract، Component، Simulation، History checking، Fault experiment و Production observation هرکدام Evidence متفاوت دارند؛ آن‌ها را به یک هرم اطمینان خطی تبدیل نکنید.

شبیه‌سازی قطعی چه مزیتی دارد؟

Scheduler، Clock، Network و Failure اگر تحت Seed کنترل شوند، Schedule شکست قابل‌تکرار می‌شود. مستندات Simulation and Testing در FoundationDB شبیه‌سازی تک‌فرآیندی قطعی Cluster را توضیح می‌دهد؛ صفحه Client Testing نیز می‌گوید Seed فقط تا زمانی Replay کمک می‌کند که Workload عدم‌قطعیت خارج از مدل وارد نکند. این نمونه یک الگوست، نه اثبات مناسب‌بودن برای هر سامانه.

Deterministic simulation Production نیست

Simulator می‌تواند NIC، Kernel، Disk firmware، CPU memory ordering، TLS library یا رفتار Vendor واقعی را ساده کند. Model coverage و Hardware/live tests را جدا گزارش کنید. یک Seed موفق درباره Seedها یا Faultهای ندیده حکم نمی‌دهد.

Schedule record برای Replay

ScheduleDecision {
  index, logical_time, enabled_actions[], chosen_action,
  message_delivery_order, delay, drop, duplicate, reorder,
  fault_start_or_end, node_restart, random_draw, state_digest
}

فقط Seed کافی نیست اگر نسخه کد، تعداد Thread، RNG call order یا Environment تغییر کند. Schedule digest، Engine version و State checkpoint را نگه دارید. Replay نتیجه را MATCHED / PREFIX_MATCHED / DIVERGED / NOT_REPRODUCED / UNSUPPORTED گزارش و نخستین Divergence را ثبت کند.

لایه‌های تست را با نوع شاهد بچینید

  1. Model/state-machine test برای قوانین کوچک و سریع.
  2. Deterministic simulation برای Schedule و Faultهای زیاد.
  3. Single-node/component test برای Artifact و Storage واقعی محدود.
  4. Local multi-node cluster برای Protocol و Wiring.
  5. Staging hardware/network test برای شکاف Simulator.
  6. Chaos experiment مجاز با Guardrail برای رفتار عملیاتی.
  7. Production observation یا Shift-right فقط با مجوز، Blast radius و Rollback.
  8. Incident replay برای First divergence و Regression evidence.

Testability پیش‌نیاز History معتبر است

Stable ID، injectable clock/RNG، controllable scheduler، deterministic fake، state snapshot، fault hook، event export و queryable invariant هزینه تشخیص را کم می‌کنند. طراحی این قابلیت‌ها را با راهنمای تست‌پذیری نرم‌افزار هماهنگ کنید. Hook تست نباید مسیر امنیتی Production را باز بگذارد.

Run Manifest حداقل لازم

RunManifest {
  run_id, subject_digest, topology_digest, environment_digest,
  workload_digest, generator_version, seed, schedule_digest,
  fault_model_digest, oracle_version, model_and_scope,
  clock_sources, trace_sampling, collection_health,
  time_memory_operation_fault_budgets,
  start_end_utc, termination_reason, warnings, artifact_index
}

Evidence Pack و Provenance

Claim، Subject/Topology snapshot، Workload، Model/Invariant، Fault/Schedule، Raw/Normalized history، Clock report، Trace health، Oracle input/output، Counterexample، Replay، Finding/Triage، Decision و Correction را با Digest نگه دارید. Retention، Access، Redaction و Producer هر Artifact مشخص باشد.

واژگان نتیجه را غیرمبهم کنید

HISTORY_ACCEPTED_BY_MODEL
HISTORY_VIOLATES_MODEL
HISTORY_INCOMPLETE
ORACLE_UNKNOWN
CHECKER_ERROR
FAULT_APPLIED
FAULT_NOT_APPLIED
RECOVERY_OBSERVED
RECOVERY_NOT_OBSERVED
REPLAY_MATCHED
REPLAY_DIVERGED
TRACE_GAP
MODEL_GAP
STALE_EVIDENCE

امنیت، حریم خصوصی و مجوز

History و Trace ممکن است شناسه، Payload یا Credential حمل کنند. Purpose، Minimization، Redaction، Access، Retention و Delete را تعریف کنید. Fault injection روی محیط مشترک، سامانه ثالث یا Production بدون مجوز ممنوع است. تست Consistency به‌تنهایی Security، Safety یا Compliance را ثابت نمی‌کند.

آزمایشگاه فارسی و کاملاً ساختگی Ledger

آزمایشگاه آفلاین سه Node خیالی N1/N2/N3، دو Client، یک Register و یک Queue حافظه‌ای دارد. هیچ شبکه، بانک، PSP، حساب، شخص، پول، داده واقعی، Cookie، Token یا Credential وجود ندارد. IRR فقط Label Fixture و تومان صرفاً نمایش غیرحسابداری است.

Invariant INV-FAKE-01:
  for each accepted EventID, effective_postings <= 1

Workload:
  C1 invoke write(E-7, 7000 IRR)
  delay response; C1 timeout; retry same EventID
  duplicate delivery to N2; pause N1; elect N3
  heal; read from N2 then N3

Scope:
  2 clients, 3 nodes, 1 key, 6 messages, 2 retries, 12 schedule steps
Not modeled:
  HTTP, real broker, disk, threads, TLS, production, payment

History ساختگی و نتیجه محدود

H1 C1 INVOKE write(E-7,7000)
H2 N1 COMMIT E-7 posting=P1
H3 C1 TIMEOUT outcome=UNKNOWN
H4 C1 INVOKE retry(E-7)
H5 N2 PROCESS duplicate(E-7) posting=P2
H6 C1 COMPLETE retry=OK

ORACLE=HISTORY_VIOLATES_INVARIANT
COUNTEREXAMPLE=P1,P2 share EventID E-7
REPLAY=FIXTURE_ONLY_MATCHED
BOUNDARY=no real ledger, payment, consistency, durability, or production claim

سناریوهای فارسی آزمایشگاه

  • EventID با رقم ۷ فارسی، ۷ عربی و ۷ لاتین برای آزمون Normalization و جلوگیری از Dedup اشتباه.
  • «تأیید/تایید»، ی/ی، ک/ک و نیم‌فاصله فقط در نمایش؛ Identity از متن محلی ساخته نمی‌شود.
  • UTC، Asia/Tehran و جلالی نمایش داده می‌شوند، اما Ordering با Local sequence و Logical time است.
  • Clock N2 ده ثانیه جلو می‌رود تا نشان دهد مرتب‌سازی Wall time می‌تواند History را خراب کند.
  • Response دیررس، Duplicate، Reorder، Directional partition و Restart با Schedule ثابت تزریق می‌شوند.
  • یک Export gap عمدی Trace را ناقص می‌کند؛ Raw operation history همچنان مرجع Oracle است.

Validator قطعی آزمایشگاه

Validator مستقل و بدون Dependency، Schema کنترل‌ها را Group-qualified و یکتا می‌کند. Checker سطحی با دیدن Nodeهای سبز، نبود ۵۰۰، Trace ظاهراً کامل، Contract pass و Chaos run اشتباه می‌گوید CONSISTENT_AVAILABLE_AND_RESILIENT. ممیزی نبود History کامل، Model check، حل Unknown outcome و Replay را آشکار و نتیجه را Hold می‌کند. پس از Pin شدن Subject/Topology/History/Fault schedule/Time model/Oracle و Replay Fixture، نتیجه محدود READY_FOR_DISTRIBUTED_HISTORY_REVIEW-0 است.

CONTROL_COUNT=380
SUPERFICIAL=CONSISTENT_AVAILABLE_AND_RESILIENT
AUDIT=HOLD-380
INDEPENDENT_TARGET=real-system-or-user:false:PASS
CORRECTED=READY_FOR_DISTRIBUTED_HISTORY_REVIEW-0
BOUNDARY=offline-fixture-only; no consistency, availability, resilience, durability, performance, security, safety, compliance, or production claim

دروازه تصمیم پیشنهادی

اگر Subject/Topology معلوم نیست، Evidence قابل‌انتساب نیست. اگر History gap دارد، Verdict باید Unknown یا محدود باشد. اگر Model/Scope مشخص نیست، Checker result معنا ندارد. اگر Counterexample روی Fixture Replay شد، Finding همان Fixture تایید شده؛ انتقال به سامانه واقعی نیازمند شاهد جداست. Release gate فقط با Risk owner، Limit و Expiry روشن اعمال شود.

تغییر، انقضا و Correction

تغییر Artifact، Topology، Quorum، Schema، Retry، Timeout، Clock، Model، Checker یا Instrumentation می‌تواند Evidence را Stale کند. رکورد قدیمی را حذف نکنید؛ Correction گزاره قبلی، علت، زمان کشف، نتیجه جدید، تصمیم‌های متاثر، Notification و Approver را نگه دارد.

۲۰ ضدالگوی رایج

Red flagها: همه Nodeها سبز پس درست؛ نبود ۵۰۰ مساوی موفقیت؛ Trace مساوی Truth؛ Wall time مساوی causality؛ Timeout مساوی Abort؛ Exactly-once بدون Scope؛ Eventual بدون Window؛ CAP به‌صورت انتخاب دائمی C/A؛ Contract مساوی Integration؛ E2E مساوی بیشترین اطمینان؛ Chaos بدون Oracle؛ Partition بی‌جهت؛ Seed بدون نسخه Schedule؛ حذف Operation ناقص؛ Sort کردن History فقط با Timestamp؛ Retry بدون Idempotency؛ Offset مساوی Side effect؛ Leader بدون Term/Fencing؛ Availability بدون Denominator؛ و پاک‌کردن Run ناسازگار.

چک‌لیست مالک تست

  • Claim، Scope، Model، Strength و Not-claimed روشن‌اند.
  • Artifact/Config/Schema/Deployment digest برای همه Nodeها ثبت شده است.
  • Topology، Term/Epoch، Quorum و تغییر عضویت نسخه‌دارند.
  • Operation، Message و Event شناسه مستقل و پیوند روشن دارند.
  • Invocation/Completion و Unknown outcome حفظ می‌شوند.
  • Wall/Monotonic/Logical time و Clock uncertainty مشخص‌اند.
  • Raw history immutable و Normalizer نسخه‌دار است.
  • Workload/Seed/Distribution/Stop condition Pin شده‌اند.
  • Fault و Direction/Duration/Guardrail/Recovery ثبت شده‌اند.
  • Oracle، Completion policy و Unknown policy قابل‌بازبینی‌اند.
  • Trace sampling/drop/context gap اندازه‌گیری می‌شود.
  • Schedule و نخستین Divergence برای Replay نگه‌داری می‌شوند.
  • Evidence Pack و Correction chain کامل است.
  • داده واقعی، Secret و Production فقط با مجوز و کنترل‌اند.
  • Consistency به Security/Safety/Compliance تعمیم داده نمی‌شود.

پایلوت ۳۰روزه بدون سامانه واقعی

هفته اول Claim، Object model، Operation/Message identity و History schema؛ هفته دوم سه‌Node Fixture با Clock/Network قابل‌کنترل؛ هفته سوم Fault schedule، Consistency/Invariant oracle و Replay؛ هفته چهارم Trace-gap drill، Evidence Pack، Correction و CI غیرمسدودکننده. معیار موفقیت تعداد Crash نیست: Completeness تاریخچه، Unknown rate، Counterexample quality، Replay match، زمان First-divergence و شکاف مدل کشف‌شده را بسنجید.

جمع‌بندی

تست سیستم توزیع‌شده با روشن‌کردن چند Container یا اجرای یک Chaos job تمام نمی‌شود. باید بدانیم چه Artifact و Topology تحت چه Workload و Fault schedule اجرا شد، چه History با چه شکاف‌هایی جمع شد، کدام Model/Invariant آن را سنجید و Replay کجا تطابق یا واگرایی داشت. اعتماد از زنجیره شاهد محدود می‌آید، نه از داشبورد سبز.

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

اولین قدم تست یک سیستم توزیع‌شده چیست؟

یک Claim محدود و Operation/Message identity قابل‌ردیابی بسازید. خرید ابزار Observability قبل از تعریف History و Oracle، فقط داده بیشتری بدون Verdict تولید می‌کند.

آیا Trace توزیع‌شده برای بازتولید خطا کافی است؟

خیر. Trace ممکن است Sample یا Drop شود و Schedule، Payload digest، Node state و Operation ناقص را کامل نداشته باشد. Trace یک ورودی Evidence است، نه Replay recipe کامل.

تفاوت Eventual consistency و Linearizability چیست؟

Linearizability برای Scope مشخص ترتیب اتمی سازگار با Real time می‌خواهد. Eventual convergence معمولاً پس از توقف Update و تحت فرض‌های تعریف‌شده همگرایی را می‌خواهد؛ خواص Session یا Bound زمانی باید جدا اضافه شوند.

آیا Contract test می‌تواند جای E2E را بگیرد؟

خیر. Contract شکل تعامل را بررسی می‌کند؛ E2E Wiring/Journey خاص را. هیچ‌کدام به‌تنهایی Schedule، Fault، Consistency history یا همه Side effectها را پوشش نمی‌دهند.

حداقل Artifactهای یک Run قابل‌ممیزی چیست؟

Claim، Subject/Topology، Workload، Time/Fault/Schedule model، Raw/Normalized history، Trace-health report، Oracle input/output، Counterexample، Replay، Finding/Decision و Evidence index با Digest.

محمد عسکری

محمد هستم، توسعه‌دهنده وب با بیش از ده سال تجربه در برنامه‌نویسی سمت سرور و کاربر. به یادگیری و اشتراک‌گذاری دانش علاقه‌مندم و اخیراً تمرکزم را روی حوزه تست نرم‌افزار گذاشته‌ام تا تجربیاتم را در این زمینه نیز به اشتراک بگذارم و به درک بهتر کیفیت نرم‌افزار کمک کنم.

دیدگاهتان را بنویسید