پیکربندی تست پیچیده

برخی از ماژول‌های تست ممکن است نیاز به تنظیمات سفارشی و مراحلی برای حذف داشته باشند که در خودِ Test Case قابل انجام نیستند. نمونه‌های معمول ممکن است شامل موارد زیر باشند:

  • نصب فایل‌های apk دیگر (علاوه بر فایل apk آزمایشی)
  • ارسال برخی فایل‌ها به دستگاه
  • دستورات را اجرا کنید (مثلاً adb shell pm ...)

در گذشته، تیم‌های سازنده معمولاً برای انجام چنین وظایفی به نوشتن یک تست سمت میزبان متوسل می‌شدند که مستلزم درک مهار فدراسیون تجاری بود و معمولاً پیچیدگی یک ماژول تست را افزایش می‌داد.

با الهام از CTS، ما مفهوم پیکربندی ماژول تست را برای پشتیبانی از چنین وظایفی معرفی کردیم، لیست وظایف رایج بالا را می‌توان تنها با چند خط پیکربندی انجام داد. برای حداکثر انعطاف‌پذیری، حتی می‌توانید آماده‌ساز هدف خود را، همانطور که توسط ITargetPreparer یا ITargetCleaner تعریف شده است، پیاده‌سازی کنید و آنها را برای استفاده در پیکربندی ماژول تست خود پیکربندی کنید.

پیکربندی ماژول تست برای یک ماژول تست، یک فایل XML مورد نیاز است که به پوشه منبع ماژول سطح بالا با نام 'AndroidTest.xml' اضافه می‌شود. این XML از قالب یک فایل پیکربندی استفاده شده توسط Trade Federation Test Automation Harness پیروی می‌کند. در حال حاضر، تگ‌های اصلی که از طریق پیکربندی‌های ماژول تست مدیریت می‌شوند، تگ‌های "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>

به عنوان مثال، می‌توانیم تگ‌های گزینه زیر را اضافه کنیم (در قسمت توضیحات «insert» در بالا):

    <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. قبل از فراخوانی ماژول آزمایشی، دستور shell "settings put secure accessibility_enabled 1" را روی دستگاه اجرا کنید.
  2. پس از اتمام ماژول آزمایشی، دستور shell را اجرا کنید: "settings put secure accessibility_enabled 0"

در این مثال خاص، دسترسی‌پذیری به ترتیب قبل/بعد از اجرای ماژول آزمایشی فعال/غیرفعال می‌شود. با یک مثال ساده، لازم است جزئیات بیشتری در مورد نحوه استفاده از برچسب «option» پوشش داده شود. همانطور که در بالا نشان داده شد، این برچسب می‌تواند دو ویژگی داشته باشد: نام، مقدار. ویژگی نام باید به یکی از گزینه‌های ارائه شده توسط آماده‌کننده اشاره کند.

هدف دقیق فیلد مقدار (value field) به نحوه تعریف گزینه توسط آماده‌ساز (prepreter) بستگی دارد: می‌تواند یک رشته، عدد، مقدار بولی یا حتی یک مسیر فایل باشد. در اینجا خلاصه‌ای از سه آماده‌ساز هدف رایج آمده است:

  • نام کلاس: PushFilePreparer

    • نام کوتاه : فایل فشاری
    • تابع : فایل‌های دلخواه را در پوشه‌ی مورد آزمایشی به مقصد روی دستگاه ارسال می‌کند.
    • یادداشت‌ها :
      • این آماده‌ساز می‌تواند از پوشه‌ای به پوشه دیگر یا از فایلی به فایل دیگر ارسال کند؛ یعنی، نمی‌توانید فایلی را زیر یک پوشه روی دستگاه ارسال کنید: باید نام فایل مقصد را نیز زیر آن پوشه مشخص کنید.
    • گزینه‌ها :
      • 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
    • تابع: دستورات دلخواه شل را قبل یا بعد از اجرای ماژول تست اجرا می‌کند
    • گزینه‌ها:
      • دستور run: دستور adb shell برای اجرا. ممکن است تکرار شود
      • دستور teardown: دستور adb shell برای اجرا در طول مرحله teardown. ممکن است تکرار شود

کلاس تست

کلاس تست، کلاس فدراسیون تجاری است که برای اجرای تست استفاده می‌شود.

<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: مسیری روی دستگاه که تست‌های native در آن قرار دارند.
  • نام کلاس: تست ابزار دقیق

    • نام کوتاه: ابزار دقیق
    • تابع: آزمایشی که یک بسته تست ابزار دقیق را روی دستگاه داده شده اجرا می‌کند
    • گزینه‌ها:
      • package: نام بسته‌ی مانیفست برنامه‌ی آزمایشی اندروید که قرار است اجرا شود.
      • کلاس: نام کلاس آزمایشی که قرار است اجرا شود.
      • متد: نام متد آزمایشی که قرار است اجرا شود.
  • نام کلاس: AndroidJUnitTest

    • تابع: آزمایشی که یک بسته تست ابزار دقیق را با استفاده از android.support.test.runner.AndroidJUnitRunner روی دستگاه داده شده اجرا می‌کند. این روش اصلی برای اجرای یک تست ابزار دقیق است.