Actuellement, un de nos systèmes de production est géré par plus de 3000 programmes écrits entre 1986 et maintenant. La base de code est écrite dans un langage non standard, qui manque malheureusement d'outils de test modernes. Dans le but d'améliorer la qualité de notre code à l'avenir, j'ai travaillé à l'intégration de processus et à la création d'outils qui amélioreront le développement et les tests. J'ai juste complètement un outil de couverture de ligne afin que nous puissions aider à identifier le code mort + le code non testé pendant le développement.Ecriture d'un outil de couverture de chemin
Maintenant, je voudrais commencer à travailler sur l'ajout de couverture de chemin à l'outil.
Comment dois-je procéder?
étant donné que:
1) L'outil de couverture de ligne agit comme un pré-processeur qui injecte du code
2) Je possède déjà la capacité de recueillir les statistiques I ensemble dans ledit code. Quelles données devrais-je enregistrer pendant l'exécution du programme et comment l'interpréter?
Comment puis-je représenter les résultats via HTML? J'ai déjà lu la question How to get started “writing” a code coverage tool?, qui était sur Java, mais cela n'a pas aidé (y compris le document "Couverture de branche pour les langues arbitraires Made Easy").
Merci d'avance pour toute indication donnée!
Avez-vous déjà vu le livre "Travailler efficacement avec le code existant"? –
Je suis curieux de savoir pourquoi vous voulez une couverture de chemin. J'ai travaillé sur l'avionique certifiée à la satisfaction de la FAA (DO-178b niveau B et C seulement, jamais niveau A), et nous avons seulement fait la couverture des déclarations. La couverture de la déclaration de l'OMI a un faible avantage, si vous êtes déjà engagé dans des tests unitaires de haute qualité (ex: un bon ingénieur écrira de bons tests (même sans outil de couverture), pas un mauvais ingénieur (même si la couverture l'outil leur indique que leur test est déficient)). Il y a bien sûr des moments où l'outil de couverture vous invite à écrire un test dont vous ne saviez pas que vous aviez besoin d'écrire, mais cela semblait rare. – KeyserSoze
@Robert. Pas jusqu'à maintenant. @keysersoze. La couverture des déclarations ne suffit pas à la réduire. Nous avons eu de nombreux exemples d'échec de code dans la production en raison d'une combinaison spécifique et non testée de conditions. De plus, la nature de la base de code actuelle empêche le test unitaire automatisé. Le test de la trajectoire servirait non seulement d'outil pour découvrir des choses que nous n'avions pas envisagées de tester, mais aussi de vérification que les tests manuels ont bien été effectués. Ai-je mentionné que c'est un code legecy avec presque aucune documentation, y compris ce que nous devrions tester? –