Làm cách nào để viết bài kiểm tra đơn vị cho robot (và các thiết bị cơ khí khác)?


22

Tôi là thành viên của câu lạc bộ người máy ở trường trung học của tôi và chịu trách nhiệm lập trình cho robot. Một đề nghị tôi tiếp tục nghe từ nhiều người lớn khác là tôi nên viết bài kiểm tra đơn vị để giúp xác thực mã của mình. Cơ sở mã đang trở nên hơi lớn và tôi đồng ý rằng các bài kiểm tra đơn vị sẽ thực sự hữu ích trong việc giúp tôi bắt lỗi nhanh hơn.

Tuy nhiên, tôi không hoàn toàn chắc chắn làm thế nào tôi có thể hoàn thành việc này. Theo hiểu biết tốt nhất của tôi, kiểm thử đơn vị được thực hiện bằng cách lấy một hàm (hoặc một hệ thống con của mã) và cung cấp cho nó một bộ đầu vào để đảm bảo rằng nó xuất hiện với cùng một đầu ra mỗi lần. Mã mà tôi hiện không có bất kỳ khủng hoảng dữ liệu nặng nào, mà là thao tác trực tiếp các thành phần phần cứng trên robot. Hầu hết sự phức tạp đến từ việc đảm bảo rằng các thiết bị điện tử là âm thanh, mã tại thời điểm phù hợp với phần cứng thực tế trên robot, v.v. Thông thường, tôi chỉ có thể xem liệu có vấn đề gì không bằng cách tải mã vào chính robot, và cố gắng để chạy nó.

Bằng cách mở rộng, làm thế nào các bài kiểm tra đơn vị có thể được viết cho mã có nghĩa là để vận hành bất kỳ thiết bị cơ khí nào? Dường như với tôi rằng bạn chỉ có thể bắt lỗi bằng cách quan sát thực tế hoạt động của máy.

Hay tôi chỉ hiểu sai về cách kiểm tra đơn vị nên làm việc?

( Nếu có vấn đề, đây là , nó được viết bằng C ++ và tôi đang tham gia FRC )

Câu trả lời:


21

Bạn sẽ cần phải giả định lớp phần cứng để thực hiện kiểm tra này. Ý tưởng là thay vì mã của bạn nói chuyện với phần cứng thực tế, bạn nói chuyện với phiên bản giả của phần cứng mà bạn có thể kiểm soát và sau đó sử dụng để xác minh rằng mã của bạn đang hoạt động chính xác.

Thật không may, có một số vấn đề bạn phải khắc phục:

  • Việc chế nhạo mọi thứ trong các ngôn ngữ tương đối thấp là khó khăn hơn (và do đó, nhiều công việc hơn)
  • Việc chế tạo công cụ ở cấp độ phần cứng khó khăn hơn (và do đó, công việc nhiều hơn)

Ngoài ra, hầu hết giá trị của kiểm thử đơn vị, tự động đến từ việc có thể chạy thử nghiệm của bạn bất cứ lúc nào để bắt lỗi hồi quy trong thời gian dài sau khi bạn viết mã gốc. Với các loại cuộc thi này, mã của bạn sẽ hoàn toàn không được sử dụng sau khi cuộc thi kết thúc, vì vậy bạn sẽ không thực sự nhận được hầu hết giá trị trong các bài kiểm tra. Và xem xét mức độ khó khăn khi thêm các bài kiểm tra vào trường hợp cụ thể của bạn, có thể sử dụng thời gian của bạn tốt hơn để chỉ kiểm tra thủ công và tập trung vào các tính năng cho cuộc thi.


1
Câu trả lời tốt đẹp. Đặc biệt là một chút về thực tế là mã sẽ không được sử dụng sau cuộc thi và lợi ích lớn của các bài kiểm tra đơn vị tự động sẽ xuất hiện sau khi các bài kiểm tra được viết. Bạn có thể xem xét tự động hóa một số bài kiểm tra của mình trong trường hợp bạn thấy mình chạy thử nghiệm tương tự lặp đi lặp lại; Nhưng cho đến khi điều này xảy ra, không có nhiều điểm.
Dawood nói phục hồi Monica

Không cần phải Mock phần cứng cả. Nếu robot đã đăng nhập, hãy chạy chương trình thử nghiệm và quan sát nhật ký. Thử nghiệm cuối cùng cần quan sát "rẽ trái" trong nhật ký nên tương ứng với việc robot rẽ trái. Bạn sẽ cần phải viết một khai thác thử nghiệm để giả lập các thiết bị đầu vào - móc mã thiết bị đầu vào càng gần lớp phần cứng càng tốt
mattnz

4
@DavidWallace Là một thực phẩm nhỏ để suy nghĩ, khi sử dụng TDD / BDD, lợi ích của thử nghiệm đơn vị xảy ra ngay lập tức. Ở nơi đầu tiên bằng cách cho phép mã được tự tin tái cấu trúc ngay lập tức và thứ hai bằng cách khuyến khích thực hiện được giới hạn ở mức thực hiện tối thiểu cần thiết để đáp ứng các thử nghiệm.
S.Robins

4
@mattnz ý tưởng tồi, và tôi biết từ kinh nghiệm. Điều gì sẽ xảy ra nếu mã được kiểm tra thất bại rất mạnh và robotarm đâm vào tường, làm hỏng một phần cứng xxxx $ ???
stijn

2
@mattnz: Robot của chúng tôi cao khoảng 2 feet 3 feet 4 và nặng khoảng 150 pounds. Bộ / đăng ký có giá 5 nghìn đô la mỗi năm và chúng tôi thường gây quỹ từ 5 đến 10k để mua thêm các bộ phận. Trường hợp xấu nhất có thể sẽ có giá hơn 10 đô la;)
Michael0x2a

10

Tôi có thể nghĩ về một vài điều mà bạn sẽ cần phải xem xét. Đầu tiên là làm cho lớp truy cập phần cứng của bạn mỏng nhất có thể, ngay cả khi điều đó có nghĩa là tạo ra một lớp bao bọc cơ bản cho lớp đó. Điều này cung cấp cho bạn một vài lợi thế. Đầu tiên là nó cho phép bạn cách ly các hành vi cụ thể về phần cứng của mã của bạn khỏi chính quyền truy cập phần cứng, điều đó có nghĩa là bạn có thể kiểm tra mọi thứ xuống tận cùng của phần cứng mà không cần phải truy cập vào phần cứng.

Ví dụ: nếu bạn cần thiết kế giao thức báo hiệu dựa trên I2C, bạn có thể kiểm tra mã của mình đang tạo tín hiệu I2C chính xác mà không cần nối phần cứng vào các thử nghiệm.

Đối với các cuộc gọi đến phần cứng thực tế, bạn có thể kiểm tra xem chúng có hoạt động chính xác không bằng cách chế nhạo lớp phần cứng của bạn và đây là nơi giữ cho lớp phần cứng rất mỏng thực sự được đền đáp, vì bạn có thể giảm giả của mình chỉ cần xử lý các chức năng tối thiểu cần thiết để thực sự giải quyết phần cứng, nhưng bạn không nhất thiết phải tự kiểm tra các tín hiệu riêng lẻ, vì tất cả tín hiệu của bạn phải được kiểm tra ở mức cao hơn. Điều này có nghĩa là sau đó bạn sử dụng giả của mình để kiểm tra xem các cuộc gọi được thực hiện cho các phương thức phần cứng cụ thể khiến tín hiệu của bạn được gửi đến phần cứng. Nếu bạn cần thăm dò phần cứng, thì giả của bạn chỉ có thể kích hoạt các sự kiện hoặc phương thức trong mã của bạn, bởi vì một lần nữa, tín hiệu trở lại của bạn sẽ được xử lý ở lớp cao hơn.

Điều này về cơ bản phù hợp với những gì Oleksi đã nói trong câu trả lời của mình , ở chỗ thường làm việc nhiều hơn để chế nhạo các công cụ ở cấp độ phần cứng, tuy nhiên sẽ không quá khó nếu bạn giữ lớp mã cuộc gọi / mã tối thiểu nhất có thể mà bạn có thể thực hiện cho phần cứng.

Khi bạn có mã vượt qua tất cả các bài kiểm tra của nó, bạn vẫn sẽ cần phải chạy qua một loạt các bài kiểm tra thủ công để đảm bảo bạn đã xử lý mọi thứ chính xác trong lớp phần cứng của mình.

Một điều khác xuất hiện trong tâm trí ngoài việc chế giễu và xếp lớp, là sử dụng thực hành phát triển thử nghiệm đầu tiên. Về cơ bản, bạn mã hóa các yêu cầu của bạn làm tiêu chí kiểm tra và bạn căn cứ vào việc thực hiện các bài kiểm tra của mình. Điều này sẽ giúp bạn đảm bảo bạn giữ mã triển khai ở mức tối thiểu, đồng thời đảm bảo tất cả các trường hợp thử nghiệm của bạn đang thúc đẩy nỗ lực phát triển của bạn. Bằng cách không lãng phí quá nhiều thời gian cho các mã có khả năng không quan trọng khác mà bạn có thể muốn thực hiện "chỉ vì", trước tiên, kiểm tra giúp bạn tập trung và sẽ giúp thay đổi mã của bạn dễ dàng hơn khi bạn gỡ lỗi, cũng như việc sử dụng kiểm tra đơn vị của bạn và giả. Gỡ lỗi phần mềm thông qua phần cứng nổi tiếng là phức tạp và hút một lượng lớn thời gian của bạn mà bạn sẽ thấy tốt hơn dành cho các nhiệm vụ khác.


2

Tôi có thể cho bạn biết cách họ thực hiện trên Trình mô phỏng bay

Đầu tiên, bạn sẽ chỉ nhận được một nửa câu trả lời nếu bạn chỉ đặt câu hỏi này cho các lập trình viên, vì vậy bạn có thể nên đăng bài này trên http://electronics.stackexchange.com trong khi bạn đang ở đó.

Tôi chưa từng làm việc với robot nhưng tôi đã dành 5 năm để làm phần cứng cho các trình mô phỏng bay để tôi có thể cho bạn biết kiến ​​trúc của chúng hoạt động như thế nào.

Lớp phần cứng bị câm

Nó chứa một giao diện cơ bản nơi bạn có thể điều chỉnh các giá trị đầu vào / đầu ra đơn giản và đặt các điểm dừng nội suy cho các tín hiệu tương tự. Khi bạn làm việc với phần cứng 'mới', mọi thứ sẽ hoạt động như mong đợi với rất ít hoặc không cần hiệu chuẩn nhưng theo thời gian, các bộ phận sẽ trải qua hao mòn cơ học và cần được điều chỉnh.

Hiệu chuẩn là một bảng đơn giản có chứa phần nằm trong khoảng giữa các giá trị tối thiểu / tối đa. Để đo đầu vào trên những cái này, một servo thường được sử dụng (ví dụ như chiết áp tuyến tính, đầu dò, gia tốc kế, v.v.). Hoặc trong trường hợp thiết bị, bạn chỉ cần đánh giá độ chính xác một cách trực quan và điều chỉnh cho đến khi hiệu chỉnh.

Lớp phần mềm thì ngược lại.

Mọi thứ đều phức tạp và được kết nối với nhau, vì vậy điều quan trọng là cô lập một số biến để kiểm tra chức năng. Không cần phải tự làm đau đầu khi nghĩ ra các kịch bản bởi vì việc chạy một số kịch bản thực tế nơi bạn có thể thu thập dữ liệu dễ dàng hơn nhiều. Khi bạn chạy thử nghiệm, về cơ bản, bạn đang đo dữ liệu được lưu trữ so với đầu ra hiện tại.

Trên một chuyến bay giả lập, điều này được gọi là một QTG (Hướng dẫn kiểm tra trình độ). Tại cốt lõi của nó, nó vẽ dữ liệu trên lưới 2D trong đó một chiều là thời gian và chiều còn lại là đầu ra.

Dù bạn có tin hay không, đó là bản chất của cách họ phát triển các mô hình. Một chiếc máy bay thực sự được trang bị rất nhiều cảm biến và bay xung quanh thực hiện các tình huống được kiểm soát. Bởi vì tất cả các điều khiển có thể được điều khiển mà không có sự tương tác của con người, các bài kiểm tra được chạy (tức là sim tự bay) bởi máy tính và dữ liệu được so sánh.

Mặc dù robot được tạo ra ở quy mô khác nhau, các nguyên tắc là như nhau. Cách tiếp cận truyền thống là cắt đứt hoàn toàn các lớp phần cứng và phần mềm để cả hai có thể được kiểm tra riêng lẻ. Đầu vào phần cứng được thu thập thông qua các servo và được thiết lập thông qua một giao diện độc lập. Đầu vào phần mềm có thể được đặt / đọc bằng cách đo độc lập và so sánh tín hiệu có thể đi đến phần cứng và vẽ nó với dữ liệu 'tốt' đã biết.

Bản thân các xét nghiệm không nhất thiết phải phức tạp miễn là kết quả có thể dự đoán, đo lường được và có thể lặp lại.


1

Như đã nói trước đó, giả và loại bỏ các phần cứng. Ví dụ, nếu bạn có một giao diện cho robot, bạn có thể kế thừa từ giao diện đó, và sau đó thực hiện các sơ khai đơn giản của nó. Sau đó, bạn có thể kiểm tra rằng việc triển khai còn sơ khai đã được gọi như mong đợi. Nếu đó là chức năng dự kiến ​​hoặc tham số dự kiến.

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.