Đây là giới thiệu ngắn gọn về liên kết thử nghiệm và giải thích cách nhận bắt đầu định cấu hình kiểm thử trong Dự án nguồn mở Android (AOSP).
Giới thiệu về tính năng liên kết kiểm thử
Liên kết kiểm thử là một phương pháp dựa trên Gerrit cho phép nhà phát triển tạo trước khi gửi
và đăng các quy tắc kiểm thử sau khi gửi trực tiếp trong cây nguồn Android và để lại
các quyết định về nhánh và thiết bị để kiểm tra cơ sở hạ tầng kiểm thử.
Định nghĩa ánh xạ kiểm thử là các tệp JSON có tên TEST_MAPPING mà bạn có thể đặt vào bất kỳ thư mục nguồn nào.
Atest có thể sử dụng các tệp TEST_MAPPING để chạy các kiểm thử trước khi gửi trong các thư mục liên kết. Với liên kết thử nghiệm, bạn có thể thêm cùng một nhóm thử nghiệm vào
các bước kiểm tra trước khi gửi với một thay đổi nhỏ bên trong cây nguồn Android.
Xem các ví dụ sau:
Thêm thử nghiệm trước khi gửi vào
TEST_MAPPINGchoservices.coreThêm các bài kiểm thử trước khi gửi vào
TEST_MAPPINGchotools/dexterbằng cách sử dụng lệnh nhập
Việc liên kết kiểm thử dựa vào bộ kiểm thử Liên minh thương mại (TF) để thực thi kiểm thử và báo cáo kết quả.
Xác định nhóm kiểm thử
Kiểm thử các nhóm ánh xạ bằng nhóm kiểm thử. Tên của nhóm thử nghiệm có thể là bất kỳ chuỗi nào. Ví dụ: Bạn có thể đặt tên gửi lại cho một nhóm thử nghiệm để sẽ chạy khi xác thực các thay đổi. Và postsubmit có thể là các kiểm thử dùng để xác thực các bản dựng sau khi hợp nhất các thay đổi.
Quy tắc tập lệnh tạo gói
Để bộ kiểm thử Liên minh thương mại chạy các mô-đun kiểm thử cho một bản dựng nhất định, các mô-đun này phải có một test_suites được đặt cho Soong hoặc một LOCAL_COMPATIBILITY_SUITE được đặt cho Make thành một trong hai bộ sau:
general-testsdành cho các thử nghiệm không phụ thuộc vào thiết bị cụ thể các khả năng (chẳng hạn như phần cứng dành riêng cho nhà cung cấp mà hầu hết thiết bị không có có). Hầu hết các kiểm thử đều phải nằm trong bộ công cụgeneral-tests, ngay cả khi chúng là dành riêng cho một ABI, bitness hoặc tính năng phần cứng như HWASan (có mục tiêutest_suitesriêng biệt cho mỗi ABI) và ngay cả khi chúng phải chạy trên một thiết bị.device-testsdùng cho các chương trình kiểm thử phụ thuộc vào các chức năng dành riêng cho thiết bị. Thông thường, bạn có thể tìm thấy các chương trình kiểm thử này trongvendor/. Dành riêng cho từng thiết bị chỉ đề cập đến những tính năng dành riêng cho một thiết bị, nên điều này áp dụng cho thử nghiệm JUnit cũng như thử nghiệm GTest (thường được đánh dấu làgeneral-testsngay cả khi các ứng dụ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 kiểm thử để chạy trong một bộ kiểm thử
Để chạy bên trong một bộ kiểm thử, kiểm thử phải:
- Không được có nhà cung cấp bản dựng nào.
- Phải dọn dẹp sau khi hoàn tất, chẳng hạn như bằng cách xoá mọi tệp được tạo trong quá trình kiểm thử.
- Phải thay đổi chế độ cài đặt hệ thống thành giá trị mặc định hoặc ban đầu.
Không nên giả định thiết bị đang ở một trạng thái nhất định, chẳng hạn như đã sẵn sàng cho quyền truy cập thư mục gốc. Hầu hết các chương trình kiểm thử đều không yêu cầu đặc quyền gốc để chạy. Nếu một bài kiểm thử phải yêu cầu gốc, nó phải chỉ định rằng với
RootTargetPreparertrongAndroidTest.xmlthân mến! như trong ví dụ sau:<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
Tạo tệp ánh xạ kiểm thử
Đối với thư mục cần phạm vi kiểm thử, hãy thêm tệp JSON TEST_MAPPING
tương tự như ví dụ. Những quy tắc này đảm bảo rằng các thử nghiệm sẽ chạy trong
kiểm tra trước khi gửi 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.
Làm theo một ví dụ
Dưới đây là tệp TEST_MAPPING mẫu (ở định dạng JSON nhưng có nhận xét
được hỗ trợ):
{
"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": "CtsDeqpTestCases",
"options": [
{
// Use regex in include-filter which is supported in AndroidJUnitTest
"include-filter": "dEQP-EGL.functional.color_clears.*"
}
]
}
],
"imports": [
{
"path": "frameworks/base/services/core/java/com/android/server/am"
}
]
}
Đặt thuộc tính
Trong ví dụ, presubmit và postsubmit là tên của mỗi biến
nhóm thử nghiệm. Xem bài viết Xác định nhóm thử nghiệm để biết thêm thông tin
về nhóm thử nghiệm.
Bạn có thể đặt tên của mô-đun kiểm thử hoặc tên kiểm thử tích hợp của Liên minh thương mại (ví dụ: đường dẫn tài nguyên đến tệp XML kiểm thử, uiautomator/uiautomator-demo) trong giá trị của thuộc tính name. Xin lưu ý rằng trường name không thể sử dụng lớp name hoặc phương thức kiểm thử name. Để thu hẹp các bài kiểm thử cần chạy, hãy sử dụng các tuỳ chọn như include-filter. Xem cách sử dụng mẫu include-filter.
Chế độ cài đặt host của một kiểm thử cho biết liệu kiểm thử đó có phải là kiểm thử 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à bài kiểm thử
cần có một thiết bị để chạy. Sau đây là các loại kiểm thử được hỗ trợ
HostGTest cho
Tệp nhị phân GTest và HostTest cho JUnit
kiểm thử.
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 đường dẫn tương đối của mọi tệp mã nguồn (tương đối so với
thư mục chứa tệp TEST_MAPPING). Trong ví dụ, quy trình kiểm thử CtsWindowManagerDeviceTestCases chỉ chạy ở chế độ gửi trước khi một tệp Java bắt đầu bằng Window hoặc Activity, tồn tại trong cùng thư mục với tệp TEST_MAPPING hoặc bất kỳ thư mục con nào của tệp đó. Bạn cần phải thoát dấu gạch chéo ngược (\) vì chúng nằm trong tệp JSON.
Thuộc tính imports cho phép bạn đưa các bài kiểm thử vào các tệp TEST_MAPPING khác
mà không sao chép nội dung. Các tệp TEST_MAPPING trong thư mục mẹ của đường dẫn đã nhập cũng được đưa vào. Tính năng ánh xạ kiểm thử cho phép nhập lồng nhau; nghĩa là hai tệp TEST_MAPPING có thể nhập lẫn nhau và tính năng ánh xạ kiểm thử có thể hợp nhất các kiểm thử được đưa vào.
Thuộc tính options chứa các tuỳ chọn dòng lệnh Tradefeed bổ sung.
Để xem danh sách đầy đủ các tuỳ chọn có sẵn cho một kiểm thử nhất định, hãy chạy:
tradefed.sh run commandAndExit [test_module] --help
Tham khảo Xử lý quyền chọn trong Tradefeed để biết thêm chi tiết về cách hoạt động của các tuỳ chọn.
Chạy kiểm thử bằng Atest
Để thực thi cục bộ quy tắc kiểm thử trước khi gửi:
- 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 thử trước khi gửi được định cấu hình trong các tệp TEST_MAPPING của thư mục hiện tại và các thư mục mẹ của thư mục đó sẽ được chạy. Atest sẽ tìm và chạy hai chương trình kiểm thử trước khi gửi (A và B).
Đây là cách đơn giản nhất để chạy bài kiểm thử trước khi gửi trong TEST_MAPPING
trong thư mục đang làm việc (CWD) và thư mục mẹ. Atest
tìm và sử dụng tệp TEST_MAPPING trong CWD và tất cả tệp mẹ của nó
.
Mã nguồn cấu trúc
Ví dụ này cho thấy cách bạn có thể định cấu hình các tệp TEST_MAPPING 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 một thư mục mục tiêu để chạy kiểm thử trong các tệp TEST_MAPPING trong thư mục đó. Lệnh sau đây chạy hai kiểm thử (A, B):
atest --test-mapping src/project_1
Chạy quy tắc kiểm thử sau khi gửi
Bạn cũng có thể sử dụng lệnh này để chạy các quy tắc kiểm thử sau khi gử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 quy tắc đó:
atest [--test-mapping] [src_path]:postsubmit
Chỉ chạy những chương trình kiểm thử không cần thiết bị
Bạn có thể sử dụng tuỳ chọn --host cho Atest để chỉ chạy những chương trình kiểm thử được định cấu hình
đối với máy chủ không yêu cầu thiết bị. Nếu không có tuỳ chọn này, Atest sẽ chạy cả hai quy trình kiểm thử, những quy trình kiểm thử yêu cầu thiết bị và những quy trình kiểm thử chạy trên máy chủ không yêu cầu thiết bị. Các bài kiểm thử này được chạy trong 2 bộ riêng biệt:
atest [--test-mapping] --host
Xác định nhóm thử nghiệm
Bạn có thể chỉ định các nhóm kiểm thử trong lệnh Atest. Lệnh sau đây sẽ chạy
tất cả hoạt động kiểm thử postsubmit liên quan đến tệp trong thư mục src/project_1
chỉ chứa một phép kiểm thử (C).
Hoặc bạn có thể sử dụng :all để chạy tất cả các bài kiểm thử bất kể nhóm. Lệnh sau đây sẽ chạy 4 chương trình kiểm thử (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 kiểm thử trong TEST_MAPPING bằng Atest chỉ chạy các kiểm thử trước khi gửi được định cấu hình trong tệp TEST_MAPPING trong CWD (hoặc thư mục đã cho) và các thư mục mẹ của tệp đó. Nếu bạn muốn chạy kiểm thử trong tất cả tệp TEST_MAPPING trong các thư mục con, hãy sử dụng tuỳ chọn --include-subdir để buộc Atest đưa cả các kiểm thử đó vào.
atest --include-subdir
Nếu không có tuỳ chọn --include-subdir, Atest sẽ chỉ chạy kiểm thử A. Với
--include-subdir, Atest chạy hai kiểm thử (A, B).
Hỗ trợ nhận xét ở cấp dòng
Bạn có thể thêm nhận xét định dạng // cấp dòng để làm rõ tệp TEST_MAPPING bằng nội dung mô tả chế độ cài đặt theo sau.
ATest và Liên đoàn Thương mại
xử lý trước TEST_MAPPING sang định dạng JSON hợp lệ mà không cần nhận xét. Để giữ cho tệp JSON luôn gọn gàng, chỉ hỗ trợ nhận xét định dạng // cấp dòng.
Ví dụ:
{
// For presubmit test group.
"presubmit": [
{
// Run test on module A.
"name": "A"
}
]
}