מיפוי מבחנים

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

מהו מיפוי מבחנים?

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

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

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

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

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

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

הגדרת קבוצות מבחנים

קבוצות מיפוי מבחן בדיקות באמצעות קבוצת מבחן. שמה של קבוצת בדיקה יכול להיות כל מחרוזת. לדוגמה, presubmit יכול להיות עבור קבוצה של בדיקות לרוץ כאשר תוקף לשינויים. וזה בדיקות postsubmit יכול לשמש כדי לאמת את הבונה לאחר שהשינויים מוטמעים.

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

במטרה להביא את רתמה מבחן פדרציית הסחר לרוץ מודולים המבחן של מבחן מיפוי לבנות נתון, מודולים אלה חייבים להיות test_suite סט עבור סונג סט או LOCAL_COMPATIBILITY_SUITE עבור Make לאחת משתי אלה סוויטות:

  • מבחנים כלליים - בדיקות שאיננו תלוי בתכונות מכשיר ספציפיות. רוב הבדיקות צריכות להיות בחבילת הבדיקות הכלליות, מכיוון שניתן לבנות אותן על היעד test_suites הכולל את הקבצים הבינאריים (לבדיקות מקוריות) בכל ABIs הנתמכים (32 מול 64).
  • מכשיר בדיקות - בדיקות תלוי בתכונות מכשיר ספציפי, Runnable רק על מטרות מכשיר מסוימות, או יכולות להיבנות רק רק על מטרות מכשיר מסוימות. זה נכון בין אם הבדיקה היא מבחן מקורי או מבחן JUnit.

דוגמאות:

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

הגדרת בדיקות להפעלה בחבילת בדיקות

כדי שהבדיקה תתבצע בתוך חבילת מבחנים, הבדיקה:

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

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

<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 native test with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side native test.
    {
      "name" : "net_test_avrcp",
      "host" : true
    }
  ],
  "postsubmit": [
    {
      "name": "CtsWindowManagerDeviceTestCases"
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

הגדרת תכונות

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

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

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

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

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

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

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

tradefed.sh run commandAndExit [test_module] --help

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

מבצעים בדיקות עם אטסט

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

  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

הפעלת חוקי הבדיקה לאחר ההגשה

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

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

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

ניתן להשתמש באפשרות --host עבור atest למבחנים רק לרוץ מוגדרים נגד המארחת כי לא דורשת מכשיר. ללא אפשרות זו, Atest תריץ את שתי הבדיקות, אלה הדורשות מכשיר והן אלה הפועלות על מארח ואינן דורשות מכשיר. המבחנים יתקיימו בשתי סוויטות נפרדות.

atest [--test-mapping] --host

זיהוי קבוצות מבחנים

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

או שאתה יכול להשתמש: כל לרוץ כל הבדיקות ללא קשר לקבוצה. הפקודה הבאה מריצה ארבע בדיקות (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 יפעל א המבחן היחיד עם --include-subdir האופציה, atest ירוצו שתי בדיקות (A, B).

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

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

דוגמא:

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