أتمتت Diasoft الاختبارات الآلية لواجهات API والأحداث باستخدام AI ونقلت دور QA نحو منطق الأعمال

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

لماذا كانت القوالب غير كافية

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

تعتمد ديازوفت على منصة منخفضة الكود Digital Q.Archer، حيث يتم تخزين عقود API والأحداث. هذا مهم لأن نموذج اللغة الكبير لا يعمل من وصفات عشوائية أو توثيق قديم، بل من نموذج رسمي للخدمة. بفضل هذا، يفهم النظام بشكل أفضل أي نقاط نهاية وأحداث تتعلق فعلاً بالسيناريو، ولا يقضي المختبر الوقت في تحليل يدوي لعشرات الواجهات ويفهم السياق من عملية الأعمال بسرعة أكبر.

كيف يعمل الوكيل

الفكرة الأساسية هي أن الذكاء الاصطناعي لا يتم استخراجه في دردشة منفصلة بجانب التطوير، بل يتم دمجه في منصة Digital Q.DevOps كوكيل اختبار آلي كامل. يوجه منسق الأوركسترا النموذج، ويتحقق من الكود مقابل القواعد الداخلية، ويرسل الاختبار إلى منصة اختبار حقيقية ويعيد الأخطاء إلى دورة التوليد. بهذه الطريقة، لا يكتب نموذج اللغة الكبير مسودة فقط، بل يمر بنفس المسار الذي يتبعه المهندس عادة أثناء تصحيح الأخطاء.

"الذكاء الاصطناعي لا يكتب الكود 'في الدرج'، بل يشغله على الفور على

منصة الاختبار".

بشكل عام، يبدو خط الأنابيب كالتالي:

• يختار المختبر خدمة ويصيغ حالة بلغة الأعمال
• منسق الأوركسترا يجلب Swagger وأنماط JSON للأحداث من Digital Q.Archer
• نموذج اللغة الكبير يختار نقاط النهاية والأحداث ذات الصلة للسيناريو
• يولد النموذج اختبار Groovy، والمنصة تتحقق منه مقابل قواعد المجال
• يعمل الكود على المنصة، وعند الفشل، يتم تحسينه بناءً على السجلات حتى يمر بشكل مستقر

بعد التنفيذ الناجح، يضيف النظام العلامات الخدمية وينشر الاختبار الجاهز في مستودع Git للمنتج.

تم اختيار Groovy للاختبارات لأنه قريب من Java، الذي بُنيت عليه معظم الخدمات الدقيقة للشركة، لكن النهج نفسه لا يرتبط بلغة واحدة.

تؤكد ديازوفت بشكل منفصل على تعقيد اختبار الأحداث: لا يكفي استدعاء API، يجب أيضًا التقاط رسالة في الوسيط، والتحقق من الهيكل والتأكد من أن المحتوى يطابق سيناريو الأعمال والنتيجة المتوقعة للعملية.

كيف يتغير دور فريق ضمان الجودة

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

إنها الصيغة بالضبط التي تصبح الأداة الجديدة للعمل في الأتمتة.

يترتب على هذا أيضًا منطقة جديدة من المسؤولية لفريق ضمان الجودة. بالنسبة للمختبر، لم يعد من المهم جدًا مراجعة الكود المولد بعناية سطرًا تلو الآخر كما هو مهم التحقق من معنى التأكيدات والتأكد من أن الاختبار يثبت فعلاً منطق الأعمال اللازم. بشكل أساسي، يصبح فريق ضمان الجودة مقبولاً لعمل الذكاء الاصطناعي وخبيراً بالموضوع. هناك كود روتيني أقل، لكن متطلبات أعلى لفهم المنتج والعقود المتكاملة وجودة المتطلبات نفسها. هذا أقرب إلى مراجعة السيناريو من البرمجة اليدوية.

ماذا يعني هذا

تُظهر ديازوفت سيناريو عملي حيث تكون نماذج اللغة الكبيرة مفيدة ليس كمساعد لمطور واحد، بل كجزء من خط أنابيب هندسي مُدار. إذا كانت الشركة تمتلك بالفعل عقودًا رسمية ومنصات اختبار وقواعد التحقق، فيمكن نقل توليد الاختبارات الآلية من التجربة إلى العملية الصناعية — خاصة للواجهات البرمجية والأحداث المعقدة التي ظلت سابقًا تقريبًا عملاً يدويًا. هذا ملحوظ بشكل خاص في الأنظمة المالية والتكاملية.