وكيل ذكاء اصطناعي يعمل بـ GPT-5.5 يراجع 2600 اختبار آلي في TravelLine خلال أسبوعين

أجرى مختبِر البرمجيات في TravelLine، إلسور مينغازوف، خلال أسبوعين تدقيقًا للاختبارات الآلية في منصة الفنادق بمساعدة وكيل ذكاء اصطناعي. خضع نحو 2600 اختبار من قاعدة تضم 6500 سيناريو E2E لتحليل دلالي، بينما جُمعت إحصاءات التشغيل لقاعدة الاختبارات بالكامل. جاء التدقيق بسبب انتقال مخطط له للاختبارات من Java إلى .NET. ورأى الفريق أن النقل «كما هو» سيجلب إلى المنصة التقنية الجديدة الدين التقني المتراكم على مدى 15 عامًا. وفي النتيجة حُذف نحو 450 اختبارًا لم تعد ذات صلة في قسم الاختبار بلقطات الشاشة، وفُتحت مهام لكتابة اختبارات integration في عدد من الأقسام.

بيئة عمل الوكيل: الكود وMCP واختيار النموذج

لا تكفي قائمة بأسماء السيناريوهات من نظام TMS لمثل هذا العمل، لذلك جُهّز للوكيل سياق كامل. وتألفت بيئة العمل مما يلي:

• OpenCode — البيئة التي يعمل فيها الوكيل.
• المستودعات المحلية — نسخ من مستودعي المنتج ومشروع الاختبارات الآلية. يتجول الوكيل بنفسه بين المجلدات، ويبحث عن الدوال والفئات، ويطابق الاستدعاءات، دون نسخ أي شيء إلى السياق يدويًا.
• TestIT عبر MCP — جُرّبت أولًا الطلبات المباشرة إلى API، ثم جرى الانتقال إلى خادم MCP. يستدعي الوكيل أدوات جاهزة، ويجلب الخادم الكيانات والبيانات الوصفية وعمليات التشغيل.
• GPT-5.5 — اختاره الفريق من فهرس OpenCode. واستُبعدت نسخ Flash الخفيفة فورًا، لأنها كانت تفقد التفاصيل عند مطابقة البنية والمنطق المعقد. أما GPT-5.5 فقد استوعب موجِّهًا طويلًا يتضمن قواعد هرم الاختبار، واستدعى أدوات MCP بدقة، ولم يختلق روابط بين الاختبارات والكود.
• موجِّه النظام وعقد الاستجابة — معايير التقسيم بين E2E وintegration، إضافة إلى صيغة markdown صارمة للتقرير دون حشو.

كان أول اختبار موجّهًا إلى الوكيل نفسه. فحين طُلب منه تحليل قسم ما، أعاد قائمة ناقصة. وتبيّن من سجلات الاستدلال أنه اعتمد على مجموعات الاختبار (suites)، بينما كان المختبِر ينتظر شجرة الأقسام والأقسام الفرعية. وساعد في الحل تقديم لقطة شاشة للشجرة وشرح مفصل لمكان جلب الاختبارات. بعد ذلك ثُبّت ترتيب العمل في تعليمات الوكيل.

الدورة الأولى: النقل أو التنزيل أو عدم المساس

كان على الوكيل في ملف skill.md أن يمنح كل اختبار واحدة من ثلاث علامات:

• MIGRATE_TO_NET — سيناريو مطلوب يُنقل إلى إطار .NET كما هو تمامًا؛
• SHIFT_TO_INTEGRATION — منطق أعمال أو API ينبغي تسليمه لمطوري الواجهة الخلفية لكتابة اختبارات integration؛
• OBSOLETE_OR_BROKEN — الوظيفة محذوفة أو تغيّرت، أو الاختبار معطّل، أو يكرر اختبارًا آخر، أو زائد عن الحاجة بوصفه فحص UI؛ لا يُنقل.

أدرج الوكيل ضمن E2E المسار الناجح الحرج (happy path)، والمسارات الشاملة للمستخدم، وترابط الأنظمة الفرعية، والتنقل والعرض. وأدرج ضمن integration الحسابات، والتحقق من تركيبات البيانات، وحفظ الإعدادات والحدود، أي كل ما يبطئ فيه المتصفح التنفيذ فحسب.

مثال واضح على ذلك قسم Transfers. من أصل 18 اختبار E2E، طابق الوكيل السيناريوهات مع اختبارات integration الموجودة، ووجد أن 15 منها تكرر فحوصات المستوى الأدنى، لكنها تفعل ذلك بتكلفة أعلى ومخاطر أكبر لحالات الفشل غير المستقر. والنتيجة: 3 اختبارات في MIGRATE_TO_NET، و0 في SHIFT_TO_INTEGRATION، و15 في OBSOLETE_OR_BROKEN. أما النقل المباشر فكان سيضيف 15 سيناريو زائدًا على .NET: وقت تشغيل أطول، وإخفاقات أكثر تحتاج إلى تحليل، وكودًا أكثر للصيانة.

الدورة الثانية: P85 للإخفاقات والمدة

لا يُظهر الكود عدد مرات فشل الاختبار ولا المدة التي يستغرقها فعليًا. لذلك طُلب من TestIT لكل اختبار من الاختبارات البالغ عددها نحو 6500 ما يصل إلى 100 نتيجة أخيرة، وجُمعت النتائج بحسب الأقسام. وحُسب مؤشران:

• fail rate — حصة نتائج Failed من العدد الإجمالي، فمثلًا 10 من 100 تعني 10%؛
• P85 للمدة — بحسب عمليات التشغيل بحالة Passed؛ ولم تُحتسب الاختبارات الفاشلة كي لا تشوّه مهلات الانتظار (timeouts) الصورة.

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

في قسم reports أحصى الوكيل 245 اختبارًا، و24 051 عملية تشغيل، و1598 إخفاقًا، أي fail rate بنسبة 6,6%. وبحسب الإخفاقات وحدها وقع 29 اختبارًا في منطقة المشكلة، وبحسب المدة وحدها 28 اختبارًا، وبحسب المعيارين معًا 9 اختبارات. وأعدّ الوكيل لهذه الاختبارات التسعة تقريرًا بصيغتي DOCX وMarkdown (passed / failed / P85 passed بالثواني):

• تعديل معاملات الطلب — 87 / 11 / 131,0؛
• إلغاء العملية مع إعادة احتساب جزئية — 86 / 11 / 102,0؛
• تصفية البيانات بحسب المعاملات — 88 / 10 / 308,0؛
• التحقق من المنطقة الزمنية في التقارير — 78 / 10 / 170,9؛
• التحقق من الدورية في عمليات التصدير — 75 / 11 / 162,0؛
• تأكيد حالة الكيان — 74 / 11 / 144,1؛
• إتمام إنهاء الطلب — 75 / 9 / 169,8؛
• إرسال الإشعارات المعاملاتية — 70 / 19 / 240,1؛
• معالجة الدفع وتنفيذ الاسترداد — 63 / 33 / 253,7.

ما يمكن أن تتعلمه فرق أخرى

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

والدرس عملي للفرق التي تملك قاعدة اختبارات كبيرة. يحتاج الوكيل إلى وصول إلى الكود وإلى نظام إدارة الاختبارات عبر MCP، لا إلى قائمة بالأسماء. وعلامات القرار أنفع من الأوصاف، وينبغي إدراج الفحص الأولي للوكيل في الخطة. ومن المنطقي البدء بتحليل الاختبارات التي تجمع بين الطول وعدم الاستقرار. ويبقى الوكيل المُهيَّأ بقواعد التحليل في الفريق، ويمكنه تحليل الإخفاقات، والبحث عن التغطية الموجودة، وتقييم السيناريوهات الجديدة دون إعادة تجميع السياق من الصفر.