Chạy kiểm thử (Atest)

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

Để biết thông tin chung về cách viết chương trình kiểm thử cho Android, hãy xem 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 cho nhà phát triển về thử nghiệm.

Để 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 Chạy kiểm thử trong tệp TEST_MAPPING.

Để thêm một đối tượng vào Atest, hãy làm theo Quy trình của nhà phát triển kiểm thử.

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 , Chọn mục tiêuTạo mã.

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

Các lệnh kiểm thử 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. Danh sách đầy đủ là có sẵn thông qua atest --help.

Lựa chọn Lựa chọn dài Mô tả
-b --build Tạo mục tiêu kiểm thử. (mặc định)
-i --install Cài đặt cấu phần phần mềm kiểm thử (APK) trên thiết bị. (mặc định)
-t --test Chạy kiểm thử. (mặc định)
-s --serial Chạy chương trình kiểm thử trên thiết bị đã chỉ định. Mỗi lần bạn chỉ có thể kiểm thử một thiết bị.
-d --disable-teardown Tắt tính năng chia nhỏ và dọn dẹp kiểm thử.
--dry-run Chạy thử nghiệm Atest mà không thực sự tạo, cài đặt hay chạy chương trình kiểm thử.
-m --rebuild-module-info Buộc tạo 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ị nhật ký cấp DEBUG.
--iterations Chạy các bài kiểm thử bằng vòng lặp cho đến khi đạt đến số lần lặp lại tối đa. (10 theo mặc định)
--rerun-until-failure [COUNT=10] Chạy lại tất cả các chương trình kiểm thử cho đến khi xảy ra lỗi hoặc số lần lặp lại tối đa là đạt được. (10 theo mặc định)
--retry-any-failure [COUNT=10] Chạy lại các lượt kiểm thử không thành công cho đến khi đạt 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 các bài kiểm thử trên thiết bị ảo.
--acloud-create Tạo AVD bằng lệnh acloud.
--[CUSTOM_ARGS] Chỉ định đối số tuỳ chỉnh cho trình chạy kiểm thử.
-a --all-abi Chạy kiểm thử cho tất cả cấu trúc thiết bị có sẵn.
--host Chạy chương trình kiểm thử hoàn toàn trên máy chủ mà không cần thiết bị.
Lưu ý: Chạy kiểm thử máy chủ lưu trữ yêu cầu thiết bị có --host sẽ không thành công.
--history Hiển thị kết quả thử nghiệm theo thứ tự thời gian.
--latest-result In kết quả kiểm thử mới nhất.

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

Chỉ định các bài 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 lệnh sau giá trị nhận dạng:

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

Tách biệt các tham chiếu đến nhiều 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 của mô-đun đó. Nhập tên đúng như tên xuất hiện trong các biến LOCAL_MODULE hoặc LOCAL_PACKAGE_NAME trong phép kiểm thử đó Android.mk hoặc Android.bp.

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: Lớp). Module (Mô-đun) là giống như mô tả trong Module name (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 lớp đó .

Ví dụ:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

Kiểm thử quá trình tích hợp trao đổi

Để 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 giống như trong kết quả của lệnh tradefed.sh list configs. Ví dụ:

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

atest example/reboot

Để 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ử 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 các ứng dụng đó khi thích hợp. Điều 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 minh hoạ 2 cách chạy mô-đun CtsVideoTestCases bằng một đường dẫn tệp.

Chạy trên Android repo-root:

atest cts/tests/video

Chạy trên Android repo-root/cts/tests/video:

    atest .

Chạy một lớp kiểm thử

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

Trên Android repo-root:

    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ừ Android repo-root:

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

Tên gói

Atest hỗ trợ tìm kiếm các bài 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-t để chỉ định bước cần chạy. Nếu bạn không chỉ định tuỳ chọn nào thì tất cả các bước sẽ chạy.

  • Chỉ tạo các 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 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

Quá trình kiểm thử có thể buộc một quy trình kiểm thử bỏ qua bước dọn dẹp hoặc chia nhỏ. Nhiều thử nghiệm, chẳng hạn như CTS, hãy dọn dẹp thiết bị sau khi chạy quy trình kiểm thử, vì vậy, hãy cố gắng chạy lại quy trình kiểm thử của bạn với -t sẽ không thành công nếu không có thông số --disable-teardown. 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ù toàn bộ mô-đun cần được tạo, điều này làm giảm thời gian cần thiết để chạy kiểm thử. Để chạy các phương thức cụ thể, 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 (Module:Class, tệp đường dẫn, v.v.) và nối tên của lớp 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 minh hoạ 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 so với việc 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 thử nghiệm nhanh hơn nhiều.

Sử dụng Module:Class:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

Trên Android repo-root:

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

Nhiều phương thức có thể 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 các lớp bằng dấu cách theo cách tương tự như khi chạy nhiều bài kiểm thử. Atest tạo bản dựng và chạy các lớp một cách hiệu quả, vì vậy việc chỉ định tập hợp con các lớp trong một mô-đun giúp cải thiện hiệu suất so với việc chạy toàn bộ .

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

Ví dụ về kiểm thử đầ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 kiểm thử name 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 lệnh sau để chỉ định toàn bộ kiểm thử:

atest inputflinger_tests:InputDispatcherTest

Hoặc chạy từng kiểm thử riêng lẻ bằng cách sử dụng các thao tác 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 ngầm kiểm thử gửi trước

Chạy chương trình kiểm thử gửi trước trong tệp TEST_MAPPING ở thư mục hiện tại và thư mục mẹ:

atest

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

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

Chạy một nhóm kiểm thử đã chỉ định

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

Chạy bài kiểm thử sau khi gửi trong các tệp TEST_MAPPING trong các 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 thử nghiệm sau khi gửi trong các tệp TEST_MAPPING trong /path/to/project và thư mục mẹ của nó:

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

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

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

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

Theo mặc định, Atest chỉ tìm kiếm các bài 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 vào các thư mục mẹ). Nếu bạn cũng muốn để chạy kiểm thử trong 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 kiểm thử đó:

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. Liệu đường liên kết có thành công không hoặc không thành công, Atest sẽ lặp lại quy trình kiểm thử cho đến khi đạt vòng lặp tối đa.

Ví dụ:

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

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

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

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

  • Dừng khi xảy ra lỗi hoặc vòng lặp đế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 đến vòng thứ 100.
    atest test-to-run --rerun-until-failure 100
    

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

  • Giả sử test-to-run có nhiều trường hợp kiểm thử và một trong chương trình kiểm thử không thành công. Chỉ chạy kiểm thử không thành công 10 lần (theo mặc định) hoặc cho đến khi lượt kiểm thử.
    atest test-to-run --retry-any-failure
    
  • Dừng chạy kiểm thử không thành công khi vượt qua hoặc đế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 kiểm thử trên một AVD mới tạo. Chạy acloud create để tạo AVD và cấu phần phần mềm bản dựng, hãy sử dụng các ví dụ sau để chạy kiểm thử.

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

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

Khởi động AVD trong lần 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 vào mô-đun

Atest có thể truyền các tuỳ chọn đến các mô-đun kiểm thử. Để thêm dòng lệnh TradeFed cho 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 tuỳ chỉnh đối số tuân theo định dạng tuỳ chọn dòng lệnh Tradefeed.

atest test-to-run -- [CUSTOM_ARGS]

Truyền các tuỳ chọn mô-đun kiểm thử để nhắm mục tiêu đến người chuẩn bị hoặc người chạy kiểm thử đượ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

Truyền các tuỳ chọn cho 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 thử nghiệm, hãy xem Truyền các tuỳ chọn tới các mô-đun.