בדיקות ריצה (Atest), בדיקות ריצה (Atest)

Atest הוא כלי שורת פקודה המאפשר למשתמשים לבנות, להתקין ולהריץ בדיקות אנדרואיד באופן מקומי, מה שמאיץ מאוד את ההרצות החוזרות של הבדיקות מבלי לדרוש ידע באפשרויות שורת הפקודה של Trade Federation . דף זה מסביר כיצד להשתמש ב-Atest כדי להריץ בדיקות אנדרואיד.

למידע כללי על כתיבת מבחנים עבור אנדרואיד, ראה בדיקת פלטפורמת אנדרואיד .

למידע על המבנה הכללי של Atest, עיין במדריך למפתחים של Atest .

למידע על הפעלת בדיקות בקבצי TEST_MAPPING דרך Atest, ראה הפעלת בדיקות בקבצי TEST_MAPPING .

כדי להוסיף תכונה ל-Atest, עקוב אחר זרימת העבודה של Atest Developer .

הגדרת הסביבה שלך

בצע את השלבים בסעיפים הבאים כדי להגדיר את סביבת Atest שלך.

הגדר משתנה סביבה

הגדר test_suite עבור Soong או LOCAL_COMPATIBILITY_SUITE עבור בצע את כללי הסקריפט לבניית Packaging הבאים.

הפעל envsetup.sh

מהשורש של בדיקת מקור אנדרואיד, הפעל:

source build/envsetup.sh

רץ lunch

הפעל את פקודת lunch כדי להעלות תפריט של מכשירים נתמכים. מצא את המכשיר והפעל את הפקודה.

לדוגמה, אם יש לך מכשיר ARM מחובר, הפעל את הפקודה הבאה:

lunch aosp_arm64-eng

זה מגדיר משתני סביבה שונים הדרושים להפעלת Atest ומוסיף את הפקודה Atest ל- $PATH שלך.

שימוש בסיסי

פקודות Atest בעלות הצורה הבאה:

atest test-to-run [optional-arguments]

טיעונים אופציונליים

הטבלה הבאה מפרטת את הארגומנטים הנפוצים ביותר. רשימה מלאה זמינה דרך atest --help .

אוֹפְּצִיָה אפשרות ארוכה תיאור
-b --build בונה יעדי בדיקה. (בְּרִירַת מֶחדָל)
-i --install מתקין חפצי בדיקה (APK) במכשיר. (בְּרִירַת מֶחדָל)
-t --test מריץ את הבדיקות. (בְּרִירַת מֶחדָל)
-s --serial מפעיל את הבדיקות במכשיר שצוין. ניתן לבדוק מכשיר אחד בכל פעם.
-d --disable-teardown משבית את הפירוק והניקוי של הבדיקה.
<c> --info מציג את המידע הרלוונטי על היעדים שצוינו, ואז יוצא.
<c> --dry-run מפעיל יבש את Atest מבלי לבנות, להתקין או להריץ בדיקות.
-m --rebuild-module-info מאלץ בנייה מחדש של קובץ module-info.json .
-w --wait-for-debugger ממתין לסיום באגים לפני ביצוע.
-v --verbose מציג רישום ברמת DEBUG.
<c> --iterations ריצת בדיקות לולאה עד הגעה לאיטרציה המקסימלית. (10 כברירת מחדל)
<c> --rerun-until-failure [COUNT=10] מפעיל מחדש את כל הבדיקות עד להתרחשות כשל או הגעה לאיטרציה המקסימלית. (10 כברירת מחדל)
<c> --retry-any-failure [COUNT=10] מבצע בדיקות חוזרות שנכשלו עד שיעבור או השגת האיטרציה המקסימלית. (10 כברירת מחדל)
<c> --start-avd יוצר אוטומטית AVD ומריץ בדיקות במכשיר הוירטואלי.
<c> --acloud-create יוצר AVD באמצעות פקודת acloud .
<c> --[CUSTOM_ARGS] מציין ארגומנטים מותאמים אישית עבור רצי המבחן.
-a --all-abi מפעיל את הבדיקות עבור כל ארכיטקטורות ההתקן הזמינות.
<c> --host מריץ את הבדיקה לחלוטין על המארח ללא מכשיר.
הערה: הפעלת בדיקת מארח הדורשת התקן עם --host תיכשל.
<c> --flakes-info מציג את תוצאת הבדיקה עם מידע על פתיתים.
<c> --history מציג את תוצאות הבדיקה בסדר כרונולוגי.
<c> --latest-result מדפיס את תוצאת הבדיקה האחרונה.

למידע נוסף על -b , -i ו- -t , עיין בסעיף ציין שלבים: בנייה, התקנה או הפעלה .

ציין בדיקות

כדי להפעיל בדיקות, ציין בדיקה אחת או יותר באמצעות אחד מהמזהים הבאים:

  • שם המודול
  • מודול: כיתה
  • שם הכיתה
  • מבחן אינטגרציה של Tradefed
  • נתיב הקובץ
  • שם חבילה

הפרד הפניות לבדיקות מרובות עם רווחים, כך:

atest test-identifier-1 test-identifier-2

שם המודול

כדי להפעיל מודול בדיקה שלם, השתמש בשם המודול שלו. הזן את השם כפי שהוא מופיע LOCAL_MODULE או LOCAL_PACKAGE_NAME בקובץ Android.bp או Android.mk של אותה בדיקה.

דוגמאות:

atest FrameworksServicesTests
atest CtsVideoTestCases

מודול: כיתה

כדי להפעיל מחלקה אחת בתוך מודול, השתמש ב- Module:Class . המודול זהה לזה שמתואר בשם המודול . Class הוא השם של מחלקת הבדיקה בקובץ ה-. .java , ויכול להיות שם המחלקה המלא או השם הבסיסי.

דוגמאות:

atest CtsVideoTestCases:VideoEncoderDecoderTest
atest FrameworksServicesTests:ScreenDecorWindowTests
atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests

שם הכיתה

כדי להפעיל מחלקה בודדת מבלי לציין שם מודול במפורש, השתמש בשם המחלקה.

דוגמאות:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

מבחן אינטגרציה של Tradefed

כדי להפעיל בדיקות המשולבות ישירות ב-TradeFed (לא מודולים), הזינו את השם כפי שהוא מופיע בפלט של הפקודה tradefed.sh list configs . לדוגמה:

כדי להפעיל את מבחן reboot.xml :

atest example/reboot

כדי להפעיל את מבחן native-benchmark.xml :

atest native-benchmark

נתיב הקובץ

Atest תומכת בהפעלת בדיקות מבוססות מודול והן בדיקות מבוססות אינטגרציה על ידי הזנת הנתיב לקובץ הבדיקה או ספריית הבדיקה שלהם לפי הצורך. זה גם תומך בהפעלת מחלקה אחת על ידי ציון הנתיב לקובץ Java של המחלקה. נתמכים נתיבים יחסיים ומוחלטים.

הפעל מודול

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

הפעל מ- repo-root של אנדרואיד:

atest cts/tests/video

הפעל מ-Android repo-root/cts/tests/video :

    atest .

הפעל שיעור מבחן

הדוגמה הבאה מראה כיצד להפעיל מחלקה מסוימת בתוך מודול CtsVideoTestCases באמצעות נתיב קובץ.

מתוך repo-root אנדרואיד:

    atest cts/tests/video/src/android/video/cts/VideoEncoderDecoderTest.java

הפעל מבחן אינטגרציה

הדוגמה הבאה מראה כיצד להפעיל בדיקת אינטגרציה באמצעות נתיב קובץ מ- repo-root של Android:

    atest tools/tradefederation/contrib/res/config/example/reboot.xml

שם חבילה

Atest תומך בחיפוש בדיקות לפי שם החבילה.

דוגמאות:

    atest com.android.server.wm
    atest com.android.uibench.janktests

ציין שלבים: בנה, התקן או הפעל

השתמש באפשרויות -b , -i ו- -t כדי לציין אילו שלבים להפעיל. אם לא תציין אפשרות, כל השלבים יפעלו.

  • בניית יעדים בלבד: atest -b test-to-run
  • הפעל בדיקות בלבד: atest -t test-to-run
  • התקן apk והפעל בדיקות: atest -it test-to-run
  • בנה והרץ, אך אל תתקין: atest -bt test-to-run

Atest יכול לאלץ בדיקה לדלג על שלב הניקוי או ההפסקה. בדיקות רבות, כגון CTS, מנקות את המכשיר לאחר הפעלת הבדיקה, כך שניסיון להפעיל מחדש את הבדיקה שלך עם -t ייכשל ללא הפרמטר --disable-teardown . השתמש ב- -d לפני -t כדי לדלג על שלב ניקוי הבדיקה ולבדוק באופן איטרטיבי.

atest -d test-to-run
atest -t test-to-run

הפעלת שיטות ספציפיות

Atest תומך בהפעלת שיטות ספציפיות בתוך מחלקת בדיקה. למרות שצריך לבנות את כל המודול, זה מקטין את הזמן הדרוש להפעלת הבדיקות. כדי להפעיל שיטות ספציפיות, זהה את המחלקה באמצעות כל אחת מהדרכים הנתמכות לזיהוי מחלקה (מודול: מחלקה, נתיב קובץ וכו') וצרף את שם השיטה:

atest reference-to-class#method1

בעת ציון שיטות מרובות, הפרד ביניהן באמצעות פסיקים:

atest reference-to-class#method1,method2,method3

דוגמאות:

atest com.android.server.wm.ScreenDecorWindowTests#testMultipleDecors
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval

שתי הדוגמאות הבאות מציגות את הדרכים המועדפות להפעלת שיטה בודדת, testFlagChange . דוגמאות אלו עדיפות על פני שימוש בשם המחלקה בלבד מכיוון שציינת המודול או מיקום קובץ ה-Java מאפשרת ל-Atest למצוא את המבחן הרבה יותר מהר.

שימוש במודול: מחלקה:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

מתוך repo-root אנדרואיד:

atest frameworks/base/services/tests/wmtests/src/com/android/server/wm/ScreenDecorWindowTests.java#testFlagChange

ניתן להפעיל מספר שיטות ממחלקות וממודולים שונים:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors

הפעלת מספר שיעורים

כדי להפעיל מחלקות מרובות, הפרד אותם עם רווחים באותו אופן כמו להפעלת מבחנים מרובים. Atest בונה ומריצה מחלקות ביעילות, לכן ציון תת-קבוצת מחלקות במודול משפר את הביצועים על פני הפעלת המודול כולו.

כדי להפעיל שתי מחלקות באותו מודול:

atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests

כדי להפעיל שתי מחלקות במודולים שונים:

atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest

הפעל את הקבצים הבינאריים של GTest

Atest יכול להריץ קבצים בינאריים של GTest. השתמש ב- -a כדי להריץ את הבדיקות הללו עבור כל ארכיטקטורות ההתקן הזמינות, שבדוגמה זו הן armeabi-v7a (ARM 32-bit) ו- arm64-v8a (ARM 64-bit).

מבחן קלט לדוגמה:

atest -a libinput_tests inputflinger_tests

כדי לבחור GTest בינארי ספציפי להפעלה, השתמש בנקודתיים (:) כדי לציין את שם הבדיקה, וב-hashtag (#) כדי לציין עוד יותר שיטה בודדת.

לדוגמה, עבור הגדרת הבדיקה הבאה:

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

הפעל את הדברים הבאים כדי לציין את כל הבדיקה:

atest inputflinger_tests:InputDispatcherTest

לחלופין, הפעל בדיקה פרטנית באמצעות האפשרויות הבאות:

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

הפעל בדיקות ב- TEST_MAPPING

Atest יכול להריץ בדיקות בקבצי TEST_MAPPING .

הפעל בדיקות מראש באופן מרומז

הפעל מבחני הגשה מראש בקבצי TEST_MAPPING אב:

atest

הפעל מבחני הגשה מראש בקבצי TEST_MAPPING ב- /path/to/project ובספריות האב שלו:

atest --test-mapping /path/to/project

הפעל קבוצת בדיקה שצוינה

קבוצות הבדיקה הזמינות הן: presubmit (ברירת מחדל), postsubmit , mainline-presubmit all .

הפעל בדיקות לאחר הגשה בקבצי TEST_MAPPING בספריות נוכחיות ובספריות אב:

<pre>
<code class="devsite-terminal">atest :postsubmit</code>
</pre>

הפעל בדיקות מכל הקבוצות בקבצי TEST_MAPPING:

<pre>
<code class="devsite-terminal">atest :all</code>
</pre>

הפעל בדיקות לאחר הגשה בקבצי TEST_MAPPING ב- /path/to/project ובספריות האב שלו:

<pre>
<code class="devsite-terminal">atest --test-mapping <var>/path/to/project</var>:postsubmit</code>
</pre>

הפעל בדיקות ראשיות בקבצי TEST_MAPPING ב- /path/to/project ובספריות האב שלו:

    atest --test-mapping /path/to/project:mainline-presubmit
    

הפעל בדיקות בספריות משנה

כברירת מחדל, Atest מחפש רק בדיקות בקבצי TEST_MAPPING כלפי מעלה (מהספרייה הנוכחית או הנתונה לתיקיות האב שלה). אם אתה גם רוצה להריץ בדיקות בקבצי TEST_MAPPING בספריות המשנה, השתמש --include-subdirs כדי לאלץ את Atest לכלול גם את הבדיקות הללו:

atest --include-subdirs /path/to/project

הפעל בדיקות באיטרציה

הפעל בדיקות באיטרציה על ידי העברת הארגומנט --iterations . בין אם הוא עובר או נכשל, Atest יחזור על המבחן עד להגיע לאיטרציה המקסימלית.

דוגמאות:

כברירת מחדל, Atest חוזר 10 פעמים. מספר האיטרציות חייב להיות מספר שלם חיובי.

atest test-to-run --iterations
atest test-to-run --iterations 5

הגישות הבאות מקלות על זיהוי בדיקות מתקלפות:

גישה 1: הפעל את כל הבדיקות עד שמתרחש כשל או השגת האיטרציה המקסימלית.

  • עצור כאשר מתרחש כשל או שהאיטרציה מגיעה לסיבוב העשירי (כברירת מחדל).
    atest test-to-run --rerun-until-failure
    
  • עצור כאשר מתרחש כשל או שהאיטרציה מגיעה לסיבוב ה-100.
    atest test-to-run --rerun-until-failure 100
    

גישה 2: הפעל רק מבחנים שנכשלו עד שתעבור או השגת האיטרציה המקסימלית.

  • נניח שלבדיקה test-to-run יש מספר מקרי בדיקה ואחת מהבדיקות נכשלת. הפעל רק את המבחן שנכשל 10 פעמים (כברירת מחדל) או עד שהבדיקה תעבור.
    atest test-to-run --retry-any-failure
    
  • הפסק להריץ את המבחן שנכשל כאשר הוא עובר או יגיע לסיבוב ה-100.
    atest test-to-run --retry-any-failure 100
    

הפעל בדיקות על AVDs

Atest מסוגלת להריץ בדיקות על AVD שזה עתה נוצר. הפעל acloud create כדי ליצור AVD ולבנות חפצים, ולאחר מכן השתמש בדוגמאות הבאות כדי להפעיל את הבדיקות שלך.

הפעל AVD והפעל עליו בדיקות:

acloud create --local-instance --local-image && atest test-to-run

התחל AVD כחלק מניסוי:

atest test-to-run --acloud-create "--local-instance --local-image"

למידע נוסף, הפעל acloud create --help .

העברת אפשרויות למודול

Atest מסוגלת להעביר אפשרויות לבדיקת מודולים. כדי להוסיף אפשרויות שורת הפקודה של TradeFed להפעלת המבחן שלך, השתמש במבנה הבא וודא שהארגומנטים המותאמים אישית שלך עוקבים אחר פורמט אפשרויות שורת הפקודה של Tradefed.

atest test-to-run -- [CUSTOM_ARGS]

העבר את אפשרויות מודול הבדיקה למכיני מטרה או רצים לבדיקה המוגדרים בקובץ תצורת הבדיקה:

atest test-to-run -- --module-arg module-name:option-name:option-value
atest GtsPermissionTestCases -- --module-arg GtsPermissionTestCases:ignore-business-logic-failure:true

אפשרויות מעבר לסוג רץ או לכיתה:

atest test-to-run -- --test-arg test-class:option-name:option-value
atest CtsVideoTestCases -- --test-arg com.android.tradefed.testtype.JarHosttest:collect-tests-only:true

למידע נוסף על אפשרויות לבדיקה בלבד, ראה אפשרויות מעבר למודולים .

,

Atest הוא כלי שורת פקודה המאפשר למשתמשים לבנות, להתקין ולהריץ בדיקות אנדרואיד באופן מקומי, מה שמאיץ מאוד את ההרצות החוזרות של הבדיקות מבלי לדרוש ידע באפשרויות שורת הפקודה של Trade Federation . דף זה מסביר כיצד להשתמש ב-Atest כדי להריץ בדיקות אנדרואיד.

למידע כללי על כתיבת מבחנים עבור אנדרואיד, ראה בדיקת פלטפורמת אנדרואיד .

למידע על המבנה הכללי של Atest, עיין במדריך למפתחים של Atest .

למידע על הפעלת בדיקות בקבצי TEST_MAPPING דרך Atest, ראה הפעלת בדיקות בקבצי TEST_MAPPING .

כדי להוסיף תכונה ל-Atest, עקוב אחר זרימת העבודה של Atest Developer .

הגדרת הסביבה שלך

בצע את השלבים בסעיפים הבאים כדי להגדיר את סביבת Atest שלך.

הגדר משתנה סביבה

הגדר test_suite עבור Soong או LOCAL_COMPATIBILITY_SUITE עבור בצע את כללי הסקריפט לבניית Packaging הבאים.

הפעל envsetup.sh

מהשורש של בדיקת מקור אנדרואיד, הפעל:

source build/envsetup.sh

רץ lunch

הפעל את פקודת lunch כדי להעלות תפריט של מכשירים נתמכים. מצא את המכשיר והפעל את הפקודה.

לדוגמה, אם יש לך מכשיר ARM מחובר, הפעל את הפקודה הבאה:

lunch aosp_arm64-eng

זה מגדיר משתני סביבה שונים הדרושים להפעלת Atest ומוסיף את הפקודה Atest ל- $PATH שלך.

שימוש בסיסי

פקודות Atest בעלות הצורה הבאה:

atest test-to-run [optional-arguments]

טיעונים אופציונליים

הטבלה הבאה מפרטת את הארגומנטים הנפוצים ביותר. רשימה מלאה זמינה דרך atest --help .

אוֹפְּצִיָה אפשרות ארוכה תיאור
-b --build בונה יעדי בדיקה. (בְּרִירַת מֶחדָל)
-i --install מתקין חפצי בדיקה (APK) במכשיר. (בְּרִירַת מֶחדָל)
-t --test מריץ את הבדיקות. (בְּרִירַת מֶחדָל)
-s --serial מפעיל את הבדיקות במכשיר שצוין. ניתן לבדוק מכשיר אחד בכל פעם.
-d --disable-teardown משבית את הפירוק והניקוי של הבדיקה.
<c> --info מציג את המידע הרלוונטי על היעדים שצוינו, ואז יוצא.
<c> --dry-run מפעיל יבש את Atest מבלי לבנות, להתקין או להריץ בדיקות.
-m --rebuild-module-info מאלץ בנייה מחדש של קובץ module-info.json .
-w --wait-for-debugger ממתין לסיום באגים לפני ביצוע.
-v --verbose מציג רישום ברמת DEBUG.
<c> --iterations ריצת בדיקות לולאה עד הגעה לאיטרציה המקסימלית. (10 כברירת מחדל)
<c> --rerun-until-failure [COUNT=10] מפעיל מחדש את כל הבדיקות עד להתרחשות כשל או הגעה לאיטרציה המקסימלית. (10 כברירת מחדל)
<c> --retry-any-failure [COUNT=10] מבצע בדיקות חוזרות שנכשלו עד שיעבור או השגת האיטרציה המקסימלית. (10 כברירת מחדל)
<c> --start-avd יוצר אוטומטית AVD ומריץ בדיקות במכשיר הוירטואלי.
<c> --acloud-create יוצר AVD באמצעות פקודת acloud .
<c> --[CUSTOM_ARGS] מציין ארגומנטים מותאמים אישית עבור רצי המבחן.
-a --all-abi מפעיל את הבדיקות עבור כל ארכיטקטורות ההתקן הזמינות.
<c> --host מריץ את הבדיקה לחלוטין על המארח ללא מכשיר.
הערה: הפעלת בדיקת מארח הדורשת התקן עם --host תיכשל.
<c> --flakes-info מציג את תוצאת הבדיקה עם מידע על פתיתים.
<c> --history מציג את תוצאות הבדיקה בסדר כרונולוגי.
<c> --latest-result מדפיס את תוצאת הבדיקה האחרונה.

למידע נוסף על -b , -i ו- -t , עיין בסעיף ציין שלבים: בנייה, התקנה או הפעלה .

ציין בדיקות

כדי להפעיל בדיקות, ציין בדיקה אחת או יותר באמצעות אחד מהמזהים הבאים:

  • שם המודול
  • מודול: כיתה
  • שם הכיתה
  • מבחן אינטגרציה של Tradefed
  • נתיב הקובץ
  • שם חבילה

הפרד הפניות לבדיקות מרובות עם רווחים, כך:

atest test-identifier-1 test-identifier-2

שם המודול

כדי להפעיל מודול בדיקה שלם, השתמש בשם המודול שלו. הזן את השם כפי שהוא מופיע LOCAL_MODULE או LOCAL_PACKAGE_NAME בקובץ Android.bp או Android.mk של אותה בדיקה.

דוגמאות:

atest FrameworksServicesTests
atest CtsVideoTestCases

מודול: כיתה

כדי להפעיל מחלקה אחת בתוך מודול, השתמש ב- Module:Class . המודול זהה לזה שמתואר בשם המודול . Class הוא השם של מחלקת הבדיקה בקובץ ה-. .java , ויכול להיות שם המחלקה המלא או השם הבסיסי.

דוגמאות:

atest CtsVideoTestCases:VideoEncoderDecoderTest
atest FrameworksServicesTests:ScreenDecorWindowTests
atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests

שם הכיתה

כדי להפעיל מחלקה בודדת מבלי לציין שם מודול במפורש, השתמש בשם המחלקה.

דוגמאות:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

מבחן אינטגרציה של Tradefed

כדי להפעיל בדיקות המשולבות ישירות ב-TradeFed (לא מודולים), הזינו את השם כפי שהוא מופיע בפלט של הפקודה tradefed.sh list configs . לדוגמה:

כדי להפעיל את מבחן reboot.xml :

atest example/reboot

כדי להפעיל את מבחן native-benchmark.xml :

atest native-benchmark

נתיב הקובץ

Atest תומכת בהפעלת בדיקות מבוססות מודול והן בדיקות מבוססות אינטגרציה על ידי הזנת הנתיב לקובץ הבדיקה או ספריית הבדיקה שלהם לפי הצורך. זה גם תומך בהפעלת מחלקה אחת על ידי ציון הנתיב לקובץ Java של המחלקה. נתמכים נתיבים יחסיים ומוחלטים.

הפעל מודול

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

הפעל מ- repo-root של אנדרואיד:

atest cts/tests/video

הפעל מ-Android repo-root/cts/tests/video :

    atest .

הפעל שיעור מבחן

הדוגמה הבאה מראה כיצד להפעיל מחלקה מסוימת בתוך מודול CtsVideoTestCases באמצעות נתיב קובץ.

מתוך repo-root אנדרואיד:

    atest cts/tests/video/src/android/video/cts/VideoEncoderDecoderTest.java

הפעל מבחן אינטגרציה

הדוגמה הבאה מראה כיצד להפעיל בדיקת אינטגרציה באמצעות נתיב קובץ מ- repo-root של Android:

    atest tools/tradefederation/contrib/res/config/example/reboot.xml

שם חבילה

Atest תומך בחיפוש בדיקות לפי שם החבילה.

דוגמאות:

    atest com.android.server.wm
    atest com.android.uibench.janktests

ציין שלבים: בנה, התקן או הפעל

השתמש באפשרויות -b , -i ו- -t כדי לציין אילו שלבים להפעיל. אם לא תציין אפשרות, כל השלבים יפעלו.

  • בניית יעדים בלבד: atest -b test-to-run
  • הפעל בדיקות בלבד: atest -t test-to-run
  • התקן apk והפעל בדיקות: atest -it test-to-run
  • בנה והרץ, אך אל תתקין: atest -bt test-to-run

Atest יכול לאלץ בדיקה לדלג על שלב הניקוי או ההפסקה. בדיקות רבות, כגון CTS, מנקות את המכשיר לאחר הפעלת הבדיקה, כך שניסיון להפעיל מחדש את הבדיקה שלך עם -t ייכשל ללא הפרמטר --disable-teardown . השתמש ב- -d לפני -t כדי לדלג על שלב ניקוי הבדיקה ולבדוק באופן איטרטיבי.

atest -d test-to-run
atest -t test-to-run

הפעלת שיטות ספציפיות

Atest תומך בהפעלת שיטות ספציפיות בתוך מחלקת בדיקה. למרות שצריך לבנות את כל המודול, זה מקטין את הזמן הדרוש להפעלת הבדיקות. כדי להפעיל שיטות ספציפיות, זהה את המחלקה באמצעות כל אחת מהדרכים הנתמכות לזיהוי מחלקה (מודול: מחלקה, נתיב קובץ וכו') וצרף את שם השיטה:

atest reference-to-class#method1

בעת ציון שיטות מרובות, הפרד ביניהן באמצעות פסיקים:

atest reference-to-class#method1,method2,method3

דוגמאות:

atest com.android.server.wm.ScreenDecorWindowTests#testMultipleDecors
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval

שתי הדוגמאות הבאות מציגות את הדרכים המועדפות להפעלת שיטה בודדת, testFlagChange . דוגמאות אלו עדיפות על פני שימוש בשם המחלקה בלבד מכיוון שציינת המודול או מיקום קובץ ה-Java מאפשרת ל-Atest למצוא את המבחן הרבה יותר מהר.

שימוש במודול: מחלקה:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

מתוך repo-root אנדרואיד:

atest frameworks/base/services/tests/wmtests/src/com/android/server/wm/ScreenDecorWindowTests.java#testFlagChange

ניתן להפעיל מספר שיטות ממחלקות וממודולים שונים:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors

הפעלת מספר שיעורים

כדי להפעיל מחלקות מרובות, הפרד אותם עם רווחים באותו אופן כמו להפעלת מבחנים מרובים. Atest בונה ומריצה מחלקות ביעילות, לכן ציון תת-קבוצת מחלקות במודול משפר את הביצועים על פני הפעלת המודול כולו.

כדי להפעיל שתי מחלקות באותו מודול:

atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests

כדי להפעיל שתי מחלקות במודולים שונים:

atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest

הפעל את הקבצים הבינאריים של GTest

Atest יכול להריץ קבצים בינאריים של GTest. השתמש ב- -a כדי להריץ את הבדיקות הללו עבור כל ארכיטקטורות ההתקן הזמינות, שבדוגמה זו הן armeabi-v7a (ARM 32-bit) ו- arm64-v8a (ARM 64-bit).

מבחן קלט לדוגמה:

atest -a libinput_tests inputflinger_tests

כדי לבחור GTest בינארי ספציפי להפעלה, השתמש בנקודתיים (:) כדי לציין את שם הבדיקה, וב-hashtag (#) כדי לציין עוד יותר שיטה בודדת.

לדוגמה, עבור הגדרת הבדיקה הבאה:

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

הפעל את הדברים הבאים כדי לציין את כל הבדיקה:

atest inputflinger_tests:InputDispatcherTest

לחלופין, הפעל בדיקה פרטנית באמצעות האפשרויות הבאות:

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

הפעל בדיקות ב- TEST_MAPPING

Atest יכול להריץ בדיקות בקבצי TEST_MAPPING .

הפעל בדיקות מראש באופן מרומז

הפעל מבחני הגשה מראש בקבצי TEST_MAPPING אב:

atest

הפעל מבחני הגשה מראש בקבצי TEST_MAPPING ב- /path/to/project ובספריות האב שלו:

atest --test-mapping /path/to/project

הפעל קבוצת בדיקה שצוינה

קבוצות הבדיקה הזמינות הן: presubmit (ברירת מחדל), postsubmit , mainline-presubmit all .

הפעל בדיקות לאחר הגשה בקבצי TEST_MAPPING בספריות נוכחיות ובספריות אב:

<pre>
<code class="devsite-terminal">atest :postsubmit</code>
</pre>

הפעל בדיקות מכל הקבוצות בקבצי TEST_MAPPING:

<pre>
<code class="devsite-terminal">atest :all</code>
</pre>

הפעל בדיקות לאחר הגשה בקבצי TEST_MAPPING ב- /path/to/project ובספריות האב שלו:

<pre>
<code class="devsite-terminal">atest --test-mapping <var>/path/to/project</var>:postsubmit</code>
</pre>

הפעל בדיקות ראשיות בקבצי TEST_MAPPING ב- /path/to/project ובספריות האב שלו:

    atest --test-mapping /path/to/project:mainline-presubmit
    

הפעל בדיקות בספריות משנה

כברירת מחדל, Atest מחפש רק בדיקות בקבצי TEST_MAPPING כלפי מעלה (מהספרייה הנוכחית או הנתונה לתיקיות האב שלה). אם אתה גם רוצה להריץ בדיקות בקבצי TEST_MAPPING בספריות המשנה, השתמש --include-subdirs כדי לאלץ את Atest לכלול גם את הבדיקות הללו:

atest --include-subdirs /path/to/project

הפעל בדיקות באיטרציה

הפעל בדיקות באיטרציה על ידי העברת הארגומנט --iterations . בין אם הוא עובר או נכשל, Atest יחזור על המבחן עד להגיע לאיטרציה המקסימלית.

דוגמאות:

כברירת מחדל, Atest חוזר 10 פעמים. מספר האיטרציות חייב להיות מספר שלם חיובי.

atest test-to-run --iterations
atest test-to-run --iterations 5

הגישות הבאות מקלות על זיהוי בדיקות מתקלפות:

גישה 1: הפעל את כל הבדיקות עד שמתרחש כשל או השגת האיטרציה המקסימלית.

  • עצור כאשר מתרחש כשל או שהאיטרציה מגיעה לסיבוב העשירי (כברירת מחדל).
    atest test-to-run --rerun-until-failure
    
  • עצור כאשר מתרחש כשל או שהאיטרציה מגיעה לסיבוב ה-100.
    atest test-to-run --rerun-until-failure 100
    

גישה 2: הפעל רק מבחנים שנכשלו עד שתעבור או השגת האיטרציה המקסימלית.

  • נניח שלבדיקה test-to-run יש מספר מקרי בדיקה ואחת מהבדיקות נכשלת. הפעל רק את המבחן שנכשל 10 פעמים (כברירת מחדל) או עד שהבדיקה תעבור.
    atest test-to-run --retry-any-failure
    
  • הפסק להריץ את המבחן שנכשל כאשר הוא עובר או יגיע לסיבוב ה-100.
    atest test-to-run --retry-any-failure 100
    

הפעל בדיקות על AVDs

Atest מסוגלת להריץ בדיקות על AVD שזה עתה נוצר. הפעל acloud create כדי ליצור AVD ולבנות חפצים, ולאחר מכן השתמש בדוגמאות הבאות כדי להפעיל את הבדיקות שלך.

הפעל AVD והפעל עליו בדיקות:

acloud create --local-instance --local-image && atest test-to-run

התחל AVD כחלק מניסוי:

atest test-to-run --acloud-create "--local-instance --local-image"

למידע נוסף, הפעל acloud create --help .

העברת אפשרויות למודול

Atest מסוגלת להעביר אפשרויות לבדיקת מודולים. כדי להוסיף אפשרויות שורת הפקודה של TradeFed להפעלת המבחן שלך, השתמש במבנה הבא וודא שהארגומנטים המותאמים אישית שלך עוקבים אחר פורמט אפשרויות שורת הפקודה של Tradefed.

atest test-to-run -- [CUSTOM_ARGS]

העבר את אפשרויות מודול הבדיקה למכיני מטרה או רצים לבדיקה המוגדרים בקובץ תצורת הבדיקה:

atest test-to-run -- --module-arg module-name:option-name:option-value
atest GtsPermissionTestCases -- --module-arg GtsPermissionTestCases:ignore-business-logic-failure:true

אפשרויות מעבר לסוג רץ או לכיתה:

atest test-to-run -- --test-arg test-class:option-name:option-value
atest CtsVideoTestCases -- --test-arg com.android.tradefed.testtype.JarHosttest:collect-tests-only:true

למידע נוסף על אפשרויות לבדיקה בלבד, ראה אפשרויות מעבר למודולים .