מיפוי בדיקות

זהו מבוא קצר של מיפוי בדיקות והסבר על האופן שבו ניתן לקבל התחילה להגדיר בדיקות בפרויקט הקוד הפתוח של Android (AOSP).

מידע על מיפוי בדיקות

מיפוי בדיקות הוא גישה מבוססת Gerrit שמאפשרת למפתחים ליצור הגשה מראש את כללי הבדיקה לאחר השליחה ישירות בעץ המקור של Android ומשאירים את החלטות לגבי הסתעפויות ומכשירים שייבדקו בתשתית הבדיקה. הגדרות המיפוי לבדיקה הן קובצי JSON שנקראים TEST_MAPPING, שניתן להשתמש בהם בכל ספריית מקור.

Atest יכול להשתמש בקובצי TEST_MAPPING כדי להריץ בדיקות טרום-שליחה של הספריות המשויכות. בעזרת מיפוי בדיקות, אפשר להוסיף את אותה קבוצה של בדיקות ל לשלוח בדיקות מראש עם שינוי מינימלי בעץ המקור של Android.

כדאי לעיין בדוגמאות הבאות:

מיפוי הבדיקות מסתמך על ערכת הבדיקה של Trade Federation‏ (TF) להרצת בדיקות ולדיווח על תוצאות.

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

בדיקת המיפוי מקבצת בדיקות באמצעות קבוצת בדיקה. שם קבוצת הבדיקה יכול להיות כל מחרוזת. לדוגמה, presubmit יכול להיות השם של קבוצת בדיקות. בזמן אימות השינויים. שליחה לאחר השליחה יכולה לשמש כבדיקות לאימות גרסאות ה-build אחרי מיזוג השינויים.

כללים של סקריפט build לחבילות

כדי להשתתף במסגרת הבדיקה של Traade Federation כדי להריץ מודולים לבדיקה עבור build מסוים, המודולים test_suites מוגדר ל-Soong או ל-LOCAL_COMPATIBILITY_SUITE ליצירת אחת משתי הסוויטות הבאות:

  • general-tests מיועד לבדיקות שלא תלויות במכשיר ספציפי יכולות (למשל חומרה ספציפית לספק, שרוב המכשירים לא תומכים בה יש). רוב הבדיקות צריכות להיכלל בחבילת general-tests, גם אם הן ספציפיות ל-ABI אחד או לגודל ביט אחד או לתכונות חומרה כמו HWASan (יש יעד test_suites נפרד לכל ABI), וגם אם הן צריכות לפעול במכשיר.
  • device-tests מיועד לבדיקות שתלויות ביכולות ספציפיות למכשיר. בדרך כלל הבדיקות האלה נמצאות בקטע vendor/. Device-specific (ספציפי למכשיר) מתייחס רק ליכולות ייחודיות למכשיר מסוים, כך שההגדרה הזו חלה על בדיקות JUnit וגם על בדיקות GTest (בדרך כלל צריך לסמן אותן בתווית general-tests גם אם הן ספציפיות ל-ABI).

לדוגמה:

Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests

הגדרת בדיקות להרצה בחבילת בדיקות

כדי שבדיקה תרוץ בתוך חבילת בדיקות, היא צריכה:

  • אסור שיהיה לו ספק build.
  • צריך לנקות אחרי שהבדיקה מסתיימת, למשל על ידי מחיקת קבצים זמניים שנוצרו במהלך הבדיקה.
  • צריך לשנות את הגדרות המערכת לערך ברירת המחדל או לערך המקורי.

  • לא צריך להניח שמכשיר נמצא במצב מסוים, למשל מוכן ל-root. רוב הבדיקות לא דורשות הרשאת root כדי להריץ אותן. אם הבדיקה מחייבת שורש, הוא צריך לציין את זה עם RootTargetPreparer AndroidTest.xml, כמו בדוגמה הבאה:

    <target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>

יצירת קובצי מיפוי לבדיקה

בתיקייה שרוצים לבדוק, מוסיפים קובץ JSON מסוג TEST_MAPPING שדומה לדוגמה. הכללים האלה מבטיחים שהבדיקות יפעלו בודק מראש בכל פעם שנוגעים בקבצים בספרייה הזו או באחד מהם ספריות משנה.

דוגמה

לפניכם קובץ TEST_MAPPING לדוגמה (הוא בפורמט JSON אבל תומך בתגובות):

{
  "presubmit": [
    // JUnit test with options and file patterns.
    {
      "name": "CtsWindowManagerDeviceTestCases",
      "options": [
        {
          "include-annotation": "android.platform.test.annotations.RequiresDevice"
        }
      ],
      "file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
    },
    // Device-side GTest with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side GTest.
    {
      "name" : "net_test_avrcp",
      "host" : true
    }
  ],
  "postsubmit": [
    {
      "name": "CtsDeqpTestCases",
      "options": [
        {
          // Use regex in include-filter which is supported in AndroidJUnitTest
          "include-filter": "dEQP-EGL.functional.color_clears.*"
        }
      ]
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

הגדרת מאפיינים

בדוגמה, presubmit ו-postsubmit הם השמות של כל קבוצת בדיקה. למידע נוסף על קבוצות בדיקה, ראו הגדרת קבוצות בדיקה.

אפשר להגדיר את השם של מודול הבדיקה או את השם של בדיקת השילוב של Trade Federation (נתיב המשאב לקובץ ה-XML לבדיקה, לדוגמה, uiautomator/uiautomator-demo) בערך של המאפיין name. שימו לב שאי אפשר להשתמש בשדה name בכיתה name או בשיטת הבדיקה name. כדי לצמצם את הבדיקות שרוצים להריץ, אפשר להשתמש באפשרויות כמו include-filter. דוגמה לשימוש ב-include-filter

ההגדרה host של הבדיקה מציינת אם הבדיקה היא בדיקה ללא מכשיר פועל על מארח או לא. ערך ברירת המחדל הוא false, כלומר ערך הבדיקה נדרש מכשיר כדי לפעול. סוגי הבדיקות הנתמכים הם HostGTest לקובצי הבינארי של GTest ו-HostTest לבדיקות של JUnit.

המאפיין file_patterns מאפשר להגדיר רשימה של מחרוזות של ביטויים רגולריים להתאמת הנתיב היחסי של כל קובץ קוד מקור (ביחס ספרייה שמכילה את הקובץ TEST_MAPPING). בדוגמה, הבדיקה CtsWindowManagerDeviceTestCases פועלת לפני שליחת הקוד רק כשקובץ Java שמתחיל ב-Window או ב-Activity קיים באותה ספרייה שבה נמצא הקובץ TEST_MAPPING או באחת מספריות המשנה שלו. הלוכסן ההפוך (\) צריך להיות לסמן בתו בריחה (escape) כי הם נמצאים בקובץ JSON.

המאפיין imports מאפשר לכלול בדיקות בקובצי TEST_MAPPING אחרים מבלי להעתיק את התוכן. גם קובצי TEST_MAPPING בספריות ההורה של הנתיב שיובאו נכללים. מיפוי הבדיקה מאפשר ייבוא מקונן; המשמעות היא ששני קובצי TEST_MAPPING יכולים לייבא זה את זה, מיפוי הבדיקות יכול למזג את הבדיקות הכלולים.

המאפיין options מכיל אפשרויות נוספות של שורת הפקודה של Tradefed.

כדי לקבל רשימה מלאה של האפשרויות הזמינות לבדיקה נתונה, הריצו את:

tradefed.sh run commandAndExit [test_module] --help

למידע נוסף על אופן הפעולה של אופציות, אפשר לעיין במאמר טיפול באופציות ב-Tradefed.

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

כדי להפעיל באופן מקומי את כללי הבדיקה לפני הגשה מראש:

  1. עוברים לספרייה שמכילה את הקובץ TEST_MAPPING.

  2. מריצים את הפקודה:

    atest

כל הבדיקות שהוגשו מראש שהוגדרו ב-TEST_MAPPING הקבצים של ההגדרה הנוכחית והספרייה הראשית שלה מופעלות. Atest מאתר ומפעיל שתי בדיקות (A ו-B) לפני שליחת הקוד.

זו הדרך הישירה ביותר להריץ בדיקות טרום-שליחה ב-TEST_MAPPING הקבצים בספריית העבודה הנוכחית (CWD) ובספריות ההורה. עדכני מאתר את הקובץ TEST_MAPPING ב-CWD ובכל רמות האב שלו ומשתמש בו של ספריות.

קוד מקור של מבנה

הדוגמה הזו ממחישה איך אפשר להגדיר TEST_MAPPING קבצים דרך עץ המקור:

src
├── project_1
│   └── TEST_MAPPING
├── project_2
│   └── TEST_MAPPING
└── TEST_MAPPING

התוכן של src/TEST_MAPPING:

{
  "presubmit": [
    {
      "name": "A"
    }
  ]
}

התוכן של src/project_1/TEST_MAPPING:

{
  "presubmit": [
    {
      "name": "B"
    }
  ],
  "postsubmit": [
    {
      "name": "C"
    }
  ],
  "other_group": [
    {
      "name": "X"
    }
  ]}

התוכן של src/project_2/TEST_MAPPING:

{
  "presubmit": [
    {
      "name": "D"
    }
  ],
  "import": [
    {
      "path": "src/project_1"
    }
  ]}

ציון ספריות יעד

אפשר לציין ספריית יעד להרצת בדיקות ב-TEST_MAPPING קבצים בתיקייה הפקודה הבאה מפעילה שתי בדיקות (A, B):

atest --test-mapping src/project_1

הרצת כללים לבדיקה לאחר השליחה

אפשר להשתמש בפקודה הזו גם כדי להריץ את כללי הבדיקה לאחר השליחה המוגדרים ב- TEST_MAPPING ב-src_path (ברירת המחדל היא CWD) וספריות ההורה שלו:

atest [--test-mapping] [src_path]:postsubmit

להריץ רק בדיקות שלא דורשות מכשיר

אפשר להשתמש באפשרות --host ל-Atest כדי להריץ רק את הבדיקות שהוגדרו מול המארח שלא דורש מכשיר. בלי האפשרות הזו, Atest מפעיל את שני סוגי הבדיקות – אלה שדורשות מכשיר ואלה שפועלות במארח בלי צורך במכשיר. הבדיקות מתבצעות בשתי חבילות נפרדות:

atest [--test-mapping] --host

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

אפשר לציין קבוצות בדיקה בפקודה Atest. הפקודה הבאה רצה כל postsubmit הבדיקות הקשורות לקבצים בספרייה src/project_1, מכיל בדיקה אחת בלבד (C).

לחלופין, אפשר להשתמש ב-:all כדי להריץ את כל הבדיקות, ללא קשר לקבוצה. הבאים הפקודה מריצה ארבעה בדיקות (A, B, C, X):

atest --test-mapping src/project_1:all

לכלול ספריות משנה

כברירת מחדל, הרצת בדיקות ב-TEST_MAPPING עם Atest מריצה רק שליחה מראש בדיקות שהוגדרו בקובץ TEST_MAPPING ב-CWD (או בספרייה הנתונה) ואת ספריות ההורה שלה. אם רוצים להריץ בדיקות TEST_MAPPING קבצים בספריות המשנה, ניתן להשתמש באפשרות --include-subdir כדי לאכוף גם את המבחנים האלה.

atest --include-subdir

בלי האפשרות --include-subdir, הפקודה Atest מריצה רק את הבדיקה A. כשמשתמשים באפשרות --include-subdir, המערכת של Atest מפעילה שתי בדיקות (A ו-B).

תמיכה בתגובות ברמת השורה

אפשר להוסיף תגובה בפורמט // ברמת השורה כדי לרענן את TEST_MAPPING ולהוסיף תיאור של ההגדרה הבאה. ATest ו-Trade Federation מבצעים עיבוד מקדים של TEST_MAPPING לפורמט JSON תקין ללא הערות. כדי לשמור על ניקיון קובץ ה-JSON, יש תמיכה רק בהערות בפורמט // ברמת השורה.

דוגמה:

{
  // For presubmit test group.
  "presubmit": [
    {
      // Run test on module A.
      "name": "A"
    }
  ]
}