اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
قد تتطلّب بعض وحدات الاختبار خطوات إعداد وإزالة مخصّصة لا يمكن
تنفيذها ضمن نموذج الاختبار نفسه. قد تشمل الأمثلة المعتادة ما يلي:
تثبيت حِزم APK أخرى (بالإضافة إلى حزمة APK الاختبارية)
دفع بعض الملفات إلى الجهاز
تنفيذ الأوامر (مثل adb shell pm ...)
في السابق، كانت فِرق المكوّنات تلجأ عادةً إلى كتابة اختبار على جانب المضيف لأداء هذه المهام، ما يتطلّب فهم حِزمة Trade Federation
ويزيد عادةً من تعقيد وحدة الاختبار .
استنادًا إلى CTS، طرحنا مفهوم إعداد وحدة الاختبار لدعم
هذه المهام، ويمكن تنفيذ قائمة المهام الشائعة أعلاه من خلال بضعة أسطر فقط من
الإعداد. للحصول على أقصى قدر من المرونة، يمكنك أيضًا تنفيذ معالج ملف التوجيه الخاص بك، كما هو محدّد في ITargetPreparer
أو ITargetCleaner،
وضبطه لاستخدامه في إعدادات وحدة الاختبار الخاصة بك.
ملف إعدادات وحدة الاختبار هو ملف XML مطلوب تتم إضافته إلى مجلد مصدر الوحدة في المستوى العلوي ويحمل اسم "AndroidTest.xml". يتّبع ملف XML تنسيق ملف الإعدادات المستخدَم في حِزمة التشغيل الآلي لاختبار Trade Federation.
في الوقت الحالي، العلامتان الرئيسيتان اللتان تتم معالجتهما من خلال إعدادات وحدة الاختبار هما علامتا "target_preparer" و
"test".
مُعدّو التقارير المستهدَفون
تحدِّد علامة target_preparer، كما يشير اسمها، عنصر إعداد هدف
(راجِع ITargetPreparer)
الذي يقدّم طريقة إعداد يتمّ استدعاؤها قبل تنفيذ وحدة الاختبار
للاختبار. وإذا كانت الفئة المُشار إليها في علامة target_preparer تُنفِّذ أيضًا
ITargetCleaner،
سيتمّ استدعاء طريقة الإزالة الخاصة بها بعد انتهاء وحدة الاختبار.
لاستخدام ملف الإعدادات المشترَك المدمج للوحدة، أضِف ملفًا جديدًا باسم "AndroidTest.xml" في ملف الإعدادات المشترَك المدمج للوحدة، واملأه بالمحتوى التالي:
قبل استدعاء وحدة الاختبار، نفِّذ الأمر shell "settings put secure
accessibility_enabled 1" على الجهاز.
بعد الانتهاء من اختبار الوحدة، نفِّذ الأمر shell "settings put secure
accessibility_enabled 0".
في هذا المثال تحديدًا، يتم تفعيل/إيقاف ميزة تسهيل الاستخدام قبل/بعد
تنفيذ وحدة الاختبار، على التوالي. بعد عرض مثال بسيط،
من الضروري تغطية مزيد من التفاصيل حول كيفية استخدام علامة "الخيار". كما هو موضّح أعلاه،
يمكن أن تحتوي العلامة على سمتَين: الاسم والقيمة. يجب أن تشير سمة الاسم إلى
أحد الخيارات التي يقدّمها المُعدّ.
يعتمد الغرض الدقيق من حقل القيمة على كيفية تعريف المُعدّ ل
الخيار: يمكن أن يكون سلسلة أو رقمًا أو قيمة منطقية أو حتى مسار ملف.
في ما يلي ملخّص لثلاثة من أدوات إعداد الاستهداف الشائعة:
function: تُرسِل ملفات عشوائية ضمن مجلد نموذج الاختبار إلى
الوجهة على الجهاز
ملاحظات:
يمكن لبرنامج الإعداد هذا الدفع من مجلد إلى مجلد أو من ملف إلى ملف، أي
لا يمكنك دفع ملف ضمن مجلد على الجهاز: عليك
تحديد اسم الملف الوجهة ضمن هذا المجلد أيضًا.
الخيارات:
push-file: ملف push-spec، الذي يحدّد الملف المحلي بالمسار
الذي يجب دفعه على الجهاز قد يتم تكرار الإجراء. في حال ضبط إعدادات ملفات متعددة لدفعها إلى المسار البعيد نفسه، سيتم دفع الملف
الأحدث.
push:(ميزة متوقّفة نهائيًا) مواصفات دفع، بتنسيق
'/path/to/srcfile.txt->/path/to/destfile.txt' أو
'/path/to/srcfile.txt->/path/to/destdir/'. يمكن تكرارها.
قد يكون هذا المسار نسبيًا لدليل وحدة الاختبار أو دليل out
نفسه.
post-push: أمر يتم تنفيذه على الجهاز (مع "adb shell
<your command>") بعد محاولة تنفيذ جميع عمليات الدفع. عادةً ما يكون استخدام chmod للأذونات هو الحالة المعتادة.
function: اختبار يُجري حزمة اختبارات أداة قياس الأداء على جهاز معيّن باستخدام android.support.test.runner.AndroidJUnitRunner
وهذه هي الطريقة الرئيسية لتنفيذ اختبار أداة قياس الأداء.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["# Complex test configuration\n\n| **Important:** The instructions on this page are needed only for Android [Compatibility Test Suite](/docs/compatibility/cts) (CTS) tests or those that require special setup, such as disabling Bluetooth or collecting sample data. All other cases can be covered by the Soong-based [Simple Test\n| Configuration](/docs/core/tests/development/blueprints) using Blueprints that automate much of the configuration previously conducted manually.\n\nSome test modules may require customized setup and tear down steps that cannot\nbe performed within the test case itself. Typical examples may include:\n\n- install other apks (in addition to the test apk)\n- push some files to the device\n- run commands (e.g. adb shell pm ...)\n\nIn the past, component teams usually resort to writing a host side test to\nperform such tasks, which requires understanding of Trade Federation harness\nand typically increases the complexity of a test module .\n\nBorrowing from CTS, we introduced the concept of test module config to support\nsuch tasks, the common tasks list above can be achieved by just a few lines of\nconfig. For maximum flexibility, you can even implement your own target\npreparer, as defined by [ITargetPreparer](/reference/com/android/tradefed/targetprep/ITargetPreparer)\nor [ITargetCleaner](/reference/com/android/tradefed/targetprep/ITargetCleaner),\nand configure them to use in your own test module config.\n\nA test module config for a test module is a required XML file added to the top\nlevel module source folder, named 'AndroidTest.xml'. The XML follows the format\nof a configuration file used by Trade Federation test automation harness.\nCurrently the main tags handled via the test module configs are the \"target_preparer\" and\n\"test\" tags.\n\nTarget preparers\n----------------\n\nA \"target_preparer\" tag, as the name suggests, defines a target preparer\n(see [ITargetPreparer](/reference/com/android/tradefed/targetprep/ITargetPreparer))\nthat offers a setup method, which gets called before the test module is executed\nfor testing; and if the class referenced in the \"target_preparer\" tag also\nimplements\n[ITargetCleaner](/reference/com/android/tradefed/targetprep/ITargetCleaner),\nits teardown method will be invoked after the test module has finished.\n\nTo use the built-in common module config, add a new file 'AndroidTest.xml' at\nthe top level folder for your test module, and populate it with the following\ncontent: \n\n \u003c?xml version=\"1.0\" encoding=\"utf-8\"?\u003e\n \u003c!-- [insert standard AOSP copyright here] --\u003e\n \u003cconfiguration description=\"Test module config for Foo\"\u003e\n \u003c!-- insert options here --\u003e\n \u003c/configuration\u003e\n\nAs an example, we can add the following option tags (at the \"insert\" comment\nabove): \n\n \u003ctarget_preparer class=\"com.android.tradefed.targetprep.RunCommandTargetPreparer\"\u003e\n \u003coption name=\"run-command\" value=\"settings put secure accessibility_enabled 1\" /\u003e\n \u003coption name=\"teardown-command\" value=\"settings put secure accessibility_enabled 0\" /\u003e\n \u003c/target_preparer\u003e\n\nThe options will configure the test harness to:\n\n1. before test module is invoked, execute shell command \"settings put secure accessibility_enabled 1\" on device\n2. after test module is finished, execute shell command \"settings put secure accessibility_enabled 0\"\n\nIn this particular example, accessibility is enabled/disabled before/after the\ntest module execution, respectively. With a simple example demonstrated, it's\nnecessary to cover more details on how the \"option\" tag is used. As shown above,\nthe tag can have two attributes: name, value. The name attribute must refer to\none of the options offered by the preparer.\n\nThe exact purpose of value field is dependent on how preparer defined\nthe option: it can be a string, a number, a boolean, or even a file path.\nHere's a summary of the three common target preparers:\n\n- class name: [PushFilePreparer](https://android.googlesource.com/platform/tools/tradefederation/+/android16-release/test_framework/com/android/tradefed/targetprep/PushFilePreparer.java)\n\n - **short name**: push-file\n - **function**: pushes arbitrary files under test case folder into destination on device\n - **notes** :\n - this preparer can push from folder to folder, or file to file; that is, you cannot push a file under a folder on device: you must specify the destination filename under that folder as well\n - **options** :\n - **push-file:** A push-spec, specifying the local file to the path where it should be pushed on device. May be repeated. If multiple files are configured to be pushed to the same remote path, the latest one will be pushed.\n - **push:** *(deprecated)* A push-spec, formatted as '`/path/to/srcfile.txt-\u003e/path/to/destfile.txt`' or '`/path/to/srcfile.txt-\u003e/path/to/destdir/`'. May be repeated. This path may be relative to the test module directory or the out directory itself.\n - **post-push:** A command to run on the device (with \\``adb shell\n \u003cyour command\u003e`\\`) after all pushes have been attempted. Typical use case would be using chmod for permissions\n- class name: [InstallApkSetup](https://android.googlesource.com/platform/tools/tradefederation/+/android16-release/test_framework/com/android/tradefed/targetprep/InstallApkSetup.java)\n\n - **short name:**install-apk\n - **function:** pushes arbitrary apk files under into destination on device\n - **options:**\n - **test-file-name:** the name of the apk to be installed on to device.\n - **install-arg:** Additional arguments to be passed to the pm install command, including leading dash, e.g. \"-d\". May be repeated\n- class name: [RunCommandTargetPreparer](https://android.googlesource.com/platform/tools/tradefederation/+/android16-release/src/com/android/tradefed/targetprep/RunCommandTargetPreparer.java)\n\n - **short name:** run-command\n - **function:** executes arbitrary shell commands before or after test module execution\n - **options:**\n - **run-command:**adb shell command to run. May be repeated\n - **teardown-command:**adb shell command to run during teardown phase. May be repeated\n\nTest class\n----------\n\nA test class is the Trade Federation class to use to execute the test. \n\n \u003ctest class=\"com.android.tradefed.testtype.AndroidJUnitTest\"\u003e\n \u003coption name=\"package\" value=\"android.test.example.helloworld\"/\u003e\n \u003coption name=\"runner\" value=\"android.support.test.runner.AndroidJUnitRunner\"/\u003e\n \u003c/test\u003e\n\nHere are three common test classes:\n\n- class name: [GTest](https://android.googlesource.com/platform/tools/tradefederation/+/android16-release/test_framework/com/android/tradefed/testtype/GTest.java)\n\n - **short name:** gtest\n - **function:** A Test that runs a native test package on given device.\n - **options:**\n - **native-test-device-path:**The path on the device where native tests are located.\n- class name: [InstrumentationTest](https://android.googlesource.com/platform/tools/tradefederation/+/android16-release/test_framework/com/android/tradefed/testtype/InstrumentationTest.java)\n\n - **short name:** instrumentation\n - **function:** A Test that runs an instrumentation test package on given device\n - **options:**\n - **package:**The manifest package name of the Android test application to run.\n - **class:**The test class name to run.\n - **method:**The test method name to run.\n- class name: [AndroidJUnitTest](https://android.googlesource.com/platform/tools/tradefederation/+/android16-release/test_framework/com/android/tradefed/testtype/AndroidJUnitTest.java)\n\n - **function:** A Test that runs an instrumentation test package on given device using the android.support.test.runner.AndroidJUnitRunner This is the main way to execute an instrumentation test."]]
