Discussion :

[olrt]

Bonjour à tous,

Comment définiriez-vous la meilleure stratégie de tests
d'un développement ?

Les tests sont nécessaires mais souvent coûteux en temps.

Il y a les tests "unitaires", les scénarios de tests, etc.

Il faut mettre en place des scénarios de tests qui couvrent
la plus grande portion du code.

Existe-t-il des moyens "scientifiques" pour y parvenir ?

Avec quelle fréquence doit-on effectuer des tests ?

Je pose les questions en vrac car je n'ai pas reçu de formation
spécifique dans ce domaine.

Merci à vous tous.

[la drogue c'est mal]

hello Oliv 8)

Bonjour à tous,
Comment définiriez-vous la meilleure stratégie de tests
d'un développement ?

théoriquement celle qui traite toutes les possibilités de parasitage de l'utilisateur

Les tests sont nécessaires mais souvent coûteux en temps.

moi je dirais indispensable

Il y a les tests "unitaires", les scénarios de tests, etc.
Il faut mettre en place des scénarios de tests qui couvrent
la plus grande portion du code.
Existe-t-il des moyens "scientifiques" pour y parvenir ?

il y a des logiciels qui réalisent des tests automatiques a l'aide de hook ce qui permet de simuler un scénario utilisateur

Avec quelle fréquence doit-on effectuer des tests ?

je dirais ca dépend du type de test.

Le test unitaire : tout le temps
...
...
Test de validation de la Release : a chaque Release

Je pose les questions en vrac car je n'ai pas reçu de formation
spécifique dans ce domaine.
Merci à vous tous.

sur google en tapant "software test process" t'en as quelques kilo tonnes. Apres il faut faire le trie ....

[sequentaire]

Travaillant en milieu Java, j'utilise JUnit. Et j'essaie de développer la meilleure visibilité possible de ce que fait mon logiciel.

Au départ je debug, puis je regarde si ça marche. Si ça marche pas, j'essaie de reproduire le cas d'erreur avec JUnit, et je classe les cas de test par classe java. Avec ce système, la fréquence de test (au moins unitaire) n'a pas d'importance, puisque tu peux la faire tout le temps. Et c'est très fort pour vérifier les non-régréssivités.

Néanmoins, on ne peut pas qualifier ce système de méthode. C'est juste un ensemble de combines. Je dis que c'est bon dès l'instant que j'ai l'impression que c'est bon. J'ai néanmoins l'impression que cela m'aide énormement à fournir de bons logiciels.

[qi130]

Il faut mettre en place des scénarios de tests qui couvrent
la plus grande portion du code.

Existe-t-il des moyens "scientifiques" pour y parvenir ?

Oui !
Ces moyens scientifiques sont des outils (softs) qui permettent de calculer la couverture de test.

[mat.M]

Comment définiriez-vous la meilleure stratégie de tests
d'un développement ?
Les tests sont nécessaires mais souvent coûteux en temps.

On peut faire tous les tests que l'on veut , avec une stratégie ( simulations , jeux de test ).
Mais tout le monde le sait bien ici :
* un logiciel n'est jamais terminé
*il faut quelques temps et versions avant qu'il soit complétement rodé.
Moralité toujours quelques bugs... et évolutions à apporter

[adel_dz]

Salut
voila comme je fais moi. Pour simplifier les choses disons que je veux tester une class de pile (TyPile)
J'ai integer dans mes class 1 system d'assertion utilse sous eiffel qui est compose de 3 types d'assertions:
- Les preconditions
- Les postconditions
- et invariant de class

*Les precondition definissent les conditions a remplir avant d'appller une methode de ma class
* Les postconditions definissent les "choses " qui doivent etre realise a la sortie de ma methode.
*l'invarint defini les condition de stabilite de ma class.

Voyons l'ex de ma class TyPile (pile d'entiers)

class TyPile: public ...
{
public :
TyPile(unsigned maxElt);
...
void Push(int Elt);
void Pop();

int Top() const;
....
bool IsFull() const;
bool IsEmpty() const;
unsigned GetItemCount() const;
.....

protected:
unsigned max_elt;

....

};

il est claire que la methode Pop ne peut etre appliquee a une pile vide alors je doit defint une precondition du genre:

void
TyPile:op()
{
PRECONDITION(IsEmpty() == false)
...// et la le traitement normal en supposant que la precond. est virifie
}

apres 1 pop la pile ne peut etre pleine (c ma post condition)
donc:

void
TyPile:oop()
{
PRECONDITION(IsEmpty() == false)
......//le traitement normal

POSTCONDITION(IsFull() == false)
}

qd a l'invariant de class qui est applle a la sortie de chaque fonction non const doit verifie par ex que GetItemCount() < max_elt.

ouuf.

durant le projet je defint 3 mode (3 configurations)

1-la premiere ou toute les assertion sont activée (le mode debug)
2-la 2emme ou uniquement les precondition sont activée (la vesion beta)
3-Aucune assertion n'est active (version finale)

et je m'arrange pour que mes assertion affiche lors d'une erreur:
le nom de la fonction, celui de la class et ne numero de l'assertion.

c simple rapide et tes efficaces.
a+




[/code]

[Elrond]

théoriquement celle qui traite toutes les possibilités de parasitage de l'utilisateur

Et les defaillances materielles (coupure reseau, ...).
Et les conditions exceptionnelles (memoire saturee, disques durs pleins, plantage d'un programme client/serveur...)
...

[rm66]

Vous ne parlez que des classes "internes" (les Piles...), qui peuvent encore être à peu près testées et sécurisées avec les préconditions/invariants/postconditions et les tests automatiques, mais que dire des interfaces graphiques (même en utilisant MVC), qui dépendent fortement des messages de Windows ?

A ce propos, est-ce que quelqu'un a une bonne stratégie de test des interfaces graphiques (autre qu'enregistrer des séries de cas d'utilisations au pixel près) ?

a+

[GuillaumeCorbineau]

De toutes façon les tests c'est du temps mais c'est je pense que c'est une des phases les plus importantes du developpement d'un logiciel, Car des Bugs il y en a toujours se qu'il faut c'est que les bugs ne soit pas bloquant ou trop penalisant pour l'utilisateur. Car un utilisateur mecontant d'un logiciel c'est une personne qui n'utilisera plus le soft. Donc même si cette etape est couteuse elle indispensable.

[gc243]

Bonjour,
La démarche de recette d'un projet est fortement liée à son importance et au nombre d'utilisateurs concernés.

Pour les gros projets on peut découper les tests ainsi :

- les tests unitaires : effectués par le développeur dans son environnement de travail. Il s'appui sur un dossier de spécifications générales.

- la recette interne : le développeur ne participe pas (important) cette recette est faite par des personnes connaissant l'ensemble du projet une bonne connaissance du fonctionnel. A cela il faut ajouter éventuellement des tests d'intégration sur plate forme, performances, tests aux limites, robustesse.

- la recette fonctionnelle qui elle s'attache à la finalité de l'application : est-ce que l'on m'a livré correspond à ce que j'ai demandé et aux besoins des utilisateurs ?


A chaque étape, des corrections peuvent être demandées par le développeur. Ce qui oblige nécessairement à refaire le cycle complet des tests puisqu'une correction doit être testée et chose importante elle peut induire des effets de bord.

Voici le cycle en U très connu des informaticiens. Ce sont en fait les étapes préconisées pour le développement d'une application.

Etude de faisabilité <--> Généralisation ou diff.
Définition fonctionnelle du besoin <---> Recette fonctionnelle
Dossier de conception générale <---> Recette interne
Dossier de conception détaillée <---> Tests unitaires
Développement


Pourquoi en U ? au regard de chaque étape (sauf pour l'étape de développement) correspond une étape de recette ou de test. Si un problème est détecté pour l'une de ces étapes, il faudra revoir le cycle à partir de l'étape en regard.
Par exemple si un problème est détecté en recette fonctionnelle ; c'est la définition fonctionnelle du besoin qu'il faudra revoir et reprendre les dossiers DCG, DCD, Dev, TU, RI,RF.

D'où l'importance d'une bonne DFB et de bonnes spécifications, l'écriture du code proprement dit n'est pas le centre du problème.

GC243

[cedricgirard]

Personnelement praticien XP junior, les tests unitaires me semblent garantir un "moteur" solide (à condition de bien tout tester). Si on rajoute des pre/post conditions et invariant en plus, c'est parfait (ils permettent à mon sens de valider le logiciel en utilisation courante, et de pallier aux oublis dans les tests unitaires)
Pour l'interface je suis encore un peu dans le vague, manque un framework complet pour faciliter ça. Enfin il doit exister mais je ne l'ai pas encore découvert.

[sequentaire]

Pour l'interface je suis encore un peu dans le vague, manque un framework complet pour faciliter ça. Enfin il doit exister mais je ne l'ai pas encore découvert.

Pour les programmeurs Java, en tout cas, il y a la solution : Unit Testing In Java Excerpt on GUI development, Download Chapter 13: "Graphical User Interface" (pdf), trouvé là.

[borgfabr]

Toutes ces méthodes sont bien mais rien ne vaut un test en pseudo production !

C'est là qu'on voit ce que vaut notre projet !

[ludovic.fernandez]

En Protocole Engineering, de multiples outlils de spécifications formelles existent. Généralement, basés sur des automates à états finis, ils permettent la vérification, validation et de réaliser une aprtie des tests en simulation. Ainsi peuvent être cités, LOTOS, SDL, Estelle, UPAAL, les réseaux de Perti, Promela (SPIN) et bien d'autres.

Dans le cas de SDL, il est à la fois possible de définir un environnement déterministe, qu'un environnement indéterministe, il s'appllique essentiellement au domaine des Télécoms mais peut satisfaire d'autres domaines. L'outil commercial le plus connu est ObjetcGeode. SDL peut être défini selon deux types grammaires, SDL Textual Representation (ressemble à ASN.1) et SDL Graphic Representation.

L'avantage de SPIN est d'être gratuit et disponiblie en ligne, il interprète de l'OTCL en C++.

Enfin, plus spécifiquement aux tests, je citerai TTCL que je n'ai malheureusement pas essayé au contraire des autres méthodes.

[cedricgirard]

Toutes ces méthodes sont bien mais rien ne vaut un test en pseudo production !

C'est là qu'on voit ce que vaut notre projet !

Sauf qu'en prod on ne voit pas tout, j'en veux pour preuve les bugs qui apparaissent des mois apres. Exemple vécu : pendant des années, une fonction comptable a donné des résultats faux en prod dans une banque, et personne ne l'a vu avant qu'un ami à moi n'ai pour charge de reprendre le programme.
Donc la prod n'est pas une solution à 100%. Ce qui est par contre vrai est que donner le produit le plus tot possible au client lui permet de vérifier que le produit est fonctionnelement correct. C'est complémentaire et c'es préconisé dans XP

[borgfabr]

Alors là tout à fait d'accord avec toi !

[unicyclon]

J'ai jamais trouvé plus rapide que de trouver des beta testeurs qui seront toujours fiers d'avoir un logiciels en avant première. Faut le soumettre aux tests de charge, etc... Faut se mettre à la place du néophyte comme du pro ET surtout savoir qu'aucun OS n'est pareil. Tester avec différents antivirus, etc... ET passer la certification Microsoft pour un logiciel sous Windows, pour ceux qui en ont les moyens tout du moins. "Designed for Microsoft Windows ça fait toujours du bien

[tipiak]

voila donc en gros je doit spécialisé le framework JUnit pour faire un nouveau framework dédié à une application de l'entreprise ou je fais mon stage

donc ca reviendrai a faire des testscases spécialisés pour pouvoir avoir des tests déja prédfinis pour des composants


mais je ne sais pas jusq'ou il faudrai que je descende dans la granularité de mes tests
en effet j'effectue pour l'instant mes tests sur des Components
eux meme composés d'une view (pouvant etre en 1 ou plusieurs classe)
une appLogique (les regles de gestion)
une data logiic (regles et acces à la base de donnée)
et un model (donnée du composant)

ces morceaux sont aussi en 1 ou plusieurs classes chacun

je sais que les tests unitaires conseillent de faire une classse de test par test
mais avec toutes les dépendances entre ces classes d'un meme composant, je me demande si ca ne serai pas plus simple d'avoir qu'un seul testcase pour le composant
et donc avec cette méthode je ne chercherai pas a tester indépendament les classes de ce composant...

est ce envisageable de ne pas decendre plus bas ds la granularité ???

(aussi je n'ai pas contribué au développement de l'application son fonctionnement m'echape parfois c'est pour cela que descendre trop bas ds la granularité peux me poser des PBs)



En fait je cherche surtt à savoir si il faut que dans mes tests je cherche aussi à tester des fonctions du framework de l'application
ou alors je considère que toute fonction du framework utilisé est sans failles et donc retourne un résultat tjr exacte....

ou si je dois juste tester les composants spécialisés de ce framework et dédié a l'application ....

merci

[cedricgirard]

Salut

Pour ma part je met plusieurs tests par classe de test (ou j'ai mal compris ton truc). En général une classe de test pour moi blinde un aspect d'une classe métier ou un comportement mettant en jeu plusieurs classes. Mais cet aspect et ce comportement peuvent avoir besoin de 5, 10 ou 20 tests pour être vérrouillés.

Ensuite pour le framework, tu vois. Si tu n'est pas sur d'un truc, tu te fais une classe où tu mettras des tests sur le framework. Par exemple, tu veux étudier comme se manipule tel objet/fonction? hop un test, qui te sert à comprendre et qui documente la fonction pour plus tard. Suffira de le relire pour avoir un exemple d'utilisation.
D'une maniere générale on doit pouvoir avoir confiance dans un framework, maintenant au moindre doute teste le. Surtout s'il a été fait dans ton entreprise, teste ce qui te semble risqué. Si un test plus haut ne passe pas pour des raisons bizarres, teste les aspects utilisés des classes qui utilisées.

Cédric

[tipiak]

ouai en fait pour le coups des classes de tests ce que je voullai dire c'est que normalement c'est une classe de l'appli correspond a une classe de test (selon la théorie de l'XP)
mais moi je voullai savoir si c'était envisageable (enfin oui ca l'est mais est ce judicieux ) de mettre une classe de test pour en ensemble de classes de l'appli (il semble que tu pense que cette pratique est envisageable (cf une classe pour en comportement métier avec plusieurs classes en jeux))

sinon pour le test du framework tu rejoins ce que je pensais faire à savoir tester les classes de l'appli en faisant confiance au framework
mais avec un certain recul à savoir savoir qu'au moindre doute sur le fonctionnement du framework je le test

il faut savoir aussi que pour ce projet, je fonctionne que avec des classes déja éprouvée par des tests (cependant elles furent testée par les développeurs proprement mais sans une réel stratégie collective de test)
et c'est la que j'interviens pour justement capitaliser ces tests via un framework de test (étendu de JUnit) et spécialisé pour tester l'appli découlant du framework de l'entreprise (car concernant cette appli la boite ne s'occupe que de la maitrise d'ouvrage (sur de longues périodes)) et donc captaliser les tests unitaires via un framework permetrai de gagner pas mal en productivité et en qualité ...