GH GambleHub

استراتيجية اختبار النواة

1) المبادئ

توازن كأس الهرم. الاختبارات الأساسية - الاختبارات المعيارية السريعة واختبارات العقود ؛ أعلاه - العنصر والتكامل ؛ في القمة توجد الطبقة الدنيا ولكن القيمة e2e.
التحول إلى اليسار. كلما اكتشفنا الخلل مبكرًا (البطانة، التحليل الثابت، القائم على الممتلكات)، كان ذلك أرخص.
حتمية حسب التصميم. نحن ندير الوقت والشبكة والتبعيات العشوائية والخارجية.
اقتصاد الجودة. أي اختبار هو «التأمين»: الهدف هو تقليل التكاليف الإجمالية (العيوب + صيانة الاختبار).
التوجه نحو المخاطرة. وتركز التغطية على الشركات الثابتة والبروتوكولات (العقود، والخصوصية، والاتساق).

2) مستويات الاختبار ومجالات المسؤولية

2. 1 وحدة (وحدات)

تحقق من المنطق الخالص بدون I/O.
نحن نبلل الحدود فقط (المنفذ/المحول)، ونستخدم المصانع للبيانات.
سريع (≤50 -100 مللي ثانية/اختبار)، بالتوازي.

2. 2 العقد (المورد ↔ المستهلك)

إصلاح عقود واجهة برمجة التطبيقات (HTTP/gRPC/event) بين الخدمات.
نحن نستخدم نهجًا يحركه المستهلك: يتم تخزين العقود في VCS، ويتم فحصها في CI للمورد.
تقليل هشاشة التكامل e2e.

2. 3 مكونات (فوق الوحدة، مع تخزين حقيقي)

نطلق جزءًا من الخدمة بقاعدة بيانات/ذاكرة تخزين مؤقت حقيقية في حاوية (Testcontainers).
نحن نتحقق من هجرات المخطط والفهارس والمعاملات والأقفال.

2. التكامل 4/النظام (مسارات شاملة بين الخدمات)

نقوم برفع مجموعة من الخدمات في بيئة معزولة.
نتحقق من الثوابت من طرف إلى طرف: المعاملات، والاسترداد، والغباء، والتعامل مع الأخطاء.

2. 5 E2E (الحد الأدنى من الطبقة «القيمة»)

البروتوكولات والبيئة الحقيقية «كما هو الحال في المبيعات»، ولكن مجموعة سيناريوهات محدودة: الدفع → التأكيد → النشر ؛ التسجيل → التحقق → الدخول.
نستخدم ميزات عالية الخطورة للإفراج والانحدار.

3) الهندسة المعمارية القابلة للاختبار

الموانئ/المحولات (سداسي). النواة التجارية لا تعرف عن HTTP/SQL ؛ عن طريق الوصلات البينية.
حقن الوقت/عشوائي. «الساعة»، «العشوائية» - التبعيات ؛ في الاختبارات التي نصلحها.
تجريد I/O قابل للتكوين. قوائم الانتظار، DB، KMS - من خلال واجهات مع تطبيقات الاختبار.
الثوابت الوظيفية. نحن نصوغ صراحة الشروط البعيدة والمعدلات - يسهل اختبارها ومراقبتها.

4) بيانات الاختبارات

المصانع/البناة بدلاً من تركيبات JSON الثابتة: أقل هشاشة.
البذور الغبية وإعادة ضبط الخطاف DB قبل الاختبار (الهجرات → اقتطاع البذور →).
فهارس الحالة: «المعايير»، «الحواف»، «الأخطاء»، «الفوضى».
المواد التركيبية بدلاً من PD الحقيقي: المولدات، والإخفاء، وملفات تعريف الخصوصية.

5) المنافسة والغباء

اختبارات السباق: الإدخالات التنافسية/الاحتياطيات/الأقفال.
التحقق من المفاتيح الخفية (على سبيل المثال، '(التشغيل، external_id)'): المكالمات المتكررة لا تغير الحالة.
Retrai والمهل: نحن نضمن الصواب في حالة الأخطاء المؤقتة.

Cseudocode (idempotency):

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) الوقت، المهلات، المناطق الزمنية

جميع الأوقات المخزنة هي التوقيت العالمي المنسق ؛ في الاختبارات نستخدم «الساعة الثابتة».
نختبر حالات التوقيت الصيفي (تكرارات/أخطاء الساعة)، نوافذ «اليوم المحلي».
نتحقق من المهلات باستخدام ساعة رتيبة ؛ محاكاة NTP jitter.

7) المرونة والفوضى

حقن الخطأ: أخطاء الشبكة، 5xx، التأخير، التحلل الجزئي (ذاكرة التخزين المؤقت غير متوفرة).
اختبارات الفوضى في بيئة ما قبل الحث: قطع العقد، زيادة التحميل في قوائم الانتظار، كسر BGP/Anycast (المحاكاة).
السياسات الاحتياطية وتدهور UX: يجب أن تؤكد الاختبارات «التدهور الرشيق» الصحيح.

8) الأداء

معايير دقيقة للخوارزميات الحرجة (مع تثبيت وحدة المعالجة المركزية/الألوك).
ملفات تعريف الحمل: خط الأساس (p50/p95)، الإجهاد (الذروة)، (النقع) الموسع لتسريبات الذاكرة.
بوابات الانحدار: يفشل البناء إذا كان زمن انتظار p95 أسوأ من خط الأساس> X٪.

9) السلامة والامتثال

SAST/Lint: ابحث عن نقاط الضعف/المضادات.
DAST/IAST: السيناريوهات الأساسية في المنصة (عينات XSS/SQLi/SSRF).
مسح الأسرار: لا توجد مفاتيح/كلمات مرور في الكود والقطع الأثرية.
اختبارات الخصوصية: عدم وجود PD في السجلات/الآثار، والامتثال لـ «إدارة الموافقة»، وملفات تعريف إخفاء الهوية للتحميلات.

10) مقاييس الجودة و SLO

اختبار معدل النجاح والمؤشر غير المستقر.

التغطية المستهدفة:
  • 90-100٪ لوحدات النواة الحيوية،
  • 70-80٪ للأطراف (مع التركيز على الثوابت).
  • درجة مخاطر الإصدار: المجموع: التغييرات في الملفات الحرجة × انخفاض المعايير × جديد غير مستقر.
  • الميزانية الخاطئة: مزيج من prod-SLO (وقت التشغيل/الأخطاء) مع التجارب وتواتر الإطلاق.

11) CI/CD و Gates

مصفوفة المرحلة:

1. Lint/Format/TypeCheck

2. الوحدة + الممتلكات

3. مقدم العقد/المستهلك

4. المكون (Testcontainers)

5. التكامل + دخان بيرف

6. الأمن (SAST/الأسرار)

7. بناء/حزمة + SBOM

8. نشر الدخان المسبق + e2e + الفوضى

البوابات: توقف عند انخفاض العقود، وزيادة زمن الوصول، ونقاط الضعف الحرجة الجديدة.

المخبأ والشحن: تسريع خط الأنابيب بسبب التوازي والتشغيل التدريجي (للوحدات المعدلة).

12) الاختبارات غير المستقرة: الكشف والعلاج

Autorun + Quorum (2/3 من الأشواط).
كاشف نمط Flaki: الاعتماد على التوقعات الزمنية/العشوائية/الضمنية.
الحجر الصحي مع SLA: الاختبار لا يمنع الإطلاقات، ولكن يجب تصحيحه/إعادة كتابته في أيام N.
عدم التسامح مطلقًا مع التقلبات في «جوهر» المسار الحاسم.

13) الاختبار القائم على الممتلكات والطفرات والمرحلة

قائم على الخاصية: نقوم بصياغة الخصائص (التبديل، الخصوصية، الرتابة)، مولدات البيانات الحدودية.
اختبار الطفرة: نقيس «قوة» الاختبارات (ما إذا كانت تقتل الطفرات المدخلة).
التشويش: بروتوكولات/محللات/تنسيقات (JSON، Protobuf، CSV)، خاصة عند الحدود الأمنية.

مثال خاصية (كاذب):

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

14) إمكانية الملاحظة والارتباط بالاختبارات

آثار الاختبار (معرف ضئيل في جذوع الأشجار): من الملائم التكرار في ما قبل الحث.
يتم تخزين لقطات من المقاييس أثناء تشغيل الأداء كقطعة أثرية.
التحكم في السجل: لا توجد حقول حساسة، حجم السجل داخل SLO.

15) الوثائق والإجراءات

دليل الاختبار: مكان إجراء الاختبارات، وكيفية كتابة المصانع، وكيفية تحديث العقود.
دفاتر التشغيل: حادثة إعادة التشغيل، التشخيص السريع، التراجع عن الإطلاق.
الفهرس الثابت: قائمة بضمانات النظام والإشارات إلى الاختبارات/التنبيهات ذات الصلة.

16) قائمة مراجعة المهندس المعماري

1. وصف ثوابت النواة والمسارات الحرجة ؟

2. هل هناك مصفوفة لمستويات الاختبار و SLO (الوقت، الاستقرار) ؟

3. يتم التحقق من العقود والتحقق منها في CI لدى المورد والمستهلك ؟

4. الوقت/العشوائي/الشبكة المتحكم بها في الاختبارات (الساعة الثابتة، حاقن الصدع) ؟

5. تم تكوين Testcontainers/قاعدة بيانات معزولة، هل يتم فحص الهجرات ؟

6. هل هناك خطوط أساس للأداء وبوابات تراجع ؟

7. هل تم تمكين SAST/Secrets-scan وفحوصات سجل الخصوصية ؟

8. يتم تسجيل Flaky وهل هناك SLA للتصحيح ؟

9. هل العلاقة بين الاختبارات و prod-SLO والميزانية الخاطئة شفافة ؟

10. هل تم توثيق كتاب التشغيل والكتالوج الثابت ؟

خامسا - الاستنتاج

استراتيجية اختبار النواة ليست قائمة من الأدوات ولكنها قدرة معمارية: التصميم القابل للاختبار، والتسلسل الهرمي الصارم، والبيانات المدارة، وتحمل الأخطاء، والمقاييس المضمنة في CI/CD. باتباع الممارسات الموصوفة، يتلقى الفريق ردود فعل سريعة وموثوقة، وتصبح الإصدارات متوقعة وآمنة.

Contact

اتصل بنا

تواصل معنا لأي أسئلة أو دعم.نحن دائمًا جاهزون لمساعدتكم!

Telegram
@Gamble_GC
بدء التكامل

البريد الإلكتروني — إلزامي. تيليغرام أو واتساب — اختياري.

اسمك اختياري
البريد الإلكتروني اختياري
الموضوع اختياري
الرسالة اختياري
Telegram اختياري
@
إذا ذكرت تيليغرام — سنرد عليك هناك أيضًا بالإضافة إلى البريد الإلكتروني.
WhatsApp اختياري
الصيغة: رمز الدولة + الرقم (مثال: +971XXXXXXXXX).

بالنقر على الزر، فإنك توافق على معالجة بياناتك.