Discussion :

[kisitomomotene]

Salut à tous

Si je prend un formulaire qui a 10 champs, il faudrait un minimum 2^10 valeurs à rentrer pour tester toute les combinaisons possibles de champs à remplir ce qui est presque impossible manuellement, certainement il doit exister des exemples de code pour resoudre ce type de test ( je crois que je ne suis pas la première personne à vouloir tester un formulaire qui a 10 champs).
Quelqu'un a une idée?

[tipiak]

Salut à tous

Si je prend un formulaire qui a 10 champs, il faudrait un minimum 2^10 valeurs à rentrer pour tester toute les combinaisons possibles de champs à remplir ce qui est presque impossible manuellement, certainement il doit exister des exemples de code pour resoudre ce type de test ( je crois que je ne suis pas la première personne à vouloir tester un formulaire qui a 10 champs).
Quelqu'un a une idée?

Salut,
pour les 2^10 je ne suis pas d'accord en partant de ton principe si chaque champs est par exemple un string de 10 char(a à z) cela te fait déja 26^10 rien que pour ce champ.

bref ce qu'il faut définir en fonction: de ta stratégie de test, c'est des classes d'équivalences:
ie:
>>>tests unitaire / intégration => valider le bon fonctionnement unitaire de chaque champ
(par exemple sur le type qu'il contient:
numérique, string, champs à partir d'une regex, liste de data (vérifier leur contenu) avec une combo....)

(ce qui est rapide à faire manuellement, d'autant plus que pour cette étape tu ne joue pas sur la Combinatoire entre les 10 champs de ton formulaire

>>> Tests fonctionnels: la tu va faire intervenir la combinatoire entre tes champs
à partir de tes uses cases et de ta spec fonctionnel, tu découvriras qu'il n'y a pas autant de cas fonctionnels que ce que le formulaire te laisse croire

Par exemple un champs "commentaire" qui n'intervient pas dans la fonctionnel, cela ne fait qu'un seul jeu de donnée sur ce champ (un commentaire bidon) (il faut juste vérifier qu'il est bien propagé dans la suite de l'appli) et qu'il marche unitairement...

à contratio, un champ "type de contrat" qui peut prendre 3 valeurs possible, et qui implique une variante fonctionnelle à chaque fois, c'est 3 Cas de test pour ce champ
(certes type contrat c'est facile c'est par exemple un choix dans une combo box, mais même avec un nombre tu peux avoir des classes d'équivalences définies par la spec de ton appli: si le montant positif et inférieur à 1000, si entre 1000 et 3000)
(les tests aux limites c'est du Unit/intégration: par exemple débiter une somme négative)

Avec ces cas fonctionnels, tu peux donc faire une feuille excel pour croiser tout tes jeux de donnés et faire le croisement entre tous les champs de ton formulaire (on est loin des 2^10 cas) (avec des macro tu dois même pouvoir faire générer tout seul la combinatoire dans excel)

tu obtiens donc pour chaque ligne un Jeu d'essai (un set de 10 valeurs à passer au formulaire) (il faut aussi penser à rajouter les résultats attendu correspondant à l'envoi du formulaire avec chaque jeu de donnée)

et à partir de la tu as deux options:
- test à la main chaque cas (bon courage)
- automatiser (car c'est clairement un cas éligible à l'automatisation en data driven tests) puisque les actions sont les même pour chaque jeu de donnée (seul le data à passer change)
pour le scripting de l'action, je ne peux t'aider plus, cela dépend de l'outil que tu choisis, de la techno du dit formulaire ...
mais l'approche restera la même quelque soit l'outil, l'outil suivra les steps:
- pour chaque ligne dans le fichier excel
-Ajouter valeur champ1
- ...
-Ajouter valeur champ10
- Envoyer le formulaire
- pour chaque résultat attendu, vérifier le contenu retourner par l'envoi du formulaire


voila, bon courage,

NOTE: en plus des classes d'équivalences, tu peux aussi faire intervenir des critaire de priorité ou de criticité sur certaines variantes fonctionnelles (par exemple les plus utilisées), pour orienter ton effort de testing
(les fameux 80-20)

[ypicot]

Bonjour,

Une petite précision sur les classes d'équivalence, que Tipiak a commencé à développer mais qui (à mon avis) demande approfondissement.

En fait, tu ne traites que rarement _toutes_ les valeurs.
Tu prends :
- quelques valeurs "médianes" suivant l'ampleur de l'intervale (typiquement entre une et trois)
- les valeurs limites (juste à la limite ou juste dépassée. par exemple, si la saisie doit être comprise entre 0 et 100, tu testes, 0, -1, 100, 101)

YVan