12/08/2018, 15:38

Bản đồ IoT Testing

Sự xuất hiện của Internet of Things (IoT) đặt ra một số thử thách thú vị khiến nhiều nhà phân tích chất lượng phải cân nhắc lại các quy trình truyền thống của họ. Ví dụ, gần đây tôi đã làm việc trên một sản phẩm, nơi mà một ứng dụng di động có thể trò chuyện được với một máy tính đã kết nối. Các ...

Sự xuất hiện của Internet of Things (IoT) đặt ra một số thử thách thú vị khiến nhiều nhà phân tích chất lượng phải cân nhắc lại các quy trình truyền thống của họ. Ví dụ, gần đây tôi đã làm việc trên một sản phẩm, nơi mà một ứng dụng di động có thể trò chuyện được với một máy tính đã kết nối. Các trạng thái khác nhau mà hai thiết bị này có thể làm cho nó trở nên đặc biệt khó khăn trong khi đưa ra các kịch bản test. Tôi muốn trình bày framework mà tôi thấy hữu ích khi test sản phẩm dựa trên IoT. Framework này, cái mà tôi gọi là IoT Testing Atlas giúp quản lý các hoán vị khác nhau của các trạng thái những thứ mà rất khó để có được trong quá trình triển khai IoT.

IoT Testing Parameters

Khi chúng ta xem xét một số trạng thái phổ biến hoặc biến thể được kiểm tra trong một ứng dụng web đơn giản, chúng ta sẽ thấy bốn kết quả cơ bản: Chết Server.

  • HTTP timeouts
  • Mạng chậm.
  • Lỗi ủy quyền và xác thực.

Khi kiểm tra bất kỳ ứng dụng internet, chúng ta cần phải lưu ý của bốn yếu tố đó. Bây giờ, hãy xem xét một ứng dụng di động. Đó là điều bắt buộc mà chúng ta phải ghi nhớ, tập hợp các trạng thái và biến thể phát sinh từ hoạt động trong môi trường di động. Những trạng thái này bao gồm:

  • Chế độ ngoại tuyến.
  • Chế độ trực tuyến.
  • Activity kill
  • Background behavior
  • Ngôn ngữ.
  • Vị trí.

Bây giờ, nếu chúng ta nhìn vào sự đa dạng của các trạng thái "kết nối thiết bị", chúng ta sẽ thấy bốn trạng thái mới:

  • Thiết bị tắt wifi.
  • Thiết bị kết nối wifi.
  • Thiết bị trong trạng thái bận.
  • Thiết bị trong trạng thái ngủ.

Điều này có nghĩa là ngay cả với một tập các trạng thái ví dụ, có khoảng 96 (4 x 6 x 4) cho biết toàn bộ hệ thống có thể ở bất cứ thời điểm nào.

Mỗi trạng thái này không thể được coi như một thực thể độc lập, vì sự chuyển đổi trạng thái trong một hệ thống đều có các ràng buộc bổ sung. Ví dụ: thay đổi trạng thái từ 'ngoại tuyến' sang 'trực tuyến' có thể sẽ kích hoạt một tập hợp các sự kiện khác.

Tập trên các tham số chỉ là đỉnh của tảng băng trôi. Khi chúng tôi đi sâu hơn vào chi tiết cụ thể, kết nối các trạng thái khác nhau để các kịch bản hợp lý có thể bao quát được toàn bộ hệ thống.

Khi tôi đã thử sử dụng các kỹ thuật dựa trên web hiện có như ghép cặp, phân vùng tương đương, giá trị biên và các kỹ thuật tương tự, Tôi nhận thấy rằng họ đã làm tốt công việc đối với phát sinh tình huống với một bộ dữ liệu biến cho một hệ thống tĩnh. Những kỹ thuật này áp dụng logic loại trừ để đạt tới bộ dữ liệu tối ưu nhất dùng để test.

Ví dụ, tất cả các cặp kỹ thuật được tạo nên sau khi loại bỏ sự kết hợp dữ liệu lặp đi lặp lại. Nhưng khi chúng ta áp dụng cùng một kỹ thuật cho các trạng thái biến của hệ thống để rút ra các scenarios. Các trạng thái hệ thống bị loại bỏ có thể để lại cho chúng ta một hệ thống không đáng tin cậy. Tuy nhiên, những kỹ thuật này sẽ vẫn hoạt động tốt, bên trong một đơn vị duy nhất của hệ thống IoT.

Đó là lý do cho sự cần thiết của IoT Testing Atlas.

Hình dung về Atlas

Hầu hết chúng ta đã lướt qua một atlas trong các lớp địa lý. Atlas này, trong quan điểm của tôi là phác thảo tất cả các tham số hệ thống tiềm năng và rút ra các kịch bản có ý nghĩa được yêu cầu để test tính năng.

Mọi hệ thống của một sản phẩm đều được phác họa như một vòng tròn với các trạng thái của nó. Các trạng thái tương lai hợp lý được đặt gần nhau.

Hình ảnh sau đây là quan điểm của tôi về IoT Testing Atlas:

Hãy xem xét một vài kịch bản sử dụng Atlas và rút ra các kịch bản hợp lý cho một số tính năng chỉ liên quan đến tương tác giữa điện thoại di động và thiết bị. Điều này có nghĩa là vòng tròn tập trung của chúng tôi tập trung vào các Thiết bị, Máy và Mạng.

Sửa thiết bị di động và máy Wi - fi . Khi xoay vòng kết nối Mạng, chúng tôi nhận được các tình huống sau:

  • Người dùng trái phép cố gắng truy cập vào máy gây ra thông báo lỗi 'Truy cập bị Từ chối' trên ứng dụng.
  • Chết server và lỗi server sẽ kích hoạt các thông báo lỗi thích hợp như 'Đã xảy ra sự cố. Thử lại sau.'
  • Đáp ứng timeouts có thể làm một trong hai điều. Kích hoạt lại cùng một yêu cầu sử dụng các biểu tượng tải kéo dài hoặc hiển thị một thông báo lỗi tương tự đến một trong những được liệt kê ở trên.
  • Yêu cầu không hợp lệ sẽ kích hoạt các thông báo như 'Ứng dụng của bạn cần phải được cập nhật'.

Tiếp tục giữ thiết bị di động trên Wi-Fi Bật và di chuyển vòng kết nối máy tính, từng bước một:

  • Khi máy đang ở chế độ ngoại tuyến, ứng dụng phải hiển thị 'kiểm tra kết nối mạng'.
  • Khi máy bận, cần cảnh báo, chẳng hạn như 'không thể hoàn thành yêu cầu của bạn khi máy đang bận'.
  • Khi máy đang ngủ hoặc kết nối mạng khác, hiển thị một tin nhắn 'máy không tìm thấy' hoặc tương tự như vậy.
  • Bây giờ, việc chuyển máy sang mạng bên phải nên cho phép kết nối lại giữa điện thoại di động và máy.

Chuyển vòng quay máy sang Wi-Fi Bật và xoay vòng kết nối di động để tìm các tình huống khác:

  • Khi điện thoại di động ngoại tuyến, thì các thông báo / hành vi thích hợp (như nút tắt) sẽ xuất hiện.
  • Khi thiết bị di động được hoạt động trực tuyến, các cuộc gọi thích hợp sẽ kết nối máy và ứng dụng.
  • Khi điện thoại di động chuyển mạng Wi-Fi sang 3G - bạn sẽ xác định những hành động nào là phù hợp?
  • Khi người dùng nhận cuộc gọi và đặt ứng dụng ở chế độ nền - liệu họ vẫn sẽ thấy yêu cầu đã hoàn thành hay quay trở lại quảng cáo không?
  • Vì Android sẽ kill một số ứng dụng ở chế độ nền trong một thời gian, liệu trạng thái màn hình cuối cùng của người dùng sẽ được lưu lại không?
  • Ứng dụng có phạm vi nội địa hóa cần được xác minh ở mọi mức độ của kịch bản.

Tương tự, Atlas có thể được mở rộng cho nhiều kịch bản với nhiều vòng quay. Mặc dù một số kịch bản có thể không phù hợp với tính năng hiện tại và một số thậm chí có thể không liên quan đến nhu cầu kinh doanh, nhưng bản đồ atlas vẫn là một ký thuật bao phủ.Framework này cũng có thể được mở rộng cho nhiều hệ thống trong một sản phẩm.

Trên thực tế, khi một đội nghiên cứu sản phẩm IoT có nhiều hơn một tài liệu về chất lượng, bản đồ này sẽ cung cấp một cách thức tham khảo chung. Atlas hiệu quả như vậy bởi vì nó bao gồm các yêu cầu duy nhất cho việc test - hoán vị các công cụ, thiết bị, kịch bản và các giao thức một cách toàn diện.

Bài viết được dịch lại từ nguồn: https://www.thoughtworks.com/insights/blog/iot-testing-atlas

0