Blog du testeur

Pairwise Testing: PICT est un outil qui permet de réduire la combinatoire des tests. Intéressant à appliquer dans le cas de test sur différentes configurations matérielles et logicielles, par exemple:

PLATFORM: x86, ia64, amd64

CPUS: Single, Dual, Quad

RAM: 128MB, 1GB, 4GB, 64GB

HDD: SCSI, IDE

OS: NT4, Win2K, WinXP, Win2K3

IE: 4.0, 5.0, 5.5, 6.0

APP: SQLServer, Exchange, Office

Tester toutes les combinaisons est impossible. Cet outil vous permet de construire des combinaisons en couvrant toutes les paires possibles ou tous les triplets (au choix).

Vous pouvez également définir des contraintes, telle que si un paramètre prend telle valeur alors un paramètre prendra une valeur bien définie, bref contrôler la génération des combinaisons. pict

Il existe des outils open source qui permettent d'améliorer les pratiques, que ce soit pour la gestion, l'automatisation ou également les tests de performances. Voici un site qui offre un récapitulatif: opensourcetesting

J'ai trouvé cette citation d'un responsable de test qui résume bien la situation:

"Automated test are by nature scripted, not exploratory. Even with an automation stack which injects all sort of variability, the tests wear grooves in those areas of the product they cover and they ignore everything else. "

Finalement faire uniquement confiance à des tests automatisés peut conduire à ne pas voir des problèmes liés à des effets de bord: en effet dans un test automatique on ne vérifie que des points particuliers et parfois une action peut affecter de façon non attendu l'application testée. Également il arrive que l'on réinitialise plus fréquemment l'environnement de test ce qui ne nous met pas dans toujours dans des conditions réalistes d'utilisation.

De la même façon lorsque l'on réalise des tests de façon manuelle on le réalise souvent avec des variantes, voir on image de nouveaux tests qui améliore la couverture des tests.

Voilà pourquoi à mon sens et de part quelques expériences récentes je préconiserais de toujours garder une part de test manuel.

Si vous avez une API (Application Program Interface) à tester pourquoi ne pas utiliser un langage scripté tel que jython pour une API Java ou python pour une API C ou C++.

Grâce à leur simplicité vous pourrez obtenir rapidement une implémentation de cette API et vous pourrez également la tester en ligne de commande.

Un petit exemple: une classe java permettant de gérer des complexes:

Jython 2.1 on java1.6.0_03 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> import complexe


>>> dir(complexe)
['__init__', 'add', 'imaginaire', 'reel']
>>> x = complexe(1,3)
>>> print x
complexe@142022d
>>> print x.reel()
1
>>> print x.imaginaire()
3
La commande import permet d'importer la classe. La commande dir permet de connaître les méthodes de la classe. Puis sans vraiment coder un seul programme on peut tester rapidement. Sans remplacer une vrai série de tests on peut de cette façon faire un apprentissage de cette API et de l'évaluer facilement.

Quand j'ai démarré une activité de validation j'ai été amené à repenser les outils de test. Cet outil devait permettre de recevoir et émettre des requêtes. Nos exigences pour avoir un outil performant pour les tests étaient:

• Pouvoir tester des cas nominaux.
• Pouvoir tester des cas d'erreur.
• Etre pilotable en mode commande en vue de l'automatisation future des tests.
• Vérifier les requêtes et donner un compte rendu de résultat.

J'optais pour simuler le comportement du monde extérieur par script. Le principe est simple: l'outil reçoit des requêtes et les compare à celles du script et renvoit des requêtes ou réponses qu'il trouve dans le même script. On objecta que les scripts étaient trop complexes à écrire car il demandait des compétences en terme de protocole et qu'il serait plus simple de développer un simulateur qui interprétait les requêtes et calculait les requêtes à la volée. Le simulateur logiciel est souvent une idée qui s'impose naturellement mais l'on oublie que:

• le simulateur est plus complexe à développer et donc lui-même source de bug.
• a chaque nouvelle fonctionnalité, on peut être amener à faire évoluer le simulateur, dans le cas d'un outil scripté il s'agira de concevoir de nouveaux scripts.
• il ne sera pas adapté aux cas d'erreurs.

Finalement après utilisation chacun s'y habitua et pour finir l'outil fut enrichi pour enregistrer des scripts lors de l'utilisation en condition réelle du serveur et que l'on réutilisait après quelques ajustements pour nos tests.