Chạy thử nghiệm (Atest)

Atest là một công cụ dòng lệnh cho phép người dùng xây dựng, cài đặt và chạy thử nghiệm Android cục bộ, giúp tăng tốc đáng kể việc chạy lại thử nghiệm mà không cần kiến ​​thức về các tùy chọn dòng lệnh khai thác thử nghiệm của Liên đoàn Thương mại . Trang này giải thích cách sử dụng Atest để chạy thử nghiệm Android.

Để biết thông tin chung về cách viết bài kiểm tra cho Android, hãy xem Kiểm tra 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 thử nghiệm trong tệp TEST_MAPPING thông qua Atest, hãy xem Chạy thử nghiệm 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 của nhà phát triển Atest .

Thiết lập môi trường của bạn

Để thiết lập môi trường Atest của bạn, hãy làm theo hướng dẫn trong Thiết lập môi trường , Chọn mục tiêuXây dựng mã .

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

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

atest test-to-run [optional-arguments]

Đối số tùy chọn

Bảng sau liệt kê các đối số được sử dụng phổ biến nhất. Danh sách đầy đủ có sẵn thông qua atest --help .

Lựa chọn Tùy chọn dài Sự miêu tả
-b --build Xây dựng mục tiêu thử nghiệm. (mặc định)
-i --install Cài đặt các tạo phẩm thử nghiệm (APK) trên thiết bị. (mặc định)
-t --test Chạy thử nghiệm. (mặc định)
-s --serial Chạy thử nghiệm trên thiết bị được chỉ định. Một thiết bị có thể được kiểm tra tại một thời điểm.
-d --disable-teardown Vô hiệu hóa việc phân tích và dọn dẹp thử nghiệm.
--info Không dùng nữa.
--dry-run Chạy thử Atest mà không thực sự xây dựng, cài đặt hoặc chạy thử nghiệm.
-m --rebuild-module-info Buộc xây dựng lại tệp module-info.json .
-w --wait-for-debugger Đợi trình gỡ lỗi hoàn tất trước khi thực thi.
-v --verbose Hiển thị ghi nhật ký mức DEBUG.
--iterations Chạy thử nghiệm vòng lặp cho đến khi đạt được số lần lặp tối đa. (10 theo mặc định)
--rerun-until-failure [COUNT=10] Chạy lại tất cả các thử nghiệm cho đến khi xảy ra lỗi hoặc đạt đến số lần lặp tối đa. (10 theo mặc định)
--retry-any-failure [COUNT=10] Chạy lại các bài kiểm tra không thành công cho đến khi đạt hoặc đạt đến số lần lặp tối đa. (10 theo mặc định)
--start-avd Tự động tạo AVD và chạy thử nghiệm trên thiết bị ảo.
--acloud-create Tạo AVD bằng lệnh acloud .
--[CUSTOM_ARGS] Chỉ định các đối số tùy chỉnh cho người chạy thử nghiệm.
-a --all-abi Chạy thử nghiệm cho tất cả các kiến ​​trúc thiết bị có sẵn.
--host Chạy thử nghiệm hoàn toàn trên máy chủ mà không cần thiết bị.
Lưu ý: Việc chạy thử nghiệm máy chủ yêu cầu thiết bị có --host sẽ không thành công.
--history Hiển thị kết quả kiểm tra theo thứ tự thời gian.
--latest-result In kết quả kiểm tra mới nhất.

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

Chỉ định kiểm tra

Để chạy thử nghiệm, hãy chỉ định một hoặc nhiều thử nghiệm bằng cách sử dụng một trong các mã định danh sau:

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

Phân tách các tham chiếu đến nhiều bài kiểm tra bằng dấu cách, như thế này:

atest test-identifier-1 test-identifier-2

Tên mô-đun

Để chạy toàn bộ mô-đun thử nghiệm, hãy sử dụng tên mô-đun của nó. Nhập tên giống như 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 thử nghiệm đó.

Ví dụ:

atest FrameworksServicesTests
atest CtsVideoTestCases

Mô-đun:Lớp

Để chạy một lớp duy nhất trong một mô-đun, hãy sử dụng Module:Class . Mô-đun giống như mô tả ở Tên mô-đun . Lớp là tên của lớp kiểm tra 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 duy nhất mà không nêu rõ tên mô-đun, hãy sử dụng tên lớp.

Ví dụ:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

Thử nghiệm tích hợp Tradefed

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

Để chạy thử nghiệm reboot.xml :

atest example/reboot

Để chạy thử nghiệm native-benchmark.xml :

atest native-benchmark

Đường dẫn tập tin

Atest hỗ trợ chạy cả kiểm tra dựa trên mô-đun và kiểm tra 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 tra nếu thích hợp. Nó cũng hỗ trợ chạy một lớp 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ột 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ừ Android repo-root/cts/tests/video :

    atest .

Chạy một lớp kiểm tra

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

Từ repo-root Android:

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

Chạy thử nghiệm tích hợp

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

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

Tên gói hàng

Atest hỗ trợ tìm kiếm các bài kiểm tra theo tên gói.

Ví dụ:

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

Chỉ định các bước: Xây dựng, cài đặt hoặc chạy

Sử dụng các tùy chọn -b , -i-t để chỉ định bước nào sẽ chạy. Nếu bạn không chỉ định một tùy chọn thì tất cả các bước sẽ được thực hiện.

  • Chỉ xây dựng mục tiêu: atest -b test-to-run
  • Chỉ chạy thử nghiệm: atest -t test-to-run
  • Cài đặt apk và chạy thử nghiệm: atest -it test-to-run
  • Build và chạy, nhưng không cài đặt: atest -bt test-to-run

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

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

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

Atest hỗ trợ chạy các phương thức cụ thể trong một lớp thử nghiệm. Mặc dù toàn bộ mô-đun cần được xây dựng nhưng điều này giúp giảm thời gian cần thiết để chạy thử nghiệm. Để 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 một 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 chúng 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 ưa thích để chạy một phương thức duy nhất, testFlagChange . Những ví dụ này được ưu tiên hơn là 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 bài kiểm tra nhanh hơn nhiều.

Sử dụng Mô-đun:Lớp:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

Từ repo-root Android:

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

Nhiều phương thức có thể được chạy 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 chúng bằng dấu cách giống như cách chạy nhiều bài kiểm tra. Atest xây dựng và chạy các lớp một cách hiệu quả, do đó, 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 khi chạy toàn bộ mô-đun.

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

atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests

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

atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest

Chạy 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 thử nghiệm này cho tất cả các kiến ​​trúc thiết bị có sẵn, trong ví dụ này là armeabi-v7a (ARM 32-bit) và arm64-v8a (ARM 64-bit).

Ví dụ kiểm tra đầ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 thử nghiệm và thẻ bắt đầu bằng # (#) để chỉ định thêm một phương thức riêng lẻ.

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

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

Chạy phần sau để chỉ định toàn bộ bài kiểm tra:

atest inputflinger_tests:InputDispatcherTest

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

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Chạy thử nghiệm trong TEST_MAPPING

Atest có thể chạy thử nghiệm trong tệp TEST_MAPPING .

Chạy thử nghiệm gửi trước một cách ngầm định

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

atest

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

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

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

Các nhóm thử nghiệm có sẵn là: presubmit (mặc định), postsubmit , mainline-presubmitall .

Chạy thử nghiệm gửi bài đăng trong tệp TEST_MAPPING trong thư mục hiện tại và thư mục mẹ:

atest :postsubmit

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

atest :all

Chạy thử nghiệm gửi bài đăng trong tệp TEST_MAPPING trong /path/to/project và các thư mục mẹ của nó:

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

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

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

Chạy thử nghiệm trong thư mục con

Theo mặc định, Atest chỉ tìm kiếm các bài kiểm tra 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ẹ của nó). Nếu bạn cũng muốn chạy thử nghiệm trong các tệp TEST_MAPPING trong thư mục con, hãy sử dụng --include-subdirs để buộc Atest cũng bao gồm các thử nghiệm đó:

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

Chạy thử nghiệm lặp lại

Chạy thử nghiệm lặp lại bằng cách chuyển đối số --iterations . Cho dù thành công hay thất bại, Atest sẽ lặp lại thử nghiệm cho đến khi đạt được số lần lặp 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à 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 phát hiện các bài kiểm tra không ổn định dễ dàng hơn:

Cách tiếp cận 1: Chạy tất cả các thử nghiệm 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
    

Cách tiếp cận 2: Chỉ chạy các thử nghiệm thất bại 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 thử nghiệm và một trong các thử nghiệm không thành công. Chỉ chạy bài kiểm tra thất bại 10 lần (theo mặc định) hoặc cho đến khi bài kiểm tra đạt.
    atest test-to-run --retry-any-failure
    
  • Dừng chạy bài kiểm tra thất bại khi nó vượt qua hoặc đạt đến vòng thứ 100.
    atest test-to-run --retry-any-failure 100
    

Chạy thử nghiệm trên AVD

Atest có thể chạy thử nghiệm trên AVD mới được tạo. Chạy acloud create để tạo AVD và xây dựng các thành phần lạ, sau đó sử dụng các ví dụ sau để chạy thử nghiệm.

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

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

Bắt đầu AVD như một phần của quá trình chạy 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 tùy chọn cho mô-đun

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

atest test-to-run -- [CUSTOM_ARGS]

Chuyển các tùy chọn mô-đun thử nghiệm tới người chuẩn bị mục tiêu hoặc người chạy thử nghiệm được xác định trong tệp cấu hình thử nghiệm:

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

Chuyển các tùy chọn cho loại hoặc lớp người 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 tùy chọn chỉ dành cho thử nghiệm, hãy xem Truyền tùy chọn cho mô-đun .