Syllabus CFTL

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.

2.2 Niveaux de tests (K2)

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.

 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.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)