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

  • הבדיקה צריכה להניב את אותה תוצאה אובייקטיבית באופן עקבי.
  • כדי לקבוע אם מכשיר עובר את הבדיקה או נכשל בה, צריך לבדוק אותו פעם אחת אחרי הוצאתו מהאריזה.
  • יוצרים של בדיקות חייבים להסיר את כל הגורמים האפשריים שיכולים להשפיע על תוצאות הבדיקה.
  • אם המכשיר צריך תנאי, סביבה או הגדרה מסוימים בחומרה, ההגדרה הזו חייבת להיות מוגדרת בבירור בהודעת ההתחייבות. תוכלו להיעזר בהוראות להגדרה של 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 בהסתעפות הראשית (AOSP/main). צוות Android בודק את הקוד.
  3. פרסום בדיקה: שולחים את רשימת ה-CL ב-AOSP/main ואז בוחרים בהסתעפות האחרונה ב-androidx-tests-dev. הבדיקה זמינה עכשיו לכולם.

הנחיות לכתיבת בדיקות 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, אפשר לעיין במאמר לוח הזמנים של הגרסאות ומידע על ההסתעפויות.