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

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

מידע כללי על כתיבת בדיקות ל-Android זמין במאמר בדיקות של פלטפורמת Android.

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

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

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

הגדרת הסביבה

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

שימוש בסיסי

פקודות Atest נראות כך:

atest test-to-run [optional-arguments]

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

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

אפשרות אפשרות ארוכה תיאור
-b --build יוצר יעדי בדיקה. (ברירת מחדל)
-i --install הפקודה מתקינה במכשיר פריטי מידע שנוצרים בתהליך פיתוח (Artifact) של בדיקות (חבילות APK). (ברירת מחדל)
-t --test מריץ את הבדיקות. (ברירת מחדל)
-s --serial מריצים את הבדיקות במכשיר שצוין. אפשר לבדוק רק מכשיר אחד בכל פעם.
-d --disable-teardown משבית את פירוק הבדיקה ואת הניקוי.
--dry-run הרצות ניסיון של Atest בלי לבצע build, התקנה או הרצה של בדיקות.
-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 יוצר באופן אוטומטי מכשיר וירטואלי של Android (AVD) ומריץ בדיקות במכשיר הווירטואלי.
--acloud-create יצירת מכשיר וירטואלי של Android באמצעות הפקודה acloud.
--[CUSTOM_ARGS] מציינים ארגומנטים מותאמים אישית להרצת הבדיקות.
-a --all-abi מריצים את הבדיקות לכל הארכיטקטורות הזמינות של המכשירים.
--host מריץ את הבדיקה באופן מלא במארח ללא מכשיר.
הערה: הפעלת בדיקת מארח שנדרש בה מכשיר עם --host תיכשל.
--history התוצאות של הבדיקה מוצגות בסדר כרונולוגי.
--latest-result מדפיס את תוצאת הבדיקה האחרונה.

מידע נוסף על -b,‏ -i ו--t זמין בקטע הגדרת השלבים: build,‏ install או run.

ציון בדיקות

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

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

כדי להפנות לכמה בדיקות, צריך להפריד ביניהן ברווחים, כמו בדוגמה הבאה:

atest test-identifier-1 test-identifier-2

שם המודול

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

לדוגמה:

atest FrameworksServicesTests
atest CtsVideoTestCases

מודול:Class

כדי להריץ כיתה אחת בתוך מודול, משתמשים ב-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 באמצעות נתיב קובץ.

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

  • רק יעדי build‏: 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 תומך בהרצת שיטות ספציפיות בכיתת בדיקה. למרות שצריך לבנות את המודול כולו, זה מקצר את הזמן שנדרש להרצת הבדיקות. כדי להפעיל שיטות ספציפיות, צריך לזהות את המחלקה באמצעות אחת מהדרכים שנתמכות לזיהוי מחלקה (Module:Class, נתיב קובץ וכו') ולצרף את שם השיטה:

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

שימוש ב-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 להפעלה, משתמשים בנקודתיים (:) כדי לציין את שם הבדיקה, ובסולמית (#) כדי לציין שיטה ספציפית.

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

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

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