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

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

היקף הבדיקה

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

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

דרישות שהן לא MUST, כמו STRONGLY RECOMMENDED, ‏ SHOULD, ‏ MAY, הן אופציונליות ואי אפשר לבדוק אותן באמצעות CTS.

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

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

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

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

  • ה-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‏ (android17-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.
  • טיפול בכל האזהרות וההצעות ב-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 זמינים במאמר לוח זמנים של הפצה ופרטים על הסניף.