AOSP شامل الگوهای آزمایشی برای واحدهای آزمایشی است که زیرکلاس Python سمت میزبان از VTS runner's BaseTest نیستند.
توسعه‌دهندگان می‌توانند از این الگوها برای به‌حداقل رساندن تلاش لازم برای ادغام چنین آزمایش‌هایی استفاده کنند. این بخش پیکربندی و استفاده از الگوهای آزمایشی (واقع در فهرست راهنمای VTS testcases/template) را پوشش می‌دهد و مثال‌هایی برای الگوهای رایج ارائه می‌دهد.
الگوی BinaryTest
از BinaryTest template برای ادغام آزمون‌هایی که در دستگاه هدف در VTS اجرا می‌شوند استفاده کنید. آزمایش‌های سمت هدف شامل موارد زیر است:
- آزمایش‌های مبتنی بر C++ کامپایل و به دستگاه ارسال می‌شود
- آزمایش‌های Python سمت هدف به‌عنوان دودویی کامپایل شده‌اند
- دستورات پوسته در دستگاه‌ها اجراپذیر است
این آزمایش‌ها را می‌توان با یا بدون الگوی 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 از گزینه‌های پیکربندی زیر پشتیبانی می‌کند:
| نام گزینه | نوع مقدار | شرح |
|---|---|---|
| binary-test-source | رشته‌ها | مسیرهای منبع آزمایشی باینری نسبت‌به دایرکتوری مورد آزمون vts در میزبان. مثال: DATA/nativetest/test |
| binary-test-working-directory | رشته‌ها | دایرکتوری‌های کاری (مسیر سمت دستگاه). مثال: /data/local/tmp/testing/ |
| binary-test-envp | رشته‌ها | متغیرهای محیط برای دودویی. مثال: PATH=/new:$PATH |
| binary-test-args | رشته‌ها | آرگومان‌ها یا پرچم‌ها را آزمایش کنید. مثال: --gtest_filter=test1 |
| binary-test-ld-library-path | رشته‌ها | متغیر محیطی LD_LIBRARY_PATH.مثال: /data/local/tmp/lib |
| binary-test-disable-framework | بولی | قبل‌از آزمایش، adb stop را اجرا کنید تا «چارچوب Android» خاموش شود.
مثال: true |
| binary-test-stop-native-servers | بولی | همه سرورهای بومی پیکربندی‌شده صحیح را درطول آزمایش متوقف کنید. مثال:
true |
| binary-test-type | رشته | نوع الگو. انواع دیگر الگو از این الگو گسترش می‌یابند، اما
لازم نیست این گزینه را برای این الگو مشخص کنید زیرا قبلاً
binary-test-source را مشخص کرده‌اید. |
برای گزینه‌هایی با نوع مقدار strings، می‌توانید با تکرار کردن گزینه‌ها در پیکربندی، مقدارهای متعددی اضافه کنید. برای مثال،
binary-test-source را دو بار تنظیم کنید (همان‌طور که در
VtsDeviceTreeEarlyMountTest مثال نشان داده شده است).
برچسب‌های آزمایش
می‌توانید برچسب‌های آزمایشی را با پیشوند کردن آن‌ها به گزینه‌های دارای strings
مقادیر و استفاده از :: به‌عنوان جداکننده اضافه کنید. برچسب‌های آزمایش به‌ویژه هنگام افزودن منابع باینری با نام یکسان اما با
بیت‌بودگی یا دایرکتوری‌های والد متفاوت مفید هستند. برای مثال، برای جلوگیری از برخورد نام فایل یا نتیجه
برای منابعی با نام یکسان اما از دایرکتوری‌های منبع متفاوت،
می‌توانید برچسب‌های متفاوتی برای این منابع مشخص کنید.
همان‌طور که در مثال VtsDeviceTreeEarlyMountTest با دو منبع dt_early_mount_test نشان داده شده است، برچسب‌های آزمایشی پیشوندهای _32bit:: و _64bit:: در binary-test-source هستند. برچسب‌هایی که به 32bit یا
64bit ختم می‌شوند، به‌طور خودکار آزمایش‌ها را به‌عنوان دردسترس برای یک بیت ABI علامت‌گذاری می‌کنند؛
یعنی آزمایش‌های دارای برچسب _32bit در ABI ۶۴ بیتی اجرا نمی‌شوند. مشخص نکردن برچسب معادل استفاده از برچسب با رشته خالی است.
گزینه‌های دارای برچسب‌های یکسان گروه‌بندی می‌شوند و از برچسب‌های دیگر جدا می‌شوند. برای
مثال، binary-test-args با برچسب _32bit
فقط برای binary-test-source با همان برچسب اعمال می‌شود و
در binary-test-working-directory با همان برچسب اجرا می‌شود. گزینه
binary-test-working-directory برای آزمایش‌های دودویی اختیاری است و
به شما امکان می‌دهد یک پوشه کاری واحد برای برچسب مشخص کنید. وقتی گزینه
binary-test-working-directory مشخص نشده باشد، از
دایرکتوری‌های پیش‌فرض برای هر برچسب استفاده می‌شود.
نام برچسب مستقیماً به نام چارچوب تست در گزارش نتیجه اضافه می‌شود.
برای مثال، مورد آزمون testcase1 با برچسب _32bit
به‌صورت testcase1_32bit در گزارش نتیجه نشان داده می‌شود.
ادغام کردن آزمایش‌های طرف هدف بدون الگوی BinaryTest
در VTS، قالب آزمایشی پیش‌فرض آزمون‌های Python سمت میزبان است که از BaseTest در دونده VTS گسترش یافته است. برای ادغام کردن آزمایش‌های سمت هدف، ابتدا باید فایل‌های آزمایشی را به دستگاه ارسال کنید، آزمایش‌ها را بااستفاده از فرمان‌های پوسته اجرا کنید، سپس نتایج را بااستفاده از اسکریپت‌های Python سمت میزبان تجزیه کنید.
فرستادن فایل‌های اجرایی آزمایشی
توصیه می‌کنیم فایل‌ها را بااستفاده از VtsFilePusher آماده‌ساز هدف انتقال دهید.
مثال:
<target_preparer class="com.android.compatibility.common.tradefed.targetprep.VtsFilePusher">
<option name="push" value="DATA/test->/data/local/tmp/test"/>
</target_preparer>
VtsFilePusher کارهای زیر را انجام می‌دهد:
- اتصال‌پذیری دستگاه را بررسی می‌کند.
- مسیر فایل منبع مطلق را تعیین می‌کند.
- فایل‌ها را بااستفاده از فرمان
adb pushارسال می‌کند. - فایل‌ها را پس‌از تکمیل آزمایش‌ها حذف می‌کند.
یا می‌توانید بااستفاده از یک دستورگان آزمایشی Python در سمت میزبان که از رویه مشابهی پیروی می‌کند، فایل‌ها را به‌صورت دستی انتقال دهید.
اجرای آزمایش‌ها
پس‌از ارسال فایل‌ها به دستگاه، آزمایش را بااستفاده از فرمان‌های پوسته در یک اسکریپت آزمایشی Python سمت میزبان اجرا کنید. مثال:
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 را اضافه می‌کند:
| نام گزینه | نوع مقدار | شرح |
|---|---|---|
| binary-test-type | رشته | نوع الگو. از مقدار gtest استفاده می‌کند. |
| gtest-batch-mode | بولی | اجرای فایل‌های اجرایی Gtest در حالت دسته‌ای. مثال: true |
به‌طور کلی، تنظیم gtest-batch-mode روی true
عملکرد را افزایش می‌دهد، درحالی‌که قابلیت اطمینان را کمی کاهش می‌دهد. در آزمون‌های
رعایت VTS، بسیاری از واحدها از حالت دسته‌ای برای بهبود عملکرد استفاده می‌کنند. برای اطمینان
بااین‌حال، اگر حالت نامشخص باشد، به‌طور پیش‌فرض غیردسته‌ای است.
حالت غیر دسته‌ای
حالت غیردسته‌ای برای هر چارچوب تست، تماس‌های جداگانه‌ای با GTest binary برقرار می‌کند. برای مثال، اگر باینری GTest حاوی ۱۰ مورد آزمایشی باشد (پس‌از فیلتر کردن براساس پیکربندی سمت میزبان)، باینری ۱۰ بار در پوسته دستگاه فراخوانی می‌شود و هر بار با فیلتر آزمایشی متفاوتی همراه است. برای هر مورد آزمایشی، برونداد نتیجه GTest منحصربه‌فردی به‌صورت XML تولید می‌شود و الگو آن را تجزیه می‌کند.
مزایای استفاده از حالت غیر دسته‌ای عبارتند از:
- جداسازی چارچوب تست. خرابی یا توقف در یک چارچوب تست بر چارچوب‌های تست دیگر تأثیر نمی‌گذارد.
- دقت. دریافت اندازه‌گیری پوشش/نمایه‌سازی برای هر چارچوب تست، systrace، گزارش اشکال، logcat، و غیره آسان‌تر است. نتایج و گزارش‌های تست بلافاصله پس‌از پایان هر چارچوب تست بازیابی می‌شوند.
معایب استفاده از حالت غیر دسته‌ای عبارتند از:
- بار کردن زائد. هربار که باینری GTest فراخوانده می‌شود، کتابخانه‌های مرتبط را بار می‌کند و راه‌اندازی‌های کلاس اولیه را انجام می‌دهد.
- سربار ارتباطی. پس‌از تکمیل آزمایش، میزبان و دستگاه هدف برای تجزیه‌وتحلیل نتایج و فرمان‌های بعدی با هم ارتباط برقرار می‌کنند (بهینه‌سازی‌های آتی امکان‌پذیر است).
حالت دسته‌ای
In GTest batch mode, the test binary is called only once with a long test filter value containing all test cases filtered by host-side configuration (this avoids the redundant loading issue in non-batch mode). می‌توانید نتایج آزمایش GTest را بااستفاده از output.xml یا بااستفاده از برونداد ترمینال تجزیه کنید.
هنگام استفاده از output.xml (پیش‌فرض):
مانند حالت غیر دسته‌ای، نتیجه آزمایش ازطریق فایل xml برونداد GTest تجزیه می‌شود. بااین‌حال، چون xml خروجی پس‌از تکمیل همه آزمایش‌ها تولید می‌شود، اگر یک چارچوب تست باعث ازکار افتادن دودویی یا دستگاه شود، هیچ فایل xml نتیجه‌ای تولید نمی‌شود.
هنگام استفاده از برونداد پایانه:
وقتی GTest درحال اجرا است، گزارش آزمایش و پیشرفت را در پایانه با قالبی چاپ می‌کند که چارچوب می‌تواند آن را برای وضعیت، نتایج، و گزارش‌های آزمایش تجزیه کند.
مزایای استفاده از حالت دسته‌ای عبارتند از:
- جداسازی چارچوب تست. اگر چارچوب، دودویی/دستگاه را پس‌از خرابی با فیلتر تست کاهش‌یافته (به‌استثنای چارچوب‌های تست تمام‌شده و خراب‌شده) بازراه‌اندازی کند، همان سطح جداسازی چارچوب تست را مانند حالت غیردسته‌ای ارائه می‌دهد.
- جزئیات. همان سطح جزئیات مورد آزمون را مانند حالت غیر دسته‌ای ارائه می‌دهد.
معایب استفاده از حالت دسته‌ای عبارتند از:
- هزینه نگهداری. اگر قالب گزارش‌گیری GTest تغییر کند، همه آزمایش‌ها ازکار خواهند افتاد.
- سردرگمی. مورد آزمایشی می‌تواند چیزی شبیه به قالب پیشرفت GTest چاپ کند که می‌تواند قالب را گیج کند.
به‌دلیل این معایب، گزینه استفاده از برونداد خط فرمان را موقتاً برداشته‌ایم. در آینده این گزینه را دوباره بررسی خواهیم کرد تا قابلیت اطمینان این عملکرد را بهبود بخشیم.
الگوی HostBinaryTest
الگوی HostBinaryTest شامل فایل‌های اجرایی سمت میزبان است که در دایرکتوری‌های دیگر یا در اسکریپت‌های Python وجود ندارند. این آزمایش‌ها شامل موارد زیر می‌شود:
- فایل‌های اجرایی آزمایش کامپایل‌شده در میزبان
- دستورگان‌های اجرایی در پوسته، Python، یا زبان‌های دیگر
یک نمونه آن VTS Security SELinux policy host-side test است:
<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 دارای افزونه‌های زیر هستند:
توسعه‌دهندگان تشویق می‌شوند که هر الگوی موجود را برای هرگونه نیاز خاص آزمایشی گسترش دهند. دلایل رایج برای گسترش الگوها عبارت‌اند از:
- روال‌های تنظیمات آزمایش ویژه، مثل آماده کردن دستگاه با فرمان‌های ویژه.
- درحال تولید چارچوب‌های تست و نام‌های تست متفاوت.
- تجزیه نتایج با خواندن برونداد فرمان یا استفاده از شرایط دیگر.
برای آسان‌تر کردن گسترش الگوهای موجود، الگوها حاوی روش‌هایی هستند که برای هر عملکرد اختصاصی شده‌اند. اگر طراحی‌های بهبودیافته‌ای برای الگوهای موجود دارید، شما را تشویق می‌کنیم که در پایگاه کد VTS مشارکت کنید.