CTS שמופעל על ידי מפתחים

בדף הזה מפורטות הנחיות השימוש ב-CTS מבוסס-מפתחים (CTS-D).

כיסוי בדיקות

ב-CTS-D, כמו ב-CTS וב-CTS Verifier, אפשר לאכוף רק את הפעולות הבאות:

  • כל ממשקי ה-API הציבוריים שמתוארים ב-SDK למפתחים (developer.android.com) לרמת API מסוימת.
  • כל דרישות החובה שמופיעות במסמך ההגדרה של תאימות (CDD) של Android לרמת API מסוימת.

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

מכיוון שכל ממשקי ה-API והדרישות של CDD קשורים לרמת API ספציפית, כל הבדיקות של CTS (‏CTS,‏ CTS-D ו-CTS Verifier) קשורות לאותה רמת API כמו ממשקי ה-API או הדרישות המשויכים. אם מוציאים משימוש ממשק API ספציפי או משנים אותו, צריך להוציא משימוש את הבדיקה התואמת או לעדכן אותה.

כללים ליצירת בדיקות CTS

  • התוצאה של הבדיקה צריכה להיות זהה בכל פעם.
  • בבדיקה צריך לקבוע אם מכשיר עובר או נכשל, על ידי בדיקת המכשיר פעם אחת כשהוא חדש.
  • יוצרים של בדיקות צריכים להסיר את כל הגורמים האפשריים שיכולים להשפיע על תוצאות הבדיקה.
  • אם מכשיר מסוים צריך תנאי חומרה, סביבה או הגדרה מסוימים, ההגדרה הזו צריכה להיות מוגדרת בבירור בהודעת השליחה. הוראות להגדרה לדוגמה מופיעות במאמר הגדרת CTS.
  • הבדיקה לא יכולה לפעול יותר מ-6 שעות בכל פעם. אם אתם רוצים להריץ את הבדיקה למשך זמן ארוך יותר, עליכם לכלול את הנימוקים בהצעה לבדיקה כדי שנוכל לבדוק אותה.

הדוגמה הבאה מציגה קבוצה של תנאי בדיקה לבדיקת הגבלת אפליקציה:

  • רשת ה-Wi-Fi יציבה (בבדיקה שמסתמכת על Wi-Fi).
  • המכשיר נשאר נייח במהלך הבדיקה (או לא, בהתאם לבדיקה).
  • המכשיר מנותק ממקור חשמל כלשהו עם רמת טעינה של X אחוזים.
  • לא פועלות אפליקציות, שירותים שפועלים בחזית או שירותים שפועלים ברקע, למעט CTS.
  • המסך כבוי בזמן הפעלת CTS.
  • המכשיר הוא לא isLowRamDevice.
  • ההגדרות של חיסכון בסוללה או הגבלות על אפליקציות לא השתנו מהמצב שבו הן מגיעות עם המכשיר.

בדיקת הזכאות

אנחנו מקבלים בדיקות חדשות שמחייבות התנהגות שלא נבדקת על ידי בדיקות CTS,‏ CTS Verifier או CTS-D קיימות. כל בדיקה שבודקת התנהגות שלא נכללת בכיסוי הבדיקות שלנו תידחה.

תהליך השליחה של CTS

  1. כתיבת הצעה לבדיקה: מפתח אפליקציות שולח הצעה לבדיקה באמצעות Google Issue Tracker. בהצעה הוא מתאר את הבעיה שזוהתה ומציע בדיקה כדי לבדוק אותה. ההצעה צריכה לכלול את מזהה הדרישה המשויך ל-CDD. צוות Android בודק את ההצעה.
  2. פיתוח בדיקת CTS: אחרי שההצעה מאושרת, מגיש ההצעה יוצר בדיקת CTS ב-AOSP בענף הגרסה האחרונה של Android‏ (android16-release). צוות Android בודק את הקוד, ואם הוא מתקבל, הוא בוחר את השינוי וממזג אותו עם ענף הפיתוח הפנימי. פרטים נוספים זמינים במאמר בנושא איפה כדאי להציע שינויים ב-AOSP?

הנחיות לכתיבת בדיקות CTS-D

  • פועלים לפי המדריך לסגנון קוד Java.
  • פועלים לפי כל השלבים שמתוארים במאמר פיתוח CTS.
  • מוסיפים את הבדיקות לתוכנית הבדיקות המתאימה:
    • משתמשים ב-include-filters כדי להוסיף את הבדיקות החדשות לתוכנית הבדיקות של CTS-D: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml.
    • כדי להחריג את הבדיקות החדשות מתוכנית הבדיקה הראשית של CTS, משתמשים ב-exclude-filters: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml.
  • טיפול בכל האזהרות וההצעות ב-build_error.log.errorprone
  • מבצעים Rebase של השינויים ב-head. זה כולל את תוכניות הבדיקה cts-developer.xml וcts-developer-exclude.xml.
  • כדאי להיעזר באיש הקשר שלכם בצוות ההנדסה של Google כדי לקבוע אם אפשר לכלול את תרחיש הבדיקה שלכם במודול CTS קיים. אם הם לא יוכלו לעשות זאת, הם יעזרו לכם ליצור מודול חדש.
  • לכל מודול בדיקה חדש שנוצר, יוצרים קובץ OWNERS בספרייה של מודול הבדיקה החדש.
    • קובץ הבעלים צריך לכלול את הפרטים הבאים, שמתקבלים מבעלי הבדיקה ב-Google שאיתם אתם עובדים:
    • # Bug component: xxx
    • ‫LDAP של בעלי בדיקות Google
  • בפרמטר AndroidTest.xml מציינים את הפרמטרים הבאים. לדוגמה, אפשר לעיין בקבצים לדוגמה (1, 2):
    • Instant_app או not_instant_app
    • secondary_user או not_secondary_user
    • all_foldable_states או no_foldable_states
  • כדי לציין את minSDK הנכון, אפשר לעיין במסמכי התיעוד בנושא <uses-sdk>.
  • כשמבצעים צ'ק-אין של שיטות בדיקה, מחלקות או מודולים חדשים, מוסיפים אותם לתוכנית הבדיקה של CTS-D ומוציאים אותם מתוכנית הבדיקה הראשית של CTS, בדיוק כמו כשמוסיפים בדיקות חדשות.

הרצת בדיקת CTS-D

מריצים את תוכנית הבדיקה CTS-D משורת הפקודה באמצעות run cts --plan cts-developer.

כדי להריץ תרחיש בדיקה ספציפי, משתמשים ב-run cts --include-filter "test_module_name test_name".

מידע על הרצת CTS מלא זמין במאמר הרצת בדיקות CTS.

אישור ופרסום

אחרי שליחת בקשת בדיקה, צוות פנימי יבדוק אותה כדי לוודא שהיא בודקת דרישה של CDD או התנהגות מתועדת של API. אם ייקבע שהבדיקה בודקת דרישה או התנהגות תקפים, הצוות יעביר את תרחיש הבדיקה הזה למהנדס Google לבדיקה נוספת. מהנדס של Google יפנה אליך עם משוב לגבי שיפור הבדיקה לפני שניתן יהיה לקבל אותה ל-CTS.

פרטים על לוח הזמנים של הפצת CTS זמינים במאמר בנושא לוח הזמנים של הפצת CTS ומידע על הענפים.