המבנה הכללי של הגדרות המודול דומה לדפוס של הגדרות ה-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>