Système d'inscription aux cours
Récapitulatif de l'évaluation du test
pour le
Prototype d'architecture
Version 1.0
Historique des révisions
Date |
Version |
Description |
Auteur |
21/mars/1999 |
1.0 |
Evaluation du test de prototype d'architecture |
C. Smith |
|
|
|
|
|
|
|
|
Sommaire
- Introduction
- Récapitulatif des résultats du test
- Couverture de test
- Couverture de code
- Analyse des incidents
- Actions préconisées
- Diagrammes
Récapitulatif de l'évaluation du test
pour le
Prototype d'architecture
- Introduction
- Objet
Ce rapport d'évaluation du test décrit les résultats des tests de prototype d'architecture 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).
- Portée
Ce rapport d'évaluation du test s'applique au prototype d'architecture du système d'inscription au cours. Les tests réalisés sont décrits dans le Plan de test du prototype [5]. Ce rapport d'évaluation doit être utilisé pour :
- évaluer si le(s) comportement(s) du prototype offre(nt) des performances acceptables et appropriées
- évaluer l'acceptabilité des tests
- identifier les améliorations à apporter pour augmenter la couverture du test et/ou sa qualité
- 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 du système d'inscription aux cours, Itération d'élaboration #E1, WyIT420, V1.0, 1999,
Wylie College IT.
- Plan de construction et intégration du système d'inscription aux cours pour le prototype d'architecture,
WyIT430, V1.0, 1999, Wylie College IT.
- Plan de test du système d'inscription aux cours pour le prototype d'architecture, WyIT432,
V1.0, 1999, Wylie College IT.
-
Récapitulatif des résultats du test
Les jeux d'essai définis dans la suite de tests pour le prototype ont été exécutés conformément à la stratégie de test définie dans le plan de test [5].
La couverture de test (voir la section 5.0 ci-dessous), en termes de couverture des cas d'utilisation et des exigences de test
définie dans le plan de test [5], était totale.
La couverture de code est décrite dans la section 6.0 et n'était pas considérée comme une mesure significative de la réussite pour le prototype.
L'analyse des incidents (décrite dans la section 7.0 ci-dessous) indique qu'il existe des
problèmes de performances significatifs lors de l'accès au système de catalogue des cours existant. Les tests de performances et de chargement qui portaient sur l'accès en écriture ou en lecture au système de catalogue des cours donnent des résultats bien en deçà des valeurs cibles établies. L'équipe de gestion affectera des ressources d'ingénierie système afin d'évaluer plus en profondeur ces résultats de test et de définir d'autres approches en matière de conception.
- Couverture de test
Les tests à réaliser sur le prototype sont définis dans la section 5.1 du plan de test [5], de même que leurs critères d'exécution. Les résultats de la couverture de test sont les suivants :
Rapport du nombre de jeux d'essais réalisés = 40/40 = 100 %
Rapport du nombre de jeux d'essais réussis = 30/40 = 80 %
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.
Pour plus de détails sur la couverture de test, utiliser Rational RequisitePro et la matrice de jeu d'essai du prototype.
- Couverture de code
La couverture de code des tests du prototype a été réalisée à l'aide de Rational Visual PureCoverage.
Rapport du nombre de lignes de code exécutées = 12 874/48 916 (environ 25 %)
Environ 25 % du code a été exécuté au cours du test. Il a été établi que cette couverture convenait pour les tests du prototype car toutes les interfaces sont exécutées en profondeur. Les itérations ultérieures nécessiteront un taux beaucoup plus élevé pour la couverture de code.
- 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.
- 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 4 incidents de priorité critique et 4 incidents de priorité élevée ont été journalisés. L'analyse détaillée des journaux des incidents a révélé que les incidents de priorité élevée et critique sont tous associés aux problèmes de performances et de chargement lors de l'accès au système de catalogue des cours. (remarque : tableau non inclus)
Le tableau Source de l'incident montre un pourcentage anormalement élevé d'incidents au niveau des composants de l'interface du système.
Le tableau Etat de l'incident montre que de nombreux incidents sont dans l'état journalisé et n'ont pas encore été affectés en vue d'une analyse.
- Tendance des incidents
La tendance des incidents (c'est-à-dire le nombre d'incidents dans le temps) n'a pas été mesurée pour les tests de prototype d'architecture.
- Vieillissement des incidents
Le suivi de l'âge des incidents n'est pas nécessaire pour le prototype. Le plan actuel prévoit que l'âge des incidents ouverts commencera à être suivi au début de la phase de construction. ClearQuest sera utilisé pour générer les tableaux de vieillissement des incidents.
- Actions préconisées
Les actions préconisées sont les suivantes :
- Affecter des ressources d'ingénierie système supplémentaires afin d'évaluer plus en profondeur les problèmes de performances et de chargement liés à l'accès au système de catalogue des cours existant. Les autres conceptions seront révisées par l'équipe projet avant l'implémentation de toute solution de conception.
- Affecter des ressources d'ingénierie afin de résoudre des incidents ouverts majeurs sur le prototype.
- Retarder le début de l'itération suivante jusqu'à ce que les incidents de gravité critique et élevée soient résolus.
- Concevoir des systèmes supplémentaires afin de tester davantage les charges et les temps d'accès pour le système de catalogue des cours. Recourir si possible à Rational Visual Quantify pour identifier et analyser les goulots d'étranglement des performances.
- Il est recommandé que les prochaines itérations comprennent une inspection de toute conception ou tout code impliquant des interfaces externes. Ces inspections visent à réduire le nombre de problèmes identifiés au cours du test.
7. Diagrammes
-
|