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