الكلمة الافتتاحية - JavaScript القابلة للاختبار - تصميم تطبيقك بحيث يمكن اختباره
مارك تروستلر (Google)
إنّ JavaScript القابلة للاختبار هي عملية. وسواءً كنت تبدأ من قائمة فارغة أو تطبيق قد تم تنفيذه من قبل (أو في أي مكان ما بينه)، باستطاعتك اختبار رمز JavaScript بسهولة وسلاسة وفعّالة هي ميزة ضرورية. ستتم إعادة كتابة الرمز الذي لا يمكن اختباره.
على الرغم من أنّ لغة JavaScript فريدة بسبب مجموعة كبيرة من البيئات التي تعمل ضمنها، هناك العديد من المنهجيات "القابلة للاختبار" التي تم اختبارها وبلغات أخرى من لغات أخرى. بالطبع، لا تزال هناك تحديات فريدة يجب أن يواجهها مطوّرو JavaScript أثناء كتابة الرموز البرمجية واختبارها.
ما هي الأنماط التي تجعل الرمز قابلاً للاختبار؟ أي أنماط مضادة للأنماط تعيق الاختبار؟ ما هي المقاييس والأدلة الإرشادية ذات الصلة التي يمكن استخدامها لقياس إمكانية اختبار الرمز الخاص بنا؟ بعد أن بدأت عملية إنشاء الرمز القابل للاختبار، ماذا يحدث؟
انضمّ إليّ لتقسيم عملية كتابة JavaScript الذي يمكن اختباره. سنحقّق في الأفكار والأنماط والمنهجيات التي تزيد بشكل كبير من قابلية الاختبار، وبالتالي إمكانية الحفاظ على صحة الرمز ومدّته ومدّته. وسواء كنت تكتب لغة JavaScript لتكون جهة العميل أو الخادم، سيؤدي ذلك إلى تحسين جودة الرمز بشكل كبير.
اختراق المصفوفة - اختبار Android على نطاق واسع
توماس كنتيش (Google) وستيفان رامساور (Google) وفاليرا زاكاروف (Google)
هَلْ نَحْنُ عَلَى اسْتِعْدَادْ لِتَنَاوُلِ الْقَرْبَة الْحَمْرَا؟
غيّر الجوّال طريقة تفاعل الأشخاص مع أجهزة الكمبيوتر. هذا أمر رائع، ولكن بصفتك مهندسًا، نواجه مصفوفة متزايدة من البيئات التي تعمل عليها رموزنا. لن تعود أيام التفكير في عدد من المتصفحات ودرجات دقة الشاشة فقط. كيف يستطيع المهندسون التعامل مع المصفوفة؟ سنتناول كيفية مكافحة Google لمشكلة الاختبار هذه في محطات العمل وفي السحابة الإلكترونية وفي ذهنك...
"أُحَاوِلْ تَحْرِيرَ الْعَقْلِ يَا نَوِيلْ. لَكِنْ لَا يُمْكِنُنِي عَرْضُ الْبَابْ فَقَطْ. دَهْ الْحَاجَة الْلِّي مَطْلُوبْ سَيْرَتْهَا".
التشغيل الآلي لواجهة المستخدم على Android
غوانغ تشو (朱光) (Google) وآدم موماز (Google)
مع زيادة رواج Android في عالم الأجهزة الجوّالة، يستكشف مطوّرو التطبيقات ومورّدو المصنّعون الأصليون الطرق لإجراء اختبار شامل لواجهة المستخدم للتطبيقات أو النظام الأساسي بالكامل. من خلال مراجعة موجزة لحلول التشغيل المبرمَج الحالية لواجهة المستخدم على نظام التشغيل Android، يقدِّم هذا الحديث إطار عمل التشغيل الآلي لواجهة المستخدم على نظام التشغيل Android الذي تم إصداره مؤخرًا، ويستمر في إلقاء نظرة داخلية على إطار العمل وحالات الاستخدام المعتادة وسير العمل.
Appium: التشغيل الآلي للتطبيقات المتوافقة مع الأجهزة الجوّالة
Joannathan Lipps (مختبرات الصلصات)
Appium هو خادم Node.js يُشغّل تطبيقات الجوّال المحلية والهجينة (كل من iOS وAndroid). تحدّد فلسفة Appium أنّه يجب عدم تعديل التطبيقات لكي يتمّ تنفيذها آليًا، وأنّه من المفترض أن تتمكّن من كتابة رمز الاختبار بأي لغة أو إطار عمل. والنتيجة هي خادم Selenium WebDriver الذي يتحدث عن الأجهزة الجوّالة مثل اللغة الأصلية. يعمل Appium على الأجهزة وأجهزة المحاكاة المفتوحة المصدر، وهو مفتوح المصدر تمامًا، ما يجعله وسيلة سهلة ورائعة لبدء استخدام التشغيل المبرمَج لاختبار الأجهزة الجوّالة. في هذا الحديث، سأشرح المبادئ التي تحدّد تصميم Appium، وتحدّث عن Appium في مجال أُطر عمل الأجهزة الجوّالة الأخرى، وأشرح البنية التي تجعل العملية سحرية. أخيرًا، سأتعمّق في الرمز لإجراء اختبار بسيط لتطبيق جديد متوافق مع الأجهزة الجوّالة، وأظهِر Appium الذي يجري هذا الاختبار على أجهزة iPhone وAndroid.
إنشاء بنية أساسية قابلة للتوسع لاختبار الجوّال في Google+ للجوّال
إدواردو برافو (Google)
ويُعدّ اختبار التطبيقات المحلية بطريقة مفيدة وثابتة وقابلة للتطور تحديًا. لقد طوّرت +Google حلولاً فعالة لمعالجة هذه المشاكل من خلال توفير البنية الأساسية المناسبة لكل سيناريو معقّد تمثّله الأجهزة الجوّالة. توفّر البنية الأساسية الحالية للاختبار الأدوات المناسبة لكل من تطبيقات iOS وAndroid لمنح فريق التطوير ثقةً في أنّ التغييرات الجديدة لن تؤثّر في العملاء الحاليين.
Espresso: اختبار حديث لاختبار واجهة المستخدم على Android
فاليرا زاكاروف (Google)
يجب أن يكون تطوير اختبار Android موثوقًا بالسرعة والسهولة تمامًا مثل سحب لقطة إسبرسو. ولكن باستخدام الأدوات الحالية، قد يبدو الأمر أكثر شبهًا بتحضير صلصة الكراميل الصغيرة، على الطريقة التقليدية التي تشتهر بها العجينة للمرة الأولى. Espresso هو إطار عمل جديد لاختبار Android يتيح لك كتابة اختبارات واجهة مستخدم موجزة وجميلة وموثوقة بسرعة. تتميز واجهة برمجة التطبيقات الأساسية بحجم صغير ويمكن توقعه ويمكن تعلّمه بسهولة، كما أنها مفتوحة للتخصيص. وتوضّح اختبارات الإسبرسو توقّعاتها وتفاعلاتها وتأكيداتها بوضوح بدون تشتيت الانتباه أو البنية الأساسية المخصّصة أو تفاصيل التنفيذ الفوضوية. يمكن إجراء الاختبارات على النحو الأمثل، إذ يمكنك الانتظار أو مزامنة أو النوم أو استطلاعات الرأي فحسب، فضلاً عن السماح لإطار العمل بالتركيز على واجهة المستخدم في أوقات عدم النشاط وتأكيدها بأمان. ابدأ الاستمتاع بقراءة الاختبارات وتنفيذها على واجهة المستخدم - جرِّب لقطة إسبريسو.
اختبار أداء الويب باستخدام WebDriver
مايكل كليوبكوف (Google)
أثناء اختبار أداء الويب، نعرف جيدًا كيفية تحليل تحميل الصفحة. ومع ذلك، نحن بحاجة إلى تجاوز حدود تحميل الصفحة، فالتطبيقات الحديثة تفاعلية للغاية، وغالبًا ما لا تؤدي العمليات إلى إعادة تحميل الصفحة بأكملها، بل يتم تعديلها. تم تضمين WebDriver في مجموعات اختبار أداء الويب من خلال دمج الأشخاص المختلفين، ما يساعد في الحفاظ على اختبارات الأداء منفصلة عن بقية أدوات اختبار واجهة المستخدم. أقترح إنشاء ميزات اختبار الأداء مباشرةً على WebDriver، بالاستفادة من واجهة برمجة التطبيقات Logging API التي تمت إضافتها مؤخرًا. وبذلك يصبح من الممكن جمع مقاييس الأداء أثناء إجراء اختبارات وظيفية منتظمة، ما يسمح بدمج أكثر سلاسة لاختبارات الأداء في عملية التطوير وعملية الاختبار بوجهٍ عام. كما أنّها تسبب إزعاجًا كبيرًا لسلاسل الأدوات المخصّصة للإصدار/الاختبار والتي تنشئها كل مؤسسة كبيرة تقريبًا.
سأشرح ذلك باستخدام الجيل الجديد من ChromeDriver (WebDriver لمتصفّح Chromium).
الاختبار المستمر لبيانات "خرائط Google"
Yvette Nameth (Google) وBrendan Dhein (شركة Google)
بشكل عام، يتعلق الاختبار المستمر بإجراء الوحدات التنظيمية واختبارات التكامل. ولكن عندما تكون البيانات التي يعالجها الخادم هي السبب الأهم للتغيير، كيف تضمن أن يظل مستهلكو البيانات قابلاً للاستخدام وأنّه لا يتداخل مع معدل التغيير أو تغيير سيئ؟ وسنناقش أساليب الاختبار المستمر للبيانات باستخدام أمثلة من "خرائط Google".
العثور على "عملاء" يفشلون تلقائيًا في إنشاء نماذج تتضمّن أعطالاً
Calal Ziftci (UCSD) وVivek Ramavajjala (UCSD)
يشكّل الإنشاء المستمر إحدى البُنى الأساسية الأساسية في Google. عند تعذّر إنشاء إصدار معيّن، من المهم تحديد قوائم التغييرات أو قوائم التغييرات سريعًا بحيث يمكن تصحيحها إلى اللون الأخضر.
تتوفّر حلول اكتشاف الجبر للتصميمات الصغيرة والمتوسطة الحجم، لكن ليس للإصدارات المدمَجة الكبيرة.
ويسعى الباحث عن المنحوتات إلى العثور على متغيّر التصميم المخصّص للمباني الكبيرة تلقائيًا، وذلك في إطار زمني قصير جدًا يحقّق نجاحًا كبيرًا. استنادًا إلى معدّل الإنتاج في مشاريع متعدّدة خلال آخر 9 أشهر، يوفّر الباحث عن المنحوتات نتائج واعدة إلى حد كبير. يمكنك الاطّلاع على محادثتنا للتعرّف على الطريقة التي استخدمنا بها أداة البحث عن المعاملات ومدى نجاحها في عملية الإنتاج.
التحقيق التجريبي لجودة مجموعة منتجات البرامج
كاترينا غوسيفا بوبستوجانوفا (جامعة فيرجينيا الغربية)
تُظهر مجموعات منتجات البرامج درجة مشتركة من القواسم المشتركة بين الأنظمة في مجموعة المنتجات وعددًا محددًا جيدًا من الصيغ المحتملة. استنادًا إلى البيانات المستخرجة من دراسات حالة - مجموعة منتجات صناعية متوسطة الحجم ومجموعة منتجات كبيرة ومتطوّرة ومفتوحة المصدر - استكشفنا بشكل تجريبي ما إذا كانت إعادة الاستخدام المنهجية تحسّن الجودة وتدعم التوقّع الناجح للأخطاء المستقبلية المحتملة من الأخطاء التي حدثت سابقًا، ومقاييس رمز المصدر، ومقاييس التغيير. في نتائج البحث المتعلقة بمجموعة منتجات، أكّدت نتائج البحث التي أجريناها على أنّ الأخطاء الأخرى مرتبطة ارتباطًا وثيقًا بتغيير المقاييس مقارنةً بمقاييس الرموز الثابتة. أظهرت نتائج تقييم الجودة أنه على الرغم من تغيّر الحِزم القديمة (بما في ذلك القواسم المشتركة)، إلا أنها احتفظت بكثافة منخفضة للأخطاء. إضافةً إلى ذلك، تحسّنت مجموعة منتجات البرامج المفتوحة المصدر من حيث الجودة مع تطوّرها من خلال الإصدارات. يستند التوقّع استنادًا إلى نماذج الانحدار الخطّي المعمّمة إلى الحِزم بدقة وفقًا لأخطاء ما بعد الإصدار، وذلك باستخدام النماذج التي تم إنشاؤها في الإصدار السابق. وكشفت النتائج أيضًا أنّ التوقعات الناتجة عن أخطاء ما بعد الإصدار تستفيد من معلومات مجموعات المنتجات الإضافية.
العنوان SanSanzer
كوشيا سيريباني (Google)
AddressSanitizer (ASan) هو أداة للعثور على تجاوز سعة التخزين المؤقت (في حزمة أو ذاكرة التخزين المؤقت أو العناصر العامة) ورصد الأخطاء التي لا يمكن استخدامها بعد برامج C/C+. تبحث ThreadSanitizer (TSan) عن سباقات البيانات في برامج C/C++ وGo. MemorySanitizer (MSan) هي أداة قيد التقدّم ترصد استخدامات الذاكرة التي لم يتم ضبطها (C++ ). تستند هذه الأدوات إلى أداة التجميع (LLVM وGCC)، ما يجعلها سريعة جدًا (مثلاً، يشهد ASan بطءً في الأداء بمقدار مرّتين). سنشارك تجاربنا في إجراء الاختبارات على نطاق واسع باستخدام هذه الأدوات.
الكلمة الافتتاحية - تناول المحيط - العثور على XSS على نطاق Google
كلاوديو كريسيون (Google)
إنّ "البرمجة النصية على المواقع الإلكترونية" أو XSS هي معادِلة حديثة للطانة السوداء في العصور الوسطى في عالم تطبيقات الويب، فهي واسعة النطاق وتؤدي إلى إساءة الاستخدام ولا تتوفّر سوى طرق فنية قليلة أو لا تتوفّر سوى طرق تقنية تقنية لرصد هذا التأخّر. هذا ويُعدّ نموذج DOM XSS صيغةً سيئةً بشكلٍ خاص، لأنّه يتطلّب اكتشاف متصفّح حقيقي أو ما يعادله، وهي مشكلة صعبة توفّر القليل من الحلّ المبرمَج.
كنّا بحاجة إلى أدوات فعّالة ذاتية القيادة للتعرّف على DOM XSS في مرحلة مبكرة من مراحل التطوير، ويمكن استخدام هذه الأداة من قِبل مهندسين من خارج فريق الأمان، فكل ما نريده هو منتج يمكنه فحص مجموعة التطبيقات الضخمة والسريعة والمعقدة للغاية وتلك التي لا يمكن رصدها بالطبع. لهذا السبب، صمّمنا جهازًا ضوئيًا لتطبيقات الويب يستهدف DOM XSS وصمَّم استنادًا إلى تقنيات Google العادية. وهو يعمل في App Engine ويستفيد من متصفح Chrome الفعّال وبعض مئات من وحدات المعالجة المركزية كنظام أساسي لفحص الأمان.
وهي أيضًا مواطن لطيف في ترسانة الاختبارات في Google، إذ إنها موجودة في البنية الأساسية للاختبار، بدلاً من أن تكون وسيلة فريق الأمان.
في هذا الحديث، نوضّح أسلوبنا الجديد والتحديات التي واجهناها أثناء توسيع نطاق نظامنا بما يتناسب مع حجم Google وأفكارنا حول نماذج الاكتشاف والزحف في التطبيقات التي تستخدم JavaScript بشكل مكثف.