Tests de logiciel Considérations pratiques, Documentation et Activités de test 1
Documentation de tests, risques et niveaux d intégrité Environnement de développement et exécution des tests Évaluation des résultats et rapports de problèmes Defect Tracking et prise de décisions Critères d arrêt 2
Documentation de tests Rapport Sommaire de Tests Incidents de tests Journal de tests Procedures de tests Cas de Tests Conception de Tests Plan de tests IEEE 829, Standard for Software Test Documentation 3
IEEE Std 829-2008 Documents de Spécification 4
IEEE Std 829-2008 Spécification 5
Spécifications de conception de test Un ou plusieurs documents. Une spécification de conception de test décrit comment un groupe de fonctionnalités et/ou d items de test, est testé par un ensemble de cas de test et des procédures de test. Peut inclure une matrice de traçabilité de fonctionnalités/requis. Contient : identificateur ; fonctionnalités à tester : Les items de test et les fonctionnalités couvertes par ce document Raffinements de l approche : Les techniques de test. L identification des cas de test. Les critères de succès/échec de la fonctionnalité. 6
Spécifications du cas de test Contient : L identificateur de la spécification du cas de test. Les items de test : La liste des items et fonctionnalités devant être testés par ce cas de test. Les spécifications des entrées. Les spécifications de sorties. Les besoins environnementaux. Les requis procéduraux spéciaux. Les dépendances inter cas. 7
Spécifications de procédure de test Décrit les étapes requises pour exécuter un ensemble de cas de tests ou, plus généralement, les étapes utilisées pour analyser un item logiciel en vue d évaluer un ensemble de fonctionnalités. Contient : l identificateur de la spécification de procédure de test le but les requis spécifiques les étapes de la procédure Enregistrer un journal, configurer, procéder, mesurer, fermer, redémarrer, arrêter, envelopper, les contingences. 8
Note Les cas de test sont séparés des conceptions de test afin de permettre l utilisation dans plus d une conception et pour permettre de les réutiliser dans d autres situations. Les procédures de test sont séparées des spécifications de conception de test puisqu elles sont destinées à être suivies étape par étape et ne devraient pas avoir de détails supplémentaires. 9
IEEE Std 829-2008: Rapports 10
IEEE Std 829-2008: Rapports 11
Rapport de transmission d item de test Accompagne un ensemble d items de test qui sont livrés pour être testés. Contient : Identificateur du rapport de transmission ; Items transmis : le niveau de la version/révision ; les références de la documentation des items et du plan de test relié aux items transmis ; les personnes responsables pour les items. Location. Statut : les déviations de la documentation, des transmissions antérieures ou du plan de test ; les rapports d incidents qu on a prévu de résoudre ; synchroniser les modifications et la documentation. Approbations. 12
Journal de test Enregistre les détails des résultats de l exécution du test. Contient : L identificateur du journal de test ; La description : identifie les items ayant été testés,incluant leurs niveaux de version/révision ; identifie les attributs des environnements dans lesquels le test a été effectué. Les entrées de l activité et de l événement : la description de l exécution ; les résultats de la procédure ; l information environnementale ; les événements avec anomalies ; les identificateurs du rapport de l incident ;... 13
Rapport d incident de test Aussi appelé rapport de problème : Identificateur du rapport de test d incident. Sommaire : Résumé de l incident ; Identifie les items de test impliqués en indiquant leur niveau de version/révision ; Les références de la spécification de procédure du test approprié, la spécification du cas de test et le journal de test. Description de l incident : Les entrées, les résultats attendus, les résultats réels, les anomalies, la date et l heure, l étape de la procédure, l environnement, les tentatives de répétition, les testeurs, les observateurs ; Toutes informations utiles pour reproduire et réparer. Impact : Si connu, indique quel impact cet incident aura sur les plans de test, les spécifications de la conception du test, les spécifications de procédure du test ou les spécifications du cas de test ; Le ratio de sévérité (?) 14
Rapport sommaire du test Contient : L identificateur du rapport sommaire de test. Le sommaire : résumer l évaluation des items du test; identifier les items testés en indiquant l environnement dans lequel les activités du test ont eu lieu. Les variances : Des items du test par rapport des spécifications de conception originales. L évaluation de la généralité : évaluer la généralité du processus de test contre la généralité des critères spécifiés dans le plan de test si le plan de test existe ; identifier les fonctionnalités ou les combinaisons de fonctionnalités qui n étaient pas suffisamment testées et expliquer les raisons. 15
Rapport sommaire du test cont. Sommaire des résultats : Résumer les résultats de test. Identifier tous les incidents résolus et résumer leurs résolutions Identifier tous les incidents non résolus. Évaluation : Fournir une évaluation en général de chaque item de test ainsi que ses limitations ; Cette évaluation devra être basée sur les résultats du test et sur le niveau des critères passe/échec de l item ; Une estimation de risque d échec peut être inclus. Sommaire des activités : Résumer les activités du test majeur et des événements ; Résumer les données de consommation des ressources, e.g., niveau total du personnel, temps total machine et temps total écoulé pour les activités majeures de test. Approbations. 16
Standard IEEE 829 Rapport d incident de tests IEEE Std 829 SW Test Documentation Template for Test Incident Report 1. Incident Summary Report Identifier 2. Incident Summary 3. Incident description a. Inputs b. Expected Results c. Actual Results d. Anomalies e. Date and Time f. Procedure Step g. Environment h. Attempts to Repeat i. Testers j. Observers 4. Impact 5. Investigation 6. Metrics 7. Disposition 17
IEEE 829 Niveaux d intégrité "An integrity level is an indication of the relative importance of software (or of a software characteristic, component, or test level) to its stakeholders, as established by a set of selected attributes such as complexity, risk assessment, safety level, security level, data integrity, desired performance, reliability, quality, cost, size, and/or other unique characteristics of the software. La norme utilise les niveaux d'intégrité pour déterminer quelles tâches liées aux tests doivent être réalisées La norme définit quatre niveaux d'intégrité, dont les noms indiquent la gravité des conséquences d'une panne 18
IEEE 829 Niveaux d intégrité 19
Documents vs. niveau d'intégrité 20
Documentation de tests, risques et niveaux d intégrité Environnement de développement et exécution des tests Évaluation des résultats et rapports de problèmes Defect Tracking et prise de décisions Critères d arrêt 21
Environnement de développement Documentation Interfaces (internes, externs) Logiciel (OS, SUT, testware, etc.) Communication (passerelles, connections, protocoles) Fournitures (Badges, etc.) Matériel (processeurs, stockage, I/0) Parties prenantes Environment Facilities (Espace physique) [Craig]
Exécution des tests et cycle de vie des bugs 23
Documentation de tests, risques et niveaux d intégrité Environnement de développement et exécution des tests Évaluation des résultats et rapports de problèmes Defect Tracking et prise de décisions Critères d arrêt 24
Suivi des jeux de test Figure 17.4 Une feuille de travail peut être utilisée pour traquer et gérer efficacement les suites de tests et les cas de tests. (source: Ron Paton) LOG3430 12025
Rapport de tests simple Test Log Date: mmddyyyy Test cycle: ## Build ID: ### Test configuration: aaaa Tester: name Test # Test ID Pass/Fail Defect ID Comment 1 A5 P 2 A6 P 3 B1 F ab789 severe n Cn P cd456 minor 26
Évaluation de résultats: Présentation (1) Project xyz Date mm/dd/yyyy Feature tested Total Tests # Complete % Complete # Success A 46 46 100 41 89 B 36 25 69 25 100 C 19 17 89 12 71... Total 395 320 81 290 91 % Success to Date 27
Évaluation de résultats: Présentation (2) 28
Évaluation de résultats: Présentation (3) System Test Suite Summary Pass One Suite Total Planned Tests Fulfilled Cases Count Skip Pass Fail Weighted Failure Environmental test 8 8 0 5 3 2.20 Load, Capacity & Volume 8 1 0 0 1 1.33 Basic Functionality 12 2 0 2 0 1.00 Standards 3 1 1 0 0 1.00 Total 31 12 1 7 4 5.53 Percent 39% 3% 23% 13% 29
Defect Log: Contenu Defect ID number Descriptive defect name and type Source of defect-test case or other source Defect severity Defect priority Defect status (e.g. open, fixed, closed, user error, design, and so on) more robust tools provide a status history for the defect Date and time tracking for either the most recent status change, or for each change in the status history Detailed description, including the steps necessary to reproduce the defect Component or program where defect was found Screen prints, logs, etc. that will aid the developer in resolution process Stage of origination Person assigned to research and/or correct the defect 30
Defect Log: Sévérité et Statut Minor 18 16 Major 14 Critical 12 10 8 6 4 2 0 New Open Rejected Fixed Closed 31
Documentation de tests, risques et niveaux d intégrité Environnement de développement et exécution des tests Évaluation des résultats et rapports de problèmes Defect Tracking et prise de décisions Critères d arrêt 32
Le traçage des erreurs Le système de traçage d erreur (bug tracking system) est un programme que les testeurs utilisent pour enregistrer et détecter les erreurs. Il suit le chemin de chaque erreur entre les testeurs, les développeurs, le gestionnaire de projet et les autres, suivant diagramme de flux d information conçu pour s assurer que l erreur est vérifiée et réparée. Chaque erreur rencontrée dans l exécution du test est enregistrée et entrée dans le système pour détecter les erreurs afin qu elles puissent être classées par priorité. Le diagramme de flux d informations sur les défauts devrait montrer l interaction entre les testeurs qui ont trouvé l erreur et les programmeurs qui l ont fixée. Chaque erreur doit être proprement classée par priorité et révisée par tous les «stakeholders» pour déterminer si elle doit être corrigée ou non. Ce processus de révision et de classement par priorité est appelé triage. 33
Compte-rendu et détection de bogue automatisés Nouveau bogue d un usager avec «canconfirm» ou un produit sans état non confirmé NON CONFIRMÉ Le bogue confirmé ou avec assez de votes reçus Les développeurs en prennent possession Le bogue est réouvert, n avait jamais été confirmé Copie de la figure 6-1 - Cycle de vie de Bugzilla Bug Résolutions possibles : FIXER COPIER NE FIXERA PAS FORME DE TRAVAIL INVALIDE RAPPELER PLUS TARD La propriété est changée NOUVEAU ASSIGNÉ Les développeurs en prennent possession Le développement est fini avec bogue Les développeurs en prennent possession Le problème est résolu RÉSOLU Le bogue est fermé La QA pas satisfaisante avec solution La QA vérifie si la solution fonctionne (Bugzilla open source) RE-OUVERT Le bogue est réouvert Le bogue est réouvert VÉRIFIÉ Le bogue est fermé FERMÉ 34 (source: http://www.bugzilla.org/docs/*/pdf/bugzilla-guide.pdf )
Rapport écrit d un bug Nom de votre compagnie Confidentiel Rapport de problème # Programme Distribution Version Type de rapport (1-6) Sévérité (1-3) Pièce jointe (O/N) 1 erreur de codage 4 documentation 1 fatal Si oui, décrire : 2 problème de conception 5 matériel 2 sérieux 3 suggestion 6 - question 3 mineur Résumé du problème : Pouvez-vous reproduire le problème? (O/N) Problème et comment le reproduire Copie de la figure 1.3 formulaire du rapport d un problème Solution suggérée (optionnel) Rapporté par Date / / Les items suivants sont seulement pour l usage de l équipe de développement Zone fonctionnelle Assigné à (source: Cem Kaner, Testing Computer Software) Commentaires Statut (1-2) 1 ouvert 2 - fermé Priorité (1-5) Résolu par Solution testée par Traitement reporté (O/N) Date / / Date / / 35
Compte-rendu et détection de bogue automatisés Catalogues individuels de bogues (Mantis) (source: Ron Paton) cycle de vie information sommaire pour les bogues sélectionnés Information détaillée de bogues LOG3430 36
Defect Tracking: Types de risques 120 100 80 60 40 20 0 % Coverage % Total Defects [Black] 37
Defect Tracking: Cycle de vie de bugs 38
Defect Tracking: Croissance problèmes ouverts vs problèmes fermés 39
Defect Tracking: Age de bugs 40
Defect Tracking: Variance d effort de tests 41
Defect Tracking: Correction de défauts majeurs 42
Documentation de tests, risques et niveaux d intégrité Environnement de développement et exécution des tests Évaluation des résultats et rapports de problèmes Defect Tracking et prise de décisions Critères d arrêt 43
Critères d arrêt de test Le temps et les ressources du projet expirent La détection d un nombre spécifique d anomalies a été accomplie. Tous les tests planifiés qui ont été développés ont été exécutés avec succès Tous les buts de couverture spécifiés ont été atteints Les taux de détection d anomalies pour une certaine période de temps ont chuté sous un niveau spécifié. Les ratios d injection d anomalies sont favorables Un niveau de fiabilité spécifié a été atteint Utilisation d une combinaison de critères, dépendant d un projet à un autre! 44
Rapport d incidents et critères d arrêt Nombre de défauts par heure de tests Analyser la tendance Si assez bas et que les erreurs restantes sont de basse sévérité, Arrêt possible 45
Rapport d activités de test et critères d arrêt Ici plus de 95% des tests planifiés ont réussi Arrêt possible 46
Décision optimale d arrêt de test (1/ 2) Arrêter de tester trop tard : Un gaspillage des ressources Un temps de retard pour la mise en marché Une augmentation des coûts Les échéanciers retardés Arrêter de tester trop tôt : Les défauts restent et causent des pertes ou dommages à la vie ou à la propriété Les clients sont insatisfaits Les coûts élevés pour réparer Les coûts d appels d assistance téléphonique G. Antoniol 2011 LOG3430 47
Décision optimale d arrêt de test (2/ 2) Normalement, ce n est pas bénéfique (cost-effective) de réparer tous les bogues trouvés avant de distribuer le produit. Quelques bogues sont très difficiles à réparer : Difficile à trouver (exemple : bogues aléatoires) Difficile à corriger (exemple : composant tierce partie). Stratégie possible: Réparer tous les bogues de haute sévérité Réparer (les plus faciles) 95% de bogues de sévérité médium Réparer (les plus faciles) 70% de bogues de basse sévérité. 48