Vous parcourez actuellement les archives du blog Blog du testeur de mai 2008.
- automatisation (4)
- Généralités (21)
- humour (5)
- livres (1)
- Outil de Test (13)
- Sécurité (4)
- Uncategorized (2)
- 30.8.2010: Pourquoi investir dans les tests unitaires ... s'il y a des tests systèmes?
- 25.6.2010: Environnements de test
- 20.5.2010: la sécurité applicative
- 19.5.2010: publication d'un article sur la testabilité
- 7.4.2010: Un forum dédié test
- 2.4.2010: Article sur Model Based Testing paru dans methods and tools
- 31.3.2010: Speccy: configuration
- 31.3.2010: Software Testing Europe
- 27.3.2010: Consigner vos résultat de tests automatiques avec TestLink
- 28.1.2010: Démo en ligne d'un outil de gestion de test: TestLink
Autres
formation test
infos test
sites autres
- août : 2010
- juin : 2010
- mai : 2010
- avril : 2010
- mars : 2010
- janvier : 2010
- décembre : 2009
- novembre : 2009
- octobre : 2009
- septembre : 2009
- août : 2009
- juillet : 2009
- juin : 2009
- mai : 2009
- avril : 2009
- mars : 2009
- janvier : 2009
- octobre : 2008
- septembre : 2008
- août : 2008
- juin : 2008
- mai : 2008
- avril : 2008
- mars : 2008
- février : 2008
Archive pour mai 2008
Automatiser oui mais …
19.5.2008 par Dominique Mereaux.
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.
Posté dans automatisation | Aucun commentaire »
Utilisation des langages scriptés pour le test.
7.5.2008 par Dominique Mereaux.
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.
Posté dans Outil de Test | 1 commentaire »