c3 Qualité

Télécharger au format pdf ou txt
Télécharger au format pdf ou txt
Vous êtes sur la page 1sur 13

14/04/2023

UNIVERSITÉ DE SFAX
Institut Supérieur d’Informatique et de Multimédia

Processus de test et qualité logicielle


D-IITWM

Cours 3: Techniques Statiques (K2)


par
Asma Sellami-Mnif, Ph.D.
[email protected]

3.1 Bases des tests statiques

Techniques
de test

Techniques Techniques
de test de test

Techniques Techniques
de test de test

2
14/04/2023

3.1 Bases des tests statiques (Suite…)


• Les techniques de tests statiques reposent sur l'examen manuel (revues) ou
l'analyse du code outillée (analyse statique) ou de la documentation du projet
sans exécution du code.
• Tout produit logiciel peut être revu, y compris les exigences, les spécifications,
les spécifications de conception, le code, les plans de test, les spécifications de
test, les cas de test, les scripts de test, les guides de l’utilisateur ou pages web
• Les revues permettent une détection et une correction anticipées des défauts
• Les revues, les analyses statiques et les tests dynamiques ont le même objectif
qui consiste à identifier les défauts
− Améliorer la cohérence et la qualité interne des produits d'activités, tandis que les tests dynamiques
se concentrent généralement sur les comportements visibles de l'extérieur
− Ils sont complémentaires : les techniques statiques trouvent les causes des défauts, les tests
dynamiques trouvent les défaillances elles mêmes

3.2 Processus de revue


• Les revues formelles sont caractérisées par la participation de l'équipe, la documentation des
résultats de la revue et la documentation des procédures pour la conduite de la revue Le
caractère formel d'un processus de revue est lié à des facteurs tels que le modèle de cycle de vie
de développement du logiciel, la maturité du processus de développement, la complexité du
produit d’activités à revoir, toute exigence légale ou réglementaire, et/ou la nécessité d'une
traçabilité d'audit.
• La focalisation d'une revue dépend des objectifs fixés pour la revue (par exemple, trouver des
défauts, gagner en compréhension, former les participants tels que des testeurs et de nouveaux
membres de l'équipe, ou discuter et décider par consensus).

4
14/04/2023

3.2.1 Processus de revue de produits d’activités

• Planification
• Définir le périmètre, qui comprend le but de la revue, les documents ou parties de documents à revoir et
les caractéristiques de qualité à évaluer
• Estimer l'effort et le temps requis
• Identifier les caractéristiques de la revue telles que le type de revue avec les rôles, les activités et les
checklists
• Sélectionner les personnes qui participeront à la revue et attribuer des rôles
• Définir des critères d'entrée et de sortie pour les types de revue plus formels (p. ex. inspections)
• Vérifier que les critères d'entrée soient satisfaits (pour les types de revue plus formels)
• Lancement de la revue
• Distribuer le produit d'activités (physiquement ou par voie électronique) et d'autres documents, comme
des formulaires de saisie des défauts, des checklists et des produits d'activités connexes
• Expliquer le périmètre, les objectifs, le processus, les rôles et les produits d'activités aux Participants
• Répondre à toutes les questions que les participants peuvent avoir au sujet de la revue
• Préparation individuelle (ou Revue individuelle)
• Revoir tout ou partie du produit d'activités
• Noter les défauts potentiels, les recommandations et les questions
5

3.2.1 Processus de revue de produits d’activités (Suite…)

• Communication et analyse des problèmes


• Communiquer les défauts potentiels identifiés (p. ex. lors d'une réunion de revue)
• Analyser les défauts potentiels, leur affecter un responsable et un statut
• Évaluer et documenter les caractéristiques de qualité
• Évaluer les résultats de la revue en fonction des critères de sortie pour prendre une décision de revue
(rejet ; changements majeurs nécessaires ; acceptation, éventuellement avec des changements mineurs)
• Correction et production de rapports (Re travail)
• Produire des rapports de défauts pour les constatations qui nécessitent des changements
• Corriger les défauts trouvés (correction généralement réalisée par l'auteur) dans le produit d'activités
revu
• Communiquer les défauts à la personne ou à l'équipe concernée (lorsqu'ils se trouvent dans un produit
d'activités lié au produit d'activités revu)
• Enregistrer l'état actualisé des défauts (dans les revues formelles), y compris éventuellement l'accord de
l'auteur du commentaire concerné
• Recueillir des métriques (pour les types de revue plus formels)
• Vérifier que les critères de sortie sont satisfaits (pour les types de revue plus formels)
• Accepter le produit d'activités lorsque les critères de sortie sont satisfaits
6
14/04/2023

3.2.2 Rôles et responsabilités dans une revue formelle

• Auteur
• Crée le produit d'activités revu
• Corrige les défauts du produit d’activités revu (si nécessaire)
• Manager
• Est responsable de la planification de la revue
• Décide de la mise en œuvre des revues
• Affecte le personnel, le budget et le temps
• Vérifie le rapport coût-efficacité en continu
• Met en œuvre les mesures appropriées en cas de résultats inadéquats
• Facilitateur (modérateur)
• Assure le bon déroulement des réunions de revue (quand elles ont lieu)
• Fait la médiation, si nécessaire, entre les différents points de vue
• Est souvent la personne dont dépend le succès de la revue

3.2.2 Rôles et responsabilités dans une revue formelle (Suite…)

• Responsable de la revue
• Prend la responsabilité générale de la revue
• Décide qui sera impliqué et organise quand et où elle aura lieu)
• Réviseurs
• Il peut s'agir d'experts du domaine, de personnes travaillant sur le projet, d'intervenants ayant un intérêt
pour le produit d’activités et/ou de personnes ayant des compétences techniques ou métier spécifiques
• Ils identifient les défauts potentiels du produit d’activités à revoir
• Ils peuvent représenter différentes perspectives (p. ex. testeur, programmeur, utilisateur, opérateur,
analyste métier, expert en utilisabilité, etc.)
• Scribe (Rapporteur)
• Recueille les défauts potentiels découverts au cours de l'activité de revue individuelle
• Enregistre les nouveaux défauts potentiels, les points en suspens et les décisions prises lors de la réunion
de revue (durant son déroulement)

8
14/04/2023

3.2.3 Types de revue

• Revue informelle (p. ex., par un collègue, en binôme, revue de pair)


• Objectifs :
− détecter d’éventuels défauts
− générer de nouvelles idées ou solutions, résoudre rapidement des problèmes mineurs

• Ne repose pas sur un processus formel (documenté)


• Peut ne pas comporter de réunion de revue
• Peut être effectué par un collègue de l'auteur ou par d'autres personnes
• Les résultats peuvent être documentés
• L'utilité varie selon les réviseurs
• L'utilisation de checklists est facultative
• Très couramment utilisé dans le développement Agile

3.2.3 Types de revue (Suite…)

• Relecture technique (Walkthrough)


• Objectifs :
− trouver des défauts, améliorer le produit logiciel, envisager des implémentations alternatives,
évaluer la conformité aux normes et aux spécifications,
− échange d'idées sur des techniques ou des variations de style, formation des participants,
obtention d'un consensus
• La préparation individuelle avant la réunion de revue est facultative
• La réunion de revue est généralement dirigée par l'auteur du produit d’activités
• Le rôle de scribe est obligatoire
• L'utilisation de checklists est facultative
• Peut prendre la forme de scénarios, d’essais à blanc ou de simulations
• Des rapports de défauts et des rapports de revue peuvent être produits
• Peut varier dans la pratique de plutôt informel à très formel)

10
14/04/2023

3.2.3 Types de revue (Suite…)

• Revue technique
• Objectifs :
− obtention d'un consensus, détection de défauts potentiels
− évaluer la qualité et renforcer la confiance dans le produit d’activités revu, générer de nouvelles
idées, motiver et permettre aux auteurs d'améliorer les produits d’activités futurs, envisager des
implémentations alternatives
• Les réviseurs doivent être des pairs techniques de l'auteur et des experts techniques dans la
même discipline ou dans d'autres disciplines
• Une préparation individuelle avant la réunion de revue est requise
• La réunion de revue est facultative, et de préférence dirigée par un facilitateur formé
(généralement pas l'auteur)
• Le rôle de scribe est obligatoire, de préférence pas l'auteur
• L'utilisation de checklists est facultative
• Des rapports de défauts et des rapports de revue sont généralement produits

11

3.2.3 Types de revue (Suite…)


• Inspection
• Objectifs :
− détecter les défauts potentiels, évaluer la qualité et renforcer la confiance dans le produit d’activités, prévenir de
futurs défauts similaires par l'apprentissage de l'auteur et l'analyse des causes racines
− motiver et permettre aux auteurs d'améliorer les futurs produits d’activités et le processus de développement de
logiciels, parvenir à un consensus
• Suit un processus défini avec des résultats formels documentés, basé sur des règles et des checklists
• Utilise des rôles clairement définis, comme ceux spécifiés à la section 3.2.2 qui sont obligatoires, et peut inclure un
lecteur spécialisé (qui lit le produit d’activités à haute voix pendant la réunion de revue)
• Une préparation individuelle avant la réunion de revue est requise
• Les réviseurs sont soit des pairs de l'auteur, soit des experts dans d'autres disciplines pertinentes pour le produit
d’activités concerné
• Des critères d'entrée et de sortie spécifiés sont utilisés
• Le rôle de scribe est obligatoire
• La réunion de revue est dirigée par un facilitateur formé (pas l'auteur)
• L'auteur ne peut pas agir à titre de responsable de la revue, de lecteur ou de scribe
• Des rapports de défauts et des rapports de revue sont produits
• Des métriques sont collectées et utilisées pour améliorer l'ensemble du processus de développement logiciel, y compris
le processus d'inspection
12
14/04/2023

3.2.4 Application des techniques de revue (préparation individuelle)


• Ad hoc
• Les réviseurs reçoivent peu ou pas de directives sur la façon dont cette tâche devrait être accomplie.
• Les réviseurs examinent généralement le produit d’activités de façon séquentielle, en identifiant et en
documentant les problèmes au fur et à mesure qu'ils les rencontrent.
• La révision ad hoc est une technique couramment utilisée qui nécessite peu de préparation. Cette
technique dépend fortement des compétences des réviseurs et peut donner lieu à des constats qui font
double emploi car signalés par différents réviseurs.
• Basée sur les checklists
• Une revue basée sur une checklist est une technique systématique, pour laquelle les réviseurs détectent
les problèmes sur la base de checklist qui sont distribuées au début de la revue (par exemple, par le
facilitateur)
• Une checklist consiste en une série de questions basées sur des défauts potentiels, qui peuvent être issus
de l'expérience. Les checklists devraient être spécifiques au type de produit d’activités examiné et
devraient être mises à jour régulièrement pour couvrir les types de problèmes qui ont été omis lors de
revues précédentes.
• Le principal avantage de la technique basée sur les checklists est la couverture systématique des types de
défauts courants. Il faut prendre soin de ne pas simplement suivre la checklist lors de la revue individuelle,
mais aussi de rechercher des défauts en dehors de la checklist.
13

3.2.4 Application des techniques de revue (préparation individuelle)


• Scénarios et essais à blanc
• Dans le cadre d'une revue fondée sur des scénarios, les réviseurs reçoivent un guide structuré sur la façon
de lire le produit d’activités.
• Une approche fondée sur des scénarios aide les réviseurs à effectuer des "essais à blanc" sur le produit
d’activités en fonction de l'utilisation prévue du produit d’activités (si le produit d’activités est documenté
dans un format approprié, comme les cas d'utilisation par exemple).
• Ces scénarios permettent aux réviseurs d’être mieux guidés sur la façon d'identifier des types de défauts
spécifiques qu’avec uniquement les éléments d’une checklist.
• Comme pour les revues basées sur des checklists, afin de ne pas manquer certains types de défauts (p. ex.,
des caractéristiques manquantes), les réviseurs ne devraient pas être limités aux scénarios documentés..
• Basée sur les rôles
• Une revue basée sur les rôles est une technique par laquelle les réviseurs évaluent le produit d’activités du
point de vue de rôles individuels des parties prenantes.
• Les rôles typiques comprennent des types d'utilisateurs finaux spécifiques (expérimentés, inexpérimentés,
seniors, enfants, etc.) et des rôles spécifiques dans l'organisation (administrateur utilisateur, administrateur
système, testeur de performance, etc.).

14
14/04/2023

3.2.4 Application des techniques de revue (préparation individuelle)


• Basée sur la perspective
• Dans une lecture basée sur la perspective, de façon semblable à une revue basée sur les rôles, les réviseurs
adoptent différents points de vue des parties prenantes dans le cadre d'une revue individuelle.
• Les points de vue habituels des parties prenantes comprennent l'utilisateur final, le marketing, le
concepteur, le testeur ou les opérations.
• L'utilisation de différents points de vue des parties prenantes permet d'approfondir la revue individuelle
avec moins de doublons de défauts entre les réviseurs.
• De plus, la lecture basée sur la perspective exige également que les réviseurs essaient d'utiliser le produit
d’activités revu pour produire le produit qu'ils en tireraient. Par exemple, un testeur pourrait essayer de
générer des brouillons de tests d'acceptation en réalisant une lecture basée sur la perspective d'une
spécification des exigences pour voir si toute l'information nécessaire est bien incluse.
• De plus, dans le cadre de la lecture basée sur la perspective, on s'attend à ce que des checklists soient
utilisées.

15

3.2.5 Facteurs de réussite des revues

Facteurs de réussite organisationnels pour les revues


• Chaque revue a des objectifs clairs, définis lors de la planification de la revue et utilisés comme
critères de sortie mesurables
• Le type de revue est choisi en fonction des objectifs, du type et du niveau des produits d’activités
logiciels, mais aussi en tenant compte des participants
• Toutes les techniques de revue utilisées, telles que la revue basée sur les checklists ou sur les rôles,
sont appropriées pour l'identification efficace des défauts dans le produit d’activités à revoir
• Toutes les checklists utilisées couvrent les principaux risques et sont actualisées
• Les documents volumineux sont rédigés et révisés en petits morceaux, de sorte que le contrôle de la
qualité est réalisé en fournissant aux auteurs un feed-back précoce et fréquent sur les défauts
• Les participants ont suffisamment de temps pour préparer
• Les revues sont planifiées avec un délai de notification suffisant
• Le management appuie le processus de revue (p. ex. en intégrant suffisamment de temps pour les
activités de revue dans les échéanciers des projets)
16
14/04/2023

3.2.5 Facteurs de réussite des revues (Suite…)


 Facteurs de réussite liés aux participants aux revues
• Le choix des bonnes personnes contribue à l'atteinte des objectifs de la revue, par exemple, des personnes ayant des
compétences ou des perspectives différentes, qui peuvent utiliser le document comme intrant de leurs activités
• Les testeurs sont considérés comme des réviseurs appréciés qui contribuent à la revue et aussi apprennent à propos
du produit d’activités revu, ce qui leur permet de produire des tests plus efficaces et de préparer ces tests plus tôt
• Les participants consacrent suffisamment de temps et d'attention aux détails
• Les revues sont effectuées sur de petits morceaux, de sorte que les réviseurs ne perdent pas leur concentration
pendant la revue individuelle et/ou la réunion de revue (quand elle a lieu)
• Les défauts trouvés sont identifiés, compris et traités avec objectivité
• La réunion est bien gérée, de sorte que les participants considèrent qu'il s'agit d'une utilisation efficace de leur
temps
• La revue est menée dans un climat de confiance ; le résultat ne sera pas utilisé pour l'évaluation des participants
• Les participants évitent le langage corporel et les comportements qui pourraient indiquer l'ennui, l'exaspération ou
l'hostilité envers les autres participants
• Une formation adéquate est fournie, en particulier pour les types de revue plus formels tels que les inspections
• Une culture de l'apprentissage et de l'amélioration des processus est encouragée) 17

3.3 Analyse statique outillée

• L’accent est mis sur l’apprentissage et l’amélioration du processus.


• L'objectif de l'analyse statique est de trouver des défauts dans le code source et les modèles logiciels.
• Les outils d'analyse statique analysent le code du programme et sont typiquement utilisés par des
développeurs avant et pendant les tests de composants et les tests d'intégration.
• Les outils d'analyse statique peuvent produire un nombre important de messages d'avertissement qui
doivent être gérés convenablement afin de permettre une utilisation optimale de l'outil.

18
14/04/2023

3.3 Analyse statique outillée

• La valeur des tests statiques est :


• La détection très tôt de défauts avant l’exécution des tests.
• Une information très tôt sur certains aspects suspects du code ou de la conception, par le calcul de métriques, par
exemple une mesure de complexité élevée.
• L’identification de défauts difficilement détectables par des tests dynamiques.
• La détection de dépendances et d’inconsistances dans les modèles logiciels tels que des liens dans les modèles
logiciels.
• L’amélioration de la maintenabilité du code et de la conception.
• La prévention des défauts, si les leçons sont prises en compte lors du développement.

19

3.3 Analyse statique outillée

• Les défauts typiques découverts par des outils d’analyse statique incluent :
• Référencement d’une variable avec une valeur indéfinie.
• Interface inconsistante entre modules et composants.
• Variables qui ne sont jamais utilisées ou déclarées de façon incorrecte.
• Code non accessible (code mort).
• Logique absente et erronée (potentiellement des boucles infinies).
• Constructions trop compliquées.
• Violation des standards de programmation.
• Vulnérabilités de sécurité.
• Violation de syntaxe dans le code et les modèles logiciels.

20
14/04/2023

Quizz

21
14/04/2023
14/04/2023

Vous aimerez peut-être aussi