Trade Federation (Tradefed או TF בקיצור) היא מסגרת בדיקה רציפה שמיועדת להרצת בדיקות במכשירי Android. לדוגמה, Tradefed משמש להרצה של חבילה לבדיקות תאימות (CTS) ושל חבילה לבדיקות של ספקים (VTS).
Trade Federation היא אפליקציית Java שפועלת במחשב מארח, ומבצעת תקשורת עם מכשיר Android אחד או יותר באמצעות ddmlib (הספרייה שמאחורי DDMS) דרך adb.
ריכזנו כאן כמה מהתכונות העיקריות של TF, יחד עם כמה תרחישים לדוגמה. עם זאת, אם אתם רוצים להתחיל מיד, תוכלו לעבור ישירות לדף כאן מתחילים.
תכונות
- עיצוב מודולרי, גמיש וניתן להתאמה
- יש תמיכה מובנית בהרצה של סוגים רבים ושונים של בדיקות Android: כלי למדידת ביצועים, uiautomator, gtest מקומי, JUnit מבוסס-מארח וכו'
- מספק מנגנונים של אמינות ושחזור בנוסף ל-adb
- תמיכה בתזמון ובהרצה של בדיקות במספר מכשירים במקביל
במאמר בדיקות באמצעות TF תוכלו למצוא את המידע העדכני ביותר על הפעלת הבדיקות הקיימות, כמו הטמעת מודולים.
תרחישים לדוגמה
המודולריות של Trade Federation מאפשרת להשתלב בקלות בסביבות עם תשתית קיימת ל-build, לבדיקה ולדיווח. בהמשך מפורטות כמה דוגמאות לשימוש שבו Tradefed יכול לאפשר שיטות בדיקה יעילות וניתנות להתאמה.
קודם כול, כדאי לבחון את מגוון התרחישים האפשריים לשימוש במונחים של השאלה "אילו חלקים ניתנים לשינוי ואילו חלקים סטטיים?" לדוגמה, יצרן ציוד מקורי של מכשיר יכול לשנות את המסגרת, המערכת והחומרה, אבל יש לו השפעה מועטה או אפסית על אפליקציות קיימות. לעומת זאת, למפתח אפליקציות יש אפשרות לשנות את האפליקציה, אבל יש לו שליטה מועטה ברוב ההיבטים של המערכת או המסגרת.
כתוצאה מכך, לכל ישות בכל תרחיש לדוגמה יהיו מטרות בדיקה שונות, ויהיו לה אפשרויות שונות במקרה של קבוצת כישלונות בבדיקות. למרות ההבדלים האלה, Trade Federation יכולה לעזור להם לשפר את כל תהליכי הבדיקה שלהם כך שיהיו יעילים, גמישים וניתנים להתאמה.
יצרן הציוד המקורי של המכשיר
יצרן ציוד מקורי של מכשיר מפתח חומרה, ולרוב מבצע שינויים במערכת ובמסגרות של Android כדי שהן יפעלו בצורה טובה בחומרה הזו. יצרן הציוד המקורי עשוי לנסות להשיג את היעדים האלה תוך שמירה על יציבות וביצועים ברמת החומרה והמערכת, ולוודא ששינויי המסגרת לא משבשים את התאימות לאפליקציות קיימות.
יצרן הציוד המקורי יכול להטמיע מודול להצגת נתונים במכשיר שיופעל בשלב 'הגדרת היעד' של מחזור החיים. למודול הזה תהיה שליטה מלאה במכשיר במהלך תקופת הביצוע שלו, מה שיאפשר לו לאלץ את המכשיר להיכנס לתוכנת האתחול, לבצע פלאש ואז לאלץ את המכשיר להפעיל מחדש למצב מרחב המשתמש. בשילוב עם מודול שמקושר למערכת build רציפה, הפתרון הזה יאפשר ליצרני ציוד מקורי להריץ בדיקות במכשיר שלהם בזמן שהם מבצעים שינויים בקושחה ברמת המערכת ובמסגרות ברמת Java.
אחרי שהמכשיר יופעל במלואו, יצרני הציוד המקורי יוכלו להשתמש בבדיקות קיימות שמבוססות על JUnit, או לכתוב בדיקות חדשות, כדי לאמת את הפונקציונליות הרצויה. לבסוף, הם יכולים לכתוב מודול אחד או יותר לדיווח על תוצאות כדי לקשר למאגרים קיימים של תוצאות בדיקות, או כדי לדווח על התוצאות ישירות (לדוגמה, באימייל).
מפתח אפליקציות
מפתח אפליקציות יוצר אפליקציה שצריכה לפעול בצורה תקינה במגוון גרסאות של פלטפורמות ובמגוון מכשירים. אם תיתקלו בבעיה בגרסה מסוימת של פלטפורמה או במכשיר מסוים, הפתרון היחיד הוא להוסיף פתרון עקיף ולהמשיך הלאה. במפתחים גדולים יותר, תהליך הבדיקה עשוי להשתלב בסדרת גרסאות build רציפה. למפתחים קטנים יותר, התהליך עשוי להתחיל מדי פעם או באופן ידני.
רוב מפתחי האפליקציות ישתמשו במודולים של התקנת בדיקות APK שכבר קיימים ב-TF. יש גרסה שמתקינה ממערכת הקבצים המקומית, וגם גרסה שאפשר להתקין בה קובצי APK שהורדתם משירות build. חשוב לציין שהגרסה האחרונה תמשיך לפעול כראוי עם מספר לא מוגבל של מכונות TF שפועלות באותה מכונה מארחת.
מכיוון ש-TF מתאים לעבודה עם מספר מכשירים, קל לסווג כל תוצאת בדיקה לפי סוג המכשיר שבו השתמשו לבדיקה הזו. לכן, TF יכול ליצור מטריצה דו-מימדית (או רב-מימדית) של תאימות לכל גרסה של האפליקציה.
שירות בדיקה
לדוגמה, שירות בדיקה עשוי לאפשר למפתחי אפליקציות לשלוח אפליקציות ולהריץ בדיקות במכשירים שמובנים בהם כלים למדידת צריכת החשמל, כדי לקבוע את צריכת החשמל של האפליקציה. המצב הזה שונה משני התרחישים הקודמים, כי הבעלים של השירות לא שולט במכשירים או באפליקציות שפועלות.
מכיוון ש-Trade Federation יכולה להריץ כל כיתה ב-Java שמטמיעה את הממשק הפשוט IRemoteTest, קל מאוד לכתוב מנהלי התקנים שיכולים לתאם בין חומרה חיצונית כלשהי לבין תרחיש הבדיקה שפועל במכשיר. הנהג עצמו יכול ליצור חוטים, לשלוח בקשות לשרתים אחרים או לבצע כל פעולה אחרת שנדרשת לו. בנוסף, הפשוטות והגמישות של ממשק הדיווח על תוצאות, ITestInvocationListener, מאפשרות לייצג בצורה פשוטה תוצאות בדיקה שרירותיות (כולל, למשל, מדדי הספק המספרי) בצינור עיבוד הנתונים הרגיל לדיווח על תוצאות.