Bộ kiểm thử tính tương thích với Android (CTS) cung cấp hàng triệu bài kiểm thử riêng lẻ. Mặc dù cần phải 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 quy trình 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.
Thiết bị phân đoạn
Để giảm thời gian chu kỳ, hãy cân nhắ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 bài viết Chạy kiểm thử CTS.
Trạm kiểm thử Android
Sử dụng Android Test Station (ATS) (Trạm kiểm thử Android) để 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 chế độ 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 để liên tục chạy kiểm thử.
Trạm kiểm thử Android hỗ trợ chế độ nhiều máy chủ, trong đó bạn có thể sử dụng một máy chủ điều khiển ATS để quản lý các thiết bị và kiểm thử trên nhiều máy chủ thực thi ATS.
Chạy liên tục trình mô phỏng
Để 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 thế cho phần cứng. Sự hồi quy của các lần thất bại trong kiểm thử có thể được xác định sớm, 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 rễ. Bạn có thể sử 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)
Chương trình chất lượng drawElements (dEQP) có trong CTS của Android. Được gọi là CtsDepqTestCases, chương trình này tập trung vào mức độ kiểm thử của đồ hoạ Android. Mô-đun này chiếm gần 80% tất cả các trường hợp kiểm thử trong Android CTS 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 mềm 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, dựa trên lịch cập nhật phần mềm, bạn có thể loại trừ mô-đun này trong một số chu kỳ.
Một cách là chạy riêng CtsDeqpTestCases 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ữ khác nhau.
Máy chủ 1:
cts-tf > run cts --max-log-size 100 --shard-count 6 -o -m CtsDeqpTestCases
Máy chủ lưu trữ 2:
cts-tf > run cts --max-log-size 100 --shard-count 6 -o --exclude-filter CtsDeqpTestCases
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 đa phương tiện sẽ 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 trễ có thể xảy ra khi:
- Tải tệp phương tiện xuống hoặc phát đi phát lại tệp phương tiệ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.
Android CTS chứa các mô-đun kiểm thử sau:
CtsMediaStressTestCasesCtsMediaPlayerTestCasesCtsMediaAudioTestCasesCtsVideoTestCasesCtsMediaDecoderTestCasesCtsMediaCodecTestCasesCtsMediaV2TestCases
Cân nhắc chạy một số 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 phần Chạy kiểm thử nội dung nghe nhìn CTS trên máy.
Khung đa phương tiện và trình điều khiển (bộ giải mã và bộ mã hoá) của khung này 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 theo chiến lược và loại trừ các mô-đun này trong nhiều chu kỳ, dựa trên lịch cập nhật chương trình cơ sở.