Système d'inscription aux cours
Récapitulatif de l'évaluation du test C2
Version 1.0
Historique des révisions
Date |
Version |
Description |
Auteur |
28/mars/1999 |
1.0 |
Evaluation du test de l'édition R1.0
(développée avec l'itération C2 - Edition initiale. |
C. Smith |
|
|
|
|
|
|
|
|
Sommaire
- Objectifs
- Portée
- Références
- Introduction
- Couverture de test
- Couverture de code
- Analyse des incidents
- 7.1 Densité des incidents
- 7.2 Tendance des incidents
- 7.3 Vieillissement des incidents
- Actions préconisées
- Diagrammes
Récapitulatif de l'évaluation du test C2
1. Objectifs
Ce rapport d'évaluation du test décrit les résultats des tests systèmes de l'édition 1.0 du système d'inscription aux cours
en termes de couverture de test (basée sur les exigences et basée sur le code) et d'analyse des incidents (c'est-à-dire, densité des incidents).Ces tests ont été effectués lors de l'itération C2.
2. Portée
Ce rapport d'évaluation de test s'applique à l'édition R1.0 du système d'inscription aux cours implémentée dans l'itération C2. Les tests réalisés sont décrits dans le Plan de test [5]. Ce rapport d'évaluation doit être utilisé pour :
- Evaluer si le système R1.0 offre des performances acceptables et appropriées
- Evaluer l'acceptabilité des tests
- Identifier les améliorations à apporter pour augmenter la couverture de test et/ou sa qualité
3. Références
Les références applicables sont les suivantes :
- Glossaire du système d'inscription aux cours,
WyIT406, V2.0, 1999, Wylie College IT.
- Plan de développement du logiciel du système d'inscription aux cours, WyIT418, V1.0, 1999, Wylie College IT.
- Plan d'itération C2 du système d'inscription aux cours, WyIT500, V1.0, 1999, Wylie College IT.
- Plan de construction et intégration C2 du système d'inscription aux cours, WyIT502, V1.0,
1999, Wylie College IT.
- Plan de test du système d'inscription aux cours, WyIT501, V1.0, 1999, Wylie
College IT.
4. Introduction
Les jeux d'essai définis dans la suite de tests ont été exécutés conformément à la stratégie de test définie dans le plan de test [5]. Les incidents internes ont été journalisés et tout incident de priorité moyenne, élevée ou critique est actuellement affecté au propriétaire concerné afin d'être corrigé.
La Couverture de test (voir la section 5.0 ci-dessous), qui porte sur la couverture des cas d'utilisation et des exigences de test et est définie dans le plan de test [5], a été réalisée à 95 %. Dix jeux d'essai portant sur le fonctionnement du système à pleine charge n'ont pas été réalisés du fait de bogues dans le logiciel de simulation de charge.
La Couverture de code, qui a été mesurée à l'aide de Rational Visual PureCoverage, est décrite dans la section 6.0.
L'Analyse des incidents (décrite dans la section 7.0 ci-dessous) indique que la majorité des incidents détectés a tendance à correspondre à des problèmes majeurs présentant une gravité élevée ou critique. L'autre résultat significatif a été que les composants logiciels constituant l'interface du système de catalogue des cours contenaient un nombre important d'incidents.
5. Couverture de test
Tous les jeux d'essai, tels que définis dans la suite de tests, ont été tentés. Dix tests n'ont pu se réaliser totalement du fait d'erreurs dans le logiciel de simulation de charge. Parmi les jeux d'essais exécutés, quinze ont échoué.
Les résultats de la couverture de test sont les suivants :
Rapport du nombre de jeux d'essais réalisés = 110/120 = 92 %
Rapport du nombre de jeux d'essais réussis = 95/110 = 87 %
La zone de tests comptant le taux d'incidents le plus élevé était :
- Tests des performances d'accès au système de catalogue des cours
- Tests de charge portant sur l'accès au système de catalogue des cours.
- Installation de logiciel(s) client(s).
Pour plus de détails sur la couverture de test, utiliser Rational RequisitePro
et la matrice de jeu d'essai.
6. Couverture de code
La couverture de code des tests a été mesurée à l'aide de Visual PureCoverage.
Rapport du nombre de lignes de code exécutées = 94 399/102 000 = 93 %
Environ 93 % du code a été exécuté au cours du test. Cette couverture dépassait la valeur cible, fixée à 90 %.
7. Analyse des incidents
Cette section récapitule les résultats de l'analyse des incidents générée à l'aide de Rational ClearQuest. La section 8 fournit des recommandations quant aux actions à effectuer pour traiter les résultats de l'analyse des incidents.
7.1 Densité des incidents
Les données relatives à la densité des incidents ont été générées à l'aide des données extraites des rapports ClearQuest. La section 9 de ce document contient des tableaux qui illustrent les éléments suivants :
- Incidents par niveau de gravité (critique, élevée, moyenne, faible)
- Source de l'incident (composant dans lequel réside le problème ou le défaut)
- Etat de l'incident (journalisé, affecté, corrigé, testé, fermé).
Le tableau Incidents par niveau de gravité montre que 26 des 36
incidents journalisés sont classés comme présentant une gravité élevée ou critique. Ce nombre est considéré comme très élevé et tous les incidents de gravité élevée ou critique doivent en outre être fermés pour que l'édition considérée puisse être commercialisée.
Le tableau Source de l'incident montre un nombre inhabituellement élevé d'incidents associés aux composants (c-abx, c-xxx) qui forment l'interface du Système de catalogue des cours. De plus, une grande partie des incidents réside dans les composants de logiciel qui contrôlent l'installation du logiciel client.
Le tableau Etat de l'incident montre que les incidents sont rapidement affectés et pris en charge. La majorité des incidents ont été vérifiés et fermés.
De plus, l'analyse des incidents de gravité élevée ou critique a montré que nombre de ces incidents ont pour origine la faiblesse des temps de réponse lors de l'accès au système de catalogue des cours dans des conditions de charge élevée. (50 % seulement des jeux d'essai vérifiant les exigences de performances ont réussi)
7.2 Tendance des incidents
La tendance des incidents (c'est-à-dire le décompte d'incidents dans le temps) est fournie dans le diagramme de la section 9. Cette tendance nous montre que le nombre d'occurrences d'incidents reste élevé.
Si cette tendance se confirme, il pourrait s'avérer nécessaire de recourir à des itérations supplémentaires pour rechercher les derniers incidents persistant dans le code.
7.3 Vieillissement des incidents
La tableau Vieillissement des incidents (voir la section 9) démontre que le délai de clôture de certains incidents est supérieur à 30 jours.
8. Actions préconisées
Les actions préconisées sont les suivantes :
- Continuez de consacrer des ressources d'ingénierie système au problème des temps de réponse du système de catalogue des cours. Il s'agit d'une question essentielle car l'édition R1.0 ne peut être commercialisée si elle ne répond pas aux exigences de performances.
- Révisez le planning principal pour voir si une quatrième itération peut être ajoutée à la phase de construction. La tendance des incidents dans le temps indique que de nombreux incidents persistent dans le code et qu'un cycle de test supplémentaire est recommandé.
- Les composants présentant un taux élevé d'incidents doivent être inspectés avant de soumettre à nouveau une construction. Ceci inclut c-abx et c-xxx.
- Le taux élevé d'incidents de gravité élevée ou critique indique peut-être que la conception était incomplète et n'avait pas été révisée correctement. Prévoyez des revues de conception supplémentaires pour l'édition R2.0.
- Corrigez les problèmes à l'aide du logiciel de simulation de charge et exécutez à nouveau les jeux d'essai associés.
- Etudiez le vieillissement des incidents. Pourquoi faut-il plus de 30 jours pour fermer un certain nombre d'incidents ?
9. Diagrammes
|