عرضت Sber كيف يحوّل RAG وLLM داخل IDE السيناريوهات اليدوية إلى اختبارات آلية

أظهر Sber كيفية تقليل أحد أكثر المهام روتينية في QA: تحويل سيناريوهات الاختبار اليدوية إلى اختبارات آلية مباشرة في IDE. في الأساس يكمن مزيج من LLM و RAG، والذي لا يكتفي بكتابة الكود بل يبحث أولاً عن أمثلة ذات صلة داخل المشروع نفسه للحفاظ على أسلوبه واتفاقياته وبنيته المعمارية.

لماذا الاستفسار المباشر لا يعمل

تنهار فكرة "ما عليك سوى إرسال اختبار يدوي للنموذج والحصول على كود جاهز" في الممارسة العملية أمام التفاصيل. يمكن لـ LLM بالفعل تجميع اختبار Java يعمل، لكنه بكل تأكيد لن يفعل ذلك بالطريقة المقبولة في فريق معين: سينسى Allure، سينتهك مخطط التسمية، سيضع عناوين URL وأجسام الطلب في المكان الخاطئ، سيضيف فحوصات غير ضرورية أو لن يستخدم الأدوات الداخلية مثل طريقة التحقق من الحالة المشتركة. بالنسبة لأتمتة الاختبار، هذا ليس مسألة تجميل بل فقدان فعلي للتوافق مع المشروع.

المشكلة أعمق من مجرد جودة الاستفسار. تعيش الاختبارات المؤتمتة داخل إطار عملها الخاص، مرتبطة بالبنية المعمارية و CI و Page Object ومفاتيح TMS واتفاقيات التعليقات التوضيحية. إذا حاولت تمرير المشروع بالكامل للنموذج، فستصطدم بسرعة بقيود نافذة السياق وزيادة الكمون وتكاليف الطلبات.

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

كيف يعمل RAG

بدلاً من few-shot الثابت مع الأمثلة المختارة يدويًا، أنشأت فريق Sber مكونًا إضافيًا لـ JetBrains IDE. يفحص المشروع من خلال بنية PSI، وليس كنص خام، لذا فهو يرى الفئات والطرق والتعليقات التوضيحية والاستدعاءات. على أساس هذا، يقوم النظام بجمع خطوات Allure واختبارات مؤتمتة موجودة ومفاتيح TMS الخاصة بها والكود والأوصاف النصية المختصرة. بعد ذلك، يتم تحويل هذه الأوصاف إلى تضمينات وحفظها جنباً إلى جنب مع البيانات الوصفية في قاعدة معرفة محلية أو مستودع متجه. عندما يأتي سيناريو يدوي جديد للعمل، يمر النظام بعدة مراحل:

• يحدد الإجراء والنتيجة المتوقعة لكل خطوة؛
• ينشئ عدة متغيرات استفسار دلالية للبحث عن خطوات مماثلة؛
• يطلب من LLM وصف الاختبار بأكمله بإيجاز للعثور على اختبار مؤتمت مماثل بالمعنى؛
• يستبدل تلقائيًا الأمثلة الموجودة في الاستفسار بدلاً من few-shot اليدوي؛
• يتحقق من النتيجة من خلال طلب متكرر للنموذج وعبر PSI داخل IDE.

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

RAG هو few-shot يجد الأمثلة الضرورية بنفسه.

نتائج النموذج الأولي

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

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

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

ماذا يعني هذا

بالنسبة لأدوات الذكاء الاصطناعي في التطوير، تبدأ مرحلة أكثر إثارة للاهتمام: تتحول القيمة من "توليد أي كود" إلى "توليد كود يندمج مباشرة في مشروع حي". تُظهر قصة Sber أنه في QA، ستفوز فريقًا وليس تلك التي تربط ببساطة LLM إلى IDE، بل تلك التي تلف النموذج حول قاعدة معرفتها الخاصة والفحوصات والقواعس الهندسية.