Bộ kiểm tra tính tương thích (CTS) với Android cung cấp hàng triệu bài kiểm thử riêng lẻ. Mặc dù cần thiết để chạy CTS thường xuyên trong giai đoạn phát triển phần mềm, nhưng bạn có thể rút ngắn thời gian cần thiết để chạy các kiểm thử này.
Trang này mô tả các phương pháp bạn có thể sử dụng để giảm thời gian thực thi kiểm thử và cách tối ưu hoá tài nguyên phần cứng trong quy trình.
Phân đoạn thiết bị
Để giảm thời gian chu kỳ, hãy cân nhắc việc chạy CTS trên nhiều thiết bị (phân đoạn). Để xem cách sử dụng tính năng phân đoạn, hãy xem phần Chạy kiểm thử CTS.
Giao diện kiểm thử Android
Sử dụng Trạm kiểm thử Android (ATS) để sử dụng giao diện người dùng nhằm chạy các bộ kiểm thử Android tiêu chuẩn. Công cụ này đóng vai trò là một giao diện web cho Trade Federation (TF), cho phép bạn chạy CTS mà không cần thiết lập nhiều trên một nhóm thiết bị kiểm thử, cũng như thiết lập lịch biểu để liên tục chạy các kiểm thử.
Trạm kiểm thử Android hỗ trợ Chế độ nhiều máy chủ, trong đó một máy chủ bộ điều khiển ATS có thể được dùng để quản lý các thiết bị và kiểm thử trên nhiều máy chủ ATS worker.
Trình mô phỏng chạy liên tục
Để chạy CTS liên tục trong giai đoạn phát triển, bạn có thể dùng Thiết bị Android ảo (AVD) thay cho phần cứng. Bạn có thể xác định sớm các trường hợp kiểm thử thất bại, giúp tiết kiệm nhiều thời gian cần thiết để phân loại và phân tích nguyên nhân gốc. Bạn có thể dùng nhiều phiên bản của trình mô phỏng để phân đoạn và có thể lên lịch chạy liên tục bằng trạm kiểm thử Android.
Chương trình Chất lượng drawElements (dEQP)
drawElements Chương trình chất lượng (dEQP) có trong CTS Android. Chương trình này có tên là CtsDepqTestCases, tập trung vào mức độ bao phủ kiểm thử của đồ hoạ Android. Mô-đun này chiếm gần 80% tổng số trường hợp kiểm thử trong CTS Android và chiếm 6% tổng thời gian thực thi.
Vì trình điều khiển đồ hoạ Android là một phần của chương trình cơ sở Android (BSP) và không thay đổi nhiều trong quá trình phát triển, nên bạn có thể chạy mô-đun này một cách chiến lược. Ví dụ: nếu chạy CTS mỗi hai tuần (hoặc ít hơn) trong quá trình phát triển phần mềm, thì dựa trên lịch cập nhật phần mềm cơ sở, bạn có thể loại trừ mô-đun này trong một số chu kỳ.
Một lựa chọn là chạy CtsDeqpTestCases riêng trên một nhóm thiết bị, sau đó gửi báo cáo CTS. Ví dụ: trên hai máy chủ lưu trữ riêng biệt.
Máy chủ 1:
cts-tf > run cts --max-log-size 100 --shard-count 6 -o -m CtsDeqpTestCases
Máy chủ 2:
cts-tf > run cts --max-log-size 100 --shard-count 6 -o --exclude-filter CtsDeqpTestCases
Các trường hợp kiểm thử nội dung nghe nhìn
Các trường hợp kiểm thử nội dung nghe nhìn xác minh các dịch vụ đa phương tiện như âm thanh, video và trình điều khiển đa phương tiện. Những mô-đun kiểm thử đa phương tiện này đóng góp nhiều nhất vào thời gian thực thi CTS. Tình trạng chậm trễ có thể xảy ra khi:
- Tải tệp nội dung nghe nhìn xuống hoặc phát tệp nội dung nghe nhìn nhiều lần trong quá trình kiểm thử.
- Đang thử lại các trường hợp kiểm thử không thành công.
CTS Android chứa các mô-đun kiểm thử sau:
CtsMediaStressTestCasesCtsMediaPlayerTestCasesCtsMediaAudioTestCasesCtsVideoTestCasesCtsMediaDecoderTestCasesCtsMediaCodecTestCasesCtsMediaV2TestCases
Hãy cân nhắc việc chạy một số bài kiểm thử nội dung nghe nhìn cục bộ hoặc trên một máy chủ cục bộ. Để biết thông tin chi tiết, hãy xem bài viết Chạy kiểm thử nội dung nghe nhìn CTS cục bộ.
Khung đa phương tiện và trình điều khiển (bộ giải mã và bộ mã hoá) là một phần của chương trình cơ sở Android (BSP). Bạn có thể chạy mô-đun này một cách chiến lược và loại trừ các mô-đun này trong một số chu kỳ, dựa trên lịch cập nhật chương trình cơ sở.