אסטרטגיית בדיקת קרנל

1) עקרונות

איזון גביע פירמידה. בסיס - בדיקות מודולריות מהירות וחוזים; רכיב למעלה ואינטגרציה; בשיא היא שכבת e2e אך מינימלית אך בעלת ערך.
משמרת שמאלה. מוקדם יותר אנחנו תופסים את הפגם (לינטר, ניתוח סטטי, מבוסס רכוש), זול יותר.
דטרמיניסטי על ידי עיצוב. אנחנו מנהלים זמן, רשת, תלות אקראית וחיצונית.
כלכלה איכותית. כל בדיקה היא ”ביטוח”: המטרה היא למזער עלויות (פגמים + תחזוקת מבחן).
נטיית סיכון. הכיסוי מתרכז באינווריאנטים עסקיים ופרוטוקולים (חוזים, אידמפוטנטיות, עקביות).

2) רמות של בדיקות ותחומי אחריות

2. יחידה 1 (מודולרית)

בדוק היגיון טהור ללא איי-או.
אנחנו מרטיבים רק את הגבולות (מתאם יציאה), אנחנו משתמשים במפעלים למידע.
מהיר (מנומר 50 - 100 ms/test), מקביל.

2. 2 חוזה (ספק ↔ צרכן)

תיקון חוזי API (HTTP/gRPC/event) בין שירותים.
אנו משתמשים בגישה המונעת על ידי צרכנים: חוזים מאוחסנים בוידאו-סי-אס, נבדקים במודיע של הספק.
להפחית את שבריריות האינטגרציה e2e.

2. 3 רכיבים (מעל המודול, עם אחסון אמיתי)

אנחנו משיקים חלק מהשירות עם מסד נתונים/מטמון אמיתי במיכל (Testcontainers).
אנחנו מאשרים נדודים, אינדקסים, עסקאות, מנעולים.

2. 4 אינטגרציה/מערכת (מסלולים מקצה לקצה בין השירותים)

אנחנו מגדלים סט של שירותים בסביבה מבודדת.
אנחנו בודקים אינווריאנטים מקצה לקצה: טרנזיטיביות, רטריי, אידמפוטנטיות, טיפול בטעויות.

2. 5 E2E (מינימום ”ערך” שכבה)

פרוטוקולים אמיתיים וסביבה ”כמו במכירות”, אבל תרחיש מוגבל נקבע: תשלום לאמת פרסום; אימות רישום = רשומה.
אנחנו משתמשים בתכונות בסיכון גבוה לשחרור ורגרסיה.

3) ארכיטקטורה ניתנת לבדיקה

נמלים/מתאם (הקסגונלי). הגרעין העסקי אינו יודע על HTTP/SQL; תלות מיושמת באמצעות ממשקים.
הזרקת זמן/אקראי. 'שעון', 'רנדום' - תלויות; במבחנים שאנחנו מתקנים.
אבסטרקציה של I/O ניתנת להגדרה. תורים, DB, KMS - באמצעות ממשקים עם יישומי מבחן.
פולשים פונקציונליים. אנחנו מגבשים במפורש הנחות וחיזוי - קל יותר לבדוק ולעקוב אחריהם.

4) נתונים לבדיקות

מפעלים/בנאים במקום אבזרי JSON סטטיים: פחות שבריריות.
זרעים אידמפוטנטיים וקרס אתחול DB לפני הבדיקה (נדידה = truncate = זרע).
קייס מקטלג: ”נורמות”, ”קצוות”, ”טעויות”, ”כאוס”.
סינתטיים במקום משטרה אמיתית: גנרטורים, מיסוך, פרופילי פרטיות.

5) תחרות ואידמפוטנטיות

מבחני מירוץ: רשומות תחרותיות/רזרבות/מנעולים.
בדיקת מפתחות אידמפוטנטים (לדוגמה, '(פעולה, external_id)'): קריאות חוזרות אינן משנות מצב.
רטריי ופסקי זמן: אנו מבטיחים תקינות במקרה של טעויות זמניות.

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, עיכובים, השפלה חלקית (מטמון לא זמין).
בדיקות כאוס בסביבה הקדם-פרודית: ניתוק צמתים, עומס תורים, שבירת BGP/Anycast (הדמיה).
מדיניות הגיבוי והשפלת ה-UX: בדיקות חייבות לאשר את ”השפלה החיננית” הנכונה.

8) ביצועים

Micro benchmarks עבור אלגוריתמים קריטיים (עם קיבעון מעבד/אלוק).
פרופילי טעינה: קו בסיס (p50/p95), לחץ (peak), מורחב (soak) לדליפות זיכרון.
שערי נסיגה: בנייה נכשלת אם p95 latency גרוע יותר מקו הבסיס> X%.

9) בטיחות וציות

SAST/Lint: חפש נקודות תורפה/אנטי-פטריות.
DAST/IAST: תרחישים בסיסיים בדוכן (דגימות XSS/SQLi/SSRF).
סודות-סריקה: אין מפתחות/סיסמאות בקוד וחפצים.
בדיקות פרטיות: היעדר PD ביומנים/עקבות, ציות ל ”ניהול הסכמה”, פרופילים אנונימיים להעלאה.

10) מדדי איכות ו ־ SLO

קצב מעבר מבחן ומדד רעוע.

• 90-100% עבור מודולי גרעין קריטיים,
• 70-80% לפריפריה (עם התמקדות באינווריאנטים).
• ציון סיכון שחרור: טוטאליות: שינויים בקבצים קריטיים xfall benchmarks × חדשות.
• תקציב שגוי: שילוב של פרוד-SLO (uptime/images) עם ניסויים ותדירות שחרור.

11) CI/CD ושערים

1. מוך/תבנית/בדיקת TypeCheck

2. יחידה + מבוססת נכס

3. ספק חוזים/צרכן

4. רכיב (בוחנים)

5. עשן אינטגרציה + Perf

6. אבטחה (SAST/סודות)

7. לבנות/חבילה + SBOM

8. לפרוס לעשן קדם-פרוד + e2e + כאוס

עצור בחוזים נופלים, איחור הולך וגדל, נקודות תורפה קריטיות חדשות.

מטמון ושדרוג: להאיץ צינור בשל מקביליות וריצות אינקרמנטליות (עבור מודולים מותאמים).

12) בדיקות מדשדשות: זיהוי וטיפול

Autorun + Quorum (2/3 של ריצות).
גלאי תבניות פלאקי: תלות בציפיות זמן/אקראיות/מרומזות.
הסגר עם SLA: הבדיקה אינה חוסמת שחרור, אלא חייבת להיות מתוקנת/משוכתבת בימים N.
אפס סובלנות לדפדף ב ”ליבה” של המסלול הקריטי.

13) מבוסס רכוש, מוטציה ובדיקת פאזה

על בסיס תכונה: אנחנו מגבשים תכונות (קומוטציה, אידמפוטנטיות, מונוטוניות), מחוללי מידע גבולות.
בדיקת מוטציה: אנו מודדים את ”הכוח” של המבחנים (בין אם הם הורגים את המוטציות שהוצגו).
Fuzzing: פרוטוקולים/פרזרים/פורמטים (JSON, Protobuf, CSV), במיוחד בגבולות אבטחה.

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

14) יכולת התבוננות והתרועעות עם מבחנים

עקבות בדיקה (trace-id in logs): זה נוח לשכפל בקדם-פרוד.
צילומי מדדים במהלך ריצת ביצועים מאוחסנים כחפץ.
בקרת רישום: אין שדות רגישים, גודל רישום בתוך SLO.

15) תיעוד ונהלים

Test Handbook: איפה להריץ את הבדיקות, איך לכתוב מפעלים, איך לעדכן חוזים.
תקרית שידור חוזר, אבחנה מהירה, שחרור גלגיליות.
קטלוג אינווריאנטי: רשימת ערבויות מערכת והפניות לבדיקות/התראות רלוונטיות.

16) רשימת אדריכלים

1. קורנלים ונתיבים ביקורתיים מתוארים?
2. האם יש מטריצה של רמות מבחן ו-SLO (זמן, יציבות) שלהם?
3. חוזים ממומשים ומאומתים במודיע אצל הספק והצרכן?
4. זמן/אקראי/רשת מבוקרת במבחנים (שעון, מזרק-פגם)?
5. מסדי נתונים מוגדרים/מסד נתונים מבודד, האם נבדקו הגירות?
6. האם יש קווי בסיס ביצועים ושערי רגרסיה?
7. האם בדיקת SAST/סודות ורישום פרטיות הופעלו?
8. פלאקי מוקלט והאם יש אס-אל-איי לתיקון?
9. האם הקשר בין הבדיקות ל-PROD-SLO לבין התקציב השגוי שקוף?
10. האם ספר ההפעלה וקטלוג ההמצאה מתועדים?

מסקנה

אסטרטגיית בדיקת הגרעין אינה רשימה של כלים אלא יכולת ארכיטקטונית: עיצוב בר-בחינה, היררכיית רמה קפדנית, נתונים מנוהלים, סובלנות לקויה ומדדים הבנויים לתוך CI/CD. בעקבות ההתנהלות המתוארת, הצוות מקבל משוב מהיר ואמין, ושחרורים הופכים להיות צפויים ומאובטחים.