הרצת בדיקות (atest)

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

לקבלת מידע כללי על כתיבת בדיקות ל-Android, ראו: Android Platform Testing.

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

מידע על הרצת בדיקות בקובצי TEST_MAPPING באמצעות Atest זמין בכתובת מריץ בדיקות בקובצי TEST_MAPPING.

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

הגדרת הסביבה

כדי להגדיר את סביבת Atest, פועלים לפי ההוראות במאמרים הגדרת הסביבה, בחירת יעד ויצירת הקוד.

שימוש בסיסי

פקודות האימות מופיעות בצורה הבאה:

atest test-to-run [optional-arguments]

ארגומנטים אופציונליים

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

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

ציון הבדיקות

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

• שם המודול
• יחידת לימוד:כיתה
• שם הכיתה
• בדיקת שילוב של רכיב טרי
• נתיב הקובץ
• שם חבילה

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

atest test-identifier-1 test-identifier-2

שם המודול

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

לדוגמה:

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

בדיקת שילוב של רכיב טרי

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

כדי להריץ את בדיקת reboot.xml:

atest example/reboot

כדי להריץ את בדיקת native-benchmark.xml:

atest native-benchmark

נתיב הקובץ

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

הפעלת מודול

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

הפעלה מ-Android repo-root:

atest cts/tests/video

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

    atest .

הרצת כיתה לבדיקה

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

מ-Android repo-root:

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

הרצה של בדיקת שילוב

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

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

שם חבילה

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

לדוגמה:

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

ציון השלבים: build,‏ install או run

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

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

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

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

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

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

atest reference-to-class#method1

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

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

לדוגמה:

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

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

שימוש ב-Module:Class:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

מ-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

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

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

בדיקת קלט לדוגמה:

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 בספריות הנוכחיות ובספריות ההורה:

atest :postsubmit

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

atest :all

הרצת בדיקות לאחר שליחה ב-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

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

כברירת מחדל, התכונה 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
  

הרצת בדיקות של מכשירי AVD

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

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

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