Google cam kết thúc đẩy công bằng chủng tộc cho Cộng đồng người da đen. Xem cách thực hiện.

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 bài kiểm tra Android cục bộ, giúp tăng tốc đáng kể việc chạy lại bài kiểm tra 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 kiểm tra của Trade Federation . Trang này giải thích cách sử dụng Atest để chạy các bài kiểm tra Android.

Để biết thông tin chung về các bài kiểm tra viết 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 kiểm tra trong tệp TEST_MAPPING thông qua Atest, hãy xem Chạy kiểm tra trong tệp TEST_MAPPING .

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

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

Làm theo các bước trong các phần sau để thiết lập môi trường Atest của bạn.

Đặt biến môi trường

Đặt test_suite cho Soong hoặc LOCAL_COMPATIBILITY_SUITE cho Thực hiện các quy tắc tập lệnh xây dựng Bao bì sau.

Chạy envsetup.sh

Từ gốc của kiểm tra nguồn Android, hãy chạy:

source build/envsetup.sh

Chạy lunch

Chạy lệnh lunch để hiển thị menu các thiết bị được hỗ trợ. Tìm thiết bị và chạy lệnh đó.

Ví dụ: nếu bạn đã kết nối thiết bị ARM, hãy chạy lệnh sau:

lunch aosp_arm64-eng

Điều này đặt các biến môi trường khác nhau cần thiết để chạy Atest và thêm lệnh Atest vào $PATH của bạn.

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

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. 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 các mục tiêu thử nghiệm. (mặc định)
-i --install Cài đặt phần mềm thử nghiệm (APK) trên thiết bị. (mặc định)
-t --test Chạy các bài kiểm tra. (mặc định)
-s --serial Chạy các bài kiểm tra 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 Tắt tính năng thu nhỏ và dọn dẹp thử nghiệm.
<c> --info Hiển thị thông tin liên quan về các mục tiêu được chỉ định, sau đó thoát ra.
<c> --dry-run Khô chạy Thử nghiệm 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 Chờ 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 GỠ LỖI.
<c> --iterations Kiểm tra chạy lặp lại cho đến khi đạt đến số lần lặp tối đa. (10 theo mặc định)
<c> --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 tối đa. (10 theo mặc định)
<c> --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 tối đa. (10 theo mặc định)
<c> --start-avd Tự động tạo AVD và chạy thử nghiệm trên thiết bị ảo.
<c> --acloud-create Tạo AVD bằng lệnh acloud .
<c> --[CUSTOM_ARGS] Chỉ định đối số tùy chỉnh cho người chạy thử nghiệm.
-a --all-abi Chạy các bài kiểm tra cho tất cả các kiến ​​trúc thiết bị có sẵn.
<c> --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.
<c> --flakes-info Hiển thị kết quả thử nghiệm với thông tin mảnh.
<c> --history Hiển thị kết quả kiểm tra theo thứ tự thời gian.
<c> --latest-result In kết quả thử nghiệm 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 các bài kiểm tra

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

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

Tách các tham chiếu đến nhiều bài kiểm tra 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 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 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 Mô-đun: Lớp . Mô-đun giống như 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

Kiểm tra tích hợp Tradefed

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

Để chạy kiểm tra 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 của họ nếu thích hợp. Nó cũng hỗ trợ chạy một lớp đơn lẻ bằng cách chỉ định đường dẫn đến tệp Java của lớp đó. Cả hai đườ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ừ repo-root Android:

atest cts/tests/video

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

    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ừ 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 cho thấy cách chạy kiểm tra tích hợp bằng cách sử dụng đường dẫn tệp từ repo-root Android:

    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 cần 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: ít nhất 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

Ít nhất có thể buộc thử nghiệm bỏ qua bước dọn dẹp hoặc xé nhỏ. Nhiều thử nghiệm, chẳng hạn như CTS, dọn dẹp thiết bị sau khi chạy thử nghiệm, vì vậy việc thử 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 dọn dẹp kiểm tra và kiểm tra lặp đi 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, điều này làm giảm thời gian cần thiết để chạy các bài kiểm tra. Để chạy các phương thức cụ thể, hãy xác định lớp bằ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 ưa thích để chạy một phương pháp 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 thấy 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 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ả, vì vậy việc chỉ định một tập hợp con của 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 mã nhị phân GTest

Atest có thể chạy mã nhị phân GTest. Sử dụng -a để chạy các bài kiểm tra 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).

Kiểm tra đầu vào mẫu:

atest -a libinput_tests inputflinger_tests

Để chọn một mã 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ộ kiểm tra:

atest inputflinger_tests:InputDispatcherTest

Hoặc chạy thử nghiệm riêng lẻ bằng cách sử dụng 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 kiểm tra gửi trước trong tệp TEST_MAPPING trong thư mục mẹ và thư mục hiện tại:

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 kiểm tra có sẵn là: presubmit (mặc định), postsubmit , gửi trước mainline-presubmit , và all .

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

<pre>
<code class="devsite-terminal">atest :postsubmit</code>
</pre>

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

<pre>
<code class="devsite-terminal">atest :all</code>
</pre>

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

<pre>
<code class="devsite-terminal">atest --test-mapping <var>/path/to/project</var>:postsubmit</code>
</pre>

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

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

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

Chạy kiểm tra lặp đi lặp lại bằng cách chuyển đối số --iterations . Cho dù nó đạt hay không đạt, Atest sẽ lặp lại bài kiểm tra 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 giúp phát hiện các thử nghiệm bị bong tróc dễ dàng hơn:

Phương pháp 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 lại 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 lại khi xảy ra lỗi hoặc lần lặp đế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 tra không thành công cho đến khi vượt qua 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 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 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 AVDs

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 tác, sau đó sử dụng các ví dụ sau để chạy các bài kiểm tra của bạn.

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ử nghiệm:

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 các tùy chọn đến mô-đun

Atest có thể vượt qua 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]

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 hạng 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ỉ kiểm tra, hãy xem Chuyển tùy chọn vào mô-đun .