المكاسب:
- القدرة على إنتاج كود اختبار قوي لواجهة المستخدم باستخدام الذكاء الاصطناعي، بما في ذلك اختبار البيانات والانتظار المفتوح والتأكيد على التحقق من نتيجة المستخدم الحقيقية
- القدرة على تجنب الاختبارات الهشة (محدد سيئ، الانتظار الأعمى) وجعل الاختبارات سهلة الصيانة في بنية نموذج كائن الصفحة
- القدرة على اختبار كل اختبار لواجهة المستخدم يتم إنتاجه عن طريق كسر الكود وكشف وإصلاح الاختبارات التي تم اجتيازها
كل نقرة، كل ملء نموذج، كل انتقال للصفحة يقوم به المستخدم في المتصفح لا يمكن اختباره مرارًا وتكرارًا يدويًا - ولهذا السبب توجد أتمتة اختبار واجهة المستخدم (واجهة المستخدم؛ تحاكي هذه الاختبارات سلوك المستخدم من خلال تشغيل متصفح حقيقي برمجيًا). السيلينيوم والكاتب المسرحي والسرو هي الأدوات الأكثر شيوعًا لهذه المهمة. يتمتع الذكاء الاصطناعي (AI) بمهارة عالية في كتابة التعليمات البرمجية لهذه الأدوات: عندما تصف حالة اختبار، يمنحك الذكاء الاصطناعي مسودة لبرنامج نصي آلي قابل للتطبيق. ولكن هنا يأتي دور التحذير المركزي لهذه الوحدة مرة أخرى: غالبًا ما يكون كود اختبار واجهة المستخدم الذي ينتجه الذكاء الاصطناعي عبارة عن اختبارات هشة "تضيء باللون الأخضر ولكنها تتحقق من الشيء الخطأ" أو ترفرف في مهب الريح. مهمتك ليست تشغيل هذا الرمز، ولكن التأكد من أنه يتحقق بشكل قوي من الشيء الصحيح.
في هذه الوحدة، نهدف إلى إنتاج اختبارات واجهة مستخدم قوية وقابلة للصيانة ويمكن التحقق من صحتها باستخدام الذكاء الاصطناعي؛ سوف تتعلم كيفية تجنب الاختبارات الهشة.
الركائز الثلاث لاختبار واجهة المستخدم الصلبة
1. تحديد موقع العنصر الصحيح. يستخدم الاختبار محددًا للعثور على العنصر الموجود في الصفحة. غالبًا ما ينتج الذكاء الاصطناعي محددات هشة: مسارات XPath طويلة (يعتمد العنوان بشكل مفرط على بنية الصفحة)، ومحددات تعتمد على أسماء فئات CSS (تتوقف عند تغيير التصميم). الطريقة القوية هي السمات الثابتة مثل data-testid التي أضافها المطور للاختبار. فرض هذا صراحة على الذكاء الاصطناعي.
2. الانتظار الصريح. المصدر الأول للضعف في اختبار واجهة المستخدم هو التوقيت. النوم المستمر(3) (الانتظار الأعمى) ممارسة سيئة: في بعض الأحيان لا يكون كافيًا، وأحيانًا يضيع الوقت. الطريقة الصحيحة هي استخدام الانتظار الصريح، والذي يقول "انتظر حتى يظهر هذا العنصر". يقوم الكاتب المسرحي بهذا بشكل تلقائي إلى حد كبير؛ في السيلينيوم يجب عليك أن تطلب ذلك صراحة.
3. التأكيد الهادف. يجب أن يتحقق الاختبار من النتيجة التي سيراها المستخدم بالفعل - مثل "ظهر رقم الطلب على الشاشة"، وليس فقط "تم تحميل الصفحة". إذا كان الاختبار الذي ينتجه الذكاء الاصطناعي لا يحتوي على تأكيد أو كان غير مهم، فإن هذا الاختبار ينتج تمريرة زائفة (الوحدة الأولى).
تحذير: عندما ترى لأول مرة اختبار واجهة المستخدم الذي تم إنشاؤه بواسطة الذكاء الاصطناعي، تحقق من ثلاثة أشياء على الأكثر: هل المحددات ملتزمة (اختبار البيانات)، قيد الانتظار (لا يوجد نوم أعمى)، وهل يتحقق التأكيد من نتيجة المستخدم الفعلية؟ إذا كان هؤلاء الثلاثة على ما يرام، فمن المحتمل أن يكون الاختبار قويًا.
نموذج كائن الصفحة
مع نمو الاختبارات بشكل أكبر، تصبح كتابة المحددات داخل كل اختبار كابوسًا للصيانة. نموذج كائن الصفحة (POM - نمط التصميم الذي يجمع المحددات والإجراءات لكل صفحة/شاشة في فئة واحدة) يبقي المحدد في مكان واحد؛ عندما تتغير الواجهة، يمكنك تحديثها في ملف واحد. اطلب من الذكاء الاصطناعي إجراء الاختبارات في بنية POM، وليس بشكل مباشر؛ وهذا يجعل الصيانة أسهل بشكل جذري.
موجه ضعيف / موجه قوي
ضعيف: "اكتب اختبار السيلينيوم لصفحة تسجيل الدخول."
Strong: "اكتب اختبار تدفق تسجيل الدخول باستخدام Playwright (TypeScript). تستخدم المحددات فقط data-testid؛ ولا تستخدم التحكم في ما يراه المستخدم، وليس عنوان الصفحة."
موجه قوي؛ توفر الأداة اللغة وسياسة التحديد واستراتيجية الانتظار والهندسة المعمارية (POM) وتوقعات التأكيد التعبيرية.
اختبار البيانات واستقلال البيئة
لا تتم كتابة اختبار واجهة المستخدم الصلبة بشكل صحيح فحسب، بل يقوم أيضًا بإنشاء بيانات الاختبار الخاصة به وتنظيفها. غالبًا ما ترتبط الاختبارات التي ينشئها الذكاء الاصطناعي بمستخدم أو بسجل يُفترض أنه موجود بالفعل في البيئة ("تسجيل الدخول كمستخدم مسؤول"). ينكسر هذا الافتراض عند تشغيل الاختبار في بيئة أخرى أو بعد اختبار آخر (مشكلة تبعية الطلب في الوحدة 9). الحقيقة هي أن كل اختبار يقوم بإنشاء البيانات التي يحتاجها في بداية الاختبار (أو يعدها باستدعاء واجهة برمجة التطبيقات) وينظفها في النهاية. قم بتوجيه الذكاء الاصطناعي بشكل صريح إلى "إعداد أي بيانات يعتمد عليها هذا الاختبار داخل الاختبار؛ ولا تفترض بيانات جاهزة من الخارج."
النقطة المهمة الأخرى هي عدم إجراء اختبار واجهة المستخدم باستخدام بيانات المستخدم الحقيقية. إذا تم استخدام نسخة من قاعدة بيانات الإنتاج في بيئة الاختبار، فإن هذه السجلات هي بيانات لأشخاص حقيقيين؛ قد تكشف لقطات الشاشة وتسجيلات الاختبار عن هذه البيانات. استخدام حسابات اختبارية اصطناعية (خيالية)؛ فهو يحمي السرية ويجعل الاختبارات قابلة للتكرار. يعد إجراء اختبار "إلغاء الطلب" باستخدام حساب عميل حقيقي خطأً أخلاقيًا وتشغيليًا.
نصيحة: اجعل اختبارات واجهة المستخدم قليلة قدر الإمكان؛ اترك التحقق الفعلي لواجهة برمجة التطبيقات (API) واختبارات الوحدة، والتي تتميز بالسرعة والثبات. يعد اختبار واجهة المستخدم مكلفًا وهشًا - استخدمه فقط للتحقق من صحة تدفق المستخدم من طرف إلى طرف (منطق هرم الاختبار).
مقارنة المركبات
ميزة
السيلينيوم
الكاتب المسرحي
السرو
اللغات
جافا، سي #، بايثون، JS
شبيبة/TS، بايثون، .NET، جافا
جافا سكريبت / تايب سكريبت
الاستعداد التلقائي
لا (باليد)
نعم (قوي)
نعم
متصفح متعدد
واسعة
الكروم / فايرفوكس / WebKit
الكروم المهيمنة
الميل إلى الهشاشة
عالي (وضع الاستعداد اليدوي)
منخفض
منخفض
سهولة التعلم
متوسطة
سهل
سهل
عملية موازية
الشبكة مطلوبة
مدمج
مقيم/مدفوع
عند طلب رمز من الذكاء الاصطناعي، اذكر بوضوح المركبة التي ينتمي إليها؛ وإلا، فقد ينتج عنه تعليمات برمجية مربكة وغير صالحة للعمل.
أربعة قوالب قابلة للنسخ
1) إنشاء اختبار واجهة المستخدم الصلبة:
دورك: كبير مهندسي أتمتة الاختبار. اكتب الاختبارات باستخدام [الأداة + اللغة] للتدفق التالي: [التدفق]. القواعد: - اختبار بيانات المحددات فقط؛ باستخدام فئة XPath/CSS. - لا نوم أعمى. استخدم الانتظار الصريح/التلقائي. - تطبيق نموذج كائن الصفحة. - دع كل تأكيد يتحقق من نتيجة المستخدم الفعلية. قم بالتعليق في بداية كل اختبار على معايير القبول التي تقوم بالتحقق من صحتها.
2) مكافحة الهشاشة:
افحص اختبار واجهة المستخدم التالي للتأكد من هشاشة: - هل هناك محدد غير مستقر (طويل
3) التحويل إلى كائن الصفحة:
قم بتحويل كود الاختبار العادي التالي إلى بنية نموذج كائن الصفحة. نقل المحددات والإجراءات إلى فئات الصفحة؛ دع ملف الاختبار يقرأ تدفق السيناريو فقط. [الأداة/اللغة].الرمز: [لصق الكود]
4) إثبات الانتقال الزائف:
أثبت أن اختبار واجهة المستخدم هذا يتحقق فعليًا: ما التغيير الفردي الذي أقوم به على رمز التطبيق الذي سيحول هذا الاختبار إلى اللون الأحمر؟ إذا لم تتمكن من العثور على تغيير من شأنه كسر الاختبار، فإن الاختبار غير كاف؛ إضافة التأكيدات المفقودة. الاختبار: [اختبار اللصق]
ثلاث حالات صغيرة
الحالة 1 - التحرر من المحدد الهش. من بين 40 اختبارًا أنتجها أحد الفرق باستخدام الذكاء الاصطناعي، تعطل 70% منها بعد تحديث الواجهة؛ لم يكن أي منها عبارة عن أخطاء فعلية، بل كانت جميعها أدوات تحديد XPath هشة. قام الفريق بتحويل الاختبارات إلى قاعدة بيانات اختبارية باستخدام قالب "فحص الهشاشة". خلال التحديثات الثلاثة التالية للواجهة، انخفض عدد الفواصل الخاطئة إلى الصفر؛ انخفض وقت الصيانة من 6 ساعات إلى 30 دقيقة في الأسبوع.
الحالة 2 - اختبار واجهة المستخدم الزائفة. وأنتج الذكاء الاصطناعي اختبار "الإضافة إلى سلة التسوق"؛ كان الاختبار أخضر عندما تم تشغيل قالب "إثبات المرور المزيف"، بدا أن الاختبار يتحقق فقط من النقر على الزر وعنوان الصفحة، ولم يتحقق مطلقًا مما إذا كان عداد سلة التسوق قد زاد أم لا. حتى لو تم كسر منطق العربة بالكامل، فقد نجح الاختبار. تمت إضافة التأكيد الحقيقي (شارة سلة التسوق هي "1").
الحالة 3 - فخ الانتظار الأعمى. في اختبار السيلينيوم الذي أنتجه الذكاء الاصطناعي، كان هناك نوم (2) بعد كل خطوة؛ استغرق 60 اختبارًا 14 دقيقة وما زال ينكسر من حين لآخر. بعد التبديل إلى الانتظار المفتوح (انتظر حتى يصبح العنصر قابلاً للنقر عليه)، انخفض الوقت إلى 5 دقائق واختفت الهشاشة. كان الانتظار الأعمى بطيئًا وغير موثوق به.
الأخطاء الشائعة
- الموافقة على المحددات الهشة. استخدام مسارات XPaths الطويلة التي تم إنشاؤها بواسطة الذكاء الاصطناعي كما هي؛ تتعطل الاختبارات عند تغيير الواجهة الأول.
- ترك "النوم" الأعمى. "حل" التوقيت بانتظار ثابت؛ كلاهما بطيء وغير حاسم.
- تأكيد تافهة. فقط تأكد من تحميل الصفحة؛ عدم التحقق من نتيجة المستخدم الفعلية (تمرير مزيف).
- تنمو بدون بوم. توزيع المحددات على كل اختبار؛ تحديث عشرات الملفات يدويًا عند تغيير الواجهة.
- عدم تحديد الأداة. عدم إخبار الذكاء الاصطناعي بالأداة/اللغة التي تريدها؛ الحصول على رمز فوضوي وغير عامل.
- الثقة عند تشغيل التعليمات البرمجية التي تم إنشاؤها وتمريرها. عدم الاختبار عن طريق كسر الكود.
في ملخص
تتحقق أتمتة اختبار واجهة المستخدم من سلوك المستخدم من خلال تشغيل المتصفح الفعلي مع البرنامج. ينشئ الذكاء الاصطناعي هذا الرمز بسرعة، ولكن هناك مخطئان كبيران: الاختبارات الهشة (محدد سيء، انتظار أعمى) واختبارات النجاح الزائفة (تأكيد غير مكتمل/تافه). الركائز الثلاث لاختبار واجهة المستخدم الصلبة هي محدد الالتزام (اختبار البيانات)، والانتظار الصريح، والتأكيد الذي يتحقق من نتيجة المستخدم الفعلية. يؤدي إنشاء الاختبارات في نموذج كائن الصفحة إلى تبسيط عملية الصيانة بشكل جذري. اختبر كل اختبار تم إنشاؤه بالسؤال "ما التغيير الذي سيكسر هذا؟"
مهمة التطبيق
حدد تدفق المستخدم من مشروعك الخاص (مثل تسجيل الدخول أو البحث). اطلب من الذكاء الاصطناعي كتابة الاختبارات باستخدام قالب "إنشاء اختبار واجهة المستخدم القوي". بعد ذلك: (1) التحقق من المحددات وإصلاحها والانتظار من خلال "فحص الهشاشة"، (2) إثبات أن كل اختبار يتم التحقق منه بالفعل باستخدام "دليل النجاح الزائف"، (3) كسر الكود ولاحظ أن الاختبار يتحول إلى اللون الأحمر. قم بالإبلاغ عن عدد الاختبارات التي تم إنتاجها وتصحيحها، وعدد نقاط الضعف والتصاريح الزائفة التي وجدتها.
قائمة مرجعية
- [ ] لقد أعطيت الذكاء الاصطناعي الأداة واللغة وسياسة التحديد والهندسة المعمارية (POM) بشكل واضح.
- [ ] لقد تحققت من أن المحددات تم اختبارها للبيانات.
- [ ] لقد تأكدت من استخدام الانتظار الصريح/التلقائي بدلاً من النوم الأعمى.
- [ ] لقد تأكدت من أن كل تأكيد يتحقق من نتيجة المستخدم الفعلية.
- [ ] لقد اختبرت كل اختبار عن طريق كسر الكود؛ رأيته يتحول إلى اللون الأحمر.
- [ ] قمت بجمع الاختبارات في بنية نموذج كائن الصفحة.