קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
Compatibility Test Suite (CTS) הוא חבילה של כלים ובדיקות בחינם ברמה מסחרית, שמשמשת כדי לוודא שהמכשירים שלכם תואמים ל-Android. CTS מיועד לשילוב בתהליך העבודה היומי, למשל באמצעות מערכת build רציפה. CTS פועל במחשב ומריץ בדיקות ישירות במכשירים מחוברים או באמולטור. סקירה כללית על תאימות ל-Android זמינה במאמר סקירה כללית על תוכנית התאימות של Android.
איור 1. בדיקות אוטומטיות של CTS.
באיור 1 מוצג התהליך של ביצוע הבדיקות האוטומטיות של CTS:
מורידים ומתקינים את CTS. השלב הזה כולל גם הגדרה של סביבת הבדיקה, תחנת העבודה לבדיקה והמכשיר שאתם בודקים, או המכשיר הנבדק (DUT).
הפעלת בדיקות אוטומטיות של CTS.
שומרים את התוצאות ובודקים אותן.
פותרים בעיות ומריצים מחדש את הבדיקות.
כדאי להשתמש ב-CTS כדי לזהות אי-תאימות בשלב מוקדם, וכדי לוודא שההטמעות של Android יישארו תואמות לאורך כל תהליך הפיתוח.
רכיבי CTS
CTS מכיל את הרכיבים העיקריים הבאים:
Trade Federation
ה-framework והאוסף של ערכות הבדיקה מאפשרים לבצע בדיקות באופן אוטומטי.
בדיקות אוטומטיות של CTS
בדיקות שמשתמשות במסגרת של Trade Federation ואפשר להריץ אותן באמצעות ערכת הבדיקות של Trade Federation.
בדיקות של CTS Verifier (CTS-V)
בדיקות שצריך להריץ באופן ידני.
אפליקציית CTS Verifier (CTS-V)
אפליקציה שמשמשת לביצוע בדיקות CTS-V ולאיסוף תוצאות בדיקות CTS-V.
תרחיש בדיקה
בדיקה ספציפית שמתבצעת ב-DUT. תרחישי הבדיקה האוטומטיים נכתבים ב-Java כבדיקות JUnit ומארזים בקובצי APK של Android כדי להריץ אותם במכשיר היעד.
מקרי בדיקה יכולים להיות בדיקות יחידה או בדיקות פונקציונליות. בבדיקה יחידה נבדקות יחידות קוד אטומיות בפלטפורמת Android. לדוגמה, בדיקת יחידה עשויה לבדוק כיתה אחת של Android.
בבדיקה פונקציונלית מתבצעת בדיקה של שילוב של שיטות וכיתות שמשמשות לתרחיש לדוגמה ספציפי.
הגדרת הבדיקה
קבוצה ספציפית של בדיקות אוטומטיות שפועלות ב-DUT. הגדרות הבדיקה הן קובצי XML שנמצאים בתיקייה WORKING_DIRECTORY/cts/tools/cts-tradefed/res/config.
יש הגדרות בדיקה שמכילות את כל תרחישי הבדיקה האוטומטיים, והגדרות בדיקה שמכילות קבוצת משנה של תרחישי בדיקה.
מודול בדיקה
הגדרת בדיקה שמכילה אוסף של תרחישי בדיקה לאותו תחום תכונות.
תוכנית בדיקה
הגדרת בדיקה שמכילה אוסף של מודולי בדיקה.
כיסוי הבדיקה
כדי לוודא תאימות, תרחישים הבדיקה כוללים את התחומים הבאים:
אזור
תיאור
בדיקות חתימות
לכל גרסה של Android יש קובצי XML שמתארים את החתימות של כל ממשקי ה-API הציבוריים שמכילה הגרסה. ה-CTS מכיל כלי לבדיקה של חתימות ה-API האלה מול ממשקי ה-API שזמינים במכשיר. התוצאות של בדיקת החתימה מתועדות בקובץ ה-XML של תוצאות הבדיקה.
בדיקות של Platform API
בודקים את ממשקי ה-API של הפלטפורמה (ספריות הליבה ו-Android Application Framework) כפי שמתואר בClass Index של ה-SDK, כדי לוודא שהם תקינים, כולל חתימות נכונות של שיטות, מאפיינים וכיתות, התנהגות נכונה של שיטות ובדיקות של תוצאות שליליות כדי לוודא התנהגות צפויה במקרה של טיפול שגוי בפרמטרים.
בדיקות Dalvik
הבדיקות מתמקדות בפורמט ההפעלה של Dalvik.
מודל נתונים של פלטפורמה
ב-CTS נבדק מודל הנתונים של הליבה של הפלטפורמה כפי שהוא מוצג למפתחי האפליקציות דרך ספקי התוכן, כפי שמתואר בחבילת ה-SDK android.provider (כולל אנשי קשר, דפדפנים והגדרות)
כוונות לרכישה בפלטפורמה
ב-CTS נבדקות כוונות הליבה של הפלטפורמה, כפי שמתואר במסמך
Common intents ב-SDK.
הרשאות פלטפורמה
ב-CTS נבדקות ההרשאות של הפלטפורמה המרכזית, כפי שמפורט ב-SDK Manifest.permission.
משאבי פלטפורמה
ב-CTS נבדק הטיפול הנכון בסוגים של משאבי הליבה בפלטפורמה, כפי שמתואר ב
סקירה הכללית על סוגי המשאבים ב-SDK. בדיקות CTS כוללות בדיקות של ערכים פשוטים, רכיבי drawable, תצוגות nine-patch, אנימציות, פריסות, סגנונות ועיצובים, וטעינה של משאבים חלופיים.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. Java ו-OpenJDK הם סימנים מסחריים או סימנים מסחריים רשומים של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-07-27 (שעון UTC).
[[["התוכן קל להבנה","easyToUnderstand","thumb-up"],["התוכן עזר לי לפתור בעיה","solvedMyProblem","thumb-up"],["סיבה אחרת","otherUp","thumb-up"]],[["חסרים לי מידע או פרטים","missingTheInformationINeed","thumb-down"],["התוכן מורכב מדי או עם יותר מדי שלבים","tooComplicatedTooManySteps","thumb-down"],["התוכן לא עדכני","outOfDate","thumb-down"],["בעיה בתרגום","translationIssue","thumb-down"],["בעיה בדוגמאות/בקוד","samplesCodeIssue","thumb-down"],["סיבה אחרת","otherDown","thumb-down"]],["עדכון אחרון: 2025-07-27 (שעון UTC)."],[],[],null,["# The Compatibility Test Suite (CTS) overview\n\n*Compatibility Test Suite (CTS)* is a free, commercial-grade test suite and\ntools used to help ensure that your devices are Android compatible. CTS is\nintended to be integrated into your daily workflow, such as through a\ncontinuous build system. CTS runs on a desktop machine and executes tests\ndirectly on attached devices or on an emulator. For an overview of Android compatibility, see [Android compatibility program overview](/docs/compatibility).\n\n**Figure 1.** CTS automated testing.\n\nFigure 1 shows the process of executing CTS automated tests:\n\n1. Download and install CTS. This step also involves setting up the test environment, the testing workstation, and the device you are testing or *device under test (DUT)*\n2. Run CTS automated tests.\n3. Store and review the results.\n4. Troubleshoot issues and rerun tests.\n\nUse CTS to reveal incompatibilities early, and to ensure that your Android\nimplementations remain compatible throughout the development process.\n\nCTS components\n--------------\n\nCTS contains the following major components:\n\n*Trade Federation*\n: A test harness and framework allow for the automated execution of tests.\n\n*CTS automated tests*\n: Tests that use the Trade Federation framework and can be run using the Trade\n Federation test harness.\n\n*CTS Verifier (CTS-V) tests*\n: Tests that must be run manually.\n\n*CTS Verifier (CTS-V) app*\n: An app used to conduct CTS-V tests and collect CTS-V test results.\n\n*Test case*\n\n: An individual test executed on the DUT. Automated test cases are\n written in Java as JUnit tests and packaged Android APK files to run on the\n device target.\n\n Test cases can be *unit tests* or *functional tests*. A unit test tests atomic\n units of code within the Android platform. For example, a unit test might test\n a single Android class.\n\n A functional test exercises a combination of methods and classes used for a\n specific use case.\n\n*Test configuration*\n\n: A specific set of automated tests that are run on the\n DUT. Test configurations are XML files located in\n \u003cvar translate=\"no\"\u003eWORKING_DIRECTORY\u003c/var\u003e`/cts/tools/cts-tradefed/res/config`.\n There are test configurations that contains all automated test cases and test\n configurations that contain a subset of test cases.\n\n*Test module*\n\n: A test configuration consisting of a collection of test cases for the same\n feature area.\n\n*Test plan*\n\n: A test configuration consisting of a collection of test modules.\n\n| **Note:** The Android Open Source Project accepts contributions to improve CTS just as for any other component. Improving the coverage and quality of CTS tests is one of the best ways to contribute to Android. To make contributions to CTS, follow the same process in [Submit code changes](/docs/setup/contribute/submit-patches).\n\nTest coverage\n-------------\n\nTest cases cover the following areas to ensure compatibility:\n\n| Area | Description |\n|----------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Signature tests | For each Android release, there are XML files describing the signatures of all public APIs contained in the release. The CTS contains a utility to check those API signatures against the APIs available on the device. The results from signature checking are recorded in the test result XML file. |\n| Platform API tests | Test the platform (core libraries and Android Application Framework) APIs as documented in the SDK [Class Index](https://developer.android.com/reference/classes) to ensure API correctness, including correct class, attribute and method signatures, correct method behavior, and negative tests to ensure expected behavior for incorrect parameter handling. |\n| Dalvik tests | The tests focus on testing the Dalvik executable format. |\n| Platform data model | The CTS tests the core platform data model as exposed to application developers through content providers, as documented in the SDK [`android.provider`](https://developer.android.com/reference/android/provider/package-summary) package (including contacts, browsers, and settings) |\n| Platform intents | The CTS tests the core platform intents, as documented in the SDK [Common intents](https://developer.android.com/guide/appendix/g-app-intents). |\n| Platform permissions | The CTS tests the core platform permissions, as documented in the SDK [`Manifest.permission`](https://developer.android.com/reference/android/Manifest.permission). |\n| Platform resources | The CTS tests for correct handling of the core platform resource types, as documented in the SDK [Resource types overview](https://developer.android.com/guide/topics/resources/available-resources). The CTS tests include tests for simple values, drawables, nine-patch, animations, layouts, styles and themes, and loading alternate resources. |\n\nWhat's next\n-----------\n\nAfter reading this document, continue to [Set up CTS](/docs/compatibility/cts/setup)."]]
