我正在开发一个构建机器人的小型有趣项目。 我们作为程序员正在与建造机器人的人并行工作。因此，我们经常尝试运行已更改的软件并且构建器已更改硬件。如果软件测试没有运行，那么确定软件或硬件是否出现故障总是很难，如果集成失败则更糟糕。 有一些硬件可以自动测试这个问题。
我们已经找到了一些破坏方法，所以我们有控制权让机器人在没有软件的情况下通过一些动作来确保他仍在工作。 然后我们开始一些软件测试，使机器人运行一些定义的数字，以显示软件的行为与以前一样。但这总是归结为一个非常耗时的任务，因为你不能自动化它，有人必须开始测试，观察测试并试图弄清楚机器人是否应该做它应该做的事情。
另一个问题是，使用我们的真实硬件进行的持续测试会损坏我们的硬件，接头，电机，齿轮等部件。
但是测试已经证明不会造成太多麻烦并且消耗了太多时间我想知道在其他涉及硬件软件交互的项目中使用了哪种技术，以及是否有可以使用的工具使用
答案 0 :(得分：9)
必须首先定义机器人和软件之间的接口;不一定详尽无遗，这可以逐步完成。从小开始，例如基本移动（向前，向后），然后，一旦完全测试，无论是隔离还是集成，添加一些行为（例如左转，右转），重新测试。这样，整个团队可以使用它在整个项目中学到的东西来扩展界面，可能最大限度地减少界面返工。
Progress before Hardware文章更详细地描述了这样一个过程，重点关注测试驱动开发（TDD）方面。
另见How to do TDD with hardware问题的答案。
答案 1 :(得分：2)
我认为这是一个非常有趣的情况。
我相信您的测试过程没有问题。如果你嘲笑你的机器人并对这个模拟器进行测试，这一切都很好 如果硬件机器人与您的模拟机器人的行为不同，则还有另一个大问题：通信。
软件和硬件之间的接口是“协议”规范。在我看来，没有讨论就不能改变。硬件人员可能不会改变它，而软件人员也不会改变它！你只能一起改变它。在你的情况下，每个人都自己改变它。
在您的情况下，您的团队似乎互相攻击。因此，请尽量将精力集中在您的界面上，尤其是您的沟通，而不是集成测试，无论如何都不会。
我的建议是使用机器人的软件模拟唯一规范。因此，你可以依靠你的模拟，并有一个中心点，定义硬件和软件之间的连接 当软件人想要改变它时，好吧。他们必须与您讨论，您将更改软件模拟。如果硬件被更改而模拟没有，那么您有道歉，因为您的规范是根据您的规范进行的。
祝你好运！