توضّح هذه الصفحة طريقة كتابة اختبار جهاز بنمط JUnit4 من خلال المضيف. وهذا يعني أن الجانب المضيف من الشريط سيؤدي إلى إطلاق إجراءات ضد الجهاز.
يُرجى العِلم أنّنا نعتبر أنّ البيانات "من جهة المضيف" عمليات الاختبار و"القائمة على المضيف" إجراء الاختبارات بشكل طفيف مختلفة:
- الاختبار الذي يديره المضيف: هو اختبار يجري على المضيف ويتفاعل مع مضيف واحد أو المزيد من الأجهزة. النظام قيد الاختبار (SUT) ليس على المضيف نفسه ولكنه الذي يتم اختباره من المضيف.
- الاختبار من جانب المضيف: هو اختبار يجري فقط على المضيف ويختبر شيئًا ما على المضيف فقط، مثل اختبارات الوحدة.
ما هو سبب إنشاء اختبار يعتمد على المضيف بدلاً من اختبار قياس حالة التطبيق؟
قد تتطلب منك بعض الاختبارات التأثير في حالة الجهاز بشكل عام، مثل إصدار إعادة تشغيل الجهاز. في حالة اختبار الأدوات، ستؤدي إعادة التشغيل إلى إنهاء المختلفة، لذلك، تعذّر متابعة الاختبار، ولا تكون هناك أي نتائج متوفرة.
يمكن أن تؤدي الاختبارات من خلال المضيف أيضًا إلى تنفيذ خطوات إعداد إضافية تتطلب تفاعلاً مع الأجهزة الخارجية التي يعتمد عليها الاختبار.
ويمكن للاختبار الذي يديره المضيف التعامل مع حالات الاستخدام هذه والسماح بالاختبار المتقدم الجهاز من خلال المزيد من السيناريوهات. إذا كنت في هذا الموقف، فإن كتابة أكثر منطقية مع الاختبار القائم على المضيف.
كيف تتم كتابة الاختبارات التي يديرها المضيف بتنسيق TF؟
فيما يلي عينة:
@RunWith(DeviceJUnit4ClassRunner.class)
public class SampleHostJUnit4DeviceTest extends BaseHostJUnit4Test {
@Before
public void setUp() throws Exception {
// Some setup
}
@Test
public void testCheckWeHaveDevice() throws Exception {
Assert.assertNotNull(getDevice());
}
}
يتم تشغيل الاختبارات التي يديرها المضيف في الاتحاد التجاري بواسطة DeviceJUnit4ClassRunner وحدة تشغيل اختبار JUnit4. يكون الهيكل العام لفئة الاختبار هو نفسه اختبار JUnit4 العادي:
@BeforeClass
@Before
@Test
@After
@AfterClass
Assume
،Assert
تمديد مهلة BaseHostJunit4Test طريقةً لاكتساب واجهة برمجة تطبيقات برامج الخدمات المفيدة للاختبار، مثل:
installPackage
: يسمح هذا الإذن بتثبيت حزمة APK على الجهاز المستهدَف.installPackageAsUser
: يسمح هذا الإذن بتثبيت حزمة APK كمستخدم على المستوى المستهدَف. الخاص بك.uninstallPackage
: يسمح هذا الإذن بإلغاء تثبيت حزمة APK.isPackageInstalled
: التحقّق مما إذا كان قد تم تثبيت الحزمة أم لاhasDeviceFeature
: التحقّق مما إذا كان الجهاز متوافقًا مع ميزة معيّنة من عدمه (pm list features
)runDeviceTests(DeviceTestRunOptions options)
: تشغيل أداة اختباره على جهاز مستهدف باستخدام DeviceTestRunOptions للتعامل مع جميع الخيارات الممكنة.
يمكنك أيضًا توفير إمكانية الوصول إلى عنصر الجهاز الذي تم استبداله بما يلي:
getDevice()
: يعرض كائن جهاز TF لمعالجة الجهاز.getBuild()
: يعرض كائن TF لمعلومات الإصدار للحصول على معلومات عنgetAbi()
: تعرض واجهة التطبيق الثنائية (ABI) التي يتم إجراء الاختبار وفقًا لها.
الدعم المتبادل: إعداد الجهاز وتنظيفه حسب الفئة
لا يمكن تطبيق JUnit4 @BeforeClass
و@AfterClass
إلا على الطرق الثابتة،
ما يحول دون استخدام معالج #getDevice()
لتنفيذ بعض
الإعداد الخاص بالجهاز أو الإعداد لمرة واحدة أو في الفصل أو التنظيف. لحل هذه المشكلة، استخدم
التعليق التوضيحي المتداول
- @beforeClassWithInfo: يتم التشغيل قبل التعليقات التوضيحية @BeforeClass
- @afterClassWithInfo: يتم تشغيلها بعد التعليقات التوضيحية @afterClass
@BeforeClassWithInfo
public static void beforeClassWithDevice(TestInformation testInfo) {
assertNotNull(testInfo.getDevice());
testInfo.properties().put("mytest:test-prop", "test");
}
@AfterClassWithInfo
public static void afterClassWithDevice(TestInformation testInfo) {
assertNotNull(testInfo.getDevice());
testInfo.properties().put("mytest:test-prop", "test");
}
يسمح لك TestInformation
باستخدام الجهاز وخصائص التخزين التي يمكن
يتم استخدامها إما في النطاق الثابت أو غير الثابت. BaseHostJUnit4Test
متوافق
الحصول على TestInformation
في نطاق غير ثابت من خلال #getTestInformation()
.
في حال عدم تمديد BaseHostJUnit4Test
، يمكنك تنفيذ
ITestInformationReceiver
لاستلام الكائن TestInformation
.
كيف يمكن إعداد اختبار من خلال المضيف في Tradefed؟
في ملف إعداد XML الذي تريد تبادله، يتم إجراء الاختبارات المستندة إلى المضيف من خلال HostTest الجري.
<test class="com.android.tradefed.testtype.HostTest" >
<option name="class" value="android.sample.cts.SampleHostJUnit4DeviceTest" />
</test>