Kiểm thử trong Internet of Things

• Internet vạn vật (IoT) đang tới gần chúng ta. Mọi đồ vật bạn thấy xung quanh bạn - như tủ lạnh, máy đánh răng, ôtô, thậm chí quần áo sắp sửa có được trí thông minh nhân tạo.

• Một vài trong số chúng đã có điều này. Đồng hồ Fitbit, máy chỉnh nhiệt độ Nest và Apple TV chỉ là phần nổi của tảng băng khi tương lai của chúng ta. Cảm biến, hệ thống nhúng và đám mây sẽ cùng nhau mang sự thông minh đến những vật vô tri vô giác. IoT sẽ là một thị trường tỉ đô vào năm 2020 và mọi ông lớn trong lĩnh vực phần cứng đang chạy đua cùng với rất nhiều công ty khởi nghiệp về lĩnh vực IoT.

• Trong khi các hệ thống nhúng đã tồn tại rất lâu dưới hình thức điện tử gia dụng, IoT đa mang đến một hướng phát triển mới cho chúng. Trước đây các hệ thống này đã cơ bản khép kín và có thể làm việc một cách độc lập. Nhưng các vật thể kết nối bây giờ cần giao tiếp với nhau để có thể hoạt động đúng. Điều này có nghĩa là các nhà phát triển cần phải xem xét để tinh giản cách giao tiếp giữa thiết bị tới thiết bị (device-to-device - D2D) và thiết bị tới máy chủ (device-to-server - D2S), ngoài sự tương tác giữa con người vào các vật dụng hàng ngày để trở thành một phần mở rộng của internet.

IoT và kiểm thử

• Trong phát triển phần mềm truyền thống, mã nguồn có thể được xây dựng và kiểm thử có thể được tự động trên các môi trường gần giống như môi trường thực tế. Các phương pháp tiếp cận mới mà làm cho quá trình này lặp lại và có thể dự đoán được gọi là Tích Hợp Liên Tục(Continuous Integration). Mục đích của nó là làm tăng chất lượng mã nguồn, tìm lỗi sớm, giảm rủi ro của việc lặp đi lặp lại của việc hồi quy và thúc đẩy phát triển. Nó được áp dụng rất nhiều trong các dự án phát triển web, và ngày càng nhiều trong việc phát triển ứng dụng di động. Thực tế, kiểm thử tự động đã gắn chặt vào cách suy nghĩ của các nhà phát triển mà trong rất nhiều trong số đó đã thay đổi toàn bộ cách tiếp cận để lập trình của họ, ưu tiên mô hình test-driven development(TDD)

• Những điều này càng được tăng thêm sự phức tạp trong thế giới nhúng, nơi mà người dùng cuối mong đợi điều tương tự - mô hình hệ thống cũng phải hoạt động tốt. Sự rối loạn gần đây của máy chỉnh nhiệt độ Nest đã dạy cho chúng ta rằng, các sản phẩm IoT chưa mạnh mẽ và dễ sử dụng như các sản phẩm truyền thống.

• Cho tới nay CI chưa bao giờ là một quy trình quen thuộc của việc phát triển phần mềm nhúng, phần lớn là do sự tương tác giữa phần cứng và phần mềm làm cho mọi việc khó khăn hơn. Để khác phục điều này, các nhà cung cáp IoT đang thay đổi để tích hợp CI tốt hơn vào công việc hàng ngày.

Điều gì làm các ứng dụng IoT khó kiểm thử

• Mô hình phát triển Agile yêu cầu một hướng tiếp cận khác khi phần cứng có liên quan vào quá trình này. Quá trình thiết kế cần nhiều thời gian hơn, và loại bỏ sự tích hợp của các phiên bản sản phẩm trước khiến chi phí cao hơn dự án phát triển phần mềm đơn thuần. Tối thiểu thì thời gian của mỗi vòng lặp(có thể hiểu là sprint) cũng dài hơn.

• Một giả thiết cần được đặt ra để đạt được việc tích hợp liên tục trong IoT đó là kiểm thử tự động. Để có thể tích hợp được trong mô hình phát triển sản phẩm nhúng, có một số rào cản cần phải vượt qua. Điều này không hề dễ dàng để phân tách mã nguồn vì sự phụ thuộc vào phần cứng cơ bản mà hầu như không thể bỏ qua.

• Hệ thống IoT là ứng dụng tổng hợp mà cần phải:

  • Khả năng thu thập dữ liệu cảm biến bằng cách phản ứng lại với một loạt yếu tốt như cảm ứng, giọng nói và theo dõi chuyển động.

  • Các máy chủ đám mây, di động và ứng dụng web từ mà từ đó các thiết bị có thể được theo dõi và kiểm soát

  • Một API của thiết bị cho phép các dữ liệu hàng ngày và phân tích thiết bị được đẩy đẩy tới máy chủ đám mây cũng như các thao tác chức năng.

  • Các loại phần cứng tương thích với nhau, một vài trong số chúng nổi tiếng như bảng mạch Arduino hoặc Raspberry Pi, những thứ khác thường không phổ biến như máy pha cà phê thông minh, máy quay video hoặc lò nướng

• Và phức tạp hơn nữa, IoT đi kèm với các giao thức riêng ngoài Wi-Fi và Bluetooth như MQTT, CoAP và ZigBee. Hơn nữa, các hệ thống nhúng đang được yêu cầu phải tuân thủ các chuẩn như IEC 61508 và MISRA để đảm bảo an toàn và độ tin cậy của các thiết bị.

• Ngôn ngữ lập trình được sử dụng trong các hệ thống nhúng thường là C hoặc C++. Những ngôn ngữ này ở tầng thấp hơn so bới các ngôn ngữ được sử dụng trong việc lập trình web, thường có hiệu suất tốt hơn nhưng thời gian lập trình dài và phức tạp do yêu cầu quản lý bộ nhớ rõ ràng, chưa kể đến việc thiếu nhân lực. Mã nguồn thiếu tính linh động có nghĩa là cần được biên dịch giữa các môi trường phát triển và môi trường thật.

• Dự án Greenfield độc lập là tương đối hiếm trong phần mềm nhúng - dự án mà dựa trên các mã nguồn thống nhất(monolithic legacy code) trong CI là khó trang bị thêm(retrofit). Tương tự như vậy, các hệ thống con của ứng dụng IoT thường thuộc sở hữu của các nhà cung cấp khác nhau. Điều gì sẽ xảy ra nếu mỗi lỗi được tìm thấy trong thiết bị của nhà cung cấp khác mà ứng dụng được cài đạt lên?

• Dữ liệu thử nghiệm toàn diện, bao hồm cả dữ liệu từ xa, có thể là khó khăn để thu được cho dự án IoT khi nó phụ thuộc vào điều kiện thực tế như các điều kiện thời tiết và áp suất khí quyển có thể ảnh hưởng đến kết quả.

• Cuối cùng, các yêu cầu phi chức năng thường rất khó để kiểm thử một cách có hệ thống. Những yêu cầu này có thể là giới hạn băng thông, pin lỗi và các sự can thiệp khác.

Mô phỏng, đảm bảo chất lượng và các hướng tiếp cận khác

• Mặc dù các vấn đề được liệt kê trong phần trước, các đội ngũ xây dựng tương lai của IoT đang cố gắng để đạt được một cách hệ thống, có khả năng lặp lại và phát hành thường xuyên trong thế giới nhúng.

• Một phần của sự phỏng đoán xung quanh việc lập kế hoạch kiểm thử có thể được hạn chế bằng các lựa chọn quen thuộc, có thể là một hệ thống quen thuộc. Một ví dụ đó là sử dụng Linux cho tất cả các dự án phần mềm nhúng, để ít nhất các lớp hệ điều hành là có thể dự đoán được. Nhìn chung, khả năng tách biệt lập trình logic từ phần cứng làm cho việc kiểm thử các hệ thống phụ dễ dàng hơn. Ngoài ra, việc tập trung các nguồn lực sớm vào các nguyên mẫu hoặc khối lượng ít vào giai đoạn đầu có thể giúp phỏng đoán được con chíp và dễ dàng hoạch định tương lai.

• Để giảm thiểu các vấn đề xung quanh chất lượng của dữ liệu kiểm thử, các chuyên gia IoT ghi lại các dữ liệu đầu vào từ người dùng trong thực tế và dữ liệu môi trường, sẽ được tái hiện lại trong môi trường kiểm thử. Điều này giúp giữ các môi trường kiểm thử giống thực tế nhất có thể. Kiểm tra việc tuân thủ với các quy định có thể được tự động hóa từng phần bằng cách sử dụng các công cụ phân tích tĩnh.

• Nhưng chủ yếu, các phương pháp tiếp cận hiện đại để kiểm thử các ứng dụng hỗn hợp nổi bật của phần mềm nhúng thường sử dụng các hình thức mô phỏng. Cũng như cách các nhà phát triển ứng dụng di động sử dụng bộ giả lập như Perfecto và Sauce Labs để tái tạo các điều kiện kiểm thử giữa rất nhiều các thiết bị điện thoai thông minh, các nhà phát triển phần mềm nhúng dựa đến các phần mềm mô phỏng để tao ra môi trường kiểm thử tích hợp. Đặc biệt, việc sử dụng các phần mềm mô phỏng có thể giải quyết được các vấn đề về phần cứng và đẩy nhanh tiến độ kiểm thử đối với các phiên bản khác nhau, kích thước màn hình, và các đặc tính phần cứng khác.

• Những môi trường ảo hóa là riêng biệt cho mỗi ứng dụng và thường rất đắt đỏ để thiết lập, nhưng như trường hợp của CI truyền thống, việc khởi tạo lúc đầu sẽ giảm bớt rất nhiều thời gian của vòng đời dự án.

• Những mô phỏng ngày càng trở nên tinh vi, hỗ trợ hiệu suất và kiểm thử bộ nhớ, bảo mật, và thậm chí còn cho phép kiểm tra các trường hợp ngoài phạm vi như mất kết nối hoặc giao thoa điện từ tạo ra tiếng ồn trong dữ liệu cảm biến.

• Tuy nhiên, một quá trình đảm bảo chất lượng bền vững vẫn cần sử dụng các phần cứng thực sự trong giai đoạn cuối của mỗi chu trình thử nghiệm lớn. Có nhiều lý do tại sao các đội không thể dựa toàn toàn trên các kết quả mô phỏng. Những lỗi xấp xỉ trong các mô hình mô phỏng có thể gây ra lỗi và phải được tìm ra trước khi đưa ra thị trường. Ngoài ra, việc kiểm tra sự tương tác giữa con người và các hành vi không thể mô phỏng được, và cảm xúc của con người đối với một hệ thống được mô phỏng hoàn hảo là cũng không thể dự đoán được. Một sự kết hợp giữa kiểm thử hộp đen và hộp trắng thường được sử dụng trong giai đoạn đảm bảo chất lượng để phát hiên các vấn đề mà có thể do lỗi của việc mô phỏng.

Kết luận

• Internet vạn vật hứa hẹn sẽ thay đổi cách chúng ta tương tác đến các vật dụng xung quanh, nhưng kỳ vọng cao được đặt ra bởi các công ty như Apple và Tesla sẽ yêu cầu các công ty IoT phát triển và nâng cao văn hóa kiểm thử trong các thiết bị điện tử tiêu dùng lên một tiêu chuẩn mới.

Tham khảo

http://nordicapis.com/automated-testing-for-the-internet-of-things/