Tôi làm việc tại một công ty cỡ trung bình (150 nhân viên, nhóm kỹ sư ~ 10 cỡ) và hầu hết các dự án của tôi liên quan đến việc giao tiếp với thiết bị phòng thí nghiệm (máy hiện sóng, máy phân tích quang phổ, v.v.) cho mục đích ứng dụng thử nghiệm bán tự động. Tôi đã gặp phải một vài tình huống khác nhau trong đó tôi không thể khắc phục sự cố hoặc kiểm tra mã mới một cách hiệu quả vì tôi không còn hoặc không bao giờ có sẵn thiết lập phần cứng cho tôi.
Ví dụ 1: Thiết lập trong đó các quy trình "burn-in" 10-20 được chạy độc lập bằng cảm biến loại trên băng ghế dự bị - Tôi có thể lấy một cảm biến như vậy để thử nghiệm và đôi khi có thể đánh cắp một giây để mô phỏng tất cả các khía cạnh giao tiếp với nhiều thiết bị (tìm kiếm, kết nối, phát trực tuyến, v.v.).
Cuối cùng, một lỗi đã xuất hiện (và cuối cùng là trong phần mềm và trình điều khiển của thiết bị) rất khó tái tạo chính xác chỉ với một đơn vị, nhưng đạt đến mức "hiển thị nút chặn" khi 10-20 thiết bị này được sử dụng đồng thời. Điều này vẫn chưa được giải quyết và đang diễn ra.
Ví dụ 2: Một thử nghiệm yêu cầu máy phân tích quang phổ đắt tiền làm thành phần cốt lõi của nó. Thiết bị này khá cũ, theo di sản của nhà sản xuất được mua lại bởi một công ty lớn hơn và về cơ bản đã giải thể, và tài liệu duy nhất của nó là một tài liệu dài (và không chính xác) có vẻ được dịch kém. Trong quá trình phát triển ban đầu, tôi đã có thể giữ thiết bị ở bàn làm việc của mình, nhưng bây giờ nó đã được gắn chặt, cả về thể chất và lịch trình trong các bài kiểm tra nhiều tuần 24/7.
Khi các lỗi xuất hiện liên quan hoặc không liên quan đến thiết bị, tôi thường phải trải qua sự cố kiểm tra mã bên ngoài cho ứng dụng và gắn nó vào, hoặc viết mã một cách mù quáng và cố gắng nén thời gian thử nghiệm giữa các lần chạy, như nhiều logic chương trình yêu cầu OSA và phần còn lại của phần cứng thử nghiệm được đặt đúng chỗ.
Tôi đoán câu hỏi của tôi là làm thế nào tôi nên tiếp cận điều này? Tôi có khả năng có thể dành thời gian để phát triển các trình giả lập thiết bị, nhưng hình dung rằng trong ước tính phát triển sẽ đánh bóng nó nhiều hơn hầu hết có thể đánh giá cao. Nó có thể không tái tạo chính xác tất cả các vấn đề, và thật hiếm khi thấy thiết bị tương tự được sử dụng hai lần ở đây. Tôi có thể trở nên tốt hơn khi thử nghiệm đơn vị ... vv ... Tôi cũng có thể lớn tiếng về vấn đề này và khiến người khác hiểu rằng sẽ cần phải trì hoãn tạm thời, không hơn gì đau đầu cho Nghiên cứu và Phát triển nhưng thường được coi là một trò đùa khi được sản xuất.