برخی از ماژولهای آزمایشی ممکن است نیاز به تنظیمات سفارشی داشته باشند و مراحلی را از بین ببرند که در خود کیس آزمایشی قابل انجام نباشند. نمونه های معمولی ممکن است شامل موارد زیر باشد:
- نصب apk های دیگر (علاوه بر apk آزمایشی)
- برخی از فایل ها را به دستگاه فشار دهید
- دستورات را اجرا کنید (مثلاً adb shell pm ...)
در گذشته، تیمهای مؤلفه معمولاً برای انجام چنین وظایفی به نوشتن آزمون سمت میزبان متوسل میشدند، که نیاز به درک مهار فدراسیون تجارت دارد و معمولاً پیچیدگی یک ماژول آزمایشی را افزایش میدهد.
با قرض گرفتن از CTS، مفهوم پیکربندی ماژول تست را برای پشتیبانی از چنین وظایفی معرفی کردیم، لیست وظایف رایج در بالا تنها با چند خط پیکربندی قابل دستیابی است. برای حداکثر انعطافپذیری، حتی میتوانید آمادهکننده هدف خود را که توسط ITargetPreparer یا ITargetCleaner تعریف شده است، پیادهسازی کنید و آنها را برای استفاده در پیکربندی ماژول آزمایشی خود پیکربندی کنید.
پیکربندی ماژول آزمایشی برای یک ماژول آزمایشی، یک فایل XML مورد نیاز است که به پوشه منبع ماژول سطح بالا، به نام «AndroidTest.xml» اضافه شده است. XML از فرمت فایل پیکربندی استفاده شده توسط مهار اتوماسیون تست فدراسیون تجارت پیروی می کند. در حال حاضر تگ های اصلی که از طریق پیکربندی های ماژول تست کنترل می شوند، تگ های "target_preparer" و "test" هستند.
تهیه کنندگان هدف
تگ "target_preparer" همانطور که از نام آن پیداست، یک آمادهکننده هدف را تعریف میکند (به ITargetPreparer مراجعه کنید) که یک متد راهاندازی را ارائه میدهد، که قبل از اجرای ماژول تست برای آزمایش فراخوانی میشود. و اگر کلاسی که در تگ "target_preparer" ارجاع داده شده است، ITargetCleaner را نیز پیاده سازی می کند، متد Teardown آن پس از اتمام ماژول تست فراخوانی می شود.
برای استفاده از پیکربندی ماژول مشترک داخلی، یک فایل جدید «AndroidTest.xml» در پوشه سطح بالای ماژول آزمایشی خود اضافه کنید و آن را با محتوای زیر پر کنید:
<?xml version="1.0" encoding="utf-8"?>
<!-- [insert standard AOSP copyright here] -->
<configuration description="Test module config for Foo">
<!-- insert options here -->
</configuration>
به عنوان مثال، میتوانیم تگهای گزینه زیر را اضافه کنیم (در نظر «درج» بالا):
<target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
<option name="run-command" value="settings put secure accessibility_enabled 1" />
<option name="teardown-command" value="settings put secure accessibility_enabled 0" />
</target_preparer>
گزینه ها مهار تست را به شکل زیر پیکربندی می کنند:
- قبل از فراخوانی ماژول تست، دستور پوسته "تنظیمات را امن دسترسی میدهند 1" را روی دستگاه اجرا کنید.
- پس از اتمام ماژول تست، دستور شل را اجرا کنید "تنظیمات امن دسترسی را فعال میکنند 0"
در این مثال خاص، دسترسی به ترتیب قبل و بعد از اجرای ماژول تست فعال/غیرفعال می شود. با ارائه یک مثال ساده، لازم است جزئیات بیشتری در مورد نحوه استفاده از تگ "option" پوشش دهیم. همانطور که در بالا نشان داده شده است، تگ می تواند دو ویژگی داشته باشد: نام، مقدار. ویژگی name نام گزینه را نشان میدهد و بیشتر به دو بخش تقسیم میشود که با دو نقطه از هم جدا میشوند: نام کوتاه برای آمادهکننده، و نام واقعی گزینه ارائهشده توسط آمادهکننده.
هدف دقیق فیلد مقدار به نحوه تعریف آمادهکننده این گزینه بستگی دارد: میتواند یک رشته، یک عدد، یک بولین یا حتی یک مسیر فایل و غیره باشد. در مثال بالا، نام "run-command:run-command" به معنی است. که ما در حال تعیین مقدار برای گزینه "run-command" تعریف شده توسط یک آماده کننده هدف با نام کوتاه "run-command" هستیم. و نام "run-command:teardown-command" به این معنی است که ما برای گزینه "teardown-command" که توسط همان آمادهکننده هدف با نام کوتاه "run-command" تعریف شده است، مقدار تعیین میکنیم. در اینجا خلاصه ای از سه آماده کننده هدف رایج آمده است:
نام کلاس: PushFilePreparer
- نام کوتاه : push-file
- تابع : فایل های دلخواه را در پوشه مورد آزمایشی به مقصد دستگاه فشار می دهد
- یادداشت ها :
- این آماده کننده می تواند از پوشه ای به پوشه دیگر یا فایلی به فایل دیگر را فشار دهد. یعنی نمیتوانید فایلی را زیر یک پوشه در دستگاه فشار دهید: باید نام فایل مقصد را نیز در زیر آن پوشه مشخص کنید.
- گزینه ها :
- push-file: یک push-spec که فایل محلی را در مسیری که باید روی دستگاه فشار داده شود، مشخص می کند. ممکن است تکرار شود. اگر چندین فایل پیکربندی شده باشند تا به یک مسیر راه دور یکسان منتقل شوند، آخرین مورد فشار داده می شود.
- push: (منسوخ شده) یک push-spec، فرمت شده به صورت '
/path/to/srcfile.txt->/path/to/destfile.txt
' یا '/path/to/srcfile.txt->/path/to/destdir/
'. ممکن است تکرار شود. این مسیر ممکن است نسبت به دایرکتوری ماژول تست یا خود دایرکتوری out باشد. - post-push: فرمانی برای اجرا بر روی دستگاه (با
adb shell <your command>
`) پس از انجام تمام فشارها. مورد استفاده معمولی استفاده از chmod برای مجوزها است
نام کلاس: InstallApkSetup
- نام کوتاه: install-apk
- عملکرد: فایلهای apk دلخواه را به مقصد دستگاه فشار میدهد
- گزینه ها:
- test-file-name: نام apk که باید روی دستگاه نصب شود.
- install-arg: آرگومان های اضافی برای ارسال به دستور pm install، از جمله خط تیره، به عنوان مثال "-d". ممکن است تکرار شوند.
نام کلاس: RunCommandTargetPreparer
- نام کوتاه: run-command
- تابع: دستورات پوسته دلخواه را قبل یا بعد از اجرای ماژول آزمایشی اجرا می کند
- گزینه ها:
- run-command: دستور شل adb برای اجرا. ممکن است تکرار شود
- teardown-command: دستور adb shell برای اجرا در مرحله teardown. ممکن است تکرار شود
کلاس تست
یک کلاس تست، کلاس Trade Federation برای اجرای آزمون است.
<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>
در اینجا سه کلاس تست رایج وجود دارد:
نام کلاس: GTest
- نام کوتاه: gtest
- تابع: تستی که بسته آزمایشی بومی را روی دستگاه داده شده اجرا می کند.
- گزینه ها:
- Native-test-device-path: مسیر روی دستگاهی که تست های بومی در آن قرار دارند.
نام کلاس: InstrumentationTest
- نام کوتاه: ابزار دقیق
- تابع: تستی که بسته تست ابزار دقیق را روی دستگاه داده شده اجرا می کند
- گزینه ها:
- بسته: نام بسته مانیفست برنامه آزمایشی اندروید برای اجرا.
- class: نام کلاس آزمایشی برای اجرا.
- روش: نام روش تست برای اجرا.
نام کلاس: AndroidJUnitTest
- تابع: تستی که یک بسته تست ابزار دقیق را با استفاده از android.support.test.runner.AndroidJUnitRunner روی دستگاه داده شده اجرا می کند. این روش اصلی برای اجرای تست ابزار دقیق است.