
من المحتمل أن العديد من مطوري اختبارات واجهة مستخدم iOS على دراية بمشكلة وقت الاختبار. يُجري Badoo أكثر من 1400 اختبار شامل لتطبيقات iOS لكل تشغيل تراجعي. هذه هي أكثر من 40 ساعة من الاختبارات التي تمر في 30 دقيقة حقيقية.
شارك نيكولاي أبالوف من Badoo كيف تمكن من تسريع تنفيذ الاختبار من 1.5 ساعة إلى 30 دقيقة ؛ كيف تكشف عن الاختبارات وثيقة الصلة والبنية التحتية لنظام iOS عن طريق الذهاب إلى خادم الجهاز ؛ كيف جعل من السهل تشغيل الاختبارات بشكل متوازٍ وجعل الاختبارات والبنية التحتية أسهل في الدعم والتوسع.
ستتعلم مدى سهولة إجراء الاختبارات بالتوازي مع أدوات مثل fbsimctl ، وكيف يمكن للفصل بين الاختبارات والبنية التحتية أن يسهل استضافة الاختبارات ودعمها وتوسيع نطاقها.
في البداية ، قدم نيكولاي تقريرًا في مؤتمر Heisenbug (يمكنك مشاهدة
الفيديو ) ، والآن بالنسبة لـ Habr قمنا بعمل نسخة نصية من التقرير. التالي هو سرد الشخص الأول:
مرحبًا بالجميع ، سأتحدث اليوم عن اختبار القياس لنظام التشغيل iOS. اسمي نيكولاس ، أتعامل بشكل أساسي مع البنية التحتية لنظام iOS في Badoo. قبل ذلك ، عمل في 2GIS لمدة ثلاث سنوات ، وشارك في التطوير والأتمتة ، على وجه الخصوص ، كتب Winium.Mobile - تطبيق WebDriver لـ Windows Phone. تم نقلي إلى Badoo للعمل على أتمتة Windows Phone ، ولكن بعد فترة قررت الشركة تعليق تطوير هذا النظام الأساسي. وقد عرضت علي مهام مثيرة للاهتمام لأتمتة iOS ، حول هذا سأخبرك به اليوم.
ما الذي سنتحدث عنه؟ الخطة كما يلي:
- بيان غير رسمي للمشكلة ، مقدمة للأدوات المستخدمة: كيف ولماذا.
- اختبار موازي على iOS وكيف تطور (على وجه الخصوص ، وفقًا لتاريخ شركتنا ، منذ أن بدأنا العمل عليه في عام 2015).
- خادم الجهاز هو الجزء الرئيسي من التقرير. نموذجنا الجديد لموازنة الاختبارات.
- النتائج التي حققناها مع الخادم.
- إذا لم يكن لديك 1500 اختبار ، فقد لا تحتاج حقًا إلى خادم جهاز ، ولكن لا يزال بإمكانك الحصول على أشياء مثيرة للاهتمام من ذلك ، وسوف نتحدث عنها. يمكن تطبيقها إذا كان لديك 10-25 اختبارًا ، وسيظل هذا يعطي التسارع أو الاستقرار الإضافي.
- وأخيرًا ، استخلاص المعلومات.
الأدوات
الأول هو القليل عن من يستخدم ماذا. إن مجموعتنا غير القياسية إلى حد ما ، لأننا نستخدم كلاً من Calabash و WebDriverAgent (الذي يمنحنا السرعة و Calabash للخلف لأتمتة تطبيقنا وفي نفس الوقت الوصول الكامل إلى النظام والتطبيقات الأخرى من خلال WebDriverAgent). WebDriverAgent هو تطبيق فيسبوك لـ WebDriver لنظام iOS يستخدم داخليًا بواسطة Appium. و Calabash هو خادم مضمن للأتمتة. نكتب الاختبارات بأنفسهم في شكل قابل للقراءة البشرية باستخدام الخيار. أي في شركتنا الزائفة BDD. ولأننا استخدمنا الخيار والكالاباش ، فقد ورثنا روبي ، وكل الشفرة مكتوبة عليه. هناك الكثير من التعليمات البرمجية ، وعليك الاستمرار في الكتابة في روبي. لإجراء الاختبارات بالتوازي ، نستخدم أداة
موازية ، وهي أداة كتبها أحد زملائي في Badoo.
لنبدأ بما كان لدينا. عندما بدأت في إعداد التقرير ، كان هناك 1200 اختبار. في الوقت الذي تم الانتهاء منه ، كان 1300. بينما وصلت إلى هنا ، كان هناك بالفعل 1400 اختبار. هذه اختبارات نهاية إلى نهاية ، وليست اختبارات الوحدة واختبارات التكامل. فهم يشكلون 35-40 ساعة من وقت الكمبيوتر على جهاز محاكاة واحد. مروا في وقت سابق في ساعة ونصف. سأخبركم كيف بدأوا بالمرور خلال 30 دقيقة.
لدينا سير عمل في شركتنا مع الفروع والمراجعات وإجراء الاختبارات على هذه الفروع. يقوم المطورون بإنشاء ما يقرب من 10 طلبات في المستودع الرئيسي لتطبيقنا. ولكن يحتوي أيضًا على مكونات مشتركة مع تطبيقات أخرى ، لذلك يوجد أحيانًا أكثر من عشرة. ونتيجة لذلك ، يتم تشغيل 30 اختبارًا يوميًا على الأقل. منذ أن دفع المطورون ، أدركوا أنهم بدأوا مع الأخطاء ، وإعادة التحميل ، وكل هذا يبدأ في الانحدار الكامل ، ببساطة لأنه يمكننا تشغيله. على نفس البنية التحتية ، نطلق مشاريع إضافية ، مثل Liveshot ، التي تأخذ لقطات شاشة للتطبيق في البرامج النصية للمستخدم الرئيسي بجميع اللغات ، حتى يتمكن المترجمون من التحقق من صحة الترجمة ، سواء كانت ملائمة على الشاشة وما إلى ذلك. ونتيجة لذلك ، خرج حوالي ساعة ونصف الساعة من وقت الماكينة في الوقت الحالي.
بادئ ذي بدء ، نريد أن يثق المطورون والمختبرون في الأتمتة ويعتمدون عليها لتقليل الانحدار اليدوي. ولكي يحدث هذا ، من الضروري تحقيق عملية سريعة ، والأهم من ذلك ، مستقرة وموثوقة من الأتمتة. إذا مرت الاختبارات في غضون ساعة ونصف ، فسوف يتعب المطور من انتظار النتائج ، وسيبدأ في القيام بمهمة أخرى ، وسوف يتحول تركيزه. وعندما تسقط بعض الاختبارات ، لن يكون سعيدًا جدًا بالعودة ، وتغيير انتباهه وإصلاح شيء ما. إذا كانت الاختبارات غير موثوقة ، فمع مرور الوقت يبدأ الناس في إدراكها كحاجز فقط. تسقط باستمرار ، على الرغم من عدم وجود أخطاء في التعليمات البرمجية. هذه اختبارات قشارية ، نوع من العائق. وبناء عليه ، تم الكشف عن هاتين النقطتين في هذه المتطلبات:
- يجب أن تستغرق الاختبارات 30 دقيقة أو أسرع.
- يجب أن تكون مستقرة.
- يجب أن تكون قابلة للتطوير حتى نتمكن من إضافة نصف ساعة لإضافة مائة اختبار أخرى.
- يجب صيانة البنية التحتية وتطويرها بسهولة.
- على أجهزة المحاكاة والأجهزة المادية ، يجب أن يبدأ كل شيء بنفس الطريقة.
نجري بشكل أساسي اختبارات على أجهزة المحاكاة ، وليس على الأجهزة المادية ، لأنها أسرع وأكثر استقرارًا وأسهل. يتم استخدام الأجهزة المادية فقط للاختبارات التي تتطلب ذلك حقًا. على سبيل المثال ، الكاميرا ، ودفع الإخطارات وما شابه ذلك.
كيف تفي بهذه المتطلبات وتفعل كل شيء بشكل جيد؟ الجواب بسيط للغاية: نزيل ثلثي الاختبارات! يناسب هذا الحل في 30 دقيقة (لأنه لا يزال هناك سوى ثلث الاختبارات) ، والقياس بسهولة (يمكن حذف المزيد من الاختبارات) ، ويزيد من الموثوقية (لأن أول شيء نقوم بإزالته هو أكثر الاختبارات غير الموثوقة). هذا كل شيء بالنسبة لي. أسئلة؟
ولكن بجدية ، هناك بعض الحقيقة في كل نكتة. إذا كان لديك الكثير من الاختبارات ، فأنت بحاجة إلى مراجعتها وفهم أي منها يحقق فوائد حقيقية. كان لدينا مهمة مختلفة ، لذلك قررنا أن نرى ما يمكن القيام به.
النهج الأول هو تصفية الاختبارات على أساس التغطية أو المكونات. أي ، حدد الاختبارات المناسبة بناءً على تغييرات الملف في التطبيق. لن أتحدث عن هذا ، لكن هذه إحدى المهام التي نقوم بحلها في الوقت الحالي.
خيار آخر هو تسريع وتثبيت الاختبارات نفسها. يمكنك إجراء اختبار محدد ، ومعرفة الخطوات التي تستغرق معظم الوقت فيها وما إذا كان يمكن تحسينها بطريقة أو بأخرى. إذا كان بعضها غير مستقر للغاية في كثير من الأحيان ، فإنك تقوم بتصحيحها ، لأنها تقلل من إعادة تشغيل الاختبار ، وكل شيء يسير بشكل أسرع.
وأخيرًا ، مهمة مختلفة تمامًا - موازاة الاختبارات ، وتوزيعها على عدد كبير من المحاكيات وتوفير بنية أساسية قابلة للتطوير ومستقرة بحيث يكون هناك الكثير للتوازي.
في هذه المقالة سنتحدث بشكل أساسي عن النقطتين الأخيرتين وفي النهاية ، في النصائح والحيل ، سنتطرق إلى النقطة المتعلقة بالسرعة والاستقرار.
اختبار موازي لنظام iOS
لنبدأ بتاريخ الاختبار الموازي لنظام iOS بشكل عام و Badoo بشكل خاص. بادئ ذي بدء ، الحساب البسيط ، هنا ، ومع ذلك ، هناك خطأ في الصيغة إذا قارنا الأبعاد:

كان هناك 1300 اختبار لمحاكاة واحدة ، اتضح 40 ساعة. ثم يأتي ساتيش ، قائدي ، ويقول إنه يحتاج إلى نصف ساعة. عليك أن تخترع شيئا. يظهر X في الصيغة: كم عدد المحاكيات التي يتم تشغيلها ، بحيث يستمر كل شيء في نصف ساعة. الجواب 80 محاكاة. وعلى الفور يطرح السؤال ، أين تضع هذه المحاكاة 80 ، لأنها لا تناسب أي مكان.
هناك العديد من الخيارات: يمكنك الذهاب إلى السحب مثل SauceLabs أو Xamarin أو AWS Device Farm. ويمكنك أن تفكر في كل شيء في المنزل وتقوم بعمل جيد. بالنظر إلى أن هذه المقالة موجودة ، فقد فعلنا كل شيء بشكل جيد في المنزل. قررنا ذلك ، لأن السحابة بمثل هذا الحجم ستكون باهظة الثمن للغاية ، وكان هناك أيضًا موقف عندما خرج iOS 10 وأصدر Appium دعمًا لها لمدة شهر تقريبًا. هذا يعني أنه في SauceLabs لمدة شهر لم نتمكن من اختبار iOS 10 تلقائيًا ، وهو ما لم يناسبنا على الإطلاق. بالإضافة إلى ذلك ، يتم إغلاق جميع السحب ، ولا يمكنك التأثير عليها.
لذا ، قررنا القيام بكل شيء في المنزل. بدأنا في مكان ما في عام 2015 ، ثم لم يكن Xcode قادرًا على تشغيل أكثر من جهاز محاكاة. كما اتضح ، لا يمكنه تشغيل أكثر من محاكي واحد تحت مستخدم واحد على نفس الجهاز. إذا كان لديك العديد من المستخدمين ، فيمكنك تشغيل المحاكاة بالقدر الذي تريده. توصل زميلي تيم باورستوك إلى نموذج كنا نعيش فيه طويلًا بما فيه الكفاية.

هناك وكيل (TeamCity ، Jenkins Node وما شابه) ، يعمل على موازٍ للخيار ، والذي يذهب ببساطة إلى الأجهزة البعيدة عبر ssh. تظهر الصورة سيارتين لاثنين من المستخدمين. يتم نسخ جميع الملفات الضرورية مثل الاختبارات وتشغيلها على الأجهزة البعيدة عبر ssh. وتقوم الاختبارات بالفعل بتشغيل المحاكي محليًا على سطح المكتب الحالي. لكي ينجح هذا ، كان عليك أولاً الانتقال إلى كل جهاز ، وإنشاء ، على سبيل المثال ، 5 مستخدمين ، إذا كنت تريد 5 محاكيات ، اجعل مستخدمًا واحدًا يقوم بتسجيل الدخول تلقائيًا ، وفتح مشاركة الشاشة للبقية ، بحيث يكون لديهم دائمًا سطح مكتب. وتكوين البرنامج الخفي ssh بحيث يمكنه الوصول إلى العمليات على سطح المكتب. بهذه الطريقة البسيطة ، بدأنا في إجراء اختبارات بالتوازي. ولكن هناك العديد من المشاكل في هذه الصورة. أولاً ، تتحكم الاختبارات في المحاكي ، فهي في نفس مكان المحاكي نفسه. أي أنه يجب تشغيلها دائمًا على الخشخاش ، وأنهم يستهلكون الموارد التي يمكن إنفاقها على تشغيل المحاكاة. نتيجة لذلك ، لديك عدد أقل من المحاكيات على الجهاز وتكلفتها أكثر. نقطة أخرى هي أنك بحاجة للذهاب إلى كل جهاز ، تكوين المستخدمين. وبعد ذلك تتعثر في حالة الذروة العالمية. إذا كان هناك خمسة مستخدمين ويثيرون الكثير من العمليات ، فعندئذٍ سينتهي الوصف في النظام. بعد الوصول إلى الحد الأقصى ، ستبدأ الاختبارات في الانخفاض عند محاولة فتح ملفات جديدة وبدء عمليات جديدة.

في 2016-2017 ، قررنا التبديل إلى نموذج مختلف قليلاً. شاهدنا
تقريرًا لورانس لوماكس من Facebook - قدموا fbsimctl ، وأخبروا جزئيًا كيف تعمل البنية التحتية على Facebook. كان هناك أيضًا
تقرير من قبل فيكتور كورونفيتش حول هذا النموذج. لا تختلف الصورة كثيرًا عن الصورة السابقة - لقد تخلصنا للتو من المستخدمين ، ولكن هذه خطوة كبيرة إلى الأمام ، نظرًا لأنه يوجد الآن سطح مكتب واحد فقط ، ويتم تشغيل عمليات أقل ، وأصبحت أجهزة المحاكاة أرخص. هناك ثلاث محاكيات في هذه الصورة ، وليس اثنين ، حيث تم تحرير الموارد لإطلاق محاكاة إضافية. لقد عشنا مع هذا النموذج لفترة طويلة جدًا ، حتى منتصف أكتوبر 2017 ، عندما بدأنا في التحول إلى خادمنا للأجهزة البعيدة.

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

لذلك في بعض الأحيان ، لا يتعين عليك التعامل مع البرامج ، ولكن يمكنك الالتفاف حول تشغيل أجهزة الكمبيوتر المحمولة.
ولكن إذا نظرت إلى هذه الصورة ، فهناك بعض الفوضى من الأسلاك ، والمحولات ، والقصدير بشكل عام. هذا هو الجزء الحديدي ، وكان لا يزال جيدًا. في البرمجيات ، كان هناك تشابك كامل للاختبارات مع البنية التحتية ، وكان من المستحيل الاستمرار في العيش على هذا النحو.
حددنا القضايا التالية:
- حقيقة أن الاختبارات كانت وثيقة الصلة بالبنية التحتية ، وأطلقت المحاكاة وأدارت دورة حياتها بأكملها.
- هذا جعل القياس صعبًا ، لأن إضافة عقدة جديدة تعني إعدادها لكل من الاختبارات وتشغيل المحاكيات. على سبيل المثال ، إذا كنت تريد تحديث Xcode ، فسيتعين عليك إضافة حل مباشر إلى الاختبارات ، لأنها تعمل على إصدارات مختلفة من Xcode. يظهر البعض إذا كانت أكوام لتشغيل المحاكي.
- ترتبط الاختبارات بالآلة التي يوجد بها جهاز المحاكاة ، وهذا يكلف فلساً جميلاً ، حيث يجب تشغيلها على الخشخاش بدلاً من * nix ، وهي أرخص.
- وكان من السهل دائمًا الخوض في المحاكي. في بعض الاختبارات ، انتقلنا إلى نظام الملفات في جهاز المحاكاة ، وحذفنا بعض الملفات هناك أو غيرناها ، وكان كل شيء على ما يرام حتى تم إجراؤه بثلاث طرق مختلفة في ثلاثة اختبارات مختلفة ، ثم بشكل مفاجئ بدأ الرابع في التعطل إذا لم يكن محظوظًا للبدء بعد هؤلاء الثلاثة.
- وفي اللحظة الأخيرة - لم يتم فحص الموارد بأي شكل من الأشكال. على سبيل المثال ، كان هناك أربعة وكلاء TeamCity ، تم توصيل خمس آلات لكل منها ، ولا يمكن إجراء الاختبارات إلا على أجهزتهم الخمسة. لم يكن هناك نظام مركزي لإدارة الموارد ، وبسبب ذلك ، عندما تأتي مهمة واحدة فقط ، تم تشغيلها على خمسة أجهزة ، وجميع 15 الأخرى كانت خاملة. وبسبب هذا ، استغرقت البنايات وقتًا طويلاً جدًا.
نموذج جديد
قررنا التحول إلى نموذج جديد جميل.

إزالة جميع الاختبارات على جهاز واحد ، حيث يعمل وكيل TeamCity. يمكن أن يكون هذا الجهاز الآن على * nix أو حتى على Windows إذا كنت ترغب في ذلك. سوف يتصلون عبر HTTP بشيء نسميه خادم الجهاز. سيتم وضع جميع المحاكيات والأجهزة المادية في مكان ما هناك ، وستجري الاختبارات هنا ، واطلب الجهاز عبر HTTP واستمر في العمل معه. الرسم البياني بسيط للغاية ، هناك عنصران فقط في الرسم التخطيطي.

في الواقع ، بالطبع ، بقي ssh والمزيد خلف الخادم. لكن الآن هذا لا يزعج أي شخص ، لأن الرجال الذين يكتبون الاختبارات هم في الجزء العلوي في هذا الرسم التخطيطي ، ولديهم نوع من الواجهة المحددة للعمل مع جهاز محاكاة محلي أو بعيد ، لذلك فهم بخير. والآن أعمل أدناه ، ولدي كل شيء كما كان. علينا أن نتعايش معها.
ماذا يعطي؟
- أولاً ، تقسيم المسؤولية. في مرحلة ما من اختبار الأتمتة ، يجب أن تعتبره تطوراً طبيعياً. يستخدم نفس المبادئ والأساليب التي يستخدمها المطورون.
- والنتيجة هي واجهة محددة بدقة: لا يمكنك القيام بشيء مباشر باستخدام المحاكي ، لذلك تحتاج إلى فتح تذكرة في خادم الجهاز ، وسنكتشف كيفية القيام بذلك على النحو الأمثل دون كسر اختبارات أخرى.
- أصبحت بيئة الاختبار أرخص لأننا قمنا بتثبيتها في * nix ، وهي أرخص بكثير من خشخاش الخدمة.
- وظهرت مشاركة الموارد ، لأن هناك طبقة واحدة يتواصل معها الجميع ، يمكنها التخطيط لتوزيع الآلات الموجودة خلفها ، أي تقاسم الموارد بين الوكلاء.

أعلاه يصور ، كما كان من قبل. على اليسار وحدات تقليدية من الوقت ، على سبيل المثال ، عشرات الدقائق. هناك نوعان من الوكلاء ، 7 أجهزة محاكاة متصلة بكل منهما ، في الوقت الذي يأتي فيه بناء 0 ويستغرق 40 دقيقة. بعد 20 دقيقة ، يصل آخر ، ويستغرق نفس الوقت. كل شيء يبدو رائعا. ولكن هناك ، وهناك مربعات رمادية. إنهم يعني أننا فقدنا المال لأننا لم نستخدم الموارد المتاحة.

يمكنك القيام بذلك: يأتي الإصدار الأول ويرى جميع المحاكيات المجانية ، ويتم توزيعه ، ويتم تسريع الاختبارات مرتين. لم يكن هناك شيء للقيام به. في الواقع ، يحدث هذا غالبًا لأن المطورين نادرًا ما يدفعون وجبة الغداء في نفس اللحظة. على الرغم من أن هذا يحدث أحيانًا ، ويبدأ "الداما" و "الأهرامات" وما شابه ذلك. ومع ذلك ، في معظم الحالات ، يمكن الحصول على تسريع مجاني مرتين ببساطة عن طريق تثبيت نظام إدارة مركزي لجميع الموارد.
أسباب أخرى للانتقال إلى هذا:
- الملاكمة السوداء ، أي الآن خادم الجهاز هو صندوق أسود. عندما تكتب الاختبارات ، فأنت تفكر فقط في الاختبارات وتعتقد أن هذا الصندوق الأسود سيعمل دائمًا. إذا لم يفلح ذلك ، فقط اذهب وتدق على من يجب أن يفعل ذلك ، وهذا أنا. وعليّ إصلاحه. ليس أنا فقط ، في الواقع ، يشارك العديد من الأشخاص في البنية التحتية بأكملها.
- لا يمكنك إفساد داخل المحاكي.
- لست مضطرًا إلى وضع مليون أداة مساعدة على الجهاز لبدء كل شيء - فأنت فقط تضع أداة واحدة تخفي كل العمل في خادم الجهاز.
- لقد أصبح من الأسهل تحديث البنية التحتية ، والتي سنتحدث عنها في مكان ما في النهاية.
سؤال معقول: لماذا لا شبكة السيلينيوم؟ أولاً ، كان لدينا الكثير من الرموز القديمة ، و 1500 اختبار ، و 130 ألف سطر من الشفرات لمنصات مختلفة. وتم التحكم في كل هذا عن طريق موازٍ للخيار ، مما خلق دورة حياة المحاكي خارج الاختبار. أي أنه كان هناك نظام خاص قام بتحميل جهاز المحاكاة ، منتظراً أن يكون جاهزاً ويخضعه للاختبار. لكي لا نعيد كتابة كل شيء ، قررنا محاولة عدم استخدام شبكة السيلينيوم.
لدينا أيضًا العديد من الإجراءات غير القياسية ، ونادرًا ما نستخدم WebDriver. الجزء الرئيسي من الاختبارات على كالاباش ، و WebDriver مساعد فقط. أي أننا لا نستخدم السيلينيوم في معظم الحالات.
وبالطبع ، أردنا أن يكون كل شيء مرنًا ، وسهل النموذج. لأن المشروع بأكمله بدأ ببساطة بفكرة قرروا اختبارها وتنفيذها خلال شهر ، بدأ كل شيء ، وأصبح القرار الرئيسي في شركتنا. بالمناسبة ، كتبنا أولاً في Ruby ، ثم أعدنا كتابة خادم الجهاز إلى Kotlin. كانت الاختبارات على روبي ، والخادم على Kotlin.
خادم الجهاز
الآن المزيد عن خادم الجهاز نفسه ، وكيف يعمل. عندما بدأنا في البحث عن هذه المشكلة ، استخدمنا الأدوات التالية:
- xcrun simctl و fbsimctl - أدوات سطر الأوامر لإدارة المحاكيات (الأول رسميًا من Apple ، والثاني من Facebook ، وهو أكثر ملاءمة للاستخدام)
- WebDriverAgent ، أيضًا من Facebook ، من أجل تشغيل التطبيقات خارج العملية عند وصول إشعار الدفع أو شيء من هذا القبيل
- ideviceinstaller, - .
, device server, . , fbsimctl , xcrun simctl ideviceinstaller, , fbsimctl WebDriverAgent. - . : - , Facebook . , fbsimctl . :

, .

, .
? , curl list, :

JSON, , . , .

, approve — , . open deep links . , , fbsimctl. , :

, . - . : . , , .
- — . liveshot' iPhone X, iPhone 5S, iPhone 6s. .
- - WebDriverAgent XCUI- , .
- . - iOS 8 , , . device server iOS 8, , , - . fbsimctl.
- , cookies , , , .
- — . , device server , , , , . , . , .

, - , . — , . — , , , .

: Test Runner, ; Device Provider, Device Server, ; Remote Device — ; Device Server — -. , - - fbsimctl WebDriverAgent.
? Test Runner capability, iPhone 6. Device Provider, device server, , - , , , . Device Server . RemoteDevice .
, fbsimctl. , , headless-. , , headless-. - , . , , , syslog SpringBoard .
, XCTest, WebDriverAgent, healthCheck, WebDriverAgent , . , «ready» . healthCheck. , .

fbsimctl. . , WebDriverAgent, . .
— , device server, , , . (release), , , . . , device server , Test Runner . , -, , - .
— . . 30 60. , . , 30 . : , ?
. — . , .
. , , . Separation of Concerns — , , .
. , , Xcode 9, . Xcode 9.2, , — . , - .
Test Runner, rsync, ssh . - *nix, Docker-.
: device server
( GitHub ) , ssh, . device server, ssh, .
Tips & tricks
الآن أهم شيء هو كل أنواع الحيل والأشياء المفيدة التي وجدناها عند إنشاء خادم الجهاز وهذه البنية التحتية.
الأول هو الأبسط. كما تتذكر ، كان لدينا MacBook Pro ، تم تشغيل جميع الاختبارات على أجهزة الكمبيوتر المحمولة. الآن نطلقها على Mac Pro.

فيما يلي تكوينان. هذه هي في الواقع أفضل الإصدارات لكل جهاز. على MacBook ، يمكننا تشغيل 6 محاكيات بشكل متوازٍ. إذا حاولت تحميل المزيد في نفس الوقت ، تبدأ أجهزة المحاكاة في الفشل بسبب حقيقة أنها تحمل المعالج بشكل كبير ، ولديها أقفال متبادلة وما إلى ذلك. يمكنك تشغيل 18 على Mac Pro - من السهل جدًا الحساب ، لأنه بدلاً من 4 هناك 12 مركزًا. نضرب في ثلاثة - تحصل على حوالي 18 محاكاة. في الواقع ، يمكنك محاولة الجري أكثر قليلاً ، ولكن يجب فصلها بطريقة أو بأخرى في الوقت المناسب ، لا يمكنك ، على سبيل المثال ، الجري في دقيقة واحدة. على الرغم من أنه سيكون هناك خدعة مع هذه المحاكيات الـ 18 ، إلا أنها ليست بهذه البساطة.

وهذا هو سعرهم. لا أتذكر كم هو في روبل ، ولكن من الواضح أنها تكلف الكثير. تبلغ تكلفة كل جهاز محاكاة لجهاز MacBook Pro حوالي 400 جنيهًا إسترلينيًا ، ويكلف جهاز Mac Pro 330 جنيهًا إسترلينيًا تقريبًا. وهذا يمثل بالفعل حوالي 70 جنيهًا إسترلينيًا في كل جهاز محاكاة.
بالإضافة إلى ذلك ، كان لابد من تثبيت أجهزة Macbooks بطريقة معينة ، وكانوا يشحنون على المغناطيس ، والتي يجب لصقها على الشريط ، لأنها في بعض الأحيان تسقط. وكان عليك شراء محول لتوصيل إيثرنت ، لأن العديد من الأجهزة القريبة في الصندوق الحديدي على شبكة Wi-Fi لا تعمل بالفعل ، فإنها تصبح غير مستقرة. يكلف المحول أيضًا حوالي 30 جنيهًا إسترلينيًا ، عند القسمة على 6 ، ستحصل على 5 جنيهًا إسترلينيًا آخر لكل جهاز. ولكن ، إذا لم تكن بحاجة إلى هذا التوازي الفائق ، فلديك 20 اختبارًا و 5 محاكيات فقط ، فمن السهل بالفعل شراء جهاز MacBook ، لأنه يمكنك العثور عليه في أي متجر ، وسيتعين عليك طلب وانتظار Mac Pro الأفضل. بالمناسبة ، لقد كلفتنا أرخص قليلاً ، لأننا أخذناها بكميات كبيرة وكان هناك نوع من الخصم. يمكنك أيضًا شراء Mac Pro بذاكرة صغيرة ، ثم ترقية نفسك ، وتوفير المزيد.
ولكن مع Mac Pro ، هناك خدعة واحدة. كان علينا تقسيمها إلى ثلاثة أجهزة افتراضية ، ووضع ESXi هناك. هذه هي المحاكاة الافتراضية للمعدن ، أي ، برنامج Hypervisor المثبت على آلة عارية ، وليس على النظام المضيف. إنه المضيف نفسه ، لذا يمكننا تشغيل ثلاثة أجهزة افتراضية. وإذا قمت بتثبيت نوع من المحاكاة الافتراضية العادية على macOS ، على سبيل المثال Parallels ، فستتمكن من تشغيل جهازين افتراضيين فقط بسبب قيود ترخيص Apple. اضطررت للكسر لأنه في CoreSimulator ، الخدمة الرئيسية التي تقوم بتشغيل المحاكيات ، كانت هناك أقفال داخلية ، وفي الوقت نفسه لم يتم تحميل أكثر من 6 محاكيات ، وبدأوا في الانتظار لشيء ما في قائمة الانتظار ، وأصبح وقت التحميل الإجمالي لـ 18 محاكيًا غير مقبول. بالمناسبة ، تكلفة ESXi هي 0 جنيه إسترليني ، من الجيد دائمًا عندما يكون هناك شيء لا يساوي شيئًا ، ولكنه يعمل بشكل جيد.
لماذا لم نفعل التجميع؟ جزئيا لأننا قمنا بتسريع إعادة تعيين المحاكي. افترض أن تعطل الاختبار ، تريد تنظيف المحاكي بالكامل حتى لا يتعطل الجهاز التالي بسبب الملفات الغامضة المتبقية في نظام الملفات. أبسط حل هو إيقاف تشغيل المحاكي ، ومحو (محو) و التمهيد (التمهيد) بشكل صريح.

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

اتضح 8 ثوان: تسريع التنزيل أكثر من مرتين. في الوقت نفسه ، لم يكن هناك شيء معقد للقيام به ، أي أنه في رمز روبي ، فإنه يأخذ حرفًا خطين. في الصورة ، أعطي مثالاً على باش بحيث يمكن ترجمته بسهولة إلى لغات أخرى.
الحيلة التالية. هناك تطبيق Bumble ، وهو مشابه لـ Badoo ، ولكن بمفهوم مختلف قليلاً ، أكثر إثارة للاهتمام. هناك تحتاج إلى تسجيل الدخول عبر Facebook. في جميع اختباراتنا ، نظرًا لأننا نستخدم مستخدمًا جديدًا من التجمع في كل مرة ، كان علينا تسجيل الخروج من المستخدم السابق. للقيام بذلك ، باستخدام WebDriverAgent ، فتحنا Safari ، وذهبنا إلى Facebook ، وانقر فوق تسجيل الخروج. يبدو جيدًا ، ولكنه يستغرق حوالي دقيقة في كل اختبار. مائة اختبار. مائة دقيقة إضافية.
بالإضافة إلى ذلك ، يحب Facebook أحيانًا إجراء اختبارات A / B ، حتى يتمكنوا من تغيير المواقع ، والنص على الأزرار. فجأة ، ستنخفض مجموعة من الاختبارات ، وسيكون الجميع غير سعداء للغاية. لذلك ، من خلال fbsimctl ، نقوم بعمل list_apps ، الذي يجد جميع التطبيقات.

ابحث عن موبايل سفاري:

وهناك مسار إلى DataContainer ، ويحتوي على ملف ثنائي مع ملفات تعريف الارتباط:

نحن فقط نحذفه - يستغرق 20 مللي ثانية. بدأت الاختبارات تمر بسرعة 100 دقيقة ، وأصبحت أكثر استقرارًا ، لأنها لا يمكن أن تسقط بسبب Facebook. لذلك لا تكون هناك حاجة إلى التوازي في بعض الأحيان. يمكنك العثور على أماكن للتحسين ، إنها سهلة مطروحًا منها 100 دقيقة ، ولا يلزم عمل أي شيء. في الكود ، هذان خطان.
التالي: كيف نجهز الأجهزة المضيفة لتشغيل المحاكاة.

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

الفقرة التالية أكثر صلة بنا ، لأن التطبيق متعلق بالموقع الجغرافي. وغالبًا ما تحتاج إلى تشغيل الاختبارات بحيث يتم تعطيلها في البداية. يمكنك تعيين 3101 في LocationMode. لماذا؟ كانت هناك مقالة في وثائق Apple ، لكنهم حذفوها لسبب ما. الآن هو مجرد ثابت سحري في الشفرة التي نصلي جميعًا من أجلها ونأمل ألا ينكسر. لأنه بمجرد أن ينكسر ، سيكون جميع المستخدمين في سان فرانسيسكو ، لأن fbsimctl يضع مثل هذا الموقع عند التحميل. من ناحية أخرى ، سنكتشف بسهولة ، لأن الجميع سيكونون في سان فرانسيسكو.

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

هناك أيضًا مجموعة من الخيارات المختلفة التي يمكنك تشغيلها / إيقافها. من هذه ، سأذكر فقط SlowMotionAnimation ، لأنني كان لدي يوم ثاني أو ثالث مثير للاهتمام في العمل. لقد أجريت الاختبارات ، وبدأوا جميعًا في الهبوط. لم يجدوا العناصر في المفتش ، رغم أنه كان كذلك. اتضح أنه في ذلك الوقت بدأت تشغيل Chrome ، ضغطت على cmd + T لفتح علامة تبويب جديدة. عند هذه النقطة ، أصبح المحاكي نشطًا واعترض الفريق. وبالنسبة له ، يعد cmd + T تباطؤًا لجميع الرسوم المتحركة بمقدار 10 مرات لتصحيح الرسوم المتحركة. يجب دائمًا إيقاف تشغيل هذا الخيار تلقائيًا إذا كنت ترغب في تشغيل الاختبارات على الأجهزة التي يمكن للأشخاص الوصول إليها ، لأنه يمكنهم بطريق الخطأ كسر الاختبارات عن طريق إبطاء الرسوم المتحركة.
ربما الشيء الأكثر إثارة للاهتمام بالنسبة لي ، منذ أن فعلت ذلك منذ وقت ليس ببعيد ، هو إدارة كل هذه البنية التحتية. 60 مضيفًا افتراضيًا (في الواقع 64 + 6 وكلاء TeamCity) لا أحد يريد طرحه يدويًا. لقد وجدنا أداة
xcversion - وهي الآن جزء من fastlane ، وهي جوهرة روبي يمكن استخدامها كأداة مساعدة لسطر الأوامر: فهي تعمل تلقائيًا على تثبيت Xcode جزئيًا. ثم أخذنا كتب Ansible ، كتبنا ، لنسخ fbsimctl في كل مكان من الإصدار المطلوب ، Xcode ونشر التكوينات لخادم الجهاز نفسه. و Ansible لإزالة وتحديث المحاكيات. عندما ننتقل إلى iOS 11 ، نترك iOS 10. ولكن عندما يقول فريق الاختبار أنه يتخلى تمامًا عن الاختبار التلقائي على iOS 10 ، فإننا ننتقل إلى Ansible وننظف أجهزة المحاكاة القديمة. خلاف ذلك ، فإنها تشغل مساحة كبيرة على القرص.

كيف يعمل؟ إذا كنت تأخذ xcversion وتطلقه على كل جهاز من الأجهزة الستين ، فسيستغرق الأمر الكثير من الوقت ، نظرًا لأنه ينتقل إلى موقع Apple على الويب وينزّل جميع الصور. لتحديث الأجهزة الموجودة في المتنزه ، تحتاج إلى تحديد جهاز عمل واحد ، قم بتشغيل تثبيت xcversion عليه مع الإصدار الضروري من Xcode ، ولكن لا تقم بتثبيت أي شيء أو حذف أي شيء. سيتم تنزيل حزمة التثبيت إلى ذاكرة التخزين المؤقت. يمكن عمل نفس الشيء مع أي نسخة من المحاكي. يتم وضع حزمة التثبيت في ~ / Library / Caches / XcodeInstall. ثم تقوم بتحميل كل شيء باستخدام Ceph ، وإذا لم يكن موجودًا ، فابدأ تشغيل نوع من خادم الويب في هذا الدليل. أنا معتاد على Python ، لذلك أقوم بتشغيل خادم Python Python على الأجهزة.

الآن ، على أي جهاز آخر للمطور أو المختبر ، يمكنك إجراء تثبيت xcversion وتحديد الارتباط بالخادم المرفوع. سيقوم بتنزيل xip من الجهاز المحدد (إذا كانت الشبكة المحلية سريعة ، فسيحدث ذلك على الفور تقريبًا) ، قم بفك الحزمة ، وتأكيد الترخيص - بشكل عام ، سيفعل كل شيء من أجلك. سيكون هناك Xcode يعمل بشكل كامل حيث سيكون من الممكن تشغيل المحاكاة والاختبارات. لسوء الحظ ، لم تكن مريحة جدًا مع المحاكيات ، لذلك عليك القيام بالتجعيد أو wget ، تنزيل حزمة من هذا الخادم إلى جهازك المحلي في نفس الدليل ، وتشغيل محاكاة xcversion - تثبيت. وضعنا هذه المكالمات داخل نصوص Ansible وقمنا بتحديث 60 جهازًا في يوم واحد. تم أخذ الوقت الرئيسي عن طريق نسخ ملفات الشبكة. بالإضافة إلى ذلك ، كنا نتحرك في تلك اللحظة ، أي تم إيقاف تشغيل بعض السيارات. قمنا بإعادة تشغيل Ansible مرتين أو ثلاث للحاق بالسيارات التي كانت غائبة أثناء الحركة.
القليل من استخلاص المعلومات. في الجزء الأول: يبدو لي أن الأولويات مهمة. هذا هو ، أولاً وقبل كل شيء يجب أن يكون لديك استقرار وموثوقية الاختبارات ، ثم السرعة. إذا كنت تسعى للسرعة فقط ، ابدأ بموازاة كل شيء ، فستعمل الاختبارات بسرعة ، ولكن لن ينظر إليها أحد على الإطلاق ، سيعيدون تشغيل كل شيء حتى يمر كل شيء فجأة. أو حتى يسجل في الاختبارات ويدفع للسيد.
النقطة التالية: الأتمتة هي نفس التطور ، لذلك يمكنك فقط أخذ الأنماط التي فكرت بها بالفعل لنا واستخدامها. إذا كانت بنيتك الأساسية الآن مرتبطة ارتباطًا وثيقًا بالاختبارات وتم التخطيط للتوسيع ، فهذه لحظة جيدة للانقسام أولاً ، ثم للتوسع.
والنقطة الأخيرة: إذا كانت المهمة هي تسريع الاختبارات ، فإن أول ما يتبادر إلى الذهن هو إضافة المزيد من المحاكيات لجعلها أسرع ببعض العوامل. في الواقع ، في كثير من الأحيان لا تحتاج إلى الإضافة ، ولكن قم بتحليل التعليمات البرمجية بعناية وتحسين كل شيء مع سطرين ، كما هو الحال في المثال مع ملفات تعريف الارتباط. هذا أفضل من التوازي ، لأنه تم حفظ 100 دقيقة مع سطرين من التعليمات البرمجية ، ومن أجل التوازي ، سيكون عليك كتابة الكثير من التعليمات البرمجية ثم دعم الجزء الحديدي من البنية التحتية. مقابل المال والموارد سيكلف أكثر من ذلك بكثير.
قد يكون الأشخاص المهتمون بهذا التقرير من مؤتمر Heisenbug مهتمين أيضًا بـ Heisenbug التالي: سيتم عقده في موسكو في 6-7 ديسمبر ، ويحتوي موقع المؤتمر بالفعل على أوصاف لعدد من التقارير (وبالمناسبة ، لا يزال قبول طلبات التقارير مفتوحًا).