استراتژی تست هسته

1) اصول

تعادل هرم و غنائم پایه - تست های مدولار و قرارداد سریع ؛ بالا - جزء و ادغام ؛ در راس لایه e2e حداقل اما با ارزش است.
شیفت به چپ هرچه زودتر نقص را بگیریم (لاینتر، تجزیه و تحلیل استاتیک، مبتنی بر ویژگی)، ارزان تر است.
تعیین کننده توسط طراحی ما زمان، شبکه، وابستگی های تصادفی و خارجی را مدیریت می کنیم.
اقتصاد کیفیت. هر آزمون «بیمه» است: هدف این است که به حداقل رساندن هزینه های کل (نقص + تعمیر و نگهداری آزمون).
جهت گیری ریسک پوشش متمرکز بر invariants کسب و کار و پروتکل (قرارداد، idempotency، سازگاری).

2) سطح تست و زمینه های مسئولیت

2. 1 واحد (مدولار)

بررسی منطق محض بدون I/O.
ما فقط مرزها (پورت/آداپتور) را خیس می کنیم، از کارخانه ها برای داده ها استفاده می کنیم.
سریع (≤50 -100 ms/test)، موازی.

2. 2 قرارداد (تامین کننده ↔ مصرف کننده)

رفع قراردادهای API (HTTP/gRPC/رویداد) بین خدمات.
ما از یک رویکرد مبتنی بر مصرف کننده استفاده می کنیم: قراردادها در VCS ذخیره می شوند، در CI تامین کننده بررسی می شوند.
کاهش شکنندگی ادغام e2e.

2. 3 جزء (بالای ماژول، با ذخیره سازی واقعی)

ما بخشی از سرویس را با یک پایگاه داده واقعی/کش در یک ظرف (Testcontainers) راه اندازی می کنیم.
ما مهاجرت طرح، شاخص ها، معاملات، قفل ها را تأیید می کنیم.

2. 4 ادغام/سیستم (مسیرهای پایان به پایان بین خدمات)

ما مجموعه ای از خدمات را در یک محیط جداگانه افزایش می دهیم.
ما بررسی های پایان به پایان را بررسی می کنیم: transactionality، retrai، idempotency، دست زدن به خطا.

2. 5 E2E (حداقل لایه «ارزشمند»)

پروتکل های واقعی و محیط زیست «مانند در فروش», اما یک سناریوی محدود مجموعه: پرداخت → تایید ارسال; ثبت نام → تایید → ورود.
ما از ویژگی های با خطر بالا برای انتشار و رگرسیون استفاده می کنیم.

3) معماری قابل آزمایش

پورت ها/آداپتورها (شش ضلعی). هسته کسب و کار در مورد HTTP/SQL نمی داند ؛ وابستگی ها از طریق رابط ها اجرا می شوند.
تزریق زمان/تصادفی. «ساعت»، «تصادفی» - وابستگی ها ؛ در آزمایشهایی که انجام میدهیم.
انتزاع I/O قابل تنظیم. صف، DB، KMS - از طریق رابط با پیاده سازی آزمون.
تغییرناپذیر های کاربردی ما به صراحت شرایط و پیش بینی ها را فرموله می کنیم - آنها برای آزمایش و نظارت آسان تر هستند.

4) داده ها برای آزمایش

کارخانه ها/سازندگان به جای وسایل ثابت JSON: شکنندگی کمتر.
دانه های idempotent و تنظیم مجدد قلاب DB قبل از آزمون (مهاجرت → کوتاه کردن → دانه).
کاتالوگ موارد: «هنجارها»، «لبه ها»، «خطاها»، «هرج و مرج».
Synthetics به جای PD واقعی: ژنراتور، ماسک، پروفایل های حفظ حریم خصوصی.

5) رقابت و idemotence

تست های مسابقه: ورودی های رقابتی/ذخایر/قفل.
چک کردن کلیدهای idempotent (به عنوان مثال، '(عملیات، external_id)'): تماسهای مکرر وضعیت را تغییر نمی دهد.
Retrai و timeouts: ما تضمین صحت در صورت خطاهای موقت.

dedupe_key = hash(op + external_id)
if exists(executions, dedupe_key): return previous_result else:
reserve(dedupe_key)
result = do_operation()
store(executions, dedupe_key, result)
return result

6) زمان، زمان بندی، مناطق زمانی

تمام زمان های ذخیره شده UTC هستند در تستها از «ساعت ثابت» استفاده میکنیم.
ما موارد DST (تکراری/ساعت را از دست می دهیم)، پنجره های «روز محلی» را آزمایش می کنیم.
ما زمانهای کاری را با یک ساعت یکنواخت بررسی می کنیم ؛ شبیه سازی لرزش NTP.

7) انعطاف پذیری و هرج و مرج

تزریق خطا: خطاهای شبکه، 5xx، تاخیر، تخریب جزئی (حافظه پنهان در دسترس نیست).
تست هرج و مرج در محیط pre-prod: جدا کردن گره ها، بارگذاری بیش از حد صف ها، شکستن BGP/Anycast (شبیه سازی).
سیاست های Fallback و تخریب UX: تست ها باید «تخریب برازنده» صحیح را تأیید کنند.

8) عملکرد

معیارهای میکرو برای الگوریتم های بحرانی (با CPU/fixation).
پروفایل های بار: پایه (p50/p95)، استرس (اوج)، طولانی (خیس کردن) برای نشت حافظه.
Regress gates: ساختن شکست می خورد اگر تاخیر p95 بدتر از پایه> X٪ باشد.

9) ایمنی و انطباق

SAST/Lint: جستجو برای آسیب پذیری/antipatterns.
DAST/IAST: سناریوهای اساسی در غرفه (نمونه های XSS/SQLi/SSRF).
Secrets-scan: بدون کلید/کلمه عبور در کد و مصنوعات.
تست های حریم خصوصی: عدم وجود PD در سیاهههای مربوط/ردیابی، انطباق با «مدیریت رضایت»، پروفایل های ناشناس برای آپلود.

10) معیارهای کیفیت و SLO

نرخ عبور آزمون و شاخص پوسته پوسته شدن.

• 90-100٪ برای ماژول های هسته بحرانی،
• 70-80٪ برای حاشیه (با تمرکز بر ثابت).
• نمره خطر انتشار: کلیت: تغییرات در فایل های بحرانی × سقوط معیار × پوسته پوسته شدن جدید.
• بودجه اشتباه: ترکیبی از prod-SLO (uptime/errors) با آزمایش و فرکانس انتشار.

11) CI/CD و گیتس

1. خط/فرمت/نوع بررسی

2. واحد + املاک مبتنی بر

3. ارائه دهنده قرارداد/مصرف کننده

4. کامپوننت (Testcontainers)

5. ادغام + دود Perf

6. امنیت (SAST/اسرار)

7. ساخت/بسته بندی + SBOM

8. استقرار به پیش prod + e2e + هرج و مرج دود

گیتس: توقف در سقوط قراردادها، افزایش تاخیر، آسیب پذیری های بحرانی جدید.

کش و شاردینگ: سرعت بخشیدن به خط لوله به دلیل موازی و افزایشی اجرا می شود (برای ماژول های اصلاح شده).

12) آزمایشات پوسته پوسته: تشخیص و درمان

Autorun + Quorum (2/3 اجرا می شود).
آشکارساز الگوی Flaki: وابستگی به انتظارات زمان/تصادفی/ضمنی.
قرنطینه با SLA: تست انتشار را مسدود نمی کند، اما باید در N روز اصلاح/بازنویسی شود.
تحمل صفر به flucks در «هسته» مسیر بحرانی.

13) مبتنی بر اموال، جهش و آزمایش فاز

مبتنی بر ویژگی: ما خواص (جابجایی، بی نظمی، یکنواختی)، ژنراتورهای داده مرزی را تدوین می کنیم.
تست جهش: ما «قدرت» آزمایشات را اندازه گیری می کنیم (اینکه آیا جهش های معرفی شده را از بین می برند).
Fuzzing: پروتکل ها/تجزیه کننده ها/فرمت ها (JSON، Protobuf، CSV)، به ویژه در مرزهای امنیتی.

prop "serialize/deserialize roundtrip":
forAll(randomModel()):
decode(encode(model)) == model

14) قابلیت مشاهده و ارتباط با تست ها

ردیابی تست (ردیابی شناسه در سیاهههای مربوط): راحت است که در پیش تولید تکرار شود.
عکس های فوری از معیارها در طول اجرای عملکرد به عنوان یک مصنوع ذخیره می شوند.
کنترل ورود: هیچ زمینه حساس، اندازه ورود به سیستم در SLO.

15) مستندات و روش ها

کتابچه راهنمای تست: کجا اجرا شود، چگونه کارخانه ها را بنویسیم، چگونه قراردادها را به روز کنیم.
Runbooks: پخش حادثه، تشخیص سریع، رها کردن رها کردن.
کاتالوگ ثابت: لیستی از تضمین های سیستم و مراجع مربوط به آزمون/هشدار مربوطه.

16) چک لیست معمار

1. Kernel invariants and critical paths (تغییرناپذیر هسته و مسیرهای بحرانی)

2. آیا ماتریسی از سطوح آزمون و SLO آنها (زمان، ثبات) وجود دارد ؟

3. قراردادها در CI در تامین کننده و مصرف کننده نسخه و اعتبار می شوند ؟

4. زمان/تصادفی/شبکه در تست ها کنترل می شود (FixedClock، Fault-injector) ؟

5. Configured Testcontainers/isolated database, are migrations checked?

6. آیا پایگاه های عملکرد و دروازه های رگرسیون وجود دارد ؟

7. آیا SAST/اسرار اسکن و چک ورود به سیستم حریم خصوصی را فعال کنید?

8. Flaky در حال ضبط است و SLA برای اصلاح وجود دارد ؟

9. آیا ارتباط بین آزمونها و prod-SLO و بودجه اشتباه شفاف است ؟

10. آیا کتاب اجرا و کاتالوگ ثابت مستند شده است ؟

نتیجه گیری

استراتژی تست هسته لیستی از ابزارها نیست بلکه یک توانایی معماری است: طراحی قابل آزمایش، سلسله مراتب سطح دقیق، داده های مدیریت شده، تحمل خطا و معیارهای ساخته شده در CI/CD. به دنبال شیوه های توصیف شده، تیم بازخورد سریع و قابل اعتماد دریافت می کند و نسخه ها قابل پیش بینی و امن می شوند.