Chap3 Techniques Statiques 11

Tests logiciels
25913 IFM
3
Chapitre 3
Techniques statiques
Techniques statiques 25913 IFM – Tests logiciels 3.1

Contenu du chapitre
3
• 3.1 - Revues et processus de test

• 3.2 - Processus de revue
• 3.3 - Analyse statique outillée

Avant-propos
3
• Objectif fondamental des tests statiques

– Améliorer la qualité du logiciel en aidant les
concepteurs à identifier et corriger les défauts tôt
dans le cycle de développement
• Très efficace (principe #3 - tester tôt)
– Toujours incorporer les revues dans
• Les exigences • L'implantation
• Les spécifications • Les tests
• La conception • La maintenance
• Ne remplace pas les tests dynamiques

3.1 - Revues et processus de test
3.1
• Objectifs
– Reconnaître les livrables qui peuvent être
examinés par les différentes techniques
statiques
– Décrire l’importance et la valeur de
l’utilisation de techniques statiques dans
l’évaluation de livrables logiciels
– Expliquer les différences entre les
techniques statiques et dynamiques
Tests statiques vs dynamiques
3.1
• Complémentaires Test dynamique : test

qui nécessite l’exécution
– Tests dynamiques : exécution du logiciel du logiciel d’un
composant ou système.
• Les valeurs d'entrées sont fournies
• Les résultats obtenus sont comparés aux résultats attendus
• Visent à identifier les défaillances
– Tests statiques : examen des produits Tests statique : test d’un
du logiciel composant ou système
au niveau spécification
• Documents, code source, plans de tests, ... ou implémentation sans
• Manuels ou automatisés exécution de ce logiciel
(p.ex. : revues ou analyse
• Visent à identifier les défauts (i.e. bogues) statique du code).
• Les tests dynamiques sont applicables uniquement

au code source, alors que les tests statiques
s'appliquent à tous les produits du logiciel
Produits de logiciel
3.1
• Artefacts produits pendant le cycle de vie d'un

logiciel Produits de logiciel : ensembles
des artefacts produits pendant le
– Documents de conception cycle de vie d'un logiciel (p.ex. :
documents, code source,
• Exigences testware).
• Spécifications Testware : artefact produit

pendant le processus de test afin
• Design de planifier, concevoir et exécuter
les tests, tel que la documentation,
– Code source les scripts, les entrées, les
résultats attendus, les procédures
– Testware de mise en place et de nettoyage,

les fichiers, bases de données,
environnements et tout logiciel ou
– Documents d'utilisation utilitaires supplémentaire utilisé
dans les tests.

Revues
3.1
• Principale stratégie d'analyse statique

• Objectif primaire Revue : une évaluation d’un état
d’un produit ou projet pour
– Identifier les défauts s’assurer des déviations par
rapport aux résultats planifiés et
• Objectifs secondaires recommander des améliorations.
Exemples : revue de gestion,
– Visées informatives, revue informelle, revue technique,
inspection et relecture technique.
communicatives et
éducatives
– Amènent les intervenants à connaître les
particularités du projet
– Les clients peuvent aussi contribuer en participant
Bénéfices des revues
3.1
• Bénéfices directs
– Détection anticipée des défauts et leur correction
– Améliorations de productivité dans le développement
– Durées de développement réduites
– Durées et des coûts de tests réduits
– Réduction de coûts tout au long de l’existence du logiciel
– Moins de défauts et une meilleure communication
• Peuvent détecter des omissions, par exemple, dans
des exigences
– Dont la détection pendant les tests dynamique est peu
probable

Bénéfices des revues (suite)
3.1
• Puisque les revues débutent aux exigences, celles-ci
sont validées dès le début plutôt qu'à la fin (lors des
tests d'acceptation)
• Permettent de trouver les défauts tôt, réduisant les
coûts de réalisation et résultant en un logiciel de
qualité accrue
• Des exigences validés résultent en moins de
modifications majeurs ultérieures
– Donc une meilleure productivité
• Permettent l'échange d'information entre
participants
• Permettent d'identifier les composants à
risques, donc mieux planifier les tests EF 3.1

Types de défauts
3.1
• Les tests statiques facilitent l'identification des

défauts suivants
– Déviations des standards
– Défauts d'exigences
– Défauts de conception
– Maintenabilité insuffisante
– Spécifications incorrectes d’interfaces

Cibles de revue
3.1
• Les revues s'appliquent autant aux documents

qu'au code source et aux tests
– Les revues d'exigences et de spécifications
permettent d'identifier les défauts dans celles-ci
avant qu'une première ligne de code soit écrite
– Les revues de code source permettent d'identifier
les défauts dans celui-ci avant son exécution
• Certains défauts dans le code peuvent ne pas causer de
défaillance lors des tests, donc seule la revue permettra
de les identifier

Cibles de revue (suite)
3.1
– Les revues de plans et/ou cas de test permettent

d'identifier les défauts et omissions avant que les
tests soient effectués
• Assurent une meilleure couverture des tests
La revue Document Numérique int fonction_somme(int entier1,int login [as ROLE-OR-USER] :

publie des articles qui concernent entier2) Log into the system with a
la gestion des documents. Dans { given user or a user of
ce cadre, il s'agit des documents int somme; //résultat de la somme the given type. Usually
vus comme supports ou comme only stated explicitly
finalité d'un processus. Cet somme=entier1+entier2; when the test case
aspect concerne les étapes du return somme; // permet de depends on the
processus éditorial technique de retourner le résultat à la fonction permissions of a
workflow et de groupware et de //d'appel particular role or involves
reengineering des processus... } a workflow between
Les documents sont considérés different users.
sous leurs représentations les void main(void) visit LOCATION :
plus diverses : document image, { Visit a page or screen.
document révisable, document int resultat; For web applications,
ucturé, document composé resultat LOCATION may be a
onction_somme(35,42); hyperlink. The location
rintf("La somme des should be a well-known
starting point (e.g., the
Spécifications Design Code source Cas de test

3.2 - Processus de revue
3.2
• Objectifs
– Rappeler les phases, rôles et responsabilités d’une
revue formelle typique
– Expliquer les différences entre les différents types
de revues: revue informelle, revue technique,
relecture technique et inspection
– Expliquer les facteurs liés à une exécution de
revues couronnées de succès

Revues informelles et formelles
3.2
• Les revues varient de très informelles à très formelles
– Informelles : non documentées,
non structurées Revue informelle : une revue qui
n’est pas basée sur une procédure
– Formelles : documentées, formelle (documentée).
procédures et/ou réglementation Revue formelle : une revue
établies caractérisée par des
• Les revus en début de cycle de procédures et exigences
documentées (p.ex.
vie sont généralement informelles inspection).
– Deux intervenants, un révisant le travail de l'autre

• Au fil de la progression du projet, les revues
deviennent formelles
– Plus de participants, meetings, documents, ...
EF 3.2

Phases d’une revue formelle
3.2.1
• Une revue formelle typique comprend les phases

principales suivantes
– Planification : planifier la revue
– Lancement : préparer les participants à la revue
– Préparation individuelle : chaque participant fait une
revue et se prépare pour la réunion
– Réunion de revue : discussion et consignation des revues
individuelles
– Correction : réparer les défauts identifiés
– Suivi : vérifier que les défauts sont corrigés

Planification
3.2.1
• Tâches
– Choisir le personnel
– Affecter les rôles
– Définir les critères d’entrée et de sortie pour des
types de revues plus formelles (p.ex. inspection)
– Sélectionner les parties du document à regarder
• La planification est effectuée Modérateur : le leader et
par le modérateur principale personne
responsable d’une inspection
ou autre processus de revue.
– Responsable de l'échéancier
de la revue (dates, heures, locaux et invitations)
Planification (suite)
3.2.1
• Pour les revues formelles (p. ex. une

inspection), le modérateur Critère d’entrée : l’ensemble
des conditions spécifiques et
– Effectue un vérification d'entrée génériques pour permettre à
un processus de continuer à
• S'assure que les documents sont exécuter une tâche définie
(p.ex. une phase de tests). Le
prêts à être revus (p.ex. pas de but d’un critère d’entrée est
défauts évidents, concis, syntaxe d’empêcher le début d’une
tâche qui générerait une
correct, ...) pour ne pas démotiver charge de travail plus
importante (inutile et
les réviseurs gaspillée) que celle
• Défini les critères d'entrée nécessaire pour supprimer le
critère d’entrée défaillant.
– Défini les critères de sortie formels
• Définir les critères permettant de déterminer quand la
revue est terminée
Planification : critères d'entrée
3.2.1
• Exemples de critères d'entrée

– Un expert (le modérateur?) a trouvé au minimum
3 défauts majeurs en une même page
– Le document à réviser comprend des numéros de
ligne
– Les correcteurs automatisés ont été appliqués au
document
– Les références requises pour l'inspection sont
fournies et accessibles
– L'auteur du document est prêt pour la revue
Planification : cibles de la revue
3.2.1
• Parties du document ciblées

– Identifiées par le modérateur et l'auteur
– Limitées car l'humain peut difficilement assimiler
plus que quelques pages à la fois
– Exemple : limiter le nombre de pages ciblées selon
le type de revue
• Revue informelle : 10 à 20 pages à la fois (ou 100 à 200
lignes de code source)
• Revue formelle (inspection) : une page ou deux (ou
moins de 100 lignes de code source)

Planification : l'équipe
3.2.1
• Membres sélectionnés par le modérateur et l'auteur

– Quatre à six membres (incluant le modérateur et l'auteur)
– Rôles distincts attribués à chacun
• Efficacité (on évite que plusieurs
trouvent le même défaut) Documents Ex: exigences,
de niveaux spécifications
supérieurs
Conformité Document Documents Ex: interfaces

aux standards en revue connexes entre modules
Ex: format,
conventions,
clarté, etc. Utilisateurs Ex: testabilité,
du document maintenabilité

Lancement
3.2.1
• Première rencontre des membres

– Le modérateur informe les Réviseur : la personne
impliquée dans une revue qui
réviseurs identifiera et décrira les
anomalies dans le produit ou
• Critères d'entrée de de sortie projet en revue. Les réviseurs
peuvent être choisis pour
• Rôles de chacun représenter divers points de
vue ou rôles dans le
– Permet aux membres de processus de revue.
s'entendre sur l'échéancier et les rôles

• Se sentir impliqués dans l'organisation de la révision
afin d'assurer une efficacité accrue
– Tous les détails de la revue sont établis lors de ce
meeting
Préparation individuelle
3.2.1
• Les membres révisent leur partie du document selon

leur rôle
• Ils identifient
– Défauts
– Questions et/ou commentaires
• Tout est consigné (ex: annotations au document)
– Un check-list est souvent utilisé pour éviter les oublis
• Taux de révision : nombre de pages/lignes de code
révisées par heure
– Ne devrait pas dépasser 5 à 10 pages/50 à 100 lignes de code
– Utilisé par le modérateur pour évaluer l'efficacité

Réunion de revue
3.2.1
• Dirigée par le modérateur Scribe : la personne qui doit

• En trois phases enregistrer chaque anomalie
mentionnée et chaque
1. Journalisation suggestion d’amélioration
pendant une revue, sur un
• Les défauts / commentaires de chaque formulaire de prise de note.
réviseur sont consignés par le Le scribe doit s’assurer que
le formulaire de prise de
modérateur ou le scribe (lors de notes est lisible et
revues formelles) compréhensible.
2. Discussions
• Chaque élément consigné aux journal est présenté et discuté
• Chaque défaut est évalué (critique / majeur / mineur)
3. Décisions
• En fonction des critères de sortie, le plus important étant le
nombre moyen de défauts critiques et majeurs par page

Réunion de revue (suite)
3.2.1
• Les critères de sortie peuvent être modifiés

selon l'urgence de la situation
– Le modérateur en prend la responsabilité
• Si le document n'est pas approuvé par le
comité de révision Critère de sortie : l’ensemble des
conditions génériques et spécifiques,
– L'auteur doit faire les convenues avec les responsables, pour

permettre de terminer officiellement un
corrections demandées processus. L’objectif d’un critère de sortie

est d’éviter qu’une tâche ne soit considérée
et resoumettre le comme achevée alors qu’il y a encore des

parties de cette tâche qui n’ont pas été
document par la suite terminées. Les critères de sortie sont utilisés

dans le test pour faire des comptes rendus
et pour planifier l’arrêt du test.

Correction
3.2.1
• L'auteur doit corriger les défauts identifiés

– Il n'a pas à les corriger tous; c'est à lui de décider
– Il doit consigner les actions prises pour chaque
défaut afin d'en faire rapport au modérateur
• Les modifications doivent être traçables
– Exemple : utiliser les fonctionnalités de révision du
logiciel de traitement de texte pour un document
– Exploiter une convention de numéros de version

Suivi
3.2.1
• Le modérateur est responsable du suivi des

corrections de l'auteur
– Via les consignations de corrections
– Il s'assure que l'auteur a pris en considération les
défauts et commentaires des réviseurs
• Le modérateur peut faire le suivi lui-même ou
distribué la tâche aux réviseurs concernés
– Il est cependant responsable de consigner les
résultats pour suivis et/ou analyses futurs

Rôles et responsabilités
3.2.2
• Une revue formelle typique inclue les rôles suivants

– Le gestionnaire
• Décide l’exécution des revues
• Alloue le temps dans la planification du projet
• Détermine si les objectifs de revue ont été atteints
– Le modérateur
• Dirige la revue du document ou de l’ensemble des documents,
incluant la planification de la revue, l’exécution de la revue, et le
suivi post-réunion.
• Si besoin, il peut servir d’intermédiaire entre les différents points
de vue
• Souvent la personne sur qui repose le succès d’une revue

Rôles et responsabilités (suite)
3.2.2
• Rôles (suite)
– L'auteur
• Personne à qui incombe la responsabilité principale du ou des
document(s) à revoir
– Les réviseurs
• Individus avec une culture technique ou commerciale spécifique
(aussi appelés vérificateurs ou inspecteurs) qui, après la
préparation nécessaire, identifient et décrivent les constatations
(p.ex. défauts) dans le produit en cours de revue
• Les réviseurs devraient être choisis pour représenter les
perspectives et rôles différents dans le processus de revue et
doivent prendre part à toutes les réunions de revue

Rôles et responsabilités (suite)
3.2.2
• Rôles (suite)
– Le scribe (ou greffier)
• Documente tous les aspects, problèmes et points ouverts
identifiés pendant la réunion
• En examinant des documents de différentes
perspectives et en utilisant des check-lists, les revues
peuvent devenir plus efficaces et rentables, par
exemple
– Une check-list basée sur le perspective d’un utilisateur,
d’un mainteneur, d’un testeur ou d’un opérateur
– Une check-list reprenant des problèmes d’exigences
typiques

Exemples de check-list
3.2.2
• Check-list d'attributs à rechercher dans le document
– Complet
• Y a-t-il des parties manquantes ou incomplètes?
• Est-ce que des documents référencés sont essentiels à la
compréhension?
– Exact
• La solution proposée est-elle adéquate?
• Les objectifs sont-ils bien définis?
• Y a-t-il des erreurs évidentes?
– Précis, sans ambiguïté
• Les descriptions sont-elles précises et sans confusion?
• Peut-il y avoir qu'une seule interprétation?
• Est-ce facile à lire et comprendre?
– Cohérent
• Les descriptions sont-elles cohérentes les une aux autres?
Exemples de check-list (suite)
3.2.2
• Check-list d'attributs à rechercher (suite)

– Pertinent
• Les descriptions sont-elles pertinentes aux objectifs?
• L'information fournie est-elle superflue?
• Peut-on relier le texte aux exigences du client?
– Faisable
• Peut-on l'implanter avec les ressources disponibles (personnel,
outils, $$$ et échéancier)?
– Sans code source
• Le document s'en tient-il à décrire le produit et non à son design?
– Testable
• Est-ce possible de tester le produit?
• Y a-t-il assez d'information pour vérifier/valider le produit?

3.2.2
• Check-list terminologique : attention au mots

suivants
– Toujours, chaque, toutes, aucune, jamais
• S'assurer que ce sont bien des certitudes
– Certainement, conséquemment, clairement,
naturellement, évidemment
• Tentent généralement de persuader le lecteur à
accepter un énoncé comme une évidence
– Quelques, parfois, souvent, généralement,
couramment, la plupart
• Manquant de précision, il rendent les tests impossibles

3.2.2
• Check-list terminologique (suite)

– Bon, rapide, économique, efficace, petit, stable
• Termes non quantifiables, ils ne peuvent être testés
• S'ils apparaissent dans une spécification, plus de détails
doivent être fournis
– Traité, calculé, rejeté, omis, éliminé
• Peuvent englober plusieurs fonctionnalités qui doivent
être détaillées
– Si ... alors (sans aucun sinon)
• Et que fait-on si la condition n'est pas positive?

Types de revues
3.2.3
• Un document peut être le sujet de plusieurs

revues
– L’ordre peut varier
• Exemples
– Une revue informelle peut être effectuée avant
une revue technique
– Une inspection peut être effectuée sur une
spécification d’exigences ou avant une relecture
technique avec des clients
EF 3.3 (P1,2)

Types de revues (suite)
3.2.3
• Les types de revues sont

– Revue informelle
• Sans processus formel ni documentation
– Relecture technique
• L'auteur du document guidant les réviseurs dans sa
lecture
– Revue technique
• Rencontre de discussion visant un consensus sur le
contenu technique du document
– Inspection
• Revue formelle, complète et détaillée du document

Revue informelle
3.2.3
• Objectif principal
– Manière bon marché d’obtenir des résultats
• Caractéristiques clé
– Pas de processus formel
– Peut inclure la programmation par paires ou une
revue de conception et de code par un
responsable technique
– Peut optionnellement être documentée
– Peut varier en utilité selon le réviseur

Relecture technique
3.2.3
• Objectifs principaux
– Apprendre, gagner en compréhension, trouver des défauts
– Réunion dirigée par l’auteur
– Scénarios, répétition à blanc, groupe de pairs
– Sessions sans limite de durée
– Optionnellement une réunion de préparation de revue par
les réviseurs, un rapport de revue, une liste de
constatations et un scribe (qui n’est pas l’auteur)
– Varie en pratique d’informelle à très formelle

Relecture technique (suite)
3.2.3
• L'auteur fait le gros de la préparation

– Les participants n'ont pas à se préparer Relecture technique :
une présentation pas à
– Conséquences pas par l’auteur d’un
• Le nombre de participants peut être grand document de façon à
réunir des informations et
• Ceux-ci n'ont pas à être très connaissant à établir une
sur le sujet compréhension commune
de son contenu.
• Visées éducatives
• Inviter des participants de divers compétences et
connaissances
– On assure ainsi qu'aucun défaut majeur n'est omis
• Particulièrement approprié pour les documents de
haut niveau (exigences, architectures, ...)
Revue technique
3.2.3
• Objectifs principaux
– Discuter, décider, évaluer des alternatives, trouver
des défauts, résoudre des problèmes techniques
– Vérifier la conformité à des standards et des
spécifications
– Assurer dès le début que les concepts techniques
sont exploités adéquatement
– Documentée, processus de détection de défauts
défini incluant des pairs et des experts techniques

Revue technique (suite)
3.2.3
• Caractéristiques clé (suite) Revue technique : une

activité de discussions de
– Peut être effectuée comme une groupes de pairs qui se
focalise sur l’obtention
revue de pairs sans participation de d’un consensus sur une
approche technique à
l’encadrement prendre. Une revue
technique est aussi
– Idéalement dirigée par un modérateur connue comme une revue
formé (pas l’auteur) de pairs.
– Réunion de préparation
– Peut optionnellement utiliser des check-lists, rapports de
revue, liste de constatations et participation de
l’encadrement
– Peut varier en pratique d’informelle à très formelle

Inspection
3.2.3
• Objectif principal Inspection : un type de

revue qui se base sur un
– Trouver des défauts examen visuel de documents
pour détecter des défauts
• Caractéristiques clé (p.ex. violation des standards
de développement et non
respect de documentation
– Dirigée par un modérateur formé de haut niveau). Revues
(pas l’auteur) techniques les plus formelles
et donc toujours basées sur
– Généralement examen par les pairs des procédures
documentées.
– Rôles définis
– Inclut des métriques
– Processus formel basé sur des règles et des check-lists avec
des critères d’entrée et de sortie
– Réunion de préparation
Inspection (suite)
3.2.3
• Caractéristiques clé (suite)

– Rapport d’inspection, liste de constatations
– Processus formel de suivi
– Optionnellement, amélioration des processus et
leçons des défauts identifiés
• Principale distinction de la revue technique
– La revue technique est moins formelle
• L'inspection est la plus formelle des revues
– La revue technique ne vise pas uniquement à
trouver les défauts

Facteurs de succès
3.2.3
• Facteurs clés de succès d'une revue formelle

1. Identification des problèmes
• Pas seulement identifier les anomalies, mais aussi les
omissions
• Diriger les critiques vers le document, pas vers son
auteur
– Et comme auteur, ne pas prendre les critiques comme des
attaques personnelles
2. Respecter les règles
• Elles doivent être établies à l'avance
• Les participants doivent connaître exactement leur rôle
et ce qu'on attend d'eux

Facteurs de succès (suite)
3.2.3
3. Préparation
• Chaque participant doit se préparer et contribuer à la
revue
• Sans préparation adéquate, la revue est vouée à l'échec
4. Rédaction du rapport
• Le rapport doit détailler les défauts identifiés ainsi que
les recommandations des participants
• Il doit être distribué aux développeurs et autres
membres de l'organisation afin de les maintenir
informés
• Des métriques permettent d'évaluer la progression

Facteurs de succès des revues
3.2.4
• Les facteurs de succès des revues incluent

– Chaque revue a un objectif prédéfini et clair
– Les personnes impliquées sont adéquates pour les
objectifs de la revue
• Et surtout, trouver un modérateur efficace et motivé
– Les défauts trouvés sont bien acceptés, et exprimés
objectivement
– Les aspects personnels et psychologiques sont traités
(p.ex. en faisant de cela une expérience positive pour
l’auteur)

Facteurs de succès des revues (suite)
3.2.4
– Les techniques de revue adaptées aux types et au niveau

de livrable logiciel, et aux types et niveau de réviseurs,
sont appliquées
• Par exemple, éviter la revue formelle pour un document moins
important afin d'éviter de démotiver les réviseurs
– Des check-lists ou rôles sont utilisées si approprié, afin
d’augmenter l’efficacité de détection des défauts
• Mais éviter de compliquer les règles sans raison
– Des formations sont données sur les techniques de revue,
spécialement concernant les techniques plus formelles
telles les inspections

3.2.4
– L’encadrement supporte un bon processus de revue

• Par exemple en incorporant du temps pour les activités de revue
dans les plannings projets
– L’ accent est mis sur l’apprentissage et l’amélioration du
processus
• Par exemple, consigner les heures consacrées par chaque
participant à la revue permet d'améliorer le planning des revues
futures
– Documenter les résultats de la revue et diffuser ses
conclusions au reste de l'organisation
• En incluant des métriques afin de permettre une évaluation rapide
de la progression

3.2.4
• Et surtout, faire des revues!

– Malheureusement, plusieurs organisations
négligent celles-ci
– Le processus est simple, pas nécessairement facile
– Impliquer du personnel expérimenté si possible
– Viser l'amélioration du processus au fil des revues
EF 3.3 (P3)

3.3 - Analyse statique outillée
3.3
• Objectifs
– Décrire les objectifs d’une analyse statique et les
comparer à l’analyse dynamique
– Rappeler les défauts et erreurs typiques
identifiées par les analyses statiques et les
comparer aux revues et tests dynamiques
– Lister les avantages typiques des analyses
statiques
– Lister les défauts typiques dans le code et la
conception qui peuvent être identifiés par des
outils d’analyse statique
Valeur de l'analyse statique
3.3
• Vise à trouver des défauts dans le code source

et les modèles logiciels
• Effectuée sans exécuter le code examiné par
l’outil, alors que les tests dynamiques
exécutent le code logiciel
• Peut détecter des défauts qui sont difficiles à
trouver par les tests
– L’identification de défauts difficilement
détectables par des tests dynamiques
Valeur de l'analyse statique (suite)
3.3
• Information avancée sur certains aspects

louches du code ou de la conception par le
calcul de métriques, par exemple une mesure
de complexité élevée
– Détection de dépendances et d’inconsistances
dans le design de logiciels
• Trouve des défauts plutôt que des défaillances
(comme les revues)

Valeur de l'analyse statique (suite)
3.3
• Amélioration de la maintenabilité du code et

de la conception de celui-ci
• Prévention des défauts, si les leçons sont
prises en compte lors du développement
• Les outils analysent le code programme (p.ex.
flux de contrôle et flux de données), ainsi que
les sorties générées tel que HTML et/ou XML

Défauts typiques découverts
3.3
• 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
– Code non accessible (code mort)
– Violation des standards de programmation
– Vulnérabilités de sécurité
– Violation de syntaxe dans le code ou le modèle logiciel

Outils d'analyse statique
3.3
• La plupart des outils servent à analyser le code

source logiciel
– Généralement exploités par les développeurs mais
servent aussi aux tests
• Même les compilateurs font de l'analyse statique
– Les outils sophistiqués offrent
• Des métriques de code source telles que la profondeurs
des structures et la complexité cyclomatique
• Validation selon les standards de code
• Affichage graphique des flux de contrôle et de données

Déficience des langages
3.3
• L'analyse statique comble les déficiences des

langages de programmation
• Exemple de défaut difficilement identifiable
lors de l'exécution du code
– Faiblesses des langages void main() {
int i, a[] = {0, 6, -3};
• Le C contient plus de 700 int k = 0;
déficiences!
for (i = 1; i < 3; i++)
• On retrouve en moyenne k += a[i];
8 défauts semblables par printf("Somme = %d", i);
1000 lignes de code source }

Règles de programmation
3.3
• Deux catégories de règles

– Standards : doivent être obligatoirement respectés
– Directives : recommandations, meilleures pratiques
• Assurent
– Fiabilité : moins sujet à certains types d'erreurs
• Exemple : éviter les variables polymorphiques
– Lisibilité et maintenabilité : plus facile à gérer et modifier
• Exemple : indentation du code imbriqué
– Portabilité : compilable sur toutes les plateformes
respectant les mêmes standards
• Exemple : ANSI C

Exemple de standard
3.3
• Quatre sections d'un SUJET: 3.05 Restrictions de contrôle de flux
standard ou d'une directive STANDARD

L'instruction goto (ainsi que les étiquettes) ne doit pas
être utilisée
1. Identification La boucle do-while doit être utilisée seulement lorsque

au moins une itération doit être exécutée. Sinon la
boucle while doit être utilisée.
• Titre et code indicatif Si une structure if-else peut remplacer un continue, le
if-else doit être utilisé.
2. Type et description JUSTIFICATION

L'instruction goto est prohibée pour des considérations
• Standard ou directive empiriques suggérant une corrélation majeure entre
l'utilisation de cette instruction et des défauts de
programmation ainsi qu'un déclin de lisibilité. De plus,
3. Justification le goto causent une divergence entre l'algorithme et

le processus sous-jacent émulé.
• Raisons du standard La boucle do-while est déconseillée car les boucles

doivent toujours être programmées telles que toutes les
itérations soient identiquement conditionnelles,
4. Exemples incluant la première.
• Afin de bien illustrer le standard

Exemple de directive
3.3
• Attention à ne pas confondre SUJET: 7.08 Conflits C versus C++
une directive et un style de DIRECTIVE

Éviter d'exploiter les attributs du langage C suivants
lorsque le C est intégré à du code source C++ :
programmation 1. Ne pas exploiter setjmp et longjmp s'il y a des

objets avec destructeurs pouvant être crées
entre les deux instructions.
– Une directive est une obligation 2. Ne pas exploiter la macro offsetof aux classes;
seulement l'appliquer aux structures C.
imposée par l'organisation afin

3. Ne pas appliquer les instructions d'entrées/
sorties standard C (avec stdio.h) et celles du
C++ (avec iostream.h) sur un même fichier.
d'éviter des défauts mais ne 4. Éviter d'appliquer les instructions memcpy et

memset aux objets autres que le tableau
unidimensionnel de char.
constitue pas un standard 5. Éviter d'utiliser la macro NULL; utiliser plutôt 0.
JUSTIFICATION
– Un style de programmation est Chacun des items de cette directive implique une
pratique de programmation en C reconnue comme
une façon de programmer qui

Problématique lorsque intégrée au C++.
est spécifique au programmeur;

il ne constitue pas nécessairement un défaut

Source de standards
3.3
• Organisations nationales et internationales offrant

des standards de programmation
– American National Standards Institute (ANSI)
• www.ansi.org
– Organisation internationale de normalisation (ISO)
• www.iso.org
– International Engineering Consortium (IEC)
• www.iec.org
– National Committee for Information Technology Standards
(NCITS)
• www.ncits.org

Sources de directives
3.3
• Ces organisations offrent divers documents

portant sur les meilleures pratiques en
programmation
– Association for Computing Machinery (ACM)
• www.acm.org
– Institute of Electrical and Electronics Engineers
(IEEE)
• www.ieee.org
• Les manufacturiers de compilateurs offrent
aussi des documents similaires
EF 3.4

Check-lists de revue de code
3.3
• Listes de vérifications à appliquer au code

source durant les revues de code
– À ne pas confondre avec les standards et
directives
• Élaborées à partir des défauts courants
rencontrés dans les projets de développement
• Requièrent des connaissances en
programmation pour les appliquer
– Donc destinées aux développeurs
Check-lists de revue de code (suite)
3.3
• Catégories de check-lists
– Défauts de références aux données
– Défauts de déclaration de données
– Défauts de calculs
– Défauts de comparaisons
– Défauts de flux d'exécution
– Défauts de paramètres de routines
– Défauts d'entrées/sorties
– Défauts autres

3.3
• Check-list de défauts de références aux

données
– Chaque variable référencée est-elle initialisée?
– Les indices de références aux tableaux sont-ils à
l'intérieur des bornes d'indices?
• Éviter les débordements d'indice
• Y a-t-il risque de débordement de 1 (ex: 1 à n ou 0 à
n-1)
– Est-il possible de remplacer une variable par une
constante?
3.3
• Check-list de défauts de références aux

données (suite)
– La valeur affectée à chaque variable correspond-t-
elle au type de la variable?
• Éviter les moulages de type implicites
– Chaque pointeur contient-il l'adresse d'un bloc
mémoire valide?
• Éviter les accès aux adresses invalides
– Une même structure référencée par plusieurs
routines correspond-t-elle à la même définition?
3.3
• Check-list de défauts de déclaration de données

– Toutes les variables sont-elles déclarées avec le type, la
taille et la portée appropriée?
– Les variables sont-elles initialisées selon les besoins?
– Y a-t-il des variables avec noms similaires?
– Y a-t-il des variables déclarées mais jamais utilisées ou
utilisées une seule fois?
– Les variables sont-elles toutes explicitement déclarées?
– Y a-t-il des variables globales?
• Si oui, y a-t-il risque de confusion avec des variables locales?

3.3
• Check-list de défauts de calculs

– Y a-t-il des calculs impliquant des variables de
différents types?
– Les variables de types identiques impliquées dans
un même calcul ont-elles toutes la même taille?
• Ex: danger d'un calcul impliquant un int et un long
– Le comportement du compilateur lors du moulage
de types implicite est-il bien compris?
– Est-ce que la taille de chaque variable peut
accommoder les valeurs y étant affectées?

3.3
• Check-list de défauts de calculs (suite)

– Y a-t-il possibilité de dépassement (overflow) de capacité
ou d'insuffisance de capacité (underflow) dans les calculs?
– Y a-t-il des divisions ou modulos par zéro?
– Y a-t-il possibilité de perte de précision dans les calculs
entiers?
• Particulièrement les divisions entières
– Une variable peut-elle se voir attribuer une valeur externe
à ses limites logiques?
• Par exemple un % inférieur à 0 ou supérieur à 100
– L'ordre d'évaluation des opérateurs arithmétiques dans
une expression a-t-il été pris en compte adéquatement?

3.3
• Check-list de défauts de comparaisons

– Les comparaisons sont-elle corrects?
• Ça peut sembler simpliste, mais souvent il y a confusion
(exemples: < versus <=, = versus ==, la négation)
– Attention à la comparaison d'égalité (ou inégalité)
de flottants
• Il faut plutôt exploiter une intervalle d'égalité
– Les évaluations booléennes sont-elles adéquates?
• Attention à la négation (règle de Morgan)
• Attention aux entiers interprétés comme booléens

3.3
• Check-list de défauts de flux d'exécution

– Est-ce que les End (ou EndIf, EndWhile, },
etc.) correspondent bien à leur début de bloc
respectifs?
– Est-ce que l'exécution du programme, du module,
de la routine ou de la boucle va éventuellement
terminer?
– Est-il possible qu'une boucle se termine
prématurément?
• Ou qu'aucune itération ne soit jamais exécutée?

3.3
• Check-list de défauts de flux d'exécution

(suite)
– Est-il possible qu'une boucle itère une fois de
trop?
• Ou une fois de moins que requis?
– Est-ce que le flux d'exécution dans une structure
de sélection (ex: switch) est géré
adéquatement?
• Ex: manque-t-il des break?

3.3
• Check-list de défauts de paramètres de

routines
– Les arguments d'un appel correspondent-ils aux
paramètres de la routine (en type et en nombre)?
– Une routine a-t-elle plusieurs points de sorties?
• Pire, plusieurs points d'entrée? Ouch!
– Le type de chaque paramètre est-il adéquat?
• Ex: passage par valeur versus par référence
– Y a-t-il confusion d'unité de mesure entre les
arguments et les paramètres?
• Ex: système métrique versus système impérial
3.3
• Check-list de défauts d'entrées/sorties

– Le logiciel interprète-il adéquatement des
données lues ou produites?
• Les formats sont-ils corrects? Par exemple les codes de
format dans un printf() ou scanf().
– Le logiciel gère-t-il adéquatement les pannes de
périphériques?
• Les messages d'erreur correspondent-ils à la réalité?
– Les données invalides sont-elles gérées
adéquatement?
• Ex: l'utilisateur entre un caractère plutôt qu'un entier!

3.3
• Check-list de défauts autres

– Le logiciel va-t-il fonctionner adéquatement dans un
environnement où la langue est autre?
• Gère-t-il les caractères unicode?
– Le logiciel peut-il être porté à d'autres plateformes ou
compilateurs?
– Le logiciel peut-ils s'accommoder de différents
périphériques?
• Comment se comporte-il lorsqu'il y a manque de mémoire?
– Le compilateur produit-il des avertissements (warnings), et
si oui sont-ils pris en compte?
• Idéalement, aucun avertissement toléré
Métriques de code source
3.3
• Mesures de la "structure" du code source

– Fréquence des commentaires
– Profondeur des structures imbriquées
– Nombre de lignes de code
– Complexité cyclomatique Complexité : le degré
par lequel un composant
• Ces métriques sont mesurées ou système a une

conception et/ou une
afin d'estimer la complexité structure interne qui est

difficile à comprendre,
du code source
maintenir et vérifier.
– Lors du développement de nouveau code

– Lors des modifications au code existant
Métriques de code source (suite)
3.3
• Généralement, 20% du code source cause 80%

des défaillances
– Les métriques permettent de localiser le code
source constituant ce 20% problématique
– Information requise lors de l'analyse de risques
• Permettent aussi de mieux estimer les
ressources requises pour maintenir ce code
source complexe
– Servent de "flags" lorsque le code
source à risques doit être modifié

Complexité cyclomatique
3.3
• Mesure basée sur le nombre Complexité cyclomatique :

le nombre de chemins
de décisions dans un programme indépendants au travers d’un
programme. La complexité
– Permet d'évaluer l'ampleur des cyclomatique est définie par
tests requis, incluant les revues L – N + 2P, avec :
 L = le nombre d’arcs/liens
de code d’un graphe
 N = le nombre de nœuds
• Les parties du code source ayant une du graphe
valeur cyclomatique élevée nécessiteront  P = le nombre de parties
plus de revues et de tests dynamiques déconnectées du
graphe (p.ex. un
• Il y a plusieurs définitions de cette graphe appelant et
une
métrique routine).
– La plus simple consiste à compter le nombre de décisions

binaires (if, while, etc.), et ajouter 1

Complexité cyclomatique (suite)
3.3
• Exemple
– Complexité cyclomatique
• L-N+2P = 8-7+21 = 3
A = 354
• Simplifiée = 2 + 1 = 3
B>C
Si A = 354 Alors
Si B > C Alors
A=C A=B
A = B
Sinon
A = C
FinSi
FinSi
Afficher A Afficher A

Complexité cyclomatique (suite)
3.3
• Interprétation généralement reconnue de la

métrique en rapport aux risques
Comp. cyclomat. Évaluation de risques
1 à 10 Routine simple, peu de risques
11 à 20 Routine complexe, risques moyens
21 à 50 Routine très complexe, risques élevés
> 50 Routine non testable, risques très élevés

Structure du code source
3.3
• Les modules comptant le plus de code source

ne sont pas nécessairement les plus
complexes
– C'est la structure du code source qui détermine sa
complexité
• Aspects de structure à considérer
– Structures de flux de contrôle
– Structures de flux de données
– Structures de données

Structure du code source (suite)
3.3
• Structures de flux de contrôle Flux de contrôle : une

représentation abstraite
– Séquence d'exécution des instructions de toutes les séquences
d’événements (chemins)
– Reflète les décisions et itérations dans dans l’exécution d’un
composant ou système.
le design du logiciel
– Considère non seulement le nombre d'instructions, mais
aussi le nombre de fois que chaque instruction est
exécutée
– L'analyse du flux de contrôle sert aussi à identifier le code
source inatteignable
– Plusieurs métriques tiennent compte du flux de contrôle
• C'est le cas de la mesure cyclomatique

3.3
• Structures de flux de données Flux de données : une

représentation abstraite
– Séquence de modification des de la séquence et des
modifications possibles
données durant l'exécution du de l’état des objets de
données, où l’état d’un
code source objet est soit création,
utilisation ou destruction.
– Les transactions appliquées aux

données sont souvent plus complexes que les
instructions effectuant ces transactions
– Permet d'identifier les défauts comme
• Référence aux variables indéfinies
• Variables n'étant jamais utilisées
3.3
• Structures de données
– Organisation des données indépendamment des
instructions
– Exemples : listes chaînées, files, arbres binaires
• L'exploitation d'une structure courante réduit le
potentiel de défauts car les algorithmes de
manipulation sont bien connus et disponibles
– Une structure de données complexe et/ou non
commune requiert du code source complexe pour
manipuler les données
• Risques de défauts accrus

Bénéfices de l'analyse statique
3.3
• En résume, l'analyse statique apporte

– La détection précoce de défauts, avant l'exécution du code
source
– La localisation des sources potentielles de défauts dans le
code, le design ou les spécifications
– L'identification de défauts difficiles à trouver via l'analyse
dynamique
– Une maintenabilité accrue du code et du design via
l'application de standards et directives
– La prévention de défauts via les leçons apprises et
l'amélioration des processus de revues
EF 3.5

Glossaire
3
Test dynamique (dynamic testing) : test qui nécessite l’exécution

du logiciel d’un composant ou système.
Test statique (static testing) : test d’un composant ou système
au niveau spécification ou implémentation sans exécution de
ce logiciel (p.ex. : revues ou analyse statique du code).
Produits de logiciel (software products) : ensembles des
artefacts produits pendant le cycle de vie d'un logiciel (p.ex. :
documents, code source, testware).
Testware (testware) : artefact produit pendant le processus de
test afin de planifier, concevoir et exécuter les tests, tel que la
documentation, les scripts, les entrées, les résultats attendus,
les procédures de mise en place et de nettoyage, les fichiers,
bases de données, environnements et tout logiciel ou
utilitaires supplémentaire utilisé dans les tests.
Glossaire (suite)
3
Revue (review) : une évaluation d’un état d’un produit ou projet

pour s’assurer des déviations par rapport aux résultats
planifiés et recommander des améliorations. Exemples : revue
de gestion, revue informelle, revue technique, inspection et
relecture technique.
Revue informelle (informal review) : une revue qui n’est pas
basée sur une procédure formelle (documentée).
Revue formelle (formal review) : une revue caractérisée par des
procédures et exigences documentées (p.ex. inspection).
Modérateur (moderator) : le leader et principale personne
responsable d’une inspection ou autre processus de revue.
Aussi appelé chef d'inspection.

Glossaire (suite)
3
Critère d’entrée (entry criteria) : l’ensemble des conditions

spécifiques et génériques pour permettre à un processus de
continuer à exécuter une tâche définie (p.ex. une phase de
tests). Le but d’un critère d’entrée est d’empêcher le début
d’une tâche qui générerait une charge de travail plus
importante (inutile et gaspillée) que celle nécessaire pour
supprimer le critère d’entrée défaillant.
Réviseur (reviewer) : la personne impliquée dans une revue qui
identifiera et décrira les anomalies dans le produit ou projet
en revue. Les réviseurs peuvent être choisis pour représenter
divers points de vue ou rôles dans le processus de revue.

Glossaire (suite)
3
Scribe (scribe) : la personne qui doit enregistrer chaque

anomalie mentionnée et chaque suggestion d’amélioration
pendant une revue, sur un formulaire de prise de note. Le
scribe doit s’assurer que le formulaire de prise de notes est
lisible et compréhensible. Aussi appelé greffier.
Critère de sortie (exit criteria) : l’ensemble des conditions
génériques et spécifiques, convenues avec les responsables,
pour permettre de terminer officiellement un processus.
L’objectif d’un critère de sortie est d’éviter qu’une tâche ne
soit considérée comme achevée alors qu’il y a encore des
parties de cette tâche qui n’ont pas été terminées. Les critères
de sortie sont utilisés dans le test pour faire des comptes
rendus et pour planifier l’arrêt du test.

Glossaire (suite)
3
Relecture technique (walkthrough) : une présentation pas à pas
par l’auteur d’un document de façon à réunir des
informations et à établir une compréhension commune de
son contenu.
Revue technique (technical review) : une activité de discussions
de groupes de pairs qui se focalise sur l’obtention d’un
consensus sur une approche technique à prendre. Une
revue technique est aussi connue comme une revue de
pairs (peer review).
Inspection (inspection) : un type de revue qui se base sur un
examen visuel de documents pour détecter des défauts
(p.ex. violation des standards de développement et non
respect de documentation de haut niveau). Revues
techniques les plus formelles et donc toujours basées sur
des procédures documentées.
Glossaire (suite)
3
Complexité (complexity): le degré par lequel un composant ou

système a une conception et/ou une structure interne qui est
difficile à comprendre, maintenir et vérifier.
Complexité cyclomatique (cyclomatic complexity): le nombre de
chemins indépendants au travers d’un programme. La
complexité cyclomatique est définie par L – N + 2P, avec :
 L = le nombre d’arcs/liens d’un graphe
 N = le nombre de nœuds du graphe
 P = le nombre de parties déconnectées du
graphe (p.ex. un graphe appelant et une routine).
Flux de contrôle (control flow) : une représentation abstraite de
toutes les séquences d’événements (chemins) dans
l’exécution d’un composant ou système.

Glossaire (suite)
3
Flux de données (data flow) : une représentation abstraite de la

séquence et des modifications possibles de l’état des objets
de données, où l’état d’un objet est soit création, utilisation
ou destruction.

Chap3 Techniques Statiques 11

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Chap3 Techniques Statiques 11

Transféré par

Droits d'auteur :

Formats disponibles

Tests logiciels

Techniques statiques 25913 IFM – Tests logiciels 3.1

• 3.1 - Revues et processus de test

Techniques statiques 25913 IFM – Tests logiciels 3.2

• Objectif fondamental des tests statiques

Techniques statiques 25913 IFM – Tests logiciels 3.3

• Complémentaires Test dynamique : test

• Les tests dynamiques sont applicables uniquement

• Artefacts produits pendant le cycle de vie d'un

• Spécifications Testware : artefact produit

– Testware de mise en place et de nettoyage,

Techniques statiques 25913 IFM – Tests logiciels 3.6

• Principale stratégie d'analyse statique

Techniques statiques 25913 IFM – Tests logiciels 3.8

Techniques statiques 25913 IFM – Tests logiciels 3.9

• Les tests statiques facilitent l'identification des

Techniques statiques 25913 IFM – Tests logiciels 3.10

• Les revues s'appliquent autant aux documents

Techniques statiques 25913 IFM – Tests logiciels 3.11

– Les revues de plans et/ou cas de test permettent

La revue Document Numérique int fonction_somme(int entier1,int login [as ROLE-OR-USER] :

Spécifications Design Code source Cas de test

Techniques statiques 25913 IFM – Tests logiciels 3.12

Techniques statiques 25913 IFM – Tests logiciels 3.13

– Deux intervenants, un révisant le travail de l'autre

Techniques statiques 25913 IFM – Tests logiciels 3.14

• Une revue formelle typique comprend les phases

Techniques statiques 25913 IFM – Tests logiciels 3.15

• Pour les revues formelles (p. ex. une

• Exemples de critères d'entrée

• Parties du document ciblées

Techniques statiques 25913 IFM – Tests logiciels 3.19

• Membres sélectionnés par le modérateur et l'auteur

Conformité Document Documents Ex: interfaces

Techniques statiques 25913 IFM – Tests logiciels 3.20

• Première rencontre des membres

s'entendre sur l'échéancier et les rôles

• Les membres révisent leur partie du document selon

Techniques statiques 25913 IFM – Tests logiciels 3.22

• Dirigée par le modérateur Scribe : la personne qui doit

Techniques statiques 25913 IFM – Tests logiciels 3.23

• Les critères de sortie peuvent être modifiés

– L'auteur doit faire les convenues avec les responsables, pour

corrections demandées processus. L’objectif d’un critère de sortie

et resoumettre le comme achevée alors qu’il y a encore des

document par la suite terminées. Les critères de sortie sont utilisés

Techniques statiques 25913 IFM – Tests logiciels 3.24

• L'auteur doit corriger les défauts identifiés

Techniques statiques 25913 IFM – Tests logiciels 3.25

• Le modérateur est responsable du suivi des

Techniques statiques 25913 IFM – Tests logiciels 3.26

• Une revue formelle typique inclue les rôles suivants

Techniques statiques 25913 IFM – Tests logiciels 3.27

Techniques statiques 25913 IFM – Tests logiciels 3.28

Techniques statiques 25913 IFM – Tests logiciels 3.29

• Check-list d'attributs à rechercher (suite)

Techniques statiques 25913 IFM – Tests logiciels 3.31

• Check-list terminologique : attention au mots

Techniques statiques 25913 IFM – Tests logiciels 3.32

• Check-list terminologique (suite)

Techniques statiques 25913 IFM – Tests logiciels 3.33

• Un document peut être le sujet de plusieurs

Techniques statiques 25913 IFM – Tests logiciels 3.34