מיפוי בדיקה

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

מהו מיפוי מבחן?

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

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

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

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

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

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

הגדרת קבוצות מבחן

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

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

כדי ש- Trade Federation Test Harness תריץ את מודולי הבדיקה של Test Mapping עבור מבנה נתון, מודולים אלה חייבים להגדיר 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 --include-subdir , Atest יריץ רק את מבחן A. עם האפשרות --include --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"
    }
  ]
}