Google متعهد به پیشبرد برابری نژادی برای جوامع سیاه است. ببینید چگونه.
این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.
Switch to English

هدف قرار دادن یک مثال برنامه

این دسته از تست ابزار دقیق با برنامه هایی که برنامه های معمولی Android را هدف قرار می دهند متفاوت نیست. شایان ذکر است که برنامه آزمایشی که شامل ابزار دقیق است ، باید با همان گواهی برنامه کاربردی که مورد نظر خود را امضا می کند ، امضا شود.

توجه داشته باشید که این راهنما فرض می کند که شما در گردش کار درخت منبع سکو از قبل دانش دارید. اگر اینگونه نیست ، لطفاً به https://source.android.com/source/requirements مراجعه کنید. مثالی که در اینجا آورده شده است نوشتن یک تست ابزار دقیق جدید با بسته هدف است که در بسته نرم افزار آزمون خاص خود قرار دارد. اگر شما با مفهوم آشنا نیستید ، لطفاً از طریق معرفی تست Platform بخوانید.

این راهنما برای استفاده به عنوان نمونه از آزمون زیر استفاده می کند:

  • چارچوب / پایه / بسته ها / پوسته / آزمون

توصیه می شود ابتدا از طریق کد فهرست کنید تا قبل از ادامه کار ، برداشتی خشن از آن داشته باشید.

تصمیم گیری در مورد محل منبع

از آنجا که آزمون ابزار دقیق یک برنامه را هدف قرار می دهد ، قرار است کد منبع آزمون را در یک فهرست راهنمای tests در زیر ریشه فهرست مؤلفه منبع خود در درخت منبع پلتفرم قرار دهید.

بحث های بیشتر در مورد مکان منبع را در مثال پایان به پایان برای تست های سازندگی خود ببینید .

پرونده مانیفست

درست مانند یک برنامه معمولی ، هر ماژول تست ابزار دقیق به یک فایل آشکار نیاز دارد. اگر پرونده را به عنوان AndroidManifest.xml نامگذاری کنید و آن را در کنار Android.mk برای تست tmodule خود تهیه کنید ، به طور خودکار توسط BUILD_PACKAGE هسته اصلی وارد می شود.

قبل از ادامه کار ، ابتدا توصیه می شود که ابتدا به بررسی اجمالی App بپردازید.

این نمای کلی از مؤلفه های اصلی یک فایل مانیفست و ویژگی های آنها را نشان می دهد.

به آخرین نسخه مانیفست برای تغییر گریت نمونه قابل دسترسی است: 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 صفت نام بسته نرم افزار است: این شناسه منحصر به فرد است که با استفاده از چارچوب نرم افزار آندروید برای شناسایی یک برنامه (و یا در این زمینه: نرم افزار آزمون خود را). هر کاربر در سیستم فقط می تواند یک برنامه را با آن نام بسته نصب کند.

از آنجایی که این یک برنامه کاربردی آزمایشی است ، مستقل از بسته برنامه تحت آزمایش ، باید از یک نام بسته متفاوت استفاده شود: یک کنوانسیون مشترک اضافه کردن یک پسوند .test .

علاوه بر این ، این ویژگی package همان چیزی است که ComponentName#getPackageName() برمی گرداند ، و همچنین همان شما را برای تعامل با دستورات مختلف زیر pm از طریق adb shell .

لطفاً توجه داشته باشید که اگرچه نام بسته به طور معمول به همان سبک با نام بسته Java انجام می شود ، اما در حقیقت ارتباط بسیار کمی با آن دارد. به عبارت دیگر ، بسته برنامه (یا آزمون) شما ممکن است شامل کلاس هایی با هر نام بسته باشد ، اگرچه از طرفی می توانید سادگی را برگزینید و نام بسته بالای سطح جاوا را در برنامه خود داشته باشید یا همان تست را با نام بسته برنامه داشته باشید.

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

این مورد برای کلیه تست های ابزار دقیق مورد نیاز است زیرا کلاسهای مرتبط در یک پرونده کتابخانه فریم مجزا بسته بندی می شوند ، بنابراین در هنگام فراخوانی بسته آزمون توسط چارچوب برنامه به ورودی های کلاس اضافی نیاز دارند.

 android:targetPackage="com.android.shell"
 

این مجموعه بسته ابزار دقیق را روی com.android.shell.tests . وقتی این ابزار دقیق از طریق فرمان am instrument فراخوانی am instrument ، فریم ورک فرآیند com.android.shell.tests مجدداً شروع می کند و کد ابزار دقیق را برای اجرای آزمایش به فرآیند تزریق می کند. این همچنین بدان معنی است که کد تست به تمام نمونه های کلاس در حال اجرا در برنامه تحت آزمایش دسترسی خواهد داشت و ممکن است بتواند وضعیت را نیز بستگی به قلاب های آزمایشی در معرض آن داشته باشد.

پرونده پیکربندی ساده

هر ماژول آزمایشی جدید باید یک فایل پیکربندی برای هدایت سیستم ساخت با ابرداده ماژول ، وابستگی به زمان کامپایل و دستورالعمل های بسته بندی داشته باشد. در بیشتر موارد ، گزینه پرونده مبتنی بر سونگ ، Blueprint کافی است. برای جزئیات بیشتر به پیکربندی تست ساده مراجعه کنید.

پرونده پیکربندی پیچیده

برای آزمایش های پیچیده تر ، شما همچنین نیاز به نوشتن پرونده پیکربندی آزمون برای مهار تست اندروید ، فدراسیون تجارت دارید .

پیکربندی آزمون می تواند گزینه های ویژه تنظیم دستگاه و آرگومان های پیش فرض را برای تهیه کلاس تست مشخص کند.

به آخرین نسخه پرونده پیکربندی برای تغییر نمونه گریت می توانید در: چهارچوب ها / پایه / بسته ها / شل / تست / 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 است.

برای اطلاعات بیشتر در مورد پیکربندی های ماژول تست به اینجا مراجعه کنید

ویژگی های JUnit4

استفاده از كتابخانه android-support-test به عنوان دونده آزمایش ، اتخاذ كلاسهای آزمایشی جدید به سبک JUnit4 را امکان پذیر می سازد و تغییر نمونه گریت شامل برخی از کاربردهای اساسی از ویژگیهای آن است.

به آخرین کد منبع تغییر نمونه گریت می توان در: فریم ورکها / پایه / بسته ها / پوسته / تست ها / src / com / اندیشه / پوسته / BugreportReceiverTest.java

در حالی که الگوهای آزمایش معمولاً مختص تیم های کامپوننت هستند ، برخی از الگوهای استفاده عموما مفید هستند.

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

تفاوت قابل توجه در JUnit4 در این است که آزمایش ها دیگر نیازی به ارث بردن از کلاس تست پایه مشترک نیستند. درعوض ، شما در کلاسهای ساده جاوا تست می نویسید و از حاشیه نویسی برای نشان دادن تنظیمات خاص و محدودیت ها استفاده می کنید. در این مثال ، ما در حال آموزش هستیم که این کلاس باید به صورت آزمایشی Android JUnit4 اجرا شود.

حاشیه نویسی @SmallTest اندازه کل آزمون را برای کل کلاس آزمون مشخص کرده است: تمام روشهای آزمایشی اضافه شده به این کلاس آزمایشی این یادداشت اندازه آزمایش را به ارث می برند. پیش آزمون راه اندازی کلاس، آزمون، پس آزمون پایین اشک آور و اشک آور کلاس آزمون پایین: شبیه به setUp و tearDown روش در JUnit4. حاشیه نویسی Test برای حاشیه نویسی از آزمون واقعی استفاده می شود.

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

یادداشت @Before در روش های JUnit4 برای انجام تنظیمات قبل از تست استفاده می شود. اگرچه در این مثال مورد استفاده قرار نمی گیرد ، اما همچنین @After برای @After post test وجود دارد. به همین ترتیب ، @BeforeClass و @AfterClass می توان با استفاده از روش های JUnit4 برای انجام تنظیمات قبل از اجرای کلیه تست ها در یک کلاس آزمایشی و پس از آن مراسم عقب نشینی استفاده کرد. توجه داشته باشید که روشهای تنظیم کلاس و اشکالزدایی باید ثابت باشند.

در مورد روشهای آزمایشی ، برخلاف نسخه قبلی JUnit ، دیگر نیازی به شروع نام روش با test ، درعوض ، باید هرکدام از آنها با @Test حاشیه نویسی @Test . طبق معمول ، روشهای آزمایشی باید عمومی باشند ، هیچ مقدار برگشتی را اعلام نکنند ، هیچ پارامتری نداشته باشند و ممکن است استثنائات ایجاد کنند.

         Context context = InstrumentationRegistry.getTargetContext();
 

از آنجا که JUnit4 آزمون دیگر نیاز به یک کلاس پایه مشترک، لازم دیگر برای به دست آوردن Context موارد از طریق getContext() و یا getTargetContext() از طریق روش های کلاس پایه؛ در عوض ، دونده آزمایشی جدید آنها را از طریق InstrumentationRegistry که در آن تنظیمات متنی و محیطی ایجاد شده توسط چارچوب ابزار دقیق ذخیره می شود ، مدیریت می کند. از طریق این کلاس می توانید تماس بگیرید:

  • getInstrumentation() : نمونه ای از کلاس Instrumentation
  • getArguments() : این آرگومان های خط فرمان به تصویب am instrument طریق -e <key> <value>

بصورت محلی بسازید و آزمایش کنید

برای رایج ترین موارد استفاده ، از Atest استفاده کنید .

برای موارد پیچیده تری که نیاز به سفارشی سازی سنگین تری دارند ، دستورالعمل های ابزار دقیق را دنبال کنید.