تسجيل فيديو المتصفح في agent-browser v0.37.0: كيف تختار معدل الإطارات؟

اختر معدل الإطارات في تسجيل فيديو المتصفح وفق سؤال المراجعة

ابدأ بمعدل 30 fps. فهو الإعداد الافتراضي الجديد لأن النقرات المعتادة، وحالات التحويم بالمؤشر، والتمرير في الصفحة، وانتقالات CSS، والعروض الإرشادية تظل واضحة من دون تحمّل العبء الإضافي لمعدل 60 fps.

النطاق المقبول للخيار --fps هو من 1 إلى 60. ولا يعني المعدل الأعلى تلقائيًا أن الدليل أقوى. فإذا كانت الصفحة تعيد الرسم بمعدل أقل من المطلوب، فلن يؤدي طلب 60 fps إلى إنشاء 60 حالة مختلفة فعلًا للصفحة.

ما الجديد في v0.37.0؟

بات المسجّل يتعامل مع الفيديو بوصفه عرضًا زمنيًا للصفحة التي تستخدمها فعلًا. يلتقط record start وrecord restart الصفحة النشطة الحالية بمعدل 30 fps افتراضيًا، ويقبلان --fps 1-60، ويستخدمان Page.startScreencast في Chrome. وهذه هي قناة Chrome الخاصة لإطارات الصفحة المعاد رسمها؛ أي كأن الكاميرا موصولة مباشرة بمسار العرض في المتصفح بدلًا من التقاط صور شاشة متباعدة.

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

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

سير عمل التسجيل في خمس خطوات

التسلسل الموثوق هو: افحص، وافتح، وسجّل، وتحقق، ثم أوقف التسجيل. والأمر الأخير جزء من عقد الدليل لأنه يفرّغ البيانات ويحفظ الملف.

agent-browser doctor
agent-browser open https://app.example.com/login
agent-browser record start ./login-flow.mp4 --fps 30
agent-browser snapshot -i
agent-browser click @e1
agent-browser wait --url "**/dashboard"
agent-browser record stop

1. افحص برنامج الترميز أولًا. يعرض agent-browser doctor حالة ffmpeg وبرامج الترميز الخاصة بالتسجيل. تحتاج MP4 إلى libx264، وتحتاج WebM إلى libvpx. ويتضمن البناء القياسي من ffmpeg عبر Homebrew أو Debian/Ubuntu كليهما عادةً.

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

3. اختر الحاوية عبر امتداد الملف. يختار .mp4 ترميز H.264 من خلال libx264، بينما يختار .webm ترميز VP8 من خلال libvpx. تُرسل الامتدادات الأخرى إلى ffmpeg مع H.264، ولا تعمل إلا إذا كان ffmpeg يعرف الحاوية. أما اسم الملف الذي لا يحمل امتدادًا فيُرفض.

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

5. أوقف التسجيل قبل الإغلاق. يحفظ record stop المقطع ويفرّغ بياناته. وقد يؤدي إغلاق الجلسة أولًا إلى تركك من دون الملف الذي أردت الاحتفاظ به. استخدم record restart عندما تريد إغلاق مقطع وبدء المقطع التالي فورًا على الصفحة النشطة.

يجيب capturedFrames وframes عن سؤالين مختلفين

اقرأ العدّادين باعتبار أحدهما مادة المصدر والآخر الفيديو النهائي. يحصي capturedFrames الإطارات المختلفة التي أنتجتها الصفحة، بينما يحصي frames الإطارات المكتوبة في ملف الفيديو. وقد تنتج الصفحة الثابتة عددًا قليلًا جدًا من الصور المختلفة، في حين يكتب ffmpeg إطارات متكررة ليظل المقطع قابلًا للمشاهدة.

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

لهذا لا يعني انخفاض قيمة capturedFrames تلقائيًا أن التسجيل فشل؛ فقد تكون الصفحة ساكنة فحسب. ولهذا أيضًا ينبغي حصر 60 fps في الحركة التي تستحق الفحص: يوضح دليل التسجيل أن 60 fps يضاعف تقريبًا معدل البت مقارنةً بـ30 fps، بينما يظل عدد الإطارات المختلفة مرهونًا بعمليات إعادة رسم الصفحة.

بند الميزانية الذي يتغير

إذا كان فريقك يشغّل agent-browser بالفعل، فلم يعد دليل الفيديو الأساسي مضطرًا إلى البدء باشتراك جديد في أداة تسجيل أخرى. تحمل حزمة v0.37.0 ترخيص Apache-2.0، لذلك لا يفرض المسجّل نفسه رسوم ترخيص لكل مستخدم. تقتصر التكاليف الإضافية على ما تشغّله أنت: إعداد ffmpeg، ووقت CI، وتخزين الملفات، والدقائق التي يقضيها المراجع البشري في فحص النتيجة.

وهذا يختلف جوهريًا عن شراء منصة متكاملة للملاحظات أو الاختبارات. تبلغ تكلفة Jam Team ‏$14 لكل منشئ شهريًا عند الفوترة السنوية. وتعرض BugHerd Standard سعرًا قدره $50 شهريًا لخمسة أعضاء عند الفوترة الشهرية، ويتضمن ذلك ملاحظات عبر الفيديو. أما BrowserStack Automate فيعرض تشغيلًا متوازيًا واحدًا لـChrome Desktop بسعر $59 شهريًا عند الفوترة السنوية، ويتضمن تسجيلات الفيديو ضمن أدوات تصحيح الأخطاء.

تبيع هذه المنتجات ما هو أكثر من التسجيل، لذا فإن استبدالها بالكامل استنتاج خاطئ. توفر BrowserStack تغطية مُدارة للمتصفحات، بينما تبيع BugHerd وJam إمكانات التعاون والتقاط المشكلات والتكاملات. قرار التكلفة المفيد أضيق نطاقًا: لا تشترِ طبقة التقاط ثانية إذا كان agent-browser يشغّل المسار بالفعل، وكان الملف الناقص مجرد فيديو واضح.

سبع حالات استخدام مرتبة بحسب المستفيد الأكبر

1. فرق المنتجات التي تشخّص مسارات CI الفاشلة

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

2. فرق الواجهات الأمامية التي تراجع السحب والتمرير والحركة

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

3. فرق منتجات AI التي تدقق سلوك وكيل المتصفح

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

4. مهندسو QA الذين يعيدون إنتاج الأخطاء المعتمدة على الحالة

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

5. الوكالات التي تسلّم إصدارًا إلى عميل

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

6. فرق الموثوقية التي تحتفظ بخطوط زمنية للتشغيل الطويل

يستطيع مهندس موثوقية تسجيل اختبار تحمّل طويل بمعدل 10 fps عندما يكون تسلسل الأحداث أهم من الحركة. يقلل المعدل المنخفض عبء التسجيل ونمو حجم الملف مقارنةً بـ30 أو 60 fps. ويظل المقطع مفيدًا لتحديد اللحظة المرئية للفشل، لكن ضغط الفجوات الثابتة يعني أن الطوابع الزمنية يجب أن تأتي من السجلات، لا من مدة التشغيل.

7. مهندسو الدعم الذين يصعّدون مشكلة متصفح معقدة

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

ثلاثة منتجات تستحق البناء

أفضل فرصة: حزمة أدلة لتشغيل الوكيل

ابنِ خدمة صغيرة تحوّل تشغيلًا واحدًا لوكيل المتصفح إلى حزمة مراجعة موحّدة: نتيجة التحقق، وسجل الأوامر، وصورة الشاشة النهائية، وملف MP4، وعدّادات الإطارات، ورابط يُنشر في Jira أو Linear. ستدفع فرق المنتجات والهندسة مقابلها لأن الناتج ينسجم مع سير عمل المشكلات الذي تستخدمه أصلًا.

الطلب ملموس. تُظهر بيانات الكلمات المفتاحية في الولايات المتحدة نحو 590 عملية بحث شهريًا عن “bug reporting tool”، مع $43.80 CPC. كما يظهر الإنفاق الحالي بوضوح: تبلغ تكلفة Jam Team ‏$14 لكل منشئ شهريًا عند الفوترة السنوية، بينما تبلغ تكلفة BugHerd Standard ‏$50 شهريًا عند الفوترة الشهرية. وتحتاج أصغر نسخة قابلة للبيع إلى طبقة تشغيل واحدة حول agent-browser، وتخزين للملفات، وتكامل واحد مع متعقب مشكلات، وقائمة تحقق لتنقيح البيانات الحساسة.

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

بوابة وكالة لتسليم QA

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

تُظهر بيانات الكلمات المفتاحية في الولايات المتحدة 110 عمليات بحث شهريًا عن “website qa testing”، بزيادة 55% على أساس سنوي، مع $23.91 CPC. ويمكن لنسخة MVP دعم بضعة مسارات قابلة لإعادة الاستخدام، والتقاط بمعدل 30 fps، وتعليقات، وخياري الموافقة أو الرفض. لكن عمق المنافسين يمثل تحديًا: تجمع BugHerd بالفعل بين عدد غير محدود من المشروعات ومستخدمي جهة العميل وصور الشاشة والبيانات الوصفية وملاحظات الفيديو في خطة Standard. لذا يجب أن ينتصر المنتج الجديد بأدلة ينتجها الوكيل، لا بدبوس تعليق آخر.

طبقة إعدادات مسبقة لاختبار الحركة

ابنِ أداة CI خفيفة تصنّف الاختبارات إلى timeline أو default أو motion، وتربطها بمعدلات 10 أو 30 أو 60 fps، وتنبه إلى الفجوات غير المتوقعة بين الإطارات الملتقطة والمكتوبة. وقد تدفع فرق منصات الواجهات الأمامية مقابل أدلة متسقة على مشكلات التراجع في الحركة والتفاعل.

تُظهر بيانات الكلمات المفتاحية في الولايات المتحدة 110 عمليات بحث شهريًا عن “automated browser testing” مع $14.96 CPC. أما العبارة التجارية الأضيق “automated browser testing tools” فلا تسجل سوى 20 عملية بحث شهرية، لكن مع $63.21 CPC، ما يشير إلى أن الوصول إلى هذه الشريحة الصغيرة من المشترين مكلف. تتكون نسخة MVP من ملف بيان للاختبارات، وطبقة تشغيل لأوامر agent-browser، والاحتفاظ بالمقاطع عند الفشل فقط، وفهرس مدمج للملفات.

المشكلة هي ضعف الزخم: انخفضت العبارة الأوسع 18% على أساس سنوي، كما يضيف 60 fps عبئًا مع بقائه محدودًا بمعدل إعادة رسم الصفحة. لذا ينبغي أن يبدأ هذا الحل كميزة داخل منتج للأدلة، لا كشركة مستقلة.

ما الذي لا يثبته التسجيل؟

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

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

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

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

ما الذي ينبغي فعله يوم الاثنين؟

اختر الأسبوع المقبل مسارًا واحدًا كثير الإخفاق لتسجيل الدخول أو الدفع أو النشر. شغّل doctor، وسجّل الصفحة النشطة الحالية بمعدل 30 fps، وأبقِ عملية التحقق الحالية، ثم نفّذ record stop وأرفق ملف MP4 بنتيجة الاختبار. انتقل إلى 60 fps فقط إذا تعذر على المراجع تقييم عيب حركي، وانتقل إلى 10 fps عندما يكون التشغيل الطويل تسلسلًا في المقام الأول. ينجح الاختبار التجريبي حين يستطيع المراجع تشخيص الفشل من دون إعادة التشغيل، لا حين يبدو الفيديو سلسًا فحسب.

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