أتمتة واجهة المستخدم لمواقعك وتطبيقاتك التي تبنيها بنفسك

ما يمكن للوكيل فعله لاختباراتك

• الملفاتتعمل أدوات read_file و write_file و append_file و edit_file و delete_file و make_dir و move_file و copy_file و list_dir و grep و glob داخل مجلد عمل الدردشة، ويعرض العداد عدد الملفات التي تم إنشاها أو تحريرها أو قراءتها.
• Shellيشغّل أمر الاختبار الخاص بك، أو أداة التدقيق أو عملية البناء على Windows المحلي أو WSL أو عبر SSH على خادم تملكه، ويحكم على النجاح بناءً على رمز الخروج الفعلي. يتم حظر الأوامر الخطرة.
• الويبتجد web_search الصفحات، ويقرأ http_get صفحة توثيق رسمية واحدة، بحيث يمكن التحقق من سؤال حول محدد أو فترة انتظار ضد الدليل الخاص بالإطار نفسه.
• لقطات الشاشة والصورتقرأ أداة ocr النص في لقطة شاشة محفوظة، مثل شريط الخطأ في تشغيل فاشل، وتقوم gen_image بحفظ ملفات الصور الحقيقية عند الحاجة.
• التنسيقتقسم task عمليات التحقق المستقلة عبر وكلاء فرعيين متوازيين، ويرسل run_on_model خطوة صعبة واحدة إلى نموذج أكبر، ويخزن skill مجموعة قواعد قابلة لإعادة الاستخدام مثل روتين الإصلاح المعتاد لديك.
• أوضاع الموافقةيعمل Auto-run فوراً، ويوقف Ask first قبل الإجراءات التي تغير شيئاً ما ويعرض الاختلاف (diff)، ويكتب Plan only خطة ولا يشغل شيئاً. تبقى الخطط سارية بعد إعادة التشغيل.
• جدولة Cronيشغّل مطالبة حسب جدول زمني، مثلاً لتشغيل أمر الاختبار في الأوقات التي تحددها والإبلاغ عن رمز الخروج في الدردشة، بحيث يكون التدفق الذي تعطل ليلاً هو أول ما تقرأه.
• النماذجاربط مزود ذكاء اصطناعي سحابياً عبر نقطة نهاية API قياسية، أو نموذج يعمل محلياً على جهازك، أو النموذج المدمج الجاهز للاستخدام دون الحاجة لنقطة نهاية خاصة بك. يتحقق زر Test من نقطة النهاية قبل البدء.

أربع مهام يقوم بها الوكيل في مشروع الاختبار

كتابة التدفق الأول

تبدأ أفضل الممارسات لاختبارات e2e بقائمة قصيرة من التدفقات التي يجب ألا تنكسر أبداً، لذا اطلب من FlowLatch كتابة تلك فقط. تُظهر أدوات list_dir و glob كيفية تسمية اختباراتك الحالية، ويفتح read_file ملفاً كنموذج، وينشئ write_file الملف الجديد لتدفق تسجيل الدخول بحساب اختبار وبيانات وهمية. ثم يشغّل Shell أمر الاختبار الخاص بك، وتعرض البطاقة رمز الخروج الفعلي. نادراً ما يكون المسودة الأولى نهائية، لذا اطلب تغييراً واحداً في كل مرة، مثل اسم أكثر وضوحاً أو إضافة فحص لنص الصفحة. قبل القبول، اقرأ الملف الجديد في الاختلاف (diff)، وشغّله بنفسك مرة واحدة واحتفظ به فقط إذا كان يطابق التدفق الذي قصدته.

تشغيل المجموعة وقراءة الفشل

يشغّل Shell أمر الاختبار الخاص وتحتفظ البطاقة بالمخرجات الكاملة، لذا فإن نتيجة الفشل ليست مجرد تخمين. تبحث grep في تلك المخرجات عن الخطوة الفاشلة، وإذا كان إطار عملك قد حفظ لقطة شاشة، تقرأ أداة ocr الرسالة فيها. لتقليل عدم الثبات في اختبارات end to end، اطلب من FlowLatch تشغيل الاختبار الفاشل مرة أخرى بنفس الأمر ومقارنة رموز الخروج. يشير نجاح متبوع بفشل إلى فترة انتظار ثابتة، أو بيانات اختبار مشتركة، أو ترتيب الاختبارات. اطلب شرحاً موجزاً في الدردشة، ثم راجعه مقابل المخرجات قبل تغيير أي ملف.

إصلاح محدد بعد تغيير في التخطيط

يعتمد ما إذا كانت اختبارات e2e تستحق الوقت لعمل الواجهة الأمامية على التدفق، لذا غطِ تسجيل الدخول وإتمام الشراء أولاً. عندما يتغير تخطيط الصفحة، تجد grep كل المحددات المرتبطة به، ويظهر read_file الخطوات المحيطة ويقترح edit_file تسميات مستقرة أو معرّفات اختبار بدلاً منها. في وضع Ask first، يتوقف FlowLatch قبل كل تعديل ويعرض الاختلاف (diff)، ملفاً واحداً في كل مرة. اقبل الأسطر التي تبدو صحيحة، ارفض الباقي، ثم اسمح لـ Shell بتشغيل المجموعة مرة أخرى لرؤية رمز الخروج الجديد. اجعل الاختلاف (diff) صغيراً حتى يتمكن المراجع من قراءته في دقيقة.

نقل مجموعة إلى إطار عمل آخر

عند ترحيل اختبارات e2e بين أطر عمل، احتفظ بكلا المجموعتين في المستودع حتى تمر المجموعة الجديدة. يعدّ FlowLatch الاختبارات القديمة باستخدام glob، ويقرأ كل منها بـ read_file ويكتب الملف الجديد المطابق بـ write_file، تدفقاً واحداً في كل مرة. web_search و http_get يمكنهما قراءة توثيق إطار العمل الجديد الخاص بالتركيب الذي لا تتذكره. شغل كلتا المجموعتين بـ Shell، قارن رموز الخروج، وافق على كل ملف في Ask first قبل إزالة القديم. تبقى الخطط سارية بعد إعادة التشغيل، لذا يمكن أن تستمر عملية الترحيل الطويلة في اليوم التالي.