המבנה של AndroidTest.xml

קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

המבנה הכולל של תצורת המודול בנוי לפי דפוס דומה לתצורת ה-XML הרגילה של Tradeified, אבל עם כמה הגבלות בגלל שהם פועלים כחלק מחבילה.

רשימה של תגים מותרים

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>