בדיקת תבניות

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

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

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

תבנית BinaryTest

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

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

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

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

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

<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 תומכת באפשרויות ההגדרה הבאות:

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

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

תגי בדיקה

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

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

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

אנחנו ממליצים להעביר קבצים באמצעות כלי ההכנה ליעד VtsFilePusher. דוגמה:

<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:

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

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

מצב לא באצווה

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

איור 2. ללא מצב אצווה.

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

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

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

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

מצב אצווה

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

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

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

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

כשמשתמשים בפלט מטרמינל:

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

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

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

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

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

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

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

תבנית HostBinaryTest

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

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

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

<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.