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.
  • הבדיקה לא יכולה להימשך יותר מ-6 שעות בכל פעם. אם הוא צריך לפעול במשך ארוכה יותר, עליך לכלול את הנימוקים בהצעה לבדיקה כדי שנוכל לבדוק אותה.

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

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

דרישות הסף לבדיקה

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

תהליך הגשת CTS

  1. כתיבת הצעה לבדיקה: מפתח אפליקציה שולח הצעה לבדיקה באמצעות למעקב אחר בעיות ב-Google שמתארת את הבעיה שזוהתה ומציעה בדיקה לבדיקה במיוחד בשבילך. ההצעה חייבת לכלול את מזהה הדרישה של 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
    • 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.