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ê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. 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 và -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

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

Lưu ý: Để chạy các chương trình kiểm thử không theo mô-đun được tích hợp vào TradeFed (TF), hãy sử dụng Tích hợp TF Hãy thử nghiệm làm giá trị nhận dạng.

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

Lưu ý: Để giảm thời gian cần thiết để Atest tìm được kết quả kiểm thử chính xác, bạn nên bằng cách dùng đường dẫn lớp đầy đủ như trong ví dụ trước.

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

Lưu ý: Để giảm thời gian cần thiết để Atest tìm được kết quả kiểm thử chính xác, bạn nên sử dụng Module:Class thay vì chỉ tên lớp bất cứ khi nào có thể.

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

Để 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 đó. Hỗ trợ cả đường dẫn tương đối và tuyệt đối.

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

atest cts/tests/video

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

    atest .

Chạy một 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 đườ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 và -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.

Lưu ý: -b và -t có thể chạy riêng lẻ, nhưng -i không thể chạy được nếu không có -t.

• 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

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

Lưu ý: Vì -t tắt cả tính năng thiết lập/cài đặt và gỡ bỏ/dọn dẹp thiết bị, bạn có thể chạy lại bài kiểm thử bằng atest -t test-to-run bao nhiêu lần tuỳ thích.

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 minh hoạ 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 quy trình kiểm thử 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 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 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 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

Lưu ý: Nếu bạn chỉ cần chạy kiểm thử cho một cấu trúc thiết bị cụ thể, hãy sử dụng atest -- --abi arm64-v8a hoặc atest -- --abi armeabi-v7a

Để 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 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 kiểm thử đã chỉ định

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

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 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 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. 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 đâ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 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 các trường hợp kiểm thử không thành công. Chỉ chạy chương trình 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.

Lưu ý: --acloud-create phải là đối số không bắt buộc LẦN NHẤT. Bất kỳ đối số nào tuân theo sẽ được coi là đối số vị trí cho AVD.

Lưu ý: --acloud-create và --start-avd không xoá các AVD mới tạo. Người dùng phải xoá những thông tin này theo cách thủ công.

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.