الگوهای تست

AOSP شامل قالب‌های آزمایشی برای ماژول‌های آزمایشی است که زیر کلاس پایتون سمت میزبان از BaseTest رانر VTS نیستند.

شکل 1. آزمایش معماری الگو.

توسعه دهندگان می توانند از این الگوها برای به حداقل رساندن تلاش برای ادغام چنین تست هایی استفاده کنند. این بخش پیکربندی و استفاده از الگوهای آزمایشی (واقع در فهرست راهنمای VTS testcases/template ) را پوشش می‌دهد و نمونه‌هایی را برای الگوهای رایج ارائه می‌دهد.

قالب باینری تست

از قالب BinaryTest برای ادغام تست هایی که روی دستگاه مورد نظر در VTS اجرا می شوند، استفاده کنید. تست های سمت هدف عبارتند از:

  • تست‌های مبتنی بر C++ گردآوری و به دستگاه منتقل شدند
  • تست های پایتون سمت هدف به صورت باینری کامپایل شده اند
  • اسکریپت های شل قابل اجرا بر روی دستگاه ها

این تست ها را می توان با یا بدون قالب BinaryTest در VTS ادغام کرد.

تست های سمت هدف را با قالب BinaryTest ادغام کنید

قالب BinaryTest برای کمک به توسعه دهندگان طراحی شده است تا به راحتی تست های سمت هدف را ادغام کنند. در بیشتر موارد، می‌توانید چند خط ساده پیکربندی را در AndroidTest.xml اضافه کنید. پیکربندی نمونه از VtsDeviceTreeEarlyMountTest :

<configuration description="Config for VTS VtsDeviceTreeEarlyMountTest.">
  ...
<test class="com.android.tradefed.testtype.VtsMultiDeviceTest">
<option name="test-module-name" value="VtsDeviceTreeEarlyMountTest"/>
<option name="binary-test-source" value="_32bit::DATA/nativetest/dt_early_mount_test/dt_early_mount_test" />
<option name="binary-test-source" value="_64bit::DATA/nativetest64/dt_early_mount_test/dt_early_mount_test" />
<option name="test-timeout" value="5m"/>
</test>
</configuration>

در این پیکربندی:

  • binary-test-source و binary-test-type مختص الگو هستند.
  • تعیین مسیر میزبان نسبی منبع باینری آزمایشی، الگو را قادر می‌سازد تا آماده‌سازی، فشار دادن فایل، اجرای آزمایش، تجزیه نتایج و پاکسازی را انجام دهد.
  • این الگو شامل روش‌های مربوط به ایجاد موارد آزمایشی برای نادیده گرفتن کلاس‌های فرعی است.
  • این الگو یک مورد آزمایشی را برای هر ماژول باینری آزمایشی فرض می‌کند و نام فایل منبع باینری به‌طور پیش‌فرض به عنوان نام مورد آزمایشی استفاده می‌شود.

گزینه های پیکربندی

قالب BinaryTest از گزینه های پیکربندی زیر پشتیبانی می کند:

نام گزینه نوع ارزش توضیحات
باینری-تست-منبع رشته ها مسیرهای منبع تست باینری نسبت به فهرست راهنمای vts test-case در میزبان.
مثال: DATA/nativetest/test
باینری-تست-دایرکتوری کاری رشته ها دایرکتوری های کاری (مسیر سمت دستگاه).
مثال: /data/local/tmp/testing/
binary-test-envp رشته ها متغیرهای محیطی برای باینری
مثال: PATH=/new:$PATH
باینری-آزمون-آرگ رشته ها آرگومان ها یا پرچم ها را آزمایش کنید.
مثال: --gtest_filter=test1
باینری-تست-ld-library-path رشته ها متغیر محیطی LD_LIBRARY_PATH .
مثال: /data/local/tmp/lib
باینری-test-disable-framework بولی برای خاموش کردن فریم ورک اندروید قبل از تست، adb stop اجرا کنید. مثال: true
سرورهای باینری تست توقف بومی بولی تمام سرورهای بومی که به درستی پیکربندی شده اند را در طول آزمایش متوقف کنید. مثال: true
باینری-تست-نوع رشته نوع قالب سایر انواع الگو از این الگو گسترش می یابند، اما لازم نیست این گزینه را برای این الگو مشخص کنید زیرا قبلاً binary-test-source را مشخص کرده اید.

برای گزینه‌های دارای strings نوع مقدار، می‌توانید چندین مقدار را با تکرار گزینه‌های موجود در پیکربندی اضافه کنید. به عنوان مثال، binary-test-source را دو بار تنظیم کنید (همانطور که در مثال VtsDeviceTreeEarlyMountTest نشان داده شده است).

برچسب های تست

می‌توانید تگ‌های آزمایشی را با پیشوند آن‌ها به گزینه‌های دارای مقادیر strings و استفاده از :: به عنوان جداکننده اضافه کنید. تگ‌های آزمایشی به‌ویژه زمانی مفید هستند که منابع باینری با همان نام اما با بیت‌های متفاوت یا دایرکتوری‌های والد را شامل می‌شوند. به عنوان مثال، برای جلوگیری از فشار فایل یا برخورد نام نتیجه برای منابعی با همان نام اما از دایرکتوری های منبع مختلف، می توانید برچسب های مختلفی را برای این منابع تعیین کنید.

همانطور که در مثال VtsDeviceTreeEarlyMountTest با دو منبع dt_early_mount_test نشان داده شده است، تگ های آزمایشی پیشوندهای _32bit:: و _64bit:: در binary-test-source هستند. برچسب‌هایی که با 32bit یا 64bit ختم می‌شوند، به‌طور خودکار آزمایش‌ها را به‌عنوان در دسترس یک بیت ABI علامت‌گذاری می‌کنند. یعنی تست هایی با تگ _32bit روی ABI 64 بیتی اجرا نمی شوند. عدم تعیین یک برچسب برابر است با استفاده از یک برچسب با یک رشته خالی.

گزینه های دارای تگ های مشابه گروه بندی شده و از سایر برچسب ها جدا می شوند. به عنوان مثال، binary-test-args با تگ _32bit فقط برای binary-test-source با همان تگ اعمال می شود و در binary-test-working-directory با همان تگ اجرا می شود. گزینه binary-test-working-directory برای تست های باینری اختیاری است و به شما این امکان را می دهد که یک پوشه کاری واحد را برای یک برچسب مشخص کنید. هنگامی که گزینه binary-test-working-directory نامشخص باقی می ماند، دایرکتوری های پیش فرض برای هر تگ استفاده می شود.

نام تگ مستقیماً به نام مورد آزمایشی در گزارش نتیجه اضافه می‌شود. به عنوان مثال، testcase1 با برچسب _32bit به عنوان testcase1_32bit در گزارش نتیجه ظاهر می شود.

تست های سمت هدف را بدون الگوی باینری تست یکپارچه کنید

در VTS، قالب آزمایشی پیش‌فرض، تست‌های پایتون سمت میزبان است که از BaseTest در VTS runner گسترش یافته است. برای ادغام تست های سمت هدف، ابتدا باید فایل های تست را به دستگاه فشار دهید، آزمایش ها را با استفاده از دستورات پوسته اجرا کنید، سپس نتایج را با استفاده از اسکریپت های پایتون سمت میزبان تجزیه کنید.

باینری های تست فشار

توصیه می‌کنیم فایل‌ها را با استفاده از آماده‌کننده هدف VtsFilePusher فشار دهید. مثال:

<target_preparer class="com.android.compatibility.common.tradefed.targetprep.VtsFilePusher">
        <option name="push" value="DATA/test->/data/local/tmp/test"/>
    </target_preparer>

VtsFilePusher کارهای زیر را انجام می دهد:

  1. اتصال دستگاه را بررسی می کند.
  2. مسیر فایل منبع مطلق را تعیین می کند.
  3. فایل ها را با استفاده از دستور adb push فشار می دهد.
  4. پس از اتمام تست ها فایل ها را حذف می کند.

از طرف دیگر، می‌توانید فایل‌ها را با استفاده از یک اسکریپت تست پایتون سمت میزبان که از رویه مشابهی پیروی می‌کند، به صورت دستی فشار دهید.

تست ها را اجرا کنید

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

device = self.android_devices[0]
res = device.shell.Execute(["chmod a+x /data/local/tmp/test", "/data/local/tmp/test"])
asserts.AssertFalse(any(res[return_codes]))

قالب GtestBinaryTest

قالب GtestBinaryTest میزبان باینری های آزمایشی GTest است که هر کدام معمولاً شامل چندین مورد آزمایشی است. این الگو با نادیده گرفتن روش‌های راه‌اندازی، ایجاد نمونه‌های آزمایشی و تجزیه نتیجه، الگوی BinaryTest را گسترش می‌دهد، بنابراین تمام تنظیمات BinaryTest به ارث می‌رسد.

GtestBinaryTest گزینه gtest-batch-mode اضافه می کند:

نام گزینه نوع ارزش توضیحات
باینری-تست-نوع رشته نوع قالب از مقدار gtest استفاده می کند.
gtest-batch-mode بولی باینری های Gtest را در حالت دسته ای اجرا کنید. مثال: true

به طور کلی، تنظیم gtest-batch-mode روی true عملکرد را افزایش می دهد در حالی که قابلیت اطمینان را اندکی کاهش می دهد. در تست های انطباق VTS، بسیاری از ماژول ها از حالت دسته ای برای بهبود عملکرد استفاده می کنند. اما برای قابلیت اطمینان، اگر حالت نامشخص باشد، به طور پیش‌فرض روی حالت غیر دسته‌ای قرار می‌گیرد.

حالت غیر دسته ای

حالت غیر دسته‌ای، تماس‌های جداگانه به GTest را برای هر مورد آزمایشی باینری می‌کند. به عنوان مثال، اگر باینری GTest شامل 10 مورد آزمایشی باشد (پس از فیلتر کردن بر اساس پیکربندی سمت میزبان)، باینری هر بار 10 بار در پوسته دستگاه با فیلتر آزمایشی متفاوت فراخوانی می شود. برای هر مورد آزمایشی، یک XML خروجی نتیجه GTest منحصر به فرد تولید و توسط الگو تجزیه می شود.

شکل 2. حالت غیر دسته ای.

مزایای استفاده از حالت غیر دسته ای عبارتند از:

  • جداسازی مورد آزمایشی خرابی یا هنگ کردن در یک مورد آزمایشی روی سایر موارد آزمایش تأثیری ندارد.
  • دانه بندی . دریافت پروفایل/اندازه‌گیری پوشش در هر آزمون، systrace، باگرپورت، logcat و غیره آسان‌تر است. نتایج آزمون و گزارش‌ها بلافاصله پس از پایان هر آزمون بازیابی می‌شوند.

معایب استفاده از حالت غیر دسته ای عبارتند از:

  • بارگذاری اضافی هر بار که GTest باینری فراخوانی می شود، کتابخانه های مرتبط را بارگیری می کند و تنظیمات اولیه کلاس را انجام می دهد.
  • سربار ارتباط . پس از اتمام آزمایش، دستگاه میزبان و هدف برای تجزیه نتیجه و دستورات بعدی با هم ارتباط برقرار می کنند (بهینه سازی های آینده امکان پذیر است).

حالت دسته ای

در حالت دسته‌ای GTest، باینری آزمایشی فقط یک بار با یک مقدار فیلتر آزمایشی طولانی که شامل تمام موارد آزمایشی فیلتر شده توسط پیکربندی سمت میزبان است، فراخوانی می‌شود (این کار از مشکل بارگذاری اضافی در حالت غیر دسته‌ای جلوگیری می‌کند). می توانید نتایج آزمایش GTest را با استفاده از output.xml یا خروجی ترمینال تجزیه کنید.

هنگام استفاده از output.xml (پیش‌فرض):

شکل 3. حالت دسته ای، output.xml.

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

هنگام استفاده از خروجی ترمینال:

شکل 4. حالت دسته ای، خروجی ترمینال.

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

مزایای استفاده از حالت دسته ای عبارتند از:

  • جداسازی مورد آزمایشی در صورتی که فریم ورک باینری/دستگاه را پس از خرابی با فیلتر تست کاهش یافته راه اندازی مجدد کند (به استثنای موارد آزمایش تمام شده و خراب) همان سطح ایزولاسیون مورد آزمایشی را با حالت غیر دسته ای ارائه می دهد.
  • دانه بندی . همان دانه بندی مورد آزمایش را به عنوان حالت غیر دسته ای ارائه می دهد.

معایب استفاده از حالت دسته ای عبارتند از:

  • هزینه نگهداری . اگر فرمت گزارش GTest تغییر کند، همه آزمایش‌ها خراب می‌شوند.
  • گیجی . یک مورد آزمایشی می تواند چیزی شبیه به فرمت پیشرفت GTest را چاپ کند که می تواند فرمت را اشتباه بگیرد.

به دلیل این معایب، گزینه استفاده از خروجی خط فرمان را به طور موقت حذف کرده ایم. برای بهبود قابلیت اطمینان این عملکرد، در آینده این گزینه را دوباره بررسی خواهیم کرد.

قالب HostBinaryTest

قالب HostBinaryTest شامل فایل های اجرایی سمت میزبان است که در سایر دایرکتوری ها یا اسکریپت های پایتون وجود ندارند. این تست ها عبارتند از:

  • باینری های آزمایشی کامپایل شده قابل اجرا بر روی هاست
  • اسکریپت های اجرایی در پوسته، پایتون یا زبان های دیگر

یک مثال تست سمت میزبان سیاست VTS Security SELinux است:

<configuration description="Config for VTS  Security SELinux policy host-side test cases">
    ...
    <test class="com.android.tradefed.testtype.VtsMultiDeviceTest">
        <option name="test-module-name" value="VtsSecuritySelinuxPolicyHost"/>
        <option name="binary-test-source" value="out/host/linux-x86/bin/VtsSecuritySelinuxPolicyHostTest" />
        <option name="binary-test-type" value="host_binary_test"/>
    </test>
</configuration>

HostBinaryTest قالب BinaryTest را گسترش نمی دهد، اما از تنظیمات آزمایشی مشابه استفاده می کند. در مثال بالا، گزینه binary-test-source یک مسیر نسبی سمت میزبان را به فایل اجرایی آزمایشی مشخص می‌کند و binary-test-type host_binary_test است. مانند الگوی BinaryTest، نام فایل باینری به عنوان نام مورد آزمایشی به طور پیش فرض استفاده می شود.

الگوهای موجود را گسترش دهید

می‌توانید از قالب‌ها مستقیماً در پیکربندی آزمایشی برای گنجاندن آزمایش‌های غیر پایتون استفاده کنید یا آنها را در یک کلاس فرعی گسترش دهید تا نیازهای آزمایشی خاص را انجام دهید. قالب های موجود در مخزن VTS دارای پسوندهای زیر هستند:

شکل 5. گسترش قالب های موجود در مخزن VTS.

توسعه دهندگان تشویق می شوند تا هر قالب موجود را برای هر نوع الزامات آزمایشی خاص گسترش دهند. دلایل رایج برای گسترش قالب ها عبارتند از:

  • رویه‌های راه‌اندازی آزمایشی ویژه، مانند آماده‌سازی دستگاهی با دستورات خاص.
  • تولید موارد مختلف تست و نام های تست.
  • تجزیه نتایج با خواندن خروجی فرمان یا استفاده از شرایط دیگر.

برای آسان‌تر کردن گسترش قالب‌های موجود، الگوها حاوی روش‌های تخصصی برای هر عملکرد هستند. اگر طرح‌های بهبود یافته‌ای برای قالب‌های موجود دارید، ما شما را تشویق می‌کنیم که در پایه کد VTS مشارکت کنید.