בדיקת תבניות

AOSP כולל תבניות בדיקה למערכי בדיקה שאינם תת-סוג של Python בצד המארח של BaseTest של VTS runner.

איור 1. בדיקת הארכיטקטורה של התבנית.

מפתחים יכולים להשתמש בתבניות האלה כדי לצמצם את המאמץ הנדרש לשילוב בדיקות כאלה. בקטע הזה נסביר איך מגדירים את תבניות הבדיקה (שנמצאות בספרייה testcases/template ב-VTS) ואיך משתמשים בהן, ונספק דוגמאות לתבניות נפוצות.

תבנית BinaryTest

משתמשים בתבנית BinaryTest כדי לשלב בדיקות שמבוצעות במכשיר היעד ב-VTS. בדיקות בצד היעד כוללות:

  • בדיקות מבוססות C++‎ שעבר קומפילציה ונדחפו למכשיר
  • בדיקות Python בצד היעד שעבר עיבוד (compile) כקובצי בינארי
  • סקריפטים של מעטפת שניתן להריץ במכשירים

אפשר לשלב את הבדיקות האלה ב-VTS עם התבנית BinaryTest או בלי התבנית.

שילוב בדיקות בצד היעד באמצעות התבנית BinaryTest

התבנית BinaryTest נועדה לעזור למפתחים לשלב בקלות בדיקות בצד היעד. ברוב המקרים, אפשר להוסיף כמה שורות פשוטות של הגדרה ב-AndroidTest.xml. הגדרה לדוגמה מ-VtsDeviceTreeEarlyMountTest: 

<configuration description="Config for VTS VtsDeviceTreeEarlyMountTest.">
  ...
<test class="com.android.tradefed.testtype.VtsMultiDeviceTest">
<option name="test-module-name" value="VtsDeviceTreeEarlyMountTest"/>
<option name="binary-test-source" value="_32bit::DATA/nativetest/dt_early_mount_test/dt_early_mount_test" />
<option name="binary-test-source" value="_64bit::DATA/nativetest64/dt_early_mount_test/dt_early_mount_test" />
<option name="test-timeout" value="5m"/>
</test>
</configuration>

בהגדרה הזו:

  • הערכים של binary-test-source ו-binary-test-type ספציפיים לתבנית.
  • ציון נתיב המארח היחסי של מקור הבדיקה הבינארי מאפשר לתבנית לטפל בהכנה, בהעברת קבצים, בהרצת הבדיקה, בניתוח התוצאות ובניקוי.
  • התבנית מכילה שיטות שקשורות ליצירת תרחישים לבדיקה, שאפשר לשנות אותן בסוגי המשנה.
  • בתבנית מוגדרת בדיקת מקרה אחת לכל מודול בינארי לבדיקה, ושם קובץ המקור הבינארי משמש בתור שם בדיקת המקרה כברירת מחדל.

אפשרויות הגדרה

התבנית BinaryTest תומכת באפשרויות ההגדרה הבאות:

שם האפשרות סוג הערך תיאור
binary-test-source מחרוזות נתיבי המקור של בדיקות בינאריות ביחס לספריית מקרי הבדיקה של vts במארח.
דוגמה: DATA/nativetest/test
binary-test-working-directory מחרוזות ספריות עבודה (נתיב בצד המכשיר).
דוגמה: /data/local/tmp/testing/
binary-test-envp מחרוזות משתני סביבה לקובץ הבינארי.
דוגמה: PATH=/new:$PATH
binary-test-args מחרוזות בדיקת ארגומנטים או דגלים.
דוגמה: --gtest_filter=test1
binary-test-ld-library-path מחרוזות משתנה הסביבה LD_LIBRARY_PATH.
דוגמה: /data/local/tmp/lib
binary-test-disable-framework בוליאני מריצים את הפקודה adb stop כדי להשבית את Android Framework לפני הבדיקה. דוגמה: true
binary-test-stop-native-servers בוליאני במהלך הבדיקה, צריך להפסיק את כל השרתים המקוריים שהוגדרו כראוי. דוגמה: true
binary-test-type מחרוזת סוג התבנית. סוגי תבניות אחרים מתבססים על התבנית הזו, אבל אין צורך לציין את האפשרות הזו לגבי התבנית הזו כי כבר ציינת את binary-test-source.

לאפשרויות עם סוג הערך strings, אפשר להוסיף כמה ערכים על ידי חזרה על האפשרויות בהגדרה. לדוגמה, מגדירים את binary-test-source פעמיים (כמו בדוגמה VtsDeviceTreeEarlyMountTest).

תגי בדיקה

כדי להוסיף תגי בדיקה, מוסיפים אותם כתחילית לאפשרויות עם ערכים של strings ומשתמשים ב-:: כתו המפריד. תגי בדיקה שימושיים במיוחד כשרוצים לכלול מקורות בינאריים עם אותו שם אבל עם מספר ביט שונה או ספריות הורה שונות. לדוגמה, כדי למנוע התנגשויות בשמות של תוצאות או של קובצי push ממקורות עם אותו שם אבל מספריות מקור שונות, אפשר לציין תגים שונים למקורות האלה.

כפי שמוצג בדוגמה של VtsDeviceTreeEarlyMountTest עם שני המקורות dt_early_mount_test, תגי הבדיקה הם הקידומות _32bit:: ו-_64bit:: ב-binary-test-source. תגים שמסתיימים ב-32bit או ב-64bit מסמנים באופן אוטומטי את הבדיקות כזמינות ל-ABI של ביט אחד. כלומר, בדיקות עם התג _32bit לא מתבצעות ב-ABI של 64 ביט. אי ציון תג שווה לשימוש בתג עם מחרוזת ריקה.

אפשרויות עם אותם תגים מקובצות ומבודדות מתגים אחרים. לדוגמה, binary-test-args עם התג _32bit מוחל רק על binary-test-source עם אותו תג ומופעל ב-binary-test-working-directory עם אותו תג. האפשרות binary-test-working-directory היא אופציונלית לבדיקות בינאריות, ומאפשרת לציין ספריית עבודה אחת לתג. אם לא מציינים אפשרות binary-test-working-directory, המערכת משתמשת בספריות ברירת המחדל לכל תג.

שם התג מצורף ישירות לשם של מקרה הבדיקה בדוח התוצאות. לדוגמה, תרחיש הבדיקה testcase1 עם התג _32bit יופיע בתור testcase1_32bit בדוח התוצאות.

שילוב בדיקות בצד היעד ללא תבנית BinaryTest

ב-VTS, פורמט ברירת המחדל של הבדיקה הוא בדיקות Python בצד המארח שמתרחבות מ-BaseTest ב-VTS runner. כדי לשלב בדיקות בצד היעד, קודם צריך לדחוף את קובצי הבדיקה למכשיר, להריץ את הבדיקות באמצעות פקודות מעטפת ולאחר מכן לנתח את התוצאות באמצעות סקריפטים של Python בצד המארח.

דחיפת קובצי בינארי לבדיקה

מומלץ לדחוף קבצים באמצעות הכלי VtsFilePusher target preparer. דוגמה:

<target_preparer class="com.android.compatibility.common.tradefed.targetprep.VtsFilePusher">
        <option name="push" value="DATA/test->/data/local/tmp/test"/>
    </target_preparer>

הפונקציה VtsFilePusher מבצעת את הפעולות הבאות:

  1. בדיקת קישוריות המכשיר.
  2. קובע את הנתיב המוחלט של קובץ המקור.
  3. דחיפת הקבצים באמצעות הפקודה adb push.
  4. המחיקה של הקבצים מתבצעת בסיום הבדיקות.

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

הרצת בדיקות

אחרי שדוחפים את הקבצים למכשיר, מריצים את הבדיקה באמצעות פקודות מעטפת בסקריפט בדיקה של Python בצד המארח. דוגמה:

device = self.android_devices[0]
res = device.shell.Execute(["chmod a+x /data/local/tmp/test", "/data/local/tmp/test"])
asserts.AssertFalse(any(res[return_codes]))

תבנית GtestBinaryTest

התבנית GtestBinaryTest מארחת קובצי בינאריים של בדיקות GTest, שבדרך כלל כל אחד מהם מכיל כמה מקרי בדיקה. התבנית הזו מרחיבה את התבנית BinaryTest על ידי שינוי של שיטות ההגדרה, יצירת מקרה הבדיקה ופירוק התוצאות, כך שכל ההגדרות של BinaryTest עוברות בירושה.

GtestBinaryTest מוסיף את האפשרות gtest-batch-mode:

שם האפשרות סוג הערך תיאור
binary-test-type מחרוזת סוג התבנית. נעשה שימוש בערך gtest.
gtest-batch-mode בוליאני הפעלת קובצי בינאריים של Gtest במצב באצווה. דוגמה: true

באופן כללי, הגדרת gtest-batch-mode ל-true מובילה לשיפור הביצועים תוך פגיעה קלה באמינות. בבדיקות התאימות של VTS, במודולים רבים נעשה שימוש במצב באצווה כדי לשפר את הביצועים. עם זאת, מטעמי אמינות, אם לא מציינים את המצב, ברירת המחדל היא 'לא באצווה'.

מצב ללא אצווה

במצב שאינו באצווה, מתבצעות קריאות נפרדות ל-GTest binary לכל מקרה בדיקה. לדוגמה, אם קובץ הבינארי של GTest מכיל 10 תרחישי בדיקה (אחרי סינון לפי הגדרה בצד המארח), קובץ הבינארי ייכלל 10 פעמים במעטפת המכשיר, בכל פעם עם מסנן בדיקה שונה. לכל תרחיש בדיקה, המערכת יוצרת פלט XML ייחודי של תוצאת GTest ומנתחת אותו באמצעות התבנית.

איור 2. מצב שאינו באצווה.

היתרונות של שימוש במצב שאינו באצווה כוללים:

  • בידוד של תרחישי בדיקה. קריסה או תקיעה בתרגיל בדיקה אחד לא משפיעים על תרחישי בדיקה אחרים.
  • רמת פירוט. קל יותר לקבל מדידה של פרופיל או כיסוי לכל מקרה בדיקה, systrace,‏ bugreport,‏ logcat וכו'. תוצאות הבדיקה והיומנים מאוחזרים מיד אחרי שכל מקרה בדיקה מסתיים.

החסרונות של שימוש במצב שאינו באצווה כוללים:

  • טעינה יתירה. בכל פעם שמפעילים את קובץ הבינארי של GTest, הוא טוען ספריות קשורות ומבצע הגדרות ראשוניות של הכיתות.
  • העלויות הנלוות לתקשורת. בסיום הבדיקה, המארח והמכשיר היעד מתקשרים כדי לנתח את התוצאות ולקבל את הפקודות הבאות (אפשר לבצע אופטימיזציות עתידיות).

מצב באצ'ט

במצב באצווה של GTest, קובץ ה-binary של הבדיקה נקרא רק פעם אחת עם ערך מסנן ארוך של בדיקה שמכיל את כל תרחישי הבדיקה שסוננו לפי תצורה בצד המארח (כך נמנעת בעיית הטעינה העודפת במצב שאינו באצווה). אפשר לנתח את תוצאות הבדיקה של GTest באמצעות output.xml או באמצעות פלט מסוף.

כשמשתמשים בקובץ output.xml (ברירת המחדל):

איור 3. מצב באצווה, output.xml.

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

כשמשתמשים בפלט של מסוף:

איור 4. מצב באצ', פלט טרמינל.

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

היתרונות של שימוש במצב באצווה כוללים:

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

החסרונות של שימוש במצב באצווה כוללים:

  • עלות התחזוקה. אם הפורמט של הרישום ביומן של GTest ישתנה, כל הבדיקות יקרסו.
  • בלבול. מקרה בדיקה יכול להדפיס משהו שדומה לפורמט ההתקדמות של GTest, וזה עלול לבלבל את הפורמט.

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

תבנית HostBinaryTest

התבנית HostBinaryTest כוללת קובצי הפעלה בצד המארח שלא קיימים בספריות אחרות או בסקריפטים של Python. הבדיקות האלה כוללות:

  • קובצי הפעלה של תוכנות בדיקה בינאריות שנוצרו על ידי הידור במארח
  • סקריפטים שניתן להריץ במעטפת, ב-Python או בשפות אחרות

דוגמה אחת היא בדיקה של מדיניות SELinux של VTS Security בצד המארח:

<configuration description="Config for VTS  Security SELinux policy host-side test cases">
    ...
    <test class="com.android.tradefed.testtype.VtsMultiDeviceTest">
        <option name="test-module-name" value="VtsSecuritySelinuxPolicyHost"/>
        <option name="binary-test-source" value="out/host/linux-x86/bin/VtsSecuritySelinuxPolicyHostTest" />
        <option name="binary-test-type" value="host_binary_test"/>
    </test>
</configuration>

HostBinaryTest לא מרחיב את התבנית BinaryTest, אבל הוא משתמש בתצורות בדיקה דומות. בדוגמה שלמעלה, האפשרות binary-test-source מציינת נתיב יחסי בצד המארח לקובץ ההפעלה של הבדיקה, ו-binary-test-type הוא host_binary_test. בדומה לתבנית BinaryTest, שם הקובץ הבינארי משמש כברירת מחדל בתור שם של תרחיש הבדיקה.

הרחבת תבניות קיימות

אפשר להשתמש בתבניות ישירות בהגדרת הבדיקה כדי לכלול בדיקות שאינן ב-Python, או להרחיב אותן בסוגי משנה כדי לטפל בדרישות בדיקה ספציפיות. התבניות במאגר VTS כוללות את התוספים הבאים:

איור 5. הרחבת תבניות קיימות במאגר של VTS

מפתחים מוזמנים להרחיב כל תבנית קיימת לדרישות בדיקה ספציפיות. בין הסיבות הנפוצות להרחבת תבניות:

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

כדי שיהיה קל יותר להרחיב תבניות קיימות, התבניות מכילות שיטות שמתמקדות בכל פונקציונליות. אם יש לכם עיצובים משופרים של תבניות קיימות, מומלץ לתרום ל-VTS Base Code.