מבחן

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 מאפשרת ל-Atest למצוא את המבחן הרבה יותר מהר:

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

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

דוגמאות:

כברירת מחדל atest iterates 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 --local-instance --local-image && atest test-to-run
    

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

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

כדי לקבל פירוט שימוש לגבי הטיעון, לרוץ 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

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