Analyse des résultas
Cycle de test
Le
cycle de test correspond à la période durant laquelle un ensemble de tests est
exécuté. Ainsi à la fin de chaque cycle, un examen des résultas obtenus
permettra de définir si l’on peut passer ou non au cycle suivant.
Organiser ces cycles dans un
tableau permettra de simplifier l’analyse des résultats.
Si l’application développée
est une version n+1 d’une application existante, on sera amener à en
vérifier la non-régression. Pour cela, on pourra définir un cycle de
non-régression qui consistera à rejouer des scénarios de test de la version
précédante.
Rapport
de test
On trouve en général cinq
familles de rapport dans ce domaine :
les
rapports de synthèses,
les
rapports de couverture de test,
les
rapports d’avancement,
les
rapports de performance,
les
rapports d’anomalies.
Rapports
de couverture des tests
Ils mettent en relation les
scénarios de test avec les objectifs et les règles de gestion. Toutefois, même avec l'aide de ce rapport il reste en
général difficile d'affirmer que toute l'application a été testée.
Rapports
d'avancement
Afin de pouvoir évaluer
l’avancement des tests, on générera des rapports visualisant les scénarios
enregistrés, ceux qui contiennent des bogues, par rapport à l’ensemble des
procédures.
On pourra également lister les scénarios qui auront été exécutés
sans problème.
Comme les rapports de
couverture de test, les rapports d’avancement doivent faire référence aux
objectifs de tests.
Rapports
de performance
Les performances sont liées
aux temps de réponse observés lors des tests de montée en charge ou des tests en
mode dégradé.
Afin de simplifier la
lecture de ces rapports, les résultats obtenus
pourront être présentés sous la forme de graphiques appropriés.
Rapports
d’anomalies
Ces rapports doivent faciliter le
suivit d’une anomalie.
De plus, ils permettrons
de déterminer quels sont les modules les plus fiables de l’application.
Interprétation
des résultats
Une fois les rapports de
tests écrits, il faut se prononcer sur leur signification.
Le premier critère à prendre
en compte est lié à la phase de test que l’on vient d’exécuter.
Si on se trouve dans des phases préliminaires, on aura la possibilité de corriger les anomalies
détectées sans trop perturber la suite des tests et le développement ultérieur
de l'application.
Si au contraire on se trouve
dans une phase de test avancée, il est important de prendre en compte l'impact
de la correction des anomalies sur les tests ultérieurs.
Dans tous les cas, on veillera
spécialement à qualifier correctement les anomalies, surtout celles qui ont été
définies comme bloquantes et on recherchera les modules provoquant le plus
grand nombre d'anomalies.
Enfin, avant de définir les
conditions de test du cycle suivant, il faudra préciser quelles sont les
anomalies que l'on voudra suivre tout particulièrement pour vérifier si elles ont bien été corrigées.