الاتحاد التجاري (Tradefed أو TF للاختصار) هو إطار اختبار مستمر مصمم لإجراء الاختبارات على أجهزة Android. على سبيل المثال، يتم استخدام Tradefed لتشغيل مجموعة اختبار التوافق (CTS) ومجموعة اختبار البائع (VTS) .
Trade Union هو تطبيق Java يتم تشغيله على جهاز كمبيوتر مضيف، ويتصل بجهاز واحد أو أكثر من أجهزة Android باستخدام ddmlib (المكتبة التي تقف خلف DDMS) عبر adb.
لقد قمنا بإدراج بعض الميزات الرئيسية لـ TF أدناه، بالإضافة إلى بعض نماذج حالات الاستخدام. ومع ذلك، إذا كنت تريد البدء مباشرة، فيمكنك التوجه مباشرة إلى صفحة "ابدأ هنا" .
سمات
- تصميم وحدات ومرنة وقابلة للتطوير
- دعمًا مدمجًا لتشغيل العديد من أنواع اختبارات Android المختلفة: الأجهزة ، وuiautomator ، وnative/gtest، وJUnit المستند إلى المضيف، وما إلى ذلك
- يوفر آليات الموثوقية والاسترداد أعلى بنك التنمية الآسيوي
- يدعم جدولة وتشغيل الاختبارات على أجهزة متعددة بالتوازي
راجع الاختبار من خلال TF للحصول على أحدث المعلومات حول كيفية تشغيل اختباراتك الحالية، مثل الأجهزة .
استخدم حالات
إن نمطية الاتحاد التجاري تجعل من السهل الدخول إلى البيئات ذات البنى التحتية الحالية للبناء والاختبار وإعداد التقارير. ندرج أدناه بعض حالات الاستخدام التوضيحية حيث يمكن لـ tradefed تمكين ممارسات اختبار فعالة وقابلة للتطوير.
أولاً، من المفيد النظر في مشهد حالات الاستخدام المحتملة من حيث السؤال "ما هي الأجزاء القابلة للتعديل، وما هي الأجزاء الثابتة؟" على سبيل المثال، يمكن لمصنّع المعدات الأصلية (OEM) للجهاز تعديل إطار العمل والنظام والأجهزة، ولكن تأثيره ضئيل أو معدوم على التطبيقات الموجودة. من ناحية أخرى، يمكن لمطور التطبيقات تعديل التطبيق، ولكن ليس لديه سيطرة تذكر على معظم جوانب النظام أو إطار العمل.
ونتيجة لذلك، سيكون للكيان في كل حالة استخدام أهداف اختبار مختلفة، وسيكون له خيارات مختلفة في حالة وجود مجموعة من حالات فشل الاختبار. على الرغم من هذه الاختلافات، يمكن للاتحاد التجاري المساعدة في جعل كل عملية من عمليات الاختبار الخاصة به فعالة ومرنة وقابلة للتطوير.
الجهاز OEM
تقوم الشركة المصنعة للجهاز ببناء الأجهزة، وغالبًا ما تقوم بتعديل نظام Android وأطر العمل لتعمل بشكل جيد على تلك الأجهزة. قد تسعى الشركة المصنعة الأصلية جاهدة لتحقيق هذه الأهداف مع الحفاظ على الاستقرار والأداء على مستوى الأجهزة والنظام، والتأكد من أن تغييرات إطار العمل لا تؤدي إلى كسر التوافق مع التطبيقات الحالية.
يمكن أن تقوم الشركة المصنعة للمعدات الأصلية (OEM) بتنفيذ وحدة وامضة للجهاز والتي سيتم تنفيذها أثناء مرحلة إعداد الهدف من دورة الحياة . سيكون لهذه الوحدة سيطرة كاملة على الجهاز أثناء فترة التنفيذ، مما يسمح لها بإجبار الجهاز على الدخول إلى أداة تحميل التشغيل، والوميض، ثم إجبار الجهاز على إعادة التشغيل مرة أخرى إلى وضع مساحة المستخدم. بالاقتران مع وحدة نمطية لربطها بنظام بناء مستمر، سيسمح هذا لمصنعي المعدات الأصلية (OEM) بإجراء اختبارات على أجهزتهم أثناء قيامهم بإجراء تغييرات على البرامج الثابتة على مستوى النظام وأطر عمل مستوى Java.
بمجرد تشغيل الجهاز بالكامل، سيكون OEM قادرًا على الاستفادة من الاختبارات القائمة على JUnit، أو كتابة اختبارات جديدة، للتحقق من الوظيفة محل الاهتمام. وأخيرًا، يمكنهم كتابة وحدة واحدة أو أكثر من وحدات تقارير النتائج لربطها بمستودعات نتائج الاختبار الموجودة، أو للإبلاغ عن النتائج مباشرةً (على سبيل المثال، عبر البريد الإلكتروني ).
مطور التطبيق
يقوم مطور التطبيقات بإنشاء تطبيق يحتاج إلى التشغيل بشكل جيد عبر مجموعة متنوعة من إصدارات النظام الأساسي ومجموعة متنوعة من الأجهزة. إذا ظهرت مشكلة على إصدار نظام أساسي و/أو جهاز معين، فإن العلاج الوحيد هو إضافة حل بديل والمضي قدمًا. بالنسبة للمطورين الكبار، قد يتم دمج عملية الاختبار في تسلسل بناء مستمر. بالنسبة للمطورين الصغار، قد يتم إطلاقه بشكل دوري أو يدويًا.
سيستخدم معظم مطوري التطبيقات وحدات تثبيت اختبار APK الموجودة بالفعل في TF. هناك إصدار يتم تثبيته من نظام الملفات المحلي ، بالإضافة إلى إصدار يمكنه تثبيت ملفات APK التي تم تنزيلها من خدمة البناء . من المهم ملاحظة أن الإصدار الأخير سيستمر في العمل بشكل صحيح مع العديد من مثيلات TF التي تعمل على نفس الجهاز المضيف.
نظرًا لمهارة TF في التعامل مع أجهزة متعددة، سيكون من السهل تصنيف كل نتيجة اختبار حسب نوع الجهاز الذي تم استخدامه لهذا الاختبار. وبالتالي، من المحتمل أن يقوم TF بإنشاء مصفوفة توافق ثنائية الأبعاد (أو متعددة الأبعاد) لكل إصدار من التطبيق.
خدمة الاختبار
قد تسمح خدمة الاختبار، على سبيل المثال، لمطوري التطبيقات بإرسال التطبيقات وإجراء الاختبارات على الأجهزة المزودة بأدوات قياس الطاقة لتحديد استخدام الطاقة للتطبيق. يختلف هذا عن حالتي الاستخدام السابقتين من حيث أن منشئ الخدمة لا يتحكم في الأجهزة أو التطبيقات التي يتم تشغيلها.
نظرًا لأن Trade Union يمكنه تشغيل أي فئة Java تقوم بتنفيذ واجهة IRemoteTest البسيطة، فمن السهل كتابة برامج تشغيل يمكنها تنسيق بعض الأجزاء الخارجية من الأجهزة مع حالة الاختبار التي يتم تشغيلها على الجهاز. يمكن لبرنامج التشغيل نفسه إنتاج سلاسل رسائل أو إرسال طلبات إلى خوادم أخرى أو القيام بأي شيء آخر قد يحتاجه. علاوة على ذلك، فإن بساطة وتعدد استخدامات واجهة الإبلاغ عن النتائج، ITestInvocationListener ، تعني أنه من السهل أيضًا تمثيل نتائج الاختبار التعسفية (بما في ذلك، على سبيل المثال، مقاييس الطاقة الرقمية) في مسار تقارير النتائج القياسية.