תבניות בדיקה

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

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

תבנית BinaryTest

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

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

ניתן לשלב בדיקות אלו ב-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 תומכת באפשרויות התצורה הבאות:

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

תגיות בדיקה

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

כפי שמוצג בדוגמה של VtsDeviceTreeEarlyMountTest עם שני מקורות dt_early_mount_test , תגי הבדיקה הם הקידומות _32bit:: ו _64bit:: binary-test-source . תגים המסתיימים ב 32bit או 64bit מסמנים אוטומטית את הבדיקות כזמינות ל-ABI bitness אחת; כלומר, בדיקות עם התג _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 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 :

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

מצב לא אצווה

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

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

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

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

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

מצב אצווה

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

בעת שימוש ב-output.xml (ברירת מחדל):

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

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

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

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

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

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

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

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

תבנית HostBinaryTest

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

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

דוגמה אחת היא מבחן מדיניות ה-VTS Security 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 repo יש את ההרחבות הבאות:

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

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

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