Vous parcourez actuellement les archives du blog Blog du testeur de avril 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 avril 2008
simulateur ou outil de test scripté?
1.4.2008 par Dominique Mereaux.
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.
Posté dans Outil de Test | Aucun commentaire »