Ma trận kiểm thử hồi quy sau khi cập nhật firmware cho drone
Đánh giá cập nhật firmware qua định danh thiết bị, cấu hình gốc, mô phỏng, kiểm tra chức năng thực tế và bằng chứng cho quyết định đưa vào sử dụng có kiểm soát.
Xác định lý do tại sao bản cập nhật được đề xuất
Bản phát hành chương trình cơ sở có sẵn không phải là lý do chính đáng để thay đổi máy bay đang hoạt động ngay lập tức. Xác định vấn đề, khả năng cần thiết hoặc mục tiêu bảo trì và đọc thông tin phát hành hiện hành. Ghi lại nền tảng phần cứng đích của bộ điều khiển, loại máy bay và cài đặt hiện tại. Điều này thiết lập lợi ích mong đợi và ngăn nhóm nhận được bản cập nhật chỉ vì một đơn vị khác đã sử dụng bản tải xuống có tên tương tự. Quy trình kỹ thuật có trách nhiệm xác định khi nào nên tiến hành thay đổi.
Duy trì đường cơ sở có thể phục hồi
Trước khi thực hiện công việc được ủy quyền, hãy xác định chương trình cơ sở hiện có, các thông số, tài liệu tham khảo hiệu chuẩn, thiết bị được kết nối và các ví dụ về nhiệm vụ được chấp nhận. Bảo quản các hồ sơ hỗ trợ ở vị trí dự án có thể tiếp cận được. Ảnh chụp màn hình số phiên bản không phải là đường cơ sở đầy đủ. Thiết lập các bước khôi phục nào thực sự được hỗ trợ cho sự kết hợp bo mạch và phần mềm. Đừng cho rằng việc tải một tệp cũ hơn sẽ tự động tạo lại tất cả các cài đặt trước đó hoặc đảo ngược mọi thay đổi.
Xây dựng kiểm tra xung quanh các chức năng được cài đặt
Tạo một ma trận kết nối từng chức năng liên quan với cấu hình, quan sát dự kiến, môi trường thử nghiệm và người đánh giá của nó. Bao gồm các cảm biến, thông tin liên lạc, lệnh tải trọng, giải thích nhiệm vụ, ghi nhật ký và hành vi dự phòng có thể áp dụng. Ma trận phải phản ánh máy bay được cung cấp thay vì mọi tính năng lái tự động có thể có. Nó tiết lộ bằng chứng còn thiếu: một lần khởi động thành công có thể xác nhận phần mềm đang chạy nhưng giao diện máy ảnh hoặc hành vi bay về vẫn hoàn toàn chưa được kiểm tra.
Sử dụng mô phỏng cho các câu hỏi mà nó có thể trả lời
Thử nghiệm phần mềm trong vòng lặp có thể kiểm tra logic nhiệm vụ và quy trình công việc được hỗ trợ mà không coi máy bay thật là thử nghiệm đầu tiên. Ghi lại trình mô phỏng, phiên bản phần mềm, mô hình và các giả định. Mô phỏng không chứng minh được hệ thống dây điện, tình trạng động cơ đẩy hoặc hiệu suất của cảm biến được lắp đặt. Giữ những kiểm tra đó riêng biệt. Một kết quả hữu ích cho biết hành vi nào đã được thực hiện và câu hỏi vật lý nào vẫn yêu cầu quy trình xác nhận hoạt động và mặt đất đã được phê duyệt của máy bay.
Xem xét sự khác biệt trước khi mở rộng triển khai
So sánh kết quả dự kiến và kết quả quan sát được, bao gồm các giá trị mặc định đã thay đổi, cài đặt được đổi tên, phát hiện thiết bị và dữ liệu được ghi lại. Điều tra sự khác biệt thay vì sao chép bừa bãi tệp tham số trước đó. Giữ đánh giá giới hạn trong cấu hình thực sự được kiểm tra. Nếu một vấn đề chưa được giải quyết ảnh hưởng đến chức năng bắt buộc, hãy giữ trạng thái rõ ràng và lộ trình báo cáo. Việc áp dụng trên toàn đội phải tuân theo khả năng ứng dụng đã được chứng minh, chứ không phải là không có lỗi rõ ràng trong một lần trình diễn không chính thức.
Ban hành hồ sơ cấu hình vận hành hoàn chỉnh
Gói cuối cùng phải xác định phần sụn, cấu hình, bằng chứng kiểm tra, giới hạn còn lại và hướng dẫn cập nhật được chấp nhận. Đảm bảo người vận hành và nhân viên hỗ trợ có thể nhận ra máy bay nào mang theo bố trí đã được phê duyệt. Giữ lại đường cơ sở trước đó và lịch sử quyết định. Điều này giúp cho cuộc thảo luận về chương trình cơ sở NiVO có thể được xem xét lại và tạo điểm khởi đầu đáng tin cậy cho việc khắc phục sự cố trong tương lai, đồng thời ngăn không cho chỉ số phiên bản bị nhầm lẫn là đã sẵn sàng hoàn toàn.
