قدمت شركة Slack Engineering نهجًا يسمى الاختبار الوكيل الذي يستكشف كيف يمكن دمج عوامل الذكاء الاصطناعي في الاختبارات الشاملة لتحسين المرونة في أنظمة البرامج الديناميكية. لتحسين المرونة في الأنظمة الموزعة الكبيرة. يستهدف العمل تحديًا شائعًا في بيئات التسليم المستمر، حيث تفشل الاختبارات الشاملة بشكل متكرر بسبب واجهة المستخدم أو تغييرات الخدمة بدلاً من الانحدارات الوظيفية الفعلية، مما يؤدي إلى زيادة تكاليف الصيانة للفرق الهندسية.
تعتمد الاختبارات التقليدية الشاملة على خطوات ثابتة ومحددات ثابتة وتدفقات يمكن التنبؤ بها عبر واجهة المستخدم أو واجهات برمجة التطبيقات. في الأنظمة سريعة التغير، غالبًا ما تنكسر هذه الافتراضات، مما يزيد من جهود الصيانة. يصف مهندسو Slack الاختبار الوكيل بأنه تحويل جزء من هذه المسؤولية من البرامج النصية الثابتة إلى الوكلاء المعتمدين على الذكاء الاصطناعي والتي يتم تنفيذها بناءً على نية ذات مستوى أعلى.
في هذا النموذج، يتم التعبير عن الاختبار باعتباره هدفًا وليس تسلسلًا صارمًا للإجراءات. يفسر وكيل الذكاء الاصطناعي النية ويحاول إكمال سير العمل من خلال التفاعل مع التطبيق من خلال أسطح واجهة المستخدم أو واجهة برمجة التطبيقات. يقوم الوكيل بتقييم حالة التطبيق في كل خطوة ويحدد الإجراءات ديناميكيًا. عند مواجهة تغييرات طفيفة، مثل بنية واجهة المستخدم المعدلة أو العناصر التي تم تغيير موقعها، يحاول الوكيل استخدام مسارات بديلة لمواصلة التنفيذ بدلاً من الفشل على الفور. يتم بعد ذلك التحقق من صحة التنفيذ مقابل التأكيدات المتوقعة التي يحددها المهندسون.
يبدأ سير العمل عادةً بتمرير هدف الاختبار إلى طبقة الوكيل. يقوم الوكيل بإجراء التخطيط، وتنفيذ الإجراءات ضد النظام قيد الاختبار، ومراقبة النتائج، والتكرار حتى اكتمال الهدف أو الوصول إلى حالة التوقف. يتم بعد ذلك تسجيل النتيجة جنبًا إلى جنب مع آثار التنفيذ التي تلتقط تسلسل القرارات والتفاعلات المتخذة أثناء التشغيل. يكتب مهندسو Slack أنه نظرًا لاعتبارات التكلفة، يعد الاختبار الذي يحركه الوكيل حاليًا أكثر ملاءمة لتصحيح الأخطاء المستهدف والاختبار الاستكشافي بدلاً من التنفيذ المتكرر في خطوط أنابيب التكامل المستمر.
تدفق الاختبار التقليدي:
انقر → انقر → اكتب → التأكيد
تدفق اختبار الوكيل:
الهدف ← يتكيف الوكيل ← التحقق من النتيجة
لاحظ مهندسو Slack أن الاختبارات الحتمية تستمر في العمل كآلية أساسية للتحقق من صحة المنطق النقدي وصحة العقد. يتم وضع الاختبار الوكيل داخل الطبقة الشاملة حيث يكون سير العمل أكثر حساسية لواجهة المستخدم والتغييرات الهيكلية. يتم استخدام النهج القائم على الوكيل لتقليل حالات الفشل الناجمة عن التغييرات السطحية التي لا تعكس الانحدارات الوظيفية.
يتضمن النظام أيضًا قيودًا للتحكم في سلوك الوكيل أثناء التنفيذ. وتشمل هذه القيود على الإجراءات المسموح بها، وحدود الاستكشاف، والشروط التي يجب أن يتوقف التنفيذ بموجبها. تعتبر إمكانية المراقبة مطلبًا رئيسيًا، ويتم تنظيم سجلات التنفيذ لتوفير رؤية لكل خطوة يتخذها الوكيل، مما يمكّن الفرق من إعادة تشغيل حالات الفشل وفحصها.
هرم الاختبار ذو أربع طبقات: اختبارات الوحدة، واختبارات التكامل، واختبار E2E، واختبار الوكيل (المصدر: منشور مدونة Slack)
تضع الهندسة الركود الاختبار الوكيل كقدرة تكميلية بدلاً من أن تكون بديلاً لمناهج الاختبار الحالية. تستمر الاختبارات الحتمية الشاملة في دعم التحقق من الانحدار السريع والمتكرر في CI، بينما يتم تطبيق التنفيذ القائم على الوكيل حيث تؤدي تغييرات واجهة المستخدم إلى الهشاشة. توفر الاختبارات المكتوبة أو التي تم إنشاؤها تحققًا مستقرًا للرحلات المحددة مسبقًا، في حين يعمل التنفيذ المستند إلى الوكيل من نموذج موجه نحو الهدف، ومراقبة حالة التطبيق وتحديد كيفية الوصول إلى النتيجة المرجوة ديناميكيًا. وهذا يجعله مفيدًا لاستكشاف سلوك واجهة المستخدم المعقدة، وتصحيح أخطاء سير العمل غير المستقر، وإعادة إنتاج مشكلات الإنتاج، جنبًا إلى جنب مع الاختبارات الحتمية التقليدية داخل الطبقة الشاملة.
