تخطّ إلى المحتوى
AISI
𝕏
سير عمل / أتمتة

أتمتة اختبار البرمجيات وكتابة سيناريوهات الاختبار لـ APIs والتطبيقات الويب

وكيل برمجي ذكي يحلل الشيفرة المصدرية ويكتب اختبارات الوحدة (Unit Tests) واختبارات التكامل تلقائياً باستخدام OpenHands.

الهدف من مسار العمل

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

خطوات التشغيل التفصيلية

الخطوات

خطوة

مخطط سير العمل

رسم بياني مُولَّد تلقائيًا

flowchart RL S1["1. استقبال حدث Pull Request جديد"] S2["2. تشغيل حاوية Docker للوكيل OpenHands"] S3["3. قراءة وفحص الملفات المعدلة في..."] S4["4. توليد ملفات الاختبار البرمجية"] S5["5. دمج ملفات الاختبار في فرع..."] S1 --> S2 S2 --> S3 S3 --> S4 S4 --> S5 subgraph Tools["🔧 الأدوات المستخدمة"] T0(("OpenHands")) T1(("GitHub Actions")) T2(("Docker")) T3(("GitHub")) end style Tools fill:#fffbeb,stroke:#f59e0b,stroke-width:1px

التفاصيل البرمجية والتهيئة

مقدمة حول الأتمتة الذكية لاختبار البرمجياتتعتبر كتابة اختبارات البرمجيات (Unit Tests & Integration Tests) من المراحل الأكثر أهمية لضمان استقرار التطبيقات ومنع حدوث أخطاء غير متوقعة عند إضافة ميزات جديدة. ومع ذلك، يجد الكثير من المطورين أن هذه العملية مملة وتستهلك وقتاً ثميناً كان يمكن استغلاله في تطوير الميزات الفعلية للتطبيق. يقدم هذا الدليل التفصيلي حلاً متطوراً بالاعتماد على OpenHands، وهو وكيل الذكاء الاصطناعي البرمجي المفتوح المصدر، لأتمتة كتابة واختبار الأكواد البرمجية مباشرة داخل بيئة معزولة متكاملة مع خطوط الإنتاج والتحقق المستمر (CI/CD) على منصة GitHub. الأدوات والتقنيات الأساسيةلإعداد خط أتمتة الاختبارات، يجب توفير الأدوات التالية: OpenHands: وكيل البرمجة الذاتي الذي يدير عملية كتابة وفحص واختبار الأكواد. Docker: لتشغيل بيئة الاختبار (Sandbox) المعزولة لمنع الوكيل من إلحاق الضرر بالنظام الأصلي. GitHub Actions: لتنظيم وتشغيل التدفق البرمجي تلقائياً عند حدوث تعديلات على الكود. نماذج لغوية كبرى (مثل Claude 3.5 Sonnet أو GPT-4o): لتزويد الوكيل بالقدرات البرمجية والتحليلية المتقدمة. خطوات الإعداد والتهيئة الفنية1. تكوين مفاتيح الوصول وإعدادات الأماننولد رمز وصول شخصي (GitHub Personal Access Token) بصلاحيات تعديل المستودعات ورفع الأكواد، ونخزنه في إعدادات الأمان (Secrets) للمستودع الخاص بنا باسم GH_TOKEN.2. إعداد حاوية Docker لـ OpenHandsنتأكد من تثبيت Docker على خادم التطوير أو خادم GitHub Actions Runner. نقوم بتهيئة إعدادات تشغيل حاوية OpenHands مع تفعيل خيارات العزل والتحجيم الموارد.3. كتابة ملف سير العمل لـ GitHub Actionsn8n كحلقة ربط أساسية لنقل النصوص المعتمدة وإدارة موافقة الكاتب البشري لتجنب أي خطأ إملائي أو سياقي غير مرغوب فيه. تفاصيل تشغيل سير العملعندما يرفع المطور تعديلات برمجية جديدة ويفتح طلب سحب (Pull Request)، يكتشف نظام GitHub Actions ذلك ويطلق الحدث. يقوم خط الإنتاج بتشغيل حاوية Docker المخصصة لـ OpenHands ويمرر لها الكود المعدل. يقوم الوكيل الذكي بقراءة الكود، وتحديد الدوال الجديدة والمعدلة التي تفتقر للتغطية الاختبارية (Test Coverage). بعد ذلك، يكتب OpenHands ملفات اختبار متكاملة بلغة التطبيق (مثل Jest لـ TypeScript أو PyTest لـ Python) مع اختبار حالات الإدخال الصحيحة والاطراف (Edge cases). يقوم الوكيل بتشغيل الاختبارات داخل بيئته المعزولة للتأكد من نجاحها وعدم وجود أخطاء في الصياغة. بمجرد التحقق، يقوم الوكيل برفع التعديلات وملفات الاختبار الجديدة مباشرة إلى نفس فرع طلب السحب (PR) ليراها المطور ويعتمدها. المحاذير البرمجية وأفضل ممارسات بيئات Sandboxلتجنب المشاكل الأمنية أثناء استخدام وكلاء البرمجة التلقائية: العزل التام لبيئة العمل (Sandboxing): يجب تشغيل وكيل OpenHands دائماً داخل حاوية Docker معزولة ومقيدة الصلاحيات وبدون اتصال بالشبكة الداخلية للشركة، لمنع الوكيل من تشغيل أوامر قد تضر بالبنية التحتية في حال حدوث هلوسة أو سوء فهم للمطالبة. مراجعة الأكواد التوليدية: رغم ذكاء الوكيل، يجب على المطورين مراجعة الأكواد والاختبارات المولدة بعناية للتأكد من توافقها مع القواعد معمارية المشروع وعدم احتوائها على ثغرات منطقية. التحكم في تكاليف الـ API: تشغيل الوكيل البرمجي لمهام معقدة قد يستهلك عدداً كبيراً من التوكنز (Tokens). يفضل وضع حد أقصى للخطوات والوقت لكل تشغيل للتحكم في التكلفة المالية لاستدعاء النماذج السحابية.