Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Sau đây là một số hình thức tự động hoá điển hình mà bạn nên sử dụng trong hệ thống CI.
Công việc cơ bản
Bản dựng: Bằng cách xây dựng một dự án từ đầu, bạn đảm bảo rằng những thay đổi mới sẽ biên dịch chính xác, đồng thời tất cả thư viện và công cụ đều tương thích với nhau.
Kiểm tra để tìm lỗi mã nguồn hoặc kiểu: Đây là bước không bắt buộc nhưng nên thực hiện. Khi bạn thực thi các quy tắc kiểu và thực hiện phân tích tĩnh, quá trình xem xét mã có thể ngắn gọn và tập trung hơn.
Kiểm thử cục bộ hoặc kiểm thử phía máy chủ: Các kiểm thử này chạy trên máy cục bộ thực hiện quá trình tạo bản dựng. Trên Android, đây thường là JVM, vì vậy, các máy chủ này rất nhanh và đáng tin cậy. Ngoài ra, chương trình này cũng bao gồm các chương trình kiểm thử Robolectric.
Có nhiều lựa chọn để chạy kiểm thử đo lường trên CI:
Bạn có thể sử dụng Thiết bị do Gradle quản lý để xác định thiết bị cần sử dụng (ví dụ: "Trình mô phỏng Pixel 2 trên API 27") và xử lý việc cấp phép thiết bị.
Hầu hết các hệ thống CI đều đi kèm với một trình bổ trợ của bên thứ ba (còn gọi là "hành động", "tích hợp" hoặc "bước") để xử lý trình mô phỏng Android.
Ủy quyền kiểm thử đo lường cho một nhóm thiết bị, chẳng hạn như Phòng thử nghiệm Firebase.
Trang trại thiết bị được sử dụng để mang lại độ tin cậy cao và có thể chạy trên trình mô phỏng hoặc thiết bị thực.
Kiểm thử hồi quy hiệu suất
Để theo dõi hiệu suất của ứng dụng, bạn nên sử dụng thư viện điểm chuẩn.
Việc tự động kiểm thử hiệu suất trong quá trình phát triển yêu cầu các thiết bị thực tế để đảm bảo kết quả kiểm thử nhất quán và thực tế.
Việc chạy phép đo điểm chuẩn có thể mất nhiều thời gian, đặc biệt là khi bạn có mức độ phù hợp cao về mã và hành trình của người dùng mà bạn đang đo điểm chuẩn. Thay vì chạy tất cả các điểm chuẩn cho mọi tính năng hoặc lệnh xác nhận đã hợp nhất, hãy cân nhắc thực thi các điểm chuẩn đó trong quá trình bảo trì định kỳ theo lịch, chẳng hạn như bản dựng chạy vào ban đêm.
Giám sát hiệu suất
Bạn có thể theo dõi số lần hồi quy hiệu suất bằng cách sử dụng tính năng điều chỉnh bước. Tính năng điều chỉnh bước xác định một cửa sổ cuộn các kết quả bản dựng trước đó mà bạn so sánh với bản dựng hiện tại. Phương pháp này kết hợp một số kết quả đo điểm chuẩn thành một chỉ số dành riêng cho hồi quy. Bạn có thể áp dụng phương pháp điều chỉnh bước để giảm độ nhiễu trong quá trình kiểm thử hồi quy.
Điều này làm giảm trường hợp dương tính giả (FN) có thể xảy ra khi thời gian đo điểm chuẩn cho một bản dựng bị chậm, sau đó chuẩn hoá lại.
Kiểm thử hồi quy mức độ phù hợp
Phạm vi kiểm thử là một chỉ số có thể giúp bạn và nhóm của bạn quyết định xem liệu các bài kiểm thử có đủ khả năng thể hiện một thay đổi hay không. Tuy nhiên, đó không phải là chỉ báo duy nhất. Bạn nên thiết lập quy trình kiểm tra hồi quy nhưng không thành công hoặc hiển thị cảnh báo khi mức độ sử dụng giảm xuống so với nhánh cơ sở.
Nội dung và mã mẫu trên trang này phải tuân thủ các giấy phép như mô tả trong phần Giấy phép nội dung. Java và OpenJDK là nhãn hiệu hoặc nhãn hiệu đã đăng ký của Oracle và/hoặc đơn vị liên kết của Oracle.
Cập nhật lần gần đây nhất: 2025-07-27 UTC.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 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."]]