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.

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 thử nghiệm Android tại địa phương, rất nhiều tăng tốc kiểm tra lại chạy mà không đòi hỏi kiến thức về Liên đoàn Triển khai thác thử nghiệm tùy chọn dòng lệnh. 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ề viết bài kiểm tra dành cho Android, xem nền tảng Android Testing .

Để biết thông tin về cấu trúc tổng thể của Atest, xem Atest Developer Guide .

Để biết thông tin về chạy thử nghiệm trong các tập tin TEST_MAPPING qua Atest, xem Chạy thử nghiệm trong các tập tin TEST_MAPPING .

Và để thêm một tính năng để 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 các 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

Set test_suite cho Soong hoặc LOCAL_COMPATIBILITY_SUITE cho Make mỗi Bao bì nguyên tắc xây dựng kịch bản .

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

Chạy trưa

Chạy lunch lệnh để đưa ra một danh mục các thiết bị 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 cho chạy Atest và thêm lệnh Atest để bạn $PATH .

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

Dưới đây là 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. (vỡ nợ)
-i --install Cài đặt phần mềm thử nghiệm (APK) trên thiết bị. (vỡ nợ)
-t --test Chạy các bài kiểm tra. (vỡ nợ)
-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.
--info Hiển thị thông tin liên quan về các mục tiêu và số lần thoát được chỉ định.
--dry-run Chạy khô ít nhất mà không cần xây dựng, cài đặt và chạy thử nghiệm trong thực tế
-m --rebuild-module-info Lực lượng xây dựng lại các module-info.json tập tin.
-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ị đo đạc.
-v --verbose Hiển thị ghi nhật ký mức NỢ.
--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)
--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)
--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)
--start-avd Tự động tạo AVD và chạy thử nghiệm trên thiết bị ảo.
--acloud-create Tạo AVDs bằng cách sử dụng acloud command.
--[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.
--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 một thử nghiệm máy chủ đòi hỏi một thiết bị với --host sẽ thất bại.)
--flakes-info Hiển thị kết quả thử nghiệm với thông tin mảnh.
--history Hiển thị kết quả thử nghiệm theo thứ tự thời gian.
--latest-result In kết quả thử nghiệm mới nhất.

Để biết thêm thông tin về -b , -i-t , xem Xác định bước sau: 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 xét nghiệm 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 CtsVideoTestCases
atest FrameworksServicesTests:ScreenDecorWindowTests

Để biết thêm thông tin về làm thế nào để tham khảo một kiểm tra, xem Xác định kiểm tra.

Xác định các bài kiểm tra

Bạn có thể chỉ định các test-to-run tranh cãi với tên của thử nghiệm module, Module: Class, tên lớp, kiểm tra tích hợp TF, đường dẫn tập tin 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 như nó xuất hiện trong LOCAL_MODULE hoặc LOCAL_PACKAGE_NAME biến trong của bài kiểm tra đó Android.mk hoặc Android.bp tập tin.

Ví dụ:

atest FrameworksServicesTests
atest CtsVideoTestCases

Mô-đun: Lớp

Để chạy một lớp duy nhất trong một module, sử dụng Module: Class. Module này là giống như được mô tả trong tên mô-đun . Lớp là tên của lớp thử nghiệm trong .java tập tin và có thể là tên lớp đầy đủ hoặc tên cơ bản.

Ví dụ:

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

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

Sử dụng Module: tài liệu tham khảo lớp được khuyến khích bất cứ khi nào có thể từ Atest đòi hỏi nhiều thời gian để tìm kiếm trên cây nguồn đầy đủ cho trận đấu tiềm năng nếu không có mô-đun được ghi.

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 thử nghiệm đã được tích hợp trực tiếp vào TradeFed (không mô-đun), nhập vào tên như nó xuất hiện trong đầu ra của các tradefed.sh list configs lệnh. Ví dụ:

Để chạy reboot.xml kiểm tra :

atest example/reboot

Để chạy các native-benchmark.xml kiểm tra :

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 của chúng 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ụ: Có hai cách để chạy CtsVideoTestCases mô-đun thông qua đường dẫn

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

    atest cts/tests/video
    
  2. Từ Android repo-root / cts / kiểm tra / video:

    atest .
    

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

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

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

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 com.android.uibench.janktests

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 để chạy bằng -b , -i , và -t tùy chọn. 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.

  • Mục tiêu xây dựng chỉ: atest -b test-to-run
  • Chạy thử nghiệm chỉ: atest -t test-to-run
  • Cài đặt gói ứng dụng và thử nghiệm chạy: 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, sạch thiết bị sau khi các thử nghiệm được chạy, vì vậy cố gắng chạy lại thử nghiệm của bạn với -t sẽ thất bại nếu không có sự --disable-teardown tham số. Sử dụng -d trước -t để bỏ qua các bài kiểm tra sạch sẽ bước lên và thử nghiệm 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 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 những 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 kiểm tra nhanh hơn nhiều:

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

    atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange
    
  2. Từ 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ể đượ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.

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 CtsVideoTestCases:VideoEncoderDecoderTest
    

Chạy thử nghiệm gốc

Atest có thể chạy thử nghiệm gốc. Sử dụng -a để chạy thử nghiệm cho tất cả các kiến trúc thiết bị có sẵn, mà 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 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 các định nghĩa thử nghiệm sau đây:

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

Bạn có thể chạy toàn bộ bài kiểm tra sử dụng

atest inputflinger_tests:InputDispatcherTest

hoặc một phương pháp thử nghiệm cá nhân sử dụng

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.

  1. Chạy thử nghiệm gửi trước hoàn toàn trong tệp TEST_MAPPING trong thư mục hiện tại, chính hoặc thư mục cụ thể.

    Kiểm tra presubmit chạy trong các tập tin trong thư mục hiện hành TEST_MAPPING và phụ huynh:

    atest
    

    Kiểm tra presubmit chạy trong các tập tin TEST_MAPPING trong /path/to/project và thư mục mẹ của nó:

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

  2. Chạy một nhóm thử nghiệm theo quy định tại TEST_MAPPING file; nhóm thử nghiệm có sẵn là: presubmit (mặc định), postsubmit , mainline-presubmitall .

    • Kiểm tra postsubmit chạy trong các tập tin trong thư mục hiện hành TEST_MAPPING và phụ huynh:

      atest :postsubmit
      

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

      atest :all
      

    • Kiểm tra postsubmit chạy trong các tập tin TEST_MAPPING trong /path/to/project và thư mục mẹ

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

    • Chạy thử nghiệm đường chính trong các tập tin TEST_MAPPING trong /path/to/project và thư mục mẹ

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

  3. Chạy thử nghiệm trong các tệp TEST_MAPPING bao gồm các thư mục con.

Theo mặc định, ít nhất chỉ tìm kiếm các bài kiểm tra trong các tệp TEST_MAPPING trở lên (từ tệp hiện tại hoặc được cung cấp cho các 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 tin TEST_MAPPING trong thư mục con, bạn có thể sử dụng tùy chọn --include-subdirs để buộc atest để bao gồm những xét nghiệm là tốt.

Kiểm tra presubmit chạy trong các tập tin TEST_MAPPING trong hiện tại, phụ huynh và thư mục con:

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

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

Để chạy thử nghiệm trong lần lặp, chỉ cần vượt qua --iterations tranh cãi. Cho dù nó đạt hay không thành công, ít nhất sẽ không ngừng thử nghiệm cho đến khi đạt đến số lần lặp tối đa.

Ví dụ:

Theo mặc định, ít nhất lặp lại 10 lần, cho một số nguyên để thay đổi vòng lặp.

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

Hai cách tiếp cận hỗ trợ người dùng phát hiện các bài kiểm tra không ổn định:

Phương pháp 1: Chạy 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.

  • Dừng lại 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 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ả test-to-run có năm trường hợp thử nghiệm và một trong các bài kiểm tra thất bại. Chỉ chạy thử nghiệm không thành công 10 lần 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 với AVD mới được tạo. Atest có thể xây dựng hiện vật cùng với chạy acloud create và chạy thử nghiệm sau khi AVD đã được tạo thành công.

Ví dụ:

  • Bắt đầu một AVD trước khi chạy thử nghiệm trên rằng thiết bị mới được tạo ra:

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

  • Bắt đầu bằng việc xác định AVDs acloud create lý luận và thử nghiệm chạy trên rằng thiết bị mới được tạo ra.

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

Để có được chi tiết việc sử dụng về lập luận, chạy acloud create --help .

Chuyển các tùy chọn đến mô-đun

Atest có thể chuyển các tùy chọn cho các mô-đun. Định dạng ngắn gọn trong dòng lệnh Atest thêm TradeFed tùy chọn dòng lệnh là

atest test-to-run -- [CUSTOM_ARGS]
các [CUSTOM_ARGS] nên làm theo các định dạng tùy chọn dòng lệnh Tradefed.

Ví dụ về việc chuyển các tùy chọn mô-đun thử nghiệm đến 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

Ví dụ về việc 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ề chỉ kiểm tra tùy chọn, xem tùy chọn Pass để các module