Đây là phần giới thiệu ngắn gọn về ánh xạ thử nghiệm và giải thích cách bắt đầu định cấu hình thử nghiệm một cách dễ dàng trong Dự án mã nguồn mở Android (AOSP).
Giới thiệu về bản đồ thử nghiệm
Ánh xạ thử nghiệm là một phương pháp tiếp cận dựa trên Gerrit cho phép các nhà phát triển tạo các quy tắc thử nghiệm trước và sau gửi trực tiếp trong cây nguồn Android và để chính cơ sở hạ tầng thử nghiệm đưa ra quyết định của các nhánh và thiết bị. Định nghĩa ánh xạ thử nghiệm là các tệp JSON có tên TEST_MAPPING có thể được đặt trong bất kỳ thư mục nguồn nào.
Atest có thể sử dụng tệp TEST_MAPPING để chạy thử nghiệm gửi trước trong các thư mục được liên kết. Với ánh xạ thử nghiệm, bạn có thể thêm cùng một bộ thử nghiệm để gửi trước các bản kiểm tra bằng một thay đổi đơn giản bên trong cây nguồn Android.
Xem những ví dụ sau:
Thêm bài kiểm tra gửi trước vào TEST_MAPPING cho services.core
Ánh xạ thử nghiệm dựa trên Khai thác thử nghiệm của Liên đoàn Thương mại (TF) để thực hiện thử nghiệm và báo cáo kết quả.
Xác định nhóm thử nghiệm
Kiểm tra các nhóm lập bản đồ kiểm tra thông qua một nhóm kiểm tra . Tên của nhóm thử nghiệm có thể là bất kỳ chuỗi nào. Ví dụ: gửi trước có thể để một nhóm thử nghiệm chạy khi xác thực các thay đổi. Và các bài kiểm tra sau khi gửi có thể được sử dụng để xác thực các bản dựng sau khi các thay đổi được hợp nhất.
Quy tắc tập lệnh xây dựng gói
Để Bộ khai thác thử nghiệm của Liên đoàn thương mại chạy các mô-đun thử nghiệm của ánh xạ thử nghiệm cho một bản dựng nhất định, các mô-đun này phải được đặt test_suite cho Soong hoặc LOCAL_COMPATIBILITY_SUITE được đặt cho Make thành một trong hai bộ sau:
- kiểm tra chung - kiểm tra không phụ thuộc vào chức năng dành riêng cho thiết bị (chẳng hạn như phần cứng dành riêng cho nhà cung cấp mà hầu hết các thiết bị không có). Hầu hết các thử nghiệm phải nằm trong bộ thử nghiệm chung, ngay cả khi chúng dành riêng cho một ABI hoặc bitness hoặc các tính năng phần cứng như HWASan (có mục tiêu test_suites riêng cho từng ABI) và ngay cả khi chúng phải chạy trên một thiết bị.
- kiểm tra thiết bị - kiểm tra phụ thuộc vào chức năng dành riêng cho thiết bị. Thông thường, các thử nghiệm này sẽ được tìm thấy trong
vendor/. Bởi vì "dành riêng cho thiết bị" không đề cập đến chức năng ABI hoặc SoC mà các thiết bị khác có thể có hoặc có thể không có mà chỉ đề cập đến chức năng dành riêng cho một thiết bị, điều này áp dụng cho các bài kiểm tra JUnit nhiều như các bài kiểm tra gốc GTest (thường phải làgeneral-testsngay cả khi chúng dành riêng cho ABI).
Ví dụ:
Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests
Định cấu hình các thử nghiệm để chạy trong bộ thử nghiệm
Để chạy thử nghiệm bên trong bộ thử nghiệm, thử nghiệm này:
- không được có bất kỳ nhà cung cấp bản dựng nào.
- phải dọn dẹp sau khi hoàn thành, chẳng hạn như bằng cách xóa mọi tệp tạm thời được tạo trong quá trình kiểm tra.
- thay đổi cài đặt hệ thống thành giá trị mặc định hoặc giá trị gốc.
- không nên giả sử thiết bị ở trạng thái nhất định, ví dụ: đã sẵn sàng root. Hầu hết các thử nghiệm không yêu cầu quyền root để chạy. Nếu một thử nghiệm phải yêu cầu root thì nó phải chỉ định điều đó với
RootTargetPreparertrongAndroidTest.xmlcủa nó, như trong ví dụ sau:
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
Tạo tập tin ánh xạ thử nghiệm
Đối với thư mục yêu cầu phạm vi kiểm tra, chỉ cần thêm tệp JSON TEST_MAPPING giống như ví dụ bên dưới. Các quy tắc này sẽ đảm bảo các bài kiểm tra chạy trong quá trình kiểm tra gửi trước khi có bất kỳ tệp nào được chạm vào trong thư mục đó hoặc bất kỳ thư mục con nào của nó.
Làm theo một ví dụ
Đây là tệp TEST_MAPPING mẫu (có định dạng JSON nhưng có hỗ trợ nhận xét):
{
"presubmit": [
// JUnit test with options and file patterns.
{
"name": "CtsWindowManagerDeviceTestCases",
"options": [
{
"include-annotation": "android.platform.test.annotations.RequiresDevice"
}
],
"file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
},
// Device-side GTest with options.
{
"name" : "hello_world_test",
"options": [
{
"native-test-flag": "\"servicename1 servicename2\""
},
{
"native-test-timeout": "6000"
}
]
}
// Host-side GTest.
{
"name" : "net_test_avrcp",
"host" : true
}
],
"postsubmit": [
{
"name": "CtsWindowManagerDeviceTestCases"
}
],
"imports": [
{
"path": "frameworks/base/services/core/java/com/android/server/am"
}
]
}
Đặt thuộc tính
Trong ví dụ trên, presubmit và postsubmit là tên của từng nhóm thử nghiệm . Xem Xác định nhóm kiểm tra để biết thêm thông tin về các nhóm kiểm tra.
Tên của mô-đun thử nghiệm hoặc tên thử nghiệm tích hợp Liên đoàn Thương mại (đường dẫn tài nguyên tới tệp XML thử nghiệm, ví dụ: uiautomator/uiautomator-demo ) có thể được đặt trong giá trị của thuộc tính name . Lưu ý trường tên không thể sử dụng name lớp hoặc name phương thức kiểm tra. Để thu hẹp các thử nghiệm cần chạy, bạn có thể sử dụng các tùy chọn như include-filter tại đây. Xem ( sử dụng mẫu bao gồm bộ lọc ).
Cài đặt máy chủ của bài kiểm tra cho biết bài kiểm tra có phải là bài kiểm tra không cần thiết bị chạy trên máy chủ hay không. Giá trị mặc định là false , nghĩa là thử nghiệm yêu cầu thiết bị chạy. Các loại thử nghiệm được hỗ trợ là HostGTest cho các tệp nhị phân GTest và HostTest cho các thử nghiệm JUnit.
Thuộc tính file_patterns cho phép bạn thiết lập danh sách các chuỗi biểu thức chính quy để khớp với đường dẫn tương đối của bất kỳ tệp mã nguồn nào (liên quan đến thư mục chứa tệp TEST_MAPPING). Trong ví dụ trên, test CtsWindowManagerDeviceTestCases sẽ chỉ chạy trong chế độ gửi trước khi bất kỳ tệp java nào bắt đầu bằng Window hoặc Hoạt động, tồn tại trong cùng thư mục của tệp TEST_MAPPING hoặc bất kỳ thư mục con nào của nó, bị thay đổi. Dấu gạch chéo ngược \ cần phải được thoát vì chúng nằm trong tệp JSON.
Thuộc tính nhập cho phép bạn đưa các bài kiểm tra vào các tệp TEST_MAPPING khác mà không cần sao chép nội dung. Lưu ý rằng các tệp TEST_MAPPING trong thư mục mẹ của đường dẫn đã nhập cũng sẽ được đưa vào. Kiểm tra ánh xạ cho phép nhập lồng nhau; điều này có nghĩa là hai tệp TEST_MAPPING có thể nhập lẫn nhau và Ánh xạ thử nghiệm có thể hợp nhất chính xác các thử nghiệm đi kèm.
Thuộc tính tùy chọn chứa các tùy chọn dòng lệnh TradeFed bổ sung.
Để có danh sách đầy đủ các tùy chọn có sẵn cho một bài kiểm tra nhất định, hãy chạy:
tradefed.sh run commandAndExit [test_module] --help
Tham khảo Xử lý tùy chọn TradeFed để biết thêm chi tiết về cách hoạt động của các tùy chọn.
Chạy thử nghiệm với Atest
Để thực thi các quy tắc kiểm tra gửi trước cục bộ:
- Chuyển đến thư mục chứa tệp TEST_MAPPING.
- Chạy lệnh:
atest
Tất cả các bài kiểm tra gửi trước được định cấu hình trong tệp TEST_MAPPING của thư mục hiện tại và thư mục mẹ của nó đều được chạy. Atest sẽ xác định và chạy hai bài kiểm tra để gửi trước (A và B).
Đây là cách đơn giản nhất để chạy thử nghiệm gửi trước trong tệp TEST_MAPPING trong thư mục làm việc hiện tại (CWD) và thư mục mẹ. Atest sẽ định vị và sử dụng tệp TEST_MAPPING trong CWD và tất cả các thư mục mẹ của nó.
Mã nguồn cấu trúc
Ví dụ sau đây cho thấy cách các tệp TEST_MAPPING có thể được định cấu hình trên cây nguồn.
src
├── project_1
│ └── TEST_MAPPING
├── project_2
│ └── TEST_MAPPING
└── TEST_MAPPING
Nội dung của src/TEST_MAPPING :
{
"presubmit": [
{
"name": "A"
}
]
}
Nội dung của src/project_1/TEST_MAPPING :
{
"presubmit": [
{
"name": "B"
}
],
"postsubmit": [
{
"name": "C"
}
],
"other_group": [
{
"name": "X"
}
]}
Nội dung của src/project_2/TEST_MAPPING :
{
"presubmit": [
{
"name": "D"
}
],
"import": [
{
"path": "src/project_1"
}
]}
Chỉ định thư mục đích
Bạn có thể chỉ định thư mục đích để chạy thử nghiệm trong tệp TEST_MAPPING trong thư mục đó. Lệnh sau sẽ chạy hai bài kiểm tra (A, B).
atest --test-mapping src/project_1
Chạy quy tắc kiểm tra gửi sau
Bạn cũng có thể sử dụng lệnh này để chạy các quy tắc kiểm tra gửi bài được xác định trong TEST_MAPPING trong src_path (mặc định là CWD) và các thư mục mẹ của nó:
atest [--test-mapping] [src_path]:postsubmit
Chỉ chạy các bài kiểm tra không cần thiết bị
Bạn có thể sử dụng tùy chọn --host để Atest chỉ chạy thử nghiệm được định cấu hình trên máy chủ không yêu cầu thiết bị. Nếu không có tùy chọn này, Atest sẽ chạy cả hai thử nghiệm, thử nghiệm yêu cầu thiết bị và thử nghiệm chạy trên máy chủ và không yêu cầu thiết bị. Các bài kiểm tra sẽ được thực hiện trong hai dãy phòng riêng biệt.
atest [--test-mapping] --host
Xác định các nhóm kiểm tra
Bạn có thể chỉ định các nhóm thử nghiệm trong lệnh Atest. Lệnh sau sẽ chạy tất cả các bài kiểm tra postsubmit liên quan đến các tệp trong thư mục src/project_1, chỉ chứa một bài kiểm tra (C).
Hoặc bạn có thể sử dụng :all để chạy tất cả các bài kiểm tra bất kể nhóm nào. Lệnh sau chạy bốn bài kiểm tra (A, B, C, X):
atest --test-mapping src/project_1:all
Bao gồm các thư mục con
Theo mặc định, việc chạy thử nghiệm trong TEST_MAPPING bằng Atest sẽ chỉ chạy các thử nghiệm gửi trước được định cấu hình trong tệp TEST_MAPPING trong CWD (hoặc thư mục nhất định) và các thư mục mẹ của nó. Nếu bạn muốn chạy thử nghiệm trong tất cả các tệp TEST_MAPPING trong thư mục con, hãy sử dụng tùy chọn --include-subdir để buộc Atest cũng bao gồm các thử nghiệm đó.
atest --include-subdir
Nếu không có tùy chọn --include-subdir , Atest sẽ chỉ chạy thử nghiệm A. Với tùy chọn --include-subdir , Atest sẽ chạy hai thử nghiệm (A, B).
Nhận xét cấp dòng được hỗ trợ
Bạn có thể thêm nhận xét định dạng // - cấp dòng để bổ sung thêm cho tệp TEST_MAPPING với mô tả về cài đặt sau. ATest và Liên đoàn Thương mại sẽ xử lý trước TEST_MAPPING thành định dạng JSON hợp lệ mà không cần nhận xét. Để giữ cho tệp JSON sạch sẽ và dễ đọc, chỉ hỗ trợ nhận xét // -format cấp dòng.
Ví dụ:
{
// For presubmit test group.
"presubmit": [
{
// Run test on module A.
"name": "A"
}
]
}