מיפוי בדיקה

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

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

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

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

ראה דוגמאות אלה:

הוסף מראש בדיקות ל-TEST_MAPPING עבור services.core

הוסף בדיקות מראש ל-TEST_MAPPING עבור כלים/דקסטר באמצעות ייבוא

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

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

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

כללי סקריפט לבניית חבילה

כדי ש- Trader Federation Test Harness תפעיל את מודולי הבדיקה של מיפוי הבדיקה עבור מבנה נתון, מודולים אלה חייבים להגדיר test_suite עבור Soong או LOCAL_COMPATIBILITY_SUITE להגדיר עבור Make לאחת משתי החבילות הללו:

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

דוגמאות:

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

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

כדי שבדיקה תפעל בתוך חבילת בדיקה, הבדיקה:

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

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

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

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

בצע דוגמה

הנה קובץ 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": "CtsWindowManagerDeviceTestCases"
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

הגדר תכונות

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

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

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

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

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

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

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

tradefed.sh run commandAndExit [test_module] --help

עיין בטיפול באופציות TradeFed לפרטים נוספים על אופן פעולת האופציות.

הפעל בדיקות עם Atest

כדי לבצע את כללי הבדיקה המוקדמת באופן מקומי:

1. עבור אל הספרייה המכילה את הקובץ TEST_MAPPING.
2. הפעל את הפקודה:

atest

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

זוהי הדרך הפשוטה ביותר להריץ בדיקות מוקדמות בקבצי TEST_MAPPING בספריית העבודה הנוכחית (CWD) ובספריות האב. Atest יאתר ותשתמש בקובץ 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 לכלול גם את הבדיקות הללו.

atest --include-subdir

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

הערה ברמת השורה נתמכת

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

דוגמא:

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