Bộ kiểm tra tính tương thích (CTS) với Android cung cấp hàng triệu chương trình 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 chương trình kiểm thử này.
Trang này mô tả các phương thức mà bạn có thể dùng để giảm thời gian phiên chạy thử nghiệm và cách tối ưu hoá tài nguyên phần cứng trong quy trình.
Phân chia thiết bị
Để giảm thời lượng chu kỳ, hãy cân nhắc việc chạy CTS (Bộ kiểm tra tính tương thích) trên nhiều Thiết bị (phân đoạn). Để xem cách sử dụng tính năng phân chia, hãy xem bài viết Chạy kiểm thử CTS.
Trạm kiểm thử Android
Hãy 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à giao diện web cho Trade Federation (TF), cho phép bạn chạy CTS với quy trình thiết lập tối thiểu trên một nhóm thiết bị kiểm thử, cũng như thiết lập lịch biểu để chạy kiểm thử liên tục.
Trạm kiểm thử Android hỗ trợ Chế độ nhiều máy chủ, trong đó bạn có thể dùng một máy chủ bộ điều khiển ATS để quản lý thiết bị và kiểm thử trên nhiều máy chủ worker ATS.
Chạy liên tục trên trình mô phỏng
Để chạy CTS liên tục trong giai đoạn phát triển, Thiết bị Android ảo (AVD) có thể dùng thay cho phần cứng. Bạn có thể xác định sớm các lỗi hồi quy của chương trình kiểm thử, 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 thực thể của trình mô phỏng để phân chia 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)
Chương trình chất lượng
drawElements `drawElements` (dEQP)
có trong CTS Android. Được gọi là CtsDepqTestCases, chương trình này tập trung vào phạm vi 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 phần sụn 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 bạn chạy CTS 2 tuần một lầ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 sụn, bạn có thể loại trừ mô-đun này trong vài 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 2 máy chủ khác nhau.
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. Các 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ử.
- 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ố chương trình kiểm thử nội dung nghe nhìn cục bộ hoặc trên 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 phần sụn 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 vài chu kỳ, dựa trên lịch cập nhật phần sụn.