המבנה הכללי של הגדרות המודול דומה לדפוס של הגדרות ה-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>
מה קורה לגבי פרטי גרסאות build או הורדות?
ההגדרה של התגים המותרים עשויה ליצור רושם שגוי שלפיו מודול לא יקבל פרטי build. לא נכון.
פרטי ה-build מסופקים מההגדרה ברמת הסוויטה, וכל המודולים בסוויטה ישתפו אותם. כך אפשר להגדיר את חבילת המודולים ברמה העליונה כדי להריץ את כל המודולים שנכללים בה.
לדוגמה, במקום שכל מודול של חבילת בדיקות התאימות (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 מתאר את רכיב Android הכללי שהמודול מיועד לבדוק. אין לה השפעה ישירה על ביצוע הבדיקה. היא משמשת בעיקר למטרות ארגוניות.
הרשימה המעודכנת של הרכיבים המותרים ל-CTS זמינה ב-CtsConfigLoadingTest. הבדיקה הזו תיכשל בשליחה מראש אם רכיב לא קיים מתווסף למודול CTS.
אפשר לסנן את ההרצה של חבילת הבדיקה על סמך הרכיבים באמצעות module-metadata-include-filter ו-module-metadata-exclude-filter.
דוגמה:
--module-metadata-include-filter component framework
בדוגמה הזו פועל רק מודול הבדיקה עם ההערה על הרכיב framework.
פרמטר
המטא-נתונים של parameter הם למידע בלבד, והם משפיעים על ביצוע הבדיקה. הוא מציין את מצב Android שאליו מודול הבדיקה רלוונטי.
במקרה כזה, modes מוגבלים למצבים ברמה גבוהה של Android, כמו 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" />
ללא זאת, אם הגדרת הבדיקה כוללת metric_collector שאינו FilePullerLogCollector או כל ערך של metric_post_processor, הבדיקה תיכשל בשלב שלפני השליחה.
דוגמה להגדרה של מודול לבדיקת ביצועים:
<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>