כתיבה של מפעיל בדיקות ב-Tradefed

קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

בדף הזה נסביר איך לכתוב רכיב חדש של הרצת בדיקה ב-Trendified.

רקע

במאמר המבנה של מפעיל בדיקות מוסבר מהי המקום של מפעילי הבדיקות בארכיטקטורה של Tradefed.

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

מינימום מינימלי: הטמעת הממשק

הדרישה המינימלית כדי לעמוד בדרישות לכלי להרצת בדיקות ב-Tradefed היא להטמיע את ממשק IRemoteTest, ובאופן ספציפי יותר את השיטה run(TestInformation testInfo, ITestInvocationListener listener).

זוהי השיטה שמופעלת על ידי הרתמה כשמשתמשים בהרצת הבדיקה, בדומה ל-Java Runnable.

כל חלק מהשיטה הזו נחשב לחלק מההפעלה של מפעיל הבדיקות.

דיווח על תוצאות מכלי הבדיקה

ה-method run בממשק הבסיס נותנת גישה לאובייקט ה-listener של מקלידים ITestInvocationListener. האובייקט הזה הוא המפתח לדיווח על תוצאות מובנות מכלי הבדיקה לרתמה.

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

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

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

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

• testRunStarted: הודעה על התחלת קבוצה של תרחישי בדיקה שקשורים זה לזה.
  • testStarted: שליחת התראה על ההתחלה של מקרה בדיקה.
  • testנכשל/testignored: הודעה על שינוי המצב של מקרה הבדיקה בתהליך. תרחיש בדיקה ללא שינוי במצב נחשב כעבר בהצלחה.
  • testEnded: הודעה על סוף תרחיש הבדיקה.
• testRunFailed: הודעה על כך שהסטטוס הכולל של קבוצת בדיקות התוכנה הוא 'כישלון'. הרצת בדיקה יכולה להיות אישור או נכשל ללא תלות בתוצאות מקרי הבדיקה, בהתאם היה אמור להיות. לדוגמה, קובץ בינארי שמריץ כמה תרחישי בדיקה יכול לדווח על כל תרחישי הבדיקה שעוברים, אבל עם קוד יציאה של שגיאה (מכל סיבה שהיא: קבצים שדלפו וכו').
• testRunEnded: שליחת הודעה לסוף קבוצת מקרי הבדיקה.

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

קריאות חזרה של תרחישי בדיקה (testStarted, testEnded וכו') הן אופציונליות. יכול להיות שתתבצע הפעלת בדיקה ללא תרחישי בדיקה.

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

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

אם אתם כותבים את מחלקת הבדיקה או את ה-runner של Tradefed בעצמכם, תצטרכו להטמיע את IRemoteTest ולקבל ITestInvocationListener באמצעות השיטה run(). אפשר להשתמש במאזין הזה כדי לתעד קבצים באופן הבא:

    listener.testLog(String dataName, LogDataType type_of_data, InputStreamSource data);

בדיקה באמצעות מכשיר

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

כותבי בדיקות שירצו לעבור לשלב הבא של בדיקת מכשירים יצטרכו בממשקים הבאים:

• IDeviceTest מאפשרת לקבל את האובייקט ITestDevice שמייצג את המכשיר שנבדק, ומספקת את ה-API ליצירת אינטראקציה איתו.
• IBuildReceiver שמאפשרות לבדיקה ליצור את האובייקט IBuildInfo שלב בניית ספק שמכיל את כל המידע והפריטי מידע שנוצרו בתהליך הפיתוח (Artifact) שקשורים להגדרת הבדיקה.

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

בדיקה באמצעות מספר מכשירים

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

כדי לכתוב רכיב הרצה לבדיקה שיכול להשתמש במספר מכשירים, צריך כדי ליישם את המדיניות IMultiDeviceTest כך נוכל לקבל מפה של ITestDevice אל IBuildInfo שמכילה את הרשימה המלאה של ייצוגי מכשירים ואת המידע שקשור ל-build שלהם.

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

בדיקות מודעות להגדרות שלהן

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

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

כדי להטמיע את מפעיל הבדיקות, תצטרכו להטמיע את IConfigurationReceiver כדי לקבל את האובייקט IConfiguration.

כלי גמיש להרצת בדיקות

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

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

התמיכה בסינון מתוארת בממשק ITestFilterReceiver, שמאפשר לקבל קבוצות של מסנני include ו-exclude לבדיקות שצריך להריץ או לא צריך להריץ.

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