המבנה של AndroidTest.xml

המבנה הכללי של הגדרת המודול דומה לדפוס של הגדרת 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) מבצעת את הפעולה הזו פעם אחת, וכל מודול יקבל את המידע הזה אם הוא יבקש אותו.

כדי שהאובייקטים במודול יקבלו את פרטי הבנייה, הם צריכים לעשות את אותו הדבר כמו בהגדרה רגילה של 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

בדוגמה הזו מופעל רק מודול הבדיקה עם ההערה frameworkcomponent.

פרמטר

המטא-נתונים parameter הם מידע שמשפיע על הביצוע של הבדיקה. הוא מציין לאיזה מצב של Android מודול הבדיקה חל. במקרה הזה, ההגדרות מוגבלות להגדרות ברמה גבוהה של 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>