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.
Nội dung bạn nên kiểm thử phụ thuộc vào các yếu tố như loại ứng dụng, nhóm phát triển, số lượng mã cũ và cấu trúc được sử dụng. Các phần sau đây trình bày những điều mà người mới bắt đầu nên cân nhắc khi lên kế hoạch kiểm thử trong ứng dụng.
Sắp xếp thư mục kiểm thử
Một dự án điển hình trong Android Studio có 2 thư mục lưu giữ các chương trình kiểm thử tuỳ thuộc vào môi trường thực thi. Sắp xếp chương trình kiểm thử theo các thư mục sau như mô tả:
Thư mục androidTest phải chứa các bài kiểm thử chạy trên thiết bị thực hoặc thiết bị ảo. Các chương trình kiểm thử như vậy bao gồm kiểm thử tích hợp, kiểm thử toàn diện và các kiểm thử khác mà chỉ riêng JVM không thể xác thực chức năng của ứng dụng.
Thư mục test phải chứa các chương trình kiểm thử chạy trên máy cục bộ của bạn, chẳng hạn như kiểm thử đơn vị. Khác với những điều nêu trên, đây có thể là các phép kiểm thử chạy trên một JVM cục bộ.
Kiểm thử đơn vị thiết yếu
Khi làm theo phương pháp hay nhất, bạn nên đảm bảo sử dụng kiểm thử đơn vị trong các trường hợp sau:
Kiểm thử đơn vị cho ViewModels hoặc người trình bày.
Kiểm thử đơn vị cho lớp dữ liệu, đặc biệt là kho lưu trữ. Hầu hết lớp dữ liệu phải độc lập với nền tảng. Làm như vậy cho phép kiểm thử kép để thay thế mô-đun cơ sở dữ liệu và nguồn dữ liệu từ xa trong kiểm thử. Xem hướng dẫn về cách sử dụng kỹ thuật nhân đôi kiểm thử trong Android
Kiểm thử đơn vị cho các lớp không phụ thuộc vào nền tảng khác, chẳng hạn như lớp Miền, như với các trường hợp sử dụng và trình tương tác.
Kiểm thử đơn vị cho các lớp tiện ích, chẳng hạn như thao tác trên chuỗi và toán học.
Kiểm thử các trường hợp hiếm gặp
Kiểm thử đơn vị nên tập trung vào cả trường hợp thông thường và trường hợp hiếm gặp. Trường hợp hiếm gặp là các trường hợp không phổ biến mà người kiểm thử và các bài kiểm thử lớn hơn khó có thể phát hiện được. Có thể kể đến một số ví dụ như sau:
Dữ liệu bị hỏng, chẳng hạn như JSON không đúng định dạng.
Mô phỏng bộ nhớ đầy khi lưu vào tệp.
Đối tượng được tạo lại khi đang thực hiện quy trình (chẳng hạn như một hoạt động khi thiết bị được xoay).
Các phép kiểm thử đơn vị cần tránh
Bạn nên tránh một số kiểm thử đơn vị vì có giá trị thấp:
Các chương trình kiểm thử xác minh hoạt động chính xác của khung hoặc thư viện chứ không phải mã của bạn.
Các điểm truy cập khung như hoạt động, mảnh hoặc dịch vụ không được có logic nghiệp vụ, vì vậy, bạn không nên ưu tiên kiểm thử đơn vị. Các bài kiểm thử đơn vị cho hoạt động có ít giá trị vì các bài kiểm thử này chủ yếu bao gồm mã khung và đòi hỏi việc thiết lập nhiều hơn. Các hoạt động kiểm thử đo lường như kiểm thử giao diện người dùng
có thể bao gồm các lớp này.
Kiểm thử giao diện người dùng
Bạn nên triển khai một số loại kiểm thử giao diện người dùng:
Kiểm thử giao diện người dùng trên màn hình kiểm tra các hoạt động tương tác quan trọng của người dùng trong một màn hình. Chúng thực hiện các thao tác như nhấp vào nút, nhập biểu mẫu và kiểm tra trạng thái hiển thị. Bạn nên bắt đầu bằng một lớp kiểm thử cho mỗi màn hình.
Kiểm thử luồng người dùng hoặc Kiểm thử điều hướng, bao gồm các đường dẫn phổ biến nhất. Các chương trình kiểm thử này mô phỏng một người dùng di chuyển qua một quy trình điều hướng. Đây là các phép kiểm thử đơn giản, hữu ích trong việc kiểm tra các sự cố thời gian chạy khi khởi chạy.
Các cảnh báo thử nghiệm khác
Có nhiều loại hình kiểm thử chuyên biệt hơn như kiểm thử ảnh chụp màn hình, kiểm thử hiệu suất và kiểm thử khỉ. Bạn cũng có thể phân loại các bài kiểm thử theo mục đích, chẳng hạn như hồi quy, khả năng hỗ trợ tiếp cận và khả năng tương thích.
Tài liệu đọc thêm
Để kiểm thử riêng biệt, thông thường, bạn cần thay thế các phần phụ thuộc của đối tượng đang kiểm thử bằng các phần phụ thuộc giả mạo hoặc mô phỏng, được gọi là "Nhân đôi kiểm thử". Hãy tiếp tục đọc về chúng trong phần Sử dụng nhân đôi kiểm thử trong Android.
Nếu bạn muốn tìm hiểu cách tạo chương trình kiểm thử đơn vị và giao diện người dùng, hãy xem bài viết Lớp học lập trình kiểm thử.
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,["# What to test in Android\n\nWhat you should test depends on factors such as the type of app, the development\nteam, the amount of legacy code, and the architecture used. The following\nsections outline what a beginner might want to consider when planning what to\ntest in their app.\n\nOrganization of test directories\n--------------------------------\n\nA typical project in Android Studio contains two directories that hold tests\ndepending on their execution environment. Organize your tests in the following\ndirectories as described:\n\n- The `androidTest` directory should contain the tests that run on real or virtual devices. Such tests include integration tests, end-to-end tests, and other tests where the JVM alone cannot validate your app's functionality.\n- The `test`directory should contain the tests that run on your local machine, such as unit tests. In contrast to the above, these can be tests that run on a local JVM.\n\nEssential unit tests\n--------------------\n\nWhen following best practice, you should ensure you use unit tests in the\nfollowing cases:\n\n- **Unit tests** for **ViewModels**, or presenters.\n- **Unit tests** for the **data** layer, especially repositories. Most of the data layer should be platform-independent. Doing so enables test doubles to replace database modules and remote data sources in tests. See the guide on [using test doubles in Android](/training/testing/fundamentals/test-doubles)\n- **Unit tests** for other platform-independent layers such as the **Domain** layer, as with use cases and interactors.\n- **Unit tests** for **utility classes** such as string manipulation and math.\n\n### Testing Edge Cases\n\nUnit tests should focus on both normal and edge cases. Edge cases are uncommon\nscenarios that human testers and larger tests are unlikely to catch. Examples\ninclude the following:\n\n- Math operations using negative numbers, zero, and [boundary\n conditions](https://en.wikipedia.org/wiki/Off-by-one_error).\n- All the possible network connection errors.\n- Corrupted data, such as malformed JSON.\n- Simulating full storage when saving to a file.\n- Object recreated in the middle of a process (such as an activity when the device is rotated).\n\n### Unit Tests to Avoid\n\nSome unit tests should be avoided because of their low value:\n\n- Tests that verify the correct operation of the framework or a library, not your code.\n- Framework entry points such as *activities, fragments, or services* should not have business logic so unit testing shouldn't be a priority. Unit tests for activities have little value, because they would cover mostly framework code and they require a more involved setup. Instrumented tests such as UI tests can cover these classes.\n\nUI tests\n--------\n\nThere are several types of UI tests you should employ:\n\n- **Screen UI tests** check critical user interactions in a single screen. They perform actions such as clicking on buttons, typing in forms, and checking visible states. One test class per screen is a good starting point.\n- **User flow tests** or **Navigation tests**, covering most common paths. These tests simulate a user moving through a navigation flow. They are simple tests, useful for checking for run-time crashes in initialization.\n\n| **Note:** Test coverage is a metric that some testing tools can calculate, and indicates how much of your code is visited by your tests. It can detect untested portions of the codebase, but it should not be used as the only metric to claim a good testing strategy.\n\nOther tests\n-----------\n\nThere are more specialized tests such as screenshot tests, performance tests,\nand [monkey tests](/studio/test/monkey). You can also categorize tests by purpose, such as\nregressions, accessibility, and compatibility.\n\nFurther reading\n---------------\n\nIn order to test in isolation, you oftentimes need to replace the dependencies\nof the subject under test with fake or mock dependencies, called \"Test doubles\"\nin general. Continue reading about them in [Using test doubles in Android](/training/testing/fundamentals/test-doubles).\n\nIf you want to learn how to create unit and UI tests, check out the [Testing\ncodelabs](/codelabs/advanced-android-kotlin-training-testing-basics)."]]
