تلتزم Google بتعزيز المساواة العرقية للمجتمعات السوداء. أنظر كيف.
ترجمت واجهة Cloud Translation API‏ هذه الصفحة.
Switch to English

استهداف مثال للتطبيق

لا تختلف هذه الفئة من اختبار الأجهزة عن تلك التي تستهدف تطبيقات Android العادية. تجدر الإشارة إلى أن التطبيق الاختباري الذي تضمن الأجهزة يحتاج إلى التوقيع بنفس شهادة التطبيق الذي يستهدفه.

لاحظ أن هذا الدليل يفترض أن لديك بالفعل بعض المعرفة في سير عمل شجرة مصدر النظام الأساسي. إذا لم يكن كذلك ، يرجى الرجوع إلى https://source.android.com/source/requirements. المثال المغطى هنا هو كتابة اختبار أجهزة جديد مع حزمة الهدف المحددة في حزمة تطبيق الاختبار الخاصة بها. إذا لم تكن على دراية بالمفهوم ، فيرجى قراءة مقدمة اختبار النظام الأساسي .

يستخدم هذا الدليل الاختبار التالي ليكون بمثابة عينة:

  • الأطر / القاعدة / الحزم / شل / الاختبارات

يوصى باستعراض الرمز أولاً للحصول على انطباع تقريبي قبل المتابعة.

تحديد موقع المصدر

نظرًا لأن اختبار الأجهزة سوف يستهدف تطبيقًا ، فإن القاعدة هي وضع شفرة مصدر الاختبار في دليل tests تحت جذر دليل مصدر المكون الخاص بك في شجرة مصدر النظام الأساسي.

شاهد المزيد من المناقشات حول موقع المصدر في المثال الشامل من أجل اختبارات الأجهزة الذاتية .

ملف البيان

تمامًا مثل التطبيق العادي ، تحتاج كل وحدة اختبار أجهزة إلى ملف بيان. إذا قمت بتسمية الملف باسم AndroidManifest.xml وقمت بتقديمه بجوار Android.mk لنموذج الاختبار الخاص بك ، فسيتم تضمينه تلقائيًا بواسطة ملف BUILD_PACKAGE الأساسي.

قبل المضي قدمًا ، يوصى بشدة بالاطلاع على نظرة عامة على بيان التطبيق أولاً.

هذا يعطي لمحة عامة عن المكونات الأساسية لملف البيان ووظائفها.

يمكن الوصول إلى أحدث إصدار من ملف البيان لنموذج تغيير gerrit على: https://android.googlesource.com/platform/frameworks/base/+/master/packages/Shell/tests/AndroidManifest.xml

يتم تضمين لقطة هنا للراحة:

 <manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.shell.tests">

    <application>
        <uses-library android:name="android.test.runner" />

        <activity
            android:name="com.android.shell.ActionSendMultipleConsumerActivity"
            android:label="ActionSendMultipleConsumer"
            android:theme="@android:style/Theme.NoDisplay"
            android:noHistory="true"
            android:excludeFromRecents="true">
            <intent-filter>
                <action android:name="android.intent.action.SEND_MULTIPLE" />
                <category android:name="android.intent.category.DEFAULT" />
                <data android:mimeType="*/*" />
            </intent-filter>
        </activity>
    </application>

    <instrumentation android:name="android.support.test.runner.AndroidJUnitRunner"
        android:targetPackage="com.android.shell"
        android:label="Tests for Shell" />

</manifest>
 

بعض الملاحظات المختارة على ملف البيان:

 <manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.shell.tests">
 

سمة package هي اسم حزمة التطبيق: هذا هو المعرف الفريد الذي يستخدمه إطار عمل تطبيق Android لتحديد التطبيق (أو في هذا السياق: تطبيق الاختبار الخاص بك). يمكن لكل مستخدم في النظام تثبيت تطبيق واحد فقط باسم الحزمة هذا.

لأن هذا هو حزمة تطبيق الاختبار، مستقلة عن حزمة التطبيق تحت الاختبار، يجب استخدام اسم حزمة مختلف: اتفاقية مشتركة واحدة هي إضافة لاحقة .test .

علاوة على ذلك ، فإن سمة package هذه هي نفسها التي ComponentName#getPackageName() ، وأيضًا نفس الشيء الذي ستستخدمه للتفاعل مع مختلف أوامر pm الفرعية عبر adb shell .

يرجى أيضًا ملاحظة أنه على الرغم من أن اسم الحزمة عادةً ما يكون بنفس نمط اسم حزمة Java ، إلا أنه في الواقع له عدد قليل جدًا من الأشياء التي يمكن القيام بها به. بمعنى آخر ، قد تحتوي حزمة التطبيق (أو الاختبار) الخاصة بك على فئات بأية أسماء حزم ، على الرغم من ذلك ، يمكنك اختيار البساطة ووضع اسم حزمة Java من المستوى الأعلى في تطبيقك أو اختبار مطابق لاسم حزمة التطبيق.

 <uses-library android:name="android.test.runner" />
 

هذا مطلوب لجميع اختبارات الأجهزة حيث أن الفئات ذات الصلة يتم تجميعها في ملف مكتبة جرة إطار عمل منفصل ، وبالتالي تتطلب إدخالات مسار إضافية عند استدعاء حزمة الاختبار بواسطة إطار التطبيق.

 android:targetPackage="com.android.shell"
 

يؤدي ذلك إلى ضبط الحزمة المستهدفة للأجهزة على com.android.shell.tests . عندما يتم استدعاء الأجهزة عبر أمر am instrument ، يقوم الإطار بإعادة تشغيل عملية com.android.shell.tests ، ويحقن كود الأجهزة في العملية لتنفيذ الاختبار. وهذا يعني أيضًا أن شفرة الاختبار ستتمكن من الوصول إلى جميع مثيلات الفئة التي يتم تشغيلها في التطبيق قيد الاختبار وقد تكون قادرة على معالجة الحالة اعتمادًا على خطافات الاختبار المكشوفة.

ملف تكوين بسيط

يجب أن تحتوي كل وحدة اختبار جديدة على ملف تكوين لتوجيه نظام الإنشاء باستخدام بيانات تعريف الوحدة النمطية وتبعيات وقت الترجمة وتعليمات التعبئة. في معظم الحالات ، يكون خيار ملف Blueprint المستند إلى Soong كافيًا. انظر تكوين اختبار بسيط للحصول على التفاصيل.

ملف تكوين معقد

لإجراء اختبارات أكثر تعقيدًا ، تحتاج أيضًا إلى كتابة ملف تكوين اختبار لحزام اختبار Android ، الاتحاد التجاري .

يمكن أن يحدد تكوين الاختبار خيارات إعداد الجهاز الخاصة والوسيطات الافتراضية لتوفير فئة الاختبار.

يمكن الوصول إلى أحدث إصدار من ملف التكوين لعينة تغيير gerrit على: framework / base / package / Shell / اختبارات / AndroidTest.xml

يتم تضمين لقطة هنا للراحة:

 <configuration description="Runs Tests for Shell.">
    <target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
        <option name="test-file-name" value="ShellTests.apk" />
    </target_preparer>

    <option name="test-suite-tag" value="apct" />
    <option name="test-tag" value="ShellTests" />
    <test class="com.android.tradefed.testtype.AndroidJUnitTest" >
        <option name="package" value="com.android.shell.tests" />
        <option name="runner" value="android.support.test.runner.AndroidJUnitRunner" />
    </test>
</configuration>
 

بعض الملاحظات المختارة في ملف تكوين الاختبار:

 <target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
  <option name="test-file-name" value="ShellTests.apk"/>
</target_preparer>
 

هذا يخبر الاتحاد التجاري بتثبيت ShellTests.apk على الجهاز الهدف باستخدام target_preparer محدد. هناك العديد من أدوات التحضير المستهدفة المتاحة للمطورين في الاتحاد التجاري ، ويمكن استخدامها لضمان إعداد الجهاز بشكل صحيح قبل تنفيذ الاختبار.

 <test class="com.android.tradefed.testtype.AndroidJUnitTest">
  <option name="package" value="com.android.shell.tests"/>
  <option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>
 

يحدد هذا فئة اختبار الاتحاد التجاري لاستخدامه في تنفيذ الاختبار ويمر في الحزمة على الجهاز المراد تنفيذه وإطار عداء الاختبار وهو JUnit في هذه الحالة.

انظر هنا لمزيد من المعلومات حول Configs Configs

ميزات JUnit4

يتيح استخدام مكتبة android-support-test كمختبر تشغيل اعتماد فئات اختبار نمط JUnit4 الجديدة ، ويحتوي نموذج تغيير gerrit على بعض الاستخدامات الأساسية جدًا لميزاته.

يمكن الوصول إلى أحدث رمز مصدر لعينة تغيير gerrit في: framework / base / package / Shell / اختبارات / src / com / android / shell / BugreportReceiverTest.java

في حين أن أنماط الاختبار تكون عادةً خاصة بالفرق المكونة ، فهناك بعض أنماط الاستخدام المفيدة بشكل عام.

 @SmallTest
@RunWith(AndroidJUnit4.class)
public final class FeatureFactoryImplTest {
 

هناك فرق كبير في JUnit4 هو أن الاختبارات لم تعد مطلوبة للوراثة من فئة اختبار أساسية مشتركة ؛ بدلاً من ذلك ، تكتب الاختبارات في فئات جافا العادية وتستخدم التعليق التوضيحي للإشارة إلى إعداد اختبار وقيود معينة. في هذا المثال ، نطلب أن يتم تشغيل هذا الفصل كاختبار Android JUnit4.

@SmallTest التعليق التوضيحي @SmallTest حجم اختبار لفئة الاختبار بالكامل: جميع طرق الاختبار المضافة في فئة الاختبار هذه ترث هذا التعليق التوضيحي لحجم الاختبار. إعداد فئة ما قبل الاختبار ، تمزيق ما بعد الاختبار ، وتمزيق فئة ما بعد الاختبار: مشابه setUp و tearDown في JUnit4. Test يستخدم الشرح ليحشي الاختبار الفعلي.

     @Before
    public void setup() {
    ...
    @Test
    public void testGetProvider_shouldCacheProvider() {
    ...
 

و @Before يستخدم الشرح على الأساليب التي JUnit4 لأداء اختبار الإعداد المسبق. على الرغم من عدم استخدامه في هذا المثال ، هناك أيضًا @After لعملية @After الاختبارية اللاحقة. وبالمثل، فإن @BeforeClass و @AfterClass ويمكن استخدام التعليقات على الأساليب التي JUnit4 لأداء الإعداد قبل تنفيذ جميع الاختبارات في فئة الاختبار، وteardown بعد ذلك. لاحظ أنه يجب أن تكون طرق إعداد نطاق الفصل والتمزيق ثابتة.

بالنسبة إلى طرق الاختبار ، على عكس الإصدار السابق من JUnit ، لم تعد بحاجة إلى بدء اسم الطريقة باستخدام test ، بدلاً من ذلك ، يجب وضع تعليق توضيحي على كل منها باستخدام @Test . كالعادة ، يجب أن تكون طرق الاختبار عامة ، ولا تعلن عن أي قيمة إرجاع ، ولا تأخذ أي معلمات ، وقد تؤدي إلى استثناءات.

         Context context = InstrumentationRegistry.getTargetContext();
 

نظرًا لأن اختبارات JUnit4 لم تعد تتطلب فئة أساسية شائعة ، لم يعد من الضروري الحصول على مثيلات Context عبر getContext() أو getTargetContext() عبر طرق الفئة الأساسية ؛ بدلاً من ذلك ، يديرها عداء الاختبار الجديد عبر InstrumentationRegistry حيث يتم تخزين الإعداد السياقي والبيئي الذي تم إنشاؤه بواسطة إطار عمل الأجهزة. من خلال هذه الفئة ، يمكنك أيضًا الاتصال بـ:

  • getInstrumentation() : مثيل لفئة Instrumentation
  • getArguments() : تم تمرير وسيطات سطر الأوامر إلى am instrument عبر -e <key> <value>

قم بالبناء والاختبار محليًا

في حالات الاستخدام الأكثر شيوعًا ، استخدم Atest .

بالنسبة للحالات الأكثر تعقيدًا التي تتطلب تخصيصًا أثقل ، اتبع تعليمات الأجهزة .