קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
בהמשך מפורטות כמה צורות אוטומציה אופייניות שאפשר להשתמש בהן במערכת ה-CI.
משימות בסיסיות
יצירת גרסה (build): כשיוצרים פרויקט מאפס, מוודאים שהשינויים החדשים עוברים הידור בצורה תקינה ושכל הספריות והכלים תואמים זה לזה.
בדיקות איתור שגיאות או בדיקות סגנון: השלב הזה הוא אופציונלי, אבל מומלץ. כשאתם אוכפים כללי סגנון ומבצעים ניתוח סטטי, ביקורות הקוד יכולות להיות תמציתיות וממוקדות יותר.
בדיקות מקומיות או בצד המארח: הן פועלות במחשב המקומי שבו מתבצע ה-build. ב-Android, בדרך כלל מדובר ב-JVM, כך שהן מהירות ואמינות. הן כוללות גם בדיקות Robolectric.
יש כמה אפשרויות להרצת בדיקות עם מכשירי מדידה ב-CI:
אפשר להשתמש ב-Gradle Managed Devices כדי להגדיר את המכשירים שבהם רוצים להשתמש (לדוגמה, "Pixel 2 emulator on API 27"), והוא מטפל בהקצאת המכשירים.
רוב מערכות ה-CI מגיעות עם פלאגין של צד שלישי (שנקרא גם 'פעולה', 'שילוב' או 'שלב') לטיפול במהדמנים של Android.
להקצות בדיקות עם מכשירי מעקב לחוות מכשירי בדיקה, כמו Firebase Test Lab.
חוות מכשירי הבדיקה נחשבות לאמינות מאוד, והן יכולות לפעול במהדמנים או במכשירים פיזיים.
בדיקות רגרסיה של ביצועים
כדי לעקוב אחרי ביצועי האפליקציה, מומלץ להשתמש בספריות למדדי ביצועים.
כדי לבצע אוטומציה של בדיקות הביצועים במהלך הפיתוח, נדרשים מכשירים פיזיים כדי להבטיח תוצאות בדיקה עקביות וריאליסטיות.
הפעלת מדדי ביצועים יכולה להימשך זמן רב, במיוחד כשיש כיסוי נרחב של הקוד ותהליכי השימוש שאתם בודקים. במקום להריץ את כל אבני הבקרה לכל תכונה או השמה (commit) ששולבו, כדאי להריץ אותן כחלק מתהליך build לתחזוקה מתוזמן באופן קבוע, כמו build לילה.
מעקב אחר הביצועים
אתם יכולים לעקוב אחר רגרסיות בביצועים באמצעות התאמה לפי שלבים. התאמה לפי שלבים מגדירה חלון נע של תוצאות גרסאות build קודמות, שמשווים אליהן את הגרסה הנוכחית. הגישה הזו משלבת כמה תוצאות של מדדי ביצועים למדד אחד ספציפי לרגרסיה. אפשר להחיל התאמה של שלבים כדי לצמצם את הרעש במהלך בדיקת רגרסיה.
כך ניתן לצמצם את מספר הזיהויים השגויים של תוצאות חיוביות, שיכולים להתרחש כשזמני הסימון נמוכים בגרסה אחת של build ואז חוזרים לזמנים רגילים.
בדיקות רגרסיה של כיסוי הבדיקה
כיסוי הבדיקה הוא מדד שיכול לעזור לכם ולצוות שלכם להחליט אם הבדיקות מכסות שינוי בצורה מספקת. עם זאת, הוא לא צריך להיות האינדיקטור היחיד. נהוג להגדיר בדיקת רגרסיה שתיכשל או תציג אזהרה כשהיקף הכיסוי קטן יותר בהשוואה להסתעפות הבסיסית.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. 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,["# Types of CI automation\n\nThe following are some typical forms of automation that you might like to use in\nyour CI system.\n\nBasic jobs\n----------\n\n- **Build:** By building a project from scratch, you make sure that the new\n changes compile correctly and that all libraries and tools are compatible with\n each other.\n\n- **Lint or style checks:** This is an optional but recommended step. When you\n enforce style rules and perform [static analysis](/studio/write/lint), code reviews can be more\n concise and focused.\n\n- **[Local, or host-side tests](/training/testing/local-tests):** They run on the local machine that\n performs the build. On Android this is usually the JVM, so they're fast and\n reliable. They include Robolectric tests as well.\n\nInstrumented tests\n------------------\n\n[Tests that run on emulators or physical devices](/training/testing/instrumented-tests) require some provisioning,\nwaiting for devices to boot or be connected and other operations that add\ncomplexity.\n\nThere are multiple options to run instrumented tests on CI:\n\n- [Gradle Managed Devices](/studio/test/gradle-managed-devices) can be used to define the devices to use (for example \"Pixel 2 emulator on API 27\") and it handles device provisioning.\n- Most CI systems come with a third-party plugin (also called \"action\", \"integration\" or \"step\") to handle Android emulators.\n- Delegate instrumented tests to a device farm such as [Firebase Test Lab](https://firebase.google.com/docs/test-lab). Device farms are used for their high reliability and they can run on emulators or physical devices.\n\nPerformance regression tests\n----------------------------\n\nTo monitor app performance we recommend using the [benchmark libraries](/topic/performance/benchmarking/benchmarking-overview).\nAutomation of performance tests during development requires physical devices to\nensure consistent and realistic test results.\n\nRunning benchmarks can take a long time, especially when you have high coverage\nof code and user journeys that you are benchmarking. Instead of running all\nbenchmarks for every merged feature or commit, consider executing them as part\nof a regularly scheduled maintenance build, such as a nightly build.\n\n### Monitoring performance\n\nYou can monitor performance regressions using [step fitting](https://medium.com/androiddevelopers/fighting-regressions-with-benchmarks-in-ci-6ea9a14b5c71). Step\nfitting defines a rolling window of previous build results which you compare\nagainst the current build. This approach combines several benchmark results into\none regression-specific metric. You can apply step fitting to reduce noise\nduring regression testing.\n\nThis reduces the occurrence of false positives which can occur when benchmark\ntimes are slow for a single build and then normalize again.\n\nTest coverage regression checks\n-------------------------------\n\n[Test coverage](/studio/test/test-in-android-studio#view_test_coverage) is a metric that can help you and your team decide if tests\nsufficiently cover a change. However, it shouldn't be the only indicator. It is\ncommon practice to set up a regression check that fails or shows a warning when\nthe coverage goes down relative to the base branch.\n| **Note:** The coverage generated by an instrumentation test is different from that of a unit test as bigger tests typically make fewer assertions per line of tested code and their goal is different. Consider keeping two separate coverage metrics."]]
