Làm thế nào để khắc phục sự cố hoặc kiểm tra mã mới một cách hiệu quả khi thiết lập phần cứng để tạo lại lỗi khó hoặc không thể có được?


30

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.


5
một trình giả lập thiết bị (hoặc giao diện có thể giả) sẽ tự trả tiền chỉ trong sự tiện lợi
ratchet freak

21
@ratchetfreak - là một người dành cả ngày để mô phỏng các thiết bị (tôi làm việc trên một trình giả lập thiết bị y tế toàn thời gian), tôi đảm bảo với bạn rằng ngay cả việc mô phỏng độ chính xác thấp của thiết bị của người khác cũng có thể là một công việc RẤT khó khăn, tùy thuộc vào kết nối, giao thức và các loại dữ liệu liên quan. Nếu thiết bị kiểm tra mà OP sử dụng là bất cứ thứ gì giống như thiết bị tôi phải xử lý, có thể mất vài ngày hoặc vài tuần để chọc vào nó để tìm ra điều đẫm máu thực sự đang làm (trái ngược với những gì thông số kỹ thuật nói). Vì vậy, đây không phải là một kết luận bỏ qua mà một trình giả lập đáng giá.
Michael Kohne

Câu trả lời:


35

Quản lý hiểu rằng sẽ mất nhiều thời gian hơn để phát triển và bảo trì phần mềm khi bạn không có quyền truy cập đầy đủ vào phần cứng thử nghiệm. Bạn cần tính đến điều này khi thực hiện ước tính của mình. Một phần của tiêu chí chấp nhận đưa phần mềm của bạn vào sản xuất phải là bạn có cách duy trì phần mềm trong hầu hết các trường hợp mà không ngừng sản xuất. Nếu bạn đang thực hành TDD, điều này sẽ xảy ra khá tự nhiên.

Tôi đã từng viết phần mềm cho máy bay trị giá 60 triệu đô la. Rõ ràng, có một mức độ tin cậy cao cần thiết, và họ không muốn cung cấp cho mỗi nhà phát triển cho bàn của họ. Về cơ bản chúng tôi có 5 cấp độ môi trường thử nghiệm, với nhiều phần cứng thực tế hơn ở mỗi cấp độ, cho đến một máy bay đầy đủ. Tôi ước tính 95% phần mềm của chúng tôi có thể được phát triển và gỡ lỗi chỉ với các trình giả lập và kiểm tra đơn vị. 95% các tính năng còn lại có thể được làm việc ở cấp độ tiếp theo, v.v.

Cố gắng thiết lập các cấp độ tương tự của môi trường thử nghiệm cho chính bạn. Bạn không thể không bao giờ cần quyền truy cập vào phần cứng thực, nhưng nếu bạn đã thiết lập nó để bạn không thể làm việc trên GUI của phần mềm mà không có phần cứng khả dụng, bạn sẽ lãng phí thời gian quý báu cho một tài nguyên đắt tiền (không phải đề cập đến bạn có một số vấn đề khớp nối với kiến ​​trúc của bạn). Hãy xem xét rằng các nhà phát triển khác có thể có cùng các vấn đề như bạn. Tôi sẽ hỏi nhà cung cấp phần cứng nếu họ đã có trình giả lập hoặc các tài nguyên kiểm tra khác có sẵn.

Bạn cũng cần thay đổi suy nghĩ của mình một chút nếu bạn chỉ có quyền truy cập hạn chế vào phần cứng. Thay vì cố gắng gỡ lỗi ứng dụng của bạn theo cách nối tiếp thông thường, bạn thường cần viết mã cụ thể cho mục đích thu thập thông tin nhanh nhất có thể.

Ví dụ, có lẽ bạn có một lỗi và bạn có thể nghĩ ra 10 nguyên nhân có thể. Nếu thời gian duy nhất bạn có thể nhận được trên máy là 15 phút trong khi người vận hành nghỉ, hãy viết một Bản ngắn, Tự chứa, Đúng (Có thể biên dịch), Ví dụ kích hoạt lỗi và viết 10 bài kiểm tra tự động bằng SSCCE đó để kiểm tra lý thuyết của bạn và đăng nhập một loạt các dữ liệu. Sau khi trở lại bàn làm việc của bạn, bạn có thể mất chừng nào bạn cần sàng lọc dữ liệu cho lần thử tiếp theo. Ý tưởng là để tối đa hóa tiện ích trong thời gian giới hạn của bạn với phần cứng.


Đã chấp nhận câu trả lời này vì nó là hoàn chỉnh nhất - và tôi nghĩ rằng một sự cân bằng tốt của "làm cho quản lý nhận thức" với "thay đổi thực hành của bạn". Tôi nghĩ rằng việc dành một số nỗ lực cho các mức độ tách rời tốt hơn và một số mức mô phỏng phần cứng nên có giá trị và tôi có thể hiển thị điều này trong các ước tính của mình. Tôi cũng đặc biệt thích các mẹo để siết chặt trong một số bài kiểm tra đầy đủ tính năng nhanh chóng thu được nhiều dữ liệu trong khi gỡ lỗi - cảm ơn bạn.
plast1k

14
Tôi đã ngừng đọc sau khi "Quản lý hiểu"
PlasmaHH

1
"Bất đắc dĩ phải cung cấp cho mỗi nhà phát triển một bàn cho họ". Trớ trêu thay, bạn có thể có thể bẻ cong các con số đủ để chứng minh rằng việc cung cấp cho mỗi nhà phát triển chiếc máy bay trị giá 60 triệu đô la của riêng họ để làm việc sẽ rẻ hơn tổng chi phí tích lũy của một thảm họa hàng không!
Ông JavaScript

15

Bạn đang cố gắng giải quyết vấn đề không phải của bạn để giải quyết.

Quản lý cần ưu tiên truy cập vào thiết bị. Điều đó có thể có nghĩa là bạn kết thúc với quyền truy cập lớn hơn, nhưng nó cũng có thể có nghĩa là bạn kết thúc với ít hơn.

Trình bày những thách thức bạn có trong một định dạng khách quan cho nhóm quản lý của bạn và yêu cầu họ hướng dẫn. Bài thuyết trình của bạn sẽ mạnh mẽ hơn rất nhiều nếu bạn cộng tác với những người khác cũng cần quyền truy cập, vì vậy tất cả các bạn có thể trình bày trường hợp của mình cùng một lúc.

Từ đó, công ty (quản lý) phải ưu tiên ai được quyền truy cập và khi nào. Đó là một quyết định kinh doanh mà họ cần phải đưa ra vì (thiếu) nguồn lực đang ảnh hưởng đến sự phát triển kinh doanh.


4
Một điều có thể giúp nói chuyện với quản lý là dự đoán lịch trình của bạn (hoặc các mốc quan trọng của bạn) khi truy cập thiết bị. Bạn chỉ có thể làm rất nhiều mà không có phần cứng trước mặt và nếu bạn nói rõ rằng ước tính là từ khi họ đưa nó cho bạn, thì quản lý có thể đưa ra quyết định với kiến ​​thức đầy đủ.
Michael Kohne

4

Bạn đang mù mã hóa hiệu quả.

Nếu quản lý không trả tiền cho các thiết bị thử nghiệm, thì khả năng xảy ra lỗi rất cao hoặc thậm chí việc phát triển mất nhiều thời gian hơn nếu bạn có thiết bị thực để sử dụng.

Chi phí của các thiết bị không cần phải được phân bổ hoàn toàn cho chu trình "phát triển". Có lẽ chúng có thể được chuyển vào sử dụng sản xuất, hoặc như một bản sao lưu. Họ thậm chí có thể được bán lại cũ ở nơi khác?

Hãy thử và tính chi phí cho các giai đoạn sửa lỗi, cả về thời gian và tiền bạc và hiển thị chi phí chung cho nhóm / công ty của bạn.


4

Tranh luận với sếp của bạn dễ dàng hơn nhiều khi bạn có một số con số, hoặc ít nhất là một số ưu và nhược điểm trong tay, vì vậy đề nghị của tôi là cố gắng thực hiện một phân tích chi phí so với benfit. Ý tưởng sơ bộ như thế này:

  • bạn mong đợi bao nhiêu nỗ lực phát triển để viết một trình giả lập thiết bị? (Lưu ý rằng trình giả lập thiết bị không thể thay thế 100% phần cứng ban đầu, đặc biệt là khi phần cứng có một số điểm bất ngờ).

  • bạn mong đợi bao nhiêu nỗ lực kiểm tra / gỡ lỗi mà không có một công cụ như vậy? Bao gồm các chi phí cho nhân viên phòng thí nghiệm của bạn vì bạn phải chặn phần cứng cho mục đích thử nghiệm. Bao gồm cả chi phí cho thời gian hệ thống không thể được sử dụng do lỗi và bạn gặp khó khăn khi tìm nguyên nhân gốc.

  • Bao nhiêu phần cứng bổ sung cho chi phí thử nghiệm?

  • bạn cần bao nhiêu thời gian để chặn phần cứng cho mục đích thử nghiệm?

Tất nhiên, thực tế có thể không đơn giản như vậy, và có rất nhiều biến số chưa biết trong phương trình này, nhưng hãy thử đưa ra một số ước tính và nơi bạn không chắc chắn, hãy hỏi những người khác từ môi trường của bạn.

Trình bày kết quả cho quản lý của bạn, thảo luận về các lựa chọn thay thế và sau đó để họ quyết định.


Tôi nghĩ bạn có nghĩa là không thể ở đây Lưu ý rằng một trình giả lập thiết bị có thể hiếm khi thay thế phần cứng ban đầu 100%, đặc biệt là khi phần cứng có một số điểm bất ngờ
Rémi

@ Rémi: có lẽ "hiếm khi" không phải là thứ tự thông thường của từ trong tiếng Anh? FWIW, tôi đã thay đổi câu trả lời của mình để làm cho điều này rõ ràng, cảm ơn vì đã trả lời.
Doc Brown

Tôi không nói tiếng Anh tự nhiên nhưng nó đọc lạ. cảm ơn
Rémi
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.