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, 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ể dùng để giảm thời gian chạy thử nghiệm cũng như cách để tối ưu hoá tài nguyên phần cứng vào 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 Chạy thử nghiệm CTS.
Trạm kiểm tra Android
Sử dụng Trạm kiểm tra Android (ATS) để triển khai 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ị thử nghiệm cũng như thiết lập lịch trình để liên tục chạy kiểm thử.
Trạm kiểm thử Android hỗ trợ Chế độ nhiều máy chủ lưu trữ, trong đó một máy chủ điều khiển ATS có thể được dùng để 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ình mô phỏng
Để chạy liên tục CTS trong giai đoạn phát triển, bạn có thể sử dụng Thiết bị Android ảo (AVD) thay cho phần cứng. Hồi quy của các lỗi kiểm thử có thể là được xác định sớm, tiết kiệm nhiều thời gian cần thiết để phân loại và phân tích thư mục gốc nguyên nhân. Bạn có thể dùng nhiều thực thể của trình mô phỏng để phân đoạn và được lên lịch để chạy liên tục với trạm thử nghiệm Android.
Chương trình chất lượng drawElements (dEQP)
Chiến lược phát hành đĩa đơn
Chương trình chất lượng của drawElements (dEQP)
có trong CTS của Android. Chương trình này có tên là CtsDepqTestCases
về phạm vi kiểm thử đồ hoạ Android. Học phần này chiếm gần 80% trong tổng số
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 chương trình cơ sở Android (BSP) và không thay đổi nhiều trong quá trình phát triển, bạn có thể chạy mô-đun này một cách có chiến lược. Ví dụ: nếu bạn chạy CTS mỗi hai tuần (hoặc ít hơn) trong thời gian Trong quá trình phát triển phần mềm, bạn có thể loại trừ thông tin này dựa trên lịch cập nhật chương trình cơ sở mô-đun cho một số chu kỳ.
Có một lựa chọn là chạy CtsDeqpTestCases riêng biệt trên một nhóm thiết bị và
rồi 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ủ 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 nghe nhì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
Hãy cân nhắc chạy một số thử nghiệm 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 Chạy kiểm thử nội dung nghe nhìn CTS cục bộ.
Khung đa phương tiện và các trình điều khiển của 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ở.