我正在開發一個構建機器人的小型有趣項目。 我們作爲程序員正在與構建機器人的人並行工作。所以我們經常會遇到這種情況，我們試圖運行改變後的軟件，而且製造商已經改變了硬件。如果軟件測試沒有運行，那麼確定軟件或硬件是否出現故障是非常困難的，如果集成失敗則更加糟糕。 有一些硬件可以自動測試這個問題。如何集成/單元測試軟件硬件接口
我們已經想出了一些破解方法，所以我們有rc的控制權讓機器人在沒有軟件的情況下通過一些運動確保他仍然可以工作。 然後，我們開始一些軟件測試，使機器人進入一些定義的數字，以顯示軟件的行爲與以前相同。但是這總是要花費很長時間才能完成，因爲你不能自動化它，並且有人必須開始測試，觀察測試並試圖弄清楚機器人是否應該做它應該做的事情。
另一個問題是，用我們真實的硬件進行持續測試會損壞硬件，接頭，電機，齒輪等部件。
但是沒有測試已經證明會導致如此多的麻煩，並且消耗了太多的時間，我想知道在處理硬件軟件交互的其他項目中使用了哪種技術，以及是否有可用的工具使用。
機器人與軟件之間的接口必須先定義;不一定詳盡，這可以逐步完成。從基本動作（向前，向後）開始很小，然後，一旦完全測試完畢，無論是單獨還是整合，都要添加一些行爲（例如向左轉，向右轉），重新測試。這樣，整個團隊就可以使用它在項目中學到的知識來擴展界面，從而儘可能減少界面的返工。
Progress before Hardware文章更詳細地描述了這樣的過程，重點介紹了測試驅動開發（TDD）方面。
另請參閱How to do TDD with hardware問題的答案。
我認爲這是一個非常有趣的情況。
我相信你的測試過程沒有問題。如果你嘲笑你的機器人並對這個模擬進行測試，那就很好。
如果硬件機器人與您的嘲弄機器人行爲不同，還有另一大問題：通信。
軟件和硬件之間的接口是「協議」規範。我認爲不得在沒有討論的情況下改變。硬件傢伙可能不會改變它，你也不是軟件傢伙！你只能一起改變它。在你的情況下，每個人都自己改變它。
在你的情況下，你的團隊似乎互相攻擊。因此，儘量把精力集中在你的界面上，特別是你的溝通中，而不是在你的集成測試中不管用。
我的建議是使用機器人的軟件模擬爲的唯一規範。所以你可以依靠你的模擬，並有一箇中心點來定義硬件和軟件之間的聯繫。
當軟件傢伙想改變它，好吧。他們必須與你討論，你會改變軟件模擬。如果硬件改變了，模擬不了，你就會道歉，因爲你是根據你的規範開發的。
祝你好運！