Discussion :

[Invité]

Bonjour,

Je me posais la question de savoir comment vous faites pour tester vos logiciels ? quels méthodes, logiciels, .. ?

Par exemple dans ma société nous sommes 20 développeurs Delphi sur un seul logiciel d'environ 2.5 Mio de lignes de code, chaque développeur test ses ajouts et modifications mais il est fréquent de rajouter des bugs. Nous avons des formations en interne, de la lecture (comme les livres de Nick Hodges), nous venons d'acquérir FixInsight pour aider un peu en prévention des erreurs et avoir un code plus "propre", nous allons sans doute essayer d'avoir une méthode SOLID ...

Le développement du logiciel a commencé dans les années 2003-2005 et évolue toujours, seul les derniers modules sont en POO.

J'ai essayé DUnitX que je trouve pas super intuitif à utiliser, les macros qui sont longues à faire ..

Peut être avez vous des méthodes plus efficaces ?

Merci

[joc02]

Il n'y a pas forcément une méthode toute faite à mettre en oeuvre.
Elle dépend de pas mal de facteurs, et va varier d'une entreprise à une autre.


Quand on parle de test, on peut les classifier dans plusieurs domaines. Chaque domaine sera vu d'une façon différent. Par exemple, tu parles de DUnit, pour faire des tests unitaires, ceux-ci sont pilotés par code, peuvent intervenir dans un processus plus large avec un serveur d'intégration.
On parle aussi de tests de non-régression, souvent testé manuellement avec l'ancienne version et la nouvelle et on monte le jeu d'essai. Ce qui amène à l'écriture de scénario de test.
Pour revenir sur DUnit, certaines personnes travaillant en génie logiciel, estime le temps de codage du test presque aussi long que la fonctionnalité.


Voilà donc le sujet est à mon sens plus large qu'une simple réponse à une question.

[ShaiLeTroll]

Tu as des outils aussi comme TestComplete de SmartBear qui permet d'automatiser le tests mais au lieu d'écrire du code test avec DUnit*, tu peux enregistrer des actions à reproduire
Durant une période avec Delphi était fourni AQtime de SmartBear, qui je pense est un équivalent de FixInsight

* J'ai développé une application Serveur en PHP en appliquant la méthode TDD avec PHPUnit
Le code de test était plus long que le code à tester, cela testait les cas de succès, les cas d'erreur attendues, ... cela peut être très long, rien que la mise en place d'un contexte de base de données initiales permettant d'obtenir un résultat prévisible après le passage de la fonction testée

[Invité]

Merci pour vos réponses, je vais me renseigner sur TestComplete. Pour les scénarios entre le temps pour les créer et les dérouler je pense qu'il faut une personne à temps complet ..

[gaby277]

Bonjour,

chaque développeur test ses ajouts et modifications

Oui bien sur, mais il faut aussi qu'au moins une autre personne teste... Notamment car inconsciemment il va tester surtout le code qui a été difficile à écrire et il ne testera pas forcément des choses simples, qui pour lui marchent obligatoirement.

Par ailleurs il y a les bugs "fonctionnels" qui résultent d'une mauvaise compréhension, interprétation du cahier des charges (ou une rédaction imprécise, , ou ambiguë de ce dernier). Souvent des programmeurs n'ont pas de connaissances approfondies du métier . Donc pour les gros projets il est souhaitable q'un représentant des futurs utilisateurs effectue des tests, qui ne substituront pas à ceux du programmeur, mais les complèteront.

Il faut aussi des test en exploitation, surtout pour certains logiciels "temps réel" qui sont reliés à l'environnement (nombreuses entrées / sorties, messages d'autres systèmes informatique) pour détecter les bugs qui résultent de "saturations" du système.

Chercher uniquement "le meilleur logiciel" pour détecter tous les bugs d'un autre logiciel est pour moi peu réaliste, bien ça puisse être utile.