En résumé les tests unitaires sont souvent pris en charge par des librairies (ex : JUnit). Ils ne sont applicables que pour le code métier et peuvent donc être enchaînés automatiquement pour valider tout changement lors de build. Ils s'appuient parfois sur du bouchonnage grâce à des frameworks dédiés lorsqu'il y a des dépendances avec d'autres composants (ex EasyMock). Rajoute un petit test qui met en erreur lors de la découverte d'un nouveau bug et git bissect est ton ami pour retrouver une régression. On utilise aussi des outils de couverture de code pour vérifier que les tests couvrent un maximum de cas (ex : Emma).
Pour ce qui est de la partie interface utilisateur il n'y a pas de autre solution que d'enregistrer des scénarios de tests qui simulent le différents événements d'une IHM. Ensuite ceci est enregistré sous forme de macros dans un langage dédié et peut donc être modifié pour s'adapter aux changements mineurs d'interface. Ces outils doivent donc être adaptés pour chaque bibliothèque graphique. Mercury propose donc Quicktest Pro qui couvre beaucoup de bibliothèque. Pour des interfaces web, Sélénium fait largement l'affaire.
Après il reste à décrire des scénarios de tests fonctionnel qui permettent à la maîtrise d'ouvrage de valider la conformité du produit par rapport aux specs. Certaines parties ne sont pas automatisables. Les scénarios sont donc décrits étape par étape et lors d'une campagne de test, le testeur déroule les cas de test, valide les étapes et soumet les défauts lorsqu'il en rencontre. Mercury, leader du domaine, propose l'outil Quality Center à cet effet. C'est là je pense que se situe le produit présenté dans la dépêche. Ce qui est intéressant c'est qu'on dispose enfin d'une solution de test complète et libre avec tous les produits que j'ai cité.
Le bémol qui a été soulevé plus haut est que lorsqu'on découvre un défaut il est renseigné dans l'outil de test alors que des outils de suivi de demande de changement existent déjà, sont plus complets et sont souvent utilisés en amont du projet en phase de développement pour suivre les nouvelles fonctionnalités et pas seulement les défauts. Par ailleurs les défauts peuvent aussi être découverts en prod et soumis dans ces mêmes outils. Ici on parle de JIRA mais c'est pareil pour n'importe quel bugtracker (je préfère le terme issue tracking qui est plus juste pour traiter toutes les demandes pas seulement les bugs). Pour un outil de suivi de test fonctionnel il est donc important de pouvoir s'interfacer avec un outil de suivi des demande de changement plutôt que de réinventer la roue. Autant ça ce comprend pour Mercury qui cherche à étendre son périmètre dans les outils de gestion du cycle de vie (ALM) face à ses concurrents comme IBM, autant pour un outil libre c'est un peu dommage.
(削除) Dsl pour le style télégraphique mais vraiment les tablettes android sont pas au point (troll inside) (削除ここまで) [NdM : mise en forme et qqs corrections apportées depuis]
[^] # Re: positionnement par rapport à cTest
Posté par El Titi . En réponse à la dépêche Squash TM : nouvel outil pour la gestion du patrimoine de tests. Évalué à 5. Dernière modification le 26 avril 2012 à 10:56.
Oui,
En résumé les tests unitaires sont souvent pris en charge par des librairies (ex : JUnit). Ils ne sont applicables que pour le code métier et peuvent donc être enchaînés automatiquement pour valider tout changement lors de build. Ils s'appuient parfois sur du bouchonnage grâce à des frameworks dédiés lorsqu'il y a des dépendances avec d'autres composants (ex EasyMock). Rajoute un petit test qui met en erreur lors de la découverte d'un nouveau bug et
git bissectest ton ami pour retrouver une régression. On utilise aussi des outils de couverture de code pour vérifier que les tests couvrent un maximum de cas (ex : Emma).Pour ce qui est de la partie interface utilisateur il n'y a pas de autre solution que d'enregistrer des scénarios de tests qui simulent le différents événements d'une IHM. Ensuite ceci est enregistré sous forme de macros dans un langage dédié et peut donc être modifié pour s'adapter aux changements mineurs d'interface. Ces outils doivent donc être adaptés pour chaque bibliothèque graphique. Mercury propose donc Quicktest Pro qui couvre beaucoup de bibliothèque. Pour des interfaces web, Sélénium fait largement l'affaire.
Après il reste à décrire des scénarios de tests fonctionnel qui permettent à la maîtrise d'ouvrage de valider la conformité du produit par rapport aux specs. Certaines parties ne sont pas automatisables. Les scénarios sont donc décrits étape par étape et lors d'une campagne de test, le testeur déroule les cas de test, valide les étapes et soumet les défauts lorsqu'il en rencontre. Mercury, leader du domaine, propose l'outil Quality Center à cet effet. C'est là je pense que se situe le produit présenté dans la dépêche. Ce qui est intéressant c'est qu'on dispose enfin d'une solution de test complète et libre avec tous les produits que j'ai cité.
Le bémol qui a été soulevé plus haut est que lorsqu'on découvre un défaut il est renseigné dans l'outil de test alors que des outils de suivi de demande de changement existent déjà, sont plus complets et sont souvent utilisés en amont du projet en phase de développement pour suivre les nouvelles fonctionnalités et pas seulement les défauts. Par ailleurs les défauts peuvent aussi être découverts en prod et soumis dans ces mêmes outils. Ici on parle de JIRA mais c'est pareil pour n'importe quel bugtracker (je préfère le terme issue tracking qui est plus juste pour traiter toutes les demandes pas seulement les bugs). Pour un outil de suivi de test fonctionnel il est donc important de pouvoir s'interfacer avec un outil de suivi des demande de changement plutôt que de réinventer la roue. Autant ça ce comprend pour Mercury qui cherche à étendre son périmètre dans les outils de gestion du cycle de vie (ALM) face à ses concurrents comme IBM, autant pour un outil libre c'est un peu dommage.
(削除) Dsl pour le style télégraphique mais vraiment les tablettes android sont pas au point (troll inside) (削除ここまで)[NdM : mise en forme et qqs corrections apportées depuis]