Chạy kiểm thử (Atest)

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.

Atest là một công cụ dòng lệnh cho phép người dùng tạo, cài đặt và chạy các chương trình kiểm thử Android trên máy, giúp tăng tốc đáng kể cho việc chạy lại chương trình kiểm thử mà không cần có kiến thức về các tuỳ chọn dòng lệnh bộ kiểm thử Liên minh thương mại. Trang này giải thích cách sử dụng Atest để chạy kiểm thử Android.

Để biết thông tin chung về cách viết mã kiểm thử cho Android, hãy xem bài viết Kiểm thử nền tảng Android.

Để biết thông tin về cấu trúc tổng thể của Atest, hãy tham khảo Hướng dẫn dành cho nhà phát triển Atest.

Để biết thông tin về cách chạy kiểm thử trong tệp TEST_MAPPING thông qua Atest, hãy xem phần Chạy kiểm thử trong tệp TEST_MAPPING.

Để thêm một tính năng vào Atest, hãy làm theo quy trình làm việc dành cho nhà phát triển Atest.

Thiết lập môi trường

Để thiết lập môi trường Atest, hãy làm theo hướng dẫn trong phần Thiết lập môi trường, Chọn mục tiêu và Tạo mã.

Cách sử dụng cơ bản

Các lệnh Atest có dạng như sau:

atest test-to-run [optional-arguments]

Đối số không bắt buộc

Bảng sau đây liệt kê các đối số thường dùng nhất. Bạn có thể xem danh sách đầy đủ thông qua atest --help.

Để biết thêm thông tin về -b, -i và -t, hãy xem phần Chỉ định các bước: tạo, cài đặt hoặc chạy.

Chỉ định kiểm thử

Để chạy kiểm thử, hãy chỉ định một hoặc nhiều kiểm thử bằng một trong các giá trị nhận dạng sau:

• Tên mô-đun
• Mô-đun:Lớp
• Tên lớp
• Kiểm thử tích hợp Tradefed
• Đường dẫn tệp
• Tên gói

Phân tách các tệp tham chiếu đến nhiều chương trình kiểm thử bằng dấu cách, như sau:

atest test-identifier-1 test-identifier-2

Tên mô-đun

Để chạy toàn bộ mô-đun kiểm thử, hãy sử dụng tên mô-đun đó. Nhập tên xuất hiện trong các biến LOCAL_MODULE hoặc LOCAL_PACKAGE_NAME trong tệp Android.mk hoặc Android.bp của kiểm thử đó.

Ví dụ:

atest FrameworksServicesTests
atest CtsVideoTestCases

Mô-đun:Lớp

Để chạy một lớp trong mô-đun, hãy sử dụng Module:Class. Mô-đun giống như mô tả trong phần Tên mô-đun. Class (Lớp) là tên của lớp kiểm thử trong tệp .java và có thể là tên lớp đủ điều kiện hoặc tên cơ bản.

Ví dụ:

atest CtsVideoTestCases:VideoEncoderDecoderTest
atest FrameworksServicesTests:ScreenDecorWindowTests
atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests

Tên lớp

Để chạy một lớp mà không cần nêu rõ tên mô-đun, hãy sử dụng tên lớp.

Ví dụ:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

Kiểm thử tích hợp Tradefed

Để chạy các chương trình kiểm thử được tích hợp trực tiếp vào TradeFed (không phải mô-đun), hãy nhập tên xuất hiện trong kết quả của lệnh tradefed.sh list configs. Ví dụ:

Cách chạy kiểm thử reboot.xml:

atest example/reboot

Cách chạy kiểm thử native-benchmark.xml:

atest native-benchmark

Đường dẫn tệp

Atest hỗ trợ chạy cả kiểm thử dựa trên mô-đun và kiểm thử dựa trên tích hợp bằng cách nhập đường dẫn đến tệp hoặc thư mục kiểm thử của chúng khi thích hợp. Công cụ này cũng hỗ trợ chạy một lớp duy nhất bằng cách chỉ định đường dẫn đến tệp Java của lớp. Cả đường dẫn tương đối và tuyệt đối đều được hỗ trợ.

Chạy mô-đun

Các ví dụ sau đây cho thấy hai cách chạy mô-đun CtsVideoTestCases bằng đường dẫn tệp.

Chạy từ repo-root Android:

atest cts/tests/video

Chạy từ repo-root/cts/tests/video Android:

    atest .

Chạy lớp kiểm thử

Ví dụ sau đây cho biết cách chạy một lớp cụ thể trong mô-đun CtsVideoTestCases bằng cách sử dụng đường dẫn tệp.

Từ repo-root Android:

    atest cts/tests/video/src/android/video/cts/VideoEncoderDecoderTest.java

Chạy kiểm thử tích hợp

Ví dụ sau đây cho biết cách chạy kiểm thử tích hợp bằng đường dẫn tệp từ repo-root của Android:

    atest tools/tradefederation/contrib/res/config/example/reboot.xml

Tên gói

Atest hỗ trợ tìm kiếm kiểm thử theo tên gói.

Ví dụ:

    atest com.android.server.wm
    atest com.android.uibench.janktests

Chỉ định các bước: Tạo, cài đặt hoặc chạy

Sử dụng các tuỳ chọn -b, -i và -t để chỉ định các bước cần chạy. Nếu bạn không chỉ định một tuỳ chọn, thì tất cả các bước sẽ chạy.

• Chỉ tạo mục tiêu bản dựng: atest -b test-to-run
• Chỉ chạy kiểm thử: atest -t test-to-run
• Cài đặt apk và chạy kiểm thử: atest -it test-to-run
• Tạo và chạy, nhưng không cài đặt: atest -bt test-to-run

Atest có thể buộc một kiểm thử bỏ qua bước dọn dẹp hoặc gỡ bỏ. Nhiều chương trình kiểm thử, chẳng hạn như CTS, sẽ dọn dẹp thiết bị sau khi chạy chương trình kiểm thử. Vì vậy, nếu không có tham số --disable-teardown, bạn sẽ không thể chạy lại chương trình kiểm thử bằng -t. Sử dụng -d trước -t để bỏ qua bước dọn dẹp kiểm thử và kiểm thử lặp lại.

atest -d test-to-run
atest -t test-to-run

Chạy các phương thức cụ thể

Atest hỗ trợ chạy các phương thức cụ thể trong một lớp kiểm thử. Mặc dù cần phải tạo toàn bộ mô-đun, nhưng việc này sẽ giúp giảm thời gian cần thiết để chạy các chương trình kiểm thử. Để chạy các phương thức cụ thể, hãy xác định lớp bằng cách sử dụng bất kỳ cách nào được hỗ trợ để xác định lớp (Mô-đun:Lớp, đường dẫn tệp, v.v.) và thêm tên của phương thức:

atest reference-to-class#method1

Khi chỉ định nhiều phương thức, hãy phân tách các phương thức đó bằng dấu phẩy:

atest reference-to-class#method1,method2,method3

Ví dụ:

atest com.android.server.wm.ScreenDecorWindowTests#testMultipleDecors
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval

Hai ví dụ sau đây cho thấy các cách ưu tiên để chạy một phương thức duy nhất, testFlagChange. Bạn nên sử dụng các ví dụ này thay vì chỉ sử dụng tên lớp vì việc chỉ định mô-đun hoặc vị trí tệp Java cho phép Atest tìm thấy chương trình kiểm thử nhanh hơn nhiều.

Sử dụng Module:Class:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

Từ repo-root Android:

atest frameworks/base/services/tests/wmtests/src/com/android/server/wm/ScreenDecorWindowTests.java#testFlagChange

Bạn có thể chạy nhiều phương thức từ các lớp và mô-đun khác nhau:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors

Chạy nhiều lớp

Để chạy nhiều lớp, hãy phân tách các lớp đó bằng dấu cách giống như cách chạy nhiều chương trình kiểm thử. Atest xây dựng và chạy các lớp một cách hiệu quả, vì vậy, việc chỉ định một tập hợp con các lớp trong một mô-đun sẽ cải thiện hiệu suất so với việc chạy toàn bộ mô-đun.

Cách chạy hai lớp trong cùng một mô-đun:

atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests

Cách chạy hai lớp trong các mô-đun khác nhau:

atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest

Chạy tệp nhị phân GTest

Atest có thể chạy các tệp nhị phân GTest. Sử dụng -a để chạy các chương trình kiểm thử này cho tất cả kiến trúc thiết bị hiện có, trong ví dụ này là armeabi-v7a (ARM 32 bit) và arm64-v8a (ARM 64 bit).

Ví dụ về kiểm thử dữ liệu đầu vào:

atest -a libinput_tests inputflinger_tests

Để chọn một tệp nhị phân GTest cụ thể để chạy, hãy sử dụng dấu hai chấm (:) để chỉ định tên kiểm thử và hashtag (#) để chỉ định thêm một phương thức riêng lẻ.

Ví dụ: đối với định nghĩa kiểm thử sau:

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

Chạy đoạn mã sau để chỉ định toàn bộ kiểm thử:

atest inputflinger_tests:InputDispatcherTest

Hoặc chạy một kiểm thử riêng lẻ bằng cách sử dụng các lệnh sau:

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Chạy kiểm thử trong TEST_MAPPING

Atest có thể chạy các chương trình kiểm thử trong tệp TEST_MAPPING.

Chạy các bài kiểm thử trước khi gửi một cách ngầm ẩn

Chạy kiểm thử trước khi gửi trong các tệp TEST_MAPPING trong thư mục hiện tại và thư mục mẹ:

atest

Chạy các bài kiểm thử trước khi gửi trong tệp TEST_MAPPING trong /path/to/project và các thư mục mẹ của tệp đó:

atest --test-mapping /path/to/project

Chạy một nhóm thử nghiệm đã chỉ định

Các nhóm kiểm thử hiện có là: presubmit(mặc định), postsubmit, mainline-presubmit và all.

Chạy các kiểm thử sau khi gửi trong tệp TEST_MAPPING trong thư mục hiện tại và thư mục mẹ:

atest :postsubmit

Chạy kiểm thử từ tất cả các nhóm trong tệp TEST_MAPPING:

atest :all

Chạy các bài kiểm thử sau khi gửi trong tệp TEST_MAPPING trong /path/to/project và các thư mục mẹ của tệp đó:

atest --test-mapping /path/to/project:postsubmit

Chạy các bài kiểm thử dòng chính trong tệp TEST_MAPPING trong /path/to/project và các thư mục mẹ của tệp đó:

atest --test-mapping /path/to/project:mainline-presubmit

Chạy kiểm thử trong các thư mục con

Theo mặc định, Atest chỉ tìm kiếm các chương trình kiểm thử trong các tệp TEST_MAPPING trở lên (từ thư mục hiện tại hoặc thư mục đã cho đến thư mục mẹ). Nếu bạn cũng muốn chạy kiểm thử trong các tệp TEST_MAPPING trong thư mục con, hãy sử dụng --include-subdirs để buộc Atest cũng đưa các kiểm thử đó vào:

atest --include-subdirs /path/to/project

Chạy kiểm thử trong vòng lặp

Chạy kiểm thử trong vòng lặp bằng cách truyền đối số --iterations. Cho dù kiểm thử thành công hay không, Atest sẽ lặp lại kiểm thử cho đến khi đạt đến số lần lặp lại tối đa.

Ví dụ:

Theo mặc định, Atest lặp lại 10 lần. Số lần lặp phải là một số nguyên dương.

atest test-to-run --iterations
atest test-to-run --iterations 5

Các phương pháp sau đây giúp bạn dễ dàng phát hiện các kiểm thử không ổn định:

Phương pháp 1: Chạy tất cả các bài kiểm thử cho đến khi xảy ra lỗi hoặc đạt đến số lần lặp tối đa.

• Dừng khi xảy ra lỗi hoặc vòng lặp đạt đến vòng thứ 10 (theo mặc định).

  atest test-to-run --rerun-until-failure
  

• Dừng khi xảy ra lỗi hoặc vòng lặp đạt đến vòng thứ 100.

  atest test-to-run --rerun-until-failure 100
  

Phương pháp 2: Chỉ chạy các bài kiểm thử không đạt cho đến khi đạt hoặc đạt đến số lần lặp tối đa.

• Giả sử test-to-run có nhiều trường hợp kiểm thử và một trong các trường hợp kiểm thử không thành công. Chỉ chạy kiểm thử không đạt 10 lần (theo mặc định) hoặc cho đến khi kiểm thử đạt.

  atest test-to-run --retry-any-failure
  

• Dừng chạy kiểm thử không thành công khi kiểm thử đó thành công hoặc đạt đến vòng thứ 100.

  atest test-to-run --retry-any-failure 100
  

Chạy kiểm thử trên AVD

Atest có thể chạy các chương trình kiểm thử trên một AVD mới tạo. Chạy acloud create để tạo AVD và tạo cấu phần phần mềm, sau đó sử dụng các ví dụ sau để chạy kiểm thử.

Khởi động một AVD và chạy kiểm thử trên AVD đó:

acloud create --local-instance --local-image && atest test-to-run

Bắt đầu một AVD trong quá trình chạy kiểm thử:

atest test-to-run --acloud-create "--local-instance --local-image"

Để biết thêm thông tin, hãy chạy acloud create --help.

Truyền các tuỳ chọn đến mô-đun

Atest có thể truyền các tuỳ chọn để kiểm thử các mô-đun. Để thêm các tuỳ chọn dòng lệnh TradeFed vào lần chạy kiểm thử, hãy sử dụng cấu trúc sau và đảm bảo các đối số tuỳ chỉnh tuân theo định dạng tuỳ chọn dòng lệnh Tradefed.

atest test-to-run -- [CUSTOM_ARGS]

Truyền các tuỳ chọn mô-đun kiểm thử đến trình chuẩn bị mục tiêu hoặc trình chạy kiểm thử được xác định trong tệp cấu hình kiểm thử:

atest test-to-run -- --module-arg module-name:option-name:option-value
atest GtsPermissionTestCases -- --module-arg GtsPermissionTestCases:ignore-business-logic-failure:true

Truyền các tuỳ chọn đến một loại hoặc lớp trình chạy:

atest test-to-run -- --test-arg test-class:option-name:option-value
atest CtsVideoTestCases -- --test-arg com.android.tradefed.testtype.JarHosttest:collect-tests-only:true

Để biết thêm thông tin về các tuỳ chọn chỉ dành cho kiểm thử, hãy xem phần Chuyển tuỳ chọn đến các mô-đun.