المكاسب:
- القدرة على إنتاج اختبارات الوحدة والتكامل وواجهة المستخدم باستخدام الذكاء الاصطناعي وفقًا لهرم الاختبار وحدود التغطية وحالات الخطأ بالإضافة إلى السيناريوهات السعيدة
- القدرة على التخلص من الاختبارات الفارغة/عديمة الفائدة والتغطية المتضخمة عن طريق التحقق من أن كل اختبار يتم إنشاؤه يتحقق بالفعل من صحة السلوك
- التأكد من أن الاختبار يلتقط الخطأ ويمنعه من إصلاح الخطأ عن طريق إخبار الذكاء الاصطناعي بما يجب أن يفعله الكود
كتابة التعليمات البرمجية هي نصف المهمة؛ إثبات أن الكود يعمل بشكل صحيح هو النصف الآخر. تواجه تطبيقات الهاتف المحمول المئات من الأجهزة المختلفة وأحجام الشاشة وإصدارات نظام التشغيل وسلوكيات المستخدم. من المستحيل اختبار كل هذه الأمور يدويًا؛ ولهذا السبب يعد الاختبار الآلي (رمز اختبار التعليمات البرمجية — الاختبار الذي يتم تشغيله دون نقرة بشرية) هو العمود الفقري لجودة الهاتف المحمول. يتميز الذكاء الاصطناعي بالكفاءة بشكل لا يصدق في كتابة الاختبارات لأن كتابة الاختبارات هي بالضبط نوع العمل النمطي الذي تفضله: التحقق من سلوك معين لمدخلات محددة. في هذه الوحدة، سوف نتعلم كيفية تسريع اختبار الوحدة واختبار الواجهة والأتمتة باستخدام الذكاء الاصطناعي، مع ضمان جودة الاختبار من خلال عيون الإنسان.
هرم الاختبار: ما الذي يجب اختباره وكم
استراتيجية الاختبار الصحي تشبه الهرم. تتضمن القاعدة عددًا كبيرًا من اختبارات الوحدات (اختبار سريع يختبر وظيفة أو فئة واحدة بشكل منفصل)؛ فهي سريعة ورخيصة. يوجد في المنتصف اختبار تكامل أقل (اختبار كيفية عمل الأجزاء المتعددة معًا). يوجد في الجزء العلوي حد أدنى من اختبار واجهة المستخدم/النهاية إلى النهاية (يتم الاختبار عن طريق النقر على الشاشة كما يفعل المستخدم)؛ فهي واقعية ولكنها بطيئة وهشة. يساعد الذكاء الاصطناعي في كل طبقة، ولكن القيمة الأكبر تكمن في القاعدة: إنتاج اختبارات الوحدة لمنطق الأعمال بسرعة.
نوع الاختبار
النطاق
السرعة
كفاءة الذكاء الاصطناعي
اختبار الوحدة
وظيفة/فئة واحدة
سريع جدًا
عالية جدا
التكامل
البينية
متوسطة
عالية
واجهة المستخدم / من النهاية إلى النهاية
كل تيار الشاشة
بطيء
متوسطة (هشة)
نصيحة: عند مطالبة الذكاء الاصطناعي "بإنشاء اختبارات لهذه الوظيفة"، اطلب صراحةً حالات الحافة: إدخال فارغ، رقم فارغ، رقم سالب، قيمة كبيرة جدًا، خطأ في الشبكة. الذكاء الاصطناعي ينتج مسارًا سعيدًا بسهولة؛ الأخطاء الحقيقية تختبئ في الحدود وتقفز للخارج إذا كنت لا تريدها هناك.
خطوات كتابة الاختبارات بالذكاء الاصطناعي
- تحديد السلوك المراد اختباره. "يجب أن تعطي هذه الوظيفة هذا الإخراج لهذا الإدخال."
- تحديد الإطار. JUnit + MockK على Android، أو XCTest على iOS، أو Espresso (Android) أو XCUITest (iOS) لواجهة المستخدم.
- اسأل عن حالات الحد. سيناريو سعيد + خطأ + نقاط توقف.
- إدارة الكائنات الوهمية. تتم محاكاة التبعيات الخارجية مثل الشبكة وقاعدة البيانات للاختبار (محاكاة وهمية - يتم التحكم فيها بدلاً من الخدمة الفعلية).
- قم بإجراء الاختبار والتحقق. هل ينجح الاختبار، وهل يؤكد أي شيء ذي معنى حقيقي؟
الخطوة الخامسة حاسمة. يُنتج الذكاء الاصطناعي في بعض الأحيان اختبارات عديمة الفائدة "تنجح دائمًا"؛ على سبيل المثال، اختبار لا يتحقق من أي شيء أو يتحقق من البيانات المزورة الخاصة به. اختبار النجاح والاختبار القيم هما شيئان مختلفان.
تحذير: مجرد قدرة الذكاء الاصطناعي على الإنتاج لا يعني أن الاختبار صحيح. في بعض الأحيان يقبل الذكاء الاصطناعي السلوك الحالي (وربما الخاطئ) للكود على أنه "صحيح" ويكتب الاختبارات وفقًا لذلك. يعمل هذا الاختبار على إصلاح الخلل بدلاً من اكتشافه. أنت تحدد ما يتوقعه الاختبار؛ أخبر الذكاء الاصطناعي بما يجب أن يفعله، وليس ما يفعله الكود.
قياس تغطية الاختبار والمغالطة
تعد تغطية الاختبار (ما هي النسبة المئوية للتعليمات البرمجية التي يتم تشغيلها بواسطة الاختبارات) مقياسًا مفيدًا ولكنه مضلل. تشير التغطية بنسبة 90% إلى أنه تم تنفيذ 90% من التعليمات البرمجية؛ ولكن لم يتم التحقق من أن تلك الخطوط تعمل بشكل صحيح. يؤدي الاختبار الذي يقوم بتشغيل خط ولا يتحقق من النتيجة إلى تضخيم النطاق ولكنه لا يوفر الأمان. الهدف ليس أرقاما عالية، ولكن التحقق من صحة ذات مغزى. يمكنك الارتقاء بسرعة باستخدام الذكاء الاصطناعي، ولكن تأكد من أن كل اختبار يختبر سلوكًا ما بالفعل.
ثلاث حالات صغيرة
الحالة 1 - تم القبض على الوضع الحدودي. طُلب من الذكاء الاصطناعي إجراء اختبارات لوظيفة تحويل الأموال في أحد التطبيقات المصرفية، وتمت إضافة سيناريوهات "المبلغ السلبي" و"أكثر من الرصيد" على وجه التحديد. وكشف الاختبار أن التحويل لم يتم حظره بمبلغ سلبي؛ سيكون هذا ثغرة أمنية كبيرة في الإنتاج. تم إغلاقه عن طريق إضافة عنصر تحكم سطر واحد. الدرس المستفاد: اختبارات الحدود هي الاختبارات الأكثر قيمة.
الحالة 2 - اختبار مزيف. شعر أحد الفرق بالارتياح لزيادة التغطية إلى 85% من خلال 40 وحدة اختبارية تم إنتاجها بواسطة الذكاء الاصطناعي. أثناء الفحص، لوحظ أن معظم الاختبارات لم تتحقق فعليًا من أي مخرجات، بل قاموا فقط باستدعاء الوظيفة وكتبوا تأكيد True (صحيح). كانت التغطية عالية لكن الحماية كانت معدومة. تم إصلاح الاختبارات وإعادة كتابتها باستخدام عمليات التحقق الحقيقية. الدرس المستفاد: أرقام التغطية يمكن أن تكذب.
الحالة 3 - تسريع اختبار واجهة المستخدم. كتب فريق التجارة الإلكترونية برنامج XCUITest النصي لتدفق الإضافة إلى سلة التسوق باستخدام الذكاء الاصطناعي في 20 دقيقة؛ ولو كانت مكتوبة بخط اليد لاستغرقت نصف يوم. معرفات عناصر الشاشة التي تم تخمينها بواسطة الذكاء الاصطناعي؛ قام الفريق بمطابقتها بالرمز الحقيقي وإصلاحها. سرعة المسودة حقيقية، لكن التحقق من المعرف هو عمل بشري.
موجه ضعيف / موجه قوي
المطالبة الضعيفة: "اكتب اختبارًا لهذه الوظيفة."
موجه قوي: "قم بإنتاج اختبارات الوحدة لوظيفة Kotlin هذه باستخدام JUnit5 + MockK. الوظيفة: تحويل الأموال (المبلغ، المصدر، الهدف). السلوكيات التي يجب اختبارها (ما يجب أن يفعله الكود): - يجب أن يكون التحويل الصالح ناجحًا - يجب رفض المبلغ السلبي أو الصفري - يجب رفض المبلغ الأكبر من الرصيد - يجب أن يطرح خطأ الشبكة استثناءً مناسبًا. يجب أن يتحقق كل اختبار من شيء واحد فقط، ويجب أن تكون أسماؤهم وصفية، وتسخر من الخدمة الخارجية. لا تكتب تأكيدًا فارغًا."
قوالب قابلة للنسخ
قالب اختبار الوحدة: "إنشاء اختبارات وحدة [JUnit/XCTest] لهذه الوظيفة لـ [اللغة]. السلوك المتوقع: [ما يجب القيام به]. يتضمن: سيناريو سعيد، إدخال فارغ، نقاط التوقف، حالة الخطأ. دع كل اختبار يتحقق من سلوك واحد؛ استخدم توكيدًا ذا معنى؛ وهمية. [رمز]"
قالب اختبار واجهة المستخدم: "اكتب اختبار واجهة المستخدم للتدفق التالي باستخدام [Espresso/XCUITest]: [تدفق المستخدم خطوة بخطوة]. حدد عناصر الشاشة بمعرف إمكانية الوصول، واستخدم المعرف بدلاً من النص. أضف إستراتيجية الانتظار. ذكرني بمطابقة معرفات العناصر مع الكود الفعلي."
قالب تدقيق الاختبار:"افحص هذه الاختبارات: 1) هل تقوم بالفعل بالتحقق من المخرجات/السلوك أم أنها فارغة؟ 2) هل تغطي الحالات المحدودة؟ 3) هل تقوم بإصلاح الأخطاء في الكود أو تتوقع السلوك الصحيح؟ قم بوضع علامة على الاختبارات الضعيفة وتعزيزها. [الاختبارات]"
قالب تحسين التغطية: "حدد الأجزاء غير المختبرة من هذه الفئة واقترح اختبارات ذات معنى. حدد أولويات المسارات ذات المخاطر الحقيقية، وليس فقط عدد التغطيات. [الكود]"
الأخطاء الشائعة
- مجرد اختبار السيناريو السعيد. يتم تخزين الأخطاء في حالات الحد؛ اطلب منهم علنا.
- قبول اختبار فارغ/عديم الفائدة. تعمل اختبارات النوع AssurTrue(true) على تضخيم النطاق ولا توفر أي حماية.
- جعل الذكاء الاصطناعي يتحقق مما يفعله الكود. يجب أن يتوقع الاختبار ما يجب أن تفعله التعليمات البرمجية؛ وإلا فإنه يصلح الخلل.
- خطأ في رقم النطاق لهذا الغرض. تغطية 90% لا تعني دقة 90%.
- ربط النص في اختبار واجهة المستخدم. يتم كسر الاختبار عندما يتغير النص؛ استخدم معرفًا ثابتًا (id).
- إعداد المحاكاة بشكل غير صحيح. سيكون "اختبار الوحدة" الذي يستدعي الخدمة الفعلية بطيئًا وهشًا.
في ملخص
يعد الاختبار هو العمود الفقري لجودة الهاتف المحمول، والذكاء الاصطناعي فعال للغاية في هذا المجال، خاصة في اختبار الوحدة. اتبع هرم الاختبار: العديد من الوحدات، والتكامل المتوسط، واختبار واجهة المستخدم القليل. اطلب بوضوح من الذكاء الاصطناعي الحصول على السيناريو السعيد بالإضافة إلى تحديد الحالات ومسارات الخطأ. تأكد من أن كل اختبار يتم إنشاؤه يتحقق بالفعل من صحة السلوك؛ الاختبارات الفارغة والتغطية المتضخمة مضللة. والأهم من ذلك، إخبار الذكاء الاصطناعي بما يجب أن يفعله الكود، وليس ما يفعله، حتى يتمكن الاختبار من اكتشاف الخطأ، وليس إصلاحه.
مهمة التطبيق
اطلب اختبارات من الذكاء الاصطناعي باستخدام "قالب اختبار الوحدة" لوظيفة منطق الأعمال (مثل حساب الخصم أو التحقق من صحة النموذج) وحدد بوضوح حالات الحد (فارغة، سلبية، كبيرة جدًا). قم بتشغيل الاختبارات التي تم إنشاؤها، ثم قم بتدقيق نفس الاختبارات باستخدام "قالب تدقيق الاختبار". ابحث عن اختبار ضعيف واحد على الأقل، وقم بتقويته، واختبر ما إذا كانت الاختبارات قد اكتشفت خطأً فعليًا في الوظيفة (عن طريق إضافة خطأ صغير).
قائمة مرجعية
- [ ] قمت باختيار الطبقة المناسبة لهرم الاختبار (وحدة الأولوية)
- [ ] أردت حالات الحد والخطأ إلى جانب السيناريو السعيد
- [ ] لقد تحققت من أن كل اختبار يحتوي على تأكيد ذي معنى
- [ ] أخبرت الذكاء الاصطناعي بما يجب أن يفعله الكود، وليس ما يفعله
- [ ] ركزت على مسارات المخاطر الفعلية، وليس عدد التغطيات
- [ ] لقد استخدمت معرفًا ثابتًا في اختبارات واجهة المستخدم، ولم ألتزم بالنص