כתוב רץ מבחן של Tradefed

עמוד זה מתאר כיצד לכתוב רץ מבחן חדש ב-Tradefed.

רקע כללי

אם אתה סקרן לגבי מקומם של רצי המבחן בארכיטקטורת Tradefed, ראה מבנה של רץ מבחן .

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

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

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

שיטה זו היא זו המופעלת על ידי הרתמה בעת שימוש במבחן הרץ, בדומה ל-Java Runnable.

כל חלק בשיטה זו נחשב לחלק מביצוע רץ המבחן.

דווח על תוצאות מהרץ המבחן

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

על ידי דיווח על תוצאות מובנות, לרץ מבחן יש את המאפיינים הבאים:

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

עם זאת, דיווח על תוצאות מובנות הוא אופציונלי; רץ מבחן עשוי פשוט לרצות להעריך את מצב הריצה כולה כ- PASSED או FAILED ללא כל פרטים על הביצוע בפועל.

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

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

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

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

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

דיווח יומני מהרץ המבחן

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

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

בדוק עם מכשיר

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

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

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

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

בדוק עם מספר מכשירים

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

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

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

מבחנים מודעים להגדרות שלהם

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

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

עבור יישום רץ המבחן, תצטרך ליישם את IConfigurationReceiver כדי לקבל את האובייקט IConfiguration .

רץ מבחן גמיש

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

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

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

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