Software Testing FR

Abonnez-vous à DeepL Pro pour éditer ce document.
Visitez www.DeepL.com/Pro pour en savoir plus.
Université de Yaoundé I L'Université de Yaoundé I

Faculté des sciences Faculté des sciences
Département d’Informatique Département d'informatique
VÉRIFICATION ET VALIDATION DE LOGICIELS
INF
2018/2019 Session
Page 1 de 78 ICT304 : Notes de cours sur les essais de logiciels par le Dr X. Y. Kimbi
Objectifs du cours
 Apprendre les principes, les techniques et les outils des tests de logiciels afin
d'améliorer la qualité de l'information. la qualité du produit logiciel.
 Les étudiants acquerront des connaissances et des compétences en tests logiciels leur
permettant ainsi de
- Appliquer et comparer les techniques sur des projets professionnels
- Analyser, évaluer et améliorer la qualité des logiciels
- Développer des logiciels de haute qualité
 Les étudiants sont exposés à la technologie actuelle dans le cadre de tests automatisés
leur permettant ainsi de
- Construire des cadres de test en utilisant les principes et les paradigmes de test des
logiciels.
 Les élèves en apprennent davantage sur
- La vérification du modèle comme procédure de vérification importante
- Effectuer des tests automatisés à l'aide d'outils de test automatisés
- Le débogage systématique comme moyen de localiser les causes d'erreurs
- Logiciel de débogage pour déboguer et signaler les bogues
Résultats du cours
 À la fin du cours, les étudiants auront une vision unifiée des tests unitaires de logiciels
: où l'automatisation est possible à toutes les étapes - de la génération des cas de test, à
l'exécution, à l'évaluation de l'effort de test ; où le test automatisé est une activité
complémentaire au test manuel ; et où l'effet sur le test unitaire est une partie
intégrante du test logiciel. Test pratique de logiciels à l'aide de Junit et création d'un
rapport de test dans Bugzilla.
 Concevoir et mettre en œuvre un cadre d'essai de logiciels à l'aide de diverses
méthodes, stratégies et techniques présentées dans le cours qui répondent aux
exigences des propriétés souhaitées.
 Appliquer les principes du test logiciel dans un contexte réel et multidisciplinaire.
TABLE DES MATIÈRES
CONFÉRENCE 1 : INTRODUCTION AUX TESTS DE LOGICIELS
Qu'est-ce que le test logiciel ?

Pourquoi avons-nous besoin de tests logiciels ?
Objectifs des tests logiciels
Test et débogage
Limitation des tests de logiciels
Vérification et validation des logiciels
Les objectifs de la vérification et de la validation des logiciels
Techniques de vérification et de validation des logiciels
Analyse et méthodes informelles
Méthodes d'analyse statique
Analyse dynamique / Méthodes
Analyse formelle/Méthodes
Erreurs de programme
Les défis du test logiciel
Tests dans le cycle de vie du développement logiciel
Qu'est-ce qu'un scénario de test ?
Sources d'information pour la sélection des causes types
CONFÉRENCE 2 : MÉTHODOLOGIES DE TEST DES LOGICIELS
Que sont les méthodologies de test logiciel ?

Importance des méthodes d'essai
Types de méthodologies de tests logiciels ?
 Essais structuraux (essais en boîte blanche)
Objectifs du test de la boîte blanche
Les limites du test de la boîte blanche
Niveaux de test de la boîte blanche : (Types de tests de boîtes blanches)
Test unitaire
Test d'intégration
Test du système
Tests d'acceptation
Test de régression
 Test fonctionnel (test de boîte noire)

Objectifs du test de la boîte blanche
Les limites du test de la boîte blanche
CONFÉRENCE 3 : TECHNIQUES DE TEST DES BOÎTES BLANCHES :

(TECHNIQUES DE GÉNÉRATION DE DONNÉES D'ESSAI)
 Essai de débit de contrôle
Mesures/couverture du test des boîtes blanches (critères de sélection des trajectoires)

Critère de couverture du sillon
Critère de couverture de l'énoncé
Critère de couverture de la condition, de la direction générale ou de la décision
- Diagramme de contrôle
 Test de flux de données

Critères d'essai des flux de données
Anomalie de flux de données
EXPOSÉ 4 : TECHNIQUES DE TEST DE LA BOÎTE NOIRE
Partitionnement d'équivalence (Partitionnement de classe d'équivalence)

Analyse de la valeur limite
Tests comportementaux
Tests aléatoires
Deviner les erreurs
Tests de cas d'utilisation
Tables de décision
EXPOSÉ 5 : PRINCIPES DE TEST DES LOGICIELS
 Les tests permettent d'identifier la présence de défauts

 Les tests exhaustifs sont impossibles
 Tests précoces dans le cycle de vie du développement logiciel
 Regroupement des défauts (agrégation des défauts)
 Paradoxe des pesticides
 Le test dépend du contexte
 Absence d'erreurs Fallacie
EXPOSÉ 6 : UNE APPROCHE PRATIQUE DES TESTS LOGICIELS
TESTLINK
 Avantages de TestLink
 Création d'un projet test
 Création d'un plan de test
 Création de bâtiments
 Création d'une suite de tests
 Création d'un scénario de test
 Affectation d'un scénario de test au plan de test
 Création d'utilisateurs et affectation de rôles dans Testink
 Exigences en matière de rédaction
 Exécution d'un scénario de test
 Génération d'un rapport de test
 Exportation d'un jeu de test / d'une suite de tests
 Importation d'une valise de test ou d'une suite de tests
EXPOSÉ 7 : MÉTHODES D'ESSAIS AUTOMATISÉS
Tests automatisés
 Qu'est-ce qu'un test automatisé ?
 Pourquoi avons-nous besoin de l'automatisation des tests ?
 Introduction à l'outil de test open source JUnit : Cadre pour le dépistage à l'unité
 Outils pour les tests unitaires
 Tests basés sur des modèles
 Exécution symbolique pour les tests logiciels
 Exécution symbolique dynamique
EXPOSÉ 8 : MÉTHODES D'ESSAI AUTOMATIQUE suite
 Une approche pratique des tests logiciels

 JUnit : Cadre pour le dépistage à l'unité
 Exécution de tests automatisés
 Dérivation de cas de tests automatisés
 Test d'enregistrement en mode analogique et en mode contextuel
 Test de synchronisation
 Vérification des objets GUI
 Vérification des objets Bitmap
 Création d'un test piloté par les données
 Maintien du script de test
 Projet (Création d'un rapport de test dans Bugzilla)
 Développer des cas de test pour un projet particulier
EXPOSÉ 9 : TESTS ET MAINTENANCE DE LOGICIELS
Contexte de la maintenance
Maintenance évolutive
Maintenance corrective
Retraite et remplacement
Politiques de test de régression
EXPOSÉ 10 : UNE PRÉSENTATION PROFESSIONNELLE DU PROJET
EXPOSÉ 11 : Révision générale
Manuels scolaires :
1. Software Testing Principles, Techniques and Tools by M G Limaye, Publié par Tata
McGraw-Hill Education Private Limited, Publié en 2009, ISBN (13) : 978-0-07-013990-9,
ISBN (10) : 0-07-013990-3 (chapitres 1 et 3)
2. Essais de logiciels, deuxième édition Par : Ron Patton, publié par l'ASSM, ISBN-13 : 978-
0672327988 ISBN-10 : 0672327988 (chapitres 2, 4 & 6)
3. Génie logiciel : A Practitioner's Approach by Roger S Pressman, 8e édition, McGraw Hill,

éditeur (Chapitre 5)
CONFÉRENCE 1 : INTRODUCTION AUX TESTS DE LOGICIELS
- Software Testing exécute un programme dans le but de trouver des erreurs.

- Software Testing est un ensemble d'activités menées dans le but de déceler les erreurs. Il
s'assure également que le système fonctionne conformément aux spécifications de
conception. Les deux objectifs importants des tests de logiciels sont de s'assurer que le
système en cours de développement est conforme aux exigences du client et de révéler les
bogues. Une forme essentielle d'assurance logicielle est le test des logiciels. Les tests sont
laborieux, coûteux et prennent beaucoup de temps, de sorte que le choix des tests doit être
basé sur le risque pour le système.
- Les tests de logiciels sont une partie vitale du développement de logiciels et l'automatisation
les rend plus rapides, plus fiables et plus rentables.
- Les tests de logiciels est une enquête empirique (expérimentale) menée pour fournir aux
intervenants de l'information sur la qualité du produit ou du service mis à l'essai.
Le test du système exécute un programme pour vérifier sa fonctionnalité dans le but de

trouver des erreurs ou des défauts.
Logiciel testant le processus d'exécution d'un programme dans le but de déterminer si les
exigences spécifiées ont été satisfaites ou non.
- Les tests sont essentiels au succès d'un système. Dans le cadre des essais du système, des
normes de rendement et d'acceptation sont élaborées.
- Le test est l'une des phases importantes du développement logiciel. Dans cette phase, le
programme testé est exécuté pour révéler les défauts et, après avoir détecté les défaillances,
des techniques de débogage sont appliquées pour isoler et supprimer les défauts.
Évidemment, les techniques utilisées pour ces différentes tâches dépendent des outils,
techniques et méthodologies utilisés pour développer le logiciel testé.
- Les tests automatisés ne peuvent pas remplacer les tests manuels, ils augmentent
(complètent) les efforts de test du testeur humain.
Qu'est-ce que le test logiciel ?
Le test de logiciels est le processus d'exécution d'un programme dans l'intention de trouver
des erreurs.
L'essai est le processus d'évaluation d'un système ou de ses composants dans le but de
déterminer s'il satisfait ou non aux exigences spécifiées.
Cette activité se traduit par les résultats réels, attendus et la différence entre leurs résultats. En
d'autres termes, le test est l'exécution d'un système afin d'identifier toute lacune, erreur ou
exigence manquante contrairement au désir ou aux exigences réelles.
Le test est la partie la plus importante du cycle de vie du développement logiciel (SDLC). On
ne peut pas libérer le produit final sans passer par le processus d'essai.
Le but des tests logiciels est de trouver des bogues/défauts dans le logiciel. Le test de
logiciels est une partie essentielle du génie logiciel.
Pourquoi avons-nous besoin de tests logiciels ?

On ne saurait trop insister sur l'importance du dépistage.
(1) Il existe de nombreux appareils, navigateurs et systèmes d'exploitation différents. Nous

avons la chance de vivre à une époque où nous pouvons choisir parmi un buffet
technologique de téléphones, de tablettes, d'ordinateurs portables et de postes de travail, sans
parler des différents navigateurs et systèmes d'exploitation utilisés sur ces appareils. Toute
cette variété est géniale, mais elle rend également essentiels les tests de compatibilité. Les
tests sur plusieurs appareils, navigateurs et systèmes d'exploitation peuvent vous aider à vous
assurer que votre site Web fonctionne pour le plus grand nombre possible d'utilisateurs.
(Diversité et portabilité des utilisateurs)
(2) Le logiciel prévaut dans notre milieu de vie. La qualité des logiciels influence
considérablement notre qualité de vie. Le logiciel en tant qu'entité a affecté tous les aspects
de la vie. Personne n'aurait pu prévoir que des logiciels seraient intégrés dans des systèmes de
toutes sortes : Soins de santé, Affaires, Transport, Éducation, Télécommunications, Finances,
Militaire, Divertissement, Météo, etc. Malgré ces améliorations spectaculaires dans le
développement de logiciels (logiciels de conception Web, applications mobiles, logiciels
d'intelligence artificielle, systèmes d'exploitation, etc.), nous n'avons pas encore mis au point
une technologie logicielle qui fasse tout cela, et la probabilité qu'un tel développement se
produise dans l'avenir est faible.
(3) Les défaillances logicielles de systèmes logiciels critiques (un système critique pour la
sécurité est défini comme un système dans lequel le mauvais fonctionnement d'un logiciel
pourrait entraîner la mort, des blessures ou des dommages à l'environnement) peuvent
causer des dommages considérables sur nos vies. Par exemple
- En 1986, deux patients cancéreux du East Texas Cancer Center ont reçu des
surdoses mortelles de rayonnement provenant de l'appareil de radiothérapie
commandé par ordinateur.
- Les erreurs logicielles peuvent être coûteuses pour l'économie d'un pays.
Comparaison avec l'industrie automobile
Comparons le développement du logiciel avec le développement de l'industrie automobile :
- Si l'industrie automobile s'était développée comme l'industrie du logiciel, nous

conduirions tous des voitures achetées pour 25 000 francs, c'est-à-dire que
l'industrie du développement logiciel se développe à un rythme alarmant que
l'industrie automobile.
- Si la voiture était comme un logiciel, ils tomberaient en panne deux fois par jour
sans raison, et quand vous êtes appelé pour le service, vous direz le propre à vous
de réinstaller le moteur.
A partir de l'explication ci-dessus, quelles sont les différences entre Défaut logiciel, Erreur
logicielle et Défaillance logicielle ?
Erreur de Défaillance du
Défaut logiciel logiciel logiciel
Relations entre les défauts du logiciel
A partir de l'explication ci-dessus, quels sont les objectifs du Software Testing ?
Objectifs des tests logiciels
L'objectif général des tests de logiciels est d'affirmer la qualité des systèmes logiciels en
exerçant systématiquement le logiciel dans des circonstances soigneusement contrôlées :
 Révéler les défauts (erreurs de recherche : erreurs de syntaxe, erreurs logiques, erreurs
sémantiques, etc.)
 Établir la confiance dans le logiciel
 Clarification de la spécification des besoins de l'utilisateur
Le seul moyen d'élever le niveau confidence d'un programme significantly est de donner une
preuve convaincante de son exactitude.
Ces objectifs peuvent-ils être atteints sans difficultés ?
Les défis du test logiciel

 Les tests représentent un coût énorme pour le développement de produits
 Spécifications incomplètes, informelles et changeantes ou exigences incomplètes des
utilisateurs.
 Manque d'outils de test des logiciels
 L'efficacité des tests et la qualité des logiciels sont difficiles à mesurer
Test et débogage
Essais : Il s'agit de l'identification d'un bug/erreur/défaut dans le logiciel sans le corriger.

Normalement, des professionnels ayant une formation en assurance qualité sont impliqués
dans l'identification des bogues. Les tests sont effectués pendant la phase de test.
Débogage : Il implique l'identification, l'isolation et la réparation (I2F) des
problèmes/bogues. Les développeurs qui codent le logiciel procèdent au débogage lorsqu'ils
rencontrent une erreur dans le code. Le débogage est la partie du test de la boîte blanche ou
du test unitaire. Le débogage peut être effectué au cours de la phase de développement
pendant l'exécution des tests unitaires ou au cours des phases de correction des bogues
signalés.
Qu'est-ce que la vérification et la validation de logiciels ?
La vérification et la validation (V&V) est le processus qui consiste à vérifier qu'un système
logiciel est conforme aux spécifications et qu'il remplit sa fonction prévue. On peut aussi
l'appeler contrôle de la qualité des logiciels.
Definitions
Verification Le processus de déterminer si les produits d'une phase donnée du processus de

développement de logiciels fulfil les exigences établies au cours de la phase précédente.
La vérification peut également être définie comme le processus d'évaluation d'un logiciel
afin de déterminer si les produits d'une phase donnée de développement logiciel satisfont aux
conditions imposées au début de cette phase.
Supposons que vous construisiez une table. Ici, la vérification consiste à vérifier toutes les
parties du tableau, si les quatre pieds sont de la bonne taille ou non. Si un pied de table n'est
pas de la bonne taille, il déséquilibre le produit final. Un comportement similaire est
également observé dans le cas du produit logiciel ou de l'application. Si une caractéristique
du produit logiciel ou de l'application n'est pas à la hauteur de la marque ou si un défaut est
détecté, il en résultera la défaillance du produit final.
Ainsi, la vérification se fait au début du processus de développement du logiciel (phase de

spécification des besoins), au début de chaque phase de développement et à la fin de chaque
phase de développement.
Il comprend des examens et des réunions, des visites, des inspections, etc. pour évaluer les
documents, les plans, les spécifications des exigences, la conception et le codage du système.
La vérification est donc très importante. Elle a lieu au début du processus de développement.
Il répond aux questions du genre :

Est-ce que je construis bien le produit ?
Est-ce que j'accède aux données correctement (au bon endroit, de la bonne manière).
C'est une activité de bas niveau ? (Conception conceptuelle)
Effectué au cours de l'élaboration d'artefacts clés, comme les revues et les inspections, la
rétroaction des mentors, la formation, les listes de vérification et les normes.
Démonstration de la cohérence, de l'exhaustivité et de l'exactitude du logiciel à chaque étape
et entre chaque étape du cycle de développement.
Avantages de la vérification logicielle :
1. La vérification aide à réduire le nombre de défauts dans les stades ultérieurs du

développement.
2. La vérification du produit au début de la phase de développement aidera à mieux

comprendre le produit.
3. Il réduit les risques de défaillance de l'application logicielle ou du produit.
4. Il aide à construire le produit selon les spécifications et les besoins du client.
Validation : Le processus d'évaluation du logiciel à la fin de chaque phase de développement

du logiciel pour s'assurer qu'il est conforme à l'utilisation prévue.
La validation peut également être définie comme le processus d'évaluation du logiciel à la

fin de chaque phase de développement pour déterminer s'il satisfait aux exigences spécifiées.
La validation se fait à la fin de la phase de développement et a lieu après la fin des
vérifications.
Ça répond à la question comme :
 Est-ce que je construis le bon produit ? Ou le bon produit a-t-il été fabriqué ?
 Ai-je accès aux bonnes données (en termes de données requises pour satisfaire à
l'exigence) ?
 C'est une activité de haut niveau.
 Effectué après la production d'un produit de travail en fonction de critères établis afin
de s'assurer que le produit s'intègre correctement dans l'environnement.
 Détermination de l'exactitude du produit logiciel final par un projet de développement

en fonction des besoins et des exigences de l'utilisateur.
Validation des logiciels : La validation du logiciel vérifie que le produit logiciel satisfait ou
correspond à l'utilisation prévue (vérification de haut niveau), c'est-à-dire que le logiciel
répond aux exigences de l'utilisateur.
Non seulement le produit logiciel dans son ensemble peut être validé. Les exigences doivent
être validées avant que le logiciel dans son ensemble ne soit prêt.
Exemples d'artefacts (items) à valider :
 Validation de la spécification des besoins de l'utilisateur : Les besoins des utilisateurs,

tels qu'ils sont énoncés dans un document intitulé User Requirements Specification
Document, sont validés en vérifiant s'ils représentent bien les objectifs des parties
prenantes. Cela peut se faire en les interviewant ou même en publiant des prototypes
rapides et en demandant aux utilisateurs et aux parties prenantes de les évaluer.
 Validation des entrées utilisateur : ) est validée en vérifiant si les données fournies par
les opérateurs du logiciel et les utilisateurs respectent les règles et les contraintes du
domaine (telles que le type, la portée et le format des données).
La vérification du logiciel peut également être définie comme le processus d'évaluation du

logiciel pour déterminer si les produits d'une phase donnée de développement de logiciel
satisfont aux conditions imposées au début de cette phase, c'est-à-dire les exigences de la
phase précédente.
Quelques exemples d'éléments doivent être vérifiés :
 Vérification des spécifications de conception par rapport aux spécifications des

exigences : La conception architecturale, la conception détaillée et les spécifications
du modèle logique de la base de données appliquent-elles correctement les
spécifications des exigences fonctionnelles et non fonctionnelles ?
 Vérification des artefacts de mise en œuvre par rapport aux spécifications de

conception : Le code source, les interfaces utilisateur et le modèle physique de la base
de données appliquent-ils correctement les spécifications de conception ?
Verification est généralement une activité plus technique qui utilise les connaissances sur les
artefacts logiciels individuels, les exigences et specifications. La validation dépend
généralement de la connaissance du domaine, c'est-à-dire de la connaissance de l'application
pour laquelle le logiciel est écrit. Par exemple, la validation d'un logiciel pour un avion exige
des connaissances de la part des ingénieurs en aérospatiale et des pilotes.
La vérification et la validation (V&V) sont des processus qui permettent de s'assurer que le
logiciel est correct et fiable, c'est-à-dire qu'il répond aux besoins de l'utilisateur.
Vérification
(En cours)
Planification : -
Utilisateurs cibles Processus : Produit logiciel
Besoins et attentes Spécification des Analyse et conception du Mise à l'essai et
des clients exigences système mise en œuvre du
-Validation à la Développement de système
fin systèmes
Validation à la fin
Validation
Validation à la fin de chaque phase, de la planification au à la fin de
déploiement chaque
phase
Vérification et validation des logiciels
Les objectifs de la vérification et de la validation des logiciels
Le but de la vérification du logiciel est de trouver autant de défauts cachés dans le logiciel
avant la livraison.
L'objectif de la validation d'un logiciel est de gagner la confiance de l'utilisateur en

démontrant qu'il répond à ses spécifications des besoins de l'utilisateur, c'est-à-dire de
démontrer au développeur et au client (client) que le logiciel répond à ses exigences.
Techniques de vérification et de validation des logiciels
Il existe quatre techniques principales de vérification et de validation. Ils incluent :
- Analyse et méthodes informelles

- Méthodes d'analyse statique
- Analyse dynamique / Méthodes
- Analyse formelle/Méthodes
 Techniques informelles de V&V : Les techniques informelles de V&V sont parmi

les plus couramment utilisées. Ils sont dits informels parce que leurs outils et leurs approches
reposent largement sur le raisonnement et la subjectivité humains sans formalisme
mathématique rigoureux. Par exemple, Méthode d'inspection, ici le logiciel est inspecté pour
vérifier s'il répond aux spécifications du Document de spécification des exigences logicielles
(DSRF).
 Techniques V&V statiques : Les techniques de V&V statique évaluent la précision

de la conception du modèle statique et du code source. Les techniques statiques ne
nécessitent pas l'exécution machine du modèle, mais l'exécution mentale peut être utilisée.
Les techniques sont très populaires et largement utilisées, et de nombreux outils automatisés
sont disponibles pour aider dans le processus V&V. Les techniques statiques peuvent révéler
une variété d'informations sur la structure du modèle, les techniques de modélisation
utilisées, les flux de données et de contrôle dans le modèle et la précision syntaxique.
Analyse statique : Comme l'indique le terme "statique", il repose sur l'examen d'un certain
nombre de documents, à savoir les documents d'exigences, les modèles logiciels, les
documents de conception et le code source. L'analyse statique traditionnelle comprend
l'examen du code, l'inspection, la visite, l'analyse des algorithmes et la preuve de l'exactitude.
Il n'implique pas l'exécution effective du code en cours d'élaboration. Au lieu de cela, il
examine le code et les raisons de tous les comportements possibles qui pourraient survenir
pendant le temps d'exécution. Les optimisations du compilateur sont des analyses statiques
standard.
 Techniques V&V dynamiques : Les techniques de V&V dynamique nécessitent

l'exécution d'un logiciel/modèle ; elles évaluent le logiciel/modèle en fonction de son
comportement d'exécution. La plupart des techniques V&V dynamiques nécessitent
l'instrumentation du modèle, l'insertion de code supplémentaire (sondes ou stubs) dans le
modèle exécutable pour collecter des informations sur le comportement du modèle pendant
son exécution.
L'analyse dynamique d'un système logiciel implique l'exécution réelle d'un programme afin
d'exposer les défaillances possibles du programme. Les propriétés comportementales et de
performance du programme sont également observées. Les programmes sont exécutés avec
des valeurs d'entrée typiques et soigneusement sélectionnées. Souvent, l'ensemble d'entrée
d'un programme peut être impraticablement grand. Toutefois, pour des raisons pratiques, il
est possible de sélectionner un sous-ensemble finite du jeu d'entrées. Par conséquent, lors des
essais, nous observons certains comportements représentatifs du programme et tirons une
conclusion sur la qualité du système. Une sélection minutieuse d'un ensemble de tests finite
est cruciale pour parvenir à une conclusion fiable.
Les techniques de V&V dynamique sont généralement appliquées en trois étapes :
 Le modèle exécutable est instrumenté
 Le modèle instrumenté est exécuté
 La sortie du modèle est analysée, le comportement dynamique du modèle est évalué.
N/B :
En effectuant des analyses statiques et dynamiques, les praticiens veulent identifier autant de
fautes que possible afin que ces fautes soient fixed à un stade précoce du développement du
logiciel. L'analyse statique et l'analyse dynamique sont complémentaires par nature, et pour
une meilleure efficacité, elles doivent toutes deux être réalisées de façon répétée et alternée.
Les praticiens et les chercheurs doivent supprimer les frontières entre l'analyse statique et
l'analyse dynamique et créer une analyse hybride qui combine les forces des deux approches.
 Techniques formelles de V&V : Les techniques formelles de V&V (ou méthodes

formelles) sont basées sur des preuves mathématiques formelles ou sur l'exactitude et sont les
moyens les plus complets du modèle V&V. L'application réussie de méthodes formelles
exige que le processus d'élaboration du modèle soit bien défini et structuré. Les méthodes
formelles devraient être appliquées dès le début du processus d'élaboration du modèle afin
d'en tirer le maximum d'avantages. Parce que les techniques formelles demandent un effort
important, elles sont mieux appliquées à des problèmes complexes, qui ne peuvent être traités
par des méthodes plus simples.
Techniques de vérification et de validation - Analyse et méthodes informelles et
statiques
Rappelons les définitions suivantes de l'analyse informelle et statique comme techniques de
vérification et de validation :
 Techniques informelles de V&V : Les techniques informelles de V&V sont parmi

les plus couramment utilisées. Ils sont dits informels parce que leurs outils et leurs approches
reposent largement sur le raisonnement et la subjectivité humains sans formalisme
mathématique rigoureux.
 Techniques V&V statiques : Les techniques de V&V statique évaluent la précision

de la conception du modèle statique et du code source. Les techniques statiques ne
nécessitent pas l'exécution machine du modèle, mais l'exécution mentale peut être utilisée.
Les techniques sont très populaires et largement utilisées, et de nombreux outils automatisés
sont disponibles pour aider dans le processus V&V. Les techniques statiques peuvent révéler
une variété d'informations sur la structure du modèle, les techniques de modélisation
utilisées, les flux de données et de contrôle dans le modèle et la précision syntaxique.
Le principal avantage des techniques statiques est qu'elles ne nécessitent pas l'application
d'un système ou d'un logiciel fonctionnel : elles peuvent être appliquées à des documents et
des parties de logiciels. Ils peuvent donc être exécutés bien avant les techniques dynamiques,
qui nécessitent un système ou un logiciel fonctionnel pour leur exécution.
Le deuxième avantage des techniques statiques est qu'elles sont souvent moins chères que les
techniques dynamiques et que leur retour sur investissement est beaucoup plus élevé. Les
défauts étant identifiés plus tôt, leurs correctifs sont moins chers, et ils ne sont souvent pas du
tout introduits dans le logiciel, étant trouvés dans les documents de spécification.
Les techniques statiques peuvent être appliquées à de nombreux produits livrables, tels que
les composants logiciels, qu'ils puissent ou non être compilés, les spécifications de haut
niveau ou détaillées, les listes d'exigences, les contrats, les plans de développement ou de test,
ainsi qu'à de nombreux autres produits livrables. Les tests statiques peuvent ainsi être
exécutés très tôt dans le cycle de développement.
Les composants logiciels, qu'ils puissent être compilés ou non, peuvent être examinés à l'aide
de revues (revues de code) ou d'analyses statiques. Les autres éléments, tels que la
documentation, les exigences et les spécifications, les documents de conception d'essai, les
cas d'essai et les procédures d'essai, même les données d'essai, peuvent également être soumis
pour examen. Les plans de développement, les plans de test, les processus et les activités
commerciales peuvent également faire l'objet d'examens.
Les techniques de tests informelles et statiques sont des solutions efficaces et éprouvées pour
améliorer la qualité des logiciels.
Assurance de la qualité : L'assurance de la qualité (AQ) est un ensemble d'activités visant à

garantir que les produits répondent aux exigences des clients de manière systématique et
fiable. L'AQ est l'ensemble des activités que nous menons pour assurer une qualité correcte
lors du développement de nouveaux produits.
Types d'examens
L'Institute of Electrical and Electronics Engineering (IEEE) identifie plusieurs types

d'examens
 Revues de direction
 Examens techniques ;
 Inspections
 Visites guidées
 Audits.
Les examens peuvent être regroupés selon leur niveau de formalisme, du moins formel au
plus formel. Tous les examens ont un produit ou un processus auquel ils s'appliquent.
(Voir Bernard Homes, (2012) pour plus de détails pp. 94-)
Revues de direction
Les revues de direction ont pour but de suivre les progrès, de définir l'état d'avancement des
plans et du calendrier, ou d'évaluer l'efficacité des approches de gestion utilisées et leur
adéquation aux objectifs. Les examens de la direction permettent de déterminer la conformité
et les écarts par rapport aux plans ou aux procédures de gestion. Des connaissances
techniques peuvent être nécessaires pour gérer avec succès de tels types d'examens.
L'évaluation d'éléments ou d'objets peut nécessiter plus d'une seule réunion et les réunions
peuvent ne pas aborder tous les différents aspects du produit ou du procédé soumis à examen.
L'examen de la direction tient également compte des aspects de la faisabilité économique (c.-
à-d. l'évaluation de la rentabilité du logiciel).
Les revues de direction peuvent s'appliquer aux processus suivants (entre autres) :
- Processus d'acquisition et de livraison ;
- Processus de développement, d'utilisation et de maintenance ;
- Processus de gestion de la configuration ;
- Processus d'assurance qualité ;
- Processus de vérification et de validation, processus d'examen par les pairs et vérifications ;
- Processus de gestion et de résolution des problèmes et de gestion des défectuosités
Les revues de direction peuvent s'appliquer aux produits suivants (entre autres) :
- Rapports de défauts ;
- Rapports d'audit ;
- Plans de sauvegarde et de restauration, plans de restauration ;
- Exigences et spécifications techniques et commerciales ;
- Plans de performance du matériel et des logiciels ;
- Plans d'installation et d'entretien ;
- Rapports d'avancement ;
- Plans de gestion des risques ;
- Plans de gestion de la configuration ;
- Plans d'assurance de la qualité ;
- Plans de gestion de projet ;
Analyse des flux de données
Définition :
L'analyse des flux de données consiste à évaluer les variables et à vérifier si elles sont
correctement définies et initialisées avant leur utilisation (référencées).
L'analyse des flux de données le garantit :
 Les variables doivent être déclarées et utilisées (les variables doivent être déclarées
avant d'être utilisées)
 La variable doit être initialisée
 Les variables doivent être utilisées
Une variable est une zone de mémoire de l'ordinateur (un ensemble d'octets et de bits) à
laquelle un nom est associé (le nom de la variable). Lorsque la variable n'est pas utilisée, par
exemple avant le lancement du programme ou après la fin du programme, la zone mémoire
est affectée à un autre programme ou au système. Il peut donc contenir n'importe quelle
donnée, alphabétique ou numérique. Lorsque le programme a besoin de la variable, une zone
de mémoire est allouée, mais n'est pas toujours initialisée. Le contenu de la zone mémoire
n'est donc pas garanti. Pour s'assurer que la zone de mémoire contient des données valides, il
est important de l'initialiser avec une valeur adéquate. Certains langages de programmation
initialisent automatiquement les variables lorsqu'elles sont déclarées, d'autres pas. De même,
certains langages de programmation allouent dynamiquement des variables (et leur type,
numérique ou alphanumérique) lors de leur identification, par exemple lors de leur première
utilisation dans le code. Nous pourrions donc avoir deux variables avec des noms similaires
"NOM" et "N0M" (ici le chiffre 0 au lieu de la lettre O), qui pourraient être considérées
identiques lorsqu'elles sont lues par le développeur mais qui sont définies comme deux
variables différentes par l'ordinateur. Nous pourrions également faire identifier le défaut ci-
dessous :
Erreurs de programme/erreurs de logiciel/bogues de logiciel

Une erreur dans un programme, qu'elle soit due à des erreurs d'exigences, de conception ou
de codage, est appelée un bogue.
Erreur : Une erreur se produit lorsque le comportement d'un système n'est pas conforme à
celui prescrit dans le document d'exigences specification
L'erreur ci-dessus definition de l'erreur suppose que le specification donné est acceptable pour
le client. Toutefois, si le specification ne répond pas aux attentes du client, alors, bien sûr,
même une implémentation sans faille ne parvient pas à satisfaire le client.
- Un bogue logiciel est une erreur , un défaut, une défaillance, un défaut ou un défaut d'un
programme ou d'un système informatique qui produit un résultat ou des causes incorrects ou
inattendus.
Toute approche en matière de tests est fondée sur des hypothèses quant à la façon dont les
erreurs du programme se produisent. Les erreurs sont dues à deux raisons principales :
- Les erreurs sont dues à une mauvaise compréhension de toutes les conditions auxquelles un
programme doit faire face, ce qui entraîne des erreurs d'exigences, de conception ou de
codage.
- Des erreurs se produisent parce que nous ne nous rendons pas compte que certaines
combinaisons de conditions nécessitent des traitements spéciaux.
Certains types d'erreurs majeures peuvent être vérifiés. Les erreurs de programme sont
classées comme :
 Erreurs de syntaxe -- Une erreur de syntaxe est une instruction de programme qui
viole une ou plusieurs règles de la langue dans laquelle elle est écrite (langue
d'implémentation), c'est-à-dire une violation des règles de grammaire de la langue,
généralement détectée par le compilateur, et signalée par des messages d'erreur du
compilateur. Par exemple
- Il manque un appareil orthodontique : Si les accolades ne se produisent pas dans
les paires correspondantes, le compilateur indique une erreur.
- L'omission du type de valeur de retour dans une définition de fonction provoque
une erreur de syntaxe si le prototype de fonction spécifie un type de retour autre
que int.
- Oublier de retourner une valeur d'une fonction qui est censée retourner une valeur
peut conduire à des erreurs inattendues.
- Retourner une valeur pour une fonction dont le type de retour a été déclaré nul
entraîne une erreur de syntaxe.
- Définir une fonction dans une autre fonction est une erreur de syntaxe
 Erreur logique - Une erreur logique se produit lorsqu'un programme produit des
résultats incorrects, c'est-à-dire qu'un programme qui compile et s'exécute
normalement peut ne pas faire ce que vous voulez.
Les défauts logiques peuvent être divisés en trois catégories :
- Erreurs d'exigences : Cela signifie que les besoins réels du client ne sont pas pris
en compte.
- Erreurs de conception : Si vous avez résolu le mauvais problème, vous avez une
erreur de conception. Les erreurs de conception surviennent lorsque les
spécifications ne correspondent pas au problème à résoudre.
- Erreurs d'implémentation : Il s'agit d'un manquement à une exigence comprise.

-
 Erreurs d'exécution -- un programme qui compile peut mourir en cours d'exécution
avec un message d'erreur d'exécution qui peut être utile ou non. Les erreurs
d'exécution résultent d'hypothèses incorrectes, d'une compréhension incomplète du
langage de programmation ou d'erreurs imprévues de l'utilisateur. Par exemple, des
erreurs telles que des erreurs de division par zéro peuvent se produire lors de
l'exécution d'un programme, de sorte que ces erreurs sont appelées erreurs d'exécution
ou erreurs de temps d'exécution. La division par zéro est généralement une erreur fata,
c'est-à-dire une erreur qui provoque l'arrêt immédiat du programme sans avoir exécuté
son travail avec succès.
 Erreurs sémantiques, etc.
Figure 1
Avec référencé à la figure 1, que se passera-t-il si la propriété de chaîne de connexion n'est
pas bien définie ? Un message d'erreur apparaîtra indiquant le type d'erreur syntaxique (par
exemple le type de données omis) et le programmeur devra déboguer (Identifier le point
défectueux, Isoler le point défectueux et réparer le point défectueux).
Tests dans le cycle de vie du développement logiciel
Question : Quelles sont les différences entre la durée de vie de développement logiciel
(SDLC) et le cycle de vie de test logiciel (STLC) ?
Qu'est-ce qu'un Test case ?
Test case
Test Case est simplement une entrée de données dans un produit logiciel.
Test Suit ou Test Set est un ensemble de Test case ou simplement une collection de Test
case.
Une définition commune d'un Test case est une description des conditions et des résultats
escomptés qui sont pris ensemble pour tester pleinement une exigence ou un cas d'utilisation.
Dans ce cours, j'autorise la description de plusieurs exigences dans un seul scénario de test et
je peux limiter un Test case à une partie d'un cas d'utilisation, comme un flux d'événements.
Les cas d'essai écrits devraient comprendre une description de la fonctionnalité à mettre à
l'essai et de la préparation requise pour s'assurer que l'essai peut être effectué. (Entrée test)
Un Test case est défini par un environnement de départ, des données d'entrée, des actions et
des résultats attendus, qui comprennent les données attendues et l'environnement résultant.
Un Test case est composé des valeurs du Test case, des résultats attendus, des valeurs de
prefix (conditions préalables) et des valeurs de postfix (post-condition) nécessaires pour
une exécution et une évaluation complètes du logiciel testé.
Critères de sélection des Test case
Il y a trois critères pour la sélection des Test case :
 Spécification d'un critère pour l'évaluation d'un ensemble de valeurs d'entrée.
(c.-à-d. spécification d'un critère de validation de toutes les entrées dans le logiciel
basé sur la validation de la spécification de l'exigence parce que toutes les exigences
DOIVENT être validées avant de procéder à tout développement logiciel) (Critères de
validation de la spécification de l'exigence RSV)
 Génération d'un ensemble de valeurs d'entrée qui satisfont un critère donné.

 Les cas de test doivent être écrits pour des conditions d'entrée invalides et valides.
N/B : Un bon cas de test est un cas qui a une forte probabilité de détecter une erreur non
découverte. La vérification de la validité et de l'invalidité des données d'entrée est une
condition nécessaire à la sélection des cas ; il est donc impossible d'effectuer des tests
exhaustifs.
Chaque cas de test nécessite une documentation appropriée, de préférence dans un format
fixe. Le format de la conception de votre scénario de test est très important. Il existe de
nombreux formats ; un format est suggéré ci-dessous :
Nous utiliserons un format particulier pour nos cas de test, comme le montre le tableau 1.
Tableau 1 : Exemple de format de Test case
Test ID Valise de test Test d'entrée Résultat prévu

Description (Valeur du scénario
de test)
Les essais doivent être défensifs (essais défensifs), c.-à-d. des essais qui comprennent des
essais dans des conditions normales et anormales.
Afin de vérifier pleinement que toutes les exigences d'une demande sont satisfaites, il doit y
avoir au moins deux cas de test pour chaque exigence : un test positif et un test négatif. Si une
exigence a des sous-exigences, chaque sous-exigence doit avoir au moins deux cas de test.
Procédures d'essai
Les procédures de test décrivent les activités spécifiques prises par un testeur pour configurer,
exécuter et analyser un test. Cela comprend la définition des valeurs des données, des fichiers
d'entrée et de sortie, des tests automatisés à exécuter et des activités de test manuelles
détaillées.
La procédure de test est un document spécifiant une séquence d'actions pour l'exécution d'un
test. Aussi connu sous le nom de script de test ou script de test manuel.
- Comment configurer l'environnement de test
-Où trouver les ensembles de données d'essai ?
-Où les mettre ?
-les étapes d'exécution des tests, et
-Que faire avec les résultats des tests ?
Les procédures de test peuvent être écrites pour des tests manuels, des tests automatisés ou
une combinaison des deux. Ils ne sont généralement nécessaires que si les tests sont
complexes.
Scripts de test
Un script de tests est ce qui est utilisé pour tester la fonctionnalité d'un système logiciel. Ces
scripts peuvent être manuels ou automatisés.
Les scripts de test manuels sont généralement des scripts écrits que le testeur doit exécuter.
Cela implique une interaction directe entre le testeur et le système testé. Les scripts de test
manuels spécifient les instructions étape par étape de ce que le testeur doit entrer dans le
système et les résultats attendus. Souvent, les scripts sont intégrés dans les procédures de test.
Les scripts de test automatisés sont des logiciels écrits pour tester le système. Ceux-ci
peuvent être générés avec des outils ou codés à l'ancienne. Habituellement, un langage de
script est utilisé pour contrôler l'exécution des tests de manière ordonnée. Ces tests sont
généralement initiés par les testeurs et sont référencés dans les procédures de test.
Listes de test :
Les listes de test sont un moyen de rassembler les tests unitaires en groupes logiques. Les
principaux avantages de l'ajout de tests unitaires à une liste de test sont que vous pouvez
exécuter des tests à partir de plusieurs fichiers de test unitaires, vous pouvez les exécuter dans
le cadre d'une compilation, et vous pouvez utiliser les listes pour appliquer une politique
d'archivage. Pour plus d'informations sur les listes de test
Plans de test :
Il s'agit de documents qui expliquent comment vous allez tester le système afin de le prouver
et quelles activités seront suivies pour accomplir le travail. Le niveau de formalité et de détail
de ces plans peut varier. Nous entrerons dans la planification du test en détail plus tard dans
ce cours avec l'accent sur la planification juste assez.
La planification des essais doit se faire tout au long du cycle de développement, en particulier
au début du cycle de développement. Un plan d'essai est un document décrivant la portée,
l'approche, les ressources et le calendrier des activités d'essai prévues. Il identifie les éléments
de test, les caractéristiques à tester, les tâches de test, qui effectuera chaque tâche, et tout
risque nécessitant des plans d'urgence. Un élément important du plan de test est constitué par
les cas de test individuels. Un cas de test est un ensemble d'entrées de test, de conditions
d'exécution et de résultats attendus développés pour un objectif particulier, tel que l'exercice
d'une trajectoire de programme particulière ou la vérification de la conformité à une exigence
spécifique.
Rédigez le plan d'essai au début du cycle de développement, alors que les choses se déroulent
généralement encore assez bien et calmement. Cela vous permet de réfléchir à un ensemble
complet de cas de test. Si vous attendez jusqu'à la fin du cycle pour écrire et exécuter des
scénarios de test, vous risquez d'être dans une période très chaotique et précipitée. Souvent,
les bons cas de test ne sont pas écrits dans cet environnement précipité, et des tests ad hoc ont
lieu. Avec les tests ad hoc, les gens commencent simplement à essayer tout ce à quoi ils
peuvent penser sans aucune feuille de route rationnelle à travers les exigences du client. Les
tests effectués de cette manière ne sont pas reproductibles.
Il est essentiel, lors des essais, de commencer la planification dès que l'artefact nécessaire est
disponible. Par exemple, dès que l'analyse des besoins du client est terminée, l'équipe d'essai
devrait commencer à rédiger des cas de test de boîtes noires en fonction de ce document. En
le faisant si tôt, les testeurs pourraient se rendre compte que les exigences ne sont pas
complètes. L'équipe peut poser des questions au client pour clarifier les exigences afin qu'un
cas de test spécifique puisse être rédigé. La réponse à la question est également utile pour le
développeur de code. De plus, le testeur peut demander (au programmeur) que le code soit
conçu et développé pour permettre une exécution de test automatisée. En résumé, plus les
tests sont planifiés tôt à tous les niveaux, mieux c'est.
Il est également très important de considérer la planification et l'exécution des tests comme
des processus itératifs. Dès que la documentation des exigences est disponible, il est
préférable de commencer à rédiger des cas de test fonctionnel et de test du système. Lorsque
les exigences changent, réviser les cas de test. Dès qu'un code est disponible, exécutez les cas
de test. Lorsque le code change, exécutez à nouveau les scénarios de test. En connaissant le
nombre et le type de cas de test réellement exécutés, vous pouvez suivre avec précision
l'avancement du projet. Dans l'ensemble, les tests doivent être considérés comme un élément
itératif et essentiel de l'ensemble du processus de développement.
Sources d'information pour la sélection des causes types
La conception des cas types est restée au centre des préoccupations du milieu de la recherche
et des praticiens. Un processus de développement logiciel génère un grand nombre
d'informations, telles que les exigences specification, le document de conception et le code
source. Afin de générer des tests efficaces à moindre coût, les concepteurs de tests analysent
les sources d'information suivantes :
 Document de spécification des exigences (DSR)

 Code source
 Conception conceptuelle
 Modèle de défaillance
 Heuristique
(1) Document de spécification des exigences logicielles (SRD) : Le processus de

développement de logiciels commence par la prise en compte des besoins des utilisateurs. La
nature et la quantité des besoins des utilisateurs identified au début du développement du
système variera en fonction de la méthodologie de développement du logiciel specific
utilisée. Prenons quelques exemples. Dans la méthodologie traditionnelle de développement
de logiciels utilisant l'approche Waterfall, un ingénieur d'exigences tente de saisir la plupart
des exigences avant de s'engager dans le processus de développement. D'autre part, dans une
Méthodologie de Développement Logiciel Agile, telle que XP ou Scrum, les exigences
identified au début du projet de développement logiciel peuvent être redéfinies en versions
itérative et incrémentielle du produit logiciel.
Les exigences auraient pu être specified d'une manière informelle, comme une combinaison
de texte en clair, d'équations, figures, et flowcharts. Bien que cette forme d'exigences
specification puisse être ambiguë, elle est facilement compréhensible par les clients. Pour
certains systèmes, les exigences peuvent être saisies sous forme de cas d'utilisation, de
diagrammes entité-relation, de diagrammes de classes, etc. Parfois, les exigences d'un
système peuvent avoir été specified dans un langage ou une notation formelle, comme Z,
SDL, Estelle, ou finite-state machine. Le specifications informel et le specifications formel
sont tous deux des sources principales de cas de test.
Dans les tests de boîtes noires, les cas de test sont générés à partir de la spécification des
exigences.
(2) Code source : Alors qu'une exigence specification décrit le comportement prévu d'un
système, le code source décrit le comportement réel du système. Les hypothèses et les
contraintes de haut niveau se concrétisent dans une mise en œuvre. Bien qu'un concepteur de
logiciel puisse produire une conception détaillée, les programmeurs peuvent introduire des
détails supplémentaires dans le système. Par exemple, une étape de la conception détaillée
peut être "trier tableau A". Pour trier un tableau, il existe de nombreux algorithmes de tri
ayant des caractéristiques différentes, comme l'itération, la récursivité et l'utilisation
temporaire d'un autre tableau. Par conséquent, les cas de test doivent être conçus en fonction
du programme.
Dans les tests en boîte blanche, les cas de test sont générés à partir du code source.
(3) Modèle de défaillance : Les défauts précédemment rencontrés sont d'excellentes

sources d'information pour la conception de nouveaux cas de test. Les défauts connus sont
classified en différentes classes, telles que les défauts d'initialisation, les défauts logiques et
les défauts d'interface, et stockés dans un référentiel. Les ingénieurs de test peuvent utiliser
ces données lors de la conception des tests pour s'assurer qu'une classe particulière de défauts
n'est pas présente dans le programme.
Il existe trois types de tests basés sur les défaillances : la devinette d'erreur,
l'ensemencement de fautes et l'analyse de mutation.
- En devinant les erreurs, un ingénieur d'essai applique son expérience pour (i) évaluer la
situation et deviner où et quels types de défauts peuvent exister, et (ii) concevoir des tests
pour specifically exposer ces types de défauts.
- Lors de l'ensemencement de fautes, les fautes connues sont injectées dans un programme et
la suite de tests est exécutée pour évaluer l'efficacité de la suite de tests. L'ensemencement de
fautes suppose qu'une suite de tests que finds a ensemencé des fautes est également
susceptible de provoquer d'autres fautes.
- Test de mutation : Un logiciel de haute qualité ne peut se faire sans des tests de haute
qualité. Les tests de mutation mesurent la " bonne " qualité de nos tests en insérant des
défauts dans le programme testé. Chaque défaut génère un nouveau programme, un mutant
légèrement différent de l'original. Les tests de mutation mesurent la qualité des cas de test.
L'analyse de mutation est similaire à l'ensemencement de défauts, sauf que des mutations
dans les énoncés de programme sont effectuées afin de déterminer la capacité de détection
des défauts de la suite de tests. Si les cas de test ne sont pas capables de révéler de tels
défauts, l'ingénieur de test peut spécifier des cas de test supplémentaires pour révéler les
défauts. Le test de mutation est basé sur l'idée de simulation de défaut, alors que
l'ensemencement de défaut est basé sur l'idée d'injection de défaut. Dans l'approche
d'injection de fautes, un défaut est inséré dans un programme, et un oracle est disponible pour
affirmer que le défaut inséré a effectivement rendu le programme incorrect. En revanche,
dans la simulation d'erreur, un programme modification n'est pas garanti qu'il conduise à un
programme défectueux. Dans la simulation d'erreur, on peut modifier un programme
incorrect et le transformer en un programme correct.
(4) Heuristique, c'est-à-dire de raisonnement humain.
Suivi des incidents
Un système de suivi des incidents permet de suivre les incidents qui devraient être corrigés au
cours du processus de développement afin que tous les incidents soient correctement résolus :
- Aucun incident ne sera laissé au hasard sur les caprices d'un seul programmeur.
Limitation des tests de logiciels
Les tests de logiciels ne peuvent montrer que la présence d'erreurs et non leur absence.
C'est la principale limitation des tests de logiciels, car elle ne peut régler la question de
l'exactitude des programmes. En d'autres termes, en testant un programme avec un sous-
ensemble approprié du domaine d'entrée et en n'observant aucun défaut, nous ne pouvons pas
conclure qu'il n'y a plus de défauts dans le programme.
Bien que les essais ne puissent régler la question de l'exactitude du programme, différentes
méthodes d'essai continuent d'être mises au point. Par exemple, il existe des méthodes d'essai
fondées sur des spécifications et des méthodes d'essai fondées sur des codes. Il est important
de développer une théorie pour comparer la puissance des différentes méthodes de test.
Un système logiciel subit de multiples cycles de test, de correction et de re-test jusqu'à ce

que, idéalement, plus aucun défaut ne soit révélé. Les défauts sont corrigés en modifiant le
code ou en ajoutant un nouveau code au système. A ce stade, il peut être nécessaire de
concevoir de nouveaux cas de test. Lorsqu'il n'y a plus de défauts, nous pouvons conclure de
cette façon : soit il n'y a pas de défaut dans le programme, soit les tests n'ont pas pu révéler
les défauts. Comme nous n'avons aucun moyen de connaître la situation exacte, il est utile
d'évaluer l'adéquation de l'ensemble de tests.
Il n'est pas nécessaire d'évaluer l'adéquation des tests tant qu'ils révèlent des défauts. Deux
façons pratiques d'évaluer l'adéquation du test sont l'ensemencement de fautes et la mutation
du programme.
- L'ensemencement défectueux est le processus d'insertion des défectuosités dans un

programme.
- Le test de mutation est une méthode systématique d'ensemencement de défauts.
- Introduisez une seule faute à la fois pour créer des "mutants" du programme original.
Chaque défaut inséré entraîne un nouveau programme appelé Program Mutation. Appliquer
un ensemble de tests à chaque programme mutant.
L'"adéquation du test" est mesurée par le pourcentage de "mutants tués".
- Exécuter le programme P sur l'ensemble de test T
- P est considéré comme le programme "correct
- Enregistrer les résultats R pour servir d'appel oracle Tester Oracle
- Chaque défaut inséré entraîne un nouveau programme appelé Programme Mutant :

Programmes mutants = P1, P2, P3, ...., Pn
Les tests doivent couvrir "toutes" les fonctionnalités :
 toutes les méthodes publiques (test de la boîte noire)

 toutes les caractéristiques
 toutes les situations limites (Boundary Value Analysis (BVA))
 scénarios courants
 scénarios exceptionnels
 chaque ligne de code (test des boîtes blanches)
 chaque chemin à travers le code
Ce n'est pas parce que tous vos tests sont verts que votre code est correct et exempt de bugs.
Cela ne signifie pas non plus que les tests sont inutiles (sans succès) ! Une bonne stratégie
consiste à ajouter de nouveaux cas de test chaque fois qu'un nouveau bogue est découvert. Le
scénario de test doit démontrer la présence du bogue. Quand le test est vert, vous savez que
cette instance particulière du bogue a disparu. Rédiger un nouveau test pour le bogue qui (i)
documente le bogue, (ii) vous aide à le déboguer, et (iii) garantit que le bogue sera signalé s'il
réapparaît un jour.
N/B : Une théorie permettant de comparer la puissance des méthodes d'essai en fonction
de leurs capacités de détection de défauts est un bon domaine de recherche.
Question : Comparez le test de mutation à d'autres approches de test avec détection de fautes.
Répondez : Les tests de mutation nécessitent généralement beaucoup plus de cas de test que
les autres méthodes.
TD 1 et TD 2 Questions : (ICT 304)
1. Expliquer le concept de test logiciel et donner deux raisons pour effectuer un test
logiciel. Quelles sont les causes des pannes logicielles ? Des tests exhaustifs sont-ils
possibles ?
2. Expliquer les concepts suivants tels qu'ils sont utilisés dans les tests logiciels :
Bugs logiciels, Tests défensifs, Ensemencement de fautes, Tests de mutations, Test
Oracle, Script de test, combinaison de test, erreur de programme
3. Définissez les termes suivants tels qu'ils sont utilisés dans les tests logiciels, énumérez
la signification de chaque terme et, par conséquent, indiquez clairement à quel stade du
cycle de vie du développement logiciel se trouve le logiciel chacun s'appliquent :
(i) Vérification (ii) Validation (iii) Essais statiques (iv) Essais dynamiques
Qu'entendez-vous par le terme Cas d'essai, en utilisant le système de guichet
automatique bancaire (GAB), produire un document de cas d'essai pour le système.
5. En ce qui concerne la question quatre (4) ci-dessus, définissez les exigences
fonctionnelles et non fonctionnelles et donnez donc cinq exemples dans chaque
cas.
6. Distinguez les concepts suivants :
(a) Test et débogage
(b) Tests de régression et tests d'intégration
(c) Cycle de vie du développement logiciel (SDLC) et cycle de vie des tests
logiciels (STLC)
7. Les tests structurels et fonctionnels sont deux catégories de tests fondamentaux.

Énumérez quatre (4) techniques dans chaque catégorie.
8. a) Expliquer la notion de critère de sélection dans la conception des essais.

b) Expliquer les concepts d'un critère valide et fiable.
(c) Expliquer cinq types d'erreurs de programme à l'aide de cinq exemples dans
chaque cas.
9. Énoncer trois critères pour le choix des cas d'essai
10. Quelles sont les différences entre les essais dynamiques et les essais statiques ?
11. Vous trouverez ci-dessous quatre programmes défectueux. Chacun d'entre eux
comprend un cas de test qui entraîne une défaillance du logiciel. Répondez aux questions
suivantes au sujet de chaque programme.
(i) Identifier le défaut.

(ii) Si possible, identifier un cas de test qui n'exécute pas le défaut.
(iii) Réparer le défaut et vérifier que le test donné donne maintenant les résultats
escomptés
EXPOSÉ 2 : MÉTHODOLOGIES D'ESSAI DES LOGICIELS
Que sont les méthodologies de test logiciel ?
Les méthodologies de test de logiciels sont les différentes approches permettant de s'assurer
qu'une application logicielle est entièrement testée. Celles-ci englobent tout, des tests
frontaux jusqu'aux tests back-end.
Les méthodologies de test de logiciels sont les diverses stratégies ou approches utilisées pour
tester une application afin de s'assurer qu'elle se comporte et se présente comme prévu.
Celles-ci englobent tout, des tests frontaux jusqu'aux tests back-end.
Les méthodologies de test de logiciels englobent tout, des tests unitaires de modules
individuels, des tests d'intégration d'un système entier aux formes spécialisées de test telles
que la sécurité et la performance.
Importance des méthodes d'essai
Comme les applications logicielles deviennent de plus en plus complexes et interdépendantes

et avec le grand nombre de plates-formes et d'appareils différents qui doivent être testés, il est
plus important que jamais d'avoir une méthodologie de test robuste pour s'assurer que les
produits/systèmes logiciels en développement ont été entièrement testés pour s'assurer qu'ils
répondent à leurs exigences spécifiques et peuvent fonctionner avec succès dans tous les
environnements prévus avec la convivialité et la sécurité nécessaires.
L'objectif de l'utilisation de nombreuses méthodologies de test dans votre processus de

développement est de vous assurer que votre logiciel peut fonctionner avec succès dans de
multiples environnements et sur différentes plateformes.
Types de méthodologies de test de logiciels
Fondamentalement, il existe deux principaux types de méthodologies de test de logiciels. Ils

incluent :
(A) Essais structuraux ou essais en boîte blanche (essais dynamiques)

(B) Test fonctionnel ou test de boîte noire (test statique)
Definition 1 :
Essais statiques : Tester sans exécuter le programme. Cela comprend l'inspection des
logiciels et certaines formes d'analyse.
Definition 2 :
Essais dynamiques : Test en exécutant le programme avec des entrées réelles.
La représentation schématique des méthodes de test des logiciels est présentée ci-dessous :
Méthodologies de test des logiciels
Essais structuraux Tests fonctionnels

(Test de la boîte blanche) (Black-Box Testing)
Types de tests de boîtes
Types de tests de boîtes
noires
blanches
- Essais de performance
- Test unitaire
(1) Essai en charge
- Test d'intégration
(2) Tests de tension
- Test du système
- Test d'utilisabilité
- Tests d'acceptation
- Test d'aptitude à
- Test de régression
l'apprentissage
- Test bêta
- Test de mémorisation
-Test de fiabilité
- Test de compatibilité
Techniques d'essai des - Test de portabilité
boîtes blanches - Tests de sécurité
- Essai de débit de contrôle
- Test de flux de données Techniques d'essai des
boîtes noires
- Équivalence
Partitionnement
Critères de couverture -Analyse de la valeur limite
-Critère de couverture du sillon -Essais comportementaux
-Critère de couverture de -Tests aléatoires
l'énoncé Critère -Deviner l'erreur
-Critère de couverture de l'état -Tests de cas d'utilisation
de santé
ESSAIS STRUCTURAUX / ESSAIS DE BOÎTES BLANCHES
Les tests structurels ou les tests de boîtes blanches impliquent de tester la spécification des
exigences de l'application. Il intègre tous les types de tests conçus pour garantir que chaque
partie d'un logiciel se comporte comme prévu en utilisant les cas d'utilisation fournis par
l'équipe de conception ou l'analyste commercial.
Dans les tests en boîte blanche, le système testé n'est PAS traité comme une boîte noire parce
que :
- Dans White Box Testing, nous testons le logiciel du point de vue du développeur,
- Dans White Box Testing, les données des cas de test sont générées à partir du code
source et de la structure interne du programme. Cela nécessite la connaissance du
langage de programmation utilisé.
Quelques synonymes de test de boîte blanche sont :
1) Essai en boîte de verre

2) Test des boîtes transparentes
3) Test des boîtes ouvertes
4) Test des boîtes transparentes
5) Essais de structure
6) Essais logiques
7) Tests basés sur la conception
Objectifs/importance du test de la boîte blanche

 Tests de boîtes blanches : Le test de la boîte blanche se concentre sur la structure
interne du système testé. Les chemins à travers le logiciel sont identifiés et testés.
Pour ce faire, il faut connaître le langage de programmation utilisé.
Ces objectifs peuvent-ils être atteints sans limites ? Non. Quelles sont donc les limites du
test de la boîte blanche ?
La limitation du test des boîtes blanches
Les limites du test des boîtes blanches sont les suivantes :
 Les développeurs testent souvent avec l'intention de prouver que le code fonctionne
plutôt que de prouver que ça ne marche pas
 Les développeurs ont tendance à sauter les types plus sophistiqués de tests en boîte
blanche (p. ex. tests d'état, tests de flux de données, tests en boucle, etc.), en
s'appuyant surtout sur la couverture en ligne
 Il y a plusieurs types d'erreurs que les tests en boîte blanche ne trouveront pas :
Bugs de synchronisation et de concomitance
Problèmes de performance (par exemple, trafic réseau,
Problèmes d'utilisabilité
Niveaux de test de la boîte blanche

Les méthodes d'essai des boîtes blanches sont habituellement effectuées dans l'ordre et
comprennent :
 Test unitaire
 Test d'intégration
 Test du système
 Tests d'acceptation
 Test de régression
Le test de la boîte blanche (aussi connu sous le nom de test transparent, de boîte de verre ou
de structure) est une technique de test qui permet d'évaluer le code et la structure interne du
programme.
Les tests de la boîte blanche se concentrent sur la structure interne du système testé. Les
chemins à travers le logiciel sont identifiés et testés. Pour ce faire, il faut connaître le langage
de programmation utilisé.
Dans White Box Testing, nous testons le logiciel du point de vue des développeurs.
Les tests interviennent à chaque étape du cycle de vie du logiciel (cycle de vie du
développement du système), mais les tests effectués à chaque niveau du développement du
logiciel sont de nature différente et ont des objectifs différents.
 Test unitaire
Le test unitaire est le premier niveau de test et est souvent effectué par les développeurs eux-
mêmes. C'est le processus qui consiste à s'assurer que les composants individuels du logiciel
fonctionnent comme ils ont été conçus.
La partie test unitaire d'une méthodologie de test consiste à tester les modules ou composants
logiciels individuels qui constituent une application ou un système. Les tests unitaires sont
effectués sur des modules individuels du code source. Ce qui constitue une unité dépend de
ce qui est construit et de la méthodologie utilisée. Par exemple, dans le développement
orienté objet, une classe peut être considérée comme la plus petite unité à tester.
But : S'assurer que chaque composante fonctionne séparément. Les développeurs effectuent
des tests unitaires pour s'assurer que le composant qu'ils construisent fonctionne.
 Test d'intégration
Le test d'intégration consiste à tester différents modules/composants qui ont été testés avec
succès. Ce type de test est effectué lors de l'intégration des modules logiciels. Le test
d'intégration est effectué lorsque deux ou plusieurs unités testées sont combinées dans une
structure plus grande.
Le test d'intégration est effectué lorsque deux ou plusieurs unités testées sont combinées dans
une structure plus grande.
Les tests d'intégration impliquent une intégration descendante, une intégration ascendante et
une intégration hybride.
Intégration descendante : Développer le squelette du système et le remplir de composants.
Intégration ascendante : Intégrer des composants d'infrastructure puis ajouter des

composants fonctionnels.
L'intégration ascendante commence par l'intégration des composants de niveau inférieur,
suivie de l'intégration des composants de niveau supérieur, pour finir avec les composants de
niveau supérieur. Cela nécessitera la conception d'un certain nombre de moteurs pour piloter
chacun de ces niveaux d'intégration.
Intégration hybride : Il s'agit d'une combinaison d'intégration descendante et d'intégration

ascendante.
Objectif : Tester la compatibilité avec les autres modules.
 Test du système
Le test de système est le processus qui consiste à tester un système complètement intégré
pour vérifier qu'il répond aux spécifications de ses exigences. Ici, le test de bout en bout de
l'ensemble du système est établi.
La partie test du système d'une méthodologie de test consiste à tester l'ensemble du système à
la recherche d'erreurs et de bogues. Ce test est effectué en connectant les composants
matériels et logiciels de l'ensemble du système (qui ont été précédemment testés en unité et
en intégration), puis en le testant dans son ensemble. Ce test est répertorié sous la méthode de
test de la boîte noire, où le logiciel est vérifié pour les conditions de travail prévues par
l'utilisateur ainsi que les conditions d'exception et les conditions de bord potentielles.
Tester le comportement de l'ensemble du logiciel avec différents systèmes d'exploitation ou
différents périphériques matériels
Tester le logiciel dans un environnement adapté à l'environnement opérationnel.
Lors des tests du système, la fonctionnalité, les performances, la fiabilité et la sécurité de

l'ensemble du système sont vérifiées.
But :
Le test du système tend à confirmer la qualité de bout en bout de l'ensemble du système. Le
test du système est souvent basé sur les spécifications fonctionnelles/besoins du système. Les
attributs de qualité, tels que la portabilité, la fiabilité, la sécurité et la maintenabilité, sont
également vérifiés.
Ce type d'essai est habituellement effectué sur scène (c.-à-d. dans l'environnement de
l'utilisateur).
 Tests d'acceptation
Les essais d'acceptation font partie d'une méthodologie d'essai qui permet de s'assurer que les
spécifications du logiciel ont été respectées et que les utilisateurs finaux et les clients ont testé
le système pour s'assurer qu'il fonctionne comme prévu et répond à toutes leurs exigences
définies.
Ce type de test est généralement effectué sur l'environnement du développeur et sur

l'environnement du client.
Les tests d'acceptation peuvent avoir lieu à différents niveaux de la vie d'un logiciel :
- Lors de la conception du logiciel ;
- Lorsque le logiciel est intégré à d'autres logiciels ;
- Lorsque le logiciel est acquis par un nouveau client ;
- Pour l'acceptation de nouvelles fonctionnalités ou caractéristiques.
 TEST DE RÉGRESSION
- Le test de régression est le processus de re-test d'un logiciel qui a été modifié.
- Le test de régression est un type de test logiciel qui est effectué chaque fois que le système
est changé ou modifié.
- Le test de régression est le processus de validation des modifications introduites dans un
système pendant la maintenance logicielle.
- Le test de régression est la (ré)exécution d'une version incrémentale d'un produit logiciel.
- Le test de régression est fondamental pour la maintenance du logiciel, car il doit garantir
que les modifications apportées au logiciel ont été effectuées correctement et qu'elles n'ont
pas affecté les parties du logiciel qui étaient en ordre.
Un test de régression permet une validation cohérente et répétable de chaque nouvelle version
d'un produit. Ces tests permettent de s'assurer que les défauts signalés ont été corrigés pour
chaque nouvelle version et qu'aucun nouveau problème de qualité n'a été introduit dans le
processus de maintenance. Bien que les tests de régression puissent être effectués
manuellement, une suite de tests automatisée est souvent utilisée pour réduire le temps et les
ressources nécessaires pour effectuer les tests requis. Ce type de test est utilisé lors de la
livraison incrémentale du produit logiciel.
But :
- S'assurer que les changements apportés au système n'ont pas introduit de nouvelles
erreurs.
- Trouver et éliminer les défauts nouvellement introduits.
- L'objectif est de gérer le risque qu'un changement corrige un problème connu ou qu'il
n'ait pas causé la panne d'une zone de travail antérieure de l'application.
Les modules sont testés séparément.

Test unitaire But : S'assurer que chaque composante fonctionne séparément.
Test entre les composants.

Test d'intégration Objectif : Tester la compatibilité avec les autres modules.
Tester le comportement de l'ensemble du logiciel avec différents

systèmes d'exploitation ou différents périphériques matériels. Je teste
Test du système
tout le système.
Objectif : Le test du système tend à confirmer la qualité de bout en
bout de l'ensemble du système. (Portabilité, sécurité, fiabilité
Vérifie si les spécifications du logiciel ont été respectées. Effectué sur

Tests d'acceptation l'environnement du développeur et de l'environnement du client
Objectif : Gagner la confiance dans le logiciel
Logiciel de re-test qui a été modifié. Test effectué chaque fois que le
système est changé ou modifié.
Test de régression Objectif : Récupérer tous les nouveaux bogues introduits par de
nouvelles modifications.
TEST DE FONCTIONNEMENT / TEST DE BOÎTE NOIRE
Le test fonctionnel, également connu sous le nom de black testing, est un processus
d'assurance qualité qui base ses cas de test sur les spécifications du composant logiciel à
tester. Les tests fonctionnels permettent de s'assurer que les exigences sont correctement
satisfaites par l'application.
Dans la plupart des méthodes d'essai, l'essai fonctionnel consiste à tester l'application par
rapport aux exigences opérationnelles. Les essais structuraux sont effectués à l'aide des
spécifications fonctionnelles fournies par le client ou à l'aide des spécifications de
conception, comme les cas d'utilisation fournis par l'équipe de conception.
D'autre part, le test fonctionnel consiste à tester l'application par rapport aux exigences non
fonctionnelles, ce qui implique généralement de mesurer/tester l'application par rapport à des
qualités techniques définies, par exemple : vulnérabilité, évolutivité, convivialité. Quelques
exemples de tests non fonctionnels sont décrits ci-dessous :
Le test de boîte noire se réfère au test d'un logiciel sans rien connaître de son fonctionnement
interne - Ceci n'exige pas la connaissance du langage de programmation utilisé.
Dans Black Box Testing, le système testé est en fait traité comme une boîte noire parce que :
- Dans Black Box Testing, nous testons le logiciel du point de vue de l'utilisateur,
- Dans les tests de boîte noire, les données des cas de test sont dérivées uniquement de
la spécification des exigences (c'est-à-dire sans connaissance de la structure interne du
programme). Cela ne nécessite pas la connaissance du langage de programmation
utilisé.
Objectifs/importance du test de la boîte noire
 Les tests de boîtes noires jouent un rôle important dans les tests de logiciels, ils aident
à la validation globale de la fonctionnalité du système. Les tests de boîtes noires sont
effectués en fonction des besoins des clients, de sorte que toute exigence incomplète
ou imprévisible peut être facilement identifiée et peut être traitée plus tard.
Exemples de tests de boîtes noires
 Essais de performance
Les tests de performance sont un type de tests effectués pour déterminer comment un système
se comporte en termes de réactivité et de stabilité sous une charge de travail particulière,
c'est-à-dire que les tests de performance mesurent comment un système se comporte sous une
charge croissante (tant le nombre d'utilisateurs que les volumes de données),
Les tests de performance peuvent être appliqués pour comprendre l'évolutivité de votre
application ou de votre site Web, ou pour comparer la performance dans un environnement
de produits tiers tels que des serveurs et des intergiciels en vue d'un achat potentiel. Ce type
de test est particulièrement utile pour identifier les goulots d'étranglement de performance
dans les applications très utilisées. Les tests de performance impliquent généralement une
suite de tests automatisés car cela permet de simuler facilement une variété de conditions de
charge normales, de pointe et exceptionnelles. Voici quelques exemples de tests de
performance : Test de charge, test de contrainte, test de trempage, test de pointes, test de
configuration et test d'isolation.
(a) Test de charge : L'essai en charge est le processus d'essai qui est habituellement
effectué pour étudier le comportement du système sous une charge spécifique prévue
(charge normale). Cette charge peut être le nombre d'utilisateurs simultanés attendus sur
l'application effectuant un nombre spécifique de transactions dans la durée définie. Ce test
permet de connaître les temps de réponse de toutes les transactions critiques importantes pour
l'entreprise.
Le test de charge est destiné à tester le système en augmentant constamment et régulièrement

la charge du système jusqu'à ce qu'il atteigne la limite de seuil.
Comment le système réagit-il lorsqu'il est soumis à la charge prévue ?
(b) Tests de stress : Les essais sous contrainte sont le processus d'essai qui est
habituellement effectué pour étudier le comportement du système sous une charge extrême.
Ce type de test est effectué pour déterminer la robustesse du système en termes de charge
extrême et aide les administrateurs d'applications à déterminer si le système fonctionnera
suffisamment si la charge actuelle dépasse largement le maximum attendu. Cela aide
l'administrateur de l'application à comprendre les limites supérieures de la capacité du
système. L'essai sous contrainte consiste à trouver le(s) point(s) de défaillance dans le
système lorsque la charge testée dépasse celle qu'elle peut supporter.
Comment le système réagit-il lorsqu'il est soumis à une charge extrême ?
Par exemple :
Combien d'utilisateurs peuvent être connectés à une base de données à un site Web (par
exemple Facebook) avant qu'elle ne s'écrase ? (Stress Testing).
Combien d'utilisateurs peuvent être connectés à un serveur avant qu'il ne plante ? (Stress
Testing).
Dans le cadre de tests de stress, diverses activités visant à surcharger les ressources existantes
d'emplois excédentaires sont menées afin de tenter de décomposer le système.
N/B :
- Si vous testez la charge normale prévue (par exemple, vous savez que le système sera
utilisé par 100 utilisateurs à la fois), c'est un test de charge. Mais lorsque vous voulez
déterminer comment le système se comporte sous une charge extrême (par exemple,
vous savez que le système sera utilisé par jusqu'à 100 utilisateurs à la fois, et vous
avez décidé d'ajouter 10 utilisateurs supplémentaires), et quand il se brise, c'est un test
de stress.
- A titre d'exemple, un traitement de texte comme Writer1.1.0 d'OpenOffice.org est

utilisé dans le développement de lettres, présentations, feuilles de calcul etc... Le but
de nos tests de stress est de le charger avec l'excès de caractères.
Pour ce faire, nous collerons à plusieurs reprises une ligne de données, jusqu'à ce
qu'elle atteigne son seuil limite de traitement d'un grand volume de texte. Dès que le
corps de caractère atteint 65 535 caractères, il refuserait simplement d'accepter plus de
données. Le résultat des tests de stress sur Writer 1.1.0 produit le résultat que, il ne
s'écrase pas sous le stress et qu'il gère la situation avec grâce, ce qui assure que
l'application fonctionne correctement même dans des conditions de stress rigoureuses.
Fondamentalement la même chose mais la charge est sous charge normale et le stress
est plus que la charge normale.
- Un autre exemple, dans un système ATM, les tests de charge et de contrainte sont
effectués pour vérifier comment le système se comportera lorsqu'il sera soumis au
trafic de données et à la congestion du réseau ATM, c'est-à-dire comment le logiciel
se comportera lorsqu'il sera soumis à une charge normale (test de charge) ou extrême
(stress testing).
Les tests de performance peuvent servir à différentes fins :
 Il peut démontrer que le système répond aux critères de rendement.
 Il peut comparer deux systèmes pour trouver celui qui fonctionne le mieux.
 Il peut mesurer les parties du système ou la charge de travail qui causent un mauvais
fonctionnement du système.
De nombreux tests de performance sont entrepris sans fixer d'objectifs de performance

suffisamment réalistes et orientés vers les buts. La première question d'un point de vue
commercial devrait toujours être : "Pourquoi faisons-nous des tests de performance ?" Ces
considérations font partie de l'analyse de rentabilisation de l'essai. Les objectifs de rendement
varieront selon la technologie et l'objectif du système, mais ils devraient toujours comprendre
certains des éléments suivants :
- Certains des outils de test de performance sont Load Runner, Apache JMeter,
LoadRunner, Loadstorm, CloudTest, WebLOAD, Appvance, NeoLoad, LoadUI, Rational
Performance Tester, Testing Anywhere, OpenSTA, QEngine (ManageEngine), Httperf,
WAPT, Loadster, LoadImpact, etc.
 Test d'utilisabilité
La partie test de convivialité d'une méthodologie de test porte sur l'aspect convivialité du
logiciel pour l'utilisateur final. La facilité avec laquelle un utilisateur peut accéder au produit
constitue le principal point de test. Les tests de convivialité portent sur quatre (4) aspects des
tests : la facilité d'apprentissage, l'efficacité, la satisfaction et la mémorisation.
 Tests de sécurité
Auparavant, la sécurité était quelque chose qui était testé après coup. Avec la montée de la
cybercriminalité et la prise de conscience des risques liés aux vulnérabilités logicielles, la
sécurité des applications doit désormais être conçue et développée en même temps que la
fonctionnalité métier souhaitée. Les tests de sécurité testent la confidentialité, l'intégrité,
l'authentification, la disponibilité et la non-répudiation du logiciel. Des tests individuels sont
effectués pour empêcher tout accès non autorisé au code logiciel.
 Test de compatibilité
Tester la compatibilité d'une application ou d'un site Web avec différents navigateurs,
systèmes d'exploitation et plates-formes matérielles. Les tests de compatibilité peuvent être
effectués manuellement ou peuvent être pilotés par une suite de tests fonctionnels ou de
régression automatisés.
La partie compatibilité d'une méthodologie de test teste la compatibilité du produit ou de

l'application avec tous les systèmes d'exploitation, plates-formes matérielles, navigateurs
Web, appareils mobiles et autres programmes conçus par des tiers (par exemple, plug-ins de
navigateur). Les tests de compatibilité vérifient que le produit fonctionne comme prévu dans
toutes les différentes combinaisons matériel/logiciel et que toutes les fonctionnalités sont
prises en charge de manière cohérente.
D'autres types de tests incluent :
(a) Tests Alpha : Tests effectués par le client sur le site du développeur.
b) Bêta-test : Tests effectués par le client sur le site du client.
c) TEST DE CONFORMITÉ
Vérification de la conformité de la mise en œuvre aux normes de l'industrie. Produire
des tests pour le comportement d'une implémentation afin de s'assurer qu'elle fournit
la portabilité, l'interopérabilité et/ou la compatibilité qu'une norme définit.
En résumé, les différences entre le test des boîtes blanches et le test des boîtes noires peuvent
être résumées dans le tableau ci-dessous :
Test des boîtes blanches Test des boîtes noires

(1) Le test des boîtes noires consiste à tester
(1) Le test de la boîte blanche (aussi connu un logiciel sans rien connaître de son
sous le nom de test transparent, de boîte de fonctionnement interne.
verre ou de structure) est une technique de
test qui évalue le code et la structure interne
du programme. Cela ne nécessite pas la connaissance du
langage de programmation utilisé.
Pour ce faire, il faut connaître le langage de
programmation utilisé.
(2) Dans Black Box Testing, nous testons le

(2) Dans White Box Testing, nous testons logiciel du point de vue de l'utilisateur.
le logiciel du point de vue des développeurs.
(3) Dans le test des boîtes blanches, les cas

(3) Dans White Box Testing, les cas de test de test sont générés à partir de la
sont générés à partir du code source. spécification des exigences.
 Test de boîtes noires : Les tests de boîtes noires jouent un rôle important dans les
tests de logiciels, ils aident à la validation de la fonctionnalité globale du système.
Les tests de boîtes noires sont effectués en fonction des besoins des clients, de sorte
que toute exigence incomplète ou imprévisible peut être facilement identifiée et ainsi
empêcher son introduction dans le logiciel.
 Test de régression : Des tests de régression sont effectués pour montrer que les
parties inchangées mais vulnérables du système n'ont pas été affectées de manière
négative. Les tests de régression permettent de s'assurer que le logiciel est validé
après un changement de logiciel.
Projet choisi : Guichet automatique pour un système bancaire
Le concept de test statique explique :
 Essais de performance : Certains jours, les activités bancaires ont peut-être atteint
des sommets, en particulier dans les pays suivants festivals ou période pendant laquelle il y
a une offre. Les défaillances de performance peuvent nuire à la réputation de
l'institution financière.
 Test d'utilisabilité : L'application du guichet automatique serait utilisée par de
nombreux utilisateurs - certains seraient techniquement solides et d'autres pourraient
manquer de compétences techniques. L'application doit être simple afin que même les
personnes qui n'ont pas tant d'expérience technique soient capables de bien gérer
l'application. L'application doit être testée pour sa conception simple et efficace afin
que tout utilisateur puisse naviguer dans l' application bancaire sans assistance.
L'application bancaire doit être simple, de sorte que si un utilisateur reste absent pendant
une longue période sans l'utiliser, il ne devrait pas être difficile pour lui de
recommencer.
 Essais de sécurité :
 Test de compatibilité :
 Tests de base de données - Ceci doit être fait pour s'assurer que l'intégrité des
données, la migration des données , la validation et les tests de règles sont corrects.
Exemples de cas d'essai pour une application bancaire de guichet automatique :
1. Vérifiez que l'utilisateur est capable de se connecter avec un nom d'utilisateur et un

mot de passe valides.
2. Vérifier que l'utilisateur est capable d'effectuer des transactions financières de base.
3. Vérifier que l'utilisateur est en mesure d'ajouter un bénéficiaire dont le nom et les
détails de compte sont valides.
4. Vérifier que l'utilisateur est en mesure d'effectuer des transactions financières avec le
bénéficiaire additionnel.
5. Vérifier que l'utilisateur est capable d'ajouter un nombre décimal dans le montant
(limité par 2 chiffres)
6. Vérifiez que l'utilisateur n'est pas capable d'ajouter un nombre négatif dans le champ
montant.
7. Vérifiez que l'utilisateur n'est autorisé à transférer de l'argent que si le solde de son
compte est correct.
8. Vérifiez qu'il existe un contrôle de confirmation pour les transactions financières.
9. Vérifier que l'utilisateur reçoit un accusé de réception lorsque la transaction financière

est réussie.
10. Vérifier que le client est capable d'envoyer de l'argent à plusieurs personnes
11. Vérifier que l'utilisateur est autorisé à changer son mot de passe
12. Vérifiez que les détails du compte reflètent également les transactions financières.
13. Vérifiez que l'utilisateur dont le mot de passe est invalide n'est pas autorisé à se
connecter.
14. Vérifiez qu'après plusieurs tentatives répétées de connexion avec un mot de passe
incorrect ( selon les limites), l'utilisateur doit être bloqué.
15. Vérifiez que la fonction de délai d'attente est implémentée.
16. Vérifiez que si l'un des deux noms d'utilisateur ou mots de passe est vide, l'utilisateur
n'est pas autorisé à se connecter. L'utilisateur doit également recevoir une alerte.
Diagramme d'activité pour ATM
(b)
T Condition
F
Si (Condition 1) 1
x= a ;
Sinon (Condition 2) x=a T F

Condition
y =x+ 1 ; 2
Sinon (Condition 3) y=x+1 T Condition

F
y = x- 1 ; 3
Sinon { {
y= x+2
y=x-1 y=x+2
Rendement (Score)
Score de
retour
CONFÉRENCE 3 : TECHNIQUES DE TEST DES BOÎTES BLANCHES :

(TECHNIQUES DE GÉNÉRATION DE DONNÉES D'ESSAI)
Quelques techniques d'essai de boîte blanche incluent :
 Test de flux de contrôle
 Test de flux de données
A) ESSAIS DE DÉBIT DE CONTRÔLE
Un graphique de flux de contrôle pour un programme se compose d'un nœud pour chaque
instruction du programme et de bords représentant le flux de contrôle entre les instructions.
Certaines des limites des essais de débit de contrôle sont les suivantes :
(1) Le Test de flux de contrôle ne peut pas détecter toutes les erreurs d'initialisation.
(2) Les erreurs de spécification des exigences ne sont pas détectées par les tests de flux de
contrôle.
(3) Il est peu probable de trouver des chemins et des caractéristiques manquants si le
programme et le modèle sur lequel les tests sont basés sont effectués par la même personne.
 L'adéquation des cas de test mesurés avec une métrique appelée couverture (la
couverture est un mesure de l'exhaustivité de l'ensemble des cas de test).
Dans la section suivante, nous définirons différentes méthodes de couverture :
Critères de couverture pour le test des boîtes blanches
Considérez les termes suivants : Tests exhaustifs, tests complets ou couverture complète. En
gardant ces trois termes à l'esprit, les questions suivantes se posent :
Est-il possible d'effectuer des tests exhaustifs, des tests complets ou une couverture
complète ?
Specifically, le nombre d'entrées potentielles pour la plupart des programmes est si important
qu'il s'agit en fait de infinite. Considérez un compilateur Java - le nombre d'entrées
potentielles pour le compilateur n'est pas seulement tous les programmes Java, ou même tous
les programmes Java presque corrects, mais toutes les chaînes. La seule limitation est la taille
du file qui peut être lu par l'analyseur. Par conséquent, le nombre d'entrées est
effectivement infinite et ne peut pas être explicitement énuméré.
C'est là qu'interviennent les critères de couverture. Comme nous ne pouvons pas tester avec
toutes les entrées, les critères de couverture sont utilisés pour décider quelles entrées de test
utiliser. La communauté des testeurs de logiciels croit qu'une utilisation efficace des critères
de couverture augmente la probabilité que les ingénieurs de test commettent des erreurs dans
un programme. D'un point de vue pratique, les critères de couverture fournissent des règles
utiles pour savoir quand arrêter les tests.
Définition :
Critère de couverture
L'adéquation des cas de test est mesurée à l'aide d'une mesure appelée couverture (la
couverture est une mesure de l'exhaustivité de l'ensemble des cas de test).
La couverture de code est une mesure utilisée dans les tests logiciels. Il décrit le degré
auquel le code source a été testé.
Selon les paramètres d'entrée, différentes parties des codes seront exécutées. Le test unitaire
doit être écrit de manière à couvrir toutes les parties des codes.
L'adéquation des tests est évaluée par la mesure de couverture qui décrit le degré auquel le
code source d'un programme a été testé. Les critères de suffisance comprennent la couverture
du Sentier, la couverture de l'énoncé, la couverture de la condition, de la direction générale ou
de la décision.
Si la couverture n'est pas complétée, d'autres cas de test peuvent être conçus pour tester les
éléments qui ont été manqués et ainsi augmenter la couverture. Il existe différents types de
couverture utilisés pour les tests. Ils incluent :
Couverture des chemins - toutes les chemins possibles d'un programme doivent être testées
au moins une fois.
Couverture des instructions - tous les instructions dans les programmes doivent être
exécutés au moins une fois.
Couverture des branches - toutes les branches du programme doivent être exécutées au
moins une fois.
Couverture de la condition - elle exécute le résultat vrai ou faux de chaque condition.
Les tests en boîte blanche testent la mesure dans laquelle le code source est couvert. C'est ce
qu'on appelle les critères de couverture.
N/B : Les élèves peuvent noter que pour chaque cheminement possible, nous pouvons
générer un cas de test.
Diagramme de contrôle
Question : Énumérer cinq (5) structures de contrôle utilisées dans la programmation
Control Flow Graph est une représentation graphique d'une unité de programme.
La notation simple utilisée pour représenter le flux de contrôle est appelée graphique de flux.
Le graphique de déroulement représente le déroulement logique du contrôle qui est utilisé
pour représenter la structure de contrôle du programme.
- Chaque cercle d'un graphique d'écoulement est appelé nœud du graphique

d'écoulement.
- Les flèches sont appelées bords ou liens (représentent le flux de contrôle).
- Les zones délimitées par des noeuds et des bords sont appelées régions.
Lire (p, q)
Étant donné le code suivant, produire le graphique de flux de contrôle correspondant.
SI
P+q>100
Read p
Readq Grand
Ifp+q>100THEN
Fin Si
Print "Large" Diagramme de contrôle
END SI
IF p > 50 THEN
P+q>50
Print "p Large"
ENDIF P Grand
Fin Si
En utilisant le pseudo-code ci-dessous, produisez les graphiques de flux de contrôle

correspondants.
(i) Commencer
Read(x) ; read(y) ;
Tandis que (pas (x = y)) boucle
Si x > y Alors
x := x - y ;
Sinon
y := y - x ;
Fin si ; Commencer
Boucle d' extrémité ;
Imprimer pgcd := x ;
Fin ; Entrée (x, y)
Diagramme de
Commencer contrôle
Bien que
Entrée (x, y)
Pas x=y x=y
Page 47 de 78 ICT304 : Notes de cours sur les essais de logiciels par le Bien
Dr X. Y.
queKimbi
Si pgcd := x
x> o,y>0 x<=o ou y<=0
x<=y
Si Sortie (x+y)
x:=x-y y:=y-x
Fin
x>y x<=y
Fin Si
x:=xy y:=y-x
Fin Si
Graphique de
contrôle
(ii) Commencer
Entrée (x, y) ;
Tandis que (x>0 et y>0) Faites
Si (x>y)
Puis x : = x-y
Sinon y : = y-x
EndIf ;
EndWhile ;
Sortie (x+y) ;
Fin
(iii) Int GetNotes (Int CC, TP, Examens, Total) ;

Si (CC > TP et TP > Examens) Ensuite
Laissez-passer de retour ;
Sinon
Échec de retour ; Int CC, TP, Examens,
Fin Si Total
Si (Total >= 80) Alors
Retour A ;
SI
Sinon
Retour B+ ;
Fin Si
CC>TP et TP>Examens CC<=TP et TP<=Examens
Passe Echec
Fin Si
Diagramme de contrôle
SI
Total>=80 Total <80
A B+
Fin Si
(iv) Commencer
Entrée (x, y) ;
Commencer
Tandis que (x>0 et y>0) Faites
Si (x>y)
Puis x : = x-y Entrée (x, y)
Sinon y : = y-x
EndIf ;
EndWhile ; Bien que
Sortie (x+y) ;
Fin
x<=o,y<<=
x> o,y>0 0
Si
x>y x<=y
x:=xy y:=y-x
Fin Si
B) LES TESTS DE FLUX DE DONNÉES
 Les techniques discutées jusqu'à présent ont toutes été basées sur le "contrôle du
flux".
 Le test de flux de données est un autre type de test en boîte blanche qui examine
comment les données se déplacent dans un programme.
 Les tests de flux de données tiennent compte de l'association entre la définition des
variables et leur utilisation.
 Dans le test de flux de données, le graphique de flux de contrôle est annoté avec les
informations suivantes comment les variables du programme sont définies et utilisées.
 (Le diagramme de contrôle est une représentation schématique d'un programme et de

son exécution).
 Les tests de flux de données ont tendance à découvrir des bogues comme les variables
utilisées mais non initialisées, ou déclarées mais non utilisées, etc.
 Dans tout langage de programmation, il doit y avoir des instructions qui
déclarent/définissent des variables
(" Variable definition ") et d'autres énoncés qui utilisent les variables déclarées ("
Variable use ").
 Vous pouvez également concevoir des cas de test basés sur le "flux de données".
(c.-à-d., comment les données circulent dans le code)
- Certains énoncés "définissent" la valeur d'une variable (c.-à-d. une "définition de

variable") :
- Déclarations variables avec valeurs initiales
- Affectations
- Valeurs des paramètres entrants
- Certains énoncés "utilisent" la valeur de la variable (c.-à-d. une "utilisation variable") (c.-à-
d. que certains énoncés utilisent une définition de variable) :
- Expressions sur le côté droit de l'affectation

- Expressions booléennes de condition
- Expressions de paramètres
L'essai de flux de données (DFT) tient compte des associations entre la définition des
variables et les utilisations variables. La définition d'une variable modifie un élément de
données alors que l'utilisation d'une variable fait référence à un élément de données sans le
modifier.
- Pour chaque "utilisation" d'une variable
- Déterminer tous les endroits possibles dans le programme où la variable aurait pu être
définie (c.-à-d., étant donné sa valeur la plus récente).
- Créez un scénario de test pour chaque paire possible (Définition-Utilisation) (c.-à-d. Pour
chaque chemin possible, nous pouvons générer un scénario de test).
Exemple 1 : Jetons un coup d'œil à la structure du programme
Si (condition 1) {
x= a ;
}
Sinon { {
x= b ;
}
Si (condition 2) {
y =x+ 1 ;
}
Sinon { {
y = x- 1 ;
}
De combien de cas de test avons-nous besoin ?
Pour que nous puissions répondre à cette question, nous devons nous identifier : Toutes les
définitions, toutes les utilisations et toutes les paires définition-utilisation
Définitions : (1) x = a (2) x = b

Utilisations : (1) y = x + 1 (2) y = x - 1
Toutes les paires Définition-Utilisation : 1. (x = a, y = x + 1)

2. (x = b, y = x + 1)
3. (x = a, y = x - 1)
4. (x = b, y = x - 1)
Par conséquent, nous avons besoin de quatre cas de test pour le programme ci-dessus.
Exemple 2 :
Critères d'essai des flux de données
Ces critères reposent sur deux concepts fondamentaux, à savoir la variable definitions et les
usages variables.
Quatre (4) critères de test de flux de données sont :

 Tous les nœuds
 Toutes les arêtes
 Toutes définitions
 Tous usages
La DFT est une famille de critères d'adéquation qui comprend tous les nœuds, toutes les
arêtes et toutes les utilisations.
- Un ensemble de tests satisfait au critère de tous les nœuds si chaque nœud du CFG est
exécuté par un test dans l'ensemble de tests.
- Un ensemble d'essai satisfait au critère de tous les bords si chaque bord du CFG est
exécuté par un essai dans l'ensemble d'essai.
- Un ensemble de test satisfait au critère de tous les usages si chaque paire définition-
usage du programme est exécutée par un test dans l'ensemble de test.
Anomalie de flux de données
Une anomalie est une façon déviante ou anormale de faire quelque chose. L'anomalie de flux
de données est l'identification de certains défauts (appelés anomalies de flux de données).
Règles pour les flux de données :
(1) Une valeur ne doit pas être affectée deux fois à une variable.
(2) Une variable non définie ne doit pas être référencée, c'est-à-dire qu'une
variable non définie/non déclarée ne doit pas être référencée.
(3) Une variable définie/déclarée doit être utilisée
Par conséquent, trois actions fondamentales associées à une variable sont undefine (u),
define(d), et référence (r). Une variable est implicitement undefined lorsqu'elle est créée sans
qu'une valeur lui soit attribuée. D'autre part, une variable peut être explicitement undefined.
Par exemple, lorsqu'un file ouvert est fermé, la variable contenant le pointeur file devient
undefined. Nous avons expliqué l'idée des "états" d'une variable, à savoir undefined (U),
defined (D), référencée (R), et anormale (A), en considérant les trois actions fondamentales
sur une variable. L'état A représente le fait que la variable a été accédée d'une manière
anormale causant une anomalie des données.
- Ces anomalies de flux de données peuvent être détectées par analyse statique
- Ces anomalies pourraient être des manifestations d'erreurs de programmation
potentielles.
- L'anomalie de données flow peut être détectée en utilisant l'idée d'instrumentation de
programme. Intuitivement, l'instrumentation de programme signifie l'incorporation d'un
code additionnel dans un fichier pour surveiller son état d'exécution.
- Les élèves peuvent noter que, pour chaque cheminement possible, nous pouvons
générer un scénario de test.
-
Questions TD 3 et TD4
(1) Quelle est la signification de ;

(a) Test de boîte noire
(b) Test de la boîte blanche
(2) Dans les tests en boîte blanche, le système testé n'est PAS traité comme une boîte
noire alors qu'il est en mode la boîte noire testant le système testé est traitée comme une
boîte noire. Discuter explicitement.
(2) En tant qu'Ingénieur Logiciel, vous avez été sollicité par l'Université de Yaoundé I pour
concevoir et mettre en œuvre un logiciel de traitement des résultats des étudiants. En utilisant
le langage C+++ ou tout autre langage de programmation de votre choix, écrivez la
FONCTION pour calculer les GRADES de N élèves. Recommander trois types d'approches
de test pour le système en donnant votre justification et l'importance de chaque test et ainsi
produire le graphique de contrôle du flux (CFG) de la fonction.
(3) A l'aide d'un diagramme, définir les Méthodologies de Test Logiciel, avec référence à un
projet logiciel choisi, Expliquer les critères de sélection des cas de test, Présenter le
Document de Cas de Test du Projet choisi, Expliquer le concept de Test Fonctionnel et ainsi
décrire le Graphique de Flux de Contrôle (CFG) du Système.
Recommandez trois approches de test logiciel pour le système en donnant votre justification
et l'importance de chaque test.
Si (Condition 1)
x= a ;
Sinon (Condition 2)
y =x+ 1 ;
Sinon (Condition 3)
(b) Compte tenu yde= x-la 1structure
; du programme ci-dessous, produire l'organigramme de
Sinoncorrespondant.
contrôle (GPC) {{
y= x+2
Rendement (Score)
(4) Distinguer les concepts suivants : (3mks)

(a) Tests des boîtes blanches et des boîtes noires
(b) Tests de régression et tests d'intégration
(c) Tests de performance et tests de régression
(5) En supposant que vous développiez un logiciel de gestion des résultats des étudiants
à l' Université de Yaoundé I avec le système de notation suivant :
Notes Gamme
80≤x≤100 A+
75≤x<80 A
70≤x<75 B+
65≤x<70 B
60≤x<65 B-
55≤x<60 C+
50≤x<55 C
45≤x<50 C-
40≤x<45 D+
35≤x<40 D
0≤x<35 E
(a) Ecrire un algorithme pour le projet de logiciel ci-dessus et par conséquent indiquer
l'option caractéristiques des Algorithmes ?
(b) Définir les cas d'essai et donc expliquer les critères de sélection des cas d'essai.
(c) Présenter le document de cas d'essai du projet choisi et, par conséquent, produire
le document de cas d'essai du diagramme de séquence, diagramme de classes et diagramme
d'objets correspondants de l'élément projet. .
(d) En ce qui concerne le projet ci-dessus, expliquer le concept des tests perturbateurs.
(e) Utiliser C++ ou VB.Net ou toute autre programmation de votre choix : écrivez
la fonction de calcul des notes de N élèves et donc de représentation du
Contrôleur Diagramme de flux (CFG) du système.
(e) Recommandez trois approches de test de logiciels pour le système en donnant
à votre et l'importance de chaque test.
(6) Énumérez cinq (5) énoncés de contrôle utilisés dans la programmation et décrivez le
GPC de chacun.
(7) Quelles sont les limites du test des boîtes blanches ?
EXPOSÉ 4 : TECHNIQUES DE TEST DE LA BOÎTE NOIRE
Il s'agit de techniques de test de boîtes noires pour l'identification des cas de test.
Quelques techniques d'essai de boîte noire sont énumérées ci-dessous :
 Équivalence Partitionnement
 Analyse de la valeur limite
 Tests comportementaux
 Tests aléatoires
 Deviner les erreurs
 Tests de cas d'utilisation, etc.
PARTITIONNEMENT D'ÉQUIVALENCE/ PARTITIONNEMENT DE CLASSE
D'ÉQUIVALENCE
Un domaine d'entrée peut être trop vaste pour que tous ses éléments puissent être utilisés
comme entrée de test (Figure 3a). Cependant, le domaine d'entrée peut être divisé en un
certain nombre de sous-domaines finite pour sélectionner les entrées de test. Chaque sous-
domaine est connu sous le nom de classe d'équivalence (CE) et sert de source d'au moins une
entrée de test (Figure 3b). L'objectif du partitionnement d'équivalence est de diviser le
domaine d'entrée du système testé en classes ou groupes d'entrées. Toutes les entrées d'une
même classe ont un effet similaire sur le système testé. Un EC est un ensemble d'entrées que
le système traite de la même manière lorsqu'il est testé. Il représente certaines conditions, ou
prédicats, sur le domaine d'entrée. Une condition d'entrée sur le domaine d'entrée est un
prédicat sur les valeurs du domaine d'entrée. Une entrée valide dans un système est un
élément du domaine d'entrée dont on s'attend à ce qu'il renvoie une valeur sans erreur. Une
entrée non valide est une entrée dont on s'attend à ce qu'elle renvoie une valeur d'erreur. Les
conditions d'entrée sont utilisées pour partitionner le domaine d'entrée en CE afin de
sélectionner les entrées.
Figure 3 : (a ) Trop d'entrées de test b) Une entrée sélectionnée dans chaque sous-domaine
Stratégie
Analyse de la valeur limite
N/B : Note de cours en cours
EXPOSÉ 5 : PRINCIPES DE TEST DES LOGICIELS
Principe 1 : Les tests permettent d'identifier la présence de défauts

Les tests de logiciels ne peuvent montrer que la présence d'erreurs et non leur absence. Les
tests permettent d'identifier les défauts présents dans un morceau de code, mais ne montrent
pas que ces défauts ne sont pas présents. Pour démontrer l'absence de défauts, toutes les
combinaisons de toutes les actions possibles sur tous les objets accessibles du logiciel, pour
toutes les combinaisons de données d'entrée, dans tous les contextes possibles, doivent être
testées, c'est-à-dire le matériel : carte mère, unité centrale de traitement (CPU) et nombre de
CPU, bus, réseau, mémoire vive (RAM), vitesse E/S, vitesse et capacité du disque dur,
logiciel (système d'exploitation et ses paramètres, autres logiciels pouvant interagir avec le
logiciel, tant au niveau logiciel que matériel) qui est impossible, pour toutes intentions ou
fins.
Il n'est pas possible de démontrer l'absence réelle d'un défaut dans le logiciel, mais seulement
la présence de tels défauts. L'exécution de tests de logiciels permet de réduire les risques de
défauts résiduels - non identifiés - mais ne peut garantir que tous les défauts ont été identifiés.
(Bernard Homès (2012), p. 11)
Le test d'une application ne peut que révéler l'existence d'un ou plusieurs défauts dans
l'application, cependant, le test seul ne peut pas prouver que l'application est sans erreur. Il est
donc important de concevoir des cas de test qui trouvent autant de défauts que possible.
Les tests de logiciels ne peuvent montrer que la présence d'erreurs et non leur absence.
Un test réussi devrait révéler de nouvelles erreurs, et non "prouver" qu'il n'y a pas
d'erreurs, car le premier ajoute plus de valeur au programme.
Principe 2 : Il est impossible d'effectuer des essais exhaustifs

Il est impossible d'entreprendre des tests exhaustifs, de tout tester. Lorsque l'on teste une
petite calculatrice, "tout tester" signifie essayer toutes les combinaisons de valeurs d'entrée,
d'actions, de configurations (matérielles et logicielles), ce qui donne un nombre quasi infini
de cas de test, ce qui n'est ni réaliste à concevoir ni à exécuter. Des tests exhaustifs ne sont
pas possibles, sauf dans de rares cas insignifiants. (Bernard Homès (2012), p. 11)
Il n'est pas possible de tester toutes les combinaisons possibles de données et de scénarios.
Pour cette raison, les risques et les priorités sont utilisés pour se concentrer sur les aspects les
plus importants à tester.
Principe 3 : Tests précoces dans le cycle de vie du développement logiciel

Ce principe repose sur le fait que les coûts, qu'il s'agisse des coûts de développement, des
coûts de test, des coûts de correction des défauts, etc. augmentent tout au long du projet. Il est
économiquement plus judicieux de détecter les défauts le plus tôt possible, ce qui permet
d'éviter la conception d'un code incorrect, la création de cas de test, qui nécessitent la
conception et la maintenance des cas de test créés, l'identification des défauts qui doivent être
enregistrés, corrigés et testés à nouveau. (Bernard Homès (2012), pp 12)
Plus tôt nous commencerons les activités de test, mieux nous pourrons utiliser le temps
disponible. Dès que les produits initiaux, tels que le cahier des charges ou les documents de
conception sont disponibles, nous pouvons commencer les tests. Il est courant que la phase de
test soit écrasée à la fin du cycle de développement, c'est-à-dire lorsque le développement est
terminé, de sorte qu'en commençant le test tôt, nous pouvons préparer le test pour chaque
niveau du cycle de développement.
Un autre point important concernant les tests précoces est que lorsque les défauts sont
détectés plus tôt dans le cycle de vie, ils sont beaucoup plus faciles et moins coûteux à
réparer. Il est beaucoup moins coûteux de modifier une exigence incorrecte que d'avoir à
modifier une fonctionnalité dans un grand système qui ne fonctionne pas comme demandé ou
comme prévu !
Principe 4 : Regroupement des défauts (regroupement des défauts)

Même si les bugs n'ont pas de vie réelle, il est fréquent qu'un certain nombre de défauts soient
concentrés selon des critères identiques. Il peut s'agir d'un morceau de code (comme une
section complexe d'un algorithme), d'un sous-ensemble de composants conçus par la même
personne (lorsqu'une erreur similaire se répète), d'un groupe de composants conçus dans la
même période ou même d'un composant standard défectueux (COTS). Ce principe signifie
également que si vous trouvez un défaut, il peut être efficace de rechercher d'autres défauts
dans le même code. (Bernard Homès (2012), pp 12)
Principe 5 : Paradoxe des pesticides

Cinquième principe : le paradoxe des pesticides, ou le manque d'efficacité des tests lorsqu'ils
sont utilisés sur une période donnée. Cette perte d'efficacité est due à la ré-exécution de tests
identiques (mêmes données, mêmes actions) sur des chemins logiciels déjà testés. Si une
défaillance a été identifiée et corrigée lors d'une exécution précédente de ce test, elle ne sera
plus détectée lors de la ré-exécution de ce test à une date ultérieure. D'autres défauts
pourraient être mis en évidence, outre ceux déjà identifiés. En fin de compte, la réexécution
de ce test fonctionnera sans problème et n'identifiera aucun défaut supplémentaire.
L'efficacité des tests diminuera, tout comme l'efficacité des pesticides diminue avec le temps
et l'utilisation.
Il est fortement suggéré que les tests soient modifiés au fil du temps, afin de les modifier et
que l'impact de ce principe soit négligeable. L'utilisation d'autres techniques d'essai, la
variation des données d'essai ou de l'ordre d'exécution des essais sont des moyens de contrer
ce principe. (Bernard Homès (2012), p. 13)
Si vous continuez à exécuter le même ensemble de tests encore et encore, il y a de fortes
chances qu'aucun nouveau défaut ne soit découvert par ces cas de test. Parce qu'au fur et à
mesure de l'évolution du système, la plupart des défauts signalés précédemment auront été
corrigés et les anciens cas de test ne s'appliquent plus. Chaque fois qu'un défaut est corrigé ou
qu'une nouvelle fonctionnalité est ajoutée, nous devons effectuer un test de régression pour
nous assurer que le nouveau logiciel modifié n'a pas cassé une autre partie du logiciel.
Cependant, ces cas de tests de régression doivent également être modifiés pour refléter les
changements apportés au logiciel afin d'être applicables et, espérons-le, de corriger de
nouveaux défauts.
Principe 6 : Le test dépend du contexte

La réutilisation des plans de test, de la conception des tests, des conditions de test ou des
scénarios de test d'autres logiciels ou projets est donc contre-productive, même si elle peut
sembler intuitivement valable. Cela ne veut pas dire que vous ne devez pas tenir compte de
l'expérience acquise par les autres, mais que vous devez - à tout moment - être conscient de
votre propre environnement, de son évolution, et de toute adaptation obligatoire à votre
contexte.
Les systèmes critiques pour la sécurité seront testés différemment et avec un effort plus
intense que la plupart des systèmes de commerce électronique. Cependant, ce principe va
beaucoup plus loin, car il s'applique également à l'évolution du contexte de votre propre
application logicielle. Lors des premiers tests de votre logiciel, vous concevrez des tests basés
sur votre connaissance du logiciel à ce moment précis. Au cours des tests ultérieurs, ou des
tests de la prochaine version du logiciel, votre connaissance du logiciel aura évolué, et vous
concevrez d'autres tests, en vous concentrant, par exemple, sur les risques identifiés, sur les
composants où des regroupements de défauts sont survenus, ou en tenant compte du paradoxe
des pesticides. Votre effort de test sera influencé par le temps et les ressources disponibles,
par les défauts antérieurs, la qualité du code et les objectifs qui vous ont été assignés.
(Bernard Homès (2012), p. 13)
Différentes méthodologies, techniques et types d'essais sont liés au type et à la nature de

l'application. Par exemple, une application logicielle dans un dispositif médical nécessite plus
de tests qu'un logiciel de jeux. Plus important encore, un logiciel de dispositifs médicaux
nécessite des tests basés sur les risques, être conforme aux réglementations de l'industrie
médicale et éventuellement des techniques de conception de tests spécifiques. De même, un
site Web très populaire doit subir des tests de performance rigoureux ainsi que des tests de
fonctionnalité pour s'assurer que les performances ne sont pas affectées par la charge sur les
serveurs.
Principe 7 : Absence d'erreurs Fallacy

Très souvent, la réduction du nombre de défauts est considérée comme le but ultime des
essais. Toutefois, il n'est pas possible de garantir qu'une application logicielle, même si elle
ne présente aucun défaut, répond aux besoins du public. Si le logiciel ne correspond pas aux
besoins des utilisateurs ou à leurs attentes, l'identification et la correction des défauts
n'aideront pas l'architecture ou la convivialité du logiciel, ni le succès financier du logiciel.
(Bernard Homès (2012), pp 14)
Ce n'est pas parce que les tests n'ont révélé aucun défaut dans le logiciel que celui-ci est prêt
à être expédié. Les tests exécutés étaient-ils vraiment conçus pour détecter le plus grand
nombre de défauts ? ou pour voir si le logiciel correspondait aux exigences de l'utilisateur ? Il
y a beaucoup d'autres facteurs à considérer avant de prendre la décision d'expédier le logiciel.
TD 5
(1) Quels sont les principes du Software Testing ?

(2) Expliquer le concept de test exhaustif.
(3) Expliquer le concept des tests perturbateurs.
(4) Les bogues sont inévitables dans tout projet de développement logiciel.
Discutez en détail comment les bogues peuvent être rapportés dans un projet
donné.
(Indice : les outils d'analyse de suivi des bogues (analyse de défaillance)
doivent être expliqués, par exemple Bugzilla, Mantis, JIRA, BugTracker, FogBugz,
Redminet, etc)
EXPOSÉ 6 : UNE APPROCHE PRATIQUE DES TESTS LOGICIELS
TESTLINK
TestLink est un outil de gestion des tests en ligne qui facilite l'assurance qualité des logiciels.
Il est développé et maintenu par Teamtest. La plate-forme offre un support pour les cas de
test, les suites de test, les plans de test, les projets de test et la gestion des utilisateurs, ainsi
que divers rapports et statistiques.
Utilisation
Les unités de base utilisées par TestLink sont : Test Case, Test Suite, Test Plan, Test Project,
Test Project et User
Utilisateur
Chaque utilisateur TestLink a un rôle assigné qui définit les fonctions disponibles. Les types
par défaut sont : Invité, concepteur de test, testeur principal, testeur, responsable et
administrateur, mais des rôles personnalisés peuvent également être créés.
Avantages de TestLink
 Il prend en charge de multiples projets
 Exportation et importation faciles des cas de test
 Facile à intégrer avec de nombreux outils de gestion des défauts
 Exécution automatisée des cas de test par XML-RPC
 Filtrage facile des cas de test avec la version, les mots-clés, l'ID et la version du cas de
test
 Facile à assigner des cas de test à plusieurs utilisateurs
 Facile à générer un plan de test et des rapports de test dans différents formats
 Fournir des informations d'identification à plusieurs utilisateurs et leur assigner des

rôles
EXPOSÉ 7 : MÉTHODES D'ESSAIS AUTOMATISÉS
TEST AUTOMATISÉ
Qu'est-ce qu'un test automatisé ?
L'automatisation des tests est l'utilisation d'un logiciel (dans le cadre d'un paramétrage des
conditions préalables aux tests) pour exécuter les tests et déterminer ensuite si les résultats
réels et les résultats prévus sont les mêmes.
Pourquoi avons-nous besoin de l'automatisation des tests ?

Companies not only want to test software adequately, but also as quickly and thoroughly as
possible. To accomplish this goal, organizations are turning to automated testing.
To increase the test coverage.
Reduces the need for manual testing and discovers defects manual testing cannot expose and
also manual testing is error prone and a time consuming process.
Running the tests again and again gives us the confidence that the new features added to the
system did not break the code that worked before and also to make sure that the changes we
introduced are working. This can be achieved faster through automated testing.
Executing the tests (particularly acceptance tests) can also help us understand what portion of
the desired functionality has been implemented.
The set of the automated test suite can form a regression test suite. The purpose of the
regression suite is to make sure that the software behavior is unchanged unless due to data
change or latest software.
Automating also reduces the time taken for regression testing.
Automated unit test suite helps find the problems at an earlier stage and solve them
Some examples of automated Testing Tools:
 Junit
 NUnit
 Selenium API
 Selenium WebDriver
 Bugzilla
 QTP
 SOAP UI
 JMeter
 QC
 JIRA
 qTest
Some examples of automated Testing Tools in literature include:

 EXE.EXE Tool
 KLEE Tool
 PEX Tool
 CUTE Tool
 DART Tool
 CREST Tool
N/B: Students are encourage to look into recent literatures and see the techniques used to
develop automated testing tool.
JUnit : Cadre pour le dépistage à l'unité
The JUnit is a unit testing framework for the Java programming language designed by Kent
Beck and Erich Gamma. The idea in the JUnit framework has been ported to other languages,
including C# (NUnit), Python (PyUnit), Fortran (fUnit) and C++ (CPPUnit). This family of
unit testing frameworks is collectively referred to as xUnit. This section will introduce the
fundamental concepts of Junit to the students:
Steps of unit testing
The five steps of unit testing are as follows:

•Create an object and select a method to execute.
•Select values for the input parameters of the method.
•Compute the expected values to be returned by the method.
•Execute the selected method on the created object using the selected input values.
•Verify the result of executing the method.
Performing unit testing leads to a programmer consuming some resources, especially time.
Therefore, it is useful to employ a general programming framework to code individual test
cases, organize a set of test cases as a test suite, initialize a test environment, execute the test
suite, clean up the test environment, and record the result of execution of individual test
cases.
The JUnit framework has been developed to make test writing simple. The framework
provides a basic class, called TestCase, to write test cases. Programmers need to extend the
TestCase class to write a set of individual test cases. It may be noted that to write, for
example, 10 test cases, one need not write 10 subclasses of the class TestCase. Rather, one
subclass, say MyTestCase, of TestCase, can contain 10 methods — one for each test case.
Programmers need to make assertions about the state of objects while extending the TestCase
class to write test cases. For example, in each test case it is required to compare the actual
outcome of a computation with the expected outcome. Though an if() statement can be used
to compare the equality of two values or two objects, it is seen to be more elegant to write an
assert statement to achieve the same. The class TestCase extends a utility class called Assert
in the Junit framework. Essentially, the Assert class provides methods, as explained in the
following, to make assertions about the state of objects created and manipulated while
testing.
asssertTrue(Boolean condition): This assertion passes if the condition is true;
otherwise, it fails.
assertEquals(Object expected, Object actual): This assertion passes if the expected

and the actual objects are equal according to the equals() method;
otherwise, the assertion fails.
assertEquals(int expected, int actual): This assertion passes if expected and
actual are equal according to the == operator; otherwise, the assertion fails.
For each primitive type int, float, double, char, byte, long, short, and boolean,
the assertion has an overloaded version.
assertEquals(double expected, double actual, double tolerance): This assertion passes
if the absolute value of the difference between expected and actual is less than
or equal to the tolerance value; otherwise, the assertion fails. The assertion has
an overloaded version for float inputs.
assertSame(Object expected, Object actual): This assertion passes if the expected and
actual values refer to the same object in memory; otherwise, the assertion fails.
assertNull(Object testobject): This assertion passes if testobject is null; otherwise the

assertion fails.
assertFalse(Boolean condition): This is the logical opposite of assertTrue().
The students may note that the above list of assertions is not exhaustive. Infact, one can build
other assertions while extending the TestCase class. When an assertion fails, a programmer
may want to know immediately the nature of the failure. This can be done by displaying a
message when the assertion fails. Each assertion method listed above accepts an optional first
parameter of type String — if the assertion fails, then the String value is displayed. This
facilitates the programmer to display a desired message when the assertion fails. As an aside,
upon failure, the assertEquals() method displays a customized message showing the expected
value and the actual value. For example, an assertEquals() method can display the following:
junit.framework.AssertionFailedError: expected: <2006> but

was:<2060>.
N/B: Even though JUnit is design mainly for unit testing, it can also be used to write arbitrary
kinds of automated tests, for example, we also use it to test complete scenarios (i.e., module
testing or even system testing).
Coverage Tools
 EclEmma is a free Java coverage tool for Eclipse
Here we see in green which code has been exercised and in red which code has not. By
running your tests with the coverage tool you can quickly discover which code has not been
covered by your test suite.
LECTURE 7: METHODS OF AUTOMATED TESTING cont’d
 Une approche pratique des tests logiciels

 JUnit : Cadre pour le dépistage à l'unité
 Exécution de tests automatisés
 Dérivation de cas de tests automatisés
 Test d'enregistrement en mode analogique et en mode contextuel
 Test de synchronisation
 Vérification des objets GUI
 Vérification des objets Bitmap
 Création d'un test piloté par les données
 Maintien du script de test
 Projet (Création d'un rapport de test dans Bugzilla)
 Developing test cases for a particular project
LECTURE 8: TESTING AND MAINTENANCE
Software maintenance applies to modifications of software already used or delivered to the

market. Constraints associated with this type of test are more important than those associated
with the development of similar new software.
During maintenance, evolutions or fixes are usually caused by external events such as
changes in regulations that translate in a corresponding change in the software. Development
and testing time become a major constraint. Of course it is also paramount to ensure that
there is no impact on other functionalities provided by the software.
There are three main reasons to initiate maintenance tests:
– When the software is modified, updated, when defects are corrected, and when the
operating environment is modified.
– When the software is migrated to a new software or hardware environment;
– When the software or sub-system is retired, which will require its replacement.
The principles associated with maintenance testing is to make sure that all areas that are
changed are correctly changed, and that all areas that are not changed are not changed, either
in form (content), or in terms of supported functionalities.
Maintenance Context
Software is developed during a relatively short period of time, but is used for many years. For
example, Java programs, developed in the late 1990s are still used at this time (about 15 years
later) in most organizations. Maintainability (ability of the software product to be modified,
corrected, improved, or adapted to changes in its environment, in its requirements or its
functional specifications) includes aspects of developers reading and understanding the code,
naming rules for variables and functions, and can include rules on the amount and type of
comments to make the code more readable, and ease its comprehension.
These aspects, which continue long after the software is delivered to its market, have an
impact on the costs – and duration – of fixes before software delivery (ease of defect
identification and correction during the tests phases), and an impact throughout the life of the
software and its maintenance. Taking care of these aspects as early as possible in the
development cycle is thus important and will provide an increased return on investment.
Maintenance évolutive
Evolutive maintenance focuses on the development of new functions in existing software. In

this case it is important to ensure that the new developments do not have any side effects on
the existing functions. Generally, evolutive maintenance does not have the same time
constraints as corrective maintenance.
Example: corrective maintenance includes evolution of the software and the evolution of the
context in which the software operates (interfaces, operating system, etc.).
We may remember the portability issues associated with migration from Windows XP to
Windows Vista, or from a 32 bit system to a 64 bit system, or from a single processor
computer to a multicore machine.
When the environment is modified all the functionalities of the software must remain
available. This is done through the execution of regression tests, which are frequently
functional, on the software and all software with which it exchanges data. End-to-end
functional tests at the acceptance level are another solution.
Maintenance corrective
Corrective maintenance takes into account the correction of defects found by customers or
users. In such cases there are more important time constraints than during evolutive
maintenance.
The first stage is to identify the extent of the modification required, and the tests that are
impacted by the corrections. This will enable evaluation of the effort and duration of changes.
The first stage is to identify the extent of the modification required, and the tests that are
impacted by the corrections. This will enable evaluation of the effort and duration of changes.
In a second stage, the testing activities must focus on two aspects: – ensuring that the
software fits the user’s needs, through:
- Confirmation tests or retesting, to verify that the fixes correct the identified defects,
- Regression tests to ensure no side-effects occur in the rest of the software;

– Analysing the reasons why the defect was allowed to reach the market, in order to improve
existing processes and thus avoid these in the future. Possible causes can include:
• Incorrect risk evaluation and thus incorrect tests of the software,

• Incorrect understanding of the requirements or specifications,
• Test cases or test data that do not fit the test objectives,
• test techniques that were misunderstood or incorrectly implemented,
• Misunderstandings between the stakeholders,
• Etc.
Identification of the root causes of defects that are to be fixed during maintenance enables
process improvement, increases in productivity, efficiency, and effectiveness of the testing
activities.
Retraite et remplacement
When software or systems are retired and replaced, it is also necessary to execute tests. These
can include:
– Verification of the data conversion and data transfer software, to ensure that the data from
the old system or software will be correctly migrated to the new system or software. It is also
necessary to ensure that conversion from the new system to the old works correctly so that if
the new system does not work correctly, a rollback of the data is available;
– Verification of the backup, archival, and restoration of data, to ensure that the software in
charge of conversion of backups and archives are able to process the data from the old
software version, and archive the data from the new software in compatible form. This is
important with regards to mandatory access to archived electronic data;
Politiques de test de régression
We have seen previously that maintenance requires us to ensure that no regression occur on
areas that are not modified. There are different types of regression:
– Modification introduces a new defect;
– Modification exposes a defect that is already present in the software or in the functionality
that was modified;
– Correction or change exposes a defect already present in an unrelated area of the software.
The two first cases can usually be identified through tests in the software area that underwent
the change, while the last case will require exhaustive regression tests throughout the
software.
Regression tests are:
– Either re-execution of all tests designed during the creation of the software, possibly with
an emphasis on system and acceptance tests levels. This re-execution, if manual, can result in
a large (and costly) workload;
– Or re-execution of a sub-set of the above-mentioned tests. It is clear that the selection of

tests that will be included in this sub-set is of paramount importance, so as to avoid holes
(areas that would not be covered correctly and fail to detect regressions) or redundancies
(areas that are tested multiple times without adding any value). (See Bernard Homes, (2012)
for further reading pp. 78-80)
Automated tests can be a solution to execute a large number of tests in a short time frame.
However, the fact that automated tests must be maintained and kept in synch with the
software and its interfaces must be taken into account.
TD 6 Questions
(1) List 5 automated testing tools
(2) What is a regression test? Why is it important?
(3) Why can’t you use tests to demonstrate absence of defects?

(4) Write a program in C++ or VB.Net for computing the grades of 10 students and hence
using PVS perform Unit Testing
(5) Write a program in C++ or VB.Net for the withdrawal of cash from an ATM machine
and hence using PVS perform Unit Testing
Lecture 9: Professional Project Presentation
A Practical Approach to Software Testing
Professional Project Presentation
This will be conducted in four different sessions due to the class size
Lecture 10: General Revision
Professional Project Presentation
PROFESSIONAL PROJECT
 Given two Software development projects, choose any of the given projects of your
choice and a chosen programming language (Java, Python, C++, VB.Net, PHP, etc) develop a
software product for a nominated client and hence perform software testing using at least two
of the techniques done in class:
TOPIC 1: A Decision Support System (DSS) for Teacher Performance Evaluation
TOPIC 2: A Management Information System (MIS) for Time Table Scheduling
 Each group is coordinated by a team leader who acts a project manager. Teams are
required to produce a feasibility report , including Software Requirement
Specification Document and equally depict the Logical design that are in accordance
with currently accepted Software Engineering Principles and Concepts in order to
meet the demands of the industries. These requirements must involve analysis of the
project in details (Functional and Non-Functional Software Requirements)
 The conceptual view of the system must be depicted using either Win Design,
ArgoUML or any other Analysis tool of your choice. (Sequence Diagram, Class
Diagram and State Transition Diagram).
 A Test Case document must be produce in accordance to the functional requirements
of the chosen project. All Test Cases must be indicated in the logical design.
 Perform automated testing using JUnit or any other related automated testing tool
depending on the programming language used.
 Recommend three types of testing approaches for the system with justification and the
significant of each test.
PERFORMANCE EVALUATION CRITERIA

Teacher evaluation procedures require setting up evaluation criteria to determine the level of
performance of individual teachers for each of the aspects assessed. This typically implies the
development of indicators and/or standardised forms to record teacher performance. An
additional criterion is the weighting of the different aspects assessed in order to compute an
overall quantitative rating, in case it is part of the teacher evaluation model. This permits then
to associate the quantitative rating to a qualitative scale, as shown in the table 1 below:
Table 1: PERFORMANCE EVALUATION CRITERIA

Performance Evaluation Criteria Linguistics Assessment Variables
(PEC)
PEC1: Research Productivity and None(0), Very Low(0.2), Low(0.4), Moderate(0.6),
Publication High(0.8), Very High(1.0)
PEC2:Proficicency in Teaching None(0), Very Low(0.2), Low(0.4), Moderate(0.6),
High(0.8), Very High(1.0)
PEC3: Supervision and Creativity None(0), Very Low(0.2), Low(0.4), Moderate(0.6),
PEC4: Students Satisfaction and None(0), Very Low(0.2), Low(0.4), Moderate(0.6),
Performance High(0.8), Very High(1.0)
PEC5: Head Of Department Satisfaction None(0), Very Low(0.2), Low(0.4), Moderate(0.6),
PEC6: Punctuality and Responsibilities None(0), Very Low(0.2), Low(0.4), Moderate(0.6),
PEC7: Academic Awards and None(0), Very Low(0.2), Low(0.4), Moderate(0.6),
Achievements High(0.8), Very High(1.0)
PEC8: Colleagues Opinion None(0), Very Low(0.2), Low(0.4), Moderate(0.6),
PEC9: Professional Ethics None(0), Very Low(0.2), Low(0.4), Moderate(0.6),
PEC10: Opportunities for Professional None(0), Very Low(0.2), Low(0.4), Moderate(0.6),
Development High(0.8), Very High(1.0)
PEC11: Contribution to Institutional None(0), Very Low(0.2), Low(0.4), Moderate(0.6),
Development High(0.8), Very High(1.0)
Teacher Performance Output Unsatisfactory (0.1), Average (0.4), Proficient (0.8),
Outstanding (1.0)
PROJECT CHOICE FORM

Course Code/Course Title: INF563: Software Verification and Validation
Group Number:1
Project Topic:
Group Leader:
Group Members:
Matriculation Name
(1)
(2)
(3)
(4)
(5)
Note:
- All the projects must conform to industrial standards.

- Case Study: Department of Computer Science, University of Yaounde I.
- State clearly a well-defined software methodology and give the reason for the chosen
methodology. (You are require to use eXtream Programming (XP) Approach or any
chosen but appropriate software methodology).
- Project Choice Form must be filled and return before 31th October, 2017
- Project Presentation Date: 14th December, 2017
- Marks will be awarded as follows:
 Software Development and Public Presentation: (20 Marks)

 Project Work (Hard Copy) (10 Marks)
- The following format can be used for the Project Presentation (This is just a guide but
you are not limited to it, you are allow to expand it further)
CHAPTER ONE: INTRODUCTION
 General Introduction
 Aim and Objectives
 Problem Statement
CHAPTER TWO: LITERATURE REVIEW
 Software Development Methodologies
 Comparison between different Software Development Methodologies
 Reason for the choice of Methodology
 General review of related concepts with respect to your chosen project
 Review of related literature with respect to your chosen project
CHAPTER THREE: MATERIAL AND METHOD
 Research Methodology
 Software Requirements
 Software Requirement Specification Document
 A Test Case document
 Proposed Algorithm
 Proposed Model (Mathematical Model or otherwise) for Teacher Performance
Evaluation
 Conceptual View of System
CHAPTER THREE: RESULTS AND DISCUSSIONS
CHAPTER FOUR: RECOMMENDATIONS AND CONCLUSION
LICENSE
You are free:

• to copy, distribute or display the work
• to make derivative works
• to make commercial use of the work
•
Under the following conditions:
Attribution. You must attribute the work in the manner specified by the author or licensor.
Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting
work only under a license identical to this one with referenced to the original author.
• For any reuse or distribution, you must make clear to others the license terms of this
work.
• Any of these conditions can be waived if you get permission from the copyright
holder.
• Your fair use and other rights are in no way affected by the above.

Software Testing FR

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Software Testing FR

Загружено:

Авторское право:

Доступные форматы

Abonnez-vous à DeepL Pro pour éditer ce document.

Visitez www.DeepL.com/Pro pour en savoir plus.

Université de Yaoundé I L'Université de Yaoundé I

VÉRIFICATION ET VALIDATION DE LOGICIELS

CONFÉRENCE 1 : INTRODUCTION AUX TESTS DE LOGICIELS

Qu'est-ce que le test logiciel ?

CONFÉRENCE 2 : MÉTHODOLOGIES DE TEST DES LOGICIELS

Que sont les méthodologies de test logiciel ?

 Test fonctionnel (test de boîte noire)

CONFÉRENCE 3 : TECHNIQUES DE TEST DES BOÎTES BLANCHES :

Mesures/couverture du test des boîtes blanches (critères de sélection des trajectoires)

 Test de flux de données

EXPOSÉ 4 : TECHNIQUES DE TEST DE LA BOÎTE NOIRE

Partitionnement d'équivalence (Partitionnement de classe d'équivalence)

EXPOSÉ 5 : PRINCIPES DE TEST DES LOGICIELS

 Les tests permettent d'identifier la présence de défauts

EXPOSÉ 6 : UNE APPROCHE PRATIQUE DES TESTS LOGICIELS

EXPOSÉ 8 : MÉTHODES D'ESSAI AUTOMATIQUE suite

 Une approche pratique des tests logiciels

EXPOSÉ 9 : TESTS ET MAINTENANCE DE LOGICIELS

EXPOSÉ 10 : UNE PRÉSENTATION PROFESSIONNELLE DU PROJET

EXPOSÉ 11 : Révision générale

3. Génie logiciel : A Practitioner's Approach by Roger S Pressman, 8e édition, McGraw Hill,

CONFÉRENCE 1 : INTRODUCTION AUX TESTS DE LOGICIELS

- Software Testing exécute un programme dans le but de trouver des erreurs.

Le test du système exécute un programme pour vérifier sa fonctionnalité dans le but de

Qu'est-ce que le test logiciel ?

Pourquoi avons-nous besoin de tests logiciels ?

(1) Il existe de nombreux appareils, navigateurs et systèmes d'exploitation différents. Nous

Comparaison avec l'industrie automobile

Comparons le développement du logiciel avec le développement de l'industrie automobile :

- Si l'industrie automobile s'était développée comme l'industrie du logiciel, nous

Relations entre les défauts du logiciel

A partir de l'explication ci-dessus, quels sont les objectifs du Software Testing ?

Objectifs des tests logiciels

Les défis du test logiciel

Essais : Il s'agit de l'identification d'un bug/erreur/défaut dans le logiciel sans le corriger.

Qu'est-ce que la vérification et la validation de logiciels ?

Veriﬁcation Le processus de déterminer si les produits d'une phase donnée du processus de

Ainsi, la vérification se fait au début du processus de développement du logiciel (phase de

Il répond aux questions du genre :

Avantages de la vérification logicielle :

1. La vérification aide à réduire le nombre de défauts dans les stades ultérieurs du

2. La vérification du produit au début de la phase de développement aidera à mieux

3. Il réduit les risques de défaillance de l'application logicielle ou du produit.

4. Il aide à construire le produit selon les spécifications et les besoins du client.

Validation : Le processus d'évaluation du logiciel à la fin de chaque phase de développement

La validation peut également être définie comme le processus d'évaluation du logiciel à la

 C'est une activité de haut niveau.

 Détermination de l'exactitude du produit logiciel final par un projet de développement

Exemples d'artefacts (items) à valider :

 Validation de la spécification des besoins de l'utilisateur : Les besoins des utilisateurs,

La vérification du logiciel peut également être définie comme le processus d'évaluation du

Quelques exemples d'éléments doivent être vérifiés :

 Vérification des spécifications de conception par rapport aux spécifications des

 Vérification des artefacts de mise en œuvre par rapport aux spécifications de

Vérification et validation des logiciels

Les objectifs de la vérification et de la validation des logiciels

L'objectif de la validation d'un logiciel est de gagner la confiance de l'utilisateur en

Techniques de vérification et de validation des logiciels

Il existe quatre techniques principales de vérification et de validation. Ils incluent :

- Analyse et méthodes informelles

 Techniques informelles de V&V : Les techniques informelles de V&V sont parmi

 Techniques V&V statiques : Les techniques de V&V statique évaluent la précision