Google is committed to advancing racial equity for Black communities. See how.
Trang này được dịch bởi Cloud Translation API.
Switch to English

Bài kiểm tra

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 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 Trade Federation . 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á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 xem 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 .

Và để thêm một tính năng vào Atest, hãy làm theo Atest Developer Workflow .

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

Để chạy Atest, hãy làm theo các bước trong phần bên dưới để thiết lập môi trường của bạn.

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

Đặt test_suite cho Soong hoặc LOCAL_COMPATIBILITY_SUITE cho các quy tắc tập lệnh xây dựng Make per Packaging .

1. Chạy envsetup.sh

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

source build/envsetup.sh

2. Chạy trưa

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 [optional-arguments] test-to-run

Đối số tùy chọn

Bạn có thể sử dụng các đối số tùy chọn sau với lệnh Atest.

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.
-i --install Cài đặt phần mềm thử nghiệm (APK) trên thiết bị.
-t --test Chạy các bài kiểm tra.
-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 Vô hiệu hóa việc chia nhỏ thử nghiệm và dọn dẹp.
--info Hiển thị thông tin liên quan về các mục tiêu và lối thoát được chỉ định.
--dry-run Từ đồng nghĩa của --info.
-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 trước khi thực thi. Chỉ dành cho các bài kiểm tra thiết bị.
-v --verbose Hiển thị ghi nhật ký mức GỠ NỢ.
--generate-baseline Tạo chỉ số cơ sở, chạy 5 lần lặp lại theo mặc định.
--generate-new-metrics Tạo chỉ số mới, chạy 5 lần lặp lại theo mặc định.
--detect-regression Chạy thuật toán phát hiện hồi quy.
--[CUSTOM_ARGS] Chỉ định args 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.
-h --help Hiển thị thông báo trợ giúp và các lần thoát.
--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.)

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

Kiểm tra để chạy

Bạn có thể chạy một hoặc nhiều thử nghiệm bằng cách sử dụng test-to-run . Để chạy nhiều thử nghiệm, hãy tách các tham chiếu thử nghiệm bằng dấu cách. Ví dụ:

atest test-to-run-1 test-to-run-2

Dưới đây là một số ví dụ:

atest FrameworksServicesTests
atest example/reboot
atest FrameworksServicesTests CtsJankDeviceTestCases
atest FrameworksServicesTests:ScreenDecorWindowTests

Để biết thêm thông tin về cách tham chiếu một bài kiểm tra, hãy xem Nhận dạng bài kiểm tra.

Kiểm tra xác định

Bạn có thể chỉ định đối số test-to-run với tên mô-đun của thử nghiệm, Mô-đun: Lớp, tên lớp, kiểm tra tích hợp TF, đường dẫn tệp hoặc tên gói.

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 khi tên xuất hiện trong các LOCAL_MODULE hoặc LOCAL_PACKAGE_NAME trong tệp Android.bp hoặc Android.mk của thử nghiệm đó.

Ví dụ:

atest FrameworksServicesTests
atest CtsJankDeviceTestCases

Mô-đun: Lớp

Để chạy một lớp 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 FrameworksServicesTests:ScreenDecorWindowTests
atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests
atest CtsJankDeviceTestCases:CtsDeviceJankUi

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 CtsDeviceJankUi

Sử dụng Mô-đun: Nên tham chiếu lớp bất cứ khi nào có thể vì Atest cần thêm thời gian để tìm kiếm cây nguồn hoàn chỉnh cho các kết quả phù hợp tiềm năng nếu không có mô-đun nào được nêu.

Ví dụ (thứ tự từ nhanh nhất đến chậm nhất):

atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests
atest FrameworksServicesTests:ScreenDecorWindowTests
atest ScreenDecorWindowTests

Kiểm tra tích hợp TF

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

Bạn có thể 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. Bạn cũng có thể 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ợ.

Ví dụ: Hai cách để chạy mô-đun CtsJankDeviceTestCases qua đường dẫn

  1. Chạy mô-đun từ repo-root android:

    atest cts/tests/jank
    
  2. Từ android repo-root / cts / tests / jank:

    atest .
    

Ví dụ: Chạy một lớp cụ thể trong mô-đun CtsJankDeviceTestCases qua đường dẫn. Từ repo-root android:

atest cts/tests/jank/src/android/jank/cts/ui/CtsDeviceJankUi.java

Ví dụ: Chạy kiểm tra tích hợp qua đường dẫn. Từ repo-root android:

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

Tên gói hàng

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

Ví dụ:

atest com.android.server.wm
atest android.jank.cts

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

Bạn có thể chỉ định các bước cần chạy bằng cách sử dụng các tùy chọn -b , -i-t . 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 một bài kiểm tra bỏ qua bước dọn dẹp / 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 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 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ể

Bạn có thể 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 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

Bạn có thể chỉ định nhiều 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 cho thấy các cách ưa thích để chạy một phương thức duy nhất, testFlagChange . Các 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 kiểm tra nhanh hơn nhiều:

  1. Sử dụng mô-đun: Lớp

    atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange
    
  2. Từ repo-root android

    atest frameworks/base/services/tests/servicestests/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á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.

Ví dụ:

  • Hai lớp trong cùng một mô-đun:

    atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests
    
  • Hai lớp trong các mô-đun khác nhau:

    atest FrameworksServicesTests:ScreenDecorWindowTests CtsJankDeviceTestCases:CtsDeviceJankUi
    

Chạy thử nghiệm gốc

Atest có thể chạy thử nghiệm gốc.

Ví dụ:

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

    atest -a libinput_tests inputflinger_tests
    

Sử dụng -a để 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, trong ví dụ này là armeabi-v7a (ARM 32-bit) và arm64-v8a (ARM 64-bit).

Để chọn một thử nghiệm gốc 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 pháp riêng lẻ. Ví dụ: đối với định nghĩa kiểm tra sau:

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

Bạn có thể chạy toàn bộ thử nghiệm bằng

atest inputflinger_tests:InputDispatcherTest

hoặc một phương pháp kiểm tra riêng lẻ sử dụng

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Phát hiện hồi quy số liệu

Bạn có thể tạo các chỉ số trước hoặc sau bản vá mà không cần chạy tính năng phát hiện hồi quy. Bạn có thể chỉ định số lần lặp, nhưng mặc định là năm.

Ví dụ:

atest test-to-run --generate-baseline [optional-iteration]
atest test-to-run --generate-new-metrics [optional-iteration]

Phát hiện hồi quy cục bộ có thể được chạy trong ba tùy chọn:

  1. Tạo chỉ số cơ sở (bản vá trước) và đặt chúng vào một thư mục. Atest chạy các bài kiểm tra thông qua các lần lặp được chỉ định, tạo các chỉ số sau bản vá và so sánh các chỉ số đó với các chỉ số hiện có.

    Thí dụ:

    atest test-to-run --detect-regression /path/to/baseline --generate-new-metrics [optional-iteration]
    
  2. Sử dụng thư mục chứa các chỉ số sau bản vá đã tạo trước đó, Atest chạy thử nghiệm n lần lặp lại, tạo một tập hợp các chỉ số trước bản vá mới và so sánh những chỉ số đó với những chỉ số được cung cấp.

    Thí dụ:

    atest test-to-run --detect-regression /path/to/new --generate-baseline [optional-iteration]
    
  3. Sử dụng hai thư mục chứa cả chỉ số trước và sau bản vá, Atest chạy thuật toán phát hiện hồi quy mà không cần bất kỳ thử nghiệm nào.

    Thí dụ:

    atest --detect-regression /path/to/baseline /path/to/new