מבנה AndroidTest.xml

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

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

הגדרה של מודול AndroidTest.xml או יותר יכולה להכיל רק תגי ה-XML הבאים: target_preparer, multi_target_preparer, test ו- metrics_collector

למרות שהרשימה נראית מגבילה, היא מאפשרת להגדיר במדויק את צורכי להגדיר את מודול הבדיקה ואת הבדיקה שיש להריץ.

הערה: מידע נוסף זמין במאמר הגדרת XML שעברה מסחר אלקטרוני. אם אתם צריכים רענון לגבי התגים השונים.

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