הרצת בדיקות (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 יוצר יעדי בדיקה של גרסאות build. (ברירת מחדל)
-i --install התקנת פריטי מידע שנוצרים בתהליך פיתוח (Artifact) של בדיקות (חבילות APK) במכשיר. (ברירת מחדל)
-t --test מריץ את הבדיקות. (ברירת מחדל)
-s --serial מריצים את הבדיקות במכשיר שצוין. אפשר לבדוק רק מכשיר אחד בכל פעם.
-d --disable-teardown משבית את הניקוי וההסרה של הבדיקה.
--dry-run הרצות בדיקה של Atest בלי לבצע בנייה, התקנה או הרצה של בדיקות.
-m --rebuild-module-info מאלץ בנייה מחדש של הקובץ module-info.json.
-w --wait-for-debugger ממתין שמנפה הבאגים יסיים לפני ההרצה.
-v --verbose הצגת רישום ביומן ברמת ניפוי הבאגים.
--iterations הבדיקות של Loop רצות עד שמגיעים למספר המקסימלי של האיטרציות. (10 כברירת מחדל)
--rerun-until-failure [COUNT=10] מריץ מחדש את כל הבדיקות עד שמתרחשת שגיאה או עד שמגיעים למספר האיטרציות המקסימלי. (10 כברירת מחדל)
--retry-any-failure [COUNT=10] מריץ מחדש בדיקות שנכשלו עד שהן עוברות או עד שמגיעים למספר המקסימלי של איטרציות. ‫(10 כברירת מחדל)
--start-avd יוצר באופן אוטומטי מכשיר וירטואלי של Android (AVD) ומריץ בדיקות במכשיר הווירטואלי.
--acloud-create יוצרים מכשיר וירטואלי באמצעות הפקודה 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

מציינים את השלבים: Build,‏ install או run

משתמשים באפשרויות -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 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

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