المرة الأولى التي نجرب فيها مركز التطبيقات ونتحدث عن تجربتنا

اليوم ، عندما يكون لدى كل من سكان المدن الكبرى كمبيوتر في جيبه يمكنه القيام بأكثر من مجرد الطيران إلى القمر ، فإننا نستخدم تطبيقات الهاتف المحمول كل يوم. الأخبار ، والطقس ، والترقيات ، والتسوق - يتم تنفيذ جميع هذه الوظائف في مئات الآلاف من التطبيقات. ولكن إذا تجمد أو تعطل تطبيقك المفضل ، فسوف يتحول بسرعة إلى المفضلة لديك.

كتب هذا المقال من قبل اللاعبين من WaveAccess.

لقد قمنا بتطوير تطبيقات الهاتف المحمول لأكثر من 10 سنوات ، ولا يمكننا تحمل تكلفة إصدار منتج في أيدي المستخدمين. هذا هو السبب في أن "ضخ" فريق الاختبار والبنية التحتية ليس أقل أهمية بالنسبة لنا من المجالات الأخرى.

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

في هذه المقالة ، نريد أن نقول كيف جربنا خدمة Microsoft App Center الجديدة لأنفسنا للتحقق من جودة التطبيق الذي نقوم بتطويره في حديقة الحيوان للأجهزة الحقيقية.

لماذا طرح السؤال عن استخدام الخدمة

الآن نحن نعمل على تطوير تطبيق لدعم التسوق. استمر المشروع لفترة طويلة: يقدم العميل باستمرار بعض الميزات الجديدة ، فهو يطور فقط من أجل التطوير. هناك بالفعل العشرات من الشاشات في التطبيق ، من "buy" إلى خيارات الرسائل المختلفة ، ودفعات ، و "جمع القوس". وكل هذا الوقت ، يتم تقديم العروض التقديمية للمشروع للمستثمرين ، والتي يتم إطلاقها في مراكز التسوق الجديدة ، وبالتالي كلما كانت سرعة الإصدار أعلى (دون انخفاض جودة المنتج) - كان ذلك أفضل.

حتى الآن ، أجرينا اختبارات تلقائية على عدد محدود من الأجهزة التي كانت تحت تصرفنا (لهذا المشروع - حوالي 30 جهاز Android و "تفاح"). الآن وصل التطبيق إلى مستوى جديد ، نما الجمهور ، وأصبحت الجودة أكثر أهمية. السؤال الذي يطرح نفسه حول استخدام خدمة سحابية لتشغيل الاختبارات التلقائية على أجهزة أكثر مختلفة.

في عملية الإصدار ، أردت استخدام جميع ممارسات تطوير البرامج الحديثة والمثبتة: المراجعة الشاملة والتكامل المستمر واختبار الوظائف والوحدة الآلي في قائمة كبيرة من الأجهزة على نظام iOS + Android ومجموعة من التحليلات والتحطم.

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

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

دراسة نظائرها هي مرحلة مهمة إلى حد ما في اختيار الأداة. لقد بحثنا في العديد من الخدمات التي تقدم مثل هذه القدرات (لاختبارات Appium ، على سبيل المثال ، BrowserStack). في حالة تطبيق Microsoft Center ، تم منحنا فترة تجريبية ، لذا أتيحت لنا الفرصة لتجربة وفهم ما يمكن أن يحدث للمشروع إذا خصصنا موارد أكثر بقليل لجودة وأتمتة عملية إصدار تطبيق الهاتف المحمول بالكامل لأي نظام أساسي مع خدمة واحدة. نقول كيف كان.

كيفية إعداد تطبيق iOS

لذلك ، باستخدام الفترة التجريبية ، التي لا تفرض قيودًا على الوظيفة ، نقوم بإنشاء تطبيق iOS الخاص بنا في مركز تطبيقات Microsoft:

اختر منصة:

أضف SDK App Center إلى المشروع:

pod 'AppCenter' 

بعد تثبيت الموقد ، افتح ملف AppDelegate.swift وأضف الأسطر التالية تحت أمر الاستيراد الخاص بك:

 import AppCenter import AppCenterAnalytics import AppCenterCrashes 

في نفس الملف ، أضف الأسطر التالية إلى أسلوب didFinishLaunchingWithOptions:

 MSAppCenter.start("{Your App Secret}", withServices:[ MSAnalytics.self, MSCrashes.self ]) 

توجد عملية مماثلة للهدف C ، النسخة الكاملة للتعليمات هنا .

Buildim!

انتقل إلى علامة التبويب إنشاء ، حدد خدمة svc الخاصة بنا.

تكوين البناء. لا تنس تسجيل الدخول ، لأن هذا يولد لنا ملف تطبيق تنسيق تطبيق يمكن تشغيله على أجهزة حقيقية:

انتهى انقر فوق الزر "إنشاء الآن" وانتظر الإنشاء.

قصة مماثلة لتطبيقات أندرويد ، والتعليم هنا .

نطلق الاختبارات الأولى لنظام iOS

يمكن تضمين اختبارات الوحدة والوحدة الأصلية لكل منصة في التجميع (هناك علامة اختيار). نحن نتحدث عن وظيفة AT على أجهزة مختلفة أدناه.

قم بإعداد مجموعة من أجهزة iOS وأجهزة Android وإرسال الاختبارات إلى مجموعة

انتقل إلى علامة التبويب اختبار ، مجموعات الأجهزة. نقوم بإنشاء مجموعة من الأجهزة التي سنقوم بإجراء اختباراتنا عليها. هناك أكثر من 250 من أجهزة Android للاختيار من بينها وأكثر من 200 من أجهزة iOS المختلفة (إصدار الجيل + إصدار iOS). قائمة مفصلة من الأجهزة هنا .

كان من المخيبة للآمال بعض الشيء أن الإجابة الرسمية على السؤال ، كيف بعد ظهور الإصدار الجديد من أجهزة Apple الجديدة ، تبدو وكأنها "1-2 أشهر بعد البيع".

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

 Shell: # Generate an XCUITest bundle and your iOS application as described above. $ rm -rf DerivedData $ xcrun xcodebuild build-for-testing -derivedDataPath DerivedData -scheme YOUR_APP_SCHEME # Upload your test to App Center $ appcenter test run xcuitest \ --app "<app center username/<app name>" \ --devices DEVICE_SET \ --test-series "master" \ --locale "en_US" \ --build-dir DerivedData/Build/Products/Debug-iphoneos 

اختبارات Appium

يجدر التأكد من أن أطر الاختبار المستخدمة متسقة مع الأطر المدعومة. بالإضافة إلى ذلك ، يجب عليك استخدام برنامج التشغيل الذي يوفره مركز التطبيقات ، وهذا يفرض قيوده على استخدام الأطر (على سبيل المثال ، لا يمكن استخدام Google Giuce).

مشروع بناء للمستخدمين مخضرم

الخطوة 1. إضافة مستودع والتبعيات

ستحتاج إلى إضافة مستودع JCenter إلى ملف pom.xml.

 XML <repositories> <repository> <id>jcenter</id> <url>https://jcenter.bintray.com/</url> </repository> </repositories> 

ثم أضف تبعية لملحقات اختبارات Appium

 XML <dependency> <groupId>com.microsoft.appcenter</groupId> <artifactId>appium-test-extension</artifactId> <version>1.3</version> </dependency> 

وبالتالي ، أثناء عملية التجميع ، ستتوفر برامج التشغيل الموسعة لنظامي التشغيل Android و iOS (وهي ضرورية أولاً وقبل كل شيء لتنفيذ ميزة "التصنيف" ؛ المزيد حول هذا الموضوع في الخطوة 4).

الخطوة 2. إضافة ملف تعريف التمهيد

انسخ المقتطف إلى pom.xml في <profiles>. إذا كان قسم <ملفات التعريف> مفقودًا في ملف pom ، فأنت بحاجة إلى إنشائه. بعد التنشيط ، يحزم ملف التعريف فئات الاختبار وكل التبعيات في مجلد الهدف / التحميل ، ويكون جاهزًا للتحميل إلى TestCloud.

بناء لمستخدمي Gradle

الخطوة 1. مستودع والتبعيات

نتأكد من أنه في build.gradle في مجلد جذر المشروع ، يتم تنشيط مستودع JCenter:

 gradle allprojects { repositories { jcenter() } } 

أضف المقتطف التالي إلى build.gradle في مجلد التطبيق:

 gradle androidTestCompile('com.microsoft.appcenter:appium-test-extension:1.0') 

بدءًا من Gradle 3.0 ، يتم إهمال androidTestCompile. بدلاً من ذلك ، تحتاج إلى androidTestImplementation.

الخطوة 2. أتمتة إنشاء ملف بوم

لكي يعمل القائم بالتحميل ، يكون ملف pom.xml مطلوبًا. أضف المقتطف التالي في build.gradle في مجلد التطبيق بحيث يتم جمع ملف pom تلقائيًا:

 gradle apply plugin: 'maven' task createPom { pom { withXml { def dependenciesNode = asNode().appendNode('dependencies') //Iterate over the compile dependencies (we don't want the test ones), adding a <dependency> node for each configurations.testCompile.allDependencies.each { def dependencyNode = dependenciesNode.appendNode('dependency') dependencyNode.appendNode('groupId', it.group) dependencyNode.appendNode('artifactId', it.name) dependencyNode.appendNode('version', it.version) } def profilesNode = asNode().appendNode('profiles') profilesNode.append(new XmlParser().parse('https://raw.githubusercontent.com/Microsoft/AppCenter-Test-Appium-Java-Extensions/master/gradleuploadprofilesnippet.xml')) } }.writeTo("pom.xml") 

اختبار التغييرات

الخطوة 1. إضافة الواردات

استيراد الحزم إلى فئات الاختبار الخاصة بك:

 Java import com.microsoft.appcenter.appium.Factory; import com.microsoft.appcenter.appium.EnhancedAndroidDriver; import org.junit.rules.TestWatcher; import org.junit.Rule; 

الخطوة 2. إنشاء مثيل TestWatcher

إضافة إلى كل فئة اختبار القاعدة JUnit (أو فئة الاختبار الأساسي):

 Java @Rule public TestWatcher watcher = Factory.createWatcher(); 

الخطوة 3. تغيير نوع السائق

قم بتغيير نوع برنامج التشغيل عند إعلانه ، إما من AndroidDriver <MobileElement> إلى EnhancedAndroidDriver <MobileElement> ، أو من IOSDriver <MobileElement> إلى EnhancedIOSDriver <MobileElement>

 Java private static EnhancedAndroidDriver<MobileElement> driver; 

الخطوة 4. تحديث مثيلات برنامج التشغيل

نقوم بتغيير مثيلات برنامج التشغيل بحيث خطوط النموذج:

 Java driver = new AndroidDriver<MobileElement>(url, capabilities); 

... تغير في المظهر:

 Java driver = Factory.createAndroidDriver(url, capabilities); 

سيظل استخدام برامج التشغيل هذه يسمح لك بإجراء الاختبارات محليًا دون تعديلات إضافية ، ولكن بالإضافة إلى ذلك سوف يسمح لك بإضافة "تسمية" إلى الخطوات الموجودة في الاختبار القابل للتنفيذ باستخدام driver.label ("النص الخاص بك"). سيتوفر النص ولقطات الشاشة من الجهاز في تقرير الاختبار في Test Cloud. يوصى بشدة بالوصول إلى الملصق من خلال الأسلوب After ، حيث سيؤدي ذلك إلى إضافة لقطة شاشة للحالة الأخيرة للتطبيق إلى تقرير الاختبار.

سيتم التقاط لقطة شاشة حتى إذا فشل الاختبار. كقاعدة عامة ، توجد معلومات كافية لفهم سبب حدوث ذلك. تطبيق مثال في الأسلوب After :

 Java: @After public void TearDown(){ driver.label("Stopping App"); driver.quit(); } 

تنزيل إلى اختبار مركز التطبيقات

عملية التحميل هي كما يلي:

1. قم بإنشاء أمر تحميل اختبار مركز التطبيقات. التوثيق (EN) - بدء تشغيل الاختبار .
2. نقوم بحزم فصول الاختبار وجميع التبعيات في مجلد الهدف / التحميل

قذيفة:

1. mvn -DskipTests -P التحضير لحزمة التحميل
2. بدأ التنزيل وتشغيل الاختبارات

عند الانتهاء ، يمكننا عرض النتائج على كل جهاز من القائمة:

شاشات مع النتائج والسجلات والتقرير

على كل جهاز من أجهزة iOS أو Android ، يمكنك عرض سجل تفصيلي ولقطات شاشة لتشخيص تعطل الاختبار:

بالإضافة إلى إحصائيات جميع عمليات الإطلاق خلال فترة زمنية:

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

الاستنتاجات

من المثير للدهشة أن عملية الإصدار بأكملها بدءًا من التكامل المستمر وحتى التسليم المستمر للتطبيق يتم توفيرها في مكان واحد: يوفر Microsoft App Center بناء CI واختباره ونشره للتخزين والتحليلات والتحطم.

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

• لا حاجة لرفع الخادم لمجموعة من الأجهزة.
• لا حاجة لتوصيل 100500 جهاز بهذا الخادم.
• لا حاجة للعيش مع مواطن الخلل الروبوت عندما يتم تشغيله 24 \ 7.
• لا حاجة لتجميع حاوية للجهاز ، لا حاجة لإدارة هذه الحاويات.
• لا حاجة لتحمل محاكيات محدودة.

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