مجموعة اختبارات من ثلاث طبقات يجب أن يجتازها كل إصدار لمنصة ذكاء اصطناعي وبيانات
اختبارات وحدات وتكامل ومسار كامل لواجهة خلفية مكتوبة بلغة Python لم تكن لها أي اختبارات، تعمل مع كل طلب دمج (pull request) ويجب أن تنجح قبل أن يُدمج أي إصدار.
- الشريك
- شركة استشارية متعددة الجنسيات
- المدة
- 3 أشهر
- طبقات اختبار
- 3
- الوحدات والتكامل والمسار الكامل
- بوابة الدمج
- كل طلب دمج
- أي اختبار فاشل يوقف الإصدار
- فحوص حية
- كل ليلة
- اختبارات تكامل مقابل الخدمات الفعلية
التحدي
كانت منصة الذكاء الاصطناعي والبيانات الداخلية لدى الشركة تعمل بواجهة خلفية مكتوبة بلغة Python ومتصلة بـ PostgreSQL وClickHouse وPrefect وAzure Blob Storage وخدمات تفويض داخلية ونماذج لغوية. ولم تكن هناك أي اختبارات، فكان كل إصدار يعتمد على فحوص يدوية.
ما بنيناه
مجموعة اختبارات مبنية على Pytest من ثلاث طبقات، تعمل في GitHub Actions مع كل طلب دمج. وتستخدم اختبارات التكامل استجابات مسجّلة مسبقًا، فتعطي النتيجة نفسها في كل مرة، وتشغّلها مهمة ليلية مقابل الخدمات الحية. وتُفحص ميزات النماذج اللغوية من حيث البنية في كل تشغيل، ومن حيث الجودة مقابل مجموعة مرجعية كل ليلة.
ما تم تسليمه
- مجموعة اختبارات يجب أن تنجح قبل دمج أي إصدار
- اختبارات تكامل قابلة للتكرار لكل اعتمادية خارجية ضمن النطاق
- فحص ميزات النماذج اللغوية من حيث البنية والجودة
نبذة عن الشريك
شريكنا شركة استشارية متعددة الجنسيات بنت منصة داخلية للذكاء الاصطناعي والبيانات لفرقها. وفي نسختها الأولى، كانت الواجهة الخلفية للمنصة تعتمد على قاعدتي بيانات، وأداة لتنسيق سير العمل، وتخزين سحابي، وخدمات أمنية داخلية، ونماذج لغوية. وأرادت الشركة أن تُصدر التحديثات بوتيرة متكررة دون الاعتماد على فحوص يدوية قبل كل إصدار.
التحدي
لا شبكة أمان
كانت الواجهة الخلفية تعالج طلبات API وعمليات قواعد البيانات والتكاملات الخارجية، لكن لم تكن لها أي اختبارات مؤتمتة. فكان كل تغيير يُفحص يدويًا، أو لا يُفحص أصلًا.
اعتماديات خارجية كثيرة
كان لا بد من اختبار خدمات التفويض وPrefect وPostgreSQL وClickHouse وAzure Blob Storage والنماذج اللغوية كلٌّ على حدة، والاختبارات التي تستدعي خدمات حية بطيئة وقد تتغير نتائجها من تشغيل إلى آخر.
مخرجات النماذج متغيرة
نادرًا ما يعطي النموذج اللغوي الإجابة نفسها مرتين، فلا يمكن للاختبار أن يكتفي بمقارنة مخرجاته بنص ثابت.
سير عمل، لا دوال منفردة
تكمن قيمة المنصة في سير العمل متعدد الخطوات. واختبار الدوال منفردة لا يبيّن ما إذا كان سير العمل الكامل يعطي النتيجة الصحيحة.
الأهداف
- اختبارات مؤتمتة في كل طبقة من طبقات الواجهة الخلفية
- مجموعة اختبارات توقف الإصدار عند فشلها
- نتائج قابلة للتكرار من الاختبارات التي تتعامل مع خدمات خارجية
- طريقة لفحص ميزات النماذج اللغوية رغم تغيّر مخرجاتها
- بنية يمكن توسيعها لتشمل الميزات والتكاملات الجديدة
دورنا
صممت كارسنترك إطار الاختبارات، وكتبت طبقات الاختبار الثلاث، وربطتها بعملية الإصدار على مدى ثلاثة أشهر.
النطاق والجدول الزمني
شمل العمل اختبارات وحدات للخدمات والوحدات البرمجية، واختبارات تكامل لكل اعتمادية خارجية، واختبارات مسار كامل لمسارات سير العمل الرئيسية، ومهام التكامل المستمر التي تشغّلها. وتم التسليم خلال ثلاثة أشهر.
المنهجية
إطار واحد وثلاث طبقات
يشغّل Pytest الطبقات الثلاث بتجهيزات اختبار (fixtures) وأعراف مشتركة، فينتقل المساهمون بين الطبقات بسهولة، ويشغّل أمر واحد كل شيء.
التسجيل ثم إعادة التشغيل
تسجّل اختبارات التكامل استجابات كل خدمة خارجية مرة واحدة، ثم تستخدم هذه التسجيلات مع كل طلب دمج، فتبقى سريعة وقابلة للتكرار. وتشغّل مهمة ليلية الاختبارات نفسها مقابل الخدمات الحية، فيُكتشف أي تغيير في الطرف الآخر خلال يوم واحد.
البنية في كل تشغيل، والجودة كل ليلة
في كل تشغيل، تُفحص ميزات النماذج اللغوية من حيث البنية: الحقول والأنواع والطول المتوقعة. وكل ليلة، تُقيَّم إجاباتها مقابل مجموعة مرجعية صغيرة، وتفشل المهمة إذا جاءت النتيجة دون الحد المتفق عليه.
التنفيذ
اختبارات الوحدات
تغطي اختبارات الوحدات نقاط نهاية API، والأدوات التي تعالج البيانات وتحوّلها وتتحقق من صحتها.
اختبارات التكامل
تعمل عمليات قواعد البيانات على PostgreSQL وClickHouse في حاويات مؤقتة مع كل طلب دمج. وتغطي اختبارات التكامل أيضًا خدمات التفويض والمصادقة، وتنسيق المهام عبر Prefect، واستدعاءات النماذج اللغوية، ورفع الملفات إلى Azure Blob Storage واسترجاعها ومعالجتها.
اختبارات المسار الكامل
تشغّل اختبارات المسار الكامل تدفقات بيانات كاملة من تنسيق Prefect حتى التخزين في PostgreSQL وClickHouse، وميزة توليد المحتوى بالذكاء الاصطناعي، وتلخيص الاجتماعات من المُدخل المسجّل حتى الملخص المسلَّم.
بوابة الإصدار
يشغّل GitHub Actions مجموعة الاختبارات مع كل طلب دمج ويعرض نسبة التغطية عليه. وتشترط حماية الفروع (branch protection) تشغيلًا ناجحًا قبل دمج أي شيء.
الأدوات والتقنيات
| الأداة | الغرض |
|---|---|
| Pytest | إطار الاختبارات للطبقات الثلاث |
| pytest-recording | استجابات مسجّلة لاختبارات تكامل قابلة للتكرار |
| Testcontainers | نسخ مؤقتة من PostgreSQL وClickHouse لكل تشغيل |
| GitHub Actions | تشغيل مجموعة الاختبارات مع كل طلب دمج وكل ليلة |
| PostgreSQL وClickHouse | قواعد البيانات الخاضعة للاختبار |
| Prefect | تنسيق سير العمل الخاضع للاختبار |
| Azure Blob Storage | تخزين الملفات الخاضع للاختبار |
| واجهات API للنماذج اللغوية | ميزات الذكاء الاصطناعي الخاضعة للاختبار |
ما تم تسليمه
- طبقات اختبار
- 3
- بوابة الدمج
- كل طلب دمج
- فحوص حية وفحوص جودة
- كل ليلة
- مدة التسليم
- 3 أشهر
- مجموعة اختبارات مبنية على Pytest من ثلاث طبقات، تعمل مع كل طلب دمج
- منع الدمج عند فشل أي اختبار
- اختبارات تكامل مسجّلة، مع تشغيل ليلي مقابل الخدمات الحية
- فحص بنية ميزات الذكاء الاصطناعي في كل تشغيل، وتقييم جودتها كل ليلة
لماذا يهم ذلك
لا تجعل مجموعة الاختبارات الإصدارات متوقعة إلا حين يتعذّر إصدار أي شيء دونها. وتشغيلها مع كل طلب دمج، وإبقاؤها قابلة للتكرار بحيث يدل أي فشل على مشكلة حقيقية، هو ما يتيح لمنصة متنامية أن تُصدر بوتيرة متكررة.
إذا كانت مؤسستكم تواجه تحديًا مشابهًا، يسعدنا أن نناقشه معكم.