مثال على اختبارات الأجهزة الذاتية

عند بدء اختبار قياس حالة التطبيق، تصبح الحزمة المستهدفة إعادة التشغيل مع إدخال رمز الأداة وبدء التنفيذ. وَاحِدْ الاستثناء هو أن الحزمة المستهدفة هنا لا يمكن أن تكون تطبيق Android نفسها، مثل الحزمة android، لأن ذلك يؤدي إلى في وضع متناقض حيث يجب إعادة تشغيل إطار عمل Android، هو ما يدعم وظائف النظام، بما في ذلك الأداة نفسها.

وهذا يعني أن اختبار قياس حالة التطبيق لا يمكنه إدخال نفسه إلى Android إطار العمل، المعروف أيضًا باسم خادم النظام، لتنفيذه. لاختبار Android فإن رمز الاختبار يمكن أن يستدعي فقط أسطح واجهة برمجة التطبيقات العامة، أو باستخدام لغة تعريف واجهة Android برنامج AIDL المتوفر في شجرة المصادر للنظام الأساسي. بالنسبة إلى هذه الفئة من الاختبارات، ليس من المفيد استهداف أي حزمة معينة. لذلك، من المعتاد أن تكون الأدوات المطلوب الإعلان عنها لاستهداف حزمة التطبيق التجريبي الخاصة بها، كما محددة في علامة <manifest> الخاصة بها الخاصة بـ AndroidManifest.xml.

وفقًا للمتطلبات، قد تتمكّن من اختبار حِزم التطبيقات في هذه الفئة. أيضًا:

  • أنشطة الحِزم اللازمة للاختبار.
  • شارِك رقم تعريف المستخدم مع النظام.
  • أن تكون موقَّعة باستخدام مفتاح النظام الأساسي
  • يتم جمعه وفقًا لمصدر إطار العمل بدلاً من حزمة تطوير البرامج (SDK) العامة.

يُشار أحيانًا إلى فئة اختبارات الأدوات باسم الأدوات الذاتية. في ما يلي بعض الأمثلة على اختبارات الأجهزة الذاتية في مصدر المنصة:

المثال الذي نتناوله هنا هو كتابة اختبار قياس جديد مع تحديد الهدف كل حزمة في حزمة التطبيق التجريبي الخاصة بها. يستخدم هذا الدليل ما يلي اختباره ليكون بمثابة مثال:

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

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

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

على افتراض أنّ الموقع الجذر لمصدر المكوّن هو <component source root>، تتضمّن معظم المكوّنات مجلدَين src وtests ضمنه، وبعضها ضمنه مجلدان. ملفات إضافية مثل Android.mk (أو مقسمة إلى .mk من الملفات الإضافية)، وملف البيان AndroidManifest.xml وملف إعداد الاختبار "AndroidTest.xml".

بما أنّك تضيف اختبارًا جديدًا تمامًا، قد تحتاج على الأرجح إلى إنشاء الدليل tests بجانب المكوّن src، وملؤه بالمحتوى.

وفي بعض الحالات، قد يمتلك فريقك بُنى أدلة أخرى ضمن tests. بسبب الحاجة إلى تجميع مجموعات مختلفة من الاختبارات في ملفات APK فردية. و في هذه الحالة، ستحتاج إلى إنشاء دليل فرعي جديد ضمن tests.

بغض النظر عن البنية، سينتهي بك الأمر بتعبئة دليل tests أو الدليل الفرعي الذي تم إنشاؤه حديثًا والذي يحتوي على ملفات مشابهة لما هو موجود في الدليل instrumentation في نموذج تغيير gerrit. يتم شرح تفاصيل كل ملف لاحقًا في هذا المستند.

ملف البيان

وكما هو الحال مع مشروع التطبيق، تتطلب كل وحدة من وحدات اختبار الأدوات باسم AndroidManifest.xml. لتضمين هذا الملف باستخدام ملف BUILD_PACKAGE الأساسي، أدخِل هذا الملف بجانب ملف واحد (Android.mk) لوحدة الاختبار.

إذا لم تكن على دراية بملف AndroidManifest.xml، يمكنك الرجوع إلى نظرة عامة على ملف بيان التطبيق.

في ما يلي نموذج لملف AndroidManifest.xml:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
  android:sharedUserId="android.uid.system"
  package="android.test.example.helloworld" >

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

    <instrumentation android:name="androidx.test.runner.AndroidJUnitRunner"
                     android:targetPackage="android.test.example.helloworld"
                     android:label="Hello World Test"/>

</manifest>

في ما يلي بعض الملاحظات حول ملف البيان:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="android.test.example.helloworld" >

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

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

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

android:sharedUserId="android.uid.system"

توضح هذه السياسة أنّه عند التثبيت، يجب منح ملف APK هذا رقم تعريف المستخدم نفسه، أي هوية بيئة التشغيل، كالمنصة الأساسية. لاحظ أن هذا يعتمد على توقيع حزمة APK باستخدام الشهادة نفسها التي يستخدمها النظام الأساسي الأساسي (اطّلِع على LOCAL_CERTIFICATE في قسم سابق)، لكنّهما مختلفان. المفاهيم:

  • بعض الأذونات أو واجهات برمجة التطبيقات محمية بالتوقيع، مما يتطلب نفس شهادة التوقيع
  • تتطلب بعض الأذونات أو واجهات برمجة التطبيقات هوية مستخدم system للمتصل، الذي يتطلّب من حزمة الاتصال مشاركة رقم تعريف المستخدم مع system، إذا كان حزمة منفصلة عن المنصة الأساسية نفسها
<uses-library android:name="android.test.runner" />

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

android:targetPackage="android.test.example.helloworld"

ربما لاحظت أن targetPackage هنا تم الإعلان عنه باعتباره مماثلاً السمة package المعلَنة في العلامة manifest لهذا الملف. كما ذُكر في أساسيات الاختبار، فإن هذه الفئة من اختبار الأدوات هي مخصص عادةً لاختبار واجهات برمجة التطبيقات لإطار العمل، لذا فليس من المفيد جدًا الحصول على حزمة تطبيق مستهدفة محددة، أو غير ذلك.

ملف الإعداد البسيط

يجب أن تحتوي كل وحدة اختبار جديدة على ملف إعداد لتوجيهها نظام التصميم مع بيانات التعريف للوحدة النمطية، وتبعيات وقت التجميع، وحزمة على التعليمات في معظم الحالات، يكون خيار ملف Blueprint المستند إلى Sung هو كافية. لمعرفة التفاصيل، يُرجى الاطّلاع على إعداد الاختبار البسيط.

ملف إعدادات معقّد

بالنسبة لهذه الحالات الأكثر تعقيدًا، تحتاج أيضًا إلى كتابة تكوين اختبار لتسخير اختبار Android، اتحاد تجاري:

يمكن أن تحدد إعدادات الاختبار خيارات خاصة لإعداد الجهاز وخيارات الإعداد التلقائي وسيطات لتزويد فئة الاختبار. شاهد المثال على /platform_testing/tests/example/instrumentation/AndroidTest.xml

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

<configuration description="Runs sample instrumentation test.">
  <target_preparer class="com.android.tradefed.targetprep.TestFilePushSetup"/>
  <target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
    <option name="test-file-name" value="HelloWorldTests.apk"/>
  </target_preparer>
  <target_preparer class="com.android.tradefed.targetprep.PushFilePreparer"/>
  <target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer"/>
  <option name="test-suite-tag" value="apct"/>
  <option name="test-tag" value="SampleInstrumentationTest"/>

  <test class="com.android.tradefed.testtype.AndroidJUnitTest">
    <option name="package" value="android.test.example.helloworld"/>
    <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="HelloWorldTests.apk"/>
</target_preparer>

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

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

يحدِّد هذا العنصر فئة اختبار Trade Federation التي سيتم استخدامها لتنفيذ الاختبار ويحدد المرات التي يتم فيها تنفيذ الاختبار في الحزمة على الجهاز وإطار عمل أداة تنفيذ الاختبار، وهو JUnit في هذه الحالة.

لمزيد من المعلومات، يُرجى مراجعة إعدادات الوحدة التجريبية:

ميزات JUnit4

يتيح استخدام مكتبة android-support-test كتشغيل اختبار إمكانية اعتماد اختبار نمط JUnit4، ويحتوي نموذج تغيير Grit على بعض الأساسيات واستخدام ميزاتها. شاهد المثال على /platform_testing/tests/example/instrumentation/src/android/test/example/helloworld/HelloWorldTest.java.

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

@RunWith(JUnit4.class)
public class HelloWorldTest {

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

    @BeforeClass
    public static void beforeClass() {
    ...
    @AfterClass
    public static void afterClass() {
    ...
    @Before
    public void before() {
    ...
    @After
    public void after() {
    ...
    @Test
    @SmallTest
    public void testHelloWorld() {
    ...

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

الوصول إلى فئة قياس حالة التطبيق

رغم عدم تناوله في مثال hello world الأساسي، إلا أنه شائع إلى حد ما يتطلب اختبار Android الوصول إلى مثيل Instrumentation: هذه هي واجهة برمجة التطبيقات الأساسية توفّر الوصول إلى سياقات التطبيقات ومراحل نشاط النشاط ذات الصلة بواجهات برمجة التطبيقات وغيرها.

وبما أنّ اختبارات JUnit4 لم تعُد تتطلّب فئة أساسية مشتركة، لم تعُد اللازمة للحصول على مثيل Instrumentation عبر تم تثبيت تطبيق InstrumentationTestCase#getInstrumentation() الجديد بدلاً من ذلك يديره من خلال InstrumentationRegistry حيث يتم وضع الإعداد السياقي والبيئي الذي تم إنشاؤه من خلال إطار عمل الأدوات تخزين البيانات.

للوصول إلى مثيل فئة Instrumentation، ما عليك سوى استدعاء الطريقة الثابتة getInstrumentation() في فئة InstrumentationRegistry:

Instrumentation instrumentation = InstrumentationRegistry.getInstrumentation()

إنشاء التطبيقات واختبارها محليًا

وبالنسبة إلى حالات الاستخدام الأكثر شيوعًا، استخدم تأكيد:

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