Comment faire pour intégrer / tester les interfaces matérielles du logiciel

Question

Je travaille sur un petit projet amusant qui construit un robot. En tant que programmeurs, nous travaillons parallèlement aux personnes qui construisent le robot. Donc, très souvent, nous essayons d’exécuter un logiciel modifié et les constructeurs ont modifié le matériel. Si les tests logiciels ne sont pas en cours, il est toujours difficile de déterminer si le logiciel ou le matériel échoue, voire pire si l'intégration échoue. Il existe certaines parties difficiles avec un test automatique de ces problèmes.

Nous avons trouvé des moyens de décomposer les choses. Nous avons donc le contrôle de laisser le robot effectuer certains mouvements sans logiciel, ce qui garantit qu’il fonctionne toujours. Ensuite, nous commençons des tests logiciels qui obligent le robot à utiliser des chiffres définis pour montrer que le logiciel se comporte de la même manière qu'auparavant. Mais cela revient toujours à une tâche très fastidieuse, car vous ne pouvez pas l’automatiser et quelqu'un doit commencer le test, le surveiller et essayer de déterminer si le robot a fait ce qu’il devrait faire.

Un autre problème est que les tests constants menés avec notre matériel réel épuisent les pièces de notre matériel, joints, moteurs, roues dentées, etc.

.

Mais il n’est pas prouvé que les tests causaient tant de problèmes et prenaient tellement de temps que je voudrais savoir quel type de techniques sont utilisées dans d’autres projets traitant de l’interaction logiciel / logiciel et s’il existe des outils qui pourraient être utilisés. utilisé.

Answer 1

L’interface entre le robot et le logiciel doit être définie en premier lieu; pas nécessairement de manière exhaustive, cela pourrait se faire progressivement. Commencez petit, par exemple avec des mouvements de base (en avant, en arrière), puis, une fois que le test a été entièrement testé, à la fois de manière isolée et intégrée, ajoutez un comportement (par exemple, tournez à gauche, tournez à droite), retestez. De cette manière, toute l'équipe peut utiliser ce qu'elle a appris tout au long du projet pour étendre l'interface, en minimisant éventuellement les révisions d'interface.

L'article Progression avant le matériel décrit plus en détail un tel processus, en se concentrant sur l'aspect TDD (Test-Driven-Development).

Voir aussi les réponses à la question Comment utiliser TDD avec du matériel .

Answer 2

Je pense que c'est une situation très intéressante.

Je pense que votre processus de test ne pose aucun problème. Si vous vous moquez de votre robot et testez contre cette maquette, c'est tout bon.
Si le robot matériel agit différemment en tant que robot simulé, il existe un autre gros problème: La communication .

L’interface entre le logiciel et le matériel est le "protocole". spécification. À mon avis, cela ne doit pas être changé sans discussion. Les gars du matériel ne peuvent pas le changer et vous, les logiciels, non plus! Vous pouvez seulement le changer ensemble. Dans votre cas, tout le monde le change tout seul.

Dans votre situation, vos équipes semblent travailler les unes contre les autres. Essayez donc de concentrer vos efforts sur votre interface et en particulier sur votre communication, et non sur votre test d’intégration qui ne fonctionnera pas.

Une de mes suggestions serait d'utiliser le modèle d'un logiciel de robot comme spécification unique . Vous pouvez donc compter sur votre maquette et un point central définit la connexion entre le matériel et les logiciels.
Quand les gars du logiciel veulent le changer, d'accord. Ils doivent en discuter avec vous et vous allez changer le logiciel. Si le matériel a été modifié et que la maquette ne l’a pas été, vous avez des excuses, car vous avez évolué selon vos spécifications.

Bonne chance!