الاختبار بمساعدة الذكاء الاصطناعي: استخدام بوابات اختبار الوحدة لالتقاط جذور الكود المولد بواسطة الذكاء الاصطناعي

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

الأخطاء الصغيرة هي ساحة المعركة الرئيسية للاختبار بمساعدة الذكاء الاصطناعي

تنقسم الأخطاء إلى نوعين: الأخطاء السهلة الحل، والأصعب في الحل.

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

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

• الأخطاء التي يمكن اكتشافها بسرعة
• الأخطاء البسيطة التي تتطلب تعديلات طفيفة فقط لإصلاحها
• الأخطاء الجديدة التي يتم إدخالها أثناء التعديل
• الأخطاء التي تحدث بسبب العجلة أثناء التعديلات العاجلة
• الموازنة بين تكلفة وكفاءة الاختبار المستهدف

معظم الأخطاء هي أخطاء صغيرة، لكن الأخطاء الصغيرة قد تسبب مشاكل خطيرة. حل الأخطاء الصغيرة محليًا يمكن أن يوفر الكثير من الجهد لاحقًا.

نقل موضوع المراجعة من الكود إلى مستندات حالات الاختبار

لقد جربت فكرة جريئة مرة: السماح للذكاء الاصطناعي بإكمال متطلب بالكامل دون مراجعة الكود الذي يولده، مثل وضعية وكيل Copilot تمامًا. لاحقًا تخليت عنها. السبب الجذري هو عدم الاطمئنان. بالنسبة لبرنامج ثنائي منطقي صارم، عدم الاطمئنان يعني فقدان الثقة في التدفق العلوي والسفلي، وفقدان ثقة العملاء. لذلك أنا أتعلم التفكير في vibe coding: بالنسبة للكود المولد بواسطة الذكاء الاصطناعي، يجب أن أكون مطمئنًا تمامًا.

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

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

---
title: من مراجعة الكود إلى مراجعة المستندات
---
flowchart TB
    A[توليد الذكاء الاصطناعي لكمية كبيرة من الكود] e1@--> B[تكلفة مراجعة سطر بسطر مرتفعة]
    B e2@--> C{ما الذي تتم مراجعته}
    C e3@-->|الكود| D[ساعتين للمراجعة، عدم الاطمئنان]
    C e4@-->|مستندات حالات الاختبار| E[سهل المراجعة، التحقق السريع]
    E e5@--> F[بوابة اختبار الوحدة]
    F e6@--> G[حالات الاختبار الفاشلة تكشف المشاكل]

    classDef risk fill:#FFF3E0,stroke:#E65100,color:#E65100;
    classDef ok fill:#E8F5E9,stroke:#2E7D32,color:#1B5E20;
    classDef animate stroke:#EF6C00,stroke-width:2px,stroke-dasharray: 9\,5,stroke-dashoffset: 900,animation: dash 25s linear infinite;
    class D risk;
    class E,F,G ok;
    class e1,e2,e3,e4,e5,e6 animate;

الأساس المنهجي: سيغما ستة و DMAIC

سيغما ستة هي منهجية تحسين الجودة تعتمد على البيانات، الهدف الأساسي منها هو تقليل التباين في العملية، والسيطرة على معدل العيوب عند 3.4 لكل مليون، أي مستوى 6σ¹.

تقدم مجموعة قابلة للتنفيذ من العمليات DMAIC:

• تحديد: تحليل المتطلبات، تحويلها إلى نماذج بيانات، تصميم هياكل البيانات والواجهات
• القياس: مراقبة حالات الاختبار، التغطية، الأداء، الأمان
• التحليل: تحليل حالات الاختبار وكود العمل
• التحسين: تحسين حالات الاختبار وكود العمل
• السيطرة: بوابة اختبار تلقائية

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

يمكن للمنهجية والأدوات المساعدة في اكتشاف المشاكل وحلها، الثمن هو احتمال زيادة تكلفة التسليم وتقليل الكفاءة إلى حد ما. في ظل الموارد المحددة، يجب اختيار طريقة يمكن أن تستمر في الاستفادة منها على المدى القصير والمتوسط والطويل. خياري هو استخدام اختبار الوحدة كأداة مساعدة في عملية التطوير.

باستخدام الذكاء الاصطناعي في التحويل بين لغات الأدوار المختلفة، يمكن للتطوير دمج مزايا TDD و BDD و ATDD، وإنشاء جداول حالات الاختبار وكود الحالات بسرعة، وتحسين جودة التسليم.

التطوير الموجه بالاختبار: TDD/BDD/ATDD والكود القابل للاختبار

الاختلافات بين أنواع التطوير الموجه بالاختبار الثلاثة هي كما يلي:

هناك أربعة مبادئ أساسية للكود القابل للاختبار: مسؤولية واحدة (كل دالة تفعل شيء واحد)، حقن التبعية (نقل التبعيات عبر المعلمات)، عزل الواجهة (أنواع الإدخال والإخراج واضحة)، حالة قابلة للمراقبة (توفير واجهات استعلام للتحقق من الحالة الداخلية).

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

مثال على الكود المناسب للاختبار:

// user.h
typedef struct {
    int id;
    char name[50];
    int age;
} User;

// واجهة تخزين الذاكرة المجردة
typedef struct {
    User* (*get_user)(int id);
    int (*save_user)(const User* user);
} UserStorage;

// إنشاء مستخدم (حقن واجهة التخزين)
User* create_user(const char* name, int age, UserStorage* storage) {
    if(strlen(name) >= 50 || age <= 0) return NULL;

    User* new_user = malloc(sizeof(User));
    new_user->id = generate_user_id();
    strncpy(new_user->name, name, 49);
    new_user->name[49] = '\0';
    new_user->age = age;

    if(storage->save_user(new_user) != 0) {
        free(new_user);
        return NULL;
    }
    return new_user;
}

مثال على الكود غير المناسب للاختبار:

// عملية قاعدة بيانات مرتبطة بإحكام
void save_user_to_db(User* user) {
    MYSQL conn;
    mysql_init(&conn);
    if(!mysql_real_connect(&conn, "localhost", "root", "pass", "test", 0, NULL, 0)) {
        log_error("DB connection failed"); // تبعية سجل صعبة الاختبار
        exit(1); // الخروج المباشر يؤثر على تنفيذ الاختبار
    }
    // تجميع SQL وكتابة إلى قاعدة البيانات
}

الكود الجيد يؤثر بصمت، والكود السيئ له حضور قوي. الدالة المناسبة للاختبار لها قيمة إرجاع واضحة، ومعالجة أخطاء منظمة، ومعلمات إدخال واضحة، وعزل الآثار الجانبية، ودعم حقن التبعية.

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

المصاعب والموازنات في التطوير الفعلي

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

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

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

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

سير عمل قابل للتطبيق للاختبار بمساعدة الذكاء الاصطناعي

من خلال دمج مستندات التصميم، يمكن ربط خط أنابيب من السيناريو إلى حالة الاختبار:

---
title: سير عمل الاختبار بمساعدة الذكاء الاصطناعي
---
flowchart TB
    A[مستند التصميم] e1@--> B[توليد سيناريوهات اختبار القبول]
    B e2@--> C[توليد هياكل البيانات والواجهات]
    C e3@--> D[توليد جدول حالات الاختبار من جانب العميل]
    D e4@--> E[توليد كود حالات الاختبار]
    D e5@--> F[توليد كود العمل]
    E e6@--> G[البوابة المحلية: حالات الاختبار ناجحة]
    F e7@--> G
    G e8@--> H{هل توجد حالات اختبار فاشلة}
    H e9@-->|نعم| E
    H e10@-->|لا| I[إرسال للاختبار]

    classDef input fill:#E3F2FD,stroke:#1565C0,color:#0D47A1;
    classDef gen fill:#E8F5E9,stroke:#2E7D32,color:#1B5E20;
    classDef gate fill:#FFF3E0,stroke:#E65100,color:#E65100;
    classDef animate stroke:#EF6C00,stroke-width:2px,stroke-dasharray: 9\,5,stroke-dashoffset: 900,animation: dash 25s linear infinite;
    class A input;
    class B,C,D,E,F gen;
    class G,H,I gate;
    class e1,e2,e3,e4,e5,e6,e7,e8,e9,e10 animate;

يمكن تنظيم مطالبات كل خطوة على النحو التالي: توليد سيناريوهات اختبار القبول بناءً على مستند تصميم المنتج؛ توليد هياكل البيانات والواجهات بناءً على سيناريوهات الاختبار؛ توليد جدول حالات الاختبار من جانب العميل بناءً على سيناريوهات الاختبار والواجهات؛ توليد كود حالات الاختبار بناءً على الواجهات وجدول حالات الاختبار؛ توليد كود العمل بناءً على سيناريوهات الاختبار والتأكد من نجاح حالات الاختبار.

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

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

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

الملخص

هذا سير العمل مقارنة بعدم استخدام الذكاء الاصطناعي سيولد المزيد من المستندات وكود الاختبار، يصعب مراجعة كل كلمة. لكن المستندات أسهل في المراجعة من الكود، خاصة جدول حالات الاختبار، له دور توجيهي دقيق في توليد حالات الاختبار. في التطوير الفعلي، أحيانًا أراجع فقط حالات الاختبار الفاشلة، من خلال تصحيح حالات الاختبار الفاشلة لتأكيد المشكلة.

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

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

• ←السابق
• التالي→