اختبار تطبيقات Flutter باستخدام Firebase Test Lab: تجربة عملية لاكتشاف مشاكل الأداء
عندما تنتهي من تطوير تطبيق باستخدام Flutter، قد تعتقد أن عملك أصبح جاهزًا بمجرد نجاح الاختبارات وعدم ظهور أي أخطاء أثناء الاستخدام. لكن هل هذا يعني بالضرورة أن التطبيق يعمل بأفضل أداء ممكن؟ وماذا ستفعل إذا لم يتوفر لديك مختبر اختبار أو فريق متخصص لتجربة جميع الشاشات والسيناريوهات قبل إطلاق التطبيق؟
هذه الأسئلة دفعتني إلى تجربة إحدى الأدوات التي لم أستخدمها من قبل، وهي Firebase Test Lab من Google، بهدف اختبار تطبيق Flutter على جهاز حقيقي في بيئة سحابية، ومراقبة سلوكه واستهلاك موارده بدلًا من الاكتفاء بتشغيله على جهازي الشخصي.
الفكرة ليست جديدة، فاختبارات Flutter تشمل بالفعل اختبارات الوحدات والمكونات واختبارات التكامل. لكن تجربة التطبيق على أجهزة فعلية، ومراجعة سجل التفاعلات والصور ومؤشرات الأداء، تضيف مستوى آخر من الفحص قد يساعد على اكتشاف مشكلات لا تظهر أثناء التطوير المعتاد.
في هذا المقال، سأشرح فكرة Firebase Test Lab، وكيفية تجربته مع تطبيق Flutter، وما النتائج التي ظهرت أثناء الاختبار، ولماذا لا يعني اجتياز الاختبار أن التطبيق أصبح خاليًا من جميع المشكلات.
ما هو Firebase Test Lab؟
يُعد Firebase Test Lab خدمة من Google تتيح اختبار تطبيقات Android وiOS على مجموعة من الأجهزة المتاحة سحابيًا، دون الحاجة إلى امتلاك جميع هذه الأجهزة بصورة فعلية.
بدلًا من شراء عدة هواتف وتجربة تطبيقك على كل منها يدويًا، يمكنك رفع نسخة التطبيق إلى الخدمة، واختيار الأجهزة ونوع الاختبار، ثم ترك الاختبار يعمل لتتمكن من مراجعة النتائج بعد انتهائه.
ومن أهم أنواع الاختبارات المتاحة اختبار Robo، الذي يستكشف واجهة التطبيق بصورة آلية، وينفذ تفاعلات مختلفة، مثل الضغط على العناصر والتنقل بين الشاشات. كما تتيح الخدمة تشغيل اختبارات مكتوبة مسبقًا، بما فيها اختبارات التكامل لتطبيقات Flutter.
يمكنك التعرف على الخدمة مباشرة من خلال الموقع الرسمي لـ Firebase Test Lab.
لماذا يحتاج مطور Flutter إلى اختبار إضافي؟
توفر Flutter أدوات اختبار مدمجة تساعد على التأكد من صحة منطق التطبيق وسلوك الواجهات. ومع ذلك، فإن نجاح الاختبارات المحلية لا يضمن أن جميع السيناريوهات ستعمل بصورة صحيحة على كل جهاز.
فعلى سبيل المثال، قد يعمل التطبيق بصورة ممتازة على هاتف المطور، لكن تظهر مشكلة عند استخدام حجم شاشة مختلف، أو التنقل سريعًا بين الشاشات، أو التعامل مع أذونات النظام، أو تشغيل واجهة تحتوي على بيانات كثيرة.
كذلك قد تكون الواجهة خالية من الأعطال، لكن استهلاك الذاكرة يزداد تدريجيًا أثناء الاستخدام، وهو ما يستحق الفحص والتحليل.
لهذا السبب، من المفيد الجمع بين أكثر من أسلوب للاختبار:
- Unit Tests: للتحقق من صحة الدوال والمنطق البرمجي.
- Widget Tests: لاختبار سلوك مكونات Flutter وواجهاتها بصورة معزولة.
- Integration Tests: لاختبار رحلة المستخدم داخل التطبيق والتأكد من عمل مكوناته معًا.
اختبارات الأجهزة الفعلية: لمراقبة السلوك والأداء على بيئات تشغيل مختلفة.
ولا يلزم أن تختار أسلوبًا واحدًا فقط؛ فكل نوع يغطي جانبًا مختلفًا من جودة التطبيق.
تجربتي في اختبار تطبيق Flutter باستخدام Firebase Test Lab
قررت تجربة الخدمة على تطبيق شخصي طورته باستخدام Flutter، وهو تطبيق يساعد على متابعة التمارين والتغذية ومواعيد الوجبات والمكملات.
يتكون التطبيق من نحو 16 شاشة، وقد بنيته باستخدام Clean Architecture وCubit لإدارة الحالة، مع Hive للتخزين المحلي.
كان هدفي معرفة ما إذا كانت الخدمة قادرة على استكشاف الواجهات، وإنتاج تقرير مفيد عن سلوك التطبيق، وتوفير مؤشرات إضافية تساعدني على تحسين الأداء.
الخطوة الأولى: تجهيز التطبيق
بدأت ببناء ملف Android App Bundle، وهو الملف الذي يمكن رفعه إلى Firebase Test Lab لإجراء الاختبار.
بعد ذلك، فتحت Firebase Console وانتقلت إلى قسم Test Lab، ورفعت ملف التطبيق، ثم اخترت اختبار Robo لتجربة استكشاف الواجهة بصورة تلقائية.
الخطوة الثانية: اختيار جهاز للاختبار
في تجربتي، اخترت جهاز Pixel 5 يعمل بنظام Android 11، ثم بدأت الاختبار وتركت الخدمة تتنقل داخل التطبيق.
كانت الفكرة هي مراقبة ما يمكن أن تصل إليه الأداة دون كتابة سيناريو تفصيلي لكل ضغطة أو شاشة.
واستغرقت التجربة نحو 5 دقائق و10 ثوانٍ، وهي المدة التي حصلت بعدها على مجموعة من النتائج التي تستحق المراجعة.
الخطوة الثالثة: مراجعة التقرير
بعد انتهاء الاختبار، لم تكن النتيجة مجرد رسالة تفيد بأن الاختبار نجح، بل تضمنت بيانات تساعد على فهم ما حدث خلال الجلسة، مثل مخطط التنقل ولقطات الشاشة والفيديو ومؤشرات الأداء المتاحة للجهاز.
وهنا بدأت الفائدة الحقيقية للتجربة؛ لأن التقرير أظهر تفاصيل لم أكن أتابعها عادةً خلال تشغيل التطبيق يدويًا.
ما الفرق بين Robo Test وRobo Script؟
يستكشف Robo Test واجهة التطبيق تلقائيًا، وهي ميزة مفيدة للحصول على نظرة أولية عن مسارات التنقل والأخطاء المحتملة دون كتابة سيناريو لكل خطوة.
لكن الاعتماد على الاستكشاف التلقائي وحده لا يكفي دائمًا، خصوصًا عند التعامل مع حقول الأرقام، والقوائم المنسدلة، والنماذج المعقدة، أو السيناريوهات التي تتطلب إدخال بيانات محددة.
هنا يأتي دور Robo Script، الذي يسمح بتوجيه الأداة عبر إجراءات محددة، مثل إدخال نص، أو الضغط على عنصر معين، أو التمرير داخل واجهة، أو الانتظار حتى ظهور عنصر.
وهذا ما أنوي تجربته لاحقًا: بدلًا من الاكتفاء بترك الأداة تستكشف التطبيق، سأجهز سيناريو مخصصًا يمر برحلة استخدام كاملة، من إدخال البيانات إلى حفظ التمرين أو الوجبة ثم العودة إلى الشاشة المناسبة.
يمكنك مراجعة دليل Robo Scripts الرسمي لمعرفة الإجراءات المدعومة وكيفية تخصيص الاختبارات.
تعليقات
إرسال تعليق