Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente | ||
testcases [14/09/2008 12:00] – xavierqet | testcases [20/11/2014 14:01] (Version actuelle) – modification externe 127.0.0.1 | ||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
+ | ====== Procédures de test ====== | ||
+ | Lorsque l'on fait un programme, il est pratique d' | ||
+ | c' | ||
+ | fait bien son boulot. Cela permet de repérer facilement des régressions. La | ||
+ | limite de ces tests, c'est qu'il faut les programmer ; pour une application | ||
+ | comme `grep', | ||
+ | graphique comme QET, c'est plus difficile. Quelqu' | ||
+ | temps à maintenir un programme de vérification du rendu graphique de QET ? Je | ||
+ | ne pense pas. Évidemment, | ||
+ | ne feraient quand même pas de mal mais bon. | ||
+ | |||
+ | En fait, ce qui nous manque avant de faire une release de QET, c'est une liste | ||
+ | des choses à vérifier humainement, | ||
+ | donc créer, poser par écrit et maintenir des scénarios de test de QET. Des | ||
+ | choses du genre : | ||
+ | « Démarrer QET, s' | ||
+ | que ..., poser un autre élément et un conducteur, s' | ||
+ | |||
+ | Cela rejoint un peu les « Use scenarios » et « Use cases » qu'on peut trouver | ||
+ | dans le « User Profiles » : | ||
+ | [[http:// | ||
+ | |||
+ | Cela nous permettrait de tester QET autrement que par l' | ||
+ | nous en faisons en poussant chaque testeur à faire un tour complet de | ||
+ | l' | ||
+ | (segfaults, dysfonctionnements, | ||
+ | ergonomie, ...). Cela pourrait également impliquer de maintenir des fichiers | ||
+ | schémas/ | ||
+ | rétro-compatibilité). | ||
+ | |||
+ | Liste des procédures de test : | ||
+ | FIXME |