لماذا تنجح اختبارات الذكاء الاصطناعي رغم بقاء أخطاء في الكود

لماذا تنجح اختبارات الذكاء الاصطناعي رغم بقاء أخطاء في الكود

عالم البرمجة

مطور يراجع اختبارات ذكاء اصطناعي نجحت رغم خطأ في الكود

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

تشغل المجموعة فتظهر النتيجة خضراء بالكامل.

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

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

النجاح يعني فقط أن الحالات التي شغلت انتهت إلى النتائج التي توقعها الاختبار.

إذا كان التوقع نفسه ناقصا، أو كان مشتقا من نفس الفهم الذي أنتج الكود، فقد تنجح المجموعة 

وهي لا تزال عاجزة عن كشف الخطأ المهم.

لذلك السؤال الأقوى ليس كم اختبارا نجح، بل من أين جاءت فكرة أن هذه النتيجة هي النتيجة الصحيحة.

عندما تفصل بين تنفيذ الدالة وبين المرجع الذي يحكم عليها، يصبح الضوء الأخضر دليلا مفيدا 

بدلا من أن يتحول إلى شهادة جودة أكبر مما يستطيع إثباته.

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

جودة الاختبار لا تبدأ من عدد الحالات، بل من استقلال السؤال الذي يطرحه على التنفيذ.

نجاح الاختبار يثبت التوافق مع التوقع لا صحة النظام كله

كل اختبار آلي يحتوي بصورة أو بأخرى على مدخلات، وتنفيذ، وتوقع لما يجب أن يحدث.

إذا أعادت الدالة القيمة التي ينتظرها الاختبار يمر الاختبار.

هذه نتيجة محددة جدا، ولا تقول إن كل سلوك آخر في النظام صحيح.

تخيل دالة تحسب رسوم توصيل بناء على الوزن.

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

لكن ذلك لا يخبرك كيف تتصرف الدالة مع وزن صفري، أو قيمة غير صالحة، أو حد يتغير عند نقطة معينة،

 إلا إذا كانت هذه الحالات موجودة فعلا داخل الاختبارات.

المشكلة تصبح أعمق عندما يكون المتوقع نفسه غير مستقل.

قد يقرأ النموذج التنفيذ ثم يستنتج منه أن نتيجة معينة مقصودة، فيكتب تأكيدا يوافق السلوك الموجود.

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

وهذا يسمى في هندسة الاختبار مشكلة مرجع الاختبار.

السؤال ليس فقط هل شغلنا الكود، بل كيف نعرف ما الذي كان يجب أن ينتجه أصلا.

مصدر النتيجة المتوقعة أهم من أناقة كود الاختبار

لكي يكون الفحص قويا يحتاج إلى مرجع للتوقع لا يعتمد بالكامل على النتيجة التي يريد فحصها.

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

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

 كثير من السلوك الصحيح من أسماء الدوال والبنية والسياق.

لكنه قد لا يعرف قاعدة عمل غير ظاهرة في الكود، مثل أن نوعا محددا من الخصومات لا يجوز جمعه مع خصم آخر.

هنا لا يفشل النموذج لأنه رأى الكود.

المشكلة أن مصدر الحقيقة لم يكن موجودا في السياق.

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

أبحاث حديثة على توليد اختبارات الوحدة تؤكد أن التوثيق والسياق وطريقة التوجيه تغير جودة الاختبارات بصورة ملموسة.

كما تبين أن رؤية التنفيذ ليست عيبا في ذاتها، وأن حذف الكود بالكامل ليس قاعدة سحرية تجعل الاختبارات مستقلة أو أقوى.

رؤية التنفيذ ليست المشكلة بل الاعتماد عليه وحده

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

لكنها ليست قاعدة جيدة لكل مشروع.

رؤية التنفيذ تساعد النموذج على معرفة الواجهات والأنواع ومسارات التنفيذ والأخطاء المحتملة.

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

المشكلة تظهر عندما يصبح التنفيذ هو المصدر الوحيد لمعرفة ما هو صحيح.

الطريقة الأقوى هي إعطاء النموذج أكثر من طبقة.

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

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

بهذه الطريقة تستطيع اكتشاف نقطة خطرة مبكرا.

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

تغطية الكود تخبرك بما نفذته الاختبارات لا بما أثبتته

تغطية الكود مفيدة لأنها تكشف الأجزاء التي لم تصل إليها الاختبارات.

فإذا لم ينفذ فرع معين فلا يمكن لمجموعة الاختبارات أن تكشف خطأ موجودا حصرا داخله.

لكن تنفيذ السطر لا يعني أن الاختبار كان حساسا لنتيجته.

قد تمر الدالة عبر شرط مهم بينما لا يحتوي الاختبار على تأكيد قادر على ملاحظة أن الشرط أعاد قيمة خاطئة.

ولهذا يمكن أن تكون التغطية مرتفعة بينما تبقى قدرة المجموعة على كشف العيوب محدودة.

هذا الفرق مهم خصوصا مع الاختبارات المولدة آليا.

اقرأ ايضا : كيف تراجع كود الوكيل البرمجي دون قراءة كل سطر

النموذج يستطيع إنتاج حالات كثيرة بسرعة، وقد ترتفع التغطية نتيجة لذلك، لكن الرقم لا يخبرك 

وحده عن جودة التوقعات المكتوبة داخل تلك الحالات.

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

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

اختبر مرجع التوقع قبل أن تزيد عدد الحالات

قبل أن تطلب عشرات الاختبارات الإضافية، افتح عددا من الاختبارات الحالية واقرأ التأكيدات نفسها.

اسأل كيف عرف الاختبار أن القيمة المتوقعة صحيحة.

إذا وجدت أن المتوقع مجرد نسخة أخرى من المعادلة الموجودة في الدالة، فأنت لم تنشئ مرجعا مستقلا فعليا.

لقد كتبت المنطق مرتين، وقد يحمل الطرفان الفرضية نفسها.

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

لا تحتاج كل دالة إلى مواصفات رسمية ثقيلة.

أحيانا تكفي أمثلة قبول واضحة كتبها الفريق قبل التنفيذ.

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

وهذه الخطوة مفيدة مع المطور البشري أيضا.

المشكلة ليست خاصة بالذكاء الاصطناعي، لأن الإنسان يستطيع هو الآخر كتابة اختبار يكرر افتراضه الخاطئ.

اختبارات الخصائص توسع البحث لكنها لا تستبدل المواصفات

من الأخطاء الشائعة وصف أي اختبار يعتمد على المتطلبات بدل التنفيذ بأنه اختبار قائم على الخصائص.

الاختبار القائم على الخصائص له معنى أدق.

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

 أداة توليد بيانات للبحث عن أمثلة تكسر هذه الخاصية.

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

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

لكنها لا تحل مشكلة مرجع التوقع وحدها.

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

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

 ربط الخصائص بعقد النظام وقواعد المجال.

استخدام أداة مثل اختبارات الخصائص هو توسيع لمساحة البحث، وليس بديلا عن معرفة السلوك المطلوب.

اختبار الطفرات يقيس حساسية المجموعة للتغيير الخاطئ

هناك طريقة عملية أخرى لفحص ما إذا كانت الاختبارات تلاحظ تغير المنطق.

اختبار الطفرات يعدل الكود آليا بتغييرات صغيرة مقصودة، مثل عكس شرط أو تغيير عامل حسابي،

 ثم يشغل الاختبارات من جديد.

إذا فشلت الاختبارات بعد التغيير فهذا يعني أنها كانت حساسة لذلك النوع من الخلل.

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

لهذا لا تعني طفرة ناجية أن الاختبارات عديمة القيمة، ولا تعني نتيجة طفرات مرتفعة أن البرنامج 

خال من العيوب.

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

القيمة الحقيقية هي أن الطفرات تطرح سؤالا أقوى من مجرد هل نفذنا هذا السطر.

إنها تسأل هل ستلاحظ المجموعة لو تغير هذا المنطق بطريقة يحتمل أن تكون خاطئة.

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

الفصل بين جلسات الذكاء الاصطناعي لا يصنع استقلالا تلقائيا

قد يبدو منطقيا أن تطلب من جلسة أولى كتابة الكود ومن جلسة ثانية كتابة الاختبارات، ثم تعتبر الثانية مراجعا مستقلا.

هذا الفصل قد يقلل بعض التأثر المباشر بالتنفيذ، لكنه لا يضمن استقلال الحكم.

إذا أعطيت الجلستين المتطلب الغامض نفسه فقد تبنيان الفرضية الخاطئة نفسها.

وإذا كانت الاختبارات تعتمد على وصف ناقص فلن يحل تغيير النافذة مشكلة غياب قاعدة العمل.

الاستقلال الأقوى يأتي من فصل مرجعيات التحقق.

اكتب السلوك المطلوب قبل التنفيذ عندما تستطيع.

احتفظ بأمثلة قبول أو قواعد مجال مستقلة.

وبعد توليد الاختبارات اطلب مراجعة التوقعات مقابل هذه المرجعيات لا مقابل نجاح الدالة الحالية.

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

اطلب منه البحث عن اختلاف بين المتطلبات والتأكيدات، ثم اطلب منه اقتراح تعديل في التنفيذ

 يمر من الاختبارات رغم أنه يخالف المتطلب.

هذا يكشف ما إذا كانت المجموعة تسمح بخطأ مهم بالمرور.

استخدم فحص مصدر الحقيقة قبل أن تثق بالضوء الأخضر

يمكنك مراجعة الاختبارات المولدة عبر فحص مصدر الحقيقة.

وهو أداة عملية مبسطة وليست معيارا تقنيا رسميا.

ابدأ بالمتطلب.

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

ثم افحص المتوقع.

هل القيمة أو الحالة المنتظرة جاءت من ذلك المتطلب، أم استنتجت فقط من التنفيذ الحالي.

بعد ذلك افحص الاختلاف.

ما التعديل الخاطئ المعقول الذي يجب أن يجعل هذا الاختبار يفشل.

إذا لم تستطع تصور خطأ يستطيع الاختبار كشفه فربما يكون تأكيده ضعيفا.

ثم افحص الحساسية.

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

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

وأخيرا افحص النطاق.

اختبار الوحدة لا يستطيع إثبات سلوك يعتمد فعليا على قاعدة بيانات حقيقية أو تزامن بين خدمات

 أو عقد خارجي بمجرد محاكاة كل شيء.

احتفظ باختبارات تكامل وعقد ونظام عندما تكون المشكلة خارج حدود الوحدة.

وهذا يمنع خطأ شائعا آخر، وهو مطالبة اختبار وحدة بأن يثبت سلوكا لا يظهر إلا عند تفاعل عدة مكونات.

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

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

بعضها قد تنافس الاختبارات البشرية في مقاييس معينة عندما يتوفر السياق والتوجيه المناسبان.

لذلك ليس الهدف رفض الاختبارات المولدة، بل معرفة ماذا أثبتت فعلا.

اقرأ ايضا : لماذا يفشل كود الذكاء الاصطناعي رغم أنه يبدو صحيحا

الضوء الأخضر مفيد عندما تعرف مصدر توقعاته وحدوده.

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

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

قبل أن يتحول إلى ثقة أكبر من الدليل الذي تملكه.