Bonjour,
Quelqu'un pourrait il me fournir un exemple de plan test ?en Français...Merci à tous pour votre aide.....!!!!!!!
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Plan de test
Bonjour,
Quelqu'un pourrait il me fournir un exemple de plan test ?
Hello,
un plan de test peut être tout et n'importe quoi. Tout dépend de ce que tu as à tester !
Un plan de test pour une interface Web est complètement différent que pour le code d'une appli en Python (par exemple ^^). Le type de test est un facteur à prendre en compte (fonctionnel, unitaire, ...).
A toi de préciser ta demande !
Ne pas oubliermais aussi
"L'urgent est fait, l'impossible est en cours, pour les miracles prévoir un délai "
plan test
Bonjour,
Je te remercie pour ta réponse. Ma demande concerne un exemple de plan test lors de la mise en place d'un nouveau module sur une application, celà correspond plus à des tests fonctionnels.
plan test
Quelqu'un peut il me transmettre un exemple de plan test fonctionnel ?
ça dépend de ta fonctionalité, de tes données, et de ton environnement
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Il y a quand même des constantes. Par exemple, il faut toujours penser à l'exhaustivité des cas passants ET des cas non passants.
Par contre, après ça, il n'y a rien de commun; on peut parfaitement faire une moitié du plan avec les cas non-passants(mon style) ou les répartir par élément à tester(le style classique).
Si ton module est un module batch, je dirais que tu pourrais suivre la spec, bestialement, point de fonction par point de fonction, du plus simple au plus complexe. Faire attention, par contre, aux éventuelles mises à jour de bases qui pourraient empêcher un rejeu.
Et si c'est du transactionnel, penser aux possibles comportements vicieux de l'utilisateur(double-click sur un bouton à simple click, le coup classique pour avoir des doublons).
Il faudra aussi penser à séparer le test unitaire(i.e. le module seul, on force une entrée, et on regarde la sortie) du test bout en bout(on met le module dans son environnement complet, on envoie des choses à l'entrée de l'ensemble, et on regarde ce qui sort de l'ensemble).
En bref, si c'est un module de conversion franc-euro dans un batch, j'aurais :
(1)conversion simple(100000FF)
(2)conversion complexe(92728,63FF, 789,65DM.....)
(3)montant illicite(1,111FF, 789 yen, 55A FF.....)
Tout ça pour le module seul, puis ensuite le même genre de données, mais induite par les traitements précédents.
(oui, mon exemple est simplissime...)
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager