מבחן

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

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

לקבלת מידע על המבנה הכללי של atest, לראות מדריך Developer atest .

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

וכדי להוסיף תכונה atest, בצע Workflow Developer atest .

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

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

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

Test_suite הגדרת סונג או LOCAL_COMPATIBILITY_SUITE עבור Make לכול אריזת כללי תסריט לבנות .

הפעל envsetup.sh

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

source build/envsetup.sh

לרוץ ארוחת צהריים

הפעל את 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 משבית את ניסיונות הניקיון והניקיון.
--info מציג את המידע הרלוונטי של היעדים והיציאות שצוין.
--dry-run ריצות יבשות בודדות מבלי לבנות, להתקין ולהריץ בדיקות בפועל
-m --rebuild-module-info כוחות לשקם של module-info.json קובץ.
-w --wait-for-debugger מחכה לאיתור באגים לפני ביצוע. רק לבדיקות מכשור.
-v --verbose מציג רישום ברמת DEBUG.
--iterations בדיקות לולאה עד להגעה לאיטרציה המרבית. (10 כברירת מחדל)
--rerun-until-failure [COUNT=10] מבצע מחדש את כל הבדיקות עד לכשל או עד שהאיטרציה המקסימלית מגיעה. (10 כברירת מחדל)
--retry-any-failure [COUNT=10] הפעלות חוזרות של הבדיקות עד שהן עברו או שהאיטרציה המרבית מושגת. (10 כברירת מחדל)
--start-avd יוצר אוטומטית AVD ומריץ בדיקות במכשיר הווירטואלי.
--acloud-create יוצר AVDs באמצעות acloud command.
--[CUSTOM_ARGS] מציין ארגומנטים מותאמים אישית עבור רצי המבחנים.
-a --all-abi מריץ את הבדיקות לכל ארכיטקטורות המכשירים הזמינות.
--host מבצע את הבדיקה לחלוטין על המארח ללא מכשיר.
(הערה: הפעלת בדיקה מארחת כי יש צורך במכשיר עם --host ייכשל.)
--flakes-info מציג את תוצאת הבדיקה עם מידע על פתיתים.
--history מציג את תוצאת הבדיקה בסדר כרונולוגי.
--latest-result מדפיס את תוצאת הבדיקה העדכנית ביותר.

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

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

אתה יכול להריץ בדיקות אחד או יותר באמצעות test-to-run . כדי להריץ מספר בדיקות, יש להפריד בין הפניות הבדיקה לרווחים. לדוגמה:

atest test-to-run-1 test-to-run-2

הנה כמה דוגמאות:

atest FrameworksServicesTests
atest example/reboot
atest FrameworksServicesTests CtsVideoTestCases
atest FrameworksServicesTests:ScreenDecorWindowTests

לקבלת מידע נוסף על אופן הפניה לבדיקה, עיינו זיהוי בדיקות.

זיהוי בדיקות

אתה יכול לציין את test-to-run טיעון עם שם המודול של הבדיקה, מודול: מחלקה, שם המחלקה, בדיקת אינטגרציה TF, נתיב קובץ או שם החבילה.

שם המודול

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

דוגמאות:

atest FrameworksServicesTests
atest CtsVideoTestCases

מודול: כיתה

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

דוגמאות:

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

שם הכיתה

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

דוגמאות:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

באמצעות מודול: הפניה מחלקה מומלץ במידת האפשר מאז atest דורש יותר זמן לחפש את מקור העץ המלא ל התאמות פוטנציאליות אם אין מודול נאמר.

דוגמאות (מסודרות מהמהירות לאטיות ביותר):

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

מבחן שילוב TF

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

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

atest example/reboot

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

atest native-benchmark

נתיב קובץ

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

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

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

    atest cts/tests/video
    
  2. מ אנדרואיד repo-root / CTS / בדיקות / וידאו:

    atest .
    

דוגמה: הפעלה מסוג ספציפי בתוך CtsVideoTestCases מודול באמצעות נתיב. מ אנדרואיד repo-root :

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

דוגמה: הפעל בדיקת אינטגרציה דרך נתיב. מ אנדרואיד repo-root :

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 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 מאפשר לאסטסט למצוא את הבדיקה הרבה יותר מהר:

  1. שימוש במודול: Class

    atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange
    
  2. מ Android 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
    

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

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

דוגמאות:

  • בדיקות קלט:

    atest -a libinput_tests inputflinger_tests
    

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

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

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

atest inputflinger_tests:InputDispatcherTest

או שיטת בדיקה בודדת באמצעות

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

מבצעים בדיקות ב- TEST_MAPPING

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

  1. הפעל בדיקות שלח מראש במרומז ב- TEST_MAPPING קבצים בספריות נוכחיות, אב או ספציפיות.

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

    atest
    

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

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

  2. הפעל קבוצת מבחן מפורטת TEST_MAPPING קבצים; קבוצות מבחן הזמינות הן: presubmit (ברירת המחדל), postsubmit , mainline-presubmit ואת all .

    • הפעילו בדיקות postsubmit בקבצי TEST_MAPPING בספריות נוכחיות הורה:

      atest :postsubmit
      

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

      atest :all
      

    • בדיקות postsubmit מפעילים קבצי TEST_MAPPING ב /path/to/project והספריות האם שלה

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

    • הפעל בדיקות האליטה חברתיות בקבצי TEST_MAPPING ב /path/to/project והספריות האם שלה

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

  3. הפעל בדיקות בקבצים TEST_MAPPING כולל ספריות משנה.

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

בדיקות presubmit מפעילים קבצי TEST_MAPPING בזרם מים, ההורה לתיקיות משנה:

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

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

לערוך בדיקות איטרציה, פשוט להעביר את --iterations הטיעון. בין אם זה עובר או נכשל, 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 החדש שנוצר. Atest יכול לבנות חפצים לצד ריצות acloud create , ולהפעיל בדיקות לאחר AVD נוצרו בהצלחה.

דוגמאות:

  • התחל AVD לפני הפעלת בדיקות במכשיר הזה החדש שנוצר:

    acloud create && atest test-to-run
    
    עכשיו זה יכול להיות פשוט יותר על ידי:
    atest test-to-run --start-avd
    

  • התחל AVDs ידי specifing acloud create טיעונים ולהפעיל בדיקות במכשיר הזה החדש שנוצר.

    atest test-to-run --acloud-create "--build-id 6509363 --build-target aosp_cf_x86_phone-userdebug --branch aosp_master"
    

כדי לקבל פירוט שימוש לגבי הטיעון, לרוץ acloud create --help .

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

Atest מסוגלת להעביר אפשרויות למודולים. הפורמט קצרה שורת הפקודה atest להוסיף אפשרות שורת הפקודה TradeFed הוא

atest test-to-run -- [CUSTOM_ARGS]
ה [CUSTOM_ARGS] צריך לעקוב הפורמטים אפשרות שורת הפקודה Tradefed.

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

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

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