thực hành tốt nhất khi thử nghiệm đơn vị để phát triển nhúng

Tôi đang tìm kiếm một số chiến lược thực hành tốt nhất cho mã thử nghiệm đơn vị được viết cho hệ thống nhúng. Theo hệ thống nhúng, ý tôi là mã như trình điều khiển thiết bị, trình xử lý ISR, v.v., những thứ khá gần với kim loại.

Hầu hết các bài kiểm tra đơn vị là không thể nếu không kiểm tra nó trên phần cứng với sự trợ giúp của ICE. Đôi khi, bộ phận nhúng cũng cần được nối với các kích thích khác như công tắc cơ, động cơ bước và bóng đèn. Điều này thường xảy ra trong một thời trang thủ công, tự động hóa sẽ là tuyệt vời nhưng khó khăn và tốn kém để đạt được.

Cập nhật

Tôi đã bắt gặp một khung thử nghiệm C có vẻ khá thành công trong việc thử nghiệm các dự án nhúng. Nó sử dụng những ý tưởng của phần cứng chế giễu. Kiểm tra Unity , CMock và có thể cả Ceedling .

Cập nhật ngày 06 tháng 6 năm 2016

Đã qua cmocka - dường như được làm việc tích cực hơn.

Tôi sẽ loại bỏ các phụ thuộc phần cứng ở bước sớm nhất có thể, và xây dựng hệ thống trên các mô phỏng thử nghiệm / khai thác phần mềm, cho phép tất cả các loại khung kiểm tra. Thông thường, PC phát triển của tôi đã được sử dụng để kiểm tra 95% hoặc nhiều hơn hệ thống hoàn chỉnh. Chi phí của chi phí hoạt động thêm (một lớp trừu tượng khác) có thể dễ dàng lấy lại bằng mã sạch hơn được tạo ra do sự trừu tượng hóa đó.

Việc kiểm tra các bộ phận thực sự của một hệ thống nhúng thường là một ứng dụng riêng biệt (Kiểm tra đơn vị?) Có tác dụng ngăn chặn phần sụn vượt xa những gì ứng dụng thậm chí có thể hy vọng đạt được. Tự động hóa có thể được thực hiện - với chi phí, nhưng không phải là điển hình.

Trừ khi, đó là, bạn có ngân sách để xây dựng một khai thác phần cứng thử nghiệm đơn vị bao gồm cả ICE đầy đủ. Điều này là hoàn toàn tốt vì nhìn chung các xét nghiệm chức năng là nhỏ.

Một công cụ cần thiết để phát triển là một bộ truyền tín hiệu. Hệ thống nhúng sẽ có một số cách giao tiếp với hệ thống máy chủ (thông thường thông qua cổng nối tiếp dành riêng để gỡ lỗi). Sử dụng điều này để gửi dữ liệu thử nghiệm (tùy chọn tốt nhất là terse ascii được định dạng để nó cũng dễ dàng được mô phỏng bởi con người).

Tôi hoàn toàn không đồng ý với phần câu hỏi này của bạn: "tự động hóa sẽ rất tuyệt nhưng khó và tốn kém để đạt được".

Sử dụng TeraTerm làm công cụ tiêm tín hiệu cổng nối tiếp và viết một số macro TeraTerm (mất khoảng 20 phút), có một bộ kiểm tra tự động khổng lồ có thể chạy trên bất kỳ phần nào của hệ thống nhúng - cho dù là lớp trình điều khiển, O / S, lớp 4-5, v.v. TeraTerm: http://en.sourceforge.jp/projects/ttssh2/

Nếu cổng nối tiếp không có sẵn trên hệ thống nhúng, thì hãy sử dụng công cụ phần cứng để chuyển đổi dữ liệu cổng USB / cổng nối tiếp thành tín hiệu số (cũng không tốn kém và dễ đạt được). Khi bạn đọc điều này, tôi đang sử dụng bảng vi điều khiển $ 30 (UBW: http://www.schmalzhaus.com/UBW32/ ) để kiểm tra một hệ thống nhúng để sản xuất, bằng cách tiêm kích thích thông qua macro TeraTerm được gửi qua USB / nối tiếp bộ vi điều khiển đang chạy chương trình cơ sở sửa đổi thực hiện các đầu vào kỹ thuật số và giám sát các đầu ra kỹ thuật số của hệ thống nhúng mục tiêu. Kết hợp với điều này, chúng tôi đã phát triển một kịch bản python (sử dụng pyserial và pectect) để tự động hóa việc tiêm dữ liệu và xác thực dữ liệu. Không có cái nào khó và cái nào cũng đắt. Theo kinh nghiệm của tôi, các nhà quản lý đã chi những khoản tiền lớn (chẳng hạn như thiết bị thử nghiệm trị giá 30.000 đô la) khi nhóm thử nghiệm thiếu kinh nghiệm và không thể hình dung được các giải pháp dễ dàng này - thật không may, thiết bị lớn bằng sắt thường không bao gồm các trường hợp thử nghiệm trong đó bắt thời gian trường hợp xấu nhất / vv của hệ thống đích. Vì vậy, phương pháp rẻ tiền là thích hợp cho bảo hiểm thử nghiệm. Tin hay không.

Đây là một vấn đề rất khó khăn.

Tôi thực sự đã thiết kế một khai thác thử nghiệm đơn vị cho một hệ thống nhúng, cho phép mô phỏng các sự kiện / ngắt phần cứng và kiểm soát thời gian thực hiện (để đảm bảo chúng tôi bao gồm tất cả các xen kẽ có thể do đồng thời) và phải mất một nhóm lập trình viên hơn 2 năm để thực sự thực hiện nó và đưa nó vào hoạt động. Dự án đó là một sự phát triển độc quyền, nhưng một dự án tương tự (đơn giản hơn trong thiết kế) có sẵn ở đây .

Vì vậy, có, tự động hóa sẽ là tuyệt vời. Vâng, nó rất khó khăn và tốn kém để đạt được. Vâng, đôi khi bạn phải làm điều đó. Hiếm khi, theo kinh nghiệm của tôi trong hầu hết các trường hợp, nhanh hơn và rẻ hơn để sử dụng động cơ bước và bóng đèn và làm cho tất cả hoạt động bằng tay.

Chỉnh sửa: câu trả lời của tôi gần với mattnz, tôi nghĩ ...

Tôi muốn liên hệ vấn đề này với những người khác, tất cả các thử nghiệm phụ thuộc vào thứ gì đó bên ngoài mã của bạn (như đồng hồ hệ thống, hệ thống tệp liên tục hoặc cơ sở dữ liệu, liên hệ với dịch vụ web bên ngoài ...). Tôi đề nghị chính sách tương tự cho tất cả chúng, cô lập hai cấp độ trong hai lớp mã.

Kiểm tra một hoạt động bên ngoài duy nhất

Bạn có thể muốn kiểm tra thể chất từng thao tác. Kiểm tra xem đồng hồ hệ thống có đưa ra thời gian chính xác không, kiểm tra một tệp thực sự ghi nhớ những gì đã được viết, kiểm tra một thiết bị nhận được một thao tác ...

Những xét nghiệm này:

• nên đơn giản nhất có thể: không có thuật toán nào, không có điều kiện hoặc vòng lặp
• có thể phụ thuộc vào đơn hàng và phụ thuộc vào máy: vì vậy bạn cần tuân theo một trật tự nghiêm ngặt và lặp lại trên mỗi phần cứng
• Hầu hết ổn định trong suốt dự án của bạn, vì vậy bạn không cần phải chạy chúng thường xuyên
• vì vậy chạy chúng bằng tay là một tùy chọn; tự động hóa thậm chí còn tốt hơn, nếu không quá phức tạp
• Lưu ý rằng những gì đang được kiểm tra không phải là mã của bạn , nó là một công cụ mà mã của bạn cần ... Vì vậy, việc kiểm tra này có thể là tùy chọn cho bạn, nó có thể được thực hiện bởi một nhóm khác ...

Kiểm tra logic (mã, thuật toán) liên kết các hoạt động bên ngoài

Bằng cách có một lớp mã để thực hiện các hoạt động bên ngoài thực tế, bằng cách ẩn chúng theo một giao diện mà bạn có thể dễ dàng chế giễu, logic của bạn không còn phụ thuộc vào các thiết bị vật lý thực tế nữa ...

Bạn có thể kiểm tra một cách đơn giản, như bất kỳ dự án thông thường nào, bạn không ở trong mã khó kiểm tra nhúng nữa .

Các trình giả lập CPU nhúng thường có thể được lập trình để mô phỏng phần cứng. Tất cả các công nghệ ảo hóa khác ngoài Xen làm điều đó. Nhưng bạn cần viết mã giả vờ có một số thanh ghi tại một số địa chỉ vật lý hoặc, trên x86, một địa chỉ trên bus I / O, và sau đó bạn cần trả lời đọc và ghi vào các địa chỉ này như thể phần mềm của bạn là vật lý chip có bộ điều khiển và thanh ghi trạng thái đang được truy cập.

Nếu bạn muốn làm điều này, tôi sẽ đề nghị sửa đổi QEMU. Nhưng nó sẽ không dễ dàng. Loại điều này thường chỉ được thực hiện khi bạn đang thiết kế chip tùy chỉnh với vi điều khiển và một số lõi khác cho I / O của bạn.

Hệ thống phát triển được bán bởi ARM Holdings cung cấp cho điều này và có khả năng hoạt động dễ dàng hơn so với hack trên QEMU, nhưng rất tốn kém.

Có một số trình giả lập ARM mã nguồn mở chạy một chương trình con duy nhất, mà chính nó có thể gọi các chương trình con khác, mà bạn có thể sử dụng để gỡ lỗi điều chỉnh hiệu năng của các chương trình con không phụ thuộc vào truy cập phần cứng. Tôi đã sử dụng một trong những thứ này để thành công lớn để tối ưu hóa bộ mã hóa AES cho ARM7TDMI.

Bạn có thể viết một khai thác kiểm tra đơn vị đơn giản bằng C hoặc C ++, liên kết lớp hoặc chương trình con được kiểm tra với nó, sau đó chạy nó trong trình giả lập.

Tôi đã suy nghĩ một vấn đề tương tự trong nhiều năm, làm thế nào để kiểm tra mã hạt nhân Linux hoặc Mac OS X. Điều đó là có thể, nhưng tôi chưa bao giờ thực sự thử. Một cách có thể là xây dựng một kernel đầy đủ thay vì kiểm tra mã của bạn một cách riêng lẻ, với khung kiểm tra đơn vị được liên kết trực tiếp vào kernel của bạn. Sau đó, bạn sẽ loại bỏ các bài kiểm tra đơn vị từ một số loại giao diện bên ngoài.

Có lẽ sẽ hiệu quả hơn khi sử dụng một công cụ bao phủ mã, sau đó kiểm tra phần sụn của bạn như một gói hoàn chỉnh thông qua giao diện bên ngoài. Công cụ bảo hiểm sẽ tìm các đường dẫn mã chưa được thử nghiệm, do đó bạn có thể thêm các thử nghiệm bên ngoài bổ sung để cố gắng có thêm phạm vi bảo hiểm.

Như với TDD không nhúng, các đối tượng giả chắc chắn là bạn của bạn.

Giữ giao diện cho phần cứng bên dưới của bạn sạch sẽ và đơn giản để mọi thứ ở mức thấp nhất có thể bị chế giễu và bạn sẽ có thời gian dễ dàng hơn nhiều - nếu bạn thiết kế ứng dụng nhúng của mình với khả năng kiểm tra thì việc kiểm tra sẽ luôn suôn sẻ hơn .

Ngoài ra, chỉ vì bạn có thể không thể kiểm tra trực tuyến cho đến khi khá muộn trong dự án không có nghĩa là bạn cũng không nên chuẩn bị một bộ các bài kiểm tra trực tuyến.

Những thứ này (ban đầu) chỉ cần kiểm tra các bit không thể được kiểm tra ngoại tuyến. Chắc chắn, đó không phải là TDD (vì bạn đang tạo các bài kiểm tra trước) nhưng việc phát triển TDD ngoại tuyến của bạn sẽ cho bạn ý tưởng tốt về giao diện phần cứng của bạn cần trông như thế nào và do đó bạn cần thực hiện các bài kiểm tra trực tuyến nào.

Ngoài ra, nếu phát triển trực tuyến có chi phí cao hơn nhiều so với phát triển ngoại tuyến (như nơi tôi làm việc) thì nó có thể giúp bạn tiết kiệm rất nhiều thời gian trực tuyến khi có một bộ thử nghiệm được hiểu rõ để chạy qua.

Trong phát triển nhúng, bạn thường thực hiện quét ranh giới để xác minh toàn bộ ứng dụng (bao gồm cả phần cứng) hoạt động. Cũng xem JTAG để gỡ lỗi hệ thống.

Việc kiểm tra các thói quen phần mềm thuần túy không có liên kết đến phần cứng có thể được thực hiện bằng khung Kiểm tra đơn vị C tiêu chuẩn như Kiểm tra . Nhưng hãy cẩn thận với những hạn chế về bộ nhớ (đặc biệt là stackspace, v.v. trên các thiết bị nhỏ). Biết hợp đồng của bạn! Bạn cũng có thể cố gắng trừu tượng hóa các thói quen phần mềm từ phần cứng để có được phạm vi kiểm tra lớn hơn nhưng điều này thường tốn kém về hiệu năng trên các thiết bị nhúng như PIC nhỏ hoặc AVR. Tuy nhiên, bạn có thể giả định các cổng phần cứng để đạt được phạm vi bảo hiểm lớn hơn (và tất nhiên bạn cũng có thể kiểm tra giả đó).

Bạn cũng có thể thử sử dụng trình giả lập cho chip hoặc bộ mô phỏng mạch, nhưng những loại công cụ này đắt tiền (đặc biệt là kết hợp) và phức tạp.