Syllabus CFTL

Retour au sommaire

Tester pendant le cycle de vie logiciel (K2)

2. Tester pendant le cycle de vie logiciel (K2)

2.1 Modèles de Développement Logiciel (K2)

Termes
Logiciel commercial sur étagère (en anglais : Commercial Off The Shelf ou COTS), modèle de développement incrémental niveaux de tests, validation, vérification, modèle en V.
Contexte
Les tests n‟existent pas de façon isolée; les activités de test sont liées aux activités de développement logiciel. Les différents modèles de cycle de développement nécessitent des approches de tests différentes.

2.1.1 Modèle en V (K2)
Bien que des variantes du modèle en V existent, un modèle en V standard utilise quatre niveaux de tests, correspondant aux quatre niveaux de développement.
Les quatre niveaux utilisés dans le syllabus sont:
ï‚· Tests de composants (unitaires);
ï‚· Tests d‟intégration;
ï‚· Tests système;
 Tests d‟acceptation.
En pratique, un modèle en V peut avoir des niveaux de développement et de tests différents, en moins ou en plus, en fonction des projets et des produits logiciels. Par exemple, il peut y avoir des tests d‟intégration des composants après les tests de composants, et des tests d‟intégration de systèmes après des tests systèmes.
Les livrables logiciels (tels les scénarios d‟utilisation ou les cas d‟emploi, les spécifications d‟exigences, les documents de conception et le code) produits pendant le développement sont souvent les bases des tests d‟un ou plusieurs niveaux de tests. Des références pour des livrables génériques sont disponibles dans le modèle CMMI (Capability Maturity Model Integration) ou dans l‟IEEE/IEC 12207 (Processus de cycle de vie logiciel „Software life cycle processes‟). La vérification et la validation (ainsi que la conception au plus tôt des tests) peuvent être effectuées pendant le développement des livrables logiciels.

2.1.2 Modèle de développement itératif (K2)
Le mode de développement itératif est une succession d‟activités exécutées comme une série de petits développements: exigences, conception, construction et tests d‟un système. Exemples : prototypage, développement rapide d‟applications (RAD), Rational Unified Process (RUP) et les modèles de développement agiles. Le système logiciel résultant (l‟incrément) d‟une itération peut être testé à plusieurs niveaux de tests à chaque itération. Un incrément, ajouté à ceux développés préalablement, forme un système partiel en croissance, qui devrait également être testé. Les tests de régression sont de plus en plus importants sur toutes les itérations après la première. La vérification et la validation peuvent être effectuées sur chaque incrément.

2.1.3 Tester au sein d’un modèle de cycle de vie (K2)
Quel que soit le modèle de cycle de vie, plusieurs bonnes pratiques de tests s‟appliquent:
ï‚· A chaque activité de développement, correspond une activité de test.
ï‚· Chaque niveau de test a des objectifs de tests spécifiques pour ce niveau.
ï‚· L‟analyse et la conception des tests pour un niveau de test devraient commencer pendant l‟activité correspondante de développement.

ï‚· Les testeurs doivent être impliqués dans la revue des documents aussi tôt que des brouillons sont disponibles dans le cycle de développement.
Les niveaux de tests peuvent être combinés ou réorganisés selon la nature du projet ou de l‟architecture du système. Par exemple, pour l‟intégration d‟un logiciel sur étagère (COTS) dans un système, l‟acheteur peut effectuer des tests d‟intégration au niveau système (Ex. intégration dans l‟infrastructure et les autres systèmes, ou déploiement du système) ainsi que des tests d‟acceptation (fonctionnels et/ou non-fonctionnels, et tests d‟acceptation utilisateurs et/ou opérationnels).

2.2 Niveaux de tests (K2)

Termes
Alpha tests, Beta tests, tests de composant (aussi connus comme tests unitaires, de modules ou de programmes), tests d‟acceptation contractuelle, pilotes, tests sur le terrain, exigences fonctionnelles, intégration, tests d‟intégration, exigences non-fonctionnelles, tests de robustesse, bouchons, tests système, environnement de test, niveau de tests, développement dirigé par les tests, tests d‟acceptation utilisateurs.
Contexte
Pour chaque niveau de tests, les aspects suivants peuvent être identifiés: les objectifs génériques, le(s) livrable(s) référencé(s) pour dériver des cas de tests (c‟est à dire la base de test), les objets de tests (càd. ce qui est testé), les défauts et les défaillances typiques à trouver, les exigences en harnais de tests et en support d‟outils, ainsi que les approches et responsabilités spécifiques au niveau.
Les tests des données de configuration du système doivent être pris en compte au cours de la plannification des tests.

2.2.1 Tests de composants (K2)
Bases de tests:
ï‚· Exigences des composants
ï‚· Conception détaillée
ï‚· Code
Objets habituels de test:
ï‚· Composants
ï‚· Programmes
ï‚· Conversions de données / utilitaires ou programmes de migration
Modules de bases de données
Les tests de composants (également connus sous les noms de tests unitaires, de modules ou de programmes) cherchent des défauts dans, et vérifient le fonctionnement des, logiciels (p.ex. modules, programmes, objets, classes, etc.) qui sont testables séparément. Cela peut se faire de façon isolée par rapport au reste du système, en fonction du contexte du cycle de développement du logiciel et du système. Des bouchons, pilotes et simulateurs peuvent être utilisés.
Les tests de composants peuvent inclure des tests de fonctionnalités et des tests de caractéristiques non-fonctionnelles, telles que le comportement des ressources (p.ex. fuites mémoire) ou des tests de robustesse, ainsi que des tests structurels (p.ex. couverture des branches). Les cas de test sont dérivés des livrables tels que les spécifications des composants (spécifications détaillées), la conception du logiciel ou le modèle de données.
La plupart du temps, les tests de composants se font avec l‟accès au code du logiciel testé et sur un environnement de développement comme un framework de tests unitaire ou avec les outils de débogage. En pratique ils impliquent généralement le programmeur ayant écrit le code. Habituellement, les défauts sont corrigés dès qu‟ils sont trouvés, sans formellement enregistrer des incidents.
Une approche des tests de composants est de préparer et automatiser des cas de tests avant le codage. Cela s‟appelle l‟approche « Tester d‟abord » (en anglais : « test first »)ou « Développement piloté par les tests. Cette approche, fortement itérative est basée sur des cycles de développement de cas de tests, puis construction et intégration de petits bouts de code, puis exécution des tests de composants et correction des défauts trouvés jusqu‟à leur réussite.

2.2.2 Tests d‟intégration (K2)
Bases de Tests:
ï‚· Conception du logiciel et du système
ï‚· Architecture
ï‚· Workflows
 Cas d‟utilisation
Objets habituels de test:
ï‚· Sous-systèmes
ï‚· Implémentation de bases de données
ï‚· Infrastructure
ï‚· Interfaces
ï‚· Configuration système et données de configuration
Les tests d‟intégration testent les interfaces entre les composants, les interactions entre différentes parties d‟un système comme par exemple le système d‟exploitation, le système de fichiers, le matériel ou les interfaces entre les systèmes.
Plusieurs niveaux de tests d‟intégration peuvent être effectués sur des objets de taille variable. Par exemple:
ï‚· Tests d‟intégration des composants testant les interactions entre les composants logiciels et effectués après les tests de composants;
ï‚· Tests d‟intégration système testant l‟intégration entre les différents systèmes ou entre logiciel et matériel et pouvant être effectués après les tests système. Dans ce cas, l‟organisation en charge du développement peut ne contrôler qu‟un côté de l‟interface. Cela peut être considéré comme un risque métier. Les processus commerciaux mis en oeuvre comme les workflows peuvent impliquer plusieurs systèmes. Les aspects inter-plateformes peuvent être significatifs.
Plus la portée de l‟intégration est vaste, plus il devient difficile d‟isoler les défauts liés à un composant ou un système particulier. Cela peut conduire à un accroissement des risques et du temps nécessaire pour résoudre les problèmes.
Des stratégies d‟intégration systématique peuvent être basées sur l‟architecture des systèmes (telles que top-down ou bottom-up), les tâches fonctionnelles, les séquences d‟exécution de transactions, ou d‟autres aspects du système ou du composant. Afin d‟isoler facilement les fautes, et détecter les défauts au plus tôt, l‟intégration devrait normalement être incrémentale plutôt qu‟être effectuée en une fois (“big bang”).
Les tests de caractéristiques non-fonctionnelles particulières (p.ex. performances) peuvent être inclus dans les tests d‟intégration.
A chaque étape de l‟intégration, les testeurs se concentrent uniquement sur l‟intégration elle même. Par exemple, s‟ils sont en train d‟intégrer le module A avec le module B, les testeurs s‟appliquent à tester la communication entre les modules et non pas leurs fonctionnalités individuelles. Les approches fonctionnelles et structurelles peuvent toutes deux être utilisées.
Idéalement, les testeurs devraient comprendre l‟architecture et influencer le planning d‟intégration. Si les tests d‟intégration sont prévus avant que les composants ou les systèmes ne soient fabriqués, les tests pourront être conçus dans le bon ordre pour être efficaces et efficients.

2.2.3 Tests système (K2)
Bases de Test:
ï‚· Spécifications d‟exigences Système et logiciel

 Cas d‟utilisation
ï‚· Spécifications fonctionnelles
 Rapports d‟analyse des risques
Objets de tests habituels:
ï‚· Manuels système, utilisateur et opérationnels
ï‚· Configuration système et données de configuration
Les tests systèmes traitent le comportement d‟un système/produit complet. Le périmètre des tests doit être clairement défini dans le plan de test maitre ou le plan de test du niveau.
Pour les tests système, l‟environnement de test devrait correspondre à la cible finale ou à un environnement de production de façon à minimiser les risques de défaillances dues à l‟environnement.
Les tests système peuvent inclure des tests basés sur les risques et/ou sur les spécifications et les exigences, les processus commerciaux, les cas d‟utilisation, ou autres descriptions de haut niveau du comportement du système, les modèles de comportement, les interactions avec le système d‟exploitation et les ressources système.
Les tests système devraient examiner à la fois les exigences fonctionnelles et les non-fonctionnelles du système ainsi que la qualité des données. Les testeurs doivent également s‟adapter aux exigences peu ou pas documentées. Les tests fonctionnels au niveau système commencent par l‟utilisation des techniques de spécification de tests les plus appropriées (boîte noire). Par exemple, une table de décision peut être crée pour les combinaisons d‟effets décrits dans les processus commerciaux. Les techniques basées sur les structures (boîte blanche) peuvent ensuite être utilisées pour évaluer la minutie des tests par rapport à un élément comme la structure de menu ou la navigation dans la page web. (voir Chapitre 4.)
Une équipe de tests indépendante exécute souvent des tests système.

2.2.4 Tests d‟acceptation (K2)
Bases de test:
ï‚· Exigences utilisateur
ï‚· Exigences du système
 Cas d‟utilisation
ï‚· Processus métier
 Rapports d‟analyse des risques
Objets habituels de test:
ï‚· Processus métier sur l‟intégralité du système
ï‚· Processus opérationnels de maintenance
ï‚· Procédures utilisateur
ï‚· Formulaires
ï‚· Rapports
Données de configuration
Les tests d‟acceptation relèvent souvent de la responsabilité des clients ou utilisateurs d‟un système; d‟autres responsables (parties prenantes) peuvent aussi être impliqués.
Les objectifs des tests d‟acceptation sont de prendre confiance dans le système, dans des parties du système ou dans des caractéristiques non-fonctionnelles du système. La recherche d‟anomalies n‟est pas l‟objectif principal des tests d‟acceptation. Les tests d‟acceptation peuvent évaluer si le système est prêt à être déployé et utilisé, bien que ce ne soit pas nécessairement le dernier niveau de tests. Par exemple, une intégration système à grande échelle peut arriver après les tests d‟acceptation du système.
Les tests d‟acceptation peuvent se faire à plusieurs niveaux de tests, par exemple:
ï‚· Des tests d‟acceptation peuvent avoir lieu sur un composant sur étagère quand il est installé ou intégré.
ï‚· Les tests d‟acceptation de l‟utilisabilité d‟un composant peuvent être effectués pendant les tests unitaires.
ï‚· Les tests d‟acceptation d‟une évolution fonctionnelle peuvent être exécutés avant les tests système.
Les formes habituelles des tests d‟acceptation incluent :
Tests d’acceptation utilisateur
Ces tests vérifient l‟aptitude et l‟utilisabilité du système par des utilisateurs.
Tests (d’acceptation) opérationnelle
L‟acceptation du système par les administrateurs système, dont:
ï‚· Tests des backups et restaurations;
ï‚· Reprise après sinistre;
ï‚· Gestion des utilisateurs;
ï‚· Tâches de maintenance;
ï‚· Chargements de données et tâches de migration
ï‚· Vérification périodique des vulnérabilités de sécurité.
Tests d’acceptation contractuelle et réglementaire
Les tests d‟acceptation contractuelle sont exécutés sur base des critères d‟acceptation contractuels pour la production de logiciels développés sur mesure. Les critères d‟acceptation devraient être définis lors de la rédaction du contrat.
Les tests d‟acceptation réglementaires sont exécutés par rapport aux règlements et législations qui doivent être respectés, telles que les obligations légales, gouvernementales ou de sécurité.
Tests alpha et beta (ou sur le terrain)
Les développeurs de logiciels pour le public, ou de COTS (logiciel commercial sur étagère), souhaitent souvent recueillir l‟avis des clients potentiels ou existants sur leur marché, avant de mettre en vente.
Les Alpha tests sont exécutés sur le site de l‟organisation effectuant le développement mais pas par les équipes de développement. Les Béta tests ou tests sur le terrain sont exécutés par des personnes sur leurs sites propres.
Les organisations peuvent aussi utiliser d‟autres termes, tels que « tests d‟acceptation usine » ou « tests d‟acceptation sur site » pour des systèmes qui sont testés avant d‟être transférés sur le site client.

2.3 Types de tests (K2)

Termes
tests boîte noire, couverture du code, tests fonctionnels, tests d‟interopérabilité, tests de charge, tests de maintenabilité, tests de performances, tests de portabilité, tests de fiabilité, tests de sécurité, tests de stress, tests structurels, tests d‟utilisabilité, tests boîte blanche.
Contexte
Un groupe d‟activités de tests peut être axé sur la vérification du système logiciel (ou d‟une partie du système) pour une raison ou une cible particulière.
Un type de tests est focalisé sur un objectif de tests particulier, qui peut être
ï‚· le test d‟une fonction devant être effectuée par le logiciel;
ï‚· une caractéristique non-fonctionnelle, telle que la fiabilité ou l‟utilisabilité,
ï‚· la structure ou l‟architecture du logiciel ou du système;
ï‚· lié aux changements, p.ex. confirmer que des anomalies ont été corrigées (tests de confirmation) et pour rechercher la présence de modifications non voulues (tests de régression).
Un modèle du logiciel peut être développé et/ou utilisé dans des tests structurels et fonctionnels (p.ex un diagramme de contrôle de flux ou une structure de menu), dans des tests non fonctionnels (modèles de menaces de sécurité), dans les tests fonctionnels (p.ex un diagramme de flux de processus, un diagramme de transitions d‟état ou des spécifications en langage naturel).

2.3.1 Tests des fonctions (tests fonctionnels) (K2)
Les fonctionnalités qu‟un système, sous-système ou composant doit effectuer peuvent être décrites dans des livrables tels que des spécifications d‟exigences, les cas d‟utilisation, ou les spécifications fonctionnelles, ou encore non documentées. Les fonctions sont ce que « fait » le système.
Les tests fonctionnels sont basés sur ces fonctions et caractéristiques (décrites dans des documents ou comprises par les testeurs), et leur interopérabilité avec d‟autres systèmes. Ils peuvent être exécutés à tous les niveaux de tests (p.ex. les tests d‟un composant peuvent être basés sur les spécifications du composant).
Des techniques basées sur les spécifications peuvent être utilisées pour dériver des conditions de tests et des cas de tests à partir des fonctionnalités du logiciel ou du système (voir Chapitre 4.) Les tests fonctionnels concernent le comportement extérieur du logiciel (tests boîte noire).
Un type de test fonctionnel, le test de sécurité, examine les fonctions (p.ex. pare-feu) liées à la détection de menaces, comme des virus, provenant de tiers malveillants. Un autre type de test fonctionnel, le test d‟interopérabilité, évalue la capacité du logiciel à interagir avec un ou plusieurs composants ou systèmes spécifiés.

2.3.2 Tests des caractéristiques non fonctionnelles des produits logiciels (tests non-fonctionnels) (K2)
Les tests non-fonctionnels incluent, mais pas uniquement, les tests de performances, tests de charge, tests de stress, tests d‟utilisabilité, tests de maintenabilité, tests de fiabilité et les tests de portabilité. Ces tests évaluent “comment” le système fonctionne.
Les tests non-fonctionnels peuvent être effectués à tous les niveaux de tests. Le terme de tests non-fonctionnels décrit les tests requis pour mesurer les caractéristiques des systèmes et logiciels qui peuvent être quantifiées sur une échelle variable, comme les temps de réponse pour les tests de performances. Ces tests peuvent être référencés dans un modèle qualité tel que celui défini par l‟ISO9126 „Ingénierie Logicielle – Qualité des Produits Logiciels‟ („Software Engineering – Software Product Quality‟). Les tests non fonctionnels concernent l‟aspect extérieur du logiciel et la plupart du temps utilisent les techniques de conception de tests boîte noire.

2.3.3 Tests de la structure / architecture logicielle (tests structurels) (K2)
Les tests structurels (boîte blanche) peuvent être effectués à tous les niveaux de tests. Les techniques structurelles sont utilisées de façon optimale après les techniques basées sur les spécifications, pour aider à mesurer l‟ampleur des tests via l‟évaluation de la couverture d‟un type de structure.
La couverture indique à quel point une structure a été testée par une suite de tests. Elle est exprimée en pourcentage d‟éléments couverts. Si la couverture n‟est pas de 100%, alors de nouveaux tests peuvent être conçus pour tester les éléments manquants et ainsi augmenter la couverture. Les techniques de couverture sont traitées dans le chapitre 4.
A tous les niveaux de tests, mais spécialement dans les tests de composants et les tests d‟intégration de composants, des outils peuvent être utilisés pour mesurer la couverture du code des éléments, telle que les instructions ou les décisions. Les tests structurels peuvent être basés sur l‟architecture du système comme par exemple la hiérarchie d‟appels.
Les approches de tests structurels peuvent être aussi appliquées au niveau système, à l‟intégration système ou aux niveaux de tests d‟acceptation (p.ex. pour les processus métier ou les structures de menus).

2.3.4 Tests liés au changement (tests de confirmation et de régression) (K2)
Quand un défaut est détecté et corrigé, le logiciel devrait être re-testé pour confirmer que le défaut original a été correctement ôté. Ceci est appelé test de confirmation. Le débogage (localisation et correction de défaut) est une activité de développement, pas une activité de tests.
Ré-exécuter des tests sur un programme déjà testé s‟appelle « test de régression ». Cela se fait après que des modifications du programme aient eu lieu, pour identifier tout nouveau défaut dû à ce(s) changement(s). Ces défauts peuvent se trouver soit dans le logiciel en cours de tests, soit dans d‟autres composants logiciels liés ou non. Les tests de régression sont exécutés quand le logiciel, ou son environnement, est modifié. Le périmètre des tests de régression est basé sur le risque de ne pas trouver d‟anomalie dans un logiciel fonctionnant auparavant.
Les tests devraient être répétables s‟ils sont utilisés pour des tests de confirmation ou pour les tests de régression.
Les tests de régression peuvent être exécutés à tous les niveaux de tests, et s‟appliquent aux tests fonctionnels, non-fonctionnels et structurels. Les suites de tests de régression sont exécutées plusieurs fois et évoluent généralement lentement. Donc les tests de régression sont de bons candidats à l‟automatisation.

2.4 Tests de maintenance (K2)

Termes
Analyse d‟impact, tests de maintenance
Contexte
Une fois déployé, un système logiciel est souvent en service pendant des années, voire des dizaines d‟années. Pendant ce temps, le système, son paramétrage et son environnement sont fréquemment corrigés, modifiés ou étendus. La planification au plus tôt des livraisons est cruciale pour le succès des tests de maintenance. Une distinction doit être faite entre les livraisons planifiées et les mises à jour à chaud (hot fixes). Les tests de maintenance sont effectués sur un système opérationnel existant et sont déclenchés par des modifications, migrations ou suppression de logiciels ou de systèmes.
Les modifications incluent les changements dûs aux évolutions planifiées (p.ex. livraisons de nouvelles versions), aux modifications correctives et d‟urgence, ainsi qu‟aux changements d‟environnements tels que les montées en version planifiées des systèmes d‟exploitation, des bases de données ou des COTS. Elles incluent également les patchs de correction des vulnérabilités de sécurité potentielles ou découvertes d‟un système d‟exploitation.
Les tests de maintenance lors de migrations (p.ex. d‟une plate-forme à une autre) devraient inclure les tests opérationnels du nouvel environnement tout comme les tests des modifications du logiciel.
Les tests de migration (tests de conversion) sont également nécessaires lorsque les données d‟une autre application seront migrées dans le système à maintenir.
Les tests de maintenance pour la suppression (mise au rebut) d‟un système incluent le test de la migration des données ou leur archivage si de longues périodes de stockage de données sont nécessaires.
En plus des tests des éléments changés, les tests de maintenance incluent des tests de régression sur les parties du système qui n‟ont pas été modifiées. Le périmètre des tests de maintenance est fonction des risques liés aux modifications, à la taille du système existant et à la taille des modifications effectuées. Selon le changement, les tests de maintenance peuvent être effectués à chacun ou à tous les niveaux de tests et pour certains ou tous les types de tests.
Déterminer comment un système existant est affecté par les changements est appelé analyse d‟impact, et est utilisé pour décider de la quantité de tests de régression devant être exécutés.
L‟analyse d‟impacts peut être utilisée pour déterminer les suites de tests de régression.
Les tests de maintenance peuvent être difficiles si les spécifications sont périmées ou manquantes, ou si les testeurs ayant la connaissance fonctionnelle ne sont pas disponibles.