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

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

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

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

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

כדי להוסיף תכונה ל-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

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

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

לדוגמה:

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

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