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