يصف هذا المستند أجهزة AVD للاختبارات المعملية، بما في ذلك الفوائد والقيود المعروفة. كما نقدم أيضًا توصيات حول كيفية اختبار تطبيقك طوال دورة حياة التطوير.
على الرغم من أن AVDs الخاصة بـ Test Lab تشبه AVDs في Android Studio ، إلا أن هناك بعض الاختلافات بين الاثنين. على سبيل المثال، تحتوي أجهزة AVD في Test Lab على اتصال بيانات تمت محاكاته بدلاً من اتصال Wi-Fi.
تعد أجهزة AVD الخاصة بـ Test Lab ذات اللاحقة .arm أو (Arm) من المحاكيات المتقدمة التي توفر المزايا التالية:
أسرع وقت تنفيذ الاختبار
تتوافق أحجام الشاشة وكثافاتها مع AVDs في Android Studio لتحقيق الاتساق
يوفر استخدام أجهزة AVD مع اللاحقة .arm أو (Arm) المزايا التالية مقارنة بالأنواع الأخرى من الأجهزة المادية:
| فائدة | وصف | استخدم حالات) |
| توافر عالية | يمكنك إجراء الاختبارات والحصول على نتائج الاختبار بسرعة أكبر عند الاختبار باستخدام الأجهزة الافتراضية. نظرًا لأن الأجهزة الافتراضية يتم إنشاؤها حسب الطلب، تبدأ اختباراتك على الفور تقريبًا، مما يوفر التحقق السريع من صحة تطبيقك. | اختبار التحديثات الصغيرة لتطبيقك، أو لاختبار الانحدار. |
| فترات اختبار أطول | تقتصر الاختبارات التي يتم إجراؤها على الأجهزة المادية على مدة اختبار تبلغ 45 دقيقة على كل جهاز. تدعم الأجهزة الافتراضية مدة اختبار تصل إلى 60 دقيقة. | إجراء اختبارات أطول. |
| تكاليف أقل | يتم تسعير الأجهزة الافتراضية بمبلغ 1 دولار في الساعة لكل جهاز افتراضي يستخدم لاختبار تطبيقك. | الاختبار اليومي باستخدام أنظمة التكامل المستمر، أو قبل التحقق من الكود. لمعرفة المزيد، راجع مستويات الاستخدام والحصص والأسعار الخاصة بـ Test Lab . |
اختبر تطبيقك باستخدام الأجهزة الافتراضية
يمكنك اختبار تطبيقك باستخدام الأجهزة الافتراضية بنفس الطريقة التي تختبره بها مع الأجهزة المادية. ما عليك سوى تحديد الأجهزة الافتراضية عند تحديد أبعاد الاختبار لتكوين مصفوفة الاختبار. لمعرفة المزيد حول إجراء الاختبارات باستخدام Test Lab، راجع بدء اختبار Android باستخدام Firebase Test Lab .
عرض النماذج المدعومة وواجهات برمجة التطبيقات
لعرض نماذج AVD وواجهات برمجة التطبيقات المدعومة بواسطة Test Lab، قم بتشغيل الأمر التالي:
gcloud firebase test android models list --filter=virtual
أفضل الممارسات لاختبار تطبيقك
تعمل الأجهزة الافتراضية على زيادة نطاق خياراتك عند اختبار تطبيقك باستخدام Test Lab. نوصي باستخدام أفضل الممارسات الواردة في هذا القسم لاختبار تطبيقك طوال دورة حياة تطوير التطبيق.
استخدم محاكي Android Studio أو أي جهاز فعلي متصل
عند تطوير تطبيقك، استخدم محاكي Android Studio أو جهازًا فعليًا متصلًا لفحص كل إصدار للتحقق الأولي. إذا كانت لديك اختبارات الأجهزة، فيمكنك أيضًا تشغيل هذه الاختبارات من Android Studio على الأجهزة الفعلية أو الافتراضية التي يوفرها Test Lab.
استخدم أنظمة CI عند كل تغيير في التعليمات البرمجية عند العمل على المشاريع المشتركة
إذا كنت تعمل في مشروع كبير، أو إذا كنت تساهم في المشاريع التي تتم مشاركتها باستخدام GitHub أو خدمة مشابهة، فنوصيك باستخدام أنظمة التكامل المستمر (CI).
اختبر تطبيقاتك على الأجهزة الافتراضية في كل مرة يتم فيها تشغيل نظام CI، أو قبل كل طلب سحب. لمعرفة المزيد حول استخدام Test Lab مع أنظمة CI، راجع استخدام Test Lab لنظام Android مع أنظمة التكامل المستمر .
اختبر تطبيقك على الأجهزة الفعلية باستخدام Test Lab قبل إصدار تحديثات مهمة للتطبيق
قبل أن تقوم بإصدار تحديثات التطبيق مع تغييرات كبيرة في واجهة المستخدم والوظائف، نوصي باستخدام Test Lab لاختبار تطبيقك على الأجهزة الفعلية. سيساعد ذلك على ضمان استقرار تطبيقك وفعاليته على مجموعة واسعة من الأجهزة الفعلية الشائعة. يضمن الاختبار على الأجهزة الفعلية أيضًا تغطية الاختبار لأي وظيفة تطبيق تعتمد على ميزات الجهاز الفعلي التي لا تتم محاكاتها بواسطة الأجهزة الافتراضية. لمعرفة المزيد حول هذه الميزات، راجع القيود المعروفة .
تحديثات الجهاز الظاهري
بشكل دوري، يقوم فريق Android بإضافة صور جديدة للأجهزة الافتراضية، وإلغاء الصور القديمة، وتحديث الصور الموجودة. نحن نطبق هذه التحديثات على صور أجهزتنا الافتراضية للمساعدة في ضمان اختبارك لإصدارات Android الحديثة التي تعكس تجارب المستخدمين.
في حالات نادرة، قد تتسبب هذه التحديثات في فشل الاختبارات بشكل غير متوقع. عندما يكون هناك تحديث معروف يحتمل أن يتعطل، فسيقوم Test Lab بتضمين المعلومات في ملاحظات الإصدار . كأحد أفضل الممارسات، نوصيك باستخدام أطر عمل الاختبار - على سبيل المثال، Espresso - التي تكون قوية في مواجهة هذه التغييرات كلما أمكن ذلك. عندما لا يكون ذلك ممكنًا، نوصيك باستهداف أجهزة Arm الافتراضية، والتي يمكنك توقع تحديثها بشكل أقل تكرارًا.
القيود المعروفة
لا تتم حاليًا محاكاة بعض ميزات الجهاز الفعلي بواسطة الأجهزة الافتراضية، أو تتم محاكاتها مع بعض القيود. يلخص الجدول التالي الميزات غير المتوفرة حاليًا على الأجهزة الافتراضية، أو المتوفرة مع قيود معينة.
| ميزة | تفاصيل |
| واجهات التطبيقات الثنائية (ABI) | لا تدعم جميع الأجهزة جميع واجهات ABI. إذا كنت تقوم بالتطوير باستخدام Android NDK، فتأكد من إنشاء تعليمات برمجية لواجهات ABI التي تدعمها الأجهزة التي تستهدفها. لمزيد من المعلومات، راجع الأجهزة المتوفرة في Test Lab . لمعرفة المزيد حول إدارة ABI، راجع Android ABIs . للتعرف على واجهات ABI التي يدعمها الجهاز، راجع التحقق من أجهزة الاختبار المتاحة . ملاحظة: إذا تم وضع علامة "غير صالح" على الاختبار في مصفوفة الاختبار، فقد يحدث هذا لأن تطبيقك يعتمد على تعليمات برمجية أصلية غير مدعومة بواسطة واجهة برمجة تطبيقات الجهاز. |
| أداء الرسومات | تستخدم الأجهزة الافتراضية Nexus وPixel عرض رسومات البرامج. ستشهد التطبيقات ذات الرسومات المكثفة أداءً أقل. إذا كان تطبيقك يعتمد على الرسومات بكثافة، فاستخدم طرازي SmallPhone.arm و MediumPhone.arm أو الأجهزة الفعلية بدلاً من ذلك. |
| تسجيل الشاشة | يتم تسجيل الشاشة على أجهزة Nexus وPixel بمعدل إطار واحد في الثانية. |
| واجهات برمجة التطبيقات للرسومات | OpenGL ES 3.x غير مدعوم على الأجهزة التي تقل عن مستوى واجهة برمجة التطبيقات (API) 29. الأجهزة الأحدث غير متوافقة بنسبة 100% مع واجهات برمجة تطبيقات OpenGL/Vulkan. قد تلاحظ اختلافات صغيرة في الرسومات. |