Chạy thử nghiệm (Ít nhất)

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 các thử nghiệm Android cục bộ, giúp tăng tốc đáng kể các lần chạy lại thử nghiệm mà không yêu cầu 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ề 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ề 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 dành cho 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ã .

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 đây liệt kê các đối số được sử dụng phổ biến nhất. Một danh sách đầy đủ có sẵn thông qua atest --help .

Tùy chọn tùy chọn dài Sự miêu tả
-b --build Xây dựng các mục tiêu thử nghiệm. (mặc định)
-i --install Cài đặt các phần mề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 thử nghiệm xé và dọn dẹp.
--info Hiển thị thông tin liên quan về các mục tiêu đã chỉ định, sau đó thoát.
--dry-run Chạy khô 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 kết thúc trước khi thực hiện.
-v --verbose Hiển thị ghi nhật ký mức GỠ LỖI.
--iterations Kiểm tra chạy vòng lặp cho đến khi đạt đến 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 bài kiểm tra cho đến khi xảy ra lỗi hoặc đạt đến số lần lặp lại 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 vượt qua hoặc đạt đến số lần lặp lại 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 đố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 ý: 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 số nhận dạng 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

Các tham chiếu riêng biệt cho nhiều bài kiểm tra có 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ư tên xuất hiện trong 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 Mô-đun:Lớp . Mô-đun giống như được mô tả trong Tên mô-đun . Lớp là tên của lớp thử nghiệm 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 đơn lẻ 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ả thử nghiệm dựa trên mô-đun và thử nghiệm dựa trên tích hợp bằng cách nhập đường dẫn đến tệp thử nghiệm hoặc thư mục phù hợp. Nó 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ột mô-đun

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

Chạy từ Android repo-root :

atest cts/tests/video

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

    atest .

Chạy một lớp thử nghiệm

Ví dụ sau đây cho thấy 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ừ Android repo-root :

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

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

Ví dụ sau đây cho biết 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 các bước 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ẽ chạy.

  • 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
  • Xây dựng và chạy, nhưng không cài đặt: atest -bt test-to-run

Atest có thể buộc một bài kiểm tra bỏ qua bước dọn dẹp hoặc phân tích. Nhiều thử nghiệm, chẳng hạn như CTS, 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 với -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 làm sạch 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 phải đượ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 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 ưu tiên để 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ừ Android repo-root :

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

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 chúng bằng dấu cách giống như khi 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 so với việc 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 mã nhị phân GTest

Atest có thể chạy mã 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 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à dấu thăng (#) để chỉ định thêm một phương pháp 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 cách 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 trước khi gửi ngầm

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 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

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 các bài kiểm tra postsubmit 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 các bài kiểm tra postsubmit 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: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 các 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 trong vòng lặp

Chạy thử nghiệm trong vòng lặp bằng cách chuyển đối số --iterations . Cho dù vượt qua hay thất bại, Atest sẽ lặp lại thử nghiệm cho đến khi đạt đến 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 lần 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 lặp đế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 không thành công cho đến khi vượt qua hoặc đạt đến số lần lặp lại 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 thử nghiệm không thành công 10 lần (theo mặc định) hoặc cho đến khi thử nghiệm vượt qua.
    atest test-to-run --retry-any-failure
    
  • Dừng chạy thử nghiệm không thành công khi 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 tạo phẩm, sau đó sử dụng các ví dụ sau để chạy thử nghiệm của bạn.

Bắt đầu một 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 .

Chuyể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ử 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]

Vượt qua các tùy chọn mô-đun thử nghiệm để nhắm mục tiêu người chuẩn bị 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 Chuyển tùy chọn cho mô-đun .