3 - Le-Domaine-Du-Test-Logiciel-Laqualitelogiciel

Le domaine du Testing
Psychologie humaine et test
 Les moyens de bien communiquer comprennent les exemples suivants :

• Commencer par la collaboration plutôt que par la confrontation. Rappeler à tous l'objectifcommun d'une
meilleure qualité des systèmes.
• Mettre l'accent sur les bénéfices du test. Par exemple, pour les auteurs, l'information sur les défauts peut les aider à
améliorer leurs produits d’activités et leurs compétences. Pour l'organisation, les défauts trouvés et corrigés durant les
tests permettront d'économiser du tempset de l'argent et de réduire le risque global pour la qualité du produit.
• Communiquer les résultats des tests et d'autres constats d'une manière neutre et axée sur lesfaits, sans critiquer la
personne qui a créé l’item défectueux. Rédiger des rapports objectifs et factuels sur les défauts et les constats des
revues.
• Essayer de comprendre ce que ressent l'autre personne et les raisons pour lesquelles elle peutréagir négativement à
l'information.
• Confirmer que l'autre personne a compris ce qui a été dit et vice versa.
https://www.qualitelogiciel.com
Activités et taches de test
 Un processus de test se compose des principaux groupes d'activités suivants :

• Planification des tests
• Suivi et contrôle des tests
• Analyse de test
• Conception des tests
• Implémentation des tests
• Exécution des tests
• Clôture des tests
PROCESSUS DE TEST
 Un processus de test se compose des principaux groupes d'activités suivants :
• Planification des tests
• Suivi et contrôle des tests
• Analyse de test
• Conception des tests
• Implémentation des tests
• Exécution des tests
• Clôture des tests
Planification des tests
 La planification des tests implique de définir les objectifs du test et l'approche

retenue pour atteindre les objectifs du test dans le respect des contraintes
imposées par le contexte (p. ex. spécifier les techniques et tâches de test
appropriées, et produire un calendrier de test pour respecter une date limite).
Les plans de test peuvent être revus en fonction des retours sur les activités de
pilotage et de contrôle
Pilotage et contrôle des tests
 Le pilotage des tests implique la comparaison régulière de l’avancement réel par rapport au plan de test àl'aide des métriques de pilotage
définies dans le plan de test.
 Le contrôle des tests consiste à prendre les mesures nécessaires pour satisfaire aux objectifs du plan de test (qui peut être mis à jour au fil
du temps).
 Le pilotage et le contrôle des tests se basent sur l'évaluation des critères de sortie, que l'on appelle « definition of done » (définition de «
terminé ») dans certains cycles de vie

 Par exemple, l'évaluation des critères de sortie pour l'exécution des tests dans le cadre d'un niveau de test donné peut inclure :
• La vérification des résultats et logs des tests de test par rapport aux critères de couverturespécifiés
• L’évaluation du niveau de qualité des composants ou du système sur la base des résultats etlogs des tests
• La détermination de la nécessité d'autres tests (p. ex. si les tests qui visaient à l’atteinte d’un certain niveau de
couverture des risques Produit n’y sont pas parvenu, il est nécessaire que destests supplémentaires soient écrits et
exécutés)
• L’avancement des tests par rapport au plan est communiqué aux parties prenantes dans des rapports d'avancement
des tests, comprenant les écarts par rapport au plan et les informations utiles à toute décision d’arrêter les tests.
Analyse de test
 Pendant l'analyse de test, les bases de test sont analysées pour identifier les caractéristiques testables et définir les conditions de test
associées. En d'autres termes, l'analyse des tests détermine "quoi tester" en termes de critères de couverture mesurables.
 L'analyse de test comprend les principales activités suivantes :
• Analyser les bases de test appropriées au niveau de test considéré, par exemple :
o Les spécifications des exigences, telles que les exigences métier, les exigences fonctionnelles, les exigences
système, les User Stories, les epics, les cas d'utilisation oules produits d’activités similaires qui spécifient le
comportement fonctionnel et non- fonctionnel souhaité pour le composant ou système
o Les informations sur la conception et l’implémentation, comme les diagrammes ou documents d'architecture
du système ou du logiciel, les spécifications de conception, lesflux d'appels, les diagrammes de modélisation
(p. ex., les diagrammes UML ou entité- relation), les spécifications d'interface ou des produits d’activités
similaires qui spécifientla structure du composant ou du système
o L’implémentation du composant ou du système lui-même, y compris le code, lesmétadonnées et les
requêtes sur la base de données, et les interfaces
o Les rapports d'analyse des risques, qui peuvent prendre en compte les aspectsfonctionnels, non-
fonctionnels et structurels du composant ou du système
Analyse de test
• Evaluer les bases de test et des éléments de test pour identifier des défauts de différents types,tels que :
o Ambiguïtés
o Omissions
o Incohérences
o Inexactitudes
o Contradictions
o Déclarations superflues
• Identifier les caractéristiques et les ensembles de caractéristiques à tester
• Définir et prioriser les conditions de test pour chaque caractéristique en fonction de l'analyse desbases de test et en
tenant compte des caractéristiques fonctionnelles, non-fonctionnelles et structurelles, des autres facteurs métier et
techniques, et des niveaux de risque
 Capturer la traçabilité bidirectionnelle entre chaque élément des bases de test et les conditionsde test associées
 L’application de techniques de test boîte-noire, boîte-blanche et basées sur l'expérience peut s'avérer utile dans le processus d'analyse de test
pour réduire la probabilité d'omettre des conditions de test importantes, et pour définir des conditions de test plus exactes et plus précises.
Analyse de test
 L'identification de défauts au cours de l'analyse de test est un bénéfice potentiel important, en particulier lorsqu'il n'y a pas d'autre processus de
revue utilisé et/ou si le processus de test est étroitement lié au processus de revue. De telles activités d'analyse de test ne se contentent pas de
vérifier si les exigences sont cohérentes, correctement exprimées, et complètes, mais aussi de valider si les exigences capturent correctement
les besoins des clients, utilisateurs et des autres parties prenantes. Par exemple, les techniques telles que le BDD (Behavior-Driven
Developement) et ATDD (Acceptance Test-Driven Development), qui impliquent la définition des conditions de test et de cas de test à partir des
User Story et des critères d'acceptation avant le codage, permettent aussi de vérifier, valider et détecter des défauts dans les User Stories et les
critères d'acceptation
Conception des tests
Lors de la conception des tests, les conditions de test sont déclinées en cas de test de haut niveau, en ensembles de cas de tests de haut niveau et
autres testware. Ainsi, l'analyse de test répond à la question
 « quoi tester ? » alors que la conception des tests répond à la question « comment tester ? ».La conception des tests comprend les
activités principales suivantes :
• Concevoir et prioriser les cas de test et les ensembles de cas de test

• Identifier les données de test nécessaires pour les conditions de test et les cas de test
• Concevoir l'environnement de test et identifier l'infrastructure et les outils nécessaires
• Etablir la traçabilité bidirectionnelle entre les bases de test, les conditions de test, les cas de testet les procédures de
test
Implémentation des tests
 Au cours de l'implémentation des tests, le testware nécessaire à l'exécution des tests est créé et/ou complété, y compris l'ordonnancement
des cas de test en procédures de test. Ainsi, la conception destests répond à la question « comment tester ? » tandis que l'implémentation des
tests répond à la question « est-ce que tout est en place pour exécuter les tests ? ».
 L'implémentation des tests comprend les activités principales suivantes :
• Développer et prioriser les procédures de test, et, éventuellement, créer des scripts de test automatisés
• Créer des suites de tests à partir des procédures de test et (le cas échéant) des scripts de test automatisés
• Positionner les suites de tests dans un calendrier d'exécution des tests de manière à obtenir uneexécution efficace
des tests
• Construire l'environnement de test (y compris, potentiellement, les harnais de test, la virtualisation des services, les
simulateurs et d'autres éléments d'infrastructure) et vérifier quetout le nécessaire a été correctement mis en place
• Préparer les données de test et s'assurer qu'elles sont correctement chargées dansl'environnement de
test
• Vérifier et mettre à jour la traçabilité bidirectionnelle entre les bases de test, les conditions detest, les cas de test,
les procédures de test et les suites de tests
 Les tâches de conception et d'implémentation des tests sont souvent combinées.
Implémentation des tests
Dans le cas des tests exploratoires et d'autres types de tests basés sur
l'expérience, la conception et l’implémentation des tests peuvent être réalisées et
éventuellement être documentées lors de l'exécutiondes tests. Les tests
exploratoires peuvent être basés sur des chartes de test (produites dans le cadre
de l'analyse de test), et les tests exploratoires sont exécutés immédiatement, en
même temps que leur conception et leur implémentation
Exécution des tests
 Pendant l'exécution des tests, les suites de tests sont exécutées conformément au calendrier d'exécutiondes tests.
 L'exécution des tests comprend les activités principales suivantes :
• Enregistrer les IDs et les versions des éléments de test ou de l'objet de test, des outils de test etdes testware
• Exécuter les tests manuellement ou à l'aide d'outils d'exécution de test
• Comparer les résultats obtenus avec les résultats attendus
• Analyser les anomalies afin d'établir leurs causes probables (p. ex., des défaillances peuvent survenir en raison de
défauts dans le code, mais de faux positifs peuvent également se produire
• Signaler les défauts sur la base des défaillances observées
• Enregistrer les résultats de l'exécution des tests (par exemple, réussite, échec, blocage)
• Répéter certaines activités de test, soit à la suite d'une action prise pour une anomalie, soit dans le cadre de l'activité
planifiée de test (p. ex. exécution d'un test corrigé, test de confirmation, et/outest de régression)
• Vérifier et mettre à jour la traçabilité bidirectionnelle entre les bases de test, les conditions detest, les cas de test,
les procédures de test et les résultats des tests
Clôture des tests
 Les activités de clôture des tests collectent les données des activités de test terminées afin de consoliderl'expérience, les testware et toute
autre information pertinente. Les activités de clôture des tests ont lieu àdes jalons du projet, par exemple lorsqu'un système logiciel est livré,
qu'un projet de test est terminé (ou annulé), qu'une itération de projet Agile est terminée (par exemple, dans le cadre d'une réunion rétrospective),
qu'un niveau de test est terminé ou qu'une maintenance de version est terminée.
 La clôture des tests comprend les activités principales suivantes :
• Vérifier si tous les rapports de défauts sont clôturés, et saisir des demandes de modification ou des items du backlog
du produit pour tous les défauts non résolus à la fin de l'exécution des tests
• Créer un rapport de synthèse de test à communiquer aux parties prenantes
• Finaliser et archiver l’environnement de test, les données de test, l'infrastructure de test et autrestestware pour une
réutilisation ultérieure
• Remettre le testware aux équipes de maintenance, aux autres équipes de projet, et/ou à d'autresparties prenantes qui
pourraient bénéficier de son utilisation
• Analyser les leçons apprises des activités de test terminées afin de déterminer les changementsnécessaires pour les
itérations, versions et projets futurs
• Utiliser l'information recueillie pour améliorer la maturité du processus de test
Niveaux de test
 Les niveaux de test sont des groupes d'activités de test qui sont organisées et gérées ensemble. Chaque niveau de test est une instance du
processus de test, constitué des activités réalisées en relation avec le logiciel à un niveau de développement donné, depuis les unités ou
composants individuels jusqu'aux systèmes complets ou, le cas échéant, aux systèmes de systèmes.
 Les niveaux de test sont liés à d'autres activités du cycle de vie du développement logiciel. Les niveaux de test sont les suivants :
• Test de composants
• Test d’intégration
• Test système
• Test d’acceptation
 Les niveaux de test sont caractérisés par les éléments suivants :
• Objectifs spécifiques
• Bases de test, référencées pour en dériver des cas de test
• Objet de test (c.-à-d. ce qui est testé)
• Défauts et défaillances types
• Approches et responsabilités spécifiques
 Pour chaque niveau de test, un environnement de test approprié est requis. Dans les tests d'acceptation, par exemple, un environnement de
test représentatif de la production est idéal, tandis que dans les tests de composants, les développeurs utilisent généralement leur propre
environnement de développement.
Test de composants
 Objectifs des tests de composants

 Les tests de composants (également connus sous le nom de tests unitaires ou de modules) se concentrent sur des composants qui
peuvent être testés séparément. Les objectifs des tests decomposants sont les suivants :
• Réduire le risque
• Vérifier si les comportements fonctionnels et non-fonctionnels du composant sont tels qu'ils ontété conçus et
spécifiés
• Renforcer la confiance dans la qualité du composant
• Trouver des défauts dans le composant
• Empêcher les défauts de passer à des niveaux de test plus élevés
 Dans certains cas, particulièrement dans les modèles de développement incrémentaux et itératifs (p. ex.Agile) où les changements de code
sont continus, les tests de régression automatisés jouent un rôle clédans l'établissement de la confiance que les changements n'ont pas
endommagés les composants existants.
 Les tests de composants sont souvent effectués indépendamment du reste du système, en fonction du modèle de cycle de développement
logiciel et du système, ce qui peut nécessiter de mettre en place desobjets fictifs, une virtualisation des services, des harnais de test, des
bouchons et des pilotes. Les tests de composants peuvent porter sur des caractéristiques fonctionnelles (p. ex., exactitude des calculs), non-
fonctionnelles (p. ex. recherche de fuites mémoire) et les propriétés structurelles (p. ex., tests des décisions).
Test de composants
 Bases de test
 Voici des exemples de produits d’activités qui peuvent être utilisés comme bases de test pour les tests decomposants :
• Conception détaillée
• Code
• Modèle de données
• Spécifications des composants
 Objets de test
 Les objets de test habituels pour les tests de composants sont les suivants :
• Composants, unités ou modules
• Code et structures de données
• Classes


• Modules de bases de données
 Défauts et défaillances courants
 Voici des exemples de défauts et de défaillances courants pour les tests de composants :
• Fonctionnalité incorrecte (par exemple, non conforme aux spécifications de conception)
• Problèmes de flux de données
• Code et logique incorrects
 Les défauts sont généralement corrigés dès qu'ils sont détectés, souvent sans gestion formelle desdéfauts. Cependant, lorsque les développeurs
rapportent vraiment des défauts, cela donne des informations importantes pour l'analyse des causes racines et l'amélioration des processus.
Test d'intégration
Objectifs des tests d'intégration
 Les tests d'intégration se concentrent sur les interactions entre les composants ou les systèmes. Lesobjectifs des tests d'intégration
comprennent :
• Réduire les risques
• Vérifier si les comportements fonctionnels et non-fonctionnels des interfaces sont tels qu'ils ontété conçus et
spécifiés
• Renforcer la confiance dans la qualité des interfaces
• Trouver des défauts (qui peuvent se trouver dans les interfaces elles-mêmes ou dans lescomposants ou
systèmes)
• Empêcher les défauts de passer à des niveaux de test plus élevés
 Comme pour les tests de composants, dans certains cas, les tests d'intégration automatisés utilisés en tests de régression
donnent l'assurance que les changements n'ont pas altéré les interfaces, composantsou systèmes existants
Test d'intégration
 Il y a deux niveaux différents de tests d'intégration, qui peuvent être effectués sur
 des objets de test de taille variable comme suit :

• Les tests d'intégration de composants se concentrent sur les interactions et les interfaces entre composants intégrés.
Les tests d'intégration de composants sont effectués après les tests de composants et sont généralement automatisés.
Dans le développement itératif et incrémental, lestests d'intégration des composants font généralement partie du
processus d'intégration continue.
• Les tests d'intégration de systèmes se concentrent sur les interactions et les interfaces entre systèmes, progiciels et
micro-services. Les tests d'intégration de systèmes peuvent également couvrir les interactions avec des entités
externes (p. ex. services Web) et les interfaces fournies par celles-ci. Dans ce cas, l'organisation qui développe ne
contrôle pas les interfaces externes, ce qui peut créer divers problèmes pour les tests (p. ex. s'assurer que des
défauts bloquants pour les tests dans le code de l'entité externe sont résolus, organiser des environnements de test,
etc.). Les tests d'intégration de systèmes peuvent être effectués après les tests systèmes ou en parallèle d’activités de
tests systèmes en cours (à la fois en développement séquentiel et en développement itératif et incrémental).
Test d'intégration
 Bases de test
 Voici des exemples de produits d’activités qui peuvent servir de bases de test pour les tests d'intégration :
• Conception du logiciel et du système
• Diagrammes de séquence
• Spécifications des protocoles d'interface et de communication
• Cas d’utilisation
• Architecture au niveau du composant ou du système
• Workflows
• Définitions des interfaces externes
 Objets de test
 Les objets de test habituels pour les tests d'intégration comprennent :
• Sous-systèmes
• Bases de données
• Infrastructure
• Interfaces
• APIs
• Micro-services
Test d'intégration
 Voici des exemples de défauts et de défaillances habituels pour les tests d'intégration de composants :
• Données incorrectes, données manquantes ou encodage incorrect des données
• Mauvais séquencement ou synchronisation des appels d'interfaces
• Décalages au niveau des interfaces
• Défaillances dans la communication entre les composants

• Défaillances de communication non gérées ou mal gérées entre les composants
• Hypothèses incorrectes sur la signification, les unités ou les limites des données transmises entreles composants
 Voici des exemples de défauts et de défaillances habituels pour les tests d'intégration de systèmes :
• Structures de message incohérentes entre les systèmes
• Données incorrectes, données manquantes ou encodage incorrect des données
• Décalages au niveau des interfaces
• Défaillances dans la communication entre les systèmes
• Défaillances de communication non gérées ou mal gérées entre les systèmes
• Hypothèses incorrectes sur la signification, les unités ou les limites des données transmises entreles systèmes
• Non-respect des règles de sécurité requises
Test système
 Objectifs des tests système
 Les tests système se concentrent sur le comportement et les capacités d'un système ou d'un produit entier, en considérant souvent les
tâches de bout en bout que le système peut exécuter et les comportements non-fonctionnels qu'il présente pendant l'exécution de ces tâches.
Les objectifs des testssystème comprennent :
• Réduire les risques
• Vérifier si les comportements fonctionnels et non-fonctionnels du système sont tels qu'ils ont étéconçus et spécifiés
• Valider que le système est complet et fonctionnera comme prévu
• Renforcer la confiance dans la qualité du système dans son ensemble
• Trouver des défauts
• Empêcher les défauts de passer à des niveaux de test plus élevés ou en production
 Pour certains systèmes, la vérification de la qualité des données peut être un objectif. Comme pour les tests de composants et les tests
d'intégration, dans certains cas, les tests de régression automatisés au niveau système donnent l'assurance que les changements n'ont pas
altéré les caractéristiques existantesou les capacités de bout en bout. Le test système produit souvent de l'information qui est utilisée par les
intervenants pour prendre des décisions de livraison. Les tests systèmes peuvent également satisfaire aux exigences ou aux normes légales ou
réglementaires.
 L'environnement de test devrait idéalement correspondre à la cible finale ou à

l'environnement de production.
Test système
 Bases de test
 Voici des exemples de produits d’activités qui peuvent être utilisés comme bases de test pour les testssystème :
• Spécifications des exigences système et logicielles (fonctionnelles et non-fonctionnelles)
• Rapports d'analyse des risques
• Cas d’utilisation
• Epics et User Stories
• Modèles de comportement du système
• Diagrammes d’états
• Manuels système et manuels d'utilisation
 Objets de test
 Les objets de test habituels pour les tests système comprennent :
• Applications
• Systèmes Matériel/Logiciel
• Systèmes d’exploitation

• Système sous test (SUT – System Under Test)
• Configuration du système et données de configuration
Test système

 Voici des exemples de défauts et de défaillances habituels pour les tests système :
• Calculs incorrects
• Comportement fonctionnel ou non-fonctionnel du système incorrect ou inattendu
• Flux de contrôle et/ou de données incorrects au sein du système
• Réalisation incorrecte et incomplète des tâches fonctionnelles de bout en bout
• Incapacité du système à fonctionner correctement dans le ou les environnements de production
• Incapacité du système à fonctionner selon la description faite dans les manuels système etutilisateur
Risques produit
 Le risque produit implique la possibilité qu'un produit d’activités (par exemple, une spécification, un composant, un système ou un test) puisse
ne pas satisfaire les besoins de ses utilisateurs et/ou partiesprenantes. Lorsque les risques produit sont associés à des caractéristiques de
qualité spécifiques d'unproduit (p. ex. adéquation fonctionnelle, fiabilité, performance, utilisabilité, sécurité, compatibilité, maintenabilité et
portabilité), les risques produit sont également appelés risques qualité. Voici des exemples de risques produit :
• Le logiciel peut ne pas remplir les fonctions attendues selon la spécification
• Le logiciel peut ne pas remplir les fonctions attendues selon les besoins de l'utilisateur, du clientet/ou des parties
prenantes
• Une architecture système peut ne pas répondre de manière adéquate à certaines exigences non-fonctionnelles
• Un traitement particulier peut être effectué de manière incorrecte dans certaines circonstances
• Une structure de contrôle de boucle peut être mal codée
• Les délais de réponse peuvent être insatisfaisants pour un système de traitement destransactions à haut
niveau de performance
• L'expérience utilisateur (UX - User eXperience) pourrait ne pas satisfaire les attentes pour leproduit
Risques projet
 Le risque projet implique des situations qui, si elles se produisent, peuvent avoir un effet négatif sur lacapacité d'un
projet à atteindre ses objectifs. Voici des exemples de risques projet :
 Problèmes liés au projet :
 Des retards peuvent se produire dans la livraison, l'achèvement des tâches ou la satisfaction des critères de sortie ou
de la définition du terminé
 Des estimations erronées, la réaffectation de ressources à des projets plus prioritaires ou une réduction générale des
coûts dans l'ensemble de l'organisation peuvent entraîner un financement inadéquat
 Des changements tardifs peuvent entraîner un travail supplémentaire important
 Problèmes organisationnels :
 Les compétences, la formation et le nombre de personnes peuvent ne pas être suffisants
 Les problèmes personnels peuvent causer des conflits et des problèmes
 Les utilisateurs, les personnes du métier ou les experts du domaine peuvent ne pas être disponibles en raison de
priorités contradictoires
 Problèmes liés aux fournisseurs :
 Un tiers peut ne pas livrer un produit ou un service nécessaire, ou faire faillite
 Des problèmes contractuels peuvent causer des difficultés au projet
 Les risques Projet peuvent affecter à la fois les activités de développement et les activités de test. Dans certains cas,
les chefs de projet sont responsables de la gestion de tous les risques du projet, mais il n'est pas inhabituel que les Test
Managers soient responsables des risques projet en lien avec les tests.
Gestion des défauts
 Un rapport de défaut rempli pendant les tests dynamiques comprend généralement les éléments suivants :
• Un identifiant
• Un titre et un bref résumé du défaut signalé
• La date du rapport de défaut, l'organisation émettrice et l'auteur
• L'identification de l'élément de test (élément de configuration testé) et de l'environnement
• La ou les phases du cycle de développement au cours desquelles le défaut a été observé
• Une description du défaut pour permettre la reproduction et la résolution, y compris des logs, descaptures de base de
données, des captures d'écran ou des enregistrements (si trouvés pendant l'exécution des tests)
• Les résultats attendus et obtenus
• La portée ou le degré d'impact (sévérité) du défaut pour les parties prenantes concernées
• Urgence/priorité de la correction
• L'état du rapport de défaut (p. ex. ouvert, différé, en double, en attente de correction, en attentede test de
confirmation, ré-ouvert, fermé)
• Les conclusions, recommandations et approbations
• Les enjeux généraux, tels que les autres domaines qui peuvent être affectés par un changementrésultant du défaut
• L'historique des modifications, notamment la séquence des mesures prises par les membres del'équipe de projet
quant au défaut pour isoler, réparer et confirmer qu'il est corrigé
• Les références, y compris le cas de test qui a révélé le problème
Tester pendant le cycle de vie du développement
logiciel
Critères d'entrée et de sortie (Définition du
prêt et définition du terminé)
 Afin d'exercer un contrôle efficace sur la qualité du logiciel et des tests, il est conseillé d'avoir des critèresqui définissent quand une activité de
test donnée doit commencer et quand l'activité est terminée. Les critères d'entrée (plus typiquement appelés définition du prêt dans le
développement Agile) définissent les préconditions pour entreprendre une activité de test donnée. Si les critères d'entrée ne sont pas satisfaits, il
est probable que l'activité s'avérera plus difficile, plus longue, plus coûteuse et plus risquée. Les critères de sortie (plus typiquement appelés
définition du terminé dans le développement Agile) définissent les conditions à remplir pour pouvoir déclarer un niveau de test ou un ensemble
de tests terminés. Les critères d'entrée et de sortie devraient être définis pour chaque niveau et type de test, et différeront en fonction des
objectifs de test.
 Les critères d'entrée habituels incluent :
• Disponibilité d'exigences testables, de User Stories et/ou de modèles (par exemple, lorsque l’on suit une stratégie de
test basée sur les modèles)
• Disponibilité d'éléments de test qui ont satisfait aux critères de sortie pour tous les niveaux detest précédents
• Disponibilité de l'environnement de test
• Disponibilité des outils de test nécessaires
 Disponibilité des données de test et autres ressources nécessaires
Critères d'entrée et de sortie (Définition du prêt et définition du terminé)
Les critères de sortie habituels incluent :

• Les tests planifiés ont été exécutés
• Un niveau défini de couverture (par exemple, des exigences, des User Stories, des critèresd'acceptation, des
risques, du code) a été atteint
• Le nombre de défauts non résolus est limité à ce qui a été défini
• Le nombre estimé de défauts restants est suffisamment faible
• Les niveaux évalués de fiabilité, de performance, d'utilisabilité, de sécurité et autrescaractéristiques
qualité pertinentes sont suffisants
 Même si les critères de sortie ne sont pas satisfaits, il est également courant que les activités de test soient réduites en raison du budget
dépensé, du temps prévu et/ou de la pression pour mettre le produit sur le marché. Il peut être acceptable de mettre fin aux tests dans de telles
circonstances, si les parties prenantes du projet et les responsables métier ont revu et accepté le risque de mettre en production sansautres
tests.
Tests exploratoires
Tests exploratoires
Tests basés sur des checklists
Techniques de test basées sur
l'expérience
Techniques de test basées sur
l'expérience
Estimation d’erreur
Test de confirmation et TNR ?
Types de test
Types de test
 Un type de test est un groupe d'activités de test visant à tester des caractéristiques spécifiques d'un système logiciel ou d'une partie d'un système, sur la base
d'objectifs de test spécifiques. Ces objectifspeuvent inclure :
• Évaluer des caractéristiques de qualité fonctionnelle, telles que la complétude, l'exactitude et lapertinence
• Évaluer des caractéristiques de qualité non-fonctionnelles, telles que la fiabilité, la performance,la sécurité, la compatibilité et la facilité
d'utilisation
• Évaluer si la structure ou l'architecture du composant ou du système est correcte, complète etconforme aux spécifications
• Évaluer les effets des changements, tels que la confirmation de la correction de défauts (tests deconfirmation) et la recherche de changements
non désirés résultant de changements dans le logiciel ou l'environnement (tests de régression)
Tests fonctionnels
 Les tests fonctionnels d'un système impliquent des tests qui évaluent les fonctionnalités que le système devrait réaliser. Les exigences fonctionnelles peuvent être
décrites dans des produits d’activités tels que les spécifications des exigences métier, les épics, les User Stories, les cas d'utilisation ou les spécifications fonctionnelles, ou
elles peuvent ne pas être documentées. Les fonctionnalités sont "ce que"le système doit faire.
 Les tests fonctionnels devraient être effectués à tous les niveaux de test (par exemple, les tests de composants peuvent être basés sur une spécification de
composant), bien que la focalisation soit différente à chaque niveau
 Les tests fonctionnels prennent en compte le comportement du logiciel, de sorte que des techniques boîte-noire peuvent être utilisées pour dériver des conditions
de test et des cas de test pour la fonctionnalité du composant ou du système
 La complétude des tests fonctionnels peut être mesurée par la couverture fonctionnelle. La couverture fonctionnelle est la mesure selon laquelle un certain type
d'élément fonctionnel a été exercé par des tests. Elle est exprimée en pourcentage du ou des types d'éléments couverts. Par exemple, en utilisant latraçabilité entre les tests
et les exigences fonctionnelles, le pourcentage de ces exigences qui sont couvertes par les tests peut être calculé, identifiant potentiellement des lacunes de couverture.
 La conception et l'exécution des tests fonctionnels peuvent nécessiter des compétences ou des connaissances particulières, com me la connaissance du problème métier
particulier que le logiciel résout(par exemple, un logiciel de modélisation géologique pour les industries pétrolière et gazière) ou le rôle particulier que joue le logiciel (par
exemple, un logiciel de jeux vidéo qui fournit des loisirs interactifs).
Tests non-fonctionnels
 Les tests non-fonctionnels d'un système évaluent les caractéristiques des systèmes et des logiciels comme l’utilisabilité, la performance ou la sécurité. Il convient de
se reporter à la norme ISO (ISO/CEI25010) pour une classification des caractéristiques de qualité des produits logiciels. Le test non- fonctionnel est le test de "comment"
le système se comporte.
 Contrairement aux idées fausses courantes, les tests non-fonctionnels peuvent et devraient souvent être
effectués à tous les niveaux de test, et ce, le plus tôt possible. La découverte tardive de défauts non- fonctionnels
peut être extrêmement préjudiciable à la réussite d'un projet.

 Des techniques de boîte-noire peuvent être utilisées pour dériver des conditions de testet des cas de test pour les tests non-fonctionnels. Par exemple, l'analyse des
valeurs limites peut être utilisée pour définir les conditions de sollicitation pour les tests de performance.
 La complétude des tests non-fonctionnels peut être mesurée par une couverture non-fonctionnelle. La couverture non-fonctionnelle est la mesure selon laquelle un
certain type d'élément non-fonctionnel a étéexercé par des tests et est exprimée en pourcentage du ou des types d'éléments couverts. Par exemple, en utilisant la traçabilité
entre les tests et les appareils pris en charge pour une application mobile, le pourcentage d’appareils qui font l'objet de tests de compatibilité peut être calculé, identifiant
potentiellement les lacunes de couverture.
 La conception et l'exécution de tests non-fonctionnels peuvent impliquer des compétences ou des connaissances spécifiques, telles que la connaissance des faiblesses
inhérentes à une conception ou à une technologie (par exemple, les vulnérabilités de sécurité associées à des langages de programmationparticuliers) ou la spécificité des
utilisateurs (p. ex. les types d’utilisateurs des systèmes de gestion des établissements de santé).
Tests boîte-blanche
 Les tests boîte-blanche sont des tests basés sur la structure ou l'implémentation interne du système. La structure interne peut comprendre le code, l'architecture, les
flux de travail et/ou les flux de données au sein du système
Exemple
Un testeur, généralement un développeur également,
étudie le code d'implémentation d'un certain champ sur
une page Web, détermine toutes les entrées légales (valides
et invalides) ET illégales et vérifie les sorties par rapport aux
résultats attendus, qui sont également déterminés en
étudiant le code d'implémentation. .
Le test en boîte blanche est comme le travail d'un
mécanicien qui examine le moteur pour voir pourquoi la
voiture ne bouge pas.
Tests liés aux changements
 Lorsque des modifications sont apportées à un système, que ce soit pour corriger un défaut ou en raison d'une fonctionnalité nouvelle ou modifiée, des tests devraient
être effectués pour confirmer que les
 modifications ont corrigé le défaut ou implémenté la fonctionnalité correctement, et n'ont pas causé deconséquences préjudiciables inattendues.
• Test de confirmation : Après la correction d'un défaut, le logiciel peut être testé avec tous les cas de test qui ont échoué en raison du défaut, qui
doivent être ré-exécutés sur la nouvelle version dulogiciel. Le logiciel peut également être testé avec de nouveaux tests si, par exemple, le défaut
était une fonctionnalité manquante. A minima, les étapes pour reproduire le(s) défaut(s) causé(s)par le défaut doivent être ré-exécutées sur la
nouvelle version du logiciel. Le but d'un test de confirmation est de confirmer que le défaut d'origine a été réparé avec succès.
• Tests de régression : Il est possible qu'une modification apportée à une partie du code, qu'ils'agisse d'une correction ou d'un autre type de
modification, puisse accidentellement affecter lecomportement d'autres parties du code, que ce soit au sein du même composant, dans d'autres
composants du même système ou même dans d'autres systèmes. Les changements peuvent inclure des changements de l'environnement,
comme une nouvelle version d'un système d'exploitation ou d'un système de gestion de base de données. De tels effets de bord involontaires
sont appelés régressions. Les tests de régression sont des tests visant à détecterde tels effets de bord involontaires.
 Des tests de confirmation et de régression sont effectués à tous les niveaux de test.
Types de test et niveaux de test
 Il est possible d'effectuer n'importe quel type de test mentionné ci-dessus à n'importe quel niveau de test.Pour illustrer, des exemples de tests fonctionnels, non-
fonctionnels, boîte blanche et liés au changement seront donnés pour tous les niveaux de test, pour une application bancaire, en commençant par des testsfonctionnels :
• Pour les tests de composants, les tests sont conçus en fonction de la façon dont un composantdoit calculer les intérêts composés.
• Pour les tests d'intégration de composants, les tests sont conçus en fonction de la façon dont lesinformations saisies au niveau de l'interface
utilisateur sont transmises à la couche métier.
• Pour les tests système, les tests sont conçus en fonction de la façon dont les titulaires decomptes peuvent demander une ligne de crédit
sur leurs comptes chèques.
• Pour les tests d'intégration au niveau système, les tests sont conçus en fonction de la façon dontle système utilise un micro-service externe pour
vérifier le taux de crédit d'un titulaire de compte.
• Pour les tests d'acceptation, les tests sont conçus en fonction de la façon dont le banquier gèrel'approbation ou le refus d'une demande de
crédit.
Types de test et niveaux de test
 Voici des exemples de tests non-fonctionnels :
• Pour les tests de composants, les tests de performance sont conçus pour évaluer le nombrede cycles CPU nécessaires pour effectuer un
calcul d'intérêt total complexe.
• Pour les tests d'intégration de composants, les tests de sécurité sont conçus pour les vulnérabilités de débordement de la mémoire
tampon dues aux données transmises del'interface utilisateur à la couche métier.
• Pour les tests système, les tests de portabilité sont conçus pour vérifier si la couche deprésentation fonctionne sur tous les navigateurs
et appareils mobiles supportés.
• Pour les tests d'intégration de système, les tests de fiabilité sont conçus pour évaluer la robustesse du système lorsque le micro-service de
calcul du taux de crédit ne répond pas.
• Pour les tests d'acceptation, les tests d'utilisabilité sont conçus pour évaluer l'accessibilité del'interface de traitement du crédit du banquier
pour les personnes handicapées.
 Voici des exemples de tests boîte-blanche :
• Pour les tests de composants, les tests sont conçus pour obtenir une couverture complète des
instructions et des décisions (voir section 4.3) pour tous les composants qui effectuent des calculs financiers.
• Pour les tests d'intégration de composants, les tests sont conçus pour vérifier comment chaque
écran de l'interface du navigateur transmet les données à l'écran suivant et à la couche métier.
• Pour les tests système, les tests sont conçus pour couvrir les séquences de pages Web qui
peuvent se succéder pendant une demande de ligne de crédit.
• Pour les tests d'intégration de système, les tests sont conçus pour exercer tous les types de
requête possibles envoyés au micro-service de calcul du taux de crédit.
 Pour les tests d'acceptation, les tests sont conçus pour couvrir toutes les structures de fichiers de
données financières prises en charge et les plages de valeurs pour les transferts de banque à banque
 Enfin, voici des exemples de tests liés aux changements :
• Pour les tests de composants, des tests de régression automatisés sont construits pour chaquecomposant et inclus dans le framework
d’intégration continue.
• Pour les tests d'intégration de composants, les tests sont conçus pour confirmer les correctionsdes défauts liés à l'interface au fur et à mesure
que ces corrections sont intégrées dans le référentiel de code.
• Pour les tests système, tous les tests d'un workflow donné sont ré-exécutés si un écran de ceworkflow change.
• Pour les tests d'intégration système, les tests de l'application interagissant avec le micro-servicede calcul du taux de crédit sont ré-exécutés
quotidiennement dans le cadre du déploiement continu de ce micro-service.
• Pour les tests d'acceptation, tous les tests échoués précédemment sont ré-exécutés après lacorrection d'un défaut constaté lors des tests
d'acceptation.
Tests de maintenance
 Une fois déployés dans les environnements de production, les logiciels et les systèmes doivent être maintenus. Des changements de diverses sortes sont presque
inévitables dans les logiciels et les systèmes livrés, soit pour corriger des défauts découverts lors de l'utilisation opérationnelle, soit pour ajouter de nouvelles fonctionnalités,
soit pour supprimer ou modifier des fonctionnalités déjà livrées. La maintenance est également nécessaire pour préserver ou améliorer les caractéristiques de qualité non-
fonctionnelles du composant ou du système pendant toute sa durée de vie, en particulier la performance, la compatibilité, la fiabilité, la sécurité et la portabilité.
 Lorsque des modifications sont apportées dans le cadre de la maintenance, des tests de maintenance devraient être effectués, à la fois pour évaluer le succès avec
lequel les modifications ont été apportéeset pour vérifier les effets secondaires possibles (p. ex. régressions) dans les parties du système qui demeurent inchangées (ce
qui est habituellement la plus grande partie du système). Les tests de maintenance se concentrent sur le test des changements apportés au système, ainsi que sur le test
desparties inchangées qui auraient pu être affectées par les changements. La maintenance peut impliquer des versions planifiées et des versions non planifiées
(corrections à chaud).
 Une version de maintenance peut nécessiter des tests de maintenance à plusieurs niveaux de test, en utilisant différents types de test, en fonction de sa portée.
L'étendue des tests de maintenance dépenddes éléments suivants :
• Le degré de risque du changement, par exemple, la mesure dans laquelle le périmètre modifié dulogiciel communique avec d'autres composants
ou systèmes
• La taille du système existant
• La taille du changement
Tests de maintenance
 Il y a plusieurs raisons pour lesquelles la maintenance logicielle, et donc les tests de maintenance, ontlieu, à la fois pour les changements planifiés et non planifiés.
 Nous pouvons classer les facteurs déclencheurs de la maintenance comme suit :
• Modification, comme des améliorations planifiées (p. ex., basées sur les versions), deschangements correctifs et d'urgence, des changements de
l'environnement opérationnel (commedes mises à niveau planifiées du système d'exploitation ou de la base de données), des mises à niveau de
logiciels sur étagère (COTS) et des correctifs pour les défauts et les vulnérabilités
• Migration, par exemple d'une plate-forme à une autre, qui peut nécessiter des tests opérationnelsdu nouvel environnement ainsi que du logiciel
modifié, ou des tests de conversion de données lorsque les données d'une autre application seront migrées dans le système en cours de
maintenance
• Déclassement, par exemple lorsqu'une application arrive en fin de vie
Analyse d'impact pour la maintenance
 L'analyse d'impact évalue les changements qui ont été apportés pour une version de maintenance afind'identifier les conséquences prévues ainsi que des effets
secondaires attendus et possibles d'un changement, et d'identifier les zones du système qui seront affectées par le changement. L'analyse d'impact peut également aider à
identifier l'impact d'un changement sur les tests existants. Les effets secondaires et les zones affectées dans le système doivent être testés pour les régressions,
éventuellement après la mise à jour des tests existants affectés par le changement.
 L'analyse d'impact peut être effectuée avant qu'un changement ne soit apporté, pour aider à déterminer si le changement devrait être apporté en fonction des
conséquences potentielles dans d'autres parties dusystème.
 L'analyse d'impact peut être difficile si :
• Les spécifications (p. ex., exigences métier, User Stories, architecture) sont obsolètes oumanquantes
• Les cas de test ne sont pas documentés ou sont obsolètes
• La traçabilité bidirectionnelle entre les tests et les bases de test n'a pas été maintenue
• Le support de l'outillage est faible ou inexistant
• Les personnes impliquées n'ont pas de connaissance du domaine et/ou du système
• Une attention insuffisante a été accordée à la maintenabilité du logiciel au cours dudéveloppement
Les tests statiques
 Contrairement aux tests dynamiques, qui nécessitent l'exécution du logiciel testé, les tests
statiques reposent sur l'examen manuel des produits d’activités (c.-à-d. les revues) ou sur une
évaluation outilléedu code ou d'autres produits d’activités (c.-à-d. l'analyse statique). Les deux
types de tests statiques évaluent le code ou tout autre produit d’activités testé sans exécuter
réellement le code ou le produit d’activités testé.
 L'analyse statique est importante pour les systèmes informatiques critiques pour la sûreté (p.
ex. logicielsaéronautiques, médicaux ou nucléaires), mais l'analyse statique est également
devenue importante et courante dans d'autres contextes. Par exemple, l'analyse statique est
une partie importante des tests de sécurité. L'analyse statique est aussi souvent incorporée
dans les systèmes automatisés de build et de livraison, par exemple dans le développement
Agile, en livraison en continu et en déploiement continu.
Produits d’activités qui peuvent être
examinés par des tests statiques
 Presque tous les produits d'activités peuvent être examinés à l'aide de tests statiques (revues et/ouanalyses statiques), par exemple :
• Les spécifications, y compris les exigences métier, les exigences fonctionnelles et les exigencesde sécurité
• Les épics, User Stories, et critères d’acceptation
• Les spécifications d'architecture et de conception
• Le code
• Le testware, y compris les plans de test, les cas de test, les procédures de test et les scripts detest automatisés
• Les guides utilisateur
• Les pages Web
• Les contrats, les plans de projet, les calendriers et les budgets
• Les modèles, tels que les diagrammes d'activité, qui peuvent être utilisés pour les tests basés surdes modèles
Produits d’activités qui peuvent être examinés par des tests statiques
 Les revues peuvent être appliquées à n'importe quel produit d'activités que les participants
peuvent lire et comprendre. L'analyse statique peut être appliquée efficacement à tout produit
d'activités ayant une structure formelle (généralement un code ou des modèles) pour lequel il
existe un outil d'analyse statique approprié. L'analyse statique peut même être appliquée avec
des outils qui évaluent les produits d'activités écrits en langage naturel comme les exigences
(par exemple, vérification de l'orthographe, de la grammaire et de la lisibilité).
Bénéfices des tests statiques
 Parmi les avantages des tests statiques, on peut citer les points suivants :
• Détection et correction plus efficace des défauts, avant l'exécution des tests dynamiques
• Identification des défauts qui ne sont pas facilement décelables par des tests dynamiques
• Prévention des défauts de conception ou de codage par la découverte d'incohérences,d'ambiguïtés, de contradictions, d'omissions,
d'inexactitudes et de redondances dans lesexigences
• Augmentation de la productivité du développement (par exemple, grâce à une meilleureconception, à un code plus facile à maintenir)
• Réduction des coûts et des délais de développement
• Réduction des coûts et des délais des tests
• Réduction du coût total de la qualité tout au long de la durée de vie du logiciel, grâce à la réduction du nombre de défaillances plus tard dans le
cycle de vie ou après la mise en service
• Amélioration de la communication entre les membres de l'équipe au cours de la participation auxrevues
Différences entre les tests statiques et
dynamiques
 Les tests statiques et dynamiques peuvent avoir les mêmes objectifs tels que fournir une évaluation de la qualité des produits d'activités et identifier les défauts le plus
tôt possible. Les testsstatiques et dynamiques se complètent mutuellement en trouvant différents types de défauts.
 L'une des principales distinctions est que les tests statiques détectent directement les défauts dans lesproduits d'activités plutôt que d'identifier les défaillances
causées par des défauts lorsque le logiciel estexécuté. Un défaut peut résider dans un produit d'activités pendant très longtemps sans causer une défaillance. Le chemin
où se trouve le défaut peut être rarement exercé ou difficile à atteindre, de sortequ'il ne sera pas facile de construire et d’exécuter un test dynamique qui mette en
évidence ce défaut. Les tests statiques peuvent permettre de trouver le défaut avec beaucoup moins d'efforts.
 Une autre distinction est que les tests statiques peuvent être utilisés pour améliorer la cohérence et la qualité interne des produits d'activités, tandis que les tests
dynamiques se concentrent généralement surles comportements visibles de l'extérieur.
 Par rapport aux tests dynamiques, les défauts qui sont habituellement plus faciles et moins coûteux àtrouver et à corriger grâce aux tests statiques sont les suivants :
• Défauts dans les exigences (p. ex. incohérences, ambiguïtés, contradictions, omissions,inexactitudes et redondances)
• Défauts dans la conception (p. ex. algorithmes ou structures de base de données inefficaces,taux de dépendance élevé, faible cohésion)
• Défauts dans le code (p. ex. variables avec des valeurs non définies, variables déclarées maisjamais utilisées, code inatteignable, code
dupliqué)
• Ecarts par rapport aux normes (p. ex. non-respect des règles de codage)
• Spécifications d'interface incorrectes (p. ex. unités de mesure utilisées par le système appelantdifférentes de celles utilisées par le système
appelé)
• Vulnérabilités de sécurité (p. ex. sensibilité aux débordements de la mémoire tampon)
• Lacunes ou inexactitudes dans la traçabilité ou la couverture des bases de test (p. ex., des testsmanquants pour un critère d'acceptation)
 De plus, la plupart des défauts de maintenabilité ne peuvent être trouvés que par des tests statiques (par exemple, une modularité inadéquate, une
mauvaise réutilisation des composants, un code difficile à analyser et à modifier sans introduire de nouveaux défauts)
Les techniques de test
 L'objectif d'une technique de test, y compris celles présentées dans cette section, est d'aider à identifierles conditions de test, les cas de test et les données de test.

Choix des techniques de test
 Le choix des techniques de test à utiliser dépend d'un certain nombre de facteurs, dont les suivants :
• Type de composant ou de système
• Complexité du composant ou des systèmes
• Normes réglementaires
• Exigences client ou contractuelles
• Niveaux de risque
• Types de risques
• Objectifs du test
• Documentation disponible
• Connaissances et compétences des testeurs
• Outils disponibles
• Temps et budget
• Modèle de cycle de vie du développement logiciel
• Utilisation prévue du logiciel
• Expérience antérieure de l'utilisation des techniques de test sur le composant ou le système àtester
• Types de défauts attendus dans le composant ou le système
 Certaines techniques sont plus applicables à certaines situations et à certains niveaux de test ; d'autres sont applicables à tous les niveaux
de test. Lors de la création de cas de test, les testeurs utilisent généralement une combinaison de techniques de test pour obtenir les meilleurs
résultats de l'effort de test.
 L'utilisation des techniques de test dans les activités d’analyse des tests, de conception des tests et d’implémentation des tests peut varier
de très informel (peu ou pas de documentation) à très formel. Le niveau de formalité approprié dépend du contexte des tests, y compris la
maturité des processus de testet de développement, les contraintes de temps, les exigences de sûreté ou réglementaires, les connaissances
et les compétences des personnes impliquées et le modèle de cycle de vie du développement logiciel suivi.
Catégories de techniques de test et leurs
caractéristiques
 les techniques de test sont classées en techniques boîte-noire, techniques boîte-blanche et techniques basées sur l'expérience.
 Les techniques de test de boîte-noire (aussi appelées techniques comportementales ou techniques basées sur le comportement) sont basées sur une analyse de la
base de test appropriée (par exemple, documents d'exigences formelles, spécifications, cas d'utilisation, User Stories ou processus métier). Cestechniques sont applicables
aux tests fonctionnels et non-fonctionnels. Les techniques de test de boîte- noire se concentrent sur les entrées et sorties de l'objet de test sans référence à sa structure
interne.
 Les techniques de test de boite blanche (aussi appelées techniques structurelles ou techniques basées sur la structure) sont basées sur une analyse de l'architecture,
de la conception détaillée, de la structure interne ou du code de l'objet de test. Contrairement aux techniques de test de boîte-noire, les techniquesde test de boîte-blanche
se concentrent sur la structure et le traitement à l'intérieur de l'objet de test.
 Les techniques de test basées sur l'expérience tirent parti de l'expérience des développeurs, des testeurset des utilisateurs pour concevoir, implémenter et exécuter des
tests. Ces techniques sont souvent combinées à des techniques de test boîte-noire et boite blanche.
Catégories de techniques de test et leurs caractéristiques
 Les caractéristiques communes des techniques de test boîte-noire incluent :

• Les conditions de test, les cas de test et les données de test sont dérivés d'une base de test quipeut inclure des exigences logicielles, des
spécifications, des cas d'utilisation, et des User Stories
• Les cas de test peuvent être utilisés pour détecter les écarts entre les exigences etl'implémentation des exigences, ainsi que les
défauts au niveau des exigences
• La couverture est mesurée en fonction des éléments de la base de test évalués et de latechnique appliquée à cette base de test
 Les caractéristiques communes des techniques de test des boîte-blanche incluent :

• Les conditions de test, les cas de test et les données de test sont dérivés d'une base de test quipeut inclure le code, l'architecture logicielle, la
conception détaillée ou toute autre source d'information concernant la structure du logiciel
• La couverture est mesurée en fonction des éléments testés au sein d'une structure donnée (p.ex. le code ou les interfaces)
• Les spécifications sont souvent utilisées comme source d'information supplémentaire pourdéterminer le résultat attendu des cas de test
 Les caractéristiques communes des techniques de test basées sur l'expérience incluent :
• Les conditions de test, les cas de test et les données de test sont dérivés d'une base de test quipeut inclure les connaissances et l'expérience
des testeurs, développeurs, utilisateurs et autresparties prenantes
Les modèles de développement logiciel
 Un modèle de cycle de vie de développement logiciel décrit les types d'activités réalisées à
chaque étape d'un projet de développement logiciel, et la façon dont les activités sont reliées
entre elles logiquement et chronologiquement. Il existe un certain nombre de modèles de cycle
de développement de logiciels différents, chacun d'entre eux nécessitant des approches de test
différentes.
Développement de logiciel et tests logiciels
 Une partie importante du rôle d'un testeur est de se familiariser avec les principaux modèles de cycle devie du développement logiciel afin que les activités de test
adaptées puissent être réalisées.
 Quel que soit le modèle de cycle de vie de développement logiciel, il y a plusieurs caractéristiques debonnes pratiques des tests :
• Pour chaque activité de développement, il y a une activité de test correspondante
• Chaque niveau de test a des objectifs de test spécifiques à ce niveau
• L'analyse et la conception des tests pour un niveau de test donné commencent au cours del'activité de développement correspondante
• Les testeurs participent aux discussions pour définir et affiner les exigences et la conception, et sont impliqués dans la revue des produits
d'activités (p. ex. les exigences, la conception, les UserStories, etc.) dès que des versions préliminaires sont disponibles
 Quel que soit le modèle de cycle de développement logiciel choisi, les activités de test devraient commencer dès les premières étapes du cycle de vie, en respectant
le principe de « Tester tôt ».
 les modèles de cycle de vie de développement de logiciels :

• Modèles de développement séquentiel
• Modèles de développement itératif et incrémental
 Un modèle de développement séquentiel décrit le processus de
développement logiciel comme un flux linéaire et séquentiel d'activités. Cela
signifie que toute phase du processus de développement devrait commencer
lorsque la phase précédente est terminée. En théorie, il n'y a pas de
chevauchement des phases, mais dans la pratique, il est bénéfique d'avoir un
retour rapide de la phase suivante.
 Dans le modèle 'en cascade', les activités de développement (p. ex.
analyse des exigences, conception, codage, test) sont réalisées l'une après
l'autre. Dans ce modèle, les activités de test ont seulement lieu une fois que
toutes les autres activités de développement sont terminées.
 Contrairement au modèle en 'cascade', le modèle en V intègre le
processus de test tout au long du processus de développement, en
appliquant le principe de « Tester tôt ». De plus, le modèle en V inclut des
niveaux de test associés à chaque phase de développement correspondante,
ce qui favorise le
 « Tester tôt » (voir la section 2.2 pour une discussion sur les niveaux de
test). Dans ce modèle, l'exécution des tests associés à chaque niveau de test
se déroule séquentiellement, mais dans certains cas, il y a chevauchement.
 Les modèles de développement séquentiels fournissent des logiciels qui
contiennent l'ensemble des fonctionnalités, mais qui nécessitent généralement
des mois ou des années pour être livrés aux parties prenantes et aux utilisateurs.
Le développement incrémental implique la définition des exigences, la conception, le
développement et letest d'un système par morceaux, ce qui signifie que les fonctionnalités
du logiciel augmentent de façon incrémentale. La taille de ces incréments de fonctionnalités
varie, certaines méthodes ayant des étapes plus grandes et d'autres plus petites. Les
incréments de caractéristiques peuvent être aussi petits qu'uneunique modification d'un
écran d'interface utilisateur ou qu’une nouvelle option de requête.
Le développement itératif se déroule lorsque des groupes de caractéristiques sont
spécifiés, conçus, développés et testés ensemble dans une série de cycles, souvent d'une
durée fixe. Les itérations peuvent impliquer des changements sur les caractéristiques
développées dans les itérations précédentes, ainsi que des changements sur le périmètre
du projet. Chaque itération délivre un logiciel opérationnel qui est un sous-ensemble
croissant de l'ensemble global des caractéristiques jusqu'à ce quele logiciel final soit livré
ou que le développement soit arrêté.
 En voici quelques exemples :
• Rational Unified Process : chaque itération a tendance à être relativement longue (p. ex. deux à trois mois), et les incréments de caractéristiques
sont proportionnellement importants, de l’ordrede deux ou trois groupes de caractéristiques connexes
• Scrum : chaque itération a tendance à être relativement courte (p. ex., heures, jours ou quelquessemaines), et les incréments de caractéristiques
sont proportionnellement petits, de l’ordre de quelques améliorations et/ou deux ou trois nouvelles caractéristiques
• Kanban : mis en œuvre avec des itérations de durée fixe ou non, pouvant soit livrer à la fin uneseule amélioration ou caractéristique, soit
regrouper des groupes de caractéristiques pour les livrer en une fois
• Spiral (ou par prototypage) : il s'agit de créer des incréments expérimentaux, dont certains peuvent être fortement remaniés ou même
abandonnés lors de travaux de développementultérieurs
Modèles de cycle de vie du développement logiciel en contexte
 Les modèles de cycle de vie du développement logiciel doivent être sélectionnés et adaptés au contexte du projet et aux caractéristiques du produit. Un modèle de cycle
de vie du développement logiciel approprié devrait être choisi et adapté en fonction de l'objectif du projet, du type de produit développé, des priorités métier (p. ex., délai de
mise sur le marché) et des risques produit et projet identifiés. Par exemple, le développement et le test d'un système peu important de gestion interne devrait être différent
du développement et du test d'un système critique pour la sécurité, comme un système de contrôle de freinage d'une automobile. Par ailleurs, dans certains cas, des
problèmes organisationnels et culturels peuvent inhiber la communication entre les membres de l'équipe, ce qui peut gêner le développement itératif.
 Selon le contexte du projet, il peut être nécessaire de combiner ou de réorganiser les niveaux de test et/ou les activités de test. Par exemple, pour
l'intégration d'un logiciel commercial sur étagère (COTS) dans un système plus grand, l'acheteur peut effectuer des tests d'interopérabilité au niveau des
tests d'intégration du système (p. ex., intégration à l'infrastructure et à d'autres systèmes) et au niveau des tests d'acceptation (fonctionnels et non-
fonctionnels, ainsi que des tests d'acceptation utilisateur et destests d'acceptation opérationnelle).
Utilisation efficace des outils
Model-Based Testing
TDD
Bénéfices et risques de
l'automatisation des tests
Outils de test
Classification des outils de test
Techniques
test boîte-blanche
Test et couverture des instructions
 Le test des instructions exerce les instructions exécutables dans le code.

La couverture est mesurée :
le nombre d'instructions exécutées par les tests
le nombre total d'instructions exécutables dans l'objet de test

If A = 100
Print (« Bonjour »)
Print somme(int a , int b) {
Int resultat= a +b ;
If (resultat > 0)
Print (« positif », resultat )
Else If (resultat < 0)

Print (« Négatif », resultat )
}
Test et couverture des décisions
 Le test des décisions exerce les décisions dans le code et teste le code qui est
exécuté sur la base des résultats des décisions. Pour cela, les cas de test
suivent les flux de contrôle qui se produisent à partir d'un point de décision
(par exemple, pour une instruction IF, un pour le résultat vrai et un pour le
résultat faux ; pour une instruction CASE, des cas de test seraient nécessaires
pour tous les résultats possibles, y compris le résultat par défaut).
 La couverture est mesurée :
le nombre de résultats de décision exécutés par les tests
le nombre total de résultats de décision dans l'objet de test

 If A < B A<B
B=0;
A=A+1
ELSE
A=B ; B=0; A=B
A=A+1
Combien de cas de test pour couvrir 100%

de couverture des décisions ? END
 If A < B A<B
B=0;
A=A+1 ;
B=0;
A=A+1
Combien de cas de test pour couvrir 100%

de couverture des décisions ? END
3. Types de tests et
processus de test communs
pour les applications mobiles
1. Tests d’installabilité
 Les testeurs doivent se concentrer sur l’installation, la mise à jour et la désinstallation del’application en utilisant les approches suivantes :
• « Application_stores » (magasins d’applications)
 Le processus d’installation peut être différent selon les utilisateurs de

 l’application. Les utilisateurs peuvent installer l’application à partir de magasins de marché tels que le Google Play Store ou l’App
Store d’Apple. Les utilisateurs d’applications d’entreprise devront effectuer des tests d’installation via un lien, ou un service de
distribution tel que HockeyApp ouApp Center.
• « Sideloading » (copie et installation de l’application)
 Certains systèmes d’exploitation offrent la possibilité d’installer l’application

 en la copiant sur un appareil mobile et en l’installant à partir du fichier.
• Applications de bureau
 Des applications de bureau telles qu’Apple iTunes (pour iOS) ou Android App Installer sont disponibles pour l’installation
d’applications sur le smartphone. Le testeur doit y télécharger l’application et utiliser un câble pour l’installer vers le smartphone.
La plupart de ces applications de bureaupermettent également la désinstallation de l’application.
 L’installation peut être effectuée en utilisant les méthodes suivantes :

• OTA (Over-the-Air) via Wi-Fi ou données cellulaires
• Câble de données
1. Tests d’installabilité
 Certaines des conditions de test à considérer incluent :
• Installation, désinstallation et mise à niveau de la mémoire interne et externe (sipris en charge).
• Réinstallation de l’application lorsque l’option « conserver les données de l’application » a été choisie lors de la désinstallation
précédente.
• Réinstallation de l’application lorsque l’option « conserver les données de l’application » n’a pas été choisie lors de la désinstallation
précédente.
• Annuler ou interrompre l’installation ou la désinstallation, par exemple en arrêtant l’appareil mobile pendant le processus ou en se
déconnectant d’Internet.
• Reprise de l’installation, de la désinstallation et de la mise à niveau interrompues après l’annulation ou l’interruption.
• Tests liés aux autorisations. Par exemple, certaines applications demandent la permission d’utiliser le carnet d’adresses. Ce test
important doit vérifier le comportement de l’application si l’utilisateur refuse l’autorisation. Par exemple, y a-t-il un message
correspondant envoyé à l’utilisateur ?
• Mettre à jour l’application et vérifier qu’aucune donnée n’est perdue.
 Certaines applications nécessitent des dispositifs « jailbreakés » (iOS) ou « rooted » (Android) qui donnent à l’utilisateur les droits administratifs sur
l’appareil. La plupart des fournisseurs de plates-forme ne prennent pas en charge le « jailbreaking / rooting » car ils peuvent entrainer des
conséquences juridiques. Une application n’exigeant pas de « jailbreaking / rooting » peut ne pas avoir à être testée pour les dispositifs de «
jailbreaking / rooting ».

2. Tests de Stress
 Les tests de stress sont axés sur la détermination de l’efficacité des performances de l’application lorsqu’elle est soumise à des conditions au-delà
de la charge normale. Le test destress dans ce contexte ne s’adresse qu’aux appareils mobiles.
 Les tests de stress du backend sont décrits dans le syllabus ISTQB@ tests de performance ([ISTQB CTFL PT 2018]) qui constitue une référence
utile pour ce domaine.

 Certaines des conditions de test qui peuvent être considérées pour les tests de stress comprennent :
• Utilisation élevée du processeur
• Plus de mémoire disponible
• Faible espace disque
• Stress de la batterie
• Défaillances
• Mauvaise bande passante

• Nombre très élevé d’interactions avec les utilisateurs (les conditions du réseauréel peuvent devoir être simulées pour cela)
 Certaines de ces conditions stressantes peuvent être créées à l’aide d’outils tels que Monkey. Il s’agit d’un outil de ligne de commande qui
s’exécute sur la ligne de commande shell ADB [URL3] ou, si possible, manuellement, par exemple, en utilisant de gros fichiers ou d’autres
applications avec une utilisation élevée du processeur ou la consommation de mémoire.
3 ,Tests de sécurité
 Étant donné que les tests de sécurité sont un sujet complexe, l’ISTQB a un syllabus Spécialiste distinct à ce sujet [ISTQB CTAL SEC 2016]. Les
principaux problèmes de sécurité pour les applications mobiles incluent :
• L’accès aux données sensibles sur l’appareil.
• Le transfert d’informations non crypté ou stockage non sécurisé.

 Certaines des conditions de test qui peuvent être considérées pour les tests de sécurité comprennent les sujets suivants :
• Test des entrées pour l’injection de code et le débordement.
• Cryptage des données transférées.
• Cryptage des données stockées localement.

• Suppression de données temporaires après utilisation ou après une finanormale.
• Effacer le texte dans les champs de mots de passe.

 Le top 10 des vulnérabilités liées au mobile de l’Open Web Application Security Project (OWASP) devrait également être exploré
3 .Tests de sécurité
 Étant donné que les tests de sécurité sont un sujet complexe, l’ISTQB a un syllabus Spécialiste distinct à ce sujet [ISTQB CTAL SEC 2016]. Les
principaux problèmes de sécurité pour les applications mobiles incluent :
• L’accès aux données sensibles sur l’appareil.
• Le transfert d’informations non crypté ou stockage non sécurisé.

 Certaines des conditions de test qui peuvent être considérées pour les tests de sécurité comprennent les sujets suivants :
• Test des entrées pour l’injection de code et le débordement.
• Cryptage des données transférées.
• Cryptage des données stockées localement.

• Suppression de données temporaires après utilisation ou après une finanormale.
• Effacer le texte dans les champs de mots de passe.

 Le top 10 des vulnérabilités liées au mobile de l’Open Web Application Security Project (OWASP) devrait également être exploré
4 . Tests de performance
 Si l’utilisateur installe l’application et qu’elle n’apparaît pas assez vite (par exemple, en respectant pas un temps inférieur ou égal à 3 secondes),
elle peut être désinstallée en faveur d’une autre application alternative. Les aspects de la consommation de temps et de ressources sont des facteurs
de succès importants pour une application et les tests de performance sontdonc effectués pour mesurer ces aspects.
 L’efficacité des performances doit être testée sur l’appareil lui-même en plus de l’interaction avec le système backend et d’autres appareils
mobiles.
 Les tests de performance de l’ensemble du système doivent être effectués tels que définis dans la stratégie de test et ne sont pas
spécifiques au mobile.

 Le test de performance de l’application elle-même doit contenir la chronométrie pour les flux de travail les plus importants. Voici
quelques exemples pour les flux de travail d’une application bancaire en ligne : « Connexion », « Changement d’adresse » ou « Virement
bancaire avec PIN et numéro de transaction ». Le testeur doit ensuite comparer cette chronométrie avec desapplications similaires.
 Outre les mesures chronométriques, il est important de tenir compte des performances perçues par l’utilisateur. L’expérience
utilisateur peut avoir un impact énorme sur la durée pendant laquelle l’utilisateur est prêt à attendre qu’une certaine fonction soit
terminée.
5 . Tests d’utilisabilité
 L’utilisabilité est très importante pour les applications mobiles parce que les données montrent qu’un grand nombre d’utilisateurs désinstallent leurs
applications dans les quelques minutes après l’installation en raison d’une mauvaise utilisabilité ou de mauvaises performances, voir [URL4].
 Pour cette raison, il est recommandé que la conception de l’expérience utilisateur (UX) considère l’apparence et la sensation [NDT : « look and
feel »] de la plate-forme sur laquelle l’application doit être utilisée. Si l’UX n’est pas conforme aux attentes de l’utilisateur pour la plate-forme utilisée,
cela peut avoir un fort impact négatif. Ainsi, un testeur doit être conscientde l’apparence et de la sensation sur la plate-forme utilisée.

 Les tests d’utilisabilité peuvent être effectués par un testeur à l’aide de diverses heuristiques disponibles et de types d’usage testés.

 Considérer l’usage de personae est également pertinent dans le cadre des tests d’utilisabilité. Si nécessaire, un laboratoire d’utilisabilité peut
également être utilisé à cette fin.

 Dans les projets, les résultats identifiés au cours des tests d’utilisabilité ne sont pour la plupart que des constatations et non des défauts. Le testeur
doit avoir la capacité d’expliquer les résultats à l’équipe, au Product Owner ou à des parties prenantes similaires. Pour obtenir une utilisabilité
satisfaisante, une application doit :
• Être explicite et intuitive
• Permettre les erreurs de l’utilisateur.
• Être cohérente dans les libellés et le comportement.
• Respecter les directives de conception des plates-formes.

• Rendre les informations nécessaires visibles et accessibles dans chaque tailleet type d’écran.
6 .Tests de bases de données

 De nombreuses applications doivent stocker des données localement à l’aide de divers mécanismes de stockage de données tels que des fichiers
plats ou des bases de données.

 Certaines des conditions de test à prendre en compte pour le test de base de données des applications mobiles comprennent :
• Validation des problèmes de stockage de données :
o Synchronisation
o Conflits de chargement (« upload »)
o Sécurité des données
o Contraintes sur les données

o Fonctionnalité CRUD (Create/Read/Update/Delete) [NDT : créer, lire,modifier, effacer]
o Recherche
• Test d’intégration des données pour les données fournies par l’appareil (p. ex.,contacts) ou par des applications tierces (p.
ex., photos, vidéos et messages).
• Performances de stockage des données sur l’appareil.

3 - Le-Domaine-Du-Test-Logiciel-Laqualitelogiciel

Transféré par

Droits d'auteur :

Formats disponibles

3 - Le-Domaine-Du-Test-Logiciel-Laqualitelogiciel

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

3 - Le-Domaine-Du-Test-Logiciel-Laqualitelogiciel

Transféré par

Droits d'auteur :

Formats disponibles

Le domaine du Testing

Psychologie humaine et test

 Les moyens de bien communiquer comprennent les exemples suivants :

 Un processus de test se compose des principaux groupes d'activités suivants :

 La planification des tests implique de définir les objectifs du test et l'approche

• Concevoir et prioriser les cas de test et les ensembles de cas de test

 Objectifs des tests de composants

Objectifs des tests d'intégration

 des objets de test de taille variable comme suit :

• Défaillances dans la communication entre les composants

 L'environnement de test devrait idéalement correspondre à la cible finale ou à

 Défauts et défaillances courants

 Disponibilité des données de test et autres ressources nécessaires

Les critères de sortie habituels incluent :

Tests basés sur des checklists

peut être extrêmement préjudiciable à la réussite d'un projet.

 Les caractéristiques communes des techniques de test boîte-noire incluent :

 Les caractéristiques communes des techniques de test des boîte-blanche incluent :

 les modèles de cycle de vie de développement de logiciels :

Classification des outils de test

 Le test des instructions exerce les instructions exécutables dans le code.

le nombre d'instructions exécutées par les tests

le nombre total d'instructions exécutables dans l'objet de test

Else If (resultat < 0)

le nombre de résultats de décision exécutés par les tests

le nombre total de résultats de décision dans l'objet de test

Combien de cas de test pour couvrir 100%

Combien de cas de test pour couvrir 100%

• « Application_stores » (magasins d’applications)

 Le processus d’installation peut être différent selon les utilisateurs de

• « Sideloading » (copie et installation de l’application)

 Certains systèmes d’exploitation offrent la possibilité d’installer l’application

 L’installation peut être effectuée en utilisant les méthodes suivantes :

• Faible espace disque

• Mauvaise bande passante

• Cryptage des données transférées.

• Cryptage des données stockées localement.

• Cryptage des données transférées.

• Cryptage des données stockées localement.

• Permettre les erreurs de l’utilisateur.

• Être cohérente dans les libellés et le comportement.

• Respecter les directives de conception des plates-formes.

o Conflits de chargement (« upload »)

o Sécurité des données

o Contraintes sur les données

Vous aimerez peut-être aussi