Syllabus CFTL

3. Techniques statiques (K2)

3.1 Techniques statiques et processus de test (K2)

Termes
Test dynamique, test statique.
Contexte
Contrairement au test dynamique, qui exige l‟exécution du logiciel, les techniques de tests statiques reposent sur l‟examen manuel (revues) ou l‟analyse(analyse statique) du code ou de la documentation du projet sans exécution du code.
Les revues sont une manière de tester des produits logiciels (y compris du code) et peuvent être exécutées bien avant l‟exécution de tests dynamiques. Les défauts détectés pendant les revues effectuées tôt dans le cycle de vie sont souvent bien moins coûteux à ôter que les défauts détectés lors de l‟exécution des tests (p.ex. défauts trouvés dans les exigences).
Une revue pourrait être effectuée entièrement manuellement, mais il existe aussi des outils de support. L‟activité manuelle principale est d‟examiner le produit et d‟en faire des commentaires. 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 utilisateur ou pages web.
Les bénéfices des revues incluent une détection et une correction anticipées des défauts , des améliorations de productivité dans le développement, des durées de développement réduites, des durées et des coûts de tests réduits, des réductions de coûts tout au long de l‟existence du logiciel, moins de défauts et une meilleure communication. Les revues peuvent détecter des omissions, par exemple, dans des exigences, dont la détection pendant les tests dynamiques est peu probable.
Les revues, les analyses statiques et les tests dynamiques ont le même objectif – identifier des défauts. Ils sont complémentaires : les différentes techniques peuvent trouver différents types de défauts efficacement et rapidement. Contrairement aux tests dynamiques, les techniques statiques trouvent les causes des défauts plutôt que les défaillances elles-mêmes.
Les défauts typiques plus faciles à trouver lors de revues que pendant les tests dynamiques sont : déviations par rapport aux standards, défauts d‟exigences, défauts de conception, maintenabilité insuffisante et spécifications incorrectes d‟interfaces.

3.2 Processus de revue (K2)

Termes
Critère d‟entrée, revue formelle, revue informelle, inspection, métriques, modérateur, revue de pairs, réviseur, scribe, revue technique, relecture technique.
Contexte
Les différents types de revues varient de « informel », caractérisé par l‟absence d‟instructions écrites pour les relecteurs, à « systématique », caractérisé par la participation de l‟équipe, des résultats documentés de la revue, et des procédures documentées pour mener la revue. La formalité d‟un processus de revue est liée à des facteurs tels que la maturité du processus de développement, toute disposition légale ou exigence réglementaire ou la nécessité de traces d‟audit.
La manière dont une revue est exécutée dépend des objectifs convenus pour la revue (p.ex. trouver des défauts, augmenter la compréhension, former les testeurs et les nouveaux membres d‟une équipe ou organiser la discussion et décider par consensus).

3.2.1 Phases d‟une revue formelle (K1)
Une revue formelle typique comprend les phases principales suivantes:
1. Planification :
 Définir les critères de revues
 Choisir le personnel
 Allouer les rôles
 Définition des critères d‟entrée et de sortie pour des types de revues plus formels (p.ex., inspections)
 Sélectionner la partie des documents à revoir
 Vérification des critères d‟entrée (pour des types de revues plus formels)
2. Lancement:
 Distribuer les documents
 Expliquer les objectifs, le processus et les documents aux participants
3. Préparation individuelle
 Préparer la réunion de revue en revoyant le(s) document(s)
 Ecriture des défauts potentiels, questions et commentaires
4. Examen/évaluation/enregistrement des résultats (réunion de revue):
 Discuter ou enregistrer, avec des résultats ou minutes documentés (pour des types de revues plus formels)
 Noter les défauts, faire des recommandations concernant le traitement des défauts, prendre des décisions à propos des défauts
 Examen/évaluation et enregistrement pendant toutes les réunions physiques ou enregistrement de toutes les communications électroniques
5. Re travail
 Correction des défauts détectés (réalisé généralement par l‟auteur)
 Enregistrer le statut modifié des défauts (dans les revues formelles)
6. Suivi:
 Vérifier que les défauts ont bien été traités
 Récolter les métriques
 Contrôle sur la base des critères de sorties (pour des types de revues plus formels)

3.2.2 Rôles et responsabilités (K1)
Une revue formelle typique inclura les rôles ci-dessous :

 Manager : décide l‟exécution des revues, alloue le temps dans la planification du projet et détermine si les objectifs de revue ont été atteints.
 Modérateur: la personne qui 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, le modérateur peut servir d‟intermédiaire entre les différents points de vue et est souvent la personne sur qui repose le succès d‟une revue.
 Auteur : l‟auteur ou la personne à qui incombe la responsabilité principale du ou des document(s) à revoir.
 Réviseurs : les individus avec une culture technique ou métier 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 prennent part à toute réunion de revue.
 Scribe (ou greffier): documente tous les aspects, problèmes et points ouverts identifiés pendant la réunion.
En examinant des documents selon 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 la perspective d‟un utilisateur, d‟un mainteneur, d‟un testeur ou d‟un opérateur, ou une check-list reprenant des problèmes d‟exigences typiques.

3.2.4 Facteurs de succès des revues (K2)
Les facteurs de succès des revues incluent:
 Chaque revue a des objectifs prédéfinis et clairs.
 Les personnes impliquées sont adéquates pour les objectifs de la revue.
 Les testeurs sont des réviseurs de valeur qui contribuent à la revue et ainsi prennent connaissance du produit afin de pouvoir préparer les tests plus tôt.
 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)).
 La revue est menée dans une atmosphère de confiance ; les résultats ne sont pas utilisés pour évaluer les participants ;
 Les techniques de revue adaptées aux objectifs, adaptées aux types et au niveau de livrable logiciel, et adaptées aux types et niveau des réviseurs, sont appliquées.
 Des check-lists ou des rôles sont utilisés lorsque cela est approprié, afin d‟augmenter l‟efficacité de détection des défauts.
 Des formations sont données sur les techniques de revue, en particulier celles concernant les techniques plus formelles telles que les inspections.
 L‟encadrement supporte un bon processus de revue (p.ex. en incorporant du temps pour les activités de revue dans les plannings des projets).
 L‟accent est mis sur l‟apprentissage et l‟amélioration du processus.

3.3 Analyse statique avec des outils (K2)

Termes
Compilateur, complexité, flux de contrôle, flux de données, analyse statique.
Contexte
L‟objectif de l‟analyse statique est de trouver des défauts dans le code source et les modèles logiciels. L‟analyse statique est effectuée sans vraiment exécuter le code examiné par l‟outil ; les tests dynamiques exécutent le code logiciel. L‟analyse statique peut détecter des défauts qui sont difficiles à trouver par les tests dynamiques. Comme pour les revues, l‟analyse statique trouve des défauts plutôt que des défaillances. Les outils d‟analyse statique analysent le code du programme (p.ex. les flux de contrôle et les flux de données), ainsi que les sorties générées telles que HTML et/ou XML.
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.
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.
Les outils d‟analyse statique sont typiquement utilisés par des développeurs (vérification par rapport à des règles prédéfinies ou des standards de programmation) avant et pendant les tests de composants et les tests d‟intégration, ou pendant la mise à jour du code dans les outils de gestion de configuration, et par les concepteurs pendant la modélisation logicielle. 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.
Les compilateurs peuvent offrir un certain support aux analyses statiques, notamment en incluant le calcul de métriques.