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

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

כיסוי הבדיקה

CTS-D, כמו CTS ו-CTS Verifier, יכול לאכוף רק את הדברים הבאים:

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

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

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

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

  • הבדיקה צריכה להניב את אותה תוצאה אובייקטיבית באופן עקבי.
  • כדי לקבוע אם מכשיר עובר את הבדיקה או נכשל בה, צריך לבדוק אותו פעם אחת אחרי פתיחת האריזה.
  • יוצרים של בדיקות חייבים להסיר את כל הגורמים האפשריים שיכולים להשפיע על תוצאות הבדיקה.
  • אם המכשיר צריך סביבה, הגדרה או תנאי חומרה מסוימים, צריך להגדיר אותם בבירור בהודעת ה-commit. הוראות להגדרה לדוגמה מפורטות במאמר הגדרת 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.
    • משתמשים ב-exclude-filters כדי להחריג את הבדיקות החדשות מתוכנית הבדיקה הראשית של CTS: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml.
  • לטפל בכל האזהרות וההצעות ב-errorprone.build_error.log
  • מבצעים ריבס של השינויים ב-head. זה כולל את תוכניות הבדיקה cts-developer.xml ו-cts-developer-exclude.xml.
  • עליכם לפנות לאיש הקשר שלכם מהנדס ב-Google כדי לבדוק אם אפשר לכלול את תרחיש הבדיקה שלכם במודול CTS קיים. אם לא, הם יעזרו לכם ליצור מודול חדש.
  • לכל מודול בדיקה חדש שיוצרים, יוצרים קובץ OWNERS בספרייה של מודול הבדיקה החדש.
    • קובץ ה-OWNERS צריך להכיל את הפרטים הבאים, שצריך לקבל מבעל הבדיקה ב-Google שאיתו אתם עובדים:
    • # Bug component: xxx
    • Google test owner ldap
  • ב-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, קראו את המאמר לוח זמנים להשקות ומידע על ההסתעפויות.