فتح مجلد المشروع
ابدأ FlowLatch، واختر المجلد الذي يحتوي على اختباراتك كمجلد عمل، واختر Ask first (اسأل أولاً) حتى ينتظر كل إجراء يغير شيئًا موافقتك. قم بتوصيل نموذج إذا لم تكن قد فعلت ذلك بعد، واستخدم زر الاختبار للتحقق من نقطة النهاية.
سير العمل
اختبار الويب الآلي: افتح، شغّل، اقرأ وأصلح تدفق العمل
03
فحص تدفق إتمام الشراء على تطبيقك التجريبي
لديك نسخة تجريبية من متجرك، وحساب اختبار، ومجلد اختبارات، وتريد معرفة ما إذا كانت تسجيل الدخول، والإضافة إلى السلة، وإتمام الشراء لا تزال تعمل بعد التغيير الذي أُجري اليوم. هذا هو اختبار الويب الآلي بأبسط صوره: تدفق واحد، أمر اختبار واحد، ونتيجة يمكنك قراءتها. يفتح FlowLatch المجلد، ويشغل الأمر عبر Shell ويعرض رمز الخروج الحقيقي على بطاقة. إذا فشل التدفق، يشير إلى السطر ويقترح إصلاحًا كاختلاف، وتقرر ما إذا كنت ستقبله. الخطوات أدناه تأخذ 4 إجراءات من المجلد إلى النتيجة. اعمل فقط على تطبيق تبنيه أو مصرح لك باختباره، واستخدم حساب الاختبار والبيانات الوهمية، واستخدم وضع الاختبار من إعداد الدفع الخاص بك لخطوة الدفع، ولا تستخدم بطاقة حقيقية أبدًا. تذهب فحوصات البريد الإلكتروني إلى بريد اختبار تم إعداده للاختبار.
عرض ملفات الاختبار
اطلب هيكل الاختبارات. تُظهر الأدوات list_dir و glob الملفات، بينما يفتح read_file مسار إتمام الشراء لتبدأ أنت والوكيل من نفس النص قبل تنفيذ أي إجراء أو تغيير. يظهر كل إجراء في الدردشة كبطاقة تحتوي على نتيجته.
تشغيل أمر الاختبار الخاص بك
أخبر الوكيل بأي أمر اختبار يستخدمه مشروعك. يشغل Shell الأمر على Windows أو في WSL، وتعرض البطاقة المخرجات الكاملة ورمز الخروج الحقيقي، وليس ملخصًا. قم بتوسيع البطاقة إذا كنت تريد كل سطر، واستخدم grep في المخرجات للانتقال إلى الخطوة الفاشلة.
قراءة النتيجة والإصلاح
في حالة الفشل، اسأل عما تقوله المخرجات. يقترح الوكيل تعديلًا كاختلاف، ولا يتم كتابة أي شيء حتى تقبله. ارفض ما يبدو خطأ، ثم شغل الأمر مرة أخرى لمعرفة رمز الخروج الجديد. كرر العملية حتى يمر التدفق أو تعرف ما الذي يجب تغييره في التطبيق.
مخطط اختبار يمكنك نسخه
شغّل تدفق إتمام الشراء على نسختي التجريبية وأخبرني بما فشل.
- list_dir
tests/تمت القائمة - read_file
tests/checkout-flow-test.txtتم التحميل - Shell
your test commandexit 0 - grep
FAIL reports/0 تطابقات
في انتظار موافقتك قبل الانتقال للخطوة التاليةرفضقبول
checkout-flow-test.txt
# checkout flow for the staging copy of my shop
# uses only the test account and fake data
step 1: open the sign-in page
step 2: sign in with the test account
step 3: search for the sample product
step 4: add the sample product to the cart
step 5: open the cart and start checkout
step 6: pay in the test mode of my payment set-up
expect 1: the order confirmation page is shown
expect 2: the order list shows the new test order
expect 3: the test inbox received the confirmation
# when a step fails, save a screenshot and the page textهذا المخطط هو نص عادي ويعيش في المستودع بجانب اختباراتك. يحول إطار عمل الاختبار الخاص بك كل خطوة إلى رمز، ويستخدم FlowLatch الملف كمواصفات عند كتابة هذا الرمز، وتشغيله ومقارنة النتيجة مع أسطر التوقع الثلاثة. غيّر اسم المنتج والصفحات لتتوافق مع تطبيقك التجريبي الخاص.
دروس توضيحية لاختبار المتصفح الآلي
العثور على الاختبارات الموجودة وقراءتها
ابدأ بالسؤال عن مكان الاختبارات. تُظهر list_dir المجلدات، وتُدرج glob كل ملف يطابق نمطًا مثل اختبارات إتمام الشراء، و read_file يفتح تلك التي تهمك حتى تتمكن من رؤية كيفية بناء تدفق العمل اليوم. ثم يبحث grep عن المحددات (selectors) والانتظارات التي تستخدمها. كل هذا للقراءة فقط، لذا فهو خطوة أولى معقولة في وضع Plan only (خطط فقط)، الذي يضع خطة ويشغل شيئًا واحدًا. تبقى الخطة بعد إعادة التشغيل، لذا يمكنك العودة إليها غدًا. عندما تكون جاهزًا للتشغيل الفعلي، انتقل إلى Ask first (اسأل أولاً) واقرأ الخطة مرة أخرى. دوّن التدفقات التي تغطيها بالفعل، حتى تعرف أيها يفتقر إلى اختبار.
تشغيل المجموعة وقراءة رمز الخروج
بعد ترقية وقت التشغيل، غالبًا ما تأتي فشل مجموعة e2e من البيئة بدلاً من تطبيقك، لذا اقرأ الخطأ الأول قبل أن تلمس اختبارًا. يشغل Shell أمر الاختبار الخاص بك، وتحافظ البطاقة على المخرجات الكاملة ورمز الخروج الحقيقي، وهو المعبر الوحيد الصادق عن النجاح أو الفشل. يمكن لـ grep استخراج الخطوة الفاشلة من سجل طويل. اطلب شرحًا بسيطًا للخطأ في الدردشة، وقارنه بالمخرجات، ثم فقط قرر ما إذا كان ملف الاختبار يحتاج إلى تعديل. إذا كان الخطأ يذكر حزمة مفقودة أو إعدادًا متغيرًا، فأصلح البيئة أولاً وشغل الأمر نفسه مرة أخرى. غالبًا ما تمر المجموعة بعد ذلك بدون أي تعديل على الإطلاق، ويثبت رمز الخروج على البطاقة ذلك.
إصلاح محدد وإعادة التشغيل
صيانة المحددات في أتمتة اختبارات واجهة المستخدم هي المهمة الأكثر شيوعًا، لأن تخطيطًا متغيرًا يكسر المحددات المرتبطة به. يجد grep المحدد القديم في كل ملف، و read_file يعرض الخطوات حوله، ويقترح edit_file label مستقر أو test id مكانه. في Ask first (اسأل أولاً)، يتوقف الوكيل ويعرض الاختلاف. اقبل الأسطر التي تبدو صحيحة، ثم اسمح لـ Shell بتشغيل الأمر مرة أخرى. رمز الخروج الأخضر بعد التعديل هو النتيجة التي أردتها، ويبقى الاختلاف في سجل المستودع للمراجع التالي. إذا فشل الأمر بعد ذلك، اقرأ المخرجات الجديدة قبل أن تطلب تغييرًا آخر، لأن تعديلًا ثانيًا فوق تخمين خاطئ يجعل السبب أصعب في الرؤية. اجعل كل اختلاف صغيرًا بما يكفي لقراءته في جلسة واحدة.
تكرار اختبار فاشل للتحقق من عدم الثبات
عندما ينكسر اختبار ui e2e، غالبًا ما يكون السبب الحقيقي هو انتظار ثابت، أو بيانات اختبار مشتركة، أو ترتيب الاختبارات، وليس التطبيق. اطلب من FlowLatch تشغيل الاختبار الفاشل عدة مرات بنفس الأمر وإبلاغ كل رمز خروج. تعني النتائج المختلطة أن الاختبار غير مستقر. إذا كان إطار عملك قد حفظ لقطة شاشة، فإن ocr يقرأ النص فيها، ونص الصفحة من التشغيل الفاشل يضيف تلميحًا ثانيًا. أصلح الانتظار أو البيانات في اختلاف، راجعه، وشغل الاختبار مرة أخرى. امنح كل اختبار بياناته الخاصة وأعد تعيينها، وانتظر شرطًا مرئيًا بدلاً من توقف ثابت، واجعل الاختبارات مستقلة عن ترتيب بعضها البعض. كرر التشغيل مرة أخرى بعد الإصلاح؛ مرور واحد يثبت القليل.
