👂🏼 👨🏻‍💻 🆖 اختبار تطبيقات Flutter: الأدوات ، الفوائد ، التحديات 👃 🎬 🏐

مرحبا! اسمي ماريا ليشينسكايا ، أنا متخصص في ضمان الجودة في Surf. تعمل شركتنا على تطوير تطبيقات أصلية منذ عام 2011 ، ومنذ عام 2018 نعمل أيضًا على تطوير تطبيقات Flutter.

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

تتساوى قدرات الاختبار في Flutter مع القدرات الأصلية

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

عند اختبار التطبيقات الأصلية ، نستخدم في Surf الاختبار التلقائي ونقرأ الحزم ونستبدلها. لا يوجد مكان بدون اختبارات تلقائية ، خاصة مع الانحدار ، وبدون مساعدة وكيل ، تقل تنوع التطبيق وتغطية العديد من الحالات.

كان من المهم بالنسبة لنا أن تظل الميزات المألوفة عند اختبار تطبيقات Flutter.

أختبار ذاتي

يعمل Surf مع أطر عمل Calabash و Ruby للاختبار التلقائي للتطبيقات المحلية. عندما ظهر Flutter ، كان أول ما تساءلنا عنه هو: هل من الممكن عدم استخدام Calabash ، ولكن في نفس الوقت العمل بشكل كامل مع الاختبارات التلقائية بالطريقة التي اعتدنا عليها - أو حتى أكثر برودة.

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

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

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

لاستخدام Gherkin عند اختبار تطبيقات Flutter ، قمنا بتوصيل إطار عمل flutter_gherkin مفتوح المصدر .

عندما أدركنا أن هناك اختبارات تلقائية على Flutter ، تساءلنا ما هي الاختلافات بين تقنيات Calabash و Dart + Gherkin ، أيهما أفضل. لنقارنهم معًا.

1. ملفات الميزات متطابقة تمامًا لكلا الأسلوبين.

على سبيل المثال ، سيتم تفسير النص البرمجي للترخيص بواسطة الرمز السري بشكل صحيح في كل من Dart و Ruby باستخدام Calabash:

:        ( )

تدعم كلتا التقنيتين الروسية والإنجليزية ولغات أخرى.

2. تختلف الخطوات في التنفيذ.

دارت + flutter_gherkin كالاباش

class TapAnErrorButtonOnPinCodeScreen extends ThenWithWorld<FlutterWorld> {
  @override
  Future<void> executeStep() async {
    final elemFromReportAnErrorScreen = find.byValueKey('reportAnErrorButton');
    await FlutterDriverUtils.tap(world.driver, elemFromReportAnErrorScreen);
  }
  @override
  RegExp get pattern => RegExp(r"       -");
}

When(/^       -$/) do
wait_element("* id:'reportAnErrorButton'")
tap_on("* id:'reportAnErrorButton'")
end

هذا لا يعني أيهما أكثر ملاءمة: لا يتغير الهيكل داخل تقنية معينة ، وهذا أمر جيد.

3. يستخدم Flutter ملف .dart إضافيًا لتكوين الاختبارات والعمل معها. مع كالاباش ، لا يوجد ملف واحد من هذا القبيل.

في رأينا ، من المستحيل أن نقول أن هذا رفرفة داخل Flutter أو Calabash - هذه فقط تفاصيل العمل باستخدام أدوات وتقنيات محددة.

4.لتوفير الراحة للعمل مع العناصر في التطبيق ، من الضروري أن يكون لكل عنصر معرف خاص به. عند العمل مع الاختبارات التلقائية مع Calabash ، يجب أن تنتبه مسبقًا إلى أن كلا النظامين لهما معرف في التطبيقات المختبرة. في Dart ، يمكنك إضافة معرف في عملية كتابة الاختبارات التلقائية ، دون إعادة تحميل ملفات تطبيقات iOS و Android بشكل منفصل - وهذا مناسب ويوفر الوقت.

استنتاجنا: الاختبارات التلقائية على Dart ليست أدنى من الاختبارات التلقائية باستخدام إطار Calabash.

الوكلاء

لزيادة تغطية التطبيق حسب الحالات ، يستخدم Surf برامج لقراءة حركة المرور وانتحالها ، مثل Charles. يسمح تحليل التفاعل بين العميل والخادم بما يلي:

حدد ما إذا كان هناك تفاعل حقيقي مع الواجهة الخلفية.
اكتشف من أي جانب تكمن المشكلة: على العميل أو على الخادم.
, .
: , , . Charles , , , .

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

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

شاشة التصحيح مخصصة: يضيف المطورون إليها عناصر إضافية بناءً على طلب المختبرين - على سبيل المثال ، حقول لتهيئة الوكلاء من التطبيق. لذلك ، لدينا فرص كاملة للعمل مع Charles: يمكنك توصيل خادم وكيل بشاشة Debug دون إعادة تشغيل التطبيق.

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

المشكلات: أخطاء في إطار العمل ، وعيوب في مكتبات الطرف الثالث ، والسلوك الأصلي المتوقع

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

دعنا نخبرك ما الذي تبحث عنه عند اختبار تطبيقات Flutter. أعذر من أنذر.

أخطاء Flutter-framework

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

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

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

أوجه القصور في مكتبات الطرف الثالث

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

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

التعامل مع السلوك الأصلي المتوقع

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

تختلف مربعات حوار النظام على كلا النظامين الأساسيين: في iOS ، تحتاج إلى طلب إذن للوصول إلى الإشعارات ، وعلى نظام Android ، يتم منح هذا الوصول افتراضيًا.

غالبًا ما يتعين إنهاء هذه الأجزاء من تفاصيل نظام التشغيل يدويًا. وأحيانًا - لقطع ، إذا فجأة انتقل السلوك المتوقع لمنصة iOS إلى Android ، كما كان الحال مع backwipe.

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

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

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

تم إصلاح هذه الأخطاء من قبل مطورينا داخل المشروع.

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

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

الفوائد: قاعدة بيانات واحدة ، فريق تطوير واحد

تعمل قاعدة الكود الفردية على تقليل وقت الاختبار ،

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

يمكنك البحث عن الأخطاء والتحقق من الميزات على نظام أساسي واحد: مع درجة عالية من الاحتمالية ، يتم تكرارها على كلا النظامين الأساسيين - بعد كل شيء ، هناك تطبيق واحد.

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

, , , : , . , .

, (, iOS), , (Android), event .

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

حاولنا إجراء تقييم تقريبي لاختبار مشروعين متشابهين - أحدهما على نظامي Android و iOS محليين ، والثاني على Flutter - وقمنا بمقارنتهما بشكل شامل.

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

	نظام iOS الأصلي	Android الأصلي	Flutter Android + iOS
استعادة كلمة السر	2 ح	2 ح	3 س 20 د
تفويض	1 س 30 د	1 س 30 د	2 س 20 د
دفع الإخطارات	2 ح	2 ح	4 ح

عند اختبار ميزة جاهزة لا تؤثر بشكل كامل على خصائص نظام التشغيل ولا يتم كتابتها بشكل مخصص لكل منصة على حدة ، يتم تقليل وقت فحص تطبيق Flutter على كلا النظامين بحوالي 1.3-1.5 مرة. على سبيل المثال ، تعمل ميزات التفويض واستعادة كلمة المرور التي ليس لها سلوك محدد على أنظمة أساسية مختلفة على تقليل وقت اختبار إصدار Flutter بمقدار 1.3 مرة.

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

من الأسهل تنظيم الاتصال داخل الفريق

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

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

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

نحن نحب اختبار تطبيقات Flutter

أن تكون جزءًا من مجتمع رائع

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

في الوقت نفسه ، يقدم المطورون من مجتمع Flutter-framework بسرعة ملاحظات حول المشكلات المحددة ، ويحسنون المكتبة ويسمحون لنا بالمساهمة في المشروع: نحن نتقدم معًا ، وهذا أمر رائع.

كن متخصصًا

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

عند تطوير التطبيقات الأصلية واختبارها ، من المستحيل إنشاء تطبيق iOS من ، على سبيل المثال ، Android Studio أو Visual Studio Code. عند العمل مع Flutter ، يكون IDE هو نفسه لكل من Android و iOS. هذا بارد.

كن مستقلاً

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

رفرفة - خطوة للأمام

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

أظهرت الخبرة في تطوير تطبيقات Flutter واختبارها أن هذا الإطار يمثل خطوة كبيرة إلى الأمام.

اختبار تطبيقات Flutter: الأدوات ، الفوائد ، التحديات

تتساوى قدرات الاختبار في Flutter مع القدرات الأصلية

المشكلات: أخطاء في إطار العمل ، وعيوب في مكتبات الطرف الثالث ، والسلوك الأصلي المتوقع

الفوائد: قاعدة بيانات واحدة ، فريق تطوير واحد

نحن نحب اختبار تطبيقات Flutter

رفرفة - خطوة للأمام

More articles: