لماذا لا يكفي أن تعمل الإضافة في بروفايل واحد؟
قد تعمل إضافة المتصفح بصورة ممتازة داخل بروفايل تجريبي، ثم تظهر مشكلة عند تفعيلها في عشرة بروفايلات مختلفة. ربما تستخدم الإضافة مساحة تخزين لا تتوافق مع توقعات العزل، أو تحفظ إعدادًا عامًا يغير سلوك جميع النوافذ، أو ترسل رسائل إلى تبويب غير مقصود. لا يعني هذا أن كل إضافة تتسرب بالضرورة، بل أن الاختبار الفردي لا يغطي حدود التفاعل. هدف خطة الاختبار هو فصل حالة الإضافة عن حالة الموقع وحالة المتصفح، وتحديد موضع المسؤولية عندما تتكرر المشكلة.
ارسم خريطة المكونات قبل الاختبار
اكتب أين تعمل أجزاء الإضافة: صفحة Popup أو Options أو Content Script أو Service Worker في Manifest V3، وما الأذونات التي تطلبها، وما النطاقات التي تستطيع الوصول إليها. حدّد هل يتم تثبيتها لكل بروفايل بصورة مستقلة أم يعيد المتصفح استخدام حزمة واحدة مع مخازن مختلفة. راجع مستند Manifest بدل الاستدلال من اسم الإضافة فقط. أضف نسخة المتصفح وإصدار Chromium إن كان تطبيقك مبنيًا على Electron، لأن سلوك API المدعوم قد يختلف عن Chrome المستقل.
أنشئ بيانات اختبار يمكن تمييزها
استخدم ثلاثة بروفايلات A و B و C، وضع قيمة إعداد فريدة في كل واحد مثل لون تجريبي أو رقم جلسة غير حساس. افتح موقع اختبار تملكه في كل بروفايل مع كوكيز مختلفة. لا تستخدم كلمات مرور حقيقية ولا حسابات عملاء. سجّل اسم الإضافة وإصدارها وتاريخ التثبيت والبروفايل المستهدف. إذا كانت الإضافة تدعم المزامنة، عطّلها في مجموعة الاختبار الأولى ثم اختبرها منفصلة في مجموعة ثانية. بهذه الطريقة يمكن تفسير ظهور قيمة مشتركة دون افتراض تسرب غير موجود.
اختبر chrome.storage بحسب المساحة
تدعم واجهة chrome.storage مناطق مثل local و sync و session و managed وفق البيئة والأذونات. لا تفترض أن كل منطقة تتصرف ك ـLocal Storage الخاص بالموقع. اكتب قيمًا فريدة في مناطق التخزين التي تستخدمها الإضافة، ثم اقرأها من سياقات الإضافة في كل بروفايل. وثق هل ظهرت القيمة في المكان المتوقع فقط، وهل استمرت بعد إعادة التشغيل. إذا ظهرت قيمة مشتركة، تحقق أولًا من سياسة المزامنة أو إعداد المؤسسة قبل تصنيفها خطأ عزل. لا تنس اختبار إزالة الإضافة وإعادة تثبيتها على بيانات تجريبية.
Content Scripts وحدود الموقع
قد ينفذ Content Script داخل صفحات مواقع متعددة، لكنه لا يملك تلقائيًا نفس صلاحيات صفحة الإضافة. اختبر قراءة DOM وإضافة عناصر تجريبية والرسائل المرسلة إلى الخلفية، ثم راقب ما إذا كان كل حدث يرتبط بمعرف التبويب والبروفايل الصحيح. لا تعتمد على رقم تبويب منفرد إذا كانت أرقام التبويبات قابلة لإعادة الاستخدام أو كانت هناك نوافذ متعددة. ضع معرّف اختبار واضحًا في السجلات، وامنع تسجيل محتوى حساس من صفحات العملاء. الاختبار الجيد يكشف التوجيه الخاطئ دون جمع بيانات غير ضرورية.
اختبر الأذونات بدل افتراضها
راجع host_permissions و permissions وأي أذونات اختيارية، ثم اختبر الإضافة قبل منح الإذن وبعده وبعد سحبه. هل تتوقف الوظيفة المرتبطة بالنطاق؟ هل تظهر رسالة واضحة للمستخدم؟ هل تظل بيانات قديمة محفوظة رغم فقد الإذن؟ هذه أسئلة منفصلة عن التسرب بين البروفايلات. لا تمنح الإضافة جميع الصلاحيات لمجرد إنجاح الاختبار؛ استخدم أقل مجموعة مطلوبة لكل سيناريو حتى تفهم الاعتماد الفعلي. وإذا كان المتصفح يدعم جزءًا فقط من API، سجّل عدم الدعم بوصفه توافقًا وظيفيًا لا خطأ من الإضافة بالضرورة.
MV2 و MV3 يحتاجان مسارات مختلفة
في Manifest V2 قد يعتمد الامتداد على صفحة خلفية طويلة العمر، بينما يعتمد MV3 عادةً على Service Worker يمكن إيقافه واستئنافه. هذا يغيّر توقيت الرسائل وتخزين الحالة وطريقة التعامل مع المهام الطويلة. اختبر استيقاظ العامل الخلفي بعد خمول، واستقبال الرسالة الأولى، وحفظ البيانات قبل توقفه. لا تفترض أن نجاح الإضافة في Chrome بإصدار حديث يضمن نجاحها في Electron بإصدار Chromium أقدم. وثق واجهات API التي استُدعيت فعلًا، وأخطاء Console، وما إذا كانت البيئة تدعمها.
النوافذ والتبويبات وإعادة التوجيه
افتح نافذتين لكل بروفايل، ثم نفذ حدثًا من الإضافة مثل فتح تبويب أو تحديث عنوان أو قراءة حالة صفحة اختبار. تحقق من أن الإجراء أصاب النافذة والبروفايل المقصودين. كرر مع إغلاق التبويب أثناء تنفيذ الرسالة، ثم افتح تبويبًا جديدًا قد يحصل على معرّف مختلف. لا تجعل الإضافة تفترض أن «آخر نافذة نشطة» هي نافذة المستخدم الصحيح. سجّل target profile و tab ID والوقت والنتيجة، وتحقق من غياب أي أثر في البروفايلات الأخرى.
التنزيلات والملفات خارج المتصفح
قد تطلب الإضافة تنزيل ملف أو فتحه أو تخزين بيانات في مجلد افتراضي مشترك. حتى مع فصل chrome.storage، يمكن أن ينتهي ملفان من بروفايلين في مجلد Downloads نفسه. اختبر مسار التنزيل واسم الملف والتصادم عند تكرار الاسم، ثم راجع حقوق الوصول إلى الملفات. لا تفسر مشاركة مجلد التنزيل تلقائيًا على أنها تسرب كوكيز؛ إنها طبقة مختلفة يجب أن يصفها المنتج بوضوح. استخدم ملفات نصية تجريبية خالية من بيانات العملاء، وامسحها بعد اكتمال الاختبار.
اختبر الإغلاق والتعافي من الانهيار
بعد ضبط قيم مختلفة لكل بروفايل، أغلق أحدها وأعد فتحه، ثم أغلق التطبيق بالكامل وأعد التشغيل. راقب هل تعود إعدادات الإضافة لكل بروفايل بصورة صحيحة. اختبر أيضًا تعطل Renderer أو Service Worker في بيئة اختبار، دون التسبب في تعطل خادم إنتاج. بعض الأخطاء تظهر فقط عند إعادة إنشاء السياق أو تحميل الإضافة مبكرًا قبل اكتمال إعداد Partition. احتفظ بخطوات إعادة الإنتاج وسجلات أخطاء مختصرة، ولا تخلط فشل الاستعادة مع فشل العزل في التقرير.
المراقبة والأداء مع التوسع
ابدأ بثلاثة بروفايلات ثم زد العدد تدريجيًا مع مراقبة الذاكرة واستهلاك CPU وعدد العمال الخلفيين والاتصالات المفتوحة. قد تؤدي إضافة تفتح اتصالًا دائمًا لكل بروفايل إلى استهلاك مختلف تمامًا عن إضافة لا تعمل إلا عند الضغط. قس الأداء والإغلاق واستهلاك الذاكرة بصورة مستقلة عن سلامة البيانات. لا ترفع التزامن إذا بدأ الجهاز في استخدام Swap بكثافة؛ النتائج حينها تصف ضغط الجهاز أكثر مما تصف جودة الإضافة. وثق العدد الذي اختبرته فعليًا بدل الادعاء بتوافق غير محدود.
جدول حالات قبول عملي
ضع صفًا لكل حالة: قيمة chrome.storage.local في A لا تظهر في B؛ الرسالة من Content Script في B تصل إلى خلفيته الصحيحة؛ سحب إذن نطاق يمنع العملية المرتبطة؛ تنزيل ملف لا يكتب فوق ملف بروفايل آخر دون تأكيد؛ وإعادة التشغيل لا تنقل حالة بين البروفايلات. لكل صف اكتب النتيجة المتوقعة والنتيجة الفعلية ونسخة الإضافة ودليلًا غير حساس. لا تعمم نجاح خمسة اختبارات على جميع إضافات المتصفح؛ الإضافات تختلف في تصميمها وأذوناتها واعتمادها على خدمات خارجية.
قائمة قبول أولية مشروطة بتصميم الإضافة
| chrome.storage.local | عدم ظهور قيمة A في B عند العزل المقصود | قراءة قيمة تجريبية |
| رسالة Content Script | وصولها للبروفايل الصحيح | معرّف سياق وتجربة |
| سحب إذن نطاق | توقف العملية التابعة | نتيجة اختبار |
| إعادة التشغيل | استعادة الحالة دون خلط | سجل قبل وبعد |
كيف تميز الخلل من السلوك المقصود؟
قد تكون مزامنة إعداد بين الأجهزة ميزة مقصودة في الإضافة، وقد يكون استخدام مجلد تنزيلات واحد إعدادًا افتراضيًا للنظام. قبل وصف السلوك بأنه تسرب، اقرأ وثائق الإضافة وسياسة المتصفح وقارنها بتوقع المستخدم. في المقابل، إذا ظهر رمز جلسة موقع من بروفايل A داخل B دون تفويض أو مزامنة معلنة، فهذه إشارة تستحق التحقيق الجاد. لا تكتف بلقطة شاشة؛ أعد إنتاج الحالة في بروفايلات نظيفة، ثم حدد مسار البيانات الذي نقل القيمة.
مصادر موثوقة وروابط متابعة
راجع توثيق التخزين الرسمي لإضافات Chrome: https://developer.chrome.com/docs/extensions/reference/api/storage ، ودليل الأذونات: https://developer.chrome.com/docs/extensions/develop/concepts/declare-permissions ، ووثائق عزل سياقات الاختبار: https://playwright.dev/docs/browser-contexts . وعلى إيجي تاج اقرأ دليل MV2 و MV3: https://egytag.com/ar/articles/mv2-vs-mv3-ما-الذي-يتغير-لإضافات-المتصفح . هذه المصادر تصف واجهات ومنهجيات عامة، ولا تؤكد توافق إضافة بعينها مع كل إصدارات Electron أو المتصفحات المعدلة؛ الاختبار الفعلي هو المرجع.
خطة تسليم للفريق
سلّم ملفًا يحدد إصدار الإضافة والمتصفح والبروفايلات الثلاثة وسيناريوهات التخزين والرسائل والأذونات والتنزيلات وإعادة التشغيل. أرفق جدول النتائج والأخطاء المعروفة ومواضع عدم الدعم، ثم اقترح إعادة الاختبار بعد تحديث رئيسي للإضافة أو Chromium. اجعل قرار القبول مرتبطًا بالوظائف التي يحتاجها الفريق، لا بمجرد نجاح التثبيت. إذا تعذر اختبار واجهة معينة، ضع حالتها «غير مختبرة» بدل «ناجحة». بهذه الطريقة يمكن تحسين التوافق تدريجيًا دون تقديم وعود غير مدعومة للمستخدمين.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…