البحث في الموقع

سنطّلع في هذا المقال على مشاكل التوافق مع المتصفحات Cross-browser الشائعة التي ستواجهها في شيفرة HTML و CSS، بالإضافة إلى الأدوات التي يمكن استخدامها لمنع حدوثها أو إصلاحها، إذ يتضمن ذلك كشف الأخطاء المحتملة في الشيفرة البرمجية والتعامل مع بادئات CSS واستخدام أدوات تطوير المتصفح لتعقّب المشاكل واستخدام تعويض نقص دعم المتصفحات Polyfill لإضافة الدعم إليها، ومعالجة مشاكل التصميم المتجاوب مع الشاشات وغير ذلك. المتطلبات الأساسية: يجب أن تتعلم أساسيات لغات HTML و CSS وجافاسكربت JavaScript، وأن تكون لديك فكرة عن المبادئ عالية المستوى لاختبار التوافق مع المتصفحات. الهدف: أن تكون قادرًا على تشخيص مشاكل التوافق مع المتصفحات المختلفة الشائعة في شيفرة HTML و CSS واستخدام الأدوات والتقنيات المناسبة لإصلاحها. مشاكل لغتي HTML و CSS تكمن مشاكل لغتَي HTML و CSS في حقيقة أنهما لغتان بسيطتان إلى حد ما، ولا يأخذها المطورون على محمل الجد في أغلب الأحيان من حيث التأكد من أن الشيفرة مُعَدّة جيدًا وفعالة وتصف الغرض من الميزات الموجودة في الصفحة. تُستخدَم لغة جافاسكربت في أسوأ الحالات لإنشاء محتوى صفحة الويب وتنسيقها بالكامل، مما يجعل صفحاتك غير شاملة وذات أداء ضعيف، ويُعَد إنشاء عناصر DOM مكلفًا، كما لا تُدعَم الميزات الجديدة في حالات أخرى باستمرار على متصفحات متعددة، مما يجعل بعض الميزات والتنسيقات لا تعمل عند بعض المستخدِمين. تُعَدّ مشاكل التصميم المتجاوب مع الشاشات شائعًا أيضًا، إذ يمكن أن يوفر الموقع الذي يبدو جيدًا في متصفح على حاسوب تجربةً سيئةً على هاتف محمول، لأن المحتوى صغير جدًا بحيث لا يمكن قراءته أو بسبب كون الموقع بطيئًا بسبب الحركات الثقيلة. لننتقل الآن إلى كيفية تقليل الأخطاء على المتصفحات التي تنتج عن شيفرة HTML أو CSS. إصلاح المشاكل العامة يُعَدّ اختبار بعض المتصفحات الحديثة على الحاسوب وعلى الهاتف المحمول استراتيجيةً جيدةً للتأكد من عمل شيفرتك بنجاح قبل التركيز على مشاكل التوافق مع المتصفحات. قدّمنا في مقالَي تنقيح أخطاء شيفرة HTML وتنقيح أخطاء شيفرة CSS بعض الإرشادات الأساسية حول تنقيح أخطاء شيفرة HTML و CSS، فإذا لم تكن على دراية بالأساسيات، فيجب عليك بالتأكيد مراجعة هذين المقالين قبل المتابعة، إذ يتعلق الأمر بالتحقق مما إذا كانت شيفرة HTML و CSS منسقةً جيدًا ولا تحتوي على أيّ أخطاء صياغية. ملاحظة: تظهر إحدى المشاكل الشائعة في لغتَي CSS و HTML عندما تبدأ قواعد CSS المختلفة في التعارض مع بعضها البعض، ويمكن أن يشكّل ذلك مشكلةً خاصةً عند استخدام شيفرة خارجية مثل استخدام إطار عمل خاص بلغة CSS ثم تجد أن أحد أسماء الأصناف Class التي يستخدِمها هذا الإطار يتعارض مع اسم استخدَمته مسبقًا لغرض مختلف، أو يمكن أن تجد أن شيفرة HTML التي تنشئها واجهة برمجة تطبيقات جهة خارجية -مثل إنشاء إعلانات- تتضمن اسم صنف أو معرّف ID استخدمته مسبقًا لغرض مختلف، ويمكنك ضمان عدم حدوث ذلك من خلال البحث في الأدوات التي تستخدِمها أولًا وتصميم شيفرتك على أساسها، ويمكنك استخدام فضاء أسماء Namespace في CSS إذا كان لديك عنصر واجهة مستخدم Widget مثلًا، ولكن تأكد من أنه يحتوي على صنف مميز، ثم استخدم المحدّدات Selectors التي تحدد العناصر ضمن عنصر واجهة المستخدم باستخدام هذا الصنف، وبالتالي تقل احتمالية التعارضات مثل ‎.audio-player ul a. التحقق من صحة شيفرة HTML و CSS يتضمن التحققُ من صحة شيفرة HTML التأكدَ من أن جميع الوسوم Tags مغلقة ومتداخلة بطريقة صحيحة، وأنك تستخدِم DOCTYPE والوسوم لغرضها الصحيح، كما يجب التحقق من صحة الشيفرة البرمجية بانتظام، وإحدى الخدمات التي يمكنها التحقق من صحة الشيفرة البرمجية هي خدمة Markup Validation Service من W3C التي تسمح لك بالإشارة إلى شيفرتك البرمجية ثم تعيد قائمةً بالأخطاء: كما تحتاج إلى شيفرة CSS للتحقق من أنّ أسماء الخاصيات مكتوبة بطريقة صحيحة وأنّ قيم الخاصيات صحيحة وصالحة مع الخاصيات المستخدَمة فيها، وللتحقق من عدم فقدان أي أقواس معقوصة وما إلى ذلك، كما تحتوي W3C على أداة التحقق CSS Validator أيضًا. منقحات الصياغة Linters لا يشير تطبيق منقّح الصياغة Linter إلى الأخطاء فقط، وإنما يمكنه إعطاء تحذيرات حول الممارسات السيئة في شيفرة CSS، ويمكن تخصيص منقّحات الصياغة لتكون أكثر أو أقل صرامةً في تقارير الأخطاء أو التحذيرات الناتجة. هناك العديد من تطبيقات منقحات الصياغة على الإنترنت وأفضلها تطبيق Dirty Markup لشيفرات HTML و CSS وجافاسكربت وتطبيق CSS Lint لشيفرة CSS فقط، إذ تسمح لك هذه التطبيقات بلصق شيفرتك في نافذة ما ثم ستضع علامة x على الأخطاء، ويمكن بعد ذلك تحريك مؤشر الفأرة فوقها للحصول على رسالة خطأ تخبرك ما هي المشكلة، ويسمح لك تطبيق Dirty Markup بإجراء إصلاحات على شيفرة HTML باستخدام زر التنظيف "Clean". ولكن لا يُعَدّ ذلك ملائمًا، إذ ستضطر إلى نسخ شيفرتك ولصقها في صفحة ويب للتحقق من صحتها عدة مرات، إذ تريد منقّح صياغة يتناسب مع سير عملك بأقل قدر من المتاعب، كما تحتوي العديد من محرّرات الشيفرات البرمجية على إضافات تنقيح الصياغة، إذ يحتوي المحرّر Atom من GitHub مثلًا على نظام بيئي غني بالإضافات مع العديد من خيارات تنقيح الأخطاء، وإليك مثال عن كيفية عمل هذه الإضافات Plugins: ثبّت المحرّر Atom إذا لم يكن لديك إصدار حديث مثبَّت مسبقًا. انتقل إلى مربع حوار تفضيلات Atom من خلال اختيار قائمة Atom ثم التفضيلات Preferences على نظام Mac أو من قائمة ملف File ثم Preferences في نظامَي Windows و Linux، ثم اختر خيار التثبيت Install في القائمة اليسرى. اكتب الكلمة "lint" في حقل البحث عن الحزم Search Packages واضغط على الزر Enter أو Return للبحث عن الحِزم المتعلقة بتنقيح الصياغة. يجب أن ترى حزمة تسمى "lint" في أعلى القائمة، لذا ثبّتها باستخدام زر التثبيت Install، إذ تعتمد منقّحات الصياغة الأخرى عليها في العمل، ثم ثبّت الإضافة linter-csslint لتنقيح صياغة شيفرة CSS والإضافة linter-tidy لتنقيح صياغة شيفرة HTML. حاول تحميل ملف HTML وملف CSS بعد انتهاء تثبيت الحزم، حيث سترى المشاكل مميزةً باللون الأخضر للتحذيرات وسترى دوائر حمراء للأخطاء بجوار أرقام الأسطر، ولوحةً منفصلةً في الأسفل توفِّر أرقام الأسطر ورسائل الخطأ وقيمًا مقترحة أو إصلاحات أخرى في بعض الأحيان. يتوفر لدى المحررات المشهورة الأخرى حزم تنقيح صياغة مماثلة مثل: SublimeLinter للمحرّر Sublime Text. Notepad++ Linter. VSCode linters. أدوات المطور في المتصفحات تتميز أدوات المطور المُضمَّنة في معظم المتصفحات بأدوات مفيدة لتعقب الأخطاء خاصة في شيفرة CSS. ملاحظة: لا تظهر أخطاء شيفرة HTML بسهولة في أدوات المطور، إذ سيحاول المتصفح تصحيح الوسوم ذات التنسيق السيئ تلقائيًا، حيث تُعَدّ أداة التحقق W3C Validator أفضل طريقة للعثور على أخطاء HTML. يعرض فاحص CSS في المتصفح Firefox مثلًا تصريحات CSS غير المُطبَّقة مشطوبة مع مثلث تحذير بجانبها، وسيوفر تحريك الفأرة فوق مثلث التحذير رسالةً تشرح الخطأ كما يلي: تمتلك أدوات التطوير في المتصفحات الأخرى ميزات مماثلة أيضًا. المشاكل الشائعة للتوافق مع المتصفحات لننتقل الآن إلى إلقاء نظرة على بعض مشاكل HTML و CSS الأكثر شيوعًا للتوافق مع المتصفحات، فالمجالات الرئيسية التي سنركز عليها هي نقص دعم الميزات الحديثة ومشاكل التخطيط. لا تدعم المتصفحات القديمة الميزات الحديثة تُعَدّ هذه المشكلة شائعةً خاصةً عندما تحتاج إلى دعم المتصفحات القديمة مثل إصدارات IE القديمة، أو إذا أردت استخدام ميزات تُطبَّق باستخدام بادئات CSS، إذ تعمل معظم وظائف HTML و CSS الأساسية مثل عناصر HTML وتنسيق CSS الأساسي للألوان والنصوص على معظم المتصفحات التي تريد دعمها، ولكن يظهر مزيد من المشاكل عندما تبدأ في استخدام ميزات أحدث من HTML و CSS. يُفضَّل البحث عن المتصفحات المدعومة والتقنيات ذات الصلة المفيدة بعد تحديد قائمة بالتقنيات غير المدعومة بصورة عامة التي ستستخدمها. سلوك HTML الاحتياطي يمكن حل بعض المشاكل بمجرد الاستفادة من الطريقة التي تعمل بها لغة HTML و CSS. تُعامَل عناصر HTML التي لا يتعرّف عليها المتصفح بوصفها عناصر مضمنةً مجهولة الاسم، أي هي عناصر مضمنة فعالة بدون قيمة دلالية مثل عناصر <span>، ولا يزال بإمكانك الإشارة إليها باستخدام أسماءها وتنسيقها باستخدام لغة CSS، فما عليك سوى التأكد من أنها تتصرف كما تريدها أن تتصرف مثل إعداد الخاصية display‎ إلى شيء آخر غير inline إن كان هنالك حاجة. تحتوي عناصر HTML الأكثر تعقيدًا مثل <video> و <audio> و <canvas> على آليات احتياطية لإضافتها، والتي تعمل باستخدام المبدأ السابق نفسه، إذ يمكنك إضافة محتوًى احتياطيًا بين وسمَي الفتح والإغلاق، وستتجاهل المتصفحات غير الداعمة العنصر الخارجي بفعالية وتشغّل المحتوى المتداخل. إليك المثال التالي: <video id="video" controls preload="metadata" poster="img/poster.jpg"> <source src="video/tears-of-steel-battle-clip-medium.mp4" type="video/mp4"> <source src="video/tears-of-steel-battle-clip-medium.webm" type="video/webm"> <!-- Offer download --> <p>Your browser does not support HTML5 video; here is a link to <a href="video/tears-of-steel-battle-clip-medium.mp4">view the video</a> directly.</p> </video> يتضمن هذا المثال رابطًا بسيطًا يسمح لك بتنزيل الفيديو إذا لم يعمل مشغل فيديو HTML، لذا لا يزال على الأقل بإمكان المستخدِم الوصول إلى الفيديو. تعرض عناصر نموذج HTML صفات احتياطية، إذ أدخلت لغة HTML5 أنواعًا خاصة من عناصر <input> لإدخال معلومات محددة في النماذج مثل الأوقات والتواريخ والألوان والأعداد وما إلى ذلك أو يستعمل النوع النصي type="text"‎ إن لم يدعم المتصفح نوعًا حديثًا يقدم ميزة جديدة، وهي مفيدة جدًا لا سيما على منصات الهاتف المحمول، إذ توفر طريقةً لإدخال البيانات التي تُعَدّ مهمةً جدًا لتجربة المستخدِم، كما توفر المنصات الداعمة أدوات واجهة مستخدِم خاصةً عند استخدام هذه الأنواع من حقول الإدخال مثل أداة التقويم لإدخال التواريخ. يوضِّح المثال التالي حقول إدخال التاريخ والوقت: <form> <div> <label for="date">Enter a date:</label> <input id="date" type="date"> </div> <div> <label for="time">Enter a time:</label> <input id="time" type="time"> </div> </form> يكون خرج الشيفرة السابقة كما يلي: ملاحظة: يمكنك مشاهدة هذا الخرج قيد التشغيل مباشرةً على forms-test.html، كما يمكنك الاطلاع على شيفرة هذا المثال على GitHub. إذا عرضت هذا المثال على متصفح داعم مثل المتصفح Chrome للحاسوب ولنظام Android أو iOS Safari، فسترى عناصر واجهة المستخدِم أو الميزات الخاصة قيد التشغيل أثناء إدخال البيانات. بينما ستعود المدخلات إلى مدخلات نص عادية على منصة غير داعمة مثل Internet Explorer، لذا لا يزال بإمكان المستخدِم إدخال بعض المعلومات على الأقل. سلوك CSS الاحتياطي يمكن القول أنّ لغة CSS أفضل من لغة HTML في الإجراءات الاحتياطية، فإذا صادف المتصفح تصريحًا أو قاعدةً لا يفهمها، فسيتخطاها دون تطبيقها أو ارتكاب خطأ ما، ويمكن أن يكون ذلك محبطًا لك وللمستخدِمين إذا انتقل هذا الخطأ إلى شيفرة الإنتاج، ولكن هذا يعني على الأقل عدم انهيار الموقع بأكمله بسبب خطأ واحد. لنلقِ نظرةً على المثال التالي الذي يحوي مربعًا بسيطًا مُنسَّقًا باستخدام CSS المختلفة: ملاحظة: يمكنك مشاهدة هذا المثال قيد التشغيل مباشرةً على button-with-fallback.html. يحتوي الزر على عدد من التصريحات الخاصة بتنسيقه، ولكن أكثر ما نهتم به هو ما يلي: button { ... background-color: #ff0000; background-color: rgba(255,0,0,1); box-shadow: inset 1px 1px 3px rgba(255,255,255,0.4), inset -1px -1px 3px rgba(0,0,0,0.4); } button:hover { background-color: rgba(255,0,0,0.5); } button:active { box-shadow: inset 1px 1px 3px rgba(0,0,0,0.4), inset -1px -1px 3px rgba(255,255,255,0.4); } استخدمنا هنا الخاصية background-color من النمط RGBA التي تغير العتامة Opacity عند التمرير على الزر لمنح المستخدم تلميحًا إلى أنّ الزر تفاعلي، وبعض الظل شبه الشفاف الداخلي box-shadow لإعطاء الزر ملمسًا وعمقًا. تكمن المشكلة في أن ألوان RGBA وخاصية الظلال box-shadow لا تعمل في إصدارات IE الأقدم من الإصدار 9، إذ لن تظهر الخلفية على الإطلاق في الإصدارات القديمة، لذا سيكون النص غير قابل للقراءة وسيئًا جدًا. يمكن حل هذه المشكلة من خلال إضافة تصريح ثانٍ للخاصية background-color الذي يحدد فقط اللون السداسي عشر المدعوم في المتصفحات القديمة، ويعمل بوصفه بديلًا احتياطيًا عن الميزات الحديثة إذا لم تعمل بنجاح، فما يحدث هو أن المتصفح الذي يزور هذه الصفحة يطبّق أولًا القيمة الأولى للخاصية background-color، ثم يبدّل القيمة الأولية بقيمة التصريح الثاني عندما يصل إليه إذا دعم هذا المتصفح ألوان RGBA، فإذا لم يكن الأمر كذلك، فسيتجاهل التصريح بالكامل وسيمضي قدمًا. ملاحظة: ينطبق الأمر نفسه على ميزات CSS الأخرى مثل استعلامات الوسائط Media Queries وكتل ‎@font-face و ‎@supports، فإذا لم تكن مدعومةً، فسيتجاهلها المتصفح فقط. دعم المحددات Selector لن تُطبَّق ميزات CSS على الإطلاق إذا لم تستخدِم محددات CSS الصحيحة لتحديد العنصر الذي تريد تنسيقه، فإذا كتبتَ محددًا في قائمة محددات مفصولة بفاصلة بصورة غير صحيحة، فقد لا يُحدد أو يطابق أي عنصر، وإذا كان المُحدد غير صالح، فسيجري تجاهل كل القائمة مع كتلة التنسيقات طبعًا، لذلك أضف لاحقة الصنف الزائف ‎:-moz-‎ فقط في قائمة محددات متسامحة forgiving selector list مثل ‎:where(::-moz-thumb)‎ واحذر أن تضيفها أو تستعملها في قائمة محددات ليست ضمن ‎:is()‎ أو ‎:where()‎ التي تتسامح مع محددات غير صالحة أو صحيحة لأن كل المتصفحات سوى متصفح Firefox سيراها غير صالحة وبالتالي يتجاهل كل القائمة، ولاحظ أن كلا من ‎:is()‎ أو ‎:where()‎ يمكن تمريرهما ضمن قائمة محددات أخرى من ضمنها ‎:has()‎ و ‎:not()‎. وقد وجدنا أن فحص العنصر الذي تحاول تنسيقه باستخدام أدوات التطوير في المتصفح أمر مفيد، ثم يجب النظر إلى مسار تنقل شجرة DOM الذي تميل أدوات فحص DOM إلى توفيره لمعرفة ما إذا كان المحدِّد منطقيًا بالمقارنة به. يمكنك الحصول على هذا النوع من الخرج أسفلَ أداة فحص DOM مثلًا في أدوات تطوير فايرفوكس Firefox: إذا أردت استخدام المحدد التالي مثلًا، فستتمكن من رؤية أنه لن يحدد العنصر input كما تريد: form > #date لا يُعَدّ عنصر الإدخال date في النموذج ابنًا مباشرًا للعنصر <form>، لذا يُفضَّل استخدام محدد حفيد Descendant Selector عام بدلًا من محدد ابن Child Selector. التعامل مع بادئات CSS تأتي مجموعة أخرى من المشاكل من استخدام البادئات Prefixes الخاصة بلغة CSS، وهي آلية مستخدمة للسماح لبائعي المتصفحات بتطبيق إصدارهم من ميزة CSS أو جافاسكربت أثناء وجود التقنيات في حالة تجريبية ليتمكنوا من تعديلها لتكون صحيحة دون التعارض مع تطبيقات المتصفح الأخرى أو عمليات التطبيق النهائية التي تكون بدون بادئات مثل ما يلي: يستخدِم Mozilla البادئة -moz-. تستخدِم المتصفحات Chrome و Opera و Safari و Edge البادئة -webkit-. يستخدِم Microsoft البادئة -ms-. تستخدِم الإصدارات الأصلية من المتصفح Opera البادئة o-. لا يُفترَض أبدًا استخدام الميزات ذات البادئات في مواقع الإنتاج، فهي عرضة للتغيير أو الإزالة دون سابق إنذار، وتتسبب في حدوث مشاكل على المتصفحات المختلفة عندما يقرر المطورون استخدام الإصدار -webkit- فقط من خاصية ما، مما يعني أن الموقع لن يعمل في متصفحات أخرى، ويحدث ذلك كثيرًا لدرجة أنّ المتصفحات الأخرى بدأت في تنفيذ إصدارات مع البادئة -webkit- من خاصيات CSS المختلفة، لذلك ستعمل مع مثل هذه الشيفرة البرمجية، وقد انخفض استخدام البادئات لدى بائعي المتصفحات مؤخرًا بسبب هذه الأنواع من المشاكل، ولكن لا يزال هناك بعض البادئات التي يجب الاهتمام بها. إذا أصريت على استخدام الميزات ذات البادئات، فتأكد من استخدام الميزات الصحيحة (استعمل مثلًا موقع caniuse.com)، فإذا لم تكن متأكدًا من ذلك، فيمكنك التأكد من خلال إجراء بعض الاختبارات في المتصفحات مباشرةً. وحاول تضمين الإصدار الذي لا يحوي أي بادئات بعد الذي يحوي بادئات، حيث سيُتجاهل إن لم يكن مدعومًا ويُستخدَم إن كان مدعومًا مثل: .masked { -webkit-mask-image: url(MDN.svg); mask-image: url(MDN.svg); -webkit-mask-size: 50%; mask-size: 50%; } جرب المثال البسيط التالي: افتح موقع google.com أو أيّ موقع آخر يحتوي على عنوان بارز أو أيّ عنصر كتلي آخر Block-level Element. انقر بزر الفأرة الأيمن أو اضغط على مفتاح Cmd مع الضغط على العنصر، ثم اختر فحص Inspect أو فحص العنصر Inspect element أو أيًا كان الخيار الموجود في متصفحك، إذ يجب أن يؤدي ذلك إلى فتح أدوات التطوير في متصفحك مع تحديد العنصر في أداة فحص نموذج DOM. ابحث عن ميزة يمكنك استخدامها لتحديد هذا العنصر، فقد كان لشعار جوجل الرئيسي مثلًا المعرّف hplogo في وقت كتابة هذا المقال. خزّن مرجعًا لهذا العنصر في متغير كما يلي: const test = document.getElementById("hplogo"); حاول الآن ضبط قيمة جديدة لخاصية CSS التي تهتم بها في هذا العنصر، إذ يمكنك تطبيق ذلك باستخدام الخاصية style الخاصة بالعنصر، أي اكتب ما يلي في طرفية جافاسكربت مثلًا: test.style.transform = 'rotate(90deg)' يجب أن تكمِل طرفية جافاسكربت تلقائيًا أسماء الخاصيات الموجودة في المتصفح ومطابقة ما كتبته حتى الآن عندما تكتب تمثيل اسم الخاصية بعد النقطة الثانية (لاحظ كتابة أسماء خاصيات CSS في جافاسكربت بحالة أحرف سنام الجَمل وليس باستخدام الواصلة - )، ويُعَدّ ذلك مفيدًا لمعرفة إصدارات الخاصية المُطبَّقة في ذلك المتصفح. إن أردت تضمين ميزة حديثة، فاختبر دعمها باستعمال ‎@support التي تساعدك على معرفة دعم الميزة من المتصفح أساسًا من عدمه حتى تعرف إن كنت بحاجة إلى بادئات أو حلول أخرى. مشاكل التصميم المتجاوب مع الشاشات Responsive Design التصميم المتجاوب مع الشاشات هو إنشاء تخطيطات الويب التي تتغير لتناسب عوامل أشكال الأجهزة المختلفة مثل عروض الشاشات المختلفة أو الاتجاهات (عموديًا أو أفقيًا) أو درجات الدقة، إذ سيبدو تخطيط الحاسوب مثلًا سيئًا عند عرضه على هاتف محمول، لذا يجب توفير تخطيط مناسب للهاتف المحمول باستخدام استعلامات الوسائط Media Queries والتأكد من تطبيقه بطريقة صحيحة باستخدام إطار العرض Viewport. تُعَدّ الدقة Resolution مشكلةً كبيرةً أيضًا، فليس مرجحًا أن تحتاج الأجهزة المحمولة إلى صور ثقيلة وكبيرة مثل الحواسيب، ويمكن أن يكون لديها اتصالات إنترنت أبطأ وخطط بيانات باهظة الثمن تجعل عرض النطاق الترددي الضائع مشكلةً أكبر، كما يمكن أن تحتوي الأجهزة المختلفة على مجالات من درجات الدقة المختلفة، مما يعني أنّ الصور الأصغر يمكن أن تكون غير واضحة، وهناك عدد من الأساليب التي تسمح لك بالتغلب على مثل هذه المشاكل بدءًا من استعلامات الوسائط البسيطة للهاتف المحمول أولًا وحتى تقنيات الصور المتجاوبة مع الشاشات الأكثر تعقيدًا. البحث عن المساعدة هناك العديد من المشاكل الأخرى التي ستواجهها مع شيفرة HTML و CSS، مما يجعل معرفة كيفية العثور على إجابات عبر الإنترنت لا تقدر بثمن. يمكنك طرح مشكلتك في قسم الأسئلة والأجوبة من أكاديمية حسوب للحصول على حل لمشكلتك التي تواجهها، إذ يُحتمَل أنّ المطورين الآخرين قد واجهوا المشاكل نفسها التي تواجهها أنت الآن، أو يمكنك مساعدتهم، كما يمكنك الانتقال إلى مجتمع تطوير الويب في حسوب IO، وهو مجتمع خاص بمناقشة وطرح المواضيع والقضايا العامة المتعلقة بتطوير الويب ولغاتها المختلفة. يمكنك البحث أيضًا في موسوعة حسوب والتعرف على أي ميزة أو قسم تحتاج إلى استخدامه، كما يمكنك الرجوع إلى الموقع الشهري CanIUse لمعرفة دعم الميزات في المتصفحات. الخلاصة يجب أن تكون الآن على دراية بالأنواع الرئيسية لمشاكل توافق HTML و CSS على المتصفحات التي ستواجهها في تطوير الويب وكيفية إصلاحها. ترجمة -وبتصرُّف- للمقال Handling common HTML and CSS problems. اقرأ أيضًا المقال السابق: استراتيجيات اختبارات مشاريع الويب للتوافق مع المتصفحات مدخل إلى اختبار مشاريع الويب للتوافق مع المتصفحات الأدوات المستخدمة في بناء مواقع ويب

سنتعلم في هذا المقال كيفية تثبيت بيئة الاختبارات الآلية وإجراء اختباراتك باستخدام نظام Selenium/WebDriver ومكتبة اختبار مثل selenium-webdriver في Node، وسنتعرّف على كيفية دمج بيئة اختبارك المحلية مع الأدوات التجارية مثل الأدوات التي ناقشناها في المقال السابق. المتطلبات الأساسية: يجب أن تتعلم أساسيات لغات HTML و CSS وجافاسكربت JavaScript، وأن يكون لديك فكرة عن المبادئ عالية المستوى لاختبار التوافق مع المتصفحات المختلفة والاختبارات الآلية. الهدف: معرفة كيفية إعداد بيئة اختبار Selenium محليًا وتشغيل الاختبارات باستخدامه، وكيفية دمجه مع أدوات مثل LambdaTest و Sauce Labs و BrowserStack. نظام الاختبار Selenium يُعَدّ نظام Selenium أشهر أداة لاختبار المتصفحات آليًا، وهناك طرق متعددة لاستخدام Selenium، ولكن أفضل طريقة لاستخدامه هي عبر WebDriver التي تُعَد واجهة برمجة تطبيقات API مبنية على نظام Selenium وتجري استدعاءات للمتصفح لجعله آليًا من خلال تنفيذ إجراءات مثل "افتح صفحة الويب" و"انقل هذا العنصر في الصفحة" و"انقر على هذا الرابط" و"تأكد مما إذا كان هذا الرابط يفتح عنوان URL" وغير ذلك، كما يُعَدّ ذلك مثاليًا لإجراء الاختبارات الآلية. تعتمد كيفية تثبيت واجهة WebDriver واستخدامها على البيئة البرمجية التي تريد استخدامها لكتابة الاختبارات وتشغيلها، كما تحتوي معظم البيئات الشائعة على حزمة أو إطار عمل يثبّت واجهة WebDriver والارتباطات المطلوبة للتواصل معها باستخدام هذه اللغة مثل لغات Java و C#‎ و Ruby و Python و JavaScript (Node)‎ وغيرها. تتطلب المتصفحات المختلفة مشغّلات Drivers مختلفة للسماح لواجهة WebDriver بالاتصال والتحكم بها، وراجع المنصات التي يدعمها Selenium للحصول على مزيد من المعلومات حول مكان الحصول على مشغّلات المتصفحات. سنغطّي كتابة وتشغيل اختبارات Selenium باستخدام Node.js التي تُعَدّ سريعةً وسهلة الاستخدام وبيئةً مألوفةً أكثر لمطورِي الواجهة الأمامية. إعداد Selenium في Node أعِدّ أولًا مشروع npm جديد كما ناقشنا في قسم إعداد Node و npm في المقال السابق، وسمِّ هذا المشروع باسم مختلف مثل selenium-test. يجب بعد ذلك تثبيت إطار عمل للسماح بالتعامل مع Selenium ضمن Node، كما سنختار مكتبة selenium-webdriver الرسمية الخاصة بنظام Selenium، فتوثيقها محدثٌ إلى حد ما وتُطبَّق صيانتها جيدًا، وتوجد خيارات أخرى جيدة مثل webdriver.io و nightwatch.js، كما يمكنك تثبيت selenium-webdriver من خلال تشغيل الأمر التالي مع التأكد من أنك ضمن مجلد مشروعك: npm install selenium-webdriver ملاحظة: لا يزال اتباع الخطوات السابقة أمرًا جيدًا حتى إذا ثَبَّتَّ selenium-webdriver ونزّلتَ مشغّلات المتصفح مسبقًا، إذ يجب عليك التأكد من تحديث كل شيء. يجب بعد ذلك تنزيل المشغّلات ذات الصلة لتتمكّن WebDriver من التحكم في المتصفحات التي تريد اختبارها. تُعَد بعض المتصفحات خاصة بنظام التشغيل، لذلك سنلتزم باستخدام فايرفوكس Firefox وكروم Chrome المتوفرَين على جميع أنظمة التشغيل الرئيسية. نزّل الإصدار الأحدث من المشغّلات GeckoDriver (لمتصفح Firefox) و ChromeDriver. فك ضغطها في مكان يسهل الانتقال إليه مثل جذر مجلد مستخدمك الرئيسي. أضِف موقع مشغّل chromedriver و geckodriver إلى المتغير PATH في نظامك، ويجب أن يكون هذا الموقع مسارًا مطلقًا من جذر قرصك الصلب إلى المجلد الذي يحتوي على المشغّلات، فإذا استخدمت جهاز macOS وكان اسم مستخدِمك هو sami ووضعت المشغّلات في جذر المجلد الرئيسي مثلًا، فسيكون المسار ‎/Users/sami. ملاحظة: يجب أن يكون المسار الذي تضيفه إلى المتغير PATH هو المسار إلى المجلد الذي يحتوي على المشغّلات، وليس المسارات المؤدية إلى المشغّلات نفسها، فهذا خطأ شائع. يمكنك ضبط المتغير PATH على نظام macOS ومعظم أنظمة لينكس كما يلي: إذا لم تستخدِم صدفة bash مثل أنظمة macOS التي يكون فيها الإعداد الافتراضي هو صدفة zsh وليس bash، فبدّل إلى صدفة bash كما يلي: exec bash افتح ملف ‎.bash_profile أو ‎.bashrc، فإذا لم تتمكن من رؤية الملفات المخفية، فستحتاج لعرضها. الصق ما يلي في أسفل الملف (عدّل المسار كما هو على جهازك): #Add WebDriver browser drivers to PATH export PATH=$PATH:/Users/sami احفظ هذا الملف وأغلقه، ثم أعِد تشغيل موجّه الأوامر أو الطرفية لإعادة تطبيق إعداد Bash. تحقق من وجود مساراتك الجديدة في المتغير PATH من خلال إدخال ما يلي في طرفيتك: echo $PATH يجب أن تراه مطبوعًا في الطرفية. لنجرب اختبارًا سريعًا للتأكد من أن كل شيء يعمل. أولًا، أنشئ ملفًا جديدًا ضمن مجلد مشروعك بالاسم google_test.js. ثانيًا، ضع فيه المحتويات التالية ثم احفظه: const webdriver = require('selenium-webdriver'), By = webdriver.By, until = webdriver.until; const driver = new webdriver.Builder() .forBrowser('firefox') .build(); driver.get('http://www.google.com'); driver.findElement(By.name('q')).sendKeys('webdriver'); driver.sleep(1000).then(function() { driver.findElement(By.name('q')).sendKeys(webdriver.Key.TAB); }); driver.findElement(By.name('btnK')).click(); driver.sleep(2000).then(function() { driver.getTitle().then(function(title) { if(title === 'webdriver - Google Search') { console.log('Test passed'); } else { console.log('Test failed'); } driver.quit(); }); }); ثالثًا، تأكد من أنك ضمن مجلد مشروعك في الطرفية ثم أدخِل الأمر التالي: node google_test يجب أن ترى متصفح Firefox يفتح تلقائيًا، ويجب تحميل جوجل تلقائيًا في تبويب المتصفح، وإدخال النص "webdriver" في مربع البحث، وسيُنقَر على زر البحث، ثم ستنتظر بعدها WebDriver لمدة ثانيتين، ثم يجب الوصول إلى عنوان المستند، وإذا كان النص "webdriver - Google Search"، فستُعاد رسالة تعبِّر عن اجتياز الاختبار، ثم ستغلِق WebDriver المتصفحَ Firefox وتتوقف. اختبار متصفحات متعددة في وقت واحد لا يوجد شيء يمنعك من تشغيل الاختبار على متصفحات متعددة في وقت واحد، إذًا لنجرّب ذلك. أولًا، أنشئ ملفًا جديدًا آخر ضمن مجلد مشروعك بالاسم googletestmultiple.js، ولا تتردد في تغيير المراجع إلى بعض المتصفحات الأخرى التي أضفناها أو إزالتها وغير ذلك اعتمادًا على المتصفحات المتاحة للاختبار على نظام تشغيلك، ولكن يجب التأكد من إعداد مشغّلات المتصفحات الصحيحة على نظامك، فإذا أردت معرفة السلسلة النصية المراد استخدامها ضمن التابع ‎.forBrowser()‎ للمتصفحات الأخرى، فراجع صفحة قائمة المتصفحات. ثانيًا، ضع المحتويات التالية في هذا الملف ثم احفظه: const webdriver = require('selenium-webdriver'), By = webdriver.By, until = webdriver.until; let driver_fx = new webdriver.Builder() .forBrowser('firefox') .build(); let driver_chr = new webdriver.Builder() .forBrowser('chrome') .build(); searchTest(driver_fx); searchTest(driver_chr); function searchTest(driver) { driver.get('http://www.google.com'); driver.findElement(By.name('q')).sendKeys('webdriver'); driver.sleep(1000).then(() => { driver.findElement(By.name('q')).sendKeys(webdriver.Key.TAB); }); driver.findElement(By.name('btnK')).click(); driver.sleep(2000).then(() => { driver.getTitle().then((title) => { if(title === 'webdriver - Google Search') { console.log('Test passed'); } else { console.log('Test failed'); } driver.quit(); }); }); } تأكد من أنك ضمن مجلد مشروعك في الطرفية ثم أدخِل الأمر التالي: node google_test_multiple إذا استخدمت جهاز ماك Mac وقررت اختبار المتصفح سفاري Safari، فيمكن أن تتلقى رسالة خطأ مثل "Could not create a session: You must enable the 'Allow Remote Automation' option in Safari's Develop menu to control Safari via WebDriver"، فإذا حصلت على هذا الخطأ، فاتبع التعليمات المُعطاة وحاول مرةً أخرى. أجرينا هنا الاختبار مثل الاختبار السابق باستثناء أننا غلّفناه هذه المرة ضمن الدالة searchTest()‎، وأنشأنا نسخًا من متصفحات جديدة ثم مررنا كلًا منها إلى الدالة لإجراء الاختبار على المتصفحات الثلاثة. لنلقِ نظرةً الآن على أساسيات صياغة واجهة WebDriver بمزيد من التفاصيل. أساسيات صياغة WebDriver لنلقِ نظرةً على بعض الميزات الرئيسية لصياغة Webdriver، ويمكنك الحصول على مزيد من التفاصيل من خلال الرجوع إلى مرجع واجهة برمجة تطبيقات جافاسكربت selenium-webdriver وتوثيق Selenium الرئيسي الذي يحتوي على أمثلة متعددة مكتوبة بلغات مختلفة للتعلم منها. بدء اختبار جديد يجب تضمين الوحدة selenium-webdriver كما يلي لبدء اختبار جديد: const webdriver = require('selenium-webdriver'); const By = webdriver.By; const until = webdriver.until; يجب بعد ذلك إنشاء نسخة جديدة من المشغّل باستخدام الباني new webdriver.Builder()‎، ولكن يجب ربط التابع forBrowser()‎ بها لتحديد المتصفح الذي تريد اختباره باستخدام هذا الباني، والتابع build()‎ لبنائه. let driver = new webdriver.Builder() .forBrowser('firefox') .build(); لاحظ أنه يمكن ضبط خيارات إعدادات محددة للمتصفحات المراد اختبارها، إذ يمكنك مثلًا ضبط إصدار معيّن من المتصفح ونظام التشغيل للاختبار ضمن التابع forBrowser()‎ كما يلي: let driver = new webdriver.Builder() .forBrowser('firefox', '46', 'MAC') .build(); كما يمكنك ضبط هذه الخيارات باستخدام متغير البيئة كما يلي على سبيل المثال: SELENIUM_BROWSER=firefox:46:MAC لننشئ اختبارًا جديدًا من خلال إنشاء ملف جديد بالاسم quick_test.js ضمن مجلد مشروعك لاختبار Selenium وأضِف الشيفرة البرمجية التالية إليه: const webdriver = require('selenium-webdriver'); const By = webdriver.By; const until = webdriver.until; const driver = new webdriver.Builder() .forBrowser('firefox') .build(); الحصول على الصفحة الذي تريد اختبارها يمكنك تحميل الصفحة التي تريد اختبارها من خلال استخدام التابع get()‎ مع نسخة المشغّل التي أنشأتها مسبقًا كما يلي: driver.get('http://www.google.com'); يمكنك استخدام أيّ عنوان URL للإشارة إلى موردك، بما في ذلك العنوان file://‎ لاختبار مستند محلي كما يلي: driver.get('file:///Users/chrismills/git/learning-area/tools-testing/cross-browser-testing/accessibility/fake-div-buttons.html'); أو كما يلي: driver.get('http://localhost:8888/fake-div-buttons.html'); لكن يُفضَّل استخدام موقع خادم بعيد بحيث تكون الشيفرة البرمجية أمرن، فإذا استخدَمت خادمًا بعيدًا لإجراء اختباراتك، فستُعطَّل شيفرتك إذا حاولت استخدام المسارات المحلية. أضِف السطر التالي في نهاية الملف quick_test.js: driver.get('https://mdn.github.io/learning-area/tools-testing/cross-browser-testing/accessibility/native-keyboard-accessibility.html'); التفاعل مع الصفحة لدينا مستند للاختبار، لذا يجب التفاعل معه بطريقة ما تتضمن تحديد عنصر معيّن أولًا لاختباره، ويمكنك تحديد عناصر واجهة المستخدِم بعدة طرق في WebDriver بما في ذلك استخدام المعرّف ID والصنف Class واسم العنصر وغير ذلك، كما يمكن تحقيق تحديد العنصر الفعلي باستخدام التابع findElement()‎ الذي يقبل تابعَ تحديد بوصفه معاملًا له، إذ يمكن مثلًا تحديد عنصر باستخدام المعرّف كما يلي: const element = driver.findElement(By.id('myElementId')); إحدى أكثر الطرق المفيدة للعثور على عنصر باستخدام لغة CSS هي استخدام التابع By.css الذي يسمح بتحديد عنصر باستخدام محدَّد CSS. أدخِل ما يلي في الجزء السفلي من شيفرة الملف quick_test.js: const button = driver.findElement(By.css('button:nth-of-type(1)')); اختبار العنصر إذا أردت إدخال نص ضمن الزر، فيمكننا استخدام ما يلي ضمن الملف quick_test.js: button.getText().then((text) => { console.log(`Button text is '${text}'`); }); تأكد من أنك ضمن مجلد المشروع وشغّل الاختبار كما يلي: node quick_test.js يجب أن ترى تسمية نص الزر في الطرفية. احذف إدخال الشيفرة السابقة ثم أضِف السطر التالي عوضًا عنه: button.click(); شغّل اختبارك مرةً أخرى، إذ سيُنقَر على الزر وستظهر نافذة التنبيه alert()‎ المنبثقة، وسنعلَم بذلك أنّ الزر يعمل على الأقل. كما يمكنك التفاعل مع النافذة المنبثقة من خلال إضافة ما يلي إلى أسفل الشيفرة البرمجية واختبارها مرةً أخرى: const alert = driver.switchTo().alert(); alert.getText().then((text) => { console.log(`Alert text is '${text}'`); }); alert.accept(); لنحاول بعد ذلك إدخال نص في أحد عناصر النموذج، لذا أضِف الشيفرة التالية وشغّل اختبارك مرةً أخرى: const input = driver.findElement(By.id('name')); input.sendKeys('Filling in my form'); يمكنك إرسال ضغطات على المفاتيح التي لا يمكن تمثيلها بمحارف عادية باستخدام خاصيات الكائن webdriver.Key، وقد استخدمنا سابقًا البناء التالي مثلًا للخروج من حقل إدخال النموذج قبل الإرسال: driver.sleep(1000).then(() => { driver.findElement(By.name('q')).sendKeys(webdriver.Key.TAB); }); انتظار اكتمال شيء ما تريد في بعض الأحيان جعل واجهة WebDriver تنتظر حتى يكتمل شيء ما قبل المتابعة، فإذا حمّلت صفحةً جديدةً مثلًا، فيجب عليك الانتظار حتى ينتهي تحميل نموذج DOM الخاص بالصفحة قبل محاولة التفاعل مع أيّ من عناصره، وإلّا فيُحتمَل أن يفشل الاختبار. ضمّن الكتلة التالية في اختبار الملف google_test.js مثلًا: driver.sleep(2000).then(() => { driver.getTitle().then((title) => { if(title === 'webdriver - Google Search') { console.log('Test passed'); } else { console.log('Test failed'); } }); }); يقبل التابع sleep()‎ قيمةً تحدد وقت الانتظار بالميلي ثانية ويعيد وعدًا يُؤكَّد في نهاية ذلك الوقت وتُنفَّذ الشيفرة البرمجية الموجودة ضمن التابع then()‎، إذ نحصل في هذه الحالة على عنوان الصفحة الحالية باستخدام التابع getTitle()‎ ثم نعيد رسالة نجاح أو فشل اعتمادًا على قيمة هذا العنوان. كما يمكننا إضافة التابع sleep()‎ إلى اختبار الملف quick_test.js، لذا غلّف آخر سطر من الشيفرة البرمجية ضمن كتلة كما يلي: driver.sleep(2000).then(() => { input.sendKeys('Filling in my form'); input.getAttribute("value").then((value) => { if(value !== '') { console.log('Form input editable'); } }); }); ستنتظر واجهة WebDriver الآن لمدة ثانيتين قبل ملء حقل النموذج ثم نختبر مما فيما إذا كانت قيمته مملوءةً -أي ليست فارغةً- باستخدام التابع getAttribute()‎ لاسترداد قيمة السمة value وطباعة رسالة في الطرفية إذا لم تكن فارغةً. ملاحظة: هناك تابع بالاسم wait()‎ يختبر بطريقة تكرارية شرطًا لفترة زمنية معينة ثم ينفّذ الشيفرة البرمجية، إذ يستخدِم هذا التابع المكتبة until التي تحدِّد الشروط الشائعة للاستخدام مع التابع wait()‎. إغلاق المشغلات بعد الانتهاء من استخدامها يجب عليك إغلاق أيّ نسخ من المشغّلات التي فتحتها بعد الانتهاء من إجراء الاختبار للتأكد من عدم وجود الكثير من نسخ المتصفحات المفتوحة على جهازك من خلال استخدام التابع quit()‎. استدعِ هذا التابع على نسخة مشغّلك عند الانتهاء منه من خلال إضافة السطر التالي إلى الجزء السفلي من اختبار الملف quick_test.js: driver.quit(); يجب أن ترى الآن عند تشغيله تنفيذَ الاختبار وإغلاق نسخة المتصفح مرةً أخرى بعد اكتمال الاختبار، ويُعَدّ ذلك مفيدًا لتقليل الفوضى في حاسوبك بسبب وجود الكثير من نسخ المتصفح خاصةً إذا كان لديك الكثير منها مما يتسبب في إبطاء الحاسوب. أفضل ممارسات في عملية الاختبار يجب أن تتأكد من أن اختباراتك تطبّق ما يلي: أولًا، تستخدِم استراتيجيات جيدة لتحديد المواقع: تأكّد عند التفاعل مع المستند من استخدام محدّدات المواقع وكائنات الصفحة التي لا يُحتمَل أن تتغير، فإذا كان لديك عنصر قابل للاختبار تريد إجراء اختبار عليه، فتأكد من أنه يملك معرّفًا مستقرًا أو موضعًا على الصفحة يمكن تحديده باستخدام محدّد CSS الذي لن يتغير مع تكرار الموقع التالي، إذ يجب أن تجعل اختباراتك مستقرةً قدر الإمكان، أي أنها لن تنهار عندما يتغير شيء ما. ثانيًا، تكتب اختبارات ذرية: يجب أن يختبر كل اختبار شيئًا واحدًا فقط، مما يسهل تعقّب ملف الاختبار الذي يختبر معيارًا معينًا، ويُعَدّ اختبار الملف google_test.js الذي ناقشناه سابقًا مثالًا جيدًا لأنه يختبر شيئًا واحدًا فقط، إذ يختبر ما إذا كان عنوان صفحة نتائج البحث مضبوطًا بصورة صحيحة، كما يمكننا إعطاء هذا الملف اسمًا أفضل حتى يسهل معرفة ما يفعله إذا أضفنا اختبارات جوجل أخرى مثل الاسم results_page_title_set_correctly.js. ثالثًا، تكتب اختبارات مستقلة: يجب أن يعمل كل اختبار بمفرده دون الاعتماد على اختبارات أخرى للعمل. كما يجب أن نذكر نتائج أو تقرير الاختبار، إذ أصدرنا تقريرًا بالنتائج في الأمثلة السابقة باستخدام تعليمات console.log()‎ البسيطة، ولكن يحدث كل ذلك في شيفرة جافاسكربت، لذا يمكنك استخدام أيّ نظام اختبار تريده لتشغيل الاختبار وإعداد التقارير سواءً كان Mocha أو Chai أو أيّ أداة أخرى. أولًا، أنشئ مثلًا نسخةً محليةً من المثال mocha_test.js ضمن مجلد مشروعك، ثم ضع هذا الملف ضمن مجلد فرعي بالاسم test، إذ يستخدِم هذا المثال سلسلةً طويلةً من الوعود لتنفيذ جميع الخطوات المطلوبة في اختبارنا، حيث يجب تأكيد التوابع المستندة إلى الوعود التي تستخدمها WebDriver حتى تعمل بطريقة صحيحة. ثانيًا، ثبّت أداة الاختبار Mocha عبر تشغيل الأمر التالي ضمن مجلد مشروعك: npm install --save-dev mocha يمكنك الآن تشغيل الاختبار وأيّ اختبارات أخرى تضعها ضمن مجلد test باستخدام الأمر التالي: npx mocha --no-timeouts يجب عليك تضمين الراية ‎--no-timeouts للتأكد من عدم فشل اختباراتك بسبب مهلة Mocha التي هي 3 ثوان. إجراء الاختبارات عن بعد اتضح أنّ إجراء الاختبارات على الخوادم البعيدة ليس أصعب من تشغيلها محليًا، إذ يجب فقط إنشاء نسخة من مشغّلك مع تحديد عدد من الميزات الإضافية بما في ذلك إمكانات المتصفح الذي تريد تطبيق الاختبار عليه وعنوان الخادم وبيانات ثبوتيات المستخدِم التي تحتاجها -إذا وجِدت- للوصول إليه. LambdaTest يُعَدّ إجراء اختبارات Selenium عن بُعد على نظام LambdaTest أمرًا بسيطًا، ويجب أن تتّبع الشيفرة البرمجية التي تحتاجها النمطَ الآتي. إذًا لنكتب مثالًا يوضّح إجراء اختبارات Selenium عن بُعد على نظام LambdaTest: أولًا، أنشئ ملفًا جديدًا بالاسم lambdatest-google_test.js ضمن مجلد المشروع. ثانيًا، ضع فيه المحتويات التالية: const webdriver = require('selenium-webdriver'); const By = webdriver.By; const until = webdriver.until; // username: يمكن العثور على اسم المستخدِم في لوحة تحكم الأتمتة const USERNAME = '{username}'; // AccessKey: يمكن توليد مفتاح الوصول من لوحة تحكم الأتمتة أو قسم الملف الشخصي const KEY = '{accessKey}'; // gridUrl: يمكن العثور عليه في لوحة تحكم الأتمتة const GRID_HOST = 'hub.lambdatest.com/wd/hub'; function searchTextOnGoogle() { // إعداد إمكانات الإدخال const capabilities = { platform: 'windows 10', browserName: 'chrome', version: '67.0', resolution: '1280x800', network: true, visual: true, console: true, video: true, name: 'Test 1', // اسم الاختبار build: 'NodeJS build' // اسم البناء }; // URL: https://{username}:{accessToken}@hub.lambdatest.com/wd/hub const gridUrl = `https://${USERNAME}:${KEY}@${GRID_HOST}`; // إعداد وبناء كائن مشغّل‫ selenium const driver = new webdriver.Builder() .usingServer(gridUrl) .withCapabilities(capabilities) .build(); // ‫انتقل إلى عنوان url، وابحث عن نص واحصل على عنوان الصفحة driver.get('https://www.google.com/ncr').then(function() { driver.findElement(webdriver.By.name('q')).sendKeys('LambdaTest\n').then(function() { driver.getTitle().then((title) => { setTimeout(() => { console.log(title); driver.quit(); }, 5000); }); }); }); } searchTextOnGoogle(); ثالثًا، انتقل إلى لوحة تحكم أتمتة LambdaTest لجلب اسم مستخدِم LambdaTest ومفتاح الوصول من خلال النقر على رمز المفتاح في أعلى اليمين، حيث سترى اسم المستخدِم Username ومفاتيح الوصول Access Keys، واستبدل العناصر البديلة {username} و {accessKey} في شيفرتك باسم المستخدِم وقيم مفتاح الوصول الفعلية وتأكّد من الحفاظ عليها آمنةً. رابعًا، شغّل الأمر التالي في طرفيتك لتنفيذ اختبارك: node lambdatest_google_test سيُرسَل الاختبار إلى LambdaTest وسيظهر خرج الاختبار على طرفية LambdaTest، فإذا أردتَ استخراج هذه النتائج لإصدار التقارير من منصة LambdaTest، فيمكنك ذلك باستخدام واجهة برمجة تطبيقات LambdaTest. إذا ذهبتَ الآن إلى لوحة تحكم أتمتة LambdaTest، فسترى اختبارك موجودًا هناك حيث ستتمكن من مشاهدة مقاطع الفيديو ولقطات الشاشة وغيرها من البيانات. يمكنك استرداد سجلات الشبكة والأوامر والاستثناءات و Selenium لكل اختبار في عملية بناء اختبارك، وستجد تسجيل فيديو لتنفيذ سكربت Selenium. ملاحظة: سيوفر زر "المساعدة HELP" الموجود في لوحة تحكم أتمتة LambdaTest كميةً وافرةً من المعلومات لمساعدتك في بدء تشغيل اختبار LambdaTest الآلي. ملاحظة: إذا لم ترغب في كتابة كائنات الإمكانات لاختباراتك يدويًا، فيمكنك إنشاؤها باستخدام منشئ إمكانات Selenium. ملء تفاصيل الاختبار على LambdaTest برمجيا يسهّل تمييز حالة الاختبارات الآلية المتعددة على أنها نجحت أو فشلت الأمورَ كثيرًا عند تنفيذها. أولًا، استخدِم الأمر التالي لتمييز الحالة على أنها ناجحة في LambdaTest: driver.executeScript("lambda-status=passed"); ثانيًا، استخدِم الأمر التالي لتمييز الحالة على أنها فاشلة في LambdaTest: driver.executeScript("lambda-status=failed"); BrowserStack يُعَدّ إجراء اختبارات Selenium للتشغيل عن بُعد على BrowserStack أمرًا سهلًا، إذ يجب أن تتبع الشيفرة البرمجية التي تحتاجها النمطَ الآتي. لنكتب إذًا مثالًا يوضّح إجراء اختبارات Selenium للتشغيل عن بُعد على BrowserStack: أولًا، أنشئ ملفًا جديدًا بالاسم bstack_google_test.js ضمن مجلد المشروع. ثانيًا، ضع فيه المحتويات التالية: const webdriver = require('selenium-webdriver'); const By = webdriver.By; const until = webdriver.until; // إمكانات الإدخال let capabilities = { 'browserName' : 'Firefox', 'browser_version' : '56.0 beta', 'os' : 'OS X', 'os_version' : 'Sierra', 'resolution' : '1280x1024', 'browserstack.user' : 'YOUR-USER-NAME', 'browserstack.key' : 'YOUR-ACCESS-KEY', 'browserstack.debug' : 'true', 'build' : 'First build' }; const driver = new webdriver.Builder() .usingServer('http://hub-cloud.browserstack.com/wd/hub') .withCapabilities(capabilities) .build(); driver.get('http://www.google.com'); driver.findElement(By.name('q')).sendKeys('webdriver'); driver.sleep(1000).then(() => { driver.findElement(By.name('q')).sendKeys(webdriver.Key.TAB); }); driver.findElement(By.name('btnK')).click(); driver.sleep(2000).then(() => { driver.getTitle().then((title) => { if(title === 'webdriver - Google Search') { console.log('Test passed'); } else { console.log('Test failed'); } }); }); driver.quit(); ثالثًا، انتقل إلى لوحة تحكم أتمتة BrowserStack للحصول اسم مستخدِم ومفتاح الوصول، واستبدل العناصر البديلة YOUR-USER-NAME و YOUR-ACCESS-KEY في شيفرتك باسم المستخدِم وقيم مفتاح الوصول الفعلية وتأكّد من الحفاظ عليها آمنة. رابعًا، شغّل اختبارك باستخدام الأمر التالي: node bstack_google_test سيُرسَل الاختبار إلى BrowserStack وستُعاد نتيجة الاختبار إلى طرفيتك، ويدل ذلك على أهمية تضمين آلية لإعطاء تقارير بالنتائج. أخيرًا، إذا عدت الآن إلى صفحة لوحة تحكم أتمتة BrowserStack، فسترى اختبارك موجودًا هناك: إذا نقرتَ على رابط اختبارك، فستنتقل إلى شاشة جديدة حيث ستتمكن من مشاهدة تسجيل فيديو للاختبار وسجلات تفصيلية متعددة للمعلومات المتعلقة به. ملاحظة: يحتوي خيار قائمة الموارد Resources في لوحة تحكم أتمتة Browserstack على مجموعة كبيرة من المعلومات المفيدة حول استخدامه لإجراء الاختبارات الآلية. ملاحظة: إذا لم ترغب في كتابة كائنات الإمكانات لاختباراتك يدويًا، فيمكنك إنشاؤها باستخدام منشئ إمكانات Selenium. ملء تفاصيل اختبار BrowserStack برمجيا يمكنك استخدام واجهة BrowserStack REST API وبعض الإمكانات الأخرى للتعليق على اختبارك بمزيد من التفاصيل مثل إذا نجح الاختبار وسبب نجاحه وما هو المشروع الذي يكون الاختبار جزءًا منه وغير ذلك، إذ لا يعرف BrowserStack هذه التفاصيل افتراضيًا. لنعدّل bstack_google_test.js لإظهار كيفية عمل هذه الميزات: يجب أولًا استيراد وحدة طلب Node لنتمكّن من استخدامها لإرسال الطلبات إلى واجهة REST API، لذا أضِف السطر التالي في بداية شيفرتك البرمجية: const request = require("request"); سنعدّل الآن الكائن capabilities لتضمين اسم المشروع من خلال إضافة السطر التالي قبل قوس الإغلاق المعقوص، ولاتنسى إضافة فاصلة في نهاية السطر السابق، كما يمكنك تغيير أسماء البناء والمشروع لتنظيم الاختبارات في نوافذ مختلفة من لوحة تحكم أتمتة BrowserStack كما يلي: 'project' : 'Google test 2' يجب بعد ذلك الوصول إلى المعرّف sessionId للجلسة الحالية لنعرف مكان إرسال الطلب، حيث يُضمَّن المعرّف في عنوان URL الخاص بالطلب كما سنرى لاحقًا. ضمّن الأسطر التالية بعد الكتلة التي تنشئ الكائن driver (أي let driver ...‎? let sessionId; driver.session_.then((sessionData) =>{ sessionId = sessionData.id_; }); أخيرًا، عدّل الكتلة driver.sleep(2000) ...‎ بالقرب من أسفل شيفرتك لإضافة استدعاءات واجهة REST API، ولا تنسى استبدال العناصر البديلة YOUR-USER-NAME و YOUR-ACCESS-KEY في شيفرتك البرمجية باسم المستخدِم وقيم مفتاح الوصول الفعلية: driver.sleep(2000).then(() => { driver.getTitle().then((title) => { if(title === 'webdriver - Google Search') { console.log('Test passed'); request({ uri: `https://YOUR-USER-NAME:YOUR-ACCESS-KEY@www.browserstack.com/automate/sessions/${sessionId}.json`, method:"PUT", form:{"status":"passed","reason":"Google results showed correct title"}} ); } else { console.log('Test failed'); request({ uri: `https://YOUR-USER-NAME:YOUR-ACCESS-KEY@www.browserstack.com/automate/sessions/${sessionId}.json`, method:"PUT", form:{"status":"failed","reason":"Google results showed wrong title"}} ); } }); }); سنرسل استدعاء واجهة API إلى BrowserStack بعد اكتمال الاختبار لتحديثه بحالة النجاح أو الفشل وبسبب النتيجة. إذا عُدتَ الآن إلى صفحة لوحة تحكم أتمتة BrowserStack، فيجب أن ترى جلسة اختبارك متاحةً كما كانت سابقًا ولكن مع البيانات المحدَّثة المرفقة بها: Sauce Labs يُعَدّ إجراء اختبارات Selenium للتشغيل عن بُعد في Sauce Labs أمرًا بسيطًا، ويشبه إلى حد كبير اختبار BrowserStack مع بعض الاختلافات الصياغية، كما يجب أن تتّبع الشيفرة البرمجية التي تحتاجها النمط الآتي. لنكتب إذًا مثالًا يوضّح إجراء اختبارات Selenium للتشغيل عن بُعد على Sauce Labs: أولًا، أنشئ ملفًا جديدًا بالاسم sauce_google_test.js ضمن مجلد مشروعك. ثانيًا، ضع فيه المحتويات التالية: const webdriver = require('selenium-webdriver'); const By = webdriver.By; const until = webdriver.until; const username = "YOUR-USER-NAME"; const accessKey = "YOUR-ACCESS-KEY"; const driver = new webdriver.Builder() .withCapabilities({ 'browserName': 'chrome', 'platform': 'Windows XP', 'version': '43.0', 'username': username, 'accessKey': accessKey }) .usingServer(`https://${username}:${accessKey}@ondemand.saucelabs.com:443/wd/hub`) .build(); driver.get('http://www.google.com'); driver.findElement(By.name('q')).sendKeys('webdriver'); driver.sleep(1000).then(() => { driver.findElement(By.name('q')).sendKeys(webdriver.Key.TAB); }); driver.findElement(By.name('btnK')).click(); driver.sleep(2000).then(() => { driver.getTitle().then((title) => { if(title === 'webdriver - Google Search') { console.log('Test passed'); } else { console.log('Test failed'); } }); }); driver.quit(); ثالثًا، انتقل إلى إعدادات مستخدِم Sauce Labs للحصول اسم المستخدِم ومفتاح الوصول، واستبدل العناصر البديلة YOUR-USER-NAME و YOUR-ACCESS-KEY في شيفرتك باسم المستخدِم وقيم مفتاح الوصول الفعلية وتأكّد من الحفاظ عليها آمنة. رابعًا، شغّل اختبارك باستخدام الأمر التالي: node sauce_google_test سيُرسَل الاختبار إلى Sauce Labs وستُعاد نتيجة الاختبار إلى طرفيتك، إذ يدل ذلك على أهمية تضمين آلية لإعطاء تقارير بالنتائج. أخيرًا، إذا انتقلت الآن إلى صفحة لوحة تحكم أتمتة Sauce Labs، فسترى اختبارك موجودًا هناك حيث ستتمكّن من مشاهدة مقاطع الفيديو ولقطات الشاشة وغيرها من البيانات. ملاحظة: تُعَدّ أداة إعداد منصة Sauce Labs أداةً مفيدةً لإنشاء كائنات الإمكانات لتقديمها إلى نسخ المشغّلات بناءً على المتصفح/نظام التشغيل الذي تريد الاختبار عليه. ملء تفاصيل اختبار Sauce Labs برمجيا يمكنك استخدام Sauce Labs API للتعليق على اختبارك بمزيد من التفاصيل مثل نجاح الاختبار واسم الاختبار وغير ذلك، إذ لا يعرف Sauce Labs هذه التفاصيل افتراضيًا. يمكن تطبيق ذلك كما يلي: أولًا، ثبّت المغلّف Node Sauce Labs باستخدام الأمر التالي (إذا لم تفعل ذلك مسبقًا في هذا المشروع): npm install saucelabs --save-dev ثانيًا، اطلب saucelabs في أعلى الملف sauce_google_test.js بعد التصريح عن المتغيرات: const SauceLabs = require('saucelabs'); ثالثًا، أنشئ نسخةً جديدةً من SauceLabs من خلال إضافة ما يلي: let saucelabs = new SauceLabs({ username : "YOUR-USER-NAME", password : "YOUR-ACCESS-KEY" }); لا تنسى استبدال العناصر البديلة YOUR-USER-NAME و YOUR-ACCESS-KEY في شيفرتك باسم المستخدِم وقيم مفتاح الوصول الفعلية، ولاحظ أنّ حزمة saucelabs npm تستخدِم كلمة المرور password وليس مفتاح الوصول accessKey، وبما أنك تستخدِم هاتين القيمتين، فيمكن أن ترغب في إنشاء متغيرين مساعدَين لتخزينهما فيهما. رابعًا، أضِف الكتلة التالية بعد كتلة تعريف المتغير driver بعد سطر build()‎ مباشرةً، حيث تحصل هذه الكتلة على معرّف جلسة sessionID المشغّل الصحيح الذي نحتاجه لكتابة البيانات في الوظيفة، حيث يمكنك رؤية هذا المعرّف قيد التشغيل في كتلة الشيفرة البرمجية التالية: driver.getSession().then((sessionid) => { driver.sessionID = sessionid.id_; }); أخيرًا، استبدل الكتلة driver.sleep(2000) ...‎ الموجودة في أسفل الشيفرة البرمجية بما يلي: driver.sleep(2000).then(() => {.then(function() { driver.getTitle().then((title) => { let testPassed = false; if(title === 'webdriver - Google Search') { console.log('Test passed'); let testPassed = true; } else { console.log('Test failed'); } saucelabs.updateJob(driver.sessionID, { name: 'Google search results page title test', passed: testPassed }); }); }); ضبطنا هنا المتغير testPassed على القيمة true أو false اعتمادًا على نجاح الاختبار أو فشله، ثم استخدمنا التابع saucelabs.updateJob()‎ لتحديث التفاصيل. إذا عُدتَ الآن إلى صفحة لوحة تحكم أتمتة Sauce Labs، فسترى أن وظيفتك الجديدة تحتوي الآن على البيانات المُحدَّثة المرفقة بها: خادمك البعيد إذا لم ترغب في استخدام خدمة مثل Sauce Labs أو BrowserStack، فيمكنك دائمًا إعداد خادمك للاختبار عن بُعد كما يلي: أولًا، يتطلب خادم Selenium البعيد تشغيل شيفرة جافا، لذا يجب عليك تنزيل أحدث إصدار من JDK لمنصتك من صفحة تنزيلات Java SE، ثم ثبّته بعد تنزيله. ثانيًا، نزّل خادم Selenium المستقل الأحدث الذي يعمل بوصفه وكيلًا proxy بين السكربت ومشغّلات المتصفح، ثم اختر أحدث رقم إصدار مستقر -أي ليس إصدارًا تجريبيًا beta- واختر من القائمة ملفًا يبدأ بعبارة "selenium-server-standalone"، ثم ضعه في مكان يمكنك الوصول إليه بسهولة بعد تنزيله مثل مجلدك الرئيسي، كما يجب إضافة الموقع إلى المتغير PATH إذا لم تفعل ذلك بعد. ثالثًا، شغّل الخادم المستقل من خلال إدخال ما يلي في طرفية حاسوب خادمك: java -jar selenium-server-standalone-3.0.0.jar عدّل اسم الملف ‎.jar بحيث يتطابق تمامًا مع ملفك. رابعًا، سيعمل الخادم على http://localhost:4444/wd/hub، لذا انتقل إلى هناك الآن لترى ما ستحصل عليه. لدينا الآن الخادم قيد التشغيل، فلننشئ اختبارًا تجريبيًا يعمل على خادم Selenium البعيد: أنشئ نسخةً من الملف google_test.js بالاسم google_test_remote.js وضعه في مجلد مشروعك. عدّل كتلة الشيفرة البرمجية الثانية التي تبدأ بالسطر let driver = ...‎ كما يلي: let driver = new webdriver.Builder() .forBrowser('firefox') .usingServer('http://localhost:4444/wd/hub') .build(); شغّل اختبارك وسترى أنه يعمل بالشكل المتوقع، ولكنه سيعمل هذه المرة على الخادم المستقل: node google_test_remote.js أجرينا الاختبار محليًا، ولكن يمكنك إعداده على أيّ خادم تقريبًا مع مشغّلات المتصفح ذات الصلة، ثم اربطه مع سكربتاتك باستخدام عنوان URL الذي تختاره للوصول إليه. دمج Selenium مع أدوات CI يمكن دمج Selenium والأدوات المتعلقة به مثل LambdaTest و Sauce Labs مع أدوات التكامل المستمر Continuous Integration أو CI اختصارًا، إذ يُعَدّ ذلك مفيدًا لأنه يعني أنه يمكنك إجراء اختباراتك عبر أداة CI وإجراء تغييرات جديدة في مستودع شيفرتك البرمجية فقط إذا نجحت الاختبارات. نقترح عليك البدء باستخدام أداة Travis CI التي تُعَدّ أسهل أداة CI للبدء بها ولديها تكامل جيد مع أدوات الويب مثل GitHub و Node. ملاحظة: إذا أردتَ إجراء اختبار مستمر باستخدام اختبار آلي بدون شيفرة برمجية، فيمكنك استخدام أداة Endtest أو TestingBot. يجب أن يمنحك هذا المقال نظرةً كافيةً لكتابة وتشغيل الاختبارات الآلية لتبدأ في كتابة اختباراتك الآلية الخاصة. ترجمة -وبتصرُّف- للمقال Setting up your own test automation environment. اقرأ أيضًا المقال السابق: مدخل إلى اختبارات مشاريع الويب الآلية للتوافق مع المتصفحات مدخل إلى اختبار مشاريع الويب للتوافق مع المتصفحات استراتيجيات اختبارات مشاريع الويب للتوافق مع المتصفحات معالجة المشاكل الشائعة للتوافق مع المتصفحات في شيفرة جافاسكربت

يمكن أن يصبح إجراء الاختبارات يدويًا على العديد من المتصفحات والأجهزة عدة مرات في اليوم أمرًا مملًا ويمكن أن يستغرق وقتًا طويلًا، لذا يجب أن تكون على دراية بأدوات الاختبار الآلية Automation، وسنلقي في هذا المقال نظرةً على الأدوات المتاحة وكيفية استخدام مشغّلات المهام وكيفية استخدام أساسيات تطبيقات اختبار المتصفح التجارية الآلية مثل LambdaTest و Sauce Labs و BrowserStack و TestingBot. المتطلبات الأساسية: يجب أن تتعلم أساسيات لغات HTML و CSS وجافاسكربت JavaScript، وأن يكون لديك فكرة عن المبادئ عالية المستوى لاختبار التوافق مع المتصفحات. الهدف: فهم ما يتطلبه الاختبار الآلي، وكيفية الاستفادة من بعض المنتجات التجارية لتسهيل الأمور. تسهيل الأمور باستخدام الاختبارات الآلية سنتطرق في هذا المقال إلى الكثير من الطرق التفصيلية المختلفة التي يمكنك من خلالها اختبار مواقع وتطبيقات الويب، وشرح نوع النطاق الذي يجب أن تتضمنه جهود الاختبار للتوافق مع المتصفحات فيما يتعلق بالمتصفحات التي يجب اختبارها وسهولة الوصول وأمور أخرى. يمكن أن يكون اختبار جميع الأشياء التي اطلعنا عليها في المقالات السابقة يدويًا أمرًا صعبًا للغاية، ولكن لحسن الحظ هناك أدوات تساعدنا على التخلص من ذلك تلقائيًا، فهناك طريقتان رئيسيتان يمكننا من خلالهما أتمتة هذه الاختبارات وهما: استخدِم مشغّلات المهام Task Runner مثل Grunt أو Gulp أو سكربتات npm لتشغيل الاختبارات وتنظيف الشيفرة البرمجية أثناء عملية البناء، فهذه طريقة رائعة لإجراء مهام مثل تنقيح صياغة Linting الشيفرة البرمجية وتصغيرها وإضافة بادئات CSS أو تحويل Transpiling ميزات جافاسكربت المُنشَاة للوصول إلى أقصى حد من التوافق مع المتصفحات وما إلى ذلك. استخدِم نظام أتمتة للمتصفح مثل Selenium لإجراء اختبارات محددة على المتصفحات المُثبَّتة وإعادة النتائج لإعطائك تنبيهات بأخطاء المتصفحات عند ظهورها. تعتمد تطبيقات الاختبار التجارية للتوافق مع المتصفحات مثل LambdaTest و Sauce Labs و BrowserStack و TestingBot على نظام Selenium، ولكنها تتيح لك الوصول إلى إعدادها عن بُعد باستخدام واجهة بسيطة، مما يوفر لك متاعب إعداد نظام الاختبار. سنتطّرق إلى كيفية إعداد نظام الاختبار القائم على نظام Selenium في المقال التالي، ولكن سنوضح في هذا المقال كيفية إعداد مشغّل المهام واستخدام الوظائف الأساسية للأنظمة التجارية المذكورة سابقًا. ملاحظة: ليست الفئتان السابقتان متعارضتَين، إذ يمكن إعداد مشغل المهام للوصول إلى خدمة مثل Sauce Labs أو LambdaTest عبر واجهة برمجة التطبيقات وإجراء اختبارات التوافق مع المتصفحات وإعادة النتائج. استخدام مشغل المهام لجعل أدوات الاختبار آلية يمكنك تسريع المهام الشائعة بصورة كبيرة مثل تنقيح صياغة الشيفرة البرمجية وتصغيرها باستخدام مشغّل المهام لتشغيل كل ما تحتاجه تشغيلًا تلقائيًا في مرحلة معينة من عملية البناء، إذ يمكن أن يحدث ذلك مثلًا في كل مرة تحفظ فيها ملفًا أو في أيّ وقت آخر، كما سننظر في كيفية جعل تشغيل المهام آلية باستخدام Node و Gulp، وهو خيار سهل الاستخدام للمبتدئين. إعداد Node و npm تعتمد معظم الأدوات هذه الأيام على Node.js، لذا يجب تثبيته من موقع Node.js كما يلي: نزّل برنامج التثبيت على نظامك، فإذا كان لديك Node و npm مثبتين مسبقًا، فانتقل إلى الخطوة رقم 4. ثبّته مثل أيّ برنامج آخر، ولاحظ أنّ Node يأتي مع مدير الحزم npm، مما يسمح لك بسهولة بتثبيت الحزم ومشاركة حزمك مع الآخرين وتشغيل السكربتات المفيدة في مشاريعك. اختبر تثبيت Node بعد اكتمال التثبيت من خلال كتابة الأوامر التالية في الطرفية التي تعيد الإصدارات المُثبَّتة من Node و npm: node -v npm -v إذا ثبّتَ Node و npm مسبقًا، فيجب تحديثهما إلى الإصدارات الأحدث، إذ يمكن تحديث Node من خلال تنزيل حزمة برنامج تثبيت محدَّثة وتثبيتها من الموقع الرسمي، ويمكن تحديث npm من خلال استخدام الأمر التالي في طرفيتك: npm install npm@latest -g يمكنك بدء استخدام الحزم المستندة إلى Node/npm في مشروعاتك من خلال إعداد مجلدات مشروعك بوصفها مشاريع npm، ويُعَدّ ذلك أمرًا سهلًا، فلننشئ أولًا مجلد اختبار مثلًا ولنعدّل ما نريده دون خوف. أنشئ أولًا مجلدًا جديدًا في مكان مناسب باستخدام واجهة مستخدِم مدير الملفات أو على سطر الأوامر من خلال الانتقال إلى الموقع الذي تريده وتشغيل الأمر التالي: mkdir node-test يمكنك جعل هذا المجلد مشروع npm من خلال الانتقال إلى مجلد الاختبار وتهيئته كما يلي: cd node-test npm init سيطرح عليك الأمر الثاني العديد من الأسئلة لمعرفة المعلومات المطلوبة لإعداد المشروع، ويمكنك تحديد الإعدادات الافتراضية فقط حاليًا، كما ستُسأَل بعد طرح جميع الأسئلة عمّا إذا كانت المعلومات التي أدخلتها صحيحةً، لذا اكتب yes واضغط على مفتاح Enter أو Return وسينشئ npm الملف package.json في مجلدك. يُعَدّ هذا الملف ملف إعداد للمشروع ويمكنك تخصيصه لاحقًا، ولكن سيبدو كما يلي حاليًا: { "name": "node-test", "version": "1.0.0", "description": "Test for npm projects", "main": "index.js", "scripts": { "test": "test" }, "author": "Chris Mills", "license": "MIT" } إعداد أداة Gulp للاختبارات الآلية لنلقِ نظرةً على إعداد أداة Gulp واستخدامها لجعل بعض أدوات الاختبار آليةً. أنشئ أولًا مشروع اختبار npm كما تحدّثنا سابقًا، إذ ستحتاج بعد ذلك لبعض النماذج لمحتوى HTML و CSS وجافاسكربت لاختبار نظامك، لذلك أنشئ نسخةً من الملفات index.html و main.js و style.css في مجلد فرعي باسم src ضمن مجلد مشروعك، كما يمكنك تجربة محتوى الاختبار الذي تريده، ولكن ضع في الحسبان أنّ هذه الأدوات لن تعمل على ملفات JS و CSS الداخلية، فأنت بحاجة إلى ملفات خارجية. ثبّت الأداة Gulp تثبيتًا عامًا بحيث تكون متاحةً في جميع المشاريع باستخدام الأمر التالي: npm install --global gulp-cli شغّل بعد ذلك الأمر التالي ضمن جذر مجلد مشروع npm لإعداد أداة Gulp بوصفها اعتماديةً Dependency لمشروعك: npm install --save-dev gulp أنشئ الآن ملفًا جديدًا ضمن مجلد مشروعك بالاسم gulpfile.js، وهو الملف الذي سيشغّل جميع مهامنا، وضَع ما يلي ضمن هذا الملف: const gulp = require('gulp'); exports.default = function(cb) { console.log('Gulp running'); cb(); }; يتطلب ذلك وحدة gulp التي ثبّتناها مسبقًا، ثم يصدّر مهمةً افتراضيةً لا تفعل شيئًا سوى طباعة رسالة إلى الطرفية، وهذا مفيد لإعلامنا بأنّ أداة Gulp تعمل. تُصدَّر كل مهمة من مهام gulp بالتنسيق الأساسي نفسه exports.taskName = taskFunction، وتأخذ كل دالة معامِلًا واحدًا هو دالة رد نداء callback لتشغيلها عند اكتمال المهمة. يمكنك تشغيل مهمة gulp الافتراضية باستخدام الأمر التالي: gulp إضافة بعض المهام الحقيقية إلى أداة Gulp يمكنك إضافة بعض المهام الحقيقية إلى أداة Gulp من خلال التفكير فيما نريد تطبيقه، إذ سنوضّح فيما يلي مجموعةً من الدوال الأساسية لتشغيلها في مشروعنا: html-tidy وcss-lint و js-hint للإبلاغ عن أو إصلاح أخطاء شيفرة HTML أو CSS أو JS الشائعة (اطّلع على gulp-htmltidy و gulp-csslint و gulp-jshint). Autoprefixer لفحص شيفرة CSS وإضافة بادئات البائع عند الحاجة فقط (اطلع على gulp-autoprefixer). babel لتحويل أيّ ميزات صيغة جافاسكربت جديدة إلى صيغة تقليدية تعمل في المتصفحات القديمة (اطلع على gulp-babel). راجع الروابط السابقة للحصول على إرشادات كاملة حول حزم gulp المختلفة التي نستخدمها. يجب أولًا تثبيت الإضافة عبر مدير حزم npm لاستخدامها، ثم طلب أيّ اعتماديات في الجزء العلوي من الملف gulpfile.js ثم إضافة الاختبار -أو الاختبارات- إلى الجزء السفلي منه وتصدير اسم مهمتك لتكون متاحةً باستخدام أوامر gulp. html-tidy ثبّتها باستخدام الأمر التالي: npm install --save-dev gulp-htmltidy ملاحظة: تضيف ‎--save-dev الحزمة بوصفها اعتماديةً لمشروعك، فإذا نظرت في الملف package.json الخاص بمشروعك، فسترى مدخلةً لها في الخاصية devDependencies. أضِف بعد ذلك الاعتمادية التالية إلى الملف gulpfile.js: const htmltidy = require('gulp-htmltidy'); أضِف الاختبار التالي إلى الجزء السفلي من الملف gulpfile.js: function html(cb) { return gulp.src('src/index.html') .pipe(htmltidy()) .pipe(gulp.dest('build')); cb(); } صدّر مهمة html باستخدام ما يلي: exports.html = html; عدّل بعد ذلك تعليمة التصدير الافتراضية إلى ما يلي: exports.default = html; حصلنا هنا على ملف التطوير index.html باستخدام التابع gulp.src()‎ الذي يتيح الحصول على ملف مصدر لتطبيق شيء ما عليه، ثم استخدمنا بعد ذلك الدالة pipe()‎ لتمرير هذا الملف المصدر إلى أمر آخر لتطبيق شيء آخر عليه، حيث يمكننا ربط سلسلة من دوال pipe()‎ عليه بالقدر الذي نريده. شغّلنا أولًا الدالة htmltidy()‎ على الملف المصدر التي تمر على الملف وتصلح الأخطاء فيه، وتكتب الدالة pipe()‎ الثانية ملف HTML الناتج في المجلد build. لا بدّ أنك لاحظت أننا وضعنا عنصر <p> فارغ في نسخة الدخل من الملف، حيث أزالته الدالة htmltidy عند إنشاء ملف الخرج. Autoprefixer و css-lint ثبّتهما أولًا باستخدام الأمرين التاليين: npm install --save-dev gulp-autoprefixer npm install --save-dev gulp-csslint ثانيًا، أضف الاعتماديات التالية إلى الملف gulpfile.js: const autoprefixer = require('gulp-autoprefixer'); const csslint = require('gulp-csslint'); ثالثًا، أضِف الاختبار التالي إلى الجزء السفلي من الملف gulpfile.js: function css(cb) { return gulp.src('src/style.css') .pipe(csslint()) .pipe(csslint.formatter('compact')) .pipe(autoprefixer({ cascade: false })) .pipe(gulp.dest('build')); cb(); } رابعًا، أضِف الخاصية التالية إلى الملف package.json: "browserslist": [ "last 5 versions" ] خامسًا، أضِف السطر التالي بعد التعريفات الثابتة const: const { series } = require('gulp'); سادسًا، صدِّر مهمة css باستخدام ما يلي: exports.css = css; أخيرًا، عدّل المهمة الافتراضية إلى ما يلي: exports.default = series(html, css); حصلنا هنا على الملف style.css وشغّلنا الدالة csslint عليه والتي تعطي قائمةً بأخطاء شيفرة CSS في الطرفية، ثم شغلنا الدالة autoprefixer عليه لإضافة أيّ بادئات مطلوبة لجعل ميزات CSS الحديثة تعمل في المتصفحات القديمة، ويكون الخرج في نهاية سلسلة دوال pipe()‎ ملفَ CSS المعدَّل مع البادئات ضمن المجلد build. لاحظ أنّ ذلك لن يعمل إذا لم تعثر الدالة csslint على أخطاء، لذا جرّب إزالة قوس معقوص من ملف CSS وأعِد تشغيل gulp لمعرفة الخرج الذي تحصل عليه. js-hint و babel أولًا، ثبّتهما باستخدام الأوامر التالية: npm install --save-dev gulp-babel @babel/preset-env npm install --save-dev @babel/core npm install jshint gulp-jshint --save-dev ثانيًا، أضِف الاعتماديات التالية إلى الملف gulpfile.js: const babel = require('gulp-babel'); const jshint = require('gulp-jshint'); ثالثًا، أضِف الاختبار التالي إلى الجزء السفلي من الملف gulpfile.js: function js(cb) { return gulp.src('src/main.js') .pipe(jshint()) .pipe(jshint.reporter('default')) .pipe(babel({ presets: ['@babel/env'] })) .pipe(gulp.dest('build')); cb(); } رابعًا، صدّر مهمة js باستخدام ما يلي: exports.js = js; أخيرًا، عدّل المهمة الافتراضية إلى ما يلي: exports.default = series(html, css, js); حصلنا هنا على الملف main.js وشغّلنا الدالة jshint عليه وأخرجنا النتائج في الطرفية باستخدام jshint.reporter، ثم مرّرنا الملف إلى الدالة babel التي تحوله إلى صيغة التنسيق القديم وتخرج النتيجة إلى المجلد build، وقد تضمّنت شيفرتنا الأصلية على دالة سهمية Arrow Function عدّلتها دالة babel إلى دالة ذات تنسيق قديم. مزيد من الأفكار يمكنك تشغيل الأمر gulp ضمن مجلد مشروعك بمجرد إعداد كل ما سبق، ويجب أن تحصل على الخرج التالي: يمكنك بعد ذلك تجربة خرج الملفات من خلال مهامك الآلية بالنظر إليها ضمن المجلد build وتحميل الملف build/index.html في متصفح الويب، فإذا حصلت على أخطاء، فتحقق من أنك قد أضفت جميع الاعتماديات والاختبارات المذكورة سابقًا، وحاول تعليق أقسام شيفرة HTML/CSS/JavaScript ثم أعِد تشغيل gulp لمعرفة ما إذا كان بإمكانك معرفة المشكلة. تأتي Gulp مع الدالة watch()‎ والتي يمكنك استخدامها لمراقبة ملفاتك وإجراء الاختبارات كلما حفظتَ ملفًا، لذا أضِف ما يلي إلى الجزء السفلي من الملف gulpfile.js مثلًا: function watch() { gulp.watch('src/*.html', html) gulp.watch('src/*.css', css) gulp.watch('src/*.js', js) } exports.watch = watch; أدخِل الآن الأمر gulp watch في طرفيتك، وستراقب أداة Gulp مجلدك، وتشغّل المهام المناسبة كلما حفظتَ تعديلًا في ملف HTML أو CSS أو جافاسكربت. ملاحظة: المحرف * هو محرف بدل Wildcard، فالقصد هنا هو تشغيل هذه المهام عند حفظ أيّ ملفات من هذه الأنواع، كما يمكنك استخدام محارف البدل في مهامك الرئيسية مثل gulp.src('src/*.css')‎ التي تحصل على جميع ملفات CSS ثم تشغّل مهام pipe عليها. اطّلع على مقال دليلك الشامل إلى أداة البناء Gulp في أكاديمية حسوب لمزيد من التفاصيل. مشغلات المهام الأخرى هناك العديد من مشغّلات المهام الأخرى المتاحة، فإننا لا نحاول القول أنّ الأداة Gulp هي أفضل حل موجود، ولكنها جيدة إلى حد ما للمبتدئين، كما يمكنك تجربة استخدام حلول أخرى مثل: تعمل الأداة Grunt بطريقة مشابهة جدًا للأداة Gulp باستثناء أنها تعتمد على المهام المحددة في ملف الإعداد بدلًا من استخدام شيفرة مكتوبة بلغة جافاسكربت. يمكنك تشغيل المهام مباشرةً باستخدام سكربتات npm الموجودة ضمن الملف package.json دون الحاجة إلى تثبيت أيّ نظام إضافي لتشغيل المهام، إذ تعمل سكربتات npm على أساس أنّ أشياء مثل إضافات Gulp تغلّف أدوات سطر الأوامر، لذلك إذا كان بإمكانك معرفة كيفية تشغيل الأدوات باستخدام سطر الأوامر، فيمكنك تشغيلها باستخدام سكربتات npm، إذ يكون التعامل معها أصعب قليلًا، ولكنها جيدة للأشخاص ذوي المهارات العالية في استخدام سطر الأوامر. استخدام خدمات الاختبارات التجارية لتسريع اختبار المتصفحات لنلقِ نظرةً الآن على الخدمات الخارجية التجارية لاختبار المتصفحات وما فائدتها. الفكرة الأساسية لمثل هذه التطبيقات هي أنّ الشركة التي تدير كلًا منها لديها مجموعة خوادم ضخمة يمكنها إجراء العديد من الاختبارات المختلفة، إذ ستقدّم عند استخدام هذه الخدمة عنوان URL للصفحة التي تريد اختبارها مع بعض المعلومات مثل المتصفحات التي تريد اختبارها فيها، ثم يضبط التطبيق آلة افتراضية VM جديدة مع نظام التشغيل والمتصفح الذي حددته، ويعيد الاختبار النتائج على شكل لقطات شاشة ومقاطع فيديو وملفات تسجيل ونصوص وما إلى ذلك. يمكنك بعد ذلك رفع مستوى العتاد باستخدام واجهة برمجة تطبيقات API للوصول إلى الوظائف برمجيًا، مما يعني أنه يمكن دمج هذه التطبيقات مع مشغّلات المهام مثل بيئات Selenium المحلية وغيرها لإنشاء اختبارات آلية. ملاحظة: هناك أنظمة تجارية أخرى متاحة لاختبار المتصفحات ولكن سنركّز في هذا المقال على LambdaTest و Sauce Labs و BrowserStack، كما ليست هذه الأنظمة بالضرورة أفضل الأدوات المتاحة، لكنها أدوات جيدة ومناسبة للمبتدئين. LambdaTest ابدأ بالتسجيل في نظام LambdaTest مجانًا. سجّل الدخول، إذ يجب أن يحدث ذلك تلقائيًا بعد التحقق من عنوان بريدك الإلكتروني. ملاحظة: يقدّم نظام LambdaTest حسابًا مجانيًا يمكنك من خلاله الوصول إلى منصته مدى الحياة على عكس مزودي خدمة اختبار التوافق مع المتصفحات عبر السحابة الأخرى، والفرق الوحيد بين خطته المدفوعة والمجانية هو مقدار الاستهلاك.، إذ يوفر نظام LambdaTest ستِّين دقيقة شهريًا للاختبار المجاني الآلي عبر شبكة Selenium Grid. الأساسيات: الاختبارات اليدوية سيوجّهك نظام LambdaTest بعد تسجيل الدخول إلى لوحة التحكم التي ستزودك بالتفاصيل المتعلقة بعدد الدقائق التي استهلكتها وعدد الجلسات المتزامنة الجارية والعدد الإجمالي للاختبارات حتى الآن والمزيد. أولًا، يجب اختيار التبويب "اختبار الوقت الحقيقي Real Time Testing" من قائمة التنقل اليسرى لبدء الاختبار اليدوي. ستُوجَّه عند النقر على التبويب "اختبار الوقت الحقيقي Real Time Testing" إلى شاشة حيث يمكنك اختيار إعداد المتصفح وإصداره ونظام التشغيل ودقة الشاشة التي تريد اختبار موقع الويب بها. إذا نقرتَ على زر "البدء Start"، فستظهر شاشة تحميل توفر لك آلة افتراضية VM بناءً على إعداداتك، ثم يمكنك إجراء اختبار حي وتفاعلي للتوافق مع المتصفحات على موقع ويب. إذا لاحظت وجود مشكلة في واجهة المستخدِم، فيمكنك مشاركتها مع زملائك من خلال التقاط لقطة شاشة لآلتك الافتراضية باستخدام زر لقطة الشاشة Screenshot، ويمكنك تسجيل مقطع فيديو لجلسة الاختبار من خلال الضغط على زر التسجيل في جلسة الاختبار. حدّد لقطة الشاشة قبل رفعها إلى زملائك باستخدام محرّر الصور المبني مسبقًا. استخدِم زر "تحديده على أساس خطأ Mark as Bug" لرفع الأخطاء إلى العديد من الأدوات الخارجية مثل Jira و Asana و Trello وغيرها، وبذلك يمكنك تسجيل خطأ مباشرةً من جلسة الاختبار على نظام LambdaTest إلى برنامج إدارة مشروعك. ملاحظة: تُوضَع جميع مقاطع الفيديو والصور المُلتقَطة ضمن جلسة الاختبار في المعرض وسجلات الاختبار ومتعقّب المشاكل ضمن LambdaTest. Sauce Labs لنبدأ بتجربة نظام Sauce Labs. أنشئ حسابًا تجريبيًا على Sauce Labs. سجّل الدخول، إذ يجب أن يحدث ذلك تلقائيًا بعد التحقق من عنوان بريدك الإلكتروني. الأساسيات: الاختبارات اليدوية تحتوي لوحة تحكم Sauce Labs على الكثير من الخيارات المتاحة، وتأكّد حاليًا من أنك ضمن تبويب "الاختبارات اليدوية Manual Tests". انقر على "بدء جلسة يدوية جديدة Start a new manual session". اكتب في الشاشة التالية عنوان URL للصفحة التي تريد اختبارها (استخدم العنوان https://mdn.github.io/learning-area/javascript/building-blocks/events/show-video-box-fixed.html مثلًا)، ثم اختر متصفحًا ونظام تشغيل تريد اختبارهما معًا باستخدام الأزرار والقوائم المختلفة، فهناك الكثير من الخيارات. إذا نقرت على "بدء الجلسة Start Session"، فستظهر شاشة التحميل التي تشغّل آلةً افتراضيةً تعمل عليها مجموعة المتصفح ونظام تشغيل التي اخترتها. يمكنك بعد انتهاء التحميل البدء في اختبار موقع الويب الذي يعمل في المتصفح المختار عن بُعد. يمكنك رؤية تخطيط الموقع كما سيبدو في المتصفح الذي تختبره، وتحريك الفأرة والنقر فوق الأزرار وما إلى ذلك، إذ تتيح لك القائمة العلوية ما يلي: إيقاف الجلسة. إعطاء شخص آخر عنوان URL ليتمكن من مراقبة الاختبار عن بُعد. نسخ نص أو ملاحظات إلى حافظة بعيدة. أخذ لقطة شاشة. الاختبار في وضع ملء الشاشة. ستعود بعد إيقاف الجلسة إلى تبويب الاختبارات اليدوية، حيث سترى مدخلةً entry لكل جلسة من الجلسات اليدوية السابقة التي بدأتها، وسيؤدي النقر على إحدى هذه المدخلات إلى إظهار المزيد من بيانات الجلسة، حيث يمكنك تنزيل لقطات الشاشة التي التقطتها سابقًا ومشاهدة مقطع فيديو للجلسة وعرض سجلات البيانات وغير ذلك. ملاحظة: يُعَدّ ذلك مفيدًا جدًا، وهو أكثر ملاءمةً من الاضطرار إلى إعداد كل هذه المحاكيات والآلات الافتراضية بنفسك. الخيارات المتقدمة: واجهة Sauce Labs API يحتوي نظام Sauce Labs على واجهة برمجة تطبيقات مريحة تتيح لك استرداد تفاصيل حسابك والاختبارات الحالية برمجيًا وإضافة تعليقات توضيحية إلى الاختبارات بمزيد من التفاصيل مثل حالة النجاح أو الفشل التي لا يمكن تسجيلها باستخدام الاختبار اليدوي وحده، فيمكن أن ترغب مثلًا في تشغيل أحد اختبارات Selenium عن بُعد باستخدام نظام Sauce Labs لاختبار مجموعة معينة من المتصفحات وأنظمة التشغيل، ثم تمرير نتائج الاختبار مرةً أخرى إلى نظام Sauce Labs. كما يحتوي على العديد من العملاء المتاحين للسماح لك بإجراء استدعاءات لواجهة API باستخدام بيئتك المفضلة سواءً كانت PHP أو Java أو Node.js أو غيرها. لنلقِ نظرةً سريعة على كيفية وصولنا إلى واجهة برمجة التطبيقات باستخدام Node.js و node-saucelabs. أعِدّ أولًا مشروع npm جديد لاختبار ذلك كما ذكرنا سابقًا، واستخدم اسم مجلد مختلف مثل sauce-test. ثانيًا، ثبّت مغلّف Node Sauce Labs باستخدام الأمر التالي: npm install saucelabs ثالثًا، أنشئ ملفًا جديدًا ضمن جذر مشروعك بالاسم call_sauce.js وضع فيه المحتويات التالية: const SauceLabs = require('saucelabs'); let myAccount = new SauceLabs({ username: "your-sauce-username", password: "your-sauce-api-key" }); myAccount.getAccountDetails((err, res) => { console.log(res); myAccount.getServiceStatus((err, res) => { // ‫حالة خدمات Sauce Labs console.log(res); myAccount.getJobs((err, jobs) => { // احصل على قائمة بجميع وظائفك for (const job of jobs) { myAccount.showJob(job.id, (err, res) => { let str = `${res.id}: Status: ${res.status}`; if (res.error) { str += `\x1b[31m Error: ${res.error}\x1b[0m`; } console.log(str); }); } }); }); }); رابعًأ، املأ اسم مستخدِم Sauce Labs ومفتاح API في الأماكن المشار إليها، كما يمكن استرجاعها من صفحة إعدادات المستخدِم الخاصة بك. أخيرًا، تأكد من حفظ كل شيء وشغّل ملفك كما يلي: node call_sauce الخيارات المتقدمة: الاختبارات الآلية سنغطّي تشغيل اختبارات Sauce Lab الآلية في المقال التالي. BrowserStack لنبدأ بالإصدار التجريبي من نظام BrowserStack. أنشئ حسابًا تجريبيًا من BrowserStack. سجّل الدخول، إذ يجب أن يحدث ذلك تلقائيًا بعد التحقق من عنوان بريدك الإلكتروني. يجب أن تكون في صفحة الاختبار المباشرة عند تسجيل الدخول لأول مرة، فإذا لم يكن الأمر كذلك، فانقر على الرابط Live في قائمة التنقل العلوية. إذا أردت استخدام Firefox أو Chrome، فيجب تثبيت إضافة متصفح في مربع حوار بعنوان "تفعيل الاختبار المحلي Enable Local Testing"، ثم انقر على زر "تثبيت Install" للمتابعة. ستظل قادرًا على استخدام بعض الميزات في المتصفحات الأخرى باستخدام Flash عمومًا، ولكن يمكن ألّا تحصل على التجربة الكاملة. الأساسيات: الاختبارات اليدوية تتيح لك لوحة تحكم BrowserStack Live اختيار الجهاز والمتصفح الذي ترغب في اختباره، حيث تكون المنصات في العمود الأيسر والأجهزة على اليمين، فإذا حرّكت الفأرة على كل جهاز أو نقرت عليه، فستحصل على مجموعة مختارة من المتصفحات المتوفرة على هذا الجهاز. سيؤدي النقر على إحدى أيقونات المتصفح إلى تحميل اختيارك للمنصة/الجهاز/المتصفح، لذا اختر أحد الخيارات الآن وجرّبه. ملاحظة: تشير أيقونة الجهاز الزرقاء بجوار بعض خيارات الجهاز المحمول إلى أنك ستختبر على جهاز حقيقي، وستُشغَّل الخيارات بدون هذه الأيقونة على المحاكي. ستجد أنه يمكنك إدخال عناوين URL في شريط العناوين واستخدام عناصر التحكم الأخرى كما تتوقع على جهاز حقيقي، كما يمكنك تنفيذ أشياء مثل النسخ واللصق من الجهاز إلى حافظتك أو التمرير لأعلى ولأسفل عن طريق السحب بالفأرة أو استخدام الحركات المناسبة على لوحات اللمس الخاصة بالأجهزة الداعمة مثل MacBook مثل التصغير/التكبير والضغط بإصبعين للتمرير، ولاحظ أنه ليست كل الميزات متوفرة على جميع الأجهزة. كما سترى قائمةً تسمح لك بالتحكم في الجلسة. الميزات هنا هي كما يلي: "التبديل Switch": التغيير إلى مجموعة منصة/جهاز/متصفح أخرى. الاتجاه (تشبه أيقونة إعادة التحميل): تبديل الاتجاه بين الوضع الرأسي والأفقي. ملاءمة الشاشة (تبدو مثل أيقونة ملء الشاشة): ملء مناطق الاختبار بمقدار حجم الجهاز. التقاط خطأ (تبدو مثل الكاميرا): تأخذ لقطة شاشة ثم تسمح لك بالتعليق عليها وحفظها. متعقّب المشاكل (يبدو مثل مجموعة بطاقات): عرض الأخطاء/لقطات الشاشة التي جرى التقاطها مسبقًا. الإعدادات (أيقونة الترس): تسمح لك بتعديل إعدادات الجلسة العامة. المساعدة (علامة الاستفهام): للوصول إلى وظائف المساعدة أو الدعم. أدوات التطوير Devtools: تسمح لك باستخدام أدوات التطوير الخاصة بمتصفحك لتصحيح أو معالجة الصفحة المعروضة في متصفح الاختبار مباشرةً، ويعمل ذلك حاليًا فقط عند اختبار متصفح Safari على أجهزة iOS. معلومات الجهاز Device info: تعرض معلومات حول جهاز الاختبار. الميزات Features: تعرض الميزات التي يدعمها الإعداد الحالي مثل النسخ إلى الحافظة ودعم الإيماءات وما إلى ذلك. التوقف Stop: ينهي الجلسة. ملاحظة: يُعَدّ ذلك مفيدًا جدًا، وهو أكثر ملاءمةً من الاضطرار إلى إعداد كل هذه المحاكيات والآلات الافتراضية بنفسك. الميزات الأساسية الأخرى إذا عُدتَ إلى صفحة BrowserStack الرئيسية، فستجد بعض الميزات الأساسية المفيدة الأخرى ضمن خيار قائمة "المزيد More" مثل: التجاوب مع الشاشات Responsive: أدخِل عنوان URL واضغط على إنشاء Generate، وسيحمّل BrowserStack عنوان URL على أجهزة متعددة ذات أحجام إطار عرض مختلفة، كما يمكنك في كل جهاز ضبط الإعدادات أكثر مثل حجم الشاشة للحصول على فكرة جيدة عن كيفية عمل تخطيط موقعك باستخدام عوامل الأشكال المختلفة. لقطات الشاشة Screenshots: أدخِل عنوان URL واختر المتصفحات/الأجهزة/المنصات التي تريدها، ثم اضغط على إنشاء لقطات شاشة Generate Screenshots، ثم سيأخذ BrowserStack لقطات شاشة لموقعك في جميع تلك المتصفحات ويجعلها متاحةً لك لعرضها وتنزيلها. الخيارات المتقدمة: واجهة BrowserStack API يحتوي نظام BrowserStack على واجهة برمجة تطبيقات مريحة تتيح لك استرداد تفاصيل خطة حسابك وجلساتك وعمليات البناء برمجيًا، كما يحتوي على العديد من العملاء المتاحين للسماح لك بإجراء استدعاءات لواجهة API باستخدام بيئتك المفضلة سواءً كانت PHP أو Java أو Node.js أو غيرها. لنلقِ نظرةً سريعةً على كيفية وصولنا إلى واجهة برمجة التطبيقات باستخدام Node.js. أعِدّ أولًا مشروع npm جديدًا للاختبار كما ذكرنا سابقًا، واستخدم اسم مجلد مختلف مثل bstack-test. ثانيًا، أنشئ ملفًا جديدًا ضمن جذر مشروعك بالاسم call_bstack.js وضَع فيه المحتويات التالية: const request = require("request"); let bsUser = "BROWSERSTACK_USERNAME"; let bsKey = "BROWSERSTACK_ACCESS_KEY"; let baseUrl = `https://${bsUser}:${bsKey}@www.browserstack.com/automate/`; function getPlanDetails(){ request({ uri: `${baseUrl}plan.json` }, (err, res, body) => { console.log(JSON.parse(body)); }); /* Response: { automate_plan: <string>, parallel_sessions_running: <int>, team_parallel_sessions_max_allowed: <int>, parallel_sessions_max_allowed: <int>, queued_sessions: <int>, queued_sessions_max_allowed: <int> } */ } getPlanDetails(); ثالثًا، املأ اسم مستخدِم BrowserStack ومفتاح API في الأماكن المشار إليها، ويمكن استرجاعها من [لوحة تحكم BrowserStack](https://www.browserstack.com/automate الآلية). رابعًا، تأكد من حفظ كل شيء وشغّل ملفك كما يلي: node call_bstack سنقدِّم فيما يلي بعض الدوال الأخرى الجاهزة المفيدة عند العمل مع واجهة برمجة تطبيقات BrowserStack: function getBuilds(){ request({ uri: `${baseUrl}builds.json` }, (err, res, body) => { /* Response: [ { automation_build: { name: <string>, duration: <int>, status: <string>, hashed_id: <string> } }, { automation_build: { name: <string>, duration: <int>, status: <string>, hashed_id: <string> } }, ... ] */ }; function getSessionsInBuild(build){ const buildId = build.automation_build.hashed_id; request({ uri: `${baseUrl}builds/${buildId}/sessions.json` }, (err, res, body) => { console.log(JSON.parse(body)); }); /* Response: [ { automation_session: { name: <string>, duration: <int>, os: <string>, os_version: <string>, browser_version: <string>, browser: <string>, device: <string>, status: <string>, hashed_id: <string>, reason: <string>, build_name: <string>, project_name: <string>, logs: <string>, browser_url: <string>, public_url: <string>, video_url: <string>, browser_console_logs_url: <string>, har_logs_url: <string> } }, { automation_session: { name: <string>, duration: <int>, os: <string>, os_version: <string>, browser_version: <string>, browser: <string>, device: <string>, status: <string>, hashed_id: <string>, reason: <string>, build_name: <string>, project_name: <string>, logs: <string>, browser_url: <string>, public_url: <string>, video_url: <string>, browser_console_logs_url: <string>, har_logs_url: <string> } }, ... ] */ } function getSessionDetails(session){ const sessionId = session.automation_session.hashed_id; request({uri: `${baseUrl}sessions/${sessionId}.json`}, (err, res, body) => { console.log(JSON.parse(body)); }); /* Response: { automation_session: { name: <string>, duration: <int>, os: <string>, os_version: <string>, browser_version: <string>, browser: <string>, device: <string>, status: <string>, hashed_id: <string>, reason: <string>, build_name: <string>, project_name: <string>, logs: <string>, browser_url: <string>, public_url: <string>, video_url: <string>, browser_console_logs_url: <string>, har_logs_url: <string> } } */ } الخيارات المتقدمة: الاختبارات الآلية سنغطّي تشغيل اختبارات BrowserStack الآلية في المقال التالي. TestingBot لنبدأ باختبار نظام TestingBot. أنشئ حسابًا تجريبيًا في TestingBot. سجّل الدخول، إذ يجب أن يحدث ذلك تلقائيًا بعد التحقق من عنوان بريدك الإلكتروني. الأساسيات: الاختبارات اليدوية تسرد لوحة تحكم TestingBot الخيارات المختلفة التي يمكنك الاختيار من بينها، وتأكَّد من أنك حاليًا في التبويب Live Web Testing. أدخِل عنوان URL للصفحة التي تريد اختبارها. اختر مجموعة المتصفح/نظام التشغيل التي تريد اختبارها من خلال تحديدها من الشبكة. إذا نقرت على "بدء المتصفح Start Browser"، فستظهر شاشة تحميل تشغّل آلة افتراضية تعمل عليها المجموعة التي اخترتها. يمكنك بعد انتهاء التحميل البدء في اختبار موقع الويب الذي يعمل في المتصفح المختار عن بُعد. يمكنك رؤية تخطيط الموقع كما سيبدو في المتصفح الذي تختبره، وتحريك الفأرة والنقر على الأزرار وما إلى ذلك، كما تتيح لك القائمة الجانبية ما يلي: إيقاف الجلسة. تغيير دقة الشاشة. نسخ نصوص أو ملاحظات إلى حافظة بعيدة. أخذ لقطات شاشة وتحريرها وتنزيلها. الاختبار في وضع ملء الشاشة. ستعود إلى الصفحة Live Web Testing بعد إيقاف الجلسة، حيث سترى مدخلةً لكل جلسة من الجلسات اليدوية السابقة التي بدأتها، كما سيؤدي النقر على إحدى هذه المدخلات إلى إظهار المزيد من بيانات الجلسة، إذ يمكنك تنزيل لقطات الشاشة التي التقطتها ومشاهدة مقطع فيديو للاختبار وعرض سجلات الجلسة. الخيارات المتقدمة: واجهة TestingBot API يحتوي نظام TestingBot على واجهة برمجة تطبيقات مريحة تتيح لك استرداد تفاصيل حسابك والاختبارات الحالية برمجيًا، وإضافة تعليقات توضيحية إلى الاختبارات مع مزيد من التفاصيل مثل حالة النجاح أو الفشل التي لا يمكن تسجيلها باستخدام الاختبار اليدوي وحده، كما يحتوي TestingBot على العديد من عملاء واجهة برمجة التطبيقات الذين يمكنك استخدامهم للتفاعل معها بما في ذلك عملاء NodeJS و Python و Ruby و Java و PHP. سنوضّح فيما يلي مثالًا عن كيفية التفاعل مع واجهة TestingBot API مع اختبار عميل NodeJS وهو testingbot-api: أعِدّ أولًا مشروع npm جديدًا للاختبار كما تحدثنا سابقًا، واستخدِم اسم مجلد مختلف مثل tb-test. ثانيًا، ثبّت مغلّف Node TestingBot باستخدام الأمر التالي: npm install testingbot-api ثالثًا، أنشئ ملفًا جديدًا ضمن جذر مشروعك بالاسم tb.js وضَع فيه المحتويات التالية: const TestingBot = require('testingbot-api'); let tb = new TestingBot({ api_key: "your-tb-key", api_secret: "your-tb-secret" }); tb.getTests(function (err, tests) { console.log(tests); }); رابعًا، املأ مفتاح TestingBot Key و Secret في الأماكن المشار إليها، حيث يمكنك العثور عليها في لوحة تحكم TestingBot. أخيرًا، تأكد من حفظ كل شيء وشغّل الملف كما يلي: node tb.js الخيارات المتقدمة: الاختبارات الآلية سنغطّي تشغيل اختبارات TestingBot الآلية في المقال التالي. الخلاصة يمكنك الآن البدء في رؤية فوائد استخدام أدوات الاختبار الآلية لمساعدتك في عملية اختبار مواقع الويب، وسنتطرق في المقال التالي إلى إعداد نظام الاختبارات الآلية المحلي باستخدام Selenium وكيفية دمجه مع خدمات مثل Sauce Labs و BrowserStack و TestingBot. ترجمة -وبتصرُّف- للمقال Introduction to automated testing. اقرأ أيضًا بعض المشكلات الشائعة في اختبار قابلية الاستخدام وكيفية تجنبها للحصول على مراجعات صادقة قابلية الاستخدام وأهميتها في تجربة المستخدم كيفية اكتشاف دعم المتصفحات للميزات أثناء اختبار مشاريع الويب مدخل إلى اختبار مشاريع الويب للتوافق مع المتصفحات

يتضمن اكتشاف الميزات Feature Detection معرفة ما إذا كان المتصفح يدعم كتلةً معينةً من الشيفرة البرمجية ويشغّل شيفرةً مختلفةً اعتمادًا على ذلك، بحيث يمكن للمتصفح دائمًا توفير تجربة عمل ناجحة بدلًا من التعطل أو ظهور الأخطاء في بعض المتصفحات، ويوضح هذا المقال بالتفصيل كيفية كتابة شيفرة اكتشاف المتصفحات للميزات البسيطة وكيفية استخدام مكتبة لتسريع التطبيق والميزات الأصيلة Native لاكتشاف الميزات مثل الميزة ‎@supports. المتطلبات الأساسية: يجب أن تتعلم أساسيات لغات HTML و CSS وجافاسكربت JavaScript، وأن تكون لديك فكرة عن المبادئ عالية المستوى لاختبار التوافق مع المتصفحات. الهدف: فهم مفهوم اكتشاف الميزات والقدرة على تطبيق الحلول المناسبة في شيفرة CSS وجافاسكربت. مفهوم اكتشاف الميزات تكمن الفكرة وراء اكتشاف الميزات Feature Detection في أنه يمكنك إجراء اختبار لتحديد ما إذا كانت الميزة مدعومةً في المتصفح الحالي ثم تشغيل الشيفرة البرمجية شرطيًا لتوفير تجربة مقبولة في كل من المتصفحات التي تدعم الميزة والمتصفحات التي لا تدعمها، فإذا لم تطبّق ذلك، فلن تعرض المتصفحات التي لا تدعم الميزات التي تستخدمها في شيفرتك البرمجية الخاصة مواقعَك بصورة صحيحة وستفشل، مما يخلق تجربة مستخدِم سيئة. لنطّلع على المثال الذي تطرقنا إليه في مقال معالجة المشاكل الشائعة للتوافق مع المتصفحات المختلفة في شيفرة جافاسكربت، إذ كان لدينا واجهة Geolocation API التي تعرض بيانات الموقع المتاحة للجهاز الذي يعمل عليه متصفح الويب، ولهذه الواجهة نقطة دخول رئيسية لاستخدامها وهي الخاصية geolocation التي يوفرها الكائن العام Navigator، لذا يمكنك اكتشاف ما إذا كان المتصفح يدعم تحديد الموقع الجغرافي أم لا باستخدام الشيفرة البرمجية التالية مثلًا: if ("geolocation" in navigator) { navigator.geolocation.getCurrentPosition(function(position) { // اعرض الموقع على الخريطة باستخدام‫ واجهة Google Maps API مثلًا }); } else { // اجعل المستخدِم يختار من بين الخرائط الساكنة بدلًا من ذلك } لاكتشاف ميزة واحدة، تكفي تعليمة if ولكن يُفضَّل استخدام مكتبة اكتشاف ميزات مُنشَأة مسبقًا من أجل التطبيقات المعقّدة بدلًا من كتابة مكتبتك طوال الوقت، إذ تُعَدّ مكتبة مودرنيزر Modernizr المعيار القياسي لاختبارات اكتشاف الميزات وسنتطرق إليها لاحقًا. لا تخلط بين اكتشاف الميزات والتعرف على المتصفح Browser Sniffing -أي اكتشاف المتصفح المُحدَّد الذي يصل إلى الموقع- الذي يُعَدّ ممارسةً سيئةً يجب عدم استخدامها، وراجع فقرة استخدام شيفرة التعرف على المتصفح السيئة من مقال معالجة المشاكل الشائعة للتوافق مع المتصفحات المختلفة في شيفرة جافاسكربت للتعرف على مزيد من التفاصيل. كتابة اختباراتك الخاصة لاكتشاف الميزات سنتعرّف في هذا القسم على تطبيق اختباراتك الخاصة لاكتشاف الميزات في كل من شيفرة CSS وجافاسكربت. شيفرة CSS يمكنك كتابة اختبارات لميزات CSS من خلال اختبار وجود خاصيات element.style.property -مثل الخاصية paragraph.style.transform- في شيفرة جافاسكربت. يمكن أن يكون المثال التقليدي لذلك هو اختبار دعم قيمة subgrid ضمن التخطيط الشبكي Grid في المتصفح، إذ يمكننا استعمال القيمة subgrid التخطيط الشبكي الفرعي مع grid-template-columns و grid-template-rows في المتصفحات التي تدعم ضمن التخطيط الشبكي أما في المتصفحات التي لا تدعهما فنستخدم التخطيط الشبكي العادي ولكن لن تكون كما نريد مع subgrid. بناء على المثال السابق، يمكن أن نضيف ملف تنسيق stylesheet ضمن الترويسة head في ملف HTML الأول فيه تنفيذ كل subgrid وذلك إن كانت مدعومة في المتصفح والآخر يستعمل التخطيط الشبكي العادي إن لم تكن مدعومة وذلك لتعويض نقص الدعم الحاصل وتجنب اختلال التنسيق، بالشكل التالي مثلًا: <link href="basic-styling.css" rel="stylesheet" /> <link class="conditional" href="grid-layout.css" rel="stylesheet" /> يضيف هنا الملف basic-styling.css كل تنسيقات الصفحة المشتركة والمتوافقة لكل المتصفحات، وبالإضافة له يوجد ملفين CSS آخرين الذين أشرنا إليهما قبل قليل، الأول grid-layout.css والثاني subgrid-layout.css وسنضمن ملفًا منهما بناءً على دعم subgrid في المتصفح وسنستعمل لغة جافاسكربت JavaScript لاختبار دعمها ثم نُحدِّث قيمة href الذي يشير إليه العنصر <link> الثاني في الشيفرة السابقة أي ذي الصنف class="conditional"‎ بناء على دعم المتصفح. نضيف وسم <script></script> إلى ملف HTML في الجزء السفلي من العنصر body قبل وسم الإغلاق <‎/body> مباشرة يحوي الشيفرة التالية: const conditional = document.querySelector(".conditional"); if (CSS.supports("grid-template-columns", "subgrid")) { conditional.setAttribute("href", "subgrid-layout.css.css"); } اختبرنا في الشيفرة السابقة إن كانت الخاصية grid-template-columns تدعم القيمة subgrid باستعمال التابع CSS.support()‎. ‎@supports استخدَمتْ لغة CSS في الآونة الأخيرة آليةً لاكتشاف ميزاتها الأصيلة وهي ‎@supports باستخدام القاعدة @ التي تعمل بطريقة مشابهة لاستعلامات الوسائط Media Queries باستثناء أنها تطبّق شيفرة CSS بطريقة انتقائية بناءً على ما إذا كانت ميزة CSS مدعومة، بدلًا من تطبيق شيفرة CSS بطريقة انتقائية اعتمادًا على ميزة وسائط مثل الدقة أو عرض الشاشة أو نسبة العرض إلى الارتفاع aspect ratio. يمكننا إعادة كتابة مثالنا السابق باستخدام ‎@supports كما يلي: @supports (grid-template-columns: subgrid) { main { display: grid; grid-template-columns: repeat(9, 1fr); grid-template-rows: repeat(4, minmax(100px, auto)); } .item { display: grid; grid-column: 2 / 7; grid-row: 2 / 4; grid-template-columns: subgrid; grid-template-rows: repeat(3, 80px); } .subitem { grid-column: 3 / 6; grid-row: 1 / 3; } } تطبّق كتلة قاعدة @ تنسيق CSS فيها فقط إذا دعم المتصفح الحالي التصريح grid-template-columns: subgrid;‎. ويجب تضمين تصريح كامل (وليس مجرد اسم خاصية فقط) وعدم تضمين فاصلة منقوطة في النهاية لكي يعمل كل شرط. يتوفر لدى ‎@supports العبارات المنطقية OR و NOT و AND، فمثلًا ستطبق الكتلة التالية تنسيق التخطيط الشبكي grid العادي إن لم يكن المتصفح يدعم subgrid: @supports not (grid-template-columns: subgrid) { /* ضع القواعد هنا */ } يمكن أن يبدو ذلك ملائمًا أكثر من المثال السابق، إذ يمكننا تطبيق اكتشاف الميزات في CSS دون الحاجة إلى شيفرة جافاسكربت، ويمكننا التعامل مع جميع العبارات المنطقية في ملف CSS واحد مع تقليل طلبات HTTP، لذا هذه هي الطريقة المفضلة في اكتشاف الميزات دون اللجوء إلى جافاسكربت. شيفرة جافاسكربت رأينا مثالًا لاختبار اكتشاف ميزات جافاسكربت في وقت سابق، كما يمكن إجراء هذه الاختبارات عبر أحد الأنماط الشائعة القليلة. ضع في بالك أن بعض الميزات معروفة بعدم قابليتها للاكتشاف، ارجع إلى صفحة Undetectables بدءًا من عام 2016. إليك بعضًا من الأنماط الشائعة للميزات القابلة للاكتشاف: عضو في كائن تحقق مما إذا كان هناك تابع أو خاصية معينة (تكون عادةً نقطة دخولٍ إلى استخدام واجهة برمجة تطبيقات API أو ميزة أخرى تريد اكتشافها) موجودةً في الكائن الأب Object. رأينا في مثال سابق استخدامًا لهذا النمط عند اكتشاف دعم واجهة Geolocation وذلك بفحص وجود العضو geolocation في الكائن navigator: if ("geolocation" in navigator) { // navigator.geolocation الوصول إلى الواجهة } خاصية في عنصر أنشئ عنصرًا في الذاكرة باستخدام التابع Document.createElement()‎ ثم تحقق من وجود خاصية فيه، ويوضح هذا المثال طريقةً لاكتشاف دعم الواجهة Canvas API: function supports_canvas() { return !!document.createElement("canvas").getContext; } if (supports_canvas()) { // ‫ إنشاء عناصر canvas واستخدامها } ملاحظة: استخدمنا !! في المثال السابق وذلك لتحويل أي نوع بيانات إلى قيمة منطقية true أو false. تابع في عنصر يعيد قيمة أنشئ عنصرًا في الذاكرة باستخدام Document.createElement()‎ ثم تحقق من وجود تابع فيه، فإذا كان موجودًا، فتحقق من القيمة التي يعيدها. اطلع على اختبار اكتشاف تنسيقات الفيديو في HTML5 خاصية في عنصر تحتفظ بقيمة أنشئ عنصرًا في الذاكرة باستخدام التابع Document.createElement()‎ ثم اضبط خاصيةً على قيمة معينة، ثم تحقق من الاحتفاظ بالقيمة. ملاحظة: تُعَدّ قيمة NOT المُضاعفَة في المثال السابق (!!) طريقةً لإجبار القيمة المُعادة لتصبح قيمة منطقية مناسبة بدلًا من القيمة true أو false التي يمكن أن تؤدي إلى تحريف النتائج. اطّلع على مقال اكتشاف دعم المتصفحات لميزات HTML5 للعثور على مزيد من المعلومات، وضَع في الحسبان أنه توجد بعض الميزات التي لا يمكن اكتشافها بالرغم من كل ذلك. الميزة matchMedia تتيح ميزة جافاسكربت Window.matchMedia تشغيل اختبارات استعلام الوسائط ضمن شيفرة جافاسكربت، وتبدو كما يلي: if (window.matchMedia("(max-width: 480px)").matches) { // شغّل شيفرة جافاسكربت هنا } يستخدِم تطبيق Snapshot مثلًا هذه الميزة لتطبيق مكتبة جافاسكربت Brick بطريقة انتقائية ويستخدِمها للتعامل مع تخطيط واجهة المستخدم لتخطيط الشاشات الصغيرة فقط (480 بكسل أو أقل)، كما نستخدِم أولًا السمة media لتطبيق مكتبة Brick CSS على الصفحة إذا كان عرض الصفحة 480 بكسل أو أقل فقط: <link href="dist/brick.css" rel="stylesheet" media="all and (max-width: 480px)" /> نستخدِم بعد ذلك matchMedia()‎ في جافاسكربت عدة مرات لتشغيل دوال التنقل في مكتبة Brick مع تخطيط الشاشة الصغيرة فقط، ويمكن رؤية كل شيء دفعةً واحدةً في تخطيطات الشاشة الأوسع، لذلك لا نحتاج للتنقل بين العروض المختلفة. if (window.matchMedia("(max-width: 480px)").matches) { deck.shuffleTo(1); } استخدام مكتبة Modernizr لتطبيق اكتشاف الميزات يمكن تنفيذ اختبارات اكتشاف الميزات باستخدام تقنيات مثل التقنيات التي أوضحناها سابقًا، ويمكنك استخدام مكتبة مخصَّصة لاكتشاف الميزات لأنها تسهّل الأمور كثيرًا. تُعَد مكتبة Modernizr أساس جميع مكتبات اكتشاف الميزات، ويمكنها اكتشاف كل ما تحتاجه في أي وقت، ولنلقِ نظرةً على كيفية استخدامها. يمكنك استخدام بناء التطوير الذي يتضمن كل اختبار ممكن لاكتشاف الميزات عندما تجرّب مكتبة Modernizr، لذا نزّل بناء التطوير كما يلي: انقر على رابط بناء التطوير. انقر على زر "البناء Build" الوردي الكبير على الصفحة التي تظهر. انقر على رابط "التنزيل Download" الأعلى في مربع الحوار الذي يظهر. احفظه في مكان ما مثل المجلد الذي تنشئ أمثلتك الأخرى فيه. إذا أردت استخدام مكتبة Modernizr في عملية الإنتاج، فيمكنك الانتقال إلى صفحة التنزيل التي زرتها سابقًا ثم النقر على أزرار علامة الزائد للاطلاع على الميزات التي تريد اكتشافها فقط، وستنزّل بعد ذلك عند النقر على زر "البناء Build" بناءً مخصَّصًا يحتوي فقط على تلك الميزات التي جرى اكتشافها، مما يجعل حجم الملف أصغر بكثير. شيفرة CSS لنلقِ نظرةً على كيفية عمل مكتبة Modernizr من حيث التطبيق الانتقائي لشيفرة CSS. أنشئ أولًا نسخةً من الملفين supports-feature-detect.html و supports-styling.css ثم احفظهما بالاسم modernizr-css.html و modernizr-css.css. ثانيًا، عدّل العنصر <link> في شيفرة HTML بحيث يشير إلى ملف CSS الصحيح، ويجب تعديل العنصر <title> إلى شيء أكثر ملاءمةً: <link href="modernizr-css.css" rel="stylesheet"> ثالثًا، أضِف العنصر <script> قبل عنصر <link> لتطبيق مكتبة Modernizr على الصفحة، إذ يجب تطبيق ذلك على الصفحة قبل أيّ شيفرة CSS (أو جافاسكربت) تستخدِمها. <script src="modernizr-custom.js"></script> رابعًا، عدّل وسم الفتح <html> بحيث يبدو كما يلي: <html lang="en-us" class="no-js"> … </html> جرّب تحميل صفحتك، وستحصل على فكرة عن كيفية عمل مكتبة Modernizr مع ميزات CSS، فإذا ألقيت نظرةً على فاحص DOM الخاص بأدوات المطور في متصفحك، فسترى أنّ مكتبة Modernizr قد حدّثت قيمة صنف class العنصر <html> كما يلي: <html class="js no-htmlimports no-proximity sizes no-flash transferables applicationcache blobconstructor blob-constructor no-contextmenu (and loads of more values)"> … </html> يحتوي هذا العنصر الآن على عدد كبير من الأصناف التي تشير إلى حالة دعم ميزات التقنيات المختلفة، فإذا لم يدعم المتصفح الميزة التخطيط الشبكي grid مثلًا على الإطلاق، فسيُعطَى العنصر <html> اسم الصنف no-cssgrid، كما هنالك عدة أصناف أخرى متعلقة مثلًا بالتخطيط grid مثل cssgridlegacy أو no-cssgridlegacy بناء على دعم المتصفح للإصدار القديم legacy من التخطيط الشبكي. ملاحظة: يمكنك الاطلاع على قائمة الأصناف الكاملة وما تعنيه أسماؤها وما تقوم به بالرجوع إلى صفحة Features detected من Modernizr. لسوء الحظ لا تفحص مكتبة Modernizr دعم بعض ميزات CSS الجديدة مثل subgrid التي رأيتها للتو وغيرها ولو كانت تفعل ذلك، لكنا عدلنا مثال ‎@support السابق بالشكل التالي: main { display: grid; grid-template-columns: repeat(9, 1fr); grid-template-rows: repeat(4, minmax(100px, auto)); } .item { display: grid; grid-column: 2 / 7; grid-row: 2 / 4; grid-template-rows: repeat(3, 80px); } ‫/* ‫خاصيات المتصفحات مع خاصية subgrid الحديثة */ .csssubgrid .item { grid-template-columns: subgrid; } .csssubgrid .subitem { grid-column: 3 / 6; grid-row: 1 / 3; } ‫/* ‫الإجراءات الاحتياطية للمتصفحات التي لا تدعم خاصية subgrid الحديثة */ .no-csssubgrid .subitem { display: flex; flex: 33%; } يمكنك استهداف المتصفحات التي تدعم أو التي لا تدعم ميزة معينة باستخدام محددات أحفاد معينة بسبب وضع جميع أسماء الأصناف في العنصر <html>. لذلك طبّقنا هنا المجموعة العليا من القواعد فقط على المتصفحات التي تدعم subgrid ومجموعة القواعد السفلية فقط على المتصفحات التي لا تدعمها. ملاحظة: ضع في الحسبان أنّ جميع اختبارات ميزات HTML وجافاسكربت الخاصة بمكتبة Modernizr تُذكَر في أسماء الأصناف، لذلك يمكنك تطبيق شيفرة CSS بطريقة انتقائية بناءً على دعم المتصفح لميزات HTML أو جافاسكربت إذا لزم الأمر. شيفرة جافاسكربت مكتبة Modernizr مُهيَّأة جيدًا لتطبيق اكتشاف ميزات جافاسكربت من خلال توفير كائن Modernizr العام للصفحة التي تُطبَّق عليها، ويحتوي هذا الكائن على نتائج اكتشاف الميزات بوصفها خاصيات true أو false. حمّل المثال modernizr-css.html في متصفحك، ثم حاول الانتقال إلى طرفية جافاسكربت واكتب Modernizr.‎ متبوعةً ببعض أسماء هذه الأصناف كما يلي: Modernizr.flexbox Modernizr.xhr2 Modernizr.fetch ستعيد الطرفية قيم true أو false للإشارة إلى ما إذا كان متصفحك يدعم هذه الميزات أم لا. لنلقِ نظرةً على مثال لتوضيح كيفية استخدامك لتلك الخاصيات: أنشئ أولًا نسخةً محليةً من الملف modernizr-js.html. ثانيًا، اربط مكتبة Modernizr بشيفرة HTML باستخدام العنصر <script> كما فعلنا سابقًا ثم ضع هذا العنصر قبل العنصر <script> الموجود مسبقًا الذي يربط واجهة Google Maps API بالصفحة. املأ بعد ذلك نص العنصر البديل YOUR-API-KEY في عنصر <script> الثاني بمفتاح Google Maps API صالح، ويمكنك الحصول على مفتاح من خلال تسجيل الدخول إلى حساب Google، والانتقال إلى صفحة الحصول على مفتاح أو المصادقة ثم انقر على الزر الأزرق "الحصول على مفتاح Get a Key" واتبع التعليمات. أخيرًا، أضِف عنصر <script> آخر في الجزء السفلي من العنصر <body> وقبل وسم الإغلاق <‎/body> مباشرةً ثم ضع السكربت التالي ضمن الوسوم: if (Modernizr.geolocation) { navigator.geolocation.getCurrentPosition(function(position) { let latlng = new google.maps.LatLng(position.coords.latitude,position.coords.longitude); let myOptions = { zoom: 8, center: latlng, mapTypeId: google.maps.MapTypeId.TERRAIN, disableDefaultUI: true } let map = new google.maps.Map(document.getElementById("map_canvas"), myOptions); }); } else { const para = document.createElement('p'); para.textContent = 'Argh, no geolocation!'; document.body.appendChild(para); } جرب مثالك واستخدِم اختبار Modernizr.geolocation للتحقق مما إذا كان المتصفح الحالي يدعم تحديد الموقع الجغرافي، فإذا كان الأمر كذلك، فسنشغّل الشيفرة البرمجية التي تحدد موقع جهازك الحالي وترسمه على خريطة جوجل. الخلاصة لقد غطينا في هذا المقال اكتشاف دعم المتصفحات للميزات وعرضنا المفاهيم الرئيسية ووضحنا كيفية تطبيق اختبارات اكتشاف ميزاتك واستخدام مكتبة Modernizr لتطبيق الاختبارات بسهولة أكبر، وسنوضح في المقال التالي الاختبارات الآلية. ترجمة -وبتصرُّف- للمقال Implementing feature detection. اقرأ أيضًا مدخل إلى اختبار مشاريع الويب للتوافق مع المتصفحات استراتيجيات اختبارات مشاريع الويب للتوافق مع المتصفحات اكتشاف دعم المتصفحات لميزات HTML5

سننتقل في هذا المقال إلى إجراء اختبارات التوافق مع المتصفحات Cross Browser Testing والنظر في تحديد الجمهور المستهدف مثل المتصفحات والأجهزة والمجالات الأخرى التي يجب التأكد من اختبارها واستراتيجيات اختبار Lo-fi مثل الحصول على مجموعة من الأجهزة وبعض الآلات الافتراضية وإجراء الاختبارات المخصَّصة Ad-hoc عند الحاجة، واستراتيجيات التقنيات المتقدمة مثل الاختبارات الآلية واستخدام تطبيقات الاختبار المخصَّصة، والاختبار مع مجموعات المستخدِمين. المتطلبات الأساسية: يجب أن تتعلم أساسيات لغات HTML وCSS وجافاسكربت JavaScript، وأن يكون لديك فكرة عن المبادئ عالية المستوى لاختبار التوافق مع المتصفحات. الهدف: اكتساب فهم للمفاهيم عالية المستوى المتضمّنة في اختبار مشاريع الويب للتوافق مع المتصفحات. هل يجب اختبار كل شيء؟ يجب وضع قائمة بالمتصفحات التي تريد اختبارها عند إجراء اختبار التوافق مع المتصفحات، إذ لا توجد طريقة يمكنك من خلالها اختبار مجموعة المتصفحات والأجهزة التي يمكن أن يستخدِمها المستخدِمون لعرض موقعك، فهناك عدد كبير جدًا منها مع ظهور متصفحات وأجهزة أخرى جديدة طوال الوقت، لذا يجب عليك محاولة التأكد من أنّ موقعك يعمل على أهم المتصفحات والأجهزة المُستهدَفة، ثم أنشئ شيفرة دفاعية Defensive Code لمنح موقعك أكبر قدر من الدعم الذي يمكن توقعه. نعني هنا بالشيفرة الدفاعية محاولة بناء تراجعات ذكية بحيث إذا لم تعمل الميزة أو التنسيق في المتصفح، فسيكون الموقع قادرًا على الرجوع إلى إصدار أقدم ولكنه لا يزال يوفر تجربة مستخدِم مقبولة مع توفّر المعلومات الأساسية حتى إذا لم يكن يبدو جيدًا تمامًا. هدفنا هو بناء مخطط للمتصفحات/الأجهزة الذي يمكنك الرجوع إليه أثناء الاختبار، كما يمكنك جعل هذا المخطط بسيطًا أو معقدًا كما يحلو لك، إذ تتمثل الطريقة الشائعة لذلك في إنشاء درجات متعددة من مستوى الدعم مثلًا كما يلي: الدرجة A: المتصفحات المشهورة والحديثة والمعروفة بقدرتها والتي يجب أن تختبرها بدقة وتقدّم لها الدعم الكامل. الدرجة B: المتصفحات الأقدم ذات الإمكانات الأقل التي يجب اختبارها وتقديم تجربة أساسية تتيح الوصول الكامل إلى المعلومات والخدمات الأساسية. الدرجة C المتصفحات النادرة وغير المعروفة التي يمكنك ألّا تختبرها، إذ يجب أن يعمل موقعك بالكامل على الأقل مع الاحتياطات التي توفرها الشيفرة الدفاعية. سننشئ مخطط دعم بهذا الشكل في الأقسام التالية. ملاحظة: جعل ياهو Yahoo هذا الأسلوب شائعًا في البداية من خلال استخدام أسلوب دعم المتصفح المُصنَّف Graded Browser Support. التخمينات المتعلمة يمكنك تسميتها بالافتراضات، فهي لا تُعَدّ نهجًا علميًا دقيقًا، ولكن ستكون لديك بصفتك شخصًا لديه خبرة في مجال الويب فكرةً جيدةً عن بعض المتصفحات التي يجب عليك اختبارها على الأقل، ويمكن أن يشكّل ذلك أساسًا جيدًا لمخطط الدعم. إذا كنت من سكان أوروبا الغربية أو أمريكا الشمالية مثلًا، فستعرف أن الكثير من الأشخاص يستخدِمون الحواسيب المكتبية أو المحمولة التي تعمل باستخدام نظام ويندوز وماك Mac بحيث تكون المتصفحات الرئيسية هي كروم Chrome وفايرفوكس Firefox وسفاري Safari و IE و Edge، وتريد مثلًا اختبار أحدث إصدارات المتصفحات الثلاثة الأولى فقط، حيث تتلقى هذه المتصفحات تحديثات منتظمة، ويمكن أن ترغب في اختبار إصدارَي Edge و IE الأخيرين، وبالتالي يجب أن تنتقل هذه المتصفحات إلى مستوى الدرجة A. يستخدِم الكثير من الأشخاص نظامَي iOS وأندرويد Android، لذا لا بد أنك ترغب في اختبار أحدث إصدارات iOS Safari، وآخر إصدارات متصفح Android القديم، والمتصفحين Chrome و Firefox لنظامَي التشغيل iOS و Android، كما يجب عليك اختبارها بطريقة مثالية على كل من الهاتف والجهاز اللوحي للتأكد من أن التصميمات المتجاوبة مع الشاشات تعمل بنجاح. يمكن أن يكون عددٌ من الأشخاص يستخدِمون المتصفح IE 9 الذي يُعَدّ قديمًا وخارج نطاق الدعم والتطوير من مايكروسوفت ويمتلك إمكانات أقل، لذلك سنضعه في الدرجة B. يعطينا ذلك مخطط الدعم التالي حتى الآن: الدرجة A: تتضمن Chrome و Firefox لنظامَي التشغيل Windows و Mac، و Safari لنظام التشغيل Mac، وEdge لنظام التشغيل ويندوز، و iOS Safari لأجهزة iPhone و iPad، ومتصفح Android القديم (الإصداران الأخيران) على الهاتف أو الجهاز اللوحي، و Chrome و Firefox لنظام Android (الإصداران الأخيران) على الهاتف اللوحي. الدرجة B: تتضمن IE لنظام التشغيل ويندوز و Opera Mini. الدرجة ? غير متوفر. إذا كنت تعيش في مكان آخر أو تعمل على موقع يخدّم مكانًا آخر مثل بلدان أو مناطق معينة، فيُحتمَل أن يكون لديك متصفحات مختلفة لاختبارها. إحصائيات دعم المتصفح أحد الإجراءات المفيدة التي يمكنك استخدامها لاختبار المتصفحات هو إحصائيات دعم المتصفح، وهناك عدد من المواقع التي تقدم مثل هذه الإحصائيات مثل: Statcounter. استخدام التحليلات يأتي مصدر البيانات الأدق من تطبيقات التحليلات مثل Google Analytics الذي يمنحك إحصائيات دقيقة حول المتصفحات التي يستخدِمها الأشخاص لتصفح موقعك، ويعتمد ذلك على أن يكون لديك موقع مسبقًا لاستخدام هذا التطبيق عليه، لذلك لا يُعَدّ جيدًا للمواقع الجديدة كليًا. لكن يمكن أن يكون سجل التحليلات مفيدًا في العثور على إحصائيات الدعم للتأثير على إصدار جديد من موقع الشركة أو الميزات الجديدة التي تضيفها إلى موقع قائم، ويُعَدّ ذلك -إذا توفّر- أدق بكثير من إحصائيات المتصفح العامة التي ذكرناها سابقًا. كما يمكنك التفكير في استخدام منصات التحليلات مفتوحة المصدر التي تركز على الخصوصية مثل Open Web Analytics و Matomo التي تتوقع منك استضافة منصة التحليلات بنفسك. إعداد Google Analytics يمكنك إعداد Google Analytics باتباع الخطوات التالية: ستحتاج أولًا إلى حساب جوجل لتسجيل الدخول إلى Google Analytics. اختر خيار Google Analytics للويب وانقر على زر التسجيل Sign Up. أدخِل تفاصيل موقعك أو تطبيقك في صفحة التسجيل، حيث يكون الإعداد بسيطًا، ولكن أهم حقل هو عنوان URL لموقع الويب الذي يجب أن يكون عنوان URL الجذر لموقعك أو تطبيقك. اضغط بعد ذلك على زر الحصول على معرّف التتبّع Get Tracking ID ثم اقبل شروط الخدمة التي ستظهر. توفِّر لك الصفحة التالية بعض مقتطفات الشيفرة البرمجية وإرشادات أخرى، فذا كان لديك موقع ويب أساسي، فما عليك فعله هو نسخ كتلة شيفرة تتبع موقع الويب Website Tracking ولصقها في جميع الصفحات التي تريد تتبعها باستخدام Google Analytics على موقعك، كما يمكنك وضع مقتطفات الشيفرة البرمجية بعد وسم الإغلاق <‎/body> أو في مكان آخر مناسب لا يتداخل مع شيفرة تطبيقك. حمّل التغييرات على خادم التطوير أو في أيّ مكان آخر تحتاج فيه لشيفرتك البرمجية. يجب أن يكون موقعك جاهزًا الآن لبدء إصدار تقارير بالبيانات التحليلية. دراسة البيانات التحليلية يجب الآن أن تكون قادرًا على العودة إلى صفحة تحليلات الويب Analytics Web والاطلاع على البيانات التي جمعتها حول موقعك، ويجب بالطبع أن تنتظر قليلًا من الوقت لجمع بعض البيانات. يُفترَض أن ترى تبويب إعداد التقارير Reporting افتراضيًا كما يلي: هناك قدر هائل من البيانات التي يمكنك الاطلاع عليها باستخدام Google Analytics مثل التقارير المخصَّصة ضمن فئات مختلفة وغير ذلك، كما يجب النظر إلى الخيارات المختلفة على الجانب الأيسر ومعرفة أنواع البيانات التي يمكنك اكتشافها، إذ يمكنك مثلًا معرفة المتصفحات وأنظمة التشغيل التي يستخدمها المستخدمون من خلال تحديد خيار القائمة Audience ثم Technology ثم Browser & OS من القائمة اليسرى. ملاحظة: يجب أن تكون حذرًا عند استخدام Google Analytics إذا كان لديك شيء مثل النتيجة "لا يوجد لدينا مستخدِمون للمتصفح Firefox Mobile" التي يمكن أن تقودك إلى عدم دعم Firefox mobile، ولكن لن يكون لديك أيٌّ من مستخدِمي المتصفح Firefox Mobile إذا كان موقعك معطَّلًا على متصفح Firefox mobile بالأصل. هناك أمور أخرى يجب عليك تضمينها، إذ يجب بالتأكيد تضمين سهولة الوصول Accessibility على أساس شرط اختبار من الدرجة A، وسنغطي بالضبط ما يجب عليك اختباره في مقال معالجة مشاكل الشمولية الشائعة للتوافق مع المتصفحات لاحقًا. إذا أردت إنشاء شبكة داخلية Intranet خاصة بالشركة لتوصيل أرقام المبيعات للمديرين مع تزويد جميع المديرين بهواتف ويندوز مثلًا، فيمكن أن ترغب في إعطاء الأولوية لدعم المتصفح IE على الهواتف المحمولة. مخطط الدعم النهائي سيكون مخطط الدعم النهائي بالصورة التالية: الدرجة A: تتضمن Chrome و Firefox لنظامَي التشغيل Windows و Mac، و Safari لنظام التشغيل Mac و Edge لنظام التشغيل Windows (الإصداران الأخيران) و iOS Safari لأجهزة iPhone و iPad ومتصفح Android القديم (الإصداران الأخيران) على الهاتف والجهاز اللوحي و Chrome و Firefox لنظام Android (الإصداران الأخيران) على الهاتف اللوحي، مع النجاح في اختبارات الشمولية الشائعة. الدرجة B: تتضمن IE 8 و9 لنظام التشغيل Windows و Opera Mini. الدرجة ? تتضمن Opera والمتصفحات الحديثة المتخصصة الأخرى. ماذا يجب أن نختبر؟ إذا كان لديك إضافة جديدة إلى قاعدة شيفرتك البرمجية والتي يجب اختبارها، فيجب كتابة قائمة بمتطلبات الاختبار التي يجب اجتيازها قبل أن تبدأ الاختبار حتى تُقبَل، ويمكن أن تكون هذه المتطلبات مرئيةً أو وظيفيةً، إذ يجتمع هذان النوعان لإنشاء ميزة موقع ويب قابلة للاستخدام. لنفترض المثال التالي (اطلع على الشيفرة البرمجية): يمكن كتابة معايير الاختبار لهذه الميزة على النحو التالي: الدرجة A و B: يجب أن يكون الزر قابلًا للتنشيط باستخدام آلية التحكم الأساسية للمستخدِم، كما يجب أن يشمل ذلك مستخدِمي الفأرة ولوحة المفاتيح وشاشات اللمس. يجب أن يؤدي تبديل الزر إلى ظهور أو إخفاء مربع المعلومات. يجب أن يكون النص مقروءًا. يجب أن يتمكن المستخدِمون المعاقون بصريًا الذين يستخدِمون قارئات الشاشة من الوصول إلى النص. الدرجة A: يجب أن يتحرك مربع المعلومات بسلاسة عندما يظهر أو يختفي. يجب أن يظهر التدرج اللوني وظل النص لتحسين مظهر المربع. لاحظ في هذا المثال أنّ النص لن يعمل في المتصفح IE8، ويُعَدّ ذلك مشكلةً وفقًا لمخطط الدعم ويجب إصلاحها باستخدام مكتبة اكتشاف الميزات مثلًا لتطبيق الوظيفة بطريقة مختلفة إذا لم يدعم المتصفح انتقالات CSS، كما يمكن ألّا يكون الزر قابلًا للاستخدام لمستخدِمي لوحة المفاتيح فقط، ويجب معالجة ذلك من خلال استخدام شيفرة جافاسكربت لتطبيق التحكم بلوحة المفاتيح لتبديل الزر أو باستخدام طريقة أخرى. تُعَدّ هذه المعايير للاختبار مفيدةً للأسباب التالية: تعطي مجموعةً من الخطوات التي يجب اتباعها عند إجراء الاختبارات. يمكن تحويلها بسهولة إلى مجموعات من التعليمات لمجموعات المستخدِمين لاتباعها عند إجراء الاختبارات مثل "حاول تنشيط الزر باستخدام الفأرة ثم باستخدام لوحة المفاتيح …". يمكنها توفير أساس لكتابة الاختبارات الآلية، ويمكن كتابة مثل هذه الاختبارات بسهولة إذا عرفتَ بالضبط ما تريد اختباره وما هي شروط النجاح. إنشاء مختبر لإجراء الاختبارات أحد الخيارات لإجراء اختبارات المتصفحات هو إجراء الاختبار بنفسك من خلال استخدام مجموعة من الأجهزة الحقيقية الفعلية والبيئات المقلِّدة باستخدام إما مقلِّد أو محاكٍ Emulator أو آلة افتراضية. الأجهزة الحقيقية يُفضَّل أن يكون لديك جهاز حقيقي يشغّل المتصفح الذي تريد اختباره، وهذا يوفر أكبر قدر من الدقة من حيث السلوك وتجربة المستخدِم الإجمالية، كما يمكن استخدام جهاز منخفض المستوى ليكون مختبرًا مقبولًا كما يلي: جهاز Mac مثبَّتٌ عليه المتصفحات التي تريد اختبارها، ويمكن أن يشمل ذلك المتصفحات Firefox و Chrome و Opera و Safari. حاسوب يعمل بنظام ويندوز مثبَّت عليه المتصفحات التي يجب اختبارها، ويمكن أن يشمل ذلك Edge أو IE و Chrome و Firefox و Opera. هاتف وجهاز لوحي يعملان بنظام Android عالي المواصفات مع تثبيت المتصفح الذي تريد اختباره، ويمكن أن يشمل ذلك المتصفحات Chrome و Firefox و Opera Mini لنظام Android، بالإضافة إلى متصفح Android الأصلي القديم. هاتف وجهاز لوحي يعمل بنظام iOS عالي المواصفات مع تثبيت المتصفحات التي تريد اختبارها، ويمكن أن يشمل ذلك المتصفحات iOS Safari و Chrome و Firefox و Opera Mini لنظام التشغيل iOS. الخيارات التالية هي خيارات جيدة أيضًا إذا كان بإمكانك الحصول عليها: حاسوب يعمل بنظام لينكس Linux في حالة احتياجك لاختبار الزلات البرمجية الخاصة بإصدارات لينكس للمتصفحات، إذ يستخدِم مستخدِمو نظام لينكس المتصفحات Firefox و Opera و Chrome، فإذا كان لديك جهاز واحد فقط متاح، فيمكنك التفكير في إنشاء جهاز ذي إقلاع مزدوج Dual Boot يعمل بنظام التشغيل لينكس Linux وويندوز Windows على قطاعات منفصلة، حيث يسهّل مُثبِّت نظام أبونتو Ubuntu هذا الإعداد. هواتف محمولة منخفضة المواصفات، بحيث يمكنك اختبار أداء الميزات مثل الحركة على معالجات أقل قوة. كما يمكن أن يكون جهاز عملك الرئيسي مكانًا لتثبيت أدوات أخرى لأغراض محددة مثل أدوات تدقيق سهولة الوصول وقارئات الشاشة والمحاكيات أو الآلات الافتراضية Virtual Machines. تمتلك بعض الشركات الكبيرة مختبرات للأجهزة التي تحتوي على مجموعة كبيرة جدًا من الأجهزة المختلفة، مما يمكّن المطورين من تعقب الأخطاء في مجموعات محددة جدًا من المتصفحات والأجهزة. الشركات الصغيرة والأفراد غير قادرين على تحمّل تكلفة مثل هذا المختبر المعقد، لذلك يميلون إلى التعامل مع المختبرات الصغيرة والمحاكيات والآلات الافتراضية وتطبيقات الاختبار التجارية. ملاحظة: هناك بعض الجهود المبذولة لإنشاء مختبرات عامة لاختبار سهولة وصول الأجهزة، إذ يجب وضعها في الحسبان، فهناك عدد من الأدوات المفيدة التي يمكنك تثبيتها على جهازك لتسهيل اختبار سهولة الوصول، ولكننا سنغطيها لاحقًا. المحاكيات Emulators تُعَدّ المحاكيات أو المقلّدات برامجًا تُشغَّل ضمن حاسوبك وتقلّد جهازًا أو حالة جهاز معيّن من نوع ما، مما يسمح بإجراء بعض اختباراتك بصورة ملائمة أكثر من الاضطرار إلى العثور على مجموعة معينة من العتاد أو البرمجيات لاختبارها. يمكن أن يكون المحاكي بسيطًا مثل اختبار حالة الجهاز، فإذا أردت مثلًا إجراء بعض الاختبارات السريعة وغير المتوقَّعة لاستعلامات وسائط Media Queries العرض أو الارتفاع للتصميم المتجاوب مع الشاشات، فيمكنك استخدام وضع التصميم المتجاوب Responsive Design Mode في فايرفوكس Firefox، كما يحتوي المتصفح Safari على وضع مشابه يمكن تفعيله من خلال الانتقال إلى قائمة Safari ثم التفضيلات Preferences وتحديد قائمة إظهار التطوير Show Develop، ثم خيار التطوير Develop ثم إدخال وضع التصميم المتجاوب Enter Responsive Design Mode، كما يحتوي Chrome على شيء مشابه أيضًا هو وضع الجهاز Device mode. يجب عليك في كثير من الأحيان تثبيت محاكٍ، حيث تكون الأجهزة/المتصفحات الأكثر شيوعًا التي تريد اختبارها على هذه المحاكيات هي كما يلي: تُعَدّ بيئة التطوير Android Studio IDE الرسمية لتطوير تطبيقات Android ثقيلة الوزن بعض الشيء لمجرد اختبار مواقع الويب على Google Chrome أو متصفح Android القديم، ولكنها تأتي مع محاكٍ قوي، فإذا أردت شيئًا خفيف الوزن قليلًا، فإنّ المحاكي Andy هو خيار مقبول يعمل على كل من نظامَي Windows و Mac. توفِّر Apple تطبيقًا يسمى Simulator يعمل على بيئة تطوير XCode، ويحاكي أجهزة iPad و iPhone و Apple Watch و Apple TV، ويتضمن ذلك متصفح iOS Safari الأصلي، ولكنه للأسف يعمل فقط على أجهزة Mac. يمكنك في أغلب الأحيان العثور على محاكيات Simulators لبيئات الهواتف المحمولة الأخرى مثل: يمكنك محاكاة المتصفح Opera Mini بمفرده إذا أردت اختباره. تتوفر محاكيات لأنظمة تشغيل Windows Mobile مثل المحاكي Windows Phone لنظام Windows Phone 8 والمحاكي Microsoft Emulator لنظام التشغيل Windows 10 Mobile، حيث تعمل هذه المحاكيات على نظام ويندوز فقط. ملاحظة: تتطلب العديد من المحاكيات استخدام آلة افتراضية، حيث تُعطَى الإرشادات لذلك في أغلب الأحيان و/أو يُدمَج استخدام الآلة الافتراضية في مثبِّت المحاكي. الآلات الافتراضية تُعَدّ الآلات الافتراضية تطبيقات تعمل على حاسوبك وتسمح بتشغيل عمليات المحاكاة لأنظمة التشغيل بأكملها، حيث يكون لكل نظام قسمه الخاص من القرص الصلب الافتراضي، إذ يُمثَّل في أغلب الأحيان بملف واحد كبير موجود على القرص الصلب للجهاز المضيف، كما يتوفر عدد من تطبيقات الآلات الافتراضية الشائعة مثل Parallels و VMWare و Virtual Box المجاني. ملاحظة: يجب أن يكون لديك مساحة كبيرة على القرص الصلب لتشغيل عمليات محاكاة الآلة الافتراضية، إذ يمكن أن يستهلك كل نظام تشغيل تريد محاكاته قدرًا كبيرًا من الذاكرة، كما يمكنك اختيار مساحة القرص الصلب التي تريدها لكل تثبيت، حيث يمكنك الحصول على 10 جيجابايتات، ولكن توصي بعض المصادر بمساحة تصل إلى 50 جيجابايت أو أكثر ليعمل نظام التشغيل على نحو موثوق، كما توفِّر معظم تطبيقات الآلات الافتراضية مجموعة من الخيارات الجيدة مثل إنشاء قرص صلب مخصَّص ديناميكيًا يكبر ويصغر حسب الحاجة. تحتاج ما يلي لاستخدام برنامج Virtual Box: احصل على قرص أو صورة مثل ملف ISO لتثبيت لنظام التشغيل الذي تريد محاكاته، فإن Virtual Box غير قادر على توفير ذلك، لأنها مثل أنظمة تشغيل ويندوز والتي تُعَدّ منتجات تجارية لا يمكن توزيعها مجانًا. نزِّل برنامج التثبيت المناسب لنظام التشغيل لديك ثم ثبّته. افتح التطبيق وسيظهر ما يلي: اضغط على زر "جديد New" أعلى الزاوية اليسرى لإنشاء آلة افتراضية جديدة. اتبع التعليمات واملأ مربعات الحوار التالية بطريقة مناسبة كما يلي: أدخِل اسمًا للآلة الافتراضية الجديدة. اختر نظام التشغيل والإصدار الذي تريد تثبيته. حدّد مقدار الذاكرة RAM التي يجب تخصيصها، إذ نوصي باستخدام 2048 ميجابايت أو 2 جيجابايت. أنشئ قرصًا صلبًا افتراضيًا، واختر الخيارات الافتراضية عبر مربعات الحوار الثلاثة التي تحتوي على "إنشاء قرص صلب افتراضي الآن Create a virtual hard disk now" و VDI -أي صورة قرص افتراضي Virtual Disk Image- و"التخصيص الديناميكي Dynamically Allocated". اختر موقع وحجم ملف القرص الصلب الافتراضي، واختر اسمًا وموقعًا معقولًا للاحتفاظ به، وحدِّد الحجم إلى حوالي 50 جيجابايت أو بالمقدار الذي ترغب فيه. يجب الآن أن يظهر المربع الافتراضي الجديد في القائمة اليسرى لنافذة واجهة مستخدِم Virtual Box الرئيسية، ويمكنك النقر نقرًا مزدوجًا لفتحه وسيبدأ تشغيل الآلة الافتراضية، ولكن لن يُثبَّت نظام التشغيل OS عليه بعد، إذ يجب توجيه مربع الحوار إلى صورة أو قرص التثبيت، وسيُشغَّل على خطوات لتثبيت نظام التشغيل تمامًا كما هو الحال على أيّ جهاز حقيقي. تحذير: يجب التأكد من توفر صورة نظام التشغيل التي تريد تثبيتها على الآلة الافتراضية وتثبيتها مباشرةً، فإذا ألغيت العملية في هذه المرحلة، فيمكن أن يؤدي ذلك إلى جعل الآلة الافتراضية غير قابلة للاستخدام، وبالتالي يجب حذفها وإنشاؤها مرةً أخرى. يجب بعد اكتمال العملية أن يكون لديك آلة افتراضية تشغّل نظام تشغيل ضمن نافذة على الحاسوب المضيف. يمكنك التعامل مع تثبيت نظام التشغيل الافتراضي تمامًا كما تفعل مع أيّ تثبيت حقيقي، إذ يمكنك مثلًا تثبيت برنامج مكافحة الفيروسات لحمايته من الفيروسات بالإضافة إلى تثبيت المتصفحات التي تريد اختبارها. يُعَدّ امتلاك آلات افتراضية متعددة مفيدًا جدًا خاصة بالنسبة لاختبار Windows IE/Edge، إذ لا يمكنك على نظام ويندوز تثبيت إصدارات متعددة من المتصفح الافتراضي مع بعضها بعضًا، لذلك يمكن أن ترغب في إنشاء مكتبة من الآلات الافتراضية للتعامل مع اختبارات مختلفة حسب الحاجة مثل: Windows 10 مع Edge 14. Windows 10 مع Edge 13. ملاحظة: هناك شيء جيد آخر تتمتع به الآلات الافتراضية، وهو أن صور القرص الصلب الافتراضي مستقلة بذاتها إلى حد ما، فإذا كنت تعمل ضمن فريق، فيمكنك إنشاء صورة قرص افتراضي واحدة ثم نسخها وتمريرها، لذا تأكد فقط من أنه لديك التراخيص المطلوبة لتشغيل جميع نسخ ويندوز أو أيّ شيء آخر تريد تشغيله إذا كان منتجًا مرخصًا. الاختبارات الآلية والتطبيقات التجارية يمكنك التخلص من معاناة اختبار المتصفحات باستخدام نظام اختبار آلي، إذ يتطلب إعداد نظام اختبار آلي مثل التطبيق Selenium بعض الإعداد، ولكنه يستحق هذا العناء عند تشغيله، كما توجد أدوات تجارية متاحة مثل Sauce Labs و Browser Stack و LambdaTest المفيدة في هذا المجال دون الحاجة إلى القلق بشأن الإعداد إن أردت استثمار بعض المال في الاختبار، وهناك بديل آخر وهو استخدام أدوات الاختبار الآلية بدون شيفرة برمجية مثل Endtest. اختبار المستخدمين سننهي هذا المقال بالحديث قليلًا عن اختبار المستخدِم User Testing الذي يمكن أن يكون خيارًا جيدًا إذا كان لديك مجموعة مستخدِمين راغبين في اختبار وظائفك الجديدة، وضَع في الحسبان أنّ هذا الاختبار يمكن أن يكون بسيطًا أو معقدًا حسب رغبتك، إذ يمكن أن تكون مجموعة المستخدِمين مجموعةً من الأصدقاء أو الزملاء أو مجموعة من المتطوعين بدون أجر أو بأجر اعتمادًا على ما إذا كان لديك أية أموال تريد إنفاقها على الاختبار. سينظر المستخدموِن إلى الصفحة أو العرض الذي يحتوي على الوظيفة الجديدة الموجودة على خادم تطوير، لذا لا تضع الموقع النهائي أو تجعله حيًا مباشرًا حتى تنتهي من الاختبار، ويجب أن تجعلهم يتبعون بعض الخطوات ويعطون تقريرًا بالنتائج التي يحصلون عليها، ويُعَدّ تقديم مجموعة من الخطوات التي تسمى سكربتًا في بعض الأحيان أمرًا مفيدًا بحيث تحصل على نتائج أكثر وثوقية فيما يتعلق بما تحاول اختباره، كما يمكن تحويل معايير الاختبار المفصلة إلى خطوات يجب اتباعها مثل الخطوات التالية التي تصلح لمستخدِم يمكنه الرؤية: انقر على زر علامة الاستفهام باستخدام الفأرة على حاسوبك عدة مرات وحدّث نافذة المتصفح. حدّد زر علامة الاستفهام وفعّله باستخدام لوحة المفاتيح على حاسوبك عدة مرات. اضغط على زر علامة الاستفهام عدة مرات على جهازك الذي يعمل باللمس. يجب أن يؤدي تبديل الزر إلى ظهور أو إخفاء مربع المعلومات. هل يحصل ذلك في جميع الحالات الثلاث السابقة؟ هل النص مقروء؟ هل يتحرك مربع المعلومات بسلاسة عندما يظهر أو يختفي؟ كما تُعَدّ الإجراءات التالية مفيدة عند إجراء الاختبارات: اضبط ملف تعريف منفصل للمتصفح مع تعطيل ملحقات هذا المتصفح، وأجرِ اختباراتك في هذا الملف التعريفي. استخدِم وظيفة وضع التصفح الخاص أو المتخفي للمتصفح مثل التصفح الخاص Private Browsing في فايرفوكس Firefox ووضع التصفح المتخفي Incognito Mode في كروم Chrome عند إجراء الاختبارات حتى لا تُحفَظ أشياء مثل ملفات الارتباط Cookies والملفات المؤقتة. صُمِّمت هذه الخطوات للتأكد من أنّ المتصفح الذي تختبره "نقي" قدر الإمكان، أي أنه لا يوجد شيء مُثبَّت يمكن أن يؤثر على نتائج الاختبارات. ملاحظة: يوجد خيار آخر مفيد من استراتيجية اختبار Lo-fi إذا كان لديك الأجهزة المتاحة، وهو اختبار موقع الويب على الهواتف أو الأجهزة الأخرى منخفضة الإمكانات، فهناك فرصة أكبر لتباطؤ الموقع نظرًا لأن المواقع تكبر وتزيد فيها التأثيرات مع الوقت، لذلك عليك أن تبدأ في منح الأداء مزيدًا من الاهتمام. ستؤدي محاولة تشغيل وظائفك على جهاز منخفض الإمكانات إلى زيادة احتمالية أن تكون التجربة جيدةً على الأجهزة المتطورة. ملاحظة: توفِّر بعض بيئات التطوير من جانب الخادم آليات مفيدةً لنشر تغييرات الموقع لمجموعة محددة من المستخدِمين فقط، مما يوفر آلية مفيدة للحصول على ميزة تختبرها مجموعة من المستخدِمين دون الحاجة إلى استخدام خادم تطوير منفصل، ومن الأمثلة على ذلك الميزة Django Waffle Flags. الخلاصة يجب أن يكون لديك الآن فكرة جيدة عما يمكنك تطبيقه لتحديد جمهورك المستهدَف أو قائمة المتصفحات المستهدفة، ثم إجراء اختبار التوافق مع المتصفحات على تلك القائمة بفعالية، وسنوجِّه اهتمامنا في المقال التالي إلى مشاكل الشيفرة البرمجية الفعلية التي يكشف عنها الاختبار بدءًا من مشاكل HTML و CSS. ترجمة -وبتصرُّف- للمقال Strategies for carrying out testing. اقرأ أيضًا مدخل إلى اختبار مشاريع الويب للتوافق مع المتصفحات أدوات مطوري الويب المدمجة في المتصفحات

سنركِّز في هذه السلسلة تعلم تطوير الويب من المقالات على اختبار مشاريع الويب للتوافق مع المتصفحات Cross Browser Testing، حيث سنحدِّد الجمهور المستهدَف مثل معرفة المستخدِمين والمتصفحات والأجهزة التي يجب أخذها في الحسبان، وسنتعلّم كيفية إجراء الاختبار والمشاكل الرئيسية التي ستواجهها مع أنواع مختلفة من الشيفرات البرمجية وكيفية التخفيف من هذه المشاكل، كما سنتعرّف على الأدوات المفيدة لمساعدتك على اختبار المشاكل وإصلاحها وكيفية استخدام الاختبارات الآلية لتسريع عملية الاختبار. المتطلبات الأساسية: يجب أن تتعلم أساسيات لغات HTML وCSS وجافاسكربت JavaScript أولًا قبل محاولة استخدام الأدوات التي سنشرحها لاحقًا. تتألف هذه السلسلة من المقالات التالية: مدخل إلى اختبار مشاريع الويب للتوافق مع المتصفحات (المقال الحالي): سنقدم في هذا المقال نظرةً عامةً حول موضوع اختبار مشاريع الويب للتوافق مع المتصفحات، وسنجيب على أسئلة مثل "ما هو اختبار التوافق مع المتصفحات؟" و"ما هي أكثر أنواع المشاكل شيوعًا التي ستواجهها؟" و"ما هي الطرق الرئيسية لاختبار المشاكل وتحديدها وإصلاحها؟". استراتيجيات اختبارات مشاريع الويب للتوافق مع المتصفحات: سننتقل بعد ذلك إلى إجراء الاختبارات، وتحديد الجمهور المستهدَف مثل المتصفحات والأجهزة والمجالات الأخرى التي يجب التأكد من اختبارها، وتحديد استراتيجيات اختبار Lo-fi مثل الحصول على مجموعة من الأجهزة وبعض الآلات الافتراضية وإجراء اختبارات مخصصة Ad-hoc عند الحاجة، واستراتيجيات التقنيات المتقدمة مثل الاختبارات الآلية واستخدام تطبيقات الاختبار المخصَّصة، وإجراء الاختبارات مع مجموعات المستخدِمين. معالجة المشاكل الشائعة للتوافق مع المتصفحات في شيفرة HTML وCSS: سننظر بعد ذلك على وجه التحديد في المشاكل الشائعة للتوافق مع المتصفحات التي ستواجهها في شيفرة HTML وCSS، بالإضافة إلى الأدوات التي يمكن استخدامها لمنع حدوث هذه المشاكل أو إصلاحها،كما يتضمن ذلك فحص أخطاء الشيفرة Linting Code والتعامل مع بادئات CSS واستخدام أدوات تطوير المتصفح لتتبّع المشاكل واستخدام تعويض دعم المتصفحات Polyfill لإضافة الدعم إليها ومعالجة مشاكل التصميم المتجاوب مع الشاشات وغير ذلك الكثير. معالجة المشاكل الشائعة للتوافق مع المتصفحات في شيفرة جافاسكربت: سننظر بعد ذلك في مشاكل جافاسكربت الشائعة للتوافق مع المتصفحات وكيفية إصلاحها، ويتضمن ذلك معلومات حول استخدام أدوات تطوير المتصفح لتتبّع المشاكل وإصلاحها واستخدام تعويض دعم المتصفحات Polyfill والمكتبات لحل المشاكل والحصول على ميزات جافاسكربت الحديثة التي تعمل في المتصفحات القديمة وغير ذلك الكثير. معالجة مشاكل سهولة الوصول Accessibility الشائعة للتوافق مع المتصفحات: سننتقل بعد ذلك إلى سهولة الوصول Accessibility وتوفير معلومات حول مشاكلها الشائعة، وكيفية إجراء اختبار بسيط والاستفادة من أدوات التدقيق والاختبارات الآلية للعثور على مشاكل سهولة الوصول. كيفية اكتشاف دعم المتصفحات للميزات أثناء اختبار مشاريع الويب: يتضمن اكتشاف الميزات معرفة ما إذا كان المتصفح يدعم كتلةً معينةً من الشيفرة البرمجية، ويعتمد تشغيل شيفرة برمجية على كونها مدعومة أم لا، بحيث يمكن للمتصفح دائمًا توفير تجربة عمل ناجحة بدلًا من التعطل أو ظهور الأخطاء في بعض المتصفحات، إذ يوضح هذا المقال بالتفصيل كيفية كتابة اكتشاف المتصفحات للميزات البسيطة وكيفية استخدام مكتبة لتسريع التطبيق واستخدام الميزات الأصيلة Native لاكتشاف الميزات مثل الميزة ‎@supports. مدخل إلى اختبارات مشاريع الويب الآلية للتوافق مع المتصفحات: يمكن أن يصبح إجراء الاختبارات يدويًا على العديد من المتصفحات والأجهزة عدة مرات في اليوم أمرًا مملًا ويستغرق وقتًا طويلًا، لذا يمكن معالجة ذلك بكفاءة من خلال استخدام الأدوات الآلية، إذ سنلقي نظرةً في هذا المقال على الأدوات المتاحة وكيفية استخدام مشغّلي المهام وأساسيات كيفية استخدام تطبيقات الاختبارات الآلية للمتصفحات التجارية مثل Sauce Labs و Browser Stack. إعداد بيئتك للاختبارات الآلية في مشاريع الويب للتوافق مع المتصفحات: سنعلِّمك في هذا المقال كيفية تثبيت بيئة الاختبار الآلية وإجراء اختباراتك الخاصة باستخدام بيئة Selenium/WebDriver ومكتبة الاختبارات مثل المكتبة selenium-webdriver الخاصة ببيئة Node، كما سنتعرّف على كيفية دمج بيئة اختبارك المحلية مع التطبيقات التجارية. لنبدأ بمقالنا الأول ولنتعرف على مفهوم اختبار مشاريع الويب للتوافق مع المتصفحات Cross Browser Testing. ما هو اختبار التوافق مع المتصفحات؟ يُستخدَم اختبار التوافق مع المتصفحات للتأكد من أنّ مواقع وتطبيقات الويب التي تنشئها تعمل بنجاح على عدد مقبول من متصفحات الويب، إذ تقع على عاتقك -بصفتك مطور ويب- مسؤولية التأكد من أنّ مشاريعك لا تعمل فقط، ولكنها تعمل مع جميع المستخدِمين بغض النظر عن المتصفح أو الجهاز أو الأدوات المساعدة الإضافية التي يستخدمونها، إذ عليك التفكير فيما يلي: متصفحات مختلفة غير المتصفح أو المتصفحَين اللذين تستخدِمهما بانتظام على أجهزتك بما في ذلك المتصفحات الأقدم قليلًا التي يُحتمَل أنه لا يزال بعض الأشخاص يستخدِمونها والتي لا تدعم أحدث ميزات CSS وجافاسكربت. أجهزة مختلفة ذات قدرات مختلفة من أحدث الحواسيب إلى الأجهزة اللوحية والهواتف الذكية وأجهزة التلفاز الذكية وصولًا إلى الأجهزة اللوحية الرخيصة وحتى الهواتف ذات الميزات القديمة التي يمكن أن تشغّل متصفحات ذات إمكانات محدودة. الأشخاص ذوو الاحتياجات الخاصة الذين يستخدِمون الويب بمساعدة التقنيات المساعدة مثل قارئات الشاشة أو الأشخاص الذين لا يستخدِمون الفأرة، إذ يستخدِم بعض الأشخاص لوحة المفاتيح فقط. تذكَّر دائمًا أنك لست أحد المستخدِمين، إذ لا يعني عمل موقعك بنجاح على جهاز MacBook Pro أو جهاز Galaxy Nexus المتطور أنه سيعمل مع جميع المستخدِمين، فهناك الكثير من الاختبارات التي يجب إجراؤها. إذا تحدّثنا عن المواقع الإلكترونية التي تعمل على متصفحات مختلفة، فهذا يعني أنه يجب أن توفر تجربة مستخدِم مقبولة على متصفحات مختلفة، وقد يُحتمَل ألّا يقدم الموقع التجربة نفسها بالضبط على جميع المتصفحات طالما أن الوظيفة الأساسية يمكن الوصول إليها بطريقة ما، إذ يمكن أن تحصل في المتصفحات الحديثة على شيء متحرك وثلاثي الأبعاد وحديث، في حين يمكن أن تحصل في المتصفحات القديمة على رسم مسطح يمثل المعلومات نفسها، وطالما أنّ صاحب الموقع سعيد بذلك، فهذا يعني أنك نجحت في عملك. من ناحية أخرى، ليس مقبولًا أن يعمل الموقع بنجاح مع المستخدِمين المبصرين مع تعذر الوصول إليه بالنسبة للمستخدِمين ضعاف البصر لأن تطبيق قارئ الشاشة لا يمكنه قراءة أيٍّ من المعلومات المخزنة عليه. لا نعني بعبارة "عبر عدد مقبول من متصفحات الويب" نسبةَ 100% من المتصفحات في العالم، فهذا مستحيل تقريبًا، إذ يمكنك إجراء بحث بشأن المتصفحات والأجهزة التي سيستخدِمها مستخدمو موقعك كما سنناقش في المقال التالي من هذه السلسلة، ولكن لا يمكنك ضمان كل شيء، وتحتاج -بصفتك مطور ويب- الموافقة على مجموعة من المتصفحات والأجهزة التي تحتاجها الشيفرة البرمجية للعمل عليها مع مالك الموقع، ولكنك ستحتاج بعد ذلك لاستخدام البرمجة الدفاعية Defensive Coding لمنح المتصفحات الأخرى أفضل فرصة ممكنة لتكون قادرةً على استخدام محتواك، ويُعَدّ ذلك أحد أكبر التحديات التي تواجه تطوير الويب. سبب حدوث مشاكل التوافق مع المتصفحات هناك العديد من الأسباب المختلفة لحدوث مشاكل التوافق مع المتصفحات، ولاحظ أننا هنا نتحدث عن المشاكل التي تتصرف فيها الأشياء بطريقة مختلفة على مختلف المتصفحات أو الأجهزة أو تفضيلات التصفح، ولكن يجب عليك إصلاح الأخطاء الموجودة في شيفرتك البرمجية قبل أن تحل مشاكل التوافق مع المتصفحات. تحدث مشاكل التوافق مع المتصفحات للأسباب التالية: تحتوي المتصفحات في بعض الأحيان على أخطاء أو يمكن أن تطبّق ميزات بطريقة مختلفة، ولكن يُعَدّ هذا الوضع أقل سوءًا بكثير مما كان عليه في السابق، إذ عمدت شركات المتصفحات إلى تطبيق الأشياء بطريقة مختلفة عن بعضها البعض في محاولة لاكتساب ميزة تنافسية عندما تنافسَ كل من IE4 و Netscape 4 على موقع المتصفح المهمين في التسعينات، مما صعّب الأمور كثيرًا على المطورين، وقد أصبحت المتصفحات أفضل بكثير في اتباع المعايير حاليًا، ولكن لا يخلو الأمر من بعض الاختلافات والأخطاء. يمكن أن تحتوي بعض المتصفحات على مستويات مختلفة من الدعم للميزات التقنية عن غيرها من المتصفحات، وهذا أمر لا مفر منه عندما تتعامل مع ميزات متطورة بدأت المتصفحات في تطبيقها، أو إذا كان عليك دعم المتصفحات القديمة التي لم تَعُدّ قيد التطوير وجُمِّدت، أي لم يُطبَّق عليها أيّ عمل جديد قبل وقت طويل من اختراع ميزة جديدة، فإذا أردت مثلًا استخدام أحدث ميزات جافاسكربت في موقعك، فيمكن ألّا تعمل في المتصفحات القديمة، وإذا كنت بحاجة إلى دعم المتصفحات القديمة، فيمكن أن تضطر إلى عدم استخدام هذه الميزات أو تحويل شيفرتك البرمجية إلى صيغة قديمة الطراز باستخدام نوع من المُصرِّفات Compilers عند الحاجة. يمكن أن تحتوي بعض الأجهزة على قيود تؤدي إلى بطء تشغيل موقع الويب أو عرضه بطريقة سيئة، فإذا صُمِّم موقع ما ليبدو جميلًا على حاسوب مكتبي مثلًا، فيُحتمَل أن يبدو صغيرًا ويصعب قراءته على هاتف محمول، وإذا احتوى موقعك على عدد كبير من الرسوم المتحركة الكبيرة، فيمكن أن يكون الأمر جيدًا على جهاز لوحي عالي المواصفات، ولكنه سيكون بطيئًا على جهاز منخفض المواصفات. هناك المزيد من الأسباب الأخرى، وسنتعرّف في المقالات اللاحقة على مشاكل التوافق مع المتصفحات للوصول إلى حلول لها. سير عمل اختبار التوافق مع المتصفحات يمكن أن يبدو هذا الاختبار مستهلِكًا للوقت ومخيفًا، ولكن لا داعي لأن يكون كذلك، فكل ما عليك فعله هو التخطيط له بعناية والتأكد من إجراء اختبارات كافية في الأماكن الصحيحة للتأكد من عدم ظهور مشاكل غير متوقعة، فإذا أردت العمل في مشروع كبير، فيجب اختباره بانتظام للتأكد من أنّ الميزات الجديدة تعمل بنجاح مع جمهورك المستهدَف وأن الإضافات الجديدة إلى الشيفرة البرمجية لا تعطِّل الميزات القديمة التي كانت عاملةً في السابق، فإذا تركت جميع الاختبارات إلى نهاية المشروع، فستكون أيّ أخطاء أو زلات برمجية تكتشفها أكثر تكلفةً وستستغرق وقتًا طويلًا لإصلاحها مما لو اكتشفتها وأصلحتها أثناء العمل على المشروع. يمكن تقسيم سير عمل الاختبار وإصلاح الزلات البرمجية في المشروع إلى المراحل الأربع التالية تقريبًا، وهذا تقسيم تقريبي فقط، إذ يمكن أن يعمل أشخاص آخرون بطريقة مختلفة: التخطيط الأولي Initial Planning. التطوير Development. الاختبار Testing/الاكتشاف Discovery الإصلاحات Fixes/التكرار Iteration تُكرَّر الخطوات 2 و3 و4 عدة مرات حسب الضرورة لإنجاز التنفيذ بالكامل، كما سنتعرّف على الأجزاء المختلفة من عملية الاختبار بمزيد من التفصيل في المقالات اللاحقة، ولكن لنلخّص فقط ما يحدث في كل خطوة حاليًا. التخطيط الأولي يُحتمَل أن يكون لديك في مرحلة التخطيط الأولي العديد من اجتماعات التخطيط مع مالك الموقع أو العميل الذي يمكن أن يكون رئيسك في العمل أو شخصًا من شركة خارجية تبني موقع ويب لها، حيث تحدد بالضبط ما يجب أن يكون عليه موقع الويب، وما هو المحتوى والوظائف التي يجب أن يحتوي عليها وكيف يجب أن يبدو وما إلى ذلك، كما سترغب في هذه المرحلة في معرفة مقدار الوقت المتاح لك لتطوير الموقع أي الموعد النهائي Deadline، وكم سيدفعون لك مقابل عملك، ولن نخوض في الكثير من التفاصيل حول هذا الأمر، ولكن يمكن أن يكون لمشاكل التوافق مع المتصفحات تأثير خطير على هذا التخطيط. يجب أن تبدأ في استكشاف الجمهور المستهدَف بمجرد حصولك على فكرة عن مجموعة الميزات المطلوبة والتقنيات التي ستبني هذه الميزات بها، مثل استكشاف المتصفحات والأجهزة وغير ذلك والتي سيستخدِمها الجمهور المستهدَف لهذا الموقع، فيمكن أن يكون لدى العميل بيانات حول هذه الأمور من بحث سابق أجراه من مواقع الويب الأخرى التي يمتلكها أو من الإصدارات السابقة من موقع الويب الذي تعمل عليه الآن مثلًا، فإذا لم يكن الأمر كذلك، فستتمكن من الحصول على فكرة جيدة من خلال النظر إلى مصادر أخرى مثل إحصائيات الاستخدام للمنافسين أو البلدان التي سيخدّمها الموقع، كما يمكنك استخدام بعض التخمين. يمكن أن تنشئ مثلًا موقعًا للتجارة الإلكترونية يخدّم العملاء في أمريكا الشمالية، ويجب أن يعمل الموقع بالكامل في الإصدارات الأخيرة من متصفحات الحواسيب المكتبية والهاتف المحمول (iOS و Android و Windows phone) الأكثر شيوعًا، إذ يجب أن يشمل ذلك كروم Chrome وأوبرا Opera الذي يعتمد على محرّك التصيير Rendering نفسه الخاص بكروم، بالإضافة إلى فايرفوكس Firefox و IE/Edge وسفاري Safari، كما يجب أن توفر تجربة مقبولة في الإصدارين IE 8 و9 ويمكن الوصول إليها باتباع تعليمات WCAG AA. أصبحتَ الآن تعرف منصات الاختبار المستهدفة، لذا يجب العودة ومراجعة مجموعة الميزات المطلوبة والتقنيات التي ستستخدِمها. إذا أراد مالك موقع التجارة الإلكترونية مثلًا جولةً ثلاثية الأبعاد مدعومة من WebGL لكل منتج مُضمَّن في صفحات المنتجات، فيجب قبول أنّ ذلك لن يعمل في إصدارات المتصفح IE قبل الإصدار 11، كما يجب أن توافق على توفير نسخة من الموقع بدون هذه الميزة لمستخدِمي إصدارات IE الأقدم، كما يجب عليك تجميع قائمة بمواقع المشاكل المحتمَلة. ملاحظة: يمكنك الرجوع إلى موقع caniuse.com للحصول على مزيد من تفاصيل معلومات دعم المتصفحات للتقنيات. يمكنك المضي قدمًا والبدء في تطوير الموقع بمجرد الاتفاق على هذه التفاصيل. التطوير لننتقل الآن إلى تطوير الموقع، إذ يجب عليك تقسيم الأجزاء المختلفة من عملية التطوير إلى وحدات، حيث يمكنك تقسيم مناطق الموقع المختلفة إلى الصفحة الرئيسية وصفحة المنتجات وعربة التسوق وسير عملية الدفع مثلًا، ثم يمكنك تقسيم هذه الأجزاء إلى تطبيق جزأي الترويسة والتذييل المشتركَين في الموقع، وتطبيق عرض تفاصيل صفحة المنتجات، وعنصر عربة التسوق الدائم وغير ذلك. هناك العديد من الاستراتيجيات العامة لتطوير التوافق مع المتصفحات مثل: الحصول على جميع الوظائف التي تعمل بنجاح قدر الإمكان في جميع المتصفحات المستهدفة، ويمكن أن يتضمن ذلك كتابة مسارات شيفرات برمجية مختلفة تعيد إنتاج الوظائف بطرق مختلفة تستهدف متصفحات مختلفة، أو استخدام تعويض دعم المتصفحات Polyfill لتقليد أيّ دعم مفقود باستخدام جافاسكربت أو تقنيات أخرى، أو استخدام مكتبة تسمح لك بكتابة جزء من الشيفرة البرمجية ثم تطبيق أشياء مختلفة في الخلفية اعتمادًا على ما يدعمه المتصفح. القبول بأن بعض الأشياء لن تعمل بالطريقة نفسها على جميع المتصفحات، وتقديم حلول مختلفة مقبولة في المتصفحات التي لا تدعم الوظائف الكاملة، ويكون ذلك في بعض الأحيان أمرًا لا مفر منه بسبب قيود الجهاز، إذ لن تقدِّم شاشة السينما العريضة التجربة المرئية نفسها لشاشة الجوال التي مقاسها 4 بوصات بغض النظر عن كيفية برمجة موقعك. القبول بأن موقعك لن يعمل في بعض المتصفحات القديمة، ثم المضي قدمًا في عملية التطوير، ويُعَدّ ذلك جيدًا بشرط عدم وجود مشكلة لدى عميلك أو قاعدة المستخدِمين في ذلك. تتضمن عملية التطوير مزيجًا من الأساليب الثلاثة السابقة، ولكن أهم شيء هو أن تختبر كل جزء صغير قبل تنفيذه وألّا تترك جميع الاختبارات حتى النهاية. الاختبار/الاكتشاف يجب اختبار الوظيفة الجديدة بعد كل مرحلة تطبيق، إذ يجب عليك أولًا التأكد من عدم وجود مشاكل عامة في شيفرتك البرمجية تعطل عمل الميزة كما يلي: اختبرها في بعض المتصفحات المستقرة على نظامك مثل Firefox أو Safari أو Chrome أو IE/Edge. أجرِ اختبارات سهولة الوصول Lo-fi مثل محاولة استخدام موقعك باستخدام لوحة المفاتيح فقط أو استخدام موقعك عبر قارئ الشاشة لمعرفة ما إذا كان قابلًا للتنقل عبره أم لا. أجرِ اختبارات على منصة للهاتف المحمول مثل Android أو iOS. أصلِح أيّ مشاكل تجدها في شيفرتك البرمجية الجديدة في هذه المرحلة، ثم يجب أن تحاول توسيع قائمة المتصفحات التي تريد اختبارها إلى قائمة كاملة من متصفحات الجمهور المستهدف والبدء في التركيز على التخلص من مشاكل التوافق مع المتصفحات، فمثلًا: حاول اختبار أحدث تغيير على جميع متصفحات الحواسيب المكتبية الحديثة بما في ذلك Firefox و Chrome و Opera و IE و Edge وSafari على أنظمة التشغيل Mac و Windows و Linux. اختبرها في متصفحات الهاتف المحمول والأجهزة اللوحية الشائعة مثل iOS Safari على أجهزة iPhone/iPad و Chrome و Firefox على أجهزة iPhone/iPad/Android. أجرِ اختبارات أيضًا على أيّ متصفحات أخرى ضمّنتها في قائمة أهدافك. خيار اختبار Lo-fi الأكثر استخدامًا هو إجراء جميع الاختبارات التي يمكنك تطبيقها بنفسك مثل أن يجرّب زملاؤك في الفريق الموقع إذا كنت تعمل في فريق، إذ يجب أن تحاول اختباره على أجهزة حقيقية إذا أمكن ذلك، فإذا لم تكن لديك الوسائل اللازمة لاختبار جميع مجموعات المتصفحات وأنظمة التشغيل والأجهزة المختلفة على العتاد الفيزيائي، فيمكنك الاستفادة من المقلّدات أو المحاكيات Emulators -التي تقلد جهازًا باستخدام برنامج على حاسوبك المكتبي- والآلات الافتراضية التي هي برامج تسمح بمحاكاة مجموعات متعددة من أنظمة التشغيل والبرامج على حاسوبك. يُعَدّ ذلك خيارًا شائعًا جدًا خاصةً في ظروف معينة مثل ألّا يتيح نظام ويندوز تثبيت إصدارات متعددة منه في الوقت ذاته وعلى الجهاز نفسه، لذا يكون استخدام آلات افتراضية متعددة هو الخيار الوحيد في هذه الحالة. يوجد خيار آخر هو استخدام مجموعات المستخدِمين، أي استخدام مجموعة من الأشخاص من خارج فريقك لاختبار موقعك مثل مجموعة من الأصدقاء أو العائلة أو مجموعة من الموظفين الآخرين أو صف دراسي في جامعة محلية أو إعداد اختبار احترافي بحيث يُدفَع للأشخاص لاختبار موقعك وتقديم النتائج. أخيرًا، يمكنك استخدام الاختبار باستخدام أدوات التدقيق أو الاختبارات الآلية، حيث يُعَدّ هذا الاختيار معقولًا مع المشاريع الكبيرة، إذ يمكن أن يستغرق إجراء هذا الاختبار يدويًا وقتًا طويلًا جدًا، كما يمكنك إعداد نظام اختبار آلي مثل تطبيق Selenium الشهير الذي يمكنه تحميل موقعك في عدد من المتصفحات المختلفة مثلًا، ويمكنه: معرفة ما إذا كان النقر على الزر يؤدي إلى حدوث شيء ما بنجاح مثل عرض خريطة، وعرض النتائج بمجرد اكتمال الاختبارات. التقاط لقطة شاشة لكل من هذه الاختبارات، مما يسمح لك بمعرفة ما إذا كان تخطيط الموقع متناقسًا على المتصفحات المختلفة. هناك أدوات تجارية متاحة مثل Browserling و Sauce Labs و Browser Stack و Endtest و LambdaTest و TestingBot و CrossBrowserTesting التي تطبّق هذه الاختبارات دون الحاجة إلى القلق بشأن الإعداد إذا أردت استثمار بعض المال في الاختبارات، كما يمكنك إعداد بيئة تشغّل الاختبارات تلقائيًا نيابةً عنك ثم تتيح لك فقط التحقق من التغييرات التي أجريتها على مستودع الشيفرة المركزي إذا نجحت الاختبارات باستمرار. الاختبار على المتصفحات التجريبية يكون اختبار الإصدارات التجريبية من المتصفحات فكرة جيدة في أغلب الأحيان، لذا اطّلع على الروابط التالية: Firefox Developer Edition. Edge Insider Preview. Safari Technology Preview. Chrome Canary. Opera Developer. ينتشر هذا النوع من الاختبارات خاصةً إذا استخدمتَ تقنيات حديثة جدًا في موقعك ورغبت في اختبار أحدث التطبيقات؛ أو إذا صادفت زلةً برمجيةً في أحدث إصدار من المتصفح وأردت معرفة إذا أصلح مطورو المتصفح هذه الزلة البرمجية في إصدار أحدث. الإصلاحات/التكرار يجب محاولة إصلاح الزلة البرمجية بمجرد اكتشافها، فأول شيء يجب فعله هو تضييق نطاق مكان حدوث الزلة البرمجية قدر الإمكان، لذا احصل على أكبر قدر ممكن من المعلومات من الشخص الذي يبلّغ عن الزلة البرمجية مثل معرفة ما هي المنصة أو المنصات، والجهاز أو الأجهزة، وإصدار أو إصدارات المتصفح التي يستخدمها، وجرب هذا الاختبار على إعدادات مماثلة مثل إصدار المتصفح نفسه على منصات حواسيب مختلفة أو عدة إصدارات مختلفة من المتصفح نفسه على المنصة نفسها لمعرفة مدى انتشار الزلة البرمجبة. يمكن ألّا يكون هذا خطأك، لذا نأمل إصلاح الزلة البرمجية بسرعة في حالة وجودها في المتصفح، كما يمكن أن تكون الزلة البرمجية قد أُصلِحت مسبقًا مثل وجود خطأ في الإصدار 49 من Firefox، ولكنها لم تَعُد موجودةً في Firefox Nightly (الإصدار 52)، فعندئذٍ تكون قد أُصلِحت فعليًا، فإذا لم تكون قد أُصلِحت مسبقًا، فيمكنك إرسال تقرير بالزلة البرمجية. إذا كان ذلك خطأك، فيجب عليك إصلاحه، إذ يتضمن اكتشاف سبب الزلة البرمجية الإستراتيجية نفسها لأي زلة برمجية في عملية تطوير الويب، فإذا اكتشفتَ سبب الزلة البرمجية، فيجب أن تقرر كيفية التعامل معها في المتصفح التي تتسبب في حدوث مشاكل، ولا يمكنك تعديل شيفرة المشكلة البرمجية فقط، إذ يمكن أن يؤدي ذلك إلى تعطّل الشيفرة في المتصفحات الأخرى، والأسلوب العام في هذه الحالة هو تفرّع الشيفرة البرمجية بطريقةٍ ما مثل استخدام شيفرة اكتشاف المتصفحات لميزة جافاسكربت لاكتشاف المواقف التي لا تعمل فيها الميزة التي تؤدي إلى المشكلة، وتشغيل الشيفرة البرمجية الأخرى في الحالات التي تعمل فيها هذه الميزة. يجب تكرار عملية الاختبار بعد إصلاح المشكلة للتأكد من أنّ الإصلاح يعمل بنجاح ولا يتسبب في تعطل الموقع في أماكن أخرى أو في متصفحات أخرى. إصدار تقارير بالأخطاء إذا اكتشفت أخطاءً في المتصفحات، فيجب عليك التبليغ عنها باستخدام ما يلي: Firefox Bugzilla. متعقّب مشاكل EdgeHTML. Safari. Chrome. Opera. الخلاصة يُفترَض أن يمنحك هذا المقال فهمًا عالي المستوى لأهم المفاهيم التي تحتاج معرفتها حول اختبار التوافق مع المتصفحات، وبالتالي أصبحت الآن جاهزًا للمضي قدمًا والبدء في التعرف على استراتيجيات اختبار التوافق مع المتصفحات. ترجمة -وبتصرُّف- للمقالين Cross browser testing وIntroduction to cross browser testing. اقرأ أيضًا المقال السابق: إضافة خاصية ترشيح لتطبيق Angular وتجهيزه للنشر المدخل الشامل لتعلم تطوير الويب وبرمجة المواقع فهم أدوات تطوير الويب من طرف العميل