המבנה הכולל של תצורת המודול עוקב אחר דפוס דומה לתצורת ה-XML הרגילה של Tradefed, אך עם כמה הגבלות בשל העובדה שהם פועלים כחלק מחבילה.
רשימת התגים המותרים
תצורת מודול AndroidTest.xml או יותר בגדול יכולה להכיל רק את תגי ה-XML הבאים: target_preparer , multi_target_preparer , test ו- metrics_collector .
למרות שהרשימה נראית מגבילה, היא מאפשרת לך להגדיר במדויק את צרכי הגדרת מודול הבדיקה ואת הבדיקה שתרצה.
הערה: ראה תצורת XML של Tradefed אם אתה זקוק לרענון על התגים השונים.
אובייקטים כגון build_provider או result_reporter יעלו ConfigurationException אם ינסו להפעיל אותם מתוך תצורת מודול. זה נועד למנוע את הציפייה שאובייקטים אלו יבצעו משימה כלשהי מתוך מודול.
דוגמה לתצורת מודול
<configuration description="Config for CTS Gesture test cases">
<option name="test-suite-tag" value="cts" />
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsGestureTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.gesture.cts" />
<option name="runtime-hint" value="10m50s" />
</test>
</configuration>
תצורה זו מתארת בדיקה הדורשת התקנת CtsGestureTestCases.apk ותפעיל מכשור כנגד החבילה android.gesture.cts .
תגי הכללה <include> ו- <template-include>
השימוש ב- <include> ו- <template-include> בתצורות המודול אינו מעודד. לא מובטח שהם יעבדו כמצופה.
מקרה מיוחד לתג metrics_collector
ה- metrics_collector מותר אך מוגבל למחלקה FilePullerLogCollector על מנת לציין קובץ או ספרייה נתונה שיש למשוך ולהתחבר עבור המודול. זה שימושי אם אתה משאיר יומנים במיקום מסוים וברצונך לשחזר אותם אוטומטית.
תצורה לדוגמה:
<configuration description="Config for CTS UI Rendering test cases">
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsUiRenderingTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.uirendering.cts" />
<option name="runtime-hint" value="11m55s" />
<option name="runner" value="android.uirendering.cts.runner.UiRenderingRunner" />
<option name="isolated-storage" value="false" />
</test>
<!-- Collect the files in the dump directory for debugging -->
<metrics_collector class="com.android.tradefed.device.metric.FilePullerLogCollector">
<option name="directory-keys" value="/sdcard/UiRenderingCaptures" />
<option name="collect-on-run-ended-only" value="true" />
</metrics_collector>
</configuration>
מה לגבי מידע בנייה או הורדות?
ההגדרה של התגים המותרים עלולה לתת את הרושם השגוי שמודול לא יקבל מידע בנייה. זה לא נכון .
מידע הבנייה מסופק מההגדרה ברמת החבילה וישותף לכל המודולים של החבילה. זה מאפשר הגדרה אחת ברמה העליונה עבור החבילה על מנת להפעיל את כל המודולים של החבילה.
לדוגמה, במקום שכל מודול בדיקת תאימות (CTS) יבקש בנפרד את פרטי המכשיר, הסוגים וכו', ההגדרה ברמת החבילה של CTS ( cts.xml ) עושה זאת פעם אחת וכל מודול יקבל מידע זה אם יבקש זאת.
כדי שהאובייקטים במודול יקבלו את מידע ה-build, הם צריכים לעשות את אותו הדבר כמו בתצורת Tradefed רגילה: ליישם את ממשק IBuildReceiver כדי לקבל את IBuildInfo . ראה בדיקה עם מכשיר לפרטים נוספים.
שדות מטא נתונים
מספר רב של מודולי בדיקה כוללים כמה מפרטי metadata , שלכל אחד מהם מטרה ייחודית.
דוגמא:
<option name="config-descriptor:metadata" key="component" value="framework" />
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
<option name="config-descriptor:metadata" key="parameter" value="multi_abi" />
<option name="config-descriptor:metadata" key="parameter" value="secondary_user" />
רְכִיב
המטא נתונים component מתאר את רכיב האנדרואיד הכללי שהמודול מתכוון לבדוק. אין לה השפעה ישירה על ביצוע הבדיקה; הוא משמש בעיקר למטרות ארגוניות.
הרשימה המעודכנת של הרכיבים המותרים עבור CTS זמינה ב- CtsConfigLoadingTest . בדיקה זו נכשלת בהגשה מראש אם נוסף רכיב לא קיים למודול CTS.
אתה יכול לסנן ריצת חבילה על סמך הרכיבים באמצעות module-metadata-include-filter ו- module-metadata-exclude-filter .
דוגמא:
--module-metadata-include-filter component framework
דוגמה זו מפעילה רק את מודול הבדיקה המסומן עם רכיב framework .
פָּרָמֶטֶר
המטא-נתונים parameter הם אינפורמטיביים ומשפיעים על ביצוע הבדיקה. הוא מציין לאיזה מצב אנדרואיד חל מודול הבדיקה. במקרה זה, המצבים מוגבלים למצבי אנדרואיד ברמה גבוהה, כגון instant apps , secondary users או different abis .
במהלך הפעלת החבילה, אם המצב חל על הבדיקה, נוצרות מספר וריאציות של מודול הבדיקה על סמך המצב. כל וריאציה מפעילה בדיקות דומות אך במצבים שונים.
-
instant_app: צור וריאציה של הבדיקות שמתקינות חבילות APK כאפליקציות אינסטנט. -
multi_abi: צור וריאציה של הבדיקות עבור כל ABI שנתמך על ידי המכשיר. -
secondary_user: צור וריאציה של הבדיקות שמתקינות חבילות APK ומריצות בדיקות כמשתמש משני.
איסוף מדדים ועיבוד לאחר מודולים של בדיקת ביצועים
עבור מודולי בדיקת ביצועים, מותרים metrics_collector ו- metric_post_processor ברמת המודול מכיוון שהם חיוניים לבדיקות ביצועים. האספנים המטריים והפוסט-מעבדים ברמת המודול יכולים להיות ספציפיים למודול. לא מומלץ לציין מעבדי פוסט-מעבדים הן ברמה העליונה והן ברמת המודול.
תצורת מודול בדיקת ביצועים חייבת לכלול את המטא נתונים test-type עם ערך performance , כמו xml <option name="config-descriptor:metadata" key="test-type" value="performance" /> ללא זה, אם בדיקה config כולל metric_collector שאינו FilePullerLogCollector או כל metric_post_processor , הבדיקה נכשלת ב-presubmit.
דוגמה לתצורת מודול בדיקת ביצועים:
<configuration description="Runs sample performance test.">
<!-- Declare as a performance test module -->
<option name="config-descriptor:metadata" key="test-type" value="performance" />
<option name="test-tag" value="hello-world-performance-test" />
<test class="com.android.tradefed.testtype.HostTest" >
<option name="class" value="android.test.example.helloworldperformance.HelloWorldPerformanceTest" />
</test>
<!-- Add module-level post processor MetricFilePostProcessor -->
<metric_post_processor class="com.android.tradefed.postprocessor.MetricFilePostProcessor">
<option name="aggregate-similar-tests" value="true" />
<option name="enable-per-test-log" value="false" />
</metric_post_processor>
</configuration>