Tests de logiciel. Considérations pratiques, Documentation et Activités de test

Transcription

1 Tests de logiciel Considérations pratiques, Documentation et Activités de test 1

2 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

3 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

4 IEEE Std Documents de Spécification 4

5 IEEE Std Spécification 5

6 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

7 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

8 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

9 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

10 IEEE Std : Rapports 10

11 IEEE Std : Rapports 11

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 IEEE 829 Niveaux d intégrité 19

20 Documents vs. niveau d'intégrité 20

21 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

22 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]

23 Exécution des tests et cycle de vie des bugs 23

24 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

25 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) LOG

26 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

27 Évaluation de résultats: Présentation (1) Project xyz Date mm/dd/yyyy Feature tested Total Tests # Complete % Complete # Success A B C Total % Success to Date 27

28 Évaluation de résultats: Présentation (2) 28

29 É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 Load, Capacity & Volume Basic Functionality Standards Total Percent 39% 3% 23% 13% 29

30 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

31 Defect Log: Sévérité et Statut Minor Major 14 Critical New Open Rejected Fixed Closed 31

32 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

33 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

34 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 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: )

35 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

36 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 LOG

37 Defect Tracking: Types de risques % Coverage % Total Defects [Black] 37

38 Defect Tracking: Cycle de vie de bugs 38

39 Defect Tracking: Croissance problèmes ouverts vs problèmes fermés 39

40 Defect Tracking: Age de bugs 40

41 Defect Tracking: Variance d effort de tests 41

42 Defect Tracking: Correction de défauts majeurs 42

43 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

44 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

45 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

46 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

47 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 LOG

48 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