Định cấu hình kiểm thử ACTS

Trang này mô tả cách định cấu hình kiểm thử ACTS.

Nguồn cấu hình

Bộ kiểm thử giao tiếp Android (ACTS) có 3 nguồn cấu hình chính:

• Giao diện dòng lệnh (CLI)
• Tệp cấu hình ACTS
• Biến môi trường

Giá trị từ các nguồn này được kết hợp thành một cấu hình duy nhất dùng để chạy kiểm thử ACTS. Nếu các giá trị được chỉ định ở nhiều vị trí, thì các giá trị sẽ bị ghi đè dựa trên thứ tự ở trên (trong đó CLI được ưu tiên).

Lưu ý về biến môi trường

Hãy cẩn thận khi sử dụng các biến môi trường cho kiểm thử ACTS. Người dùng ít thấy các giá trị này nhất và không nên dùng để sử dụng bên ngoài máy trạm của nhà phát triển. Các biến môi trường sẽ bị vô hiệu hoá trong quá trình kiểm thử tự động ACTS để ngăn ngừa nhiễm độc môi trường.

Biến cấu hình bắt buộc

Mọi bài kiểm tra ACTS đều yêu cầu bạn phải đặt các biến sau.

Lộ trình thử nghiệm ACTS

ACTS chạy từ một vị trí truy cập chính. Do đó, trình chạy không xác định được vị trí đường dẫn kiểm thử.

Đặt vị trí đường dẫn kiểm thử bằng cách sử dụng biến môi trường ACTS_TESTPATH hoặc bằng cờ -tp/--testpaths trong dòng lệnh. Giá trị có thể là một danh sách các thư mục.

Lớp kiểm tra ACTS

ACTS phải biết cần chạy lớp kiểm thử nào. Đây có thể là biểu thức chính quy hoặc danh sách tên lớp kiểm thử.

Để đặt giá trị này, hãy sử dụng cờ -tc/--test_class trong dòng lệnh. Lưu ý rằng cờ này cũng chấp nhận danh sách tên lớp. Tên lớp phải khớp với tên tệp tương ứng, ví dụ: phải tìm thấy SampleTest trong SampleTest.py.

Đường dẫn nhật ký ACTS

ACTS phải có một vị trí để ghi nhật ký vào STDOUT. ACTS ghi nhật ký gỡ lỗi đầy đủ chứa dữ liệu có thể giúp xác định lý do một số kiểm thử không thành công. Để tránh tình trạng lộn xộn, ACTS không ghi các nhật ký này vào STDOUT.

Để đặt đường dẫn nhật ký, hãy sử dụng biến môi trường ACTS_LOGPATH hoặc cờ -lp/--logpath trong dòng lệnh.

Đường dẫn cấu hình ACTS

Để chạy kiểm thử, ACTS phải biết kiểm thử nào tồn tại. Cấu hình ACTS chứa mọi thiết bị trong môi trường kiểm thử cũng như mọi tham số môi trường hoặc kiểm thử đặc biệt có thể cần thiết. Hãy đặt giá trị này trên dòng lệnh bằng cách sử dụng -c/--config.

Nếu có nhiều điểm kiểm thử trong cấu hình, ACTS sẽ chạy kiểm thử cho từng trường hợp kiểm thử. Để chỉ chạy kiểm thử cho một kiểm thử duy nhất trong danh sách, hãy sử dụng đối số dòng lệnh -tb/--testbed <NAME>.

Ví dụ về máy trạm cục bộ

Hầu hết người dùng ACTS đều phát triển trên một nhánh kho lưu trữ Android duy nhất và có chế độ thiết lập tương tự như sau:

# in ~/.bashrc
ACTS_LOGPATH='/tmp/acts_logpath'
ACTS_TESTPATH='~/android/<REPO_BRANCH>/tools/test/connectivity/acts_tests/'

# On cmdline
$ act.py -c ~/acts_configs/local_config.json -tc SampleTest -tb marlin

Nếu người dùng ACTS chạy trên nhiều nhánh, thì họ thường chạy ACTS từ thư mục acts/framework và sử dụng một đường dẫn tương đối cho ACTS_TESTPATH:

# in ~/.bashrc
ACTS_LOGPATH='/tmp/acts_logpath'
ACTS_TESTPATH='../acts_tests/'

# On cmdline
$ cd ~/android/main/tools/test/connectivity/acts_tests/acts_contrib/
$ act.py -c ~/acts_configs/local_config.json -tc SampleTest -tb marlin

Định cấu hình điểm kiểm thử

Tệp cấu hình ACTS cung cấp tất cả thông tin cần thiết để chạy kiểm thử trên thiết bị phần cứng:

{
  "testbed": {
    "my_testbed": {
      "my_testbed_value": "value"
    },
    "another_testbed": {
      "AndroidDevice": [
        "53R147"
      ]
    }
  },
  "user_parameter_1": "special environment value",
  "user_parameter_2": "other special value"
}

Đơn vị cơ sở của cấu hình này là trung tâm kiểm thử. Trong cấu hình mẫu ở trên, my_testbed được kiểm thử được tạo với một giá trị được kiểm thử duy nhất. Lớp kiểm thử thứ hai, another_testbed, có một cấu hình tay điều khiển đặc biệt chứa thông tin của danh sách thiết bị Android. Các thiết bị này được lưu trữ trong danh sách thiết bị trong self.android_devices. Lưu ý rằng nếu một lớp kiểm thử không chỉ định đối tượng AndroidDevice, thì một lớp kiểm thử dự kiến đối tượng AndroidDevice sẽ đưa ra một ngoại lệ. Để xem danh sách đầy đủ các cấu hình tay điều khiển được hỗ trợ đi kèm với ACTS, hãy xem danh sách tại /acts/framework/acts/controllers/.

Tất cả giá trị khác (không phải là giá trị đặc biệt được đề cập trong phần trên) được lưu trữ trong self.user_params làm từ điển. Đây là nơi phù hợp để lưu giữ thông tin về môi trường hoặc thông tin thử nghiệm, chẳng hạn như điện thoại có đang ở trong môi trường dữ liệu có đo lượng dữ liệu hay không hoặc thời gian thu thập dữ liệu cho một thử nghiệm.

Các trường hợp đặc biệt cho AndroidDevice

Để thuận tiện cho việc phát triển khi bạn muốn có nhiều thiết bị với các thuộc tính khác nhau, AndroidDevice có một số trường hợp đặc biệt.

Định dạng cấu hình JSON

Tất cả các cặp khoá/giá trị trong ví dụ JSON sau đây được đặt thành đối tượng AndroidDevice tương ứng. Nếu cấu hình cố gắng ghi đè một tham số được xác định trong thuộc tính AndroidDevice, thì ControllerError sẽ được gửi.

  "AndroidDevice": [{"serial": "XXXXXX", "label": "publisher"},
                    {"serial": "YYYYYY", "label": "subscriber", "user_parameter_1": "anything"}]

Sau đó, trong tập lệnh kiểm thử, bạn có thể sử dụng hàm bộ lọc để truy xuất đúng thiết bị và truy cập vào các tham số bổ sung từ đối tượng thiết bị:

  def setup_class(self):
      self.pub = next(filter(lambda ad: ad.label == 'publisher',
                             self.android_devices))
      self.sub = next(filter(lambda ad: ad.label == 'user_parameter_1',
                             self.android_devices))

Tham số không bắt buộc

Sau đây là tham số không bắt buộc:

• adb_logcat_param: Một chuỗi được thêm vào lệnh adb logcat để thu thập nhật ký adb. Theo mặc định, adb logcat -v threadtime -b all sẽ được sử dụng. Nếu bạn đặt adb_logcat_param, phần -b all sẽ bị ghi đè. Ví dụ: việc đặt adb_logcat_param thành -b radio sẽ thay đổi lệnh thành adb logcat -v threadtime -b radio.