Conformité logicielle DO-178C pour l'aérospatiale et la défense

Dans le cadre de la plupart des processus de développement de logiciels, des tests de régression sont effectués après que des modifications ont été apportées au logiciel. Ces tests déterminent si les nouvelles modifications ont eu un impact sur le fonctionnement existant du logiciel.

La norme DO-178C ne mentionne pas explicitement les tests de régression, mais il s'agit d'une bonne pratique d'ingénierie largement utilisée dans l'industrie aérospatiale pour vérifier la stabilité et l'exactitude du logiciel tout au long de son cycle de développement. Les exigences relatives au processus d'intégration du logiciel et du matériel impliquent la nécessité de maintenir une vérification et une validation à jour après toute modification.

Les tests de régression sont nécessaires, mais ils indiquent seulement que les récentes modifications du code n'ont pas provoqué l'échec des tests. Rien ne garantit que ces changements fonctionneront. En outre, la nature des changements qui justifient la nécessité d'effectuer des tests de régression peut aller au-delà de l'application actuelle et inclure des modifications du matériel, du système d'exploitation et de l'environnement d'exploitation.

Tests de régression de logiciels dans les systèmes aéroportés

Dans le développement de logiciels critiques pour la sécurité, la validation est essentielle pour prouver le bon fonctionnement, la sécurité et la sûreté. Les tests sont nécessaires pour deux raisons principales.

1. Confirmez toutes les modifications apportées à l’application pour garantir sa fonctionnalité.
2. Vérifiez qu’il n’y a pas d’impacts imprévus sur le reste du système.

Si un cas de test a réussi mais échoue maintenant, une régression potentielle a été identifiée. L'échec peut être dû à une nouvelle fonctionnalité, dans laquelle le cas de test peut devoir être mis à jour afin de prendre en compte les modifications des valeurs d'entrée et de sortie.

Les tests de régression des systèmes embarqués incluent également l’exécution des types de cas de test suivants :

• Unité
• Intégration :
• Système
• Performances
• Stress et plus

En fait, tous les cas de test créés précédemment doivent être exécutés pour garantir qu'aucune régression n'existe et qu'une nouvelle version fiable du logiciel est créée. Cela est essentiel car chaque nouvelle version d'un système ou d'un sous-système logiciel est construite sur cette base. Si vous n'avez pas de base solide, tout peut s'effondrer.

Parasoft C/C++test prend en charge la création de bases de test de régression sous forme d'un ensemble organisé de tests et vérifie automatiquement tous les résultats. Ces tests sont exécutés automatiquement à intervalles réguliers pour vérifier si les modifications de code modifient ou interrompent la fonctionnalité capturée dans les tests de régression. Si des modifications sont introduites, ces cas de test ne parviendront pas à alerter l'équipe du problème. Lors des tests suivants, C/C++test signalera les tâches s'il détecte des modifications du comportement capturé dans le test initial.

Comment décider quel test de régression effectuer

Le principal défi des tests de régression est de déterminer les parties d'une application à tester. Il est courant de procéder par défaut à l'exécution de tous les tests de régression lorsqu'il existe un doute sur l'impact des modifications récentes du code : c'est l'approche du tout ou rien.

Pour les grands projets logiciels, cela devient une entreprise énorme et réduit la productivité de l'équipe. Cette incapacité à cibler les tests entrave une grande partie des avantages des processus itératifs et continus, potentiellement exacerbés dans les logiciels embarqués où les cibles de test constituent une ressource limitée.

Quelques tâches sont requises ici.

• Identifiez les tests qui doivent être réexécutés.
• Concentrez les efforts de test (tests unitaires, tests fonctionnels automatisés et tests manuels) sur la validation des fonctionnalités et du code associé qui sont impactés par les modifications les plus récentes.

Les développeurs et les testeurs peuvent obtenir une compréhension claire des changements dans la base de code entre les builds en utilisant le Process Intelligence Engine (PIE) dans Parasoft DTP (Development Testing Platform) combiné aux moteurs d'analyse de couverture propriétaires de Parasoft :

Grâce à cette combinaison, les équipes peuvent améliorer leur efficacité et tenir les promesses de la méthode Agile. Cette forme d'exécution intelligente des tests est appelée analyse d'impact des tests. On l'appelle parfois test basé sur les changements.

Comprendre l'impact des changements de code sur les tests avec l'analyse d'impact des tests

Tester l'analyse d'impact utilise les données collectées lors des tests et les modifications de code entre les builds pour déterminer quels fichiers ont changé et quels tests spécifiques ont touché ces fichiers. Le moteur d'analyse de Parasoft peut :

• Analyser le delta entre deux builds.
• Identifiez le sous-ensemble de tests de régression qui doivent être exécutés.
• Comprendre les dépendances des unités modifiées pour déterminer l’effet d’entraînement que les changements ont eu sur les autres unités.

Parasoft Jtest et dotTEST permettent d'évaluer l'impact des modifications logicielles. Chaque solution recommande où ajouter des tests et où des tests de régression supplémentaires sont nécessaires.