Test de logiciel - Guide rapide

Qu'est-ce que le test?

Le test 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. En termes simples, le test exécute un système afin d'identifier les lacunes, les erreurs ou les exigences manquantes contrairement aux exigences réelles.

Selon la norme ANSI / IEEE 1059, le test peut être défini comme - Un processus d'analyse d'un élément logiciel pour détecter les différences entre les conditions existantes et requises (c'est-à-dire les défauts / erreurs / bogues) et pour évaluer les fonctionnalités de l'élément logiciel.

Qui fait le test?

Cela dépend du processus et des parties prenantes associées au (x) projet (s). Dans le secteur informatique, les grandes entreprises disposent d'une équipe chargée d'évaluer le logiciel développé dans le contexte des exigences données. De plus, les développeurs effectuent également des tests appelésUnit Testing. Dans la plupart des cas, les professionnels suivants sont impliqués dans le test d'un système dans leurs capacités respectives -

• Testeur de logiciels
• Développeur de logiciels
• Chef de projet / gestionnaire
• Utilisateur final

Différentes entreprises ont des désignations différentes pour les personnes qui testent le logiciel sur la base de leur expérience et de leurs connaissances, telles que testeur de logiciels, ingénieur en assurance qualité logicielle, analyste d'assurance qualité, etc.

Il n'est pas possible de tester le logiciel à aucun moment de son cycle. Les deux sections suivantes indiquent quand le test doit être démarré et quand le terminer pendant le SDLC.

Quand commencer les tests?

Un démarrage précoce des tests réduit le coût et le temps nécessaires pour retravailler et produire des logiciels sans erreur livrés au client. Cependant, dans le cycle de vie du développement logiciel (SDLC), les tests peuvent être lancés à partir de la phase de collecte des exigences et se poursuivre jusqu'au déploiement du logiciel.

Cela dépend également du modèle de développement utilisé. Par exemple, dans le modèle Waterfall, des tests formels sont effectués lors de la phase de test; mais dans le modèle incrémental, le test est effectué à la fin de chaque incrément / itération et l'application entière est testée à la fin.

Les tests sont effectués sous différentes formes à chaque phase du SDLC -

• Au cours de la phase de collecte des exigences, l'analyse et la vérification des exigences sont également considérées comme des tests.

• L'examen de la conception dans la phase de conception dans le but d'améliorer la conception est également considéré comme un test.

• Les tests effectués par un développeur à la fin du code sont également classés comme des tests.

Quand arrêter les tests?

Il est difficile de déterminer quand arrêter les tests, car les tests sont un processus sans fin et personne ne peut prétendre qu'un logiciel est testé à 100%. Les aspects suivants doivent être pris en compte pour arrêter le processus de test -

• Dates limites des tests

• Achèvement de l'exécution du scénario de test

• Achèvement de la couverture fonctionnelle et du code jusqu'à un certain point

• Le taux de bogues tombe en dessous d'un certain niveau et aucun bogue hautement prioritaire n'est identifié

• Décision de gestion

Vérification validation

Ces deux termes sont très déroutants pour la plupart des gens, qui les utilisent de manière interchangeable. Le tableau suivant met en évidence les différences entre la vérification et la validation.

Sr.No.	Vérification	Validation
1	La vérification répond à la préoccupation: "Construisez-vous correctement?"	La validation répond à la préoccupation: "Construisez-vous la bonne chose?"
2	S'assure que le système logiciel répond à toutes les fonctionnalités.	S'assure que les fonctionnalités répondent au comportement prévu.
3	La vérification a lieu en premier et comprend la vérification de la documentation, du code, etc.	La validation intervient après vérification et implique principalement la vérification de l'ensemble du produit.
4	Fait par les développeurs.	Fait par les testeurs.
5	Il a des activités statiques, car il comprend la collecte d'examens, de procédures pas à pas et d'inspections pour vérifier un logiciel.	Il a des activités dynamiques, car il comprend l'exécution du logiciel par rapport aux exigences.
6	Il s'agit d'un processus objectif et aucune décision subjective ne devrait être nécessaire pour vérifier un logiciel.	Il s'agit d'un processus subjectif qui implique des décisions subjectives sur le fonctionnement d'un logiciel.

Voici quelques-uns des mythes les plus courants sur les tests de logiciels.

Mythe 1: les tests sont trop coûteux

Reality- Il y a un dicton, payez moins pour les tests pendant le développement du logiciel ou payez plus pour la maintenance ou la correction plus tard. Les premiers tests permettent d'économiser du temps et des coûts dans de nombreux aspects, mais la réduction du coût sans test peut entraîner une conception incorrecte d'une application logicielle rendant le produit inutile.

Mythe 2: Les tests prennent du temps

Reality- Pendant les phases SDLC, les tests ne sont jamais un processus chronophage. Cependant, diagnostiquer et corriger les erreurs identifiées lors de tests appropriés est une activité longue mais productive.

Mythe 3: Seuls les produits entièrement développés sont testés

Reality- Il ne fait aucun doute que les tests dépendent du code source, mais l'examen des exigences et le développement des cas de test sont indépendants du code développé. Cependant, une approche itérative ou incrémentale en tant que modèle de cycle de vie de développement peut réduire la dépendance des tests sur le logiciel entièrement développé.

Mythe 4: Un test complet est possible

Reality- Cela devient un problème lorsqu'un client ou un testeur pense qu'un test complet est possible. Il est possible que tous les chemins aient été testés par l'équipe mais la réalisation de tests complets n'est jamais possible. Il peut y avoir des scénarios qui ne sont jamais exécutés par l'équipe de test ou le client pendant le cycle de vie du développement logiciel et peuvent être exécutés une fois le projet déployé.

Mythe 5: Un logiciel testé est sans bogue

Reality - C'est un mythe très courant auquel les clients, les chefs de projet et l'équipe de direction croient. Personne ne peut affirmer avec une certitude absolue qu'une application logicielle est 100% sans bogue, même si un testeur doté de superbes compétences en test a testé l'application .

Mythe 6: les défauts manqués sont dus aux testeurs

Reality- Ce n'est pas une approche correcte pour blâmer les testeurs pour les bogues qui restent dans l'application même après que les tests ont été effectués. Ce mythe concerne les contraintes de changement de temps, de coût et d'exigences. Cependant, la stratégie de test peut également entraîner des bogues manqués par l'équipe de test.

Mythe 7: Les testeurs sont responsables de la qualité du produit

Reality- C'est une mauvaise interprétation très courante que seuls les testeurs ou l'équipe de test devraient être responsables de la qualité du produit. Les responsabilités des testeurs incluent l'identification des bogues aux parties prenantes, puis c'est à eux de décider s'ils vont corriger le bogue ou publier le logiciel. La sortie du logiciel à l'époque met plus de pression sur les testeurs, car ils seront blâmés pour toute erreur.

Mythe 8: l'automatisation des tests doit être utilisée dans la mesure du possible pour réduire le temps

Reality- Oui, il est vrai que l'automatisation des tests réduit le temps de test, mais il n'est pas possible de démarrer l'automatisation des tests à tout moment pendant le développement logiciel. L'automate de test doit être démarré lorsque le logiciel a été testé manuellement et est stable dans une certaine mesure. De plus, l'automatisation des tests ne peut jamais être utilisée si les exigences changent constamment.

Mythe 9: Tout le monde peut tester une application logicielle

Reality- Les personnes extérieures à l'industrie informatique pensent et même croient que n'importe qui peut tester un logiciel et tester n'est pas un travail créatif. Cependant, les testeurs savent très bien qu'il s'agit d'un mythe. Penser à des scénarios alternatifs, essayer de planter un logiciel avec l'intention d'explorer des bogues potentiels n'est pas possible pour la personne qui l'a développé.

Mythe 10: La seule tâche d'un testeur est de trouver des bogues

Reality- La recherche de bogues dans un logiciel est la tâche des testeurs, mais en même temps, ce sont des experts du domaine du logiciel en question. Les développeurs ne sont responsables que du composant ou du domaine spécifique qui leur est assigné, mais les testeurs comprennent le fonctionnement général du logiciel, quelles sont les dépendances et les impacts d'un module sur un autre module.

Essais, assurance qualité et contrôle qualité

La plupart des gens sont confus lorsqu'il s'agit de cerner les différences entre l'assurance qualité, le contrôle qualité et les tests. Bien qu'elles soient interdépendantes et dans une certaine mesure, elles peuvent être considérées comme les mêmes activités, mais il existe des points distinctifs qui les distinguent. Le tableau suivant répertorie les points qui différencient QA, QC et Testing.

Assurance qualité	Contrôle de qualité	Essai
L'AQ comprend des activités qui assurent la mise en œuvre des processus, des procédures et des normes dans le contexte de la vérification des logiciels développés et des exigences prévues.	Il comprend des activités qui assurent la vérification d'un logiciel développé par rapport aux exigences documentées (ou non dans certains cas).	Il comprend des activités qui assurent l'identification des bogues / erreurs / défauts d'un logiciel.
Se concentre sur les processus et les procédures plutôt que sur la réalisation de tests réels sur le système.	Se concentre sur les tests réels en exécutant le logiciel dans le but d'identifier les bogues / défauts grâce à la mise en œuvre de procédures et de processus.	Se concentre sur les tests réels.
Activités orientées processus.	Activités orientées produit.	Activités orientées produit.
Activités préventives.	C'est un processus correctif.	C'est un processus préventif.
Il s'agit d'un sous-ensemble du cycle de vie des tests logiciels (STLC).	Le CQ peut être considéré comme le sous-ensemble de l'assurance qualité.	Les tests sont le sous-ensemble du contrôle qualité.

Audit et inspection

Audit- Il s'agit d'un processus systématique pour déterminer comment le processus de test réel est conduit au sein d'une organisation ou d'une équipe. En général, il s'agit d'un examen indépendant des processus impliqués lors du test d'un logiciel. Conformément à l'IEEE, il s'agit d'un examen des processus documentés que les organisations mettent en œuvre et suivent. Les types d'audit comprennent l'audit de conformité juridique, l'audit interne et l'audit système.

Inspection- C'est une technique formelle qui implique des examens techniques formels ou informels de tout artefact en identifiant toute erreur ou lacune. Conformément à la norme IEEE94, l'inspection est une technique d'évaluation formelle dans laquelle les exigences logicielles, les conceptions ou les codes sont examinés en détail par une personne ou un groupe autre que l'auteur pour détecter les défauts, les violations des normes de développement et d'autres problèmes.

Les réunions d'inspection formelles peuvent inclure les processus suivants: planification, préparation de la vue d'ensemble, réunion d'inspection, retouche et suivi.

Test et débogage

Testing- Il s'agit d'identifier un bug / une erreur / un défaut dans un logiciel sans le corriger. Normalement, des professionnels ayant une formation en assurance qualité sont impliqués dans l'identification des bogues. Le test est effectué dans la phase de test.

Debugging- Il s'agit d'identifier, d'isoler et de corriger les problèmes / bogues. Les développeurs qui codent le logiciel effectuent le débogage lorsqu'ils rencontrent une erreur dans le code. Le débogage fait partie des tests en boîte blanche ou des tests unitaires. Le débogage peut être effectué dans la phase de développement tout en effectuant des tests unitaires ou en phases lors de la correction des bogues signalés.

De nombreuses organisations à travers le monde développent et mettent en œuvre différentes normes pour améliorer les besoins de qualité de leurs logiciels. Ce chapitre décrit brièvement quelques-unes des normes largement utilisées liées à l'assurance qualité et aux tests.

ISO / CEI 9126

Cette norme traite des aspects suivants pour déterminer la qualité d'une application logicielle -

• Modèle de qualité
• Métriques externes
• Mesures internes
• Mesures de qualité d'utilisation

Cette norme présente un ensemble d'attributs de qualité pour tout logiciel tel que -

• Functionality
• Reliability
• Usability
• Efficiency
• Maintainability
• Portability

Les attributs de qualité mentionnés ci-dessus sont ensuite divisés en sous-facteurs, que vous pouvez étudier lorsque vous étudiez la norme en détail.

ISO / CEI 9241-11

La partie 11 de cette norme traite de la mesure dans laquelle un produit peut être utilisé par des utilisateurs spécifiés pour atteindre des objectifs spécifiés avec efficacité, efficience et satisfaction dans un contexte d'utilisation spécifié.

Cette norme a proposé un cadre qui décrit les composants d'utilisabilité et la relation entre eux. Dans cette norme, la convivialité est considérée en termes de performances et de satisfaction des utilisateurs. Selon l'ISO 9241-11, la convivialité dépend du contexte d'utilisation et le niveau d'utilisation changera à mesure que le contexte change.

ISO / CEI 25000: 2005

ISO / CEI 25000: 2005 est communément connue comme la norme qui fournit les lignes directrices pour les exigences de qualité logicielle et l'évaluation (SQuaRE). Cette norme aide à organiser et à améliorer le processus lié aux exigences de qualité des logiciels et à leurs évaluations. En réalité, ISO-25000 remplace les deux anciennes normes ISO, à savoir ISO-9126 et ISO-14598.

SQuaRE est divisé en sous-parties telles que -

• ISO 2500n - Division de la gestion de la qualité
• ISO 2501n - Division des modèles de qualité
• ISO 2502n - Division de la mesure de la qualité
• ISO 2503n - Division des exigences de qualité
• ISO 2504n - Division de l'évaluation de la qualité

Les principaux contenus de SQuaRE sont -

• Termes et définitions
• Modèles de référence
• Guide général
• Guides de division individuels
• Norme relative à l'ingénierie des exigences (c.-à-d. Processus de spécification, de planification, de mesure et d'évaluation)

ISO / CEI 12119

Cette norme traite des progiciels livrés au client. Il ne se concentre pas et ne traite pas du processus de production des clients. Le contenu principal est lié aux éléments suivants -

• Ensemble d'exigences pour les progiciels.
• Instructions pour tester un progiciel livré par rapport aux exigences spécifiées.

Divers

Certaines des autres normes liées à l'AQ et aux processus de test sont mentionnées ci-dessous -

Sr. Non	Norme et description
1	IEEE 829 Une norme pour le format des documents utilisés à différentes étapes des tests logiciels.
2	IEEE 1061 Une méthodologie pour établir les exigences de qualité, identifier, mettre en œuvre, analyser et valider le processus et le produit des mesures de qualité des logiciels.
3	IEEE 1059 Guide des plans de vérification et de validation des logiciels.
4	IEEE 1008 Une norme pour les tests unitaires.
5	IEEE 1012 Une norme pour la vérification et la validation des logiciels.
6	IEEE 1028 Une norme pour les inspections de logiciels.
sept	IEEE 1044 Une norme pour la classification des anomalies logicielles.
8	IEEE 1044-1 Un guide pour la classification des anomalies logicielles.
9	IEEE 830 Un guide pour l'élaboration des spécifications d'exigences système.
dix	IEEE 730 Une norme pour les plans d'assurance qualité des logiciels.
11	IEEE 1061 Une norme pour les mesures et la méthodologie de la qualité des logiciels.
12	IEEE 12207 Une norme pour les processus du cycle de vie logiciel et les données du cycle de vie.
13	BS 7925-1 Un vocabulaire de termes utilisés dans les tests de logiciels.
14	BS 7925-2 Une norme pour les tests de composants logiciels.

Cette section décrit les différents types de tests qui peuvent être utilisés pour tester un logiciel pendant le SDLC.

Test manuel

Le test manuel comprend le test manuel d'un logiciel, c'est-à-dire sans utiliser d'outil automatisé ou de script. Dans ce type, le testeur prend le rôle d'un utilisateur final et teste le logiciel pour identifier tout comportement ou bogue inattendu. Il existe différentes étapes pour les tests manuels tels que les tests unitaires, les tests d'intégration, les tests système et les tests d'acceptation des utilisateurs.

Les testeurs utilisent des plans de test, des cas de test ou des scénarios de test pour tester un logiciel afin de garantir l'exhaustivité des tests. Les tests manuels comprennent également des tests exploratoires, car les testeurs explorent le logiciel pour identifier les erreurs qu'il contient.

Test d'automatisation

Les tests d'automatisation, également connus sous le nom d'automatisation des tests, se produisent lorsque le testeur écrit des scripts et utilise un autre logiciel pour tester le produit. Ce processus implique l'automatisation d'un processus manuel. Les tests d'automatisation sont utilisés pour réexécuter les scénarios de test qui ont été effectués manuellement, rapidement et à plusieurs reprises.

Outre les tests de régression, les tests d'automatisation sont également utilisés pour tester l'application du point de vue de la charge, des performances et des contraintes. Il augmente la couverture des tests, améliore la précision et économise du temps et de l'argent par rapport aux tests manuels.

Que automatiser?

Il n'est pas possible de tout automatiser dans un logiciel. Les zones dans lesquelles un utilisateur peut effectuer des transactions telles que le formulaire de connexion ou les formulaires d'inscription, toute zone où un grand nombre d'utilisateurs peuvent accéder simultanément au logiciel doivent être automatisées.

De plus, tous les éléments de l'interface graphique, les connexions avec les bases de données, les validations sur le terrain, etc. peuvent être testés efficacement en automatisant le processus manuel.

Quand automatiser?

L'automatisation des tests doit être utilisée en tenant compte des aspects suivants d'un logiciel -

• Projets importants et critiques
• Projets qui nécessitent de tester fréquemment les mêmes zones
• Les exigences ne changent pas fréquemment
• Accès à l'application pour la charge et les performances avec de nombreux utilisateurs virtuels
• Logiciel stable par rapport aux tests manuels
• Disponibilité du temps

Comment automatiser?

L'automatisation est effectuée à l'aide d'un langage informatique de soutien comme le script VB et une application logicielle automatisée. Il existe de nombreux outils disponibles qui peuvent être utilisés pour écrire des scripts d'automatisation. Avant de mentionner les outils, identifions le processus qui peut être utilisé pour automatiser le processus de test -

• Identifier les zones dans un logiciel pour l'automatisation
• Sélection de l'outil approprié pour l'automatisation des tests
• Rédaction de scripts de test
• Développement de combinaisons de test
• Exécution de scripts
• Créer des rapports de résultats
• Identifiez les éventuels bogues ou problèmes de performances

Outils de test de logiciels

Les outils suivants peuvent être utilisés pour les tests d'automatisation -

• Professionnel de test rapide HP
• Selenium
• IBM Rational Functional Tester
• SilkTest
• TestComplete
• Tester n'importe où
• WinRunner
• LoadRunner
• Professionnel de test Visual Studio
• WATIR

Il existe différentes méthodes qui peuvent être utilisées pour les tests logiciels. Ce chapitre décrit brièvement les méthodes disponibles.

Test en boîte noire

La technique de test sans avoir aucune connaissance du fonctionnement intérieur de l'application s'appelle le test de la boîte noire. Le testeur est inconscient de l'architecture du système et n'a pas accès au code source. En règle générale, tout en effectuant un test boîte noire, un testeur interagit avec l'interface utilisateur du système en fournissant des entrées et en examinant les sorties sans savoir comment et où les entrées sont utilisées.

Le tableau suivant répertorie les avantages et les inconvénients des tests en boîte noire.

Avantages	Désavantages
Bien adapté et efficace pour les grands segments de code.	Couverture limitée, car seul un certain nombre de scénarios de test est réellement exécuté.
L'accès au code n'est pas requis.	Tests inefficaces, en raison du fait que le testeur n'a qu'une connaissance limitée d'une application.
Sépare clairement le point de vue de l'utilisateur du point de vue du développeur grâce à des rôles visiblement définis.	Couverture aveugle, car le testeur ne peut pas cibler des segments de code spécifiques ou des zones sujettes à des erreurs.
Un grand nombre de testeurs moyennement qualifiés peuvent tester l'application sans aucune connaissance de l'implémentation, du langage de programmation ou des systèmes d'exploitation.	Les cas de test sont difficiles à concevoir.

Test en boîte blanche

Les tests en boîte blanche consistent en une étude détaillée de la logique interne et de la structure du code. Le test en boîte blanche est également appeléglass testing ou open-box testing. Pour effectuerwhite-box testant sur une application, un testeur doit connaître le fonctionnement interne du code.

Le testeur doit jeter un coup d'œil à l'intérieur du code source et découvrir quelle unité / morceau de code se comporte de manière inappropriée.

Le tableau suivant répertorie les avantages et les inconvénients des tests en boîte blanche.

Avantages	Désavantages
Comme le testeur connaît le code source, il devient très facile de savoir quel type de données peut aider à tester efficacement l'application.	En raison du fait qu'un testeur qualifié est nécessaire pour effectuer des tests en boîte blanche, les coûts sont augmentés.
Cela aide à optimiser le code.	Parfois, il est impossible de rechercher dans tous les coins et recoins pour trouver des erreurs cachées qui peuvent créer des problèmes, car de nombreux chemins ne seront pas testés.
Des lignes de code supplémentaires peuvent être supprimées, ce qui peut entraîner des vices cachés.	Il est difficile de maintenir les tests en boîte blanche, car cela nécessite des outils spécialisés tels que des analyseurs de code et des outils de débogage.
En raison des connaissances du testeur sur le code, la couverture maximale est atteinte lors de l'écriture du scénario de test.

Test de la boîte grise

Le test en boîte grise est une technique permettant de tester l'application en ayant une connaissance limitée du fonctionnement interne d'une application. Dans les tests de logiciels, l'expression plus vous en savez, mieux vaut avoir beaucoup de poids lors du test d'une application.

La maîtrise du domaine d'un système donne toujours au testeur un avantage sur une personne ayant une connaissance limitée du domaine. Contrairement aux tests boîte noire, où le testeur teste uniquement l'interface utilisateur de l'application; dans les tests en boîte grise, le testeur a accès aux documents de conception et à la base de données. Ayant ces connaissances, un testeur peut préparer de meilleures données de test et des scénarios de test tout en élaborant un plan de test.

Avantages	Désavantages
Offre les avantages combinés des tests boîte noire et boîte blanche dans la mesure du possible.	Étant donné que l'accès au code source n'est pas disponible, la possibilité de parcourir le code et de tester la couverture est limitée.
Les testeurs de la boîte grise ne s'appuient pas sur le code source; au lieu de cela, ils s'appuient sur la définition de l'interface et les spécifications fonctionnelles.	Les tests peuvent être redondants si le concepteur du logiciel a déjà exécuté un cas de test.
Sur la base des informations limitées disponibles, un testeur à boîte grise peut concevoir d'excellents scénarios de test, en particulier autour des protocoles de communication et de la gestion des types de données.	Tester tous les flux d'entrée possibles est irréaliste car cela prendrait un temps déraisonnable; par conséquent, de nombreux chemins d'accès aux programmes ne seront pas testés.
Le test se fait du point de vue de l'utilisateur et non du concepteur.

Une comparaison des méthodes de test

Le tableau suivant répertorie les points qui différencient les tests boîte noire, les tests boîte grise et les tests boîte blanche.

Test en boîte noire	Test de la boîte grise	Test en boîte blanche
Le fonctionnement interne d'une application n'a pas besoin d'être connu.	Le testeur a une connaissance limitée du fonctionnement interne de l'application.	Le testeur a une connaissance complète du fonctionnement interne de l'application.
Également connu sous le nom de test en boîte fermée, de test basé sur les données ou de test fonctionnel.	Également connu sous le nom de test translucide, car le testeur a une connaissance limitée de l'intérieur de l'application.	Également connu sous le nom de test clair, de test structurel ou de test basé sur un code.
Réalisé par les utilisateurs finaux ainsi que par les testeurs et les développeurs.	Réalisé par les utilisateurs finaux ainsi que par les testeurs et les développeurs.	Normalement fait par les testeurs et les développeurs.
Les tests sont basés sur des attentes externes - Le comportement interne de l'application est inconnu.	Les tests sont effectués sur la base de diagrammes de base de données de haut niveau et de diagrammes de flux de données.	Le fonctionnement interne est parfaitement connu et le testeur peut concevoir les données de test en conséquence.
C'est exhaustif et le moins chronophage.	En partie chronophage et exhaustif.	Le type de test le plus exhaustif et le plus chronophage.
Ne convient pas aux tests d'algorithmes.	Ne convient pas aux tests d'algorithmes.	Convient pour les tests d'algorithmes.
Cela ne peut être fait que par une méthode d'essai et d'erreur.	Les domaines de données et les limites internes peuvent être testés, s'ils sont connus.	Les domaines de données et les limites internes peuvent être mieux testés.

Il existe différents niveaux au cours du processus de test. Dans ce chapitre, une brève description de ces niveaux est fournie.

Les niveaux de test incluent différentes méthodologies qui peuvent être utilisées lors des tests de logiciels. Les principaux niveaux de tests logiciels sont:

• Test fonctionel

• Test non fonctionnel

Test fonctionel

Il s'agit d'un type de test de boîte noire basé sur les spécifications du logiciel à tester. L'application est testée en fournissant une entrée, puis les résultats sont examinés qui doivent se conformer à la fonctionnalité pour laquelle elle était prévue. Les tests fonctionnels d'un logiciel sont effectués sur un système complet et intégré pour évaluer la conformité du système aux exigences spécifiées.

Il y a cinq étapes qui sont impliquées lors du test de fonctionnalité d'une application.

Pas	La description
je	La détermination de la fonctionnalité que l'application prévue est censée exécuter.
II	La création de données de test en fonction des spécifications de l'application.
III	La sortie basée sur les données de test et les spécifications de l'application.
IV	L'écriture de scénarios de test et l'exécution de cas de test.
V	La comparaison des résultats réels et attendus en fonction des cas de test exécutés.

Une pratique de test efficace verra les étapes ci-dessus appliquées aux politiques de test de chaque organisation et s'assurera donc que l'organisation maintient les normes les plus strictes en matière de qualité logicielle.

Test unitaire

Ce type de test est effectué par les développeurs avant que la configuration ne soit remise à l'équipe de test pour exécuter formellement les cas de test. Les tests unitaires sont effectués par les développeurs respectifs sur les unités individuelles des zones attribuées au code source. Les développeurs utilisent des données de test différentes des données de test de l'équipe d'assurance qualité.

Le but des tests unitaires est d'isoler chaque partie du programme et de montrer que les différentes parties sont correctes en termes d'exigences et de fonctionnalités.

Limitations des tests unitaires

Les tests ne peuvent pas détecter tous les bogues d'une application. Il est impossible d'évaluer chaque chemin d'exécution dans chaque application logicielle. Il en va de même pour les tests unitaires.

Il existe une limite au nombre de scénarios et de données de test qu'un développeur peut utiliser pour vérifier un code source. Après avoir épuisé toutes les options, il n'y a pas d'autre choix que d'arrêter les tests unitaires et de fusionner le segment de code avec d'autres unités.

Test d'intégration

Les tests d'intégration sont définis comme les tests de parties combinées d'une application pour déterminer si elles fonctionnent correctement. Les tests d'intégration peuvent être effectués de deux manières: les tests d'intégration ascendante et les tests d'intégration descendants.

Sr.No.	Méthode de test d'intégration
1	Bottom-up integration Ces tests commencent par des tests unitaires, suivis de tests de combinaisons d'unités progressivement de plus haut niveau appelées modules ou builds.
2	Top-down integration Dans ce test, les modules de niveau le plus élevé sont testés en premier et progressivement, les modules de niveau inférieur sont testés par la suite.

Dans un environnement de développement logiciel complet, les tests ascendants sont généralement effectués en premier, suivis des tests descendants. Le processus se termine par plusieurs tests de l'application complète, de préférence dans des scénarios conçus pour imiter des situations réelles.

Test du système

Le test du système teste le système dans son ensemble. Une fois tous les composants intégrés, l'application dans son ensemble est testée rigoureusement pour vérifier qu'elle répond aux normes de qualité spécifiées. Ce type de test est effectué par une équipe de test spécialisée.

Les tests du système sont importants pour les raisons suivantes -

• Le test du système est la première étape du cycle de vie du développement logiciel, où l'application est testée dans son ensemble.

• L'application est testée minutieusement pour vérifier qu'elle répond aux spécifications fonctionnelles et techniques.

• L'application est testée dans un environnement très proche de l'environnement de production où l'application sera déployée.

• Les tests système nous permettent de tester, vérifier et valider à la fois les exigences de l'entreprise et l'architecture de l'application.

Les tests de régression

Chaque fois qu'une modification est apportée à une application logicielle, il est fort possible que d'autres zones de l'application aient été affectées par cette modification. Les tests de régression sont effectués pour vérifier qu'un bogue corrigé n'a pas entraîné une autre violation de fonctionnalité ou de règle métier. Le but des tests de régression est de s'assurer qu'une modification, telle qu'une correction de bogue, ne doit pas entraîner la découverte d'une autre erreur dans l'application.

Les tests de régression sont importants pour les raisons suivantes -

• Minimisez les lacunes dans les tests lorsqu'une application avec des modifications apportées doit être testée.

• Tester les nouvelles modifications pour vérifier que les modifications apportées n'ont affecté aucun autre domaine de l'application.

• Atténue les risques lorsque des tests de régression sont effectués sur l'application.

• La couverture des tests est augmentée sans compromettre les délais.

• Augmentez la vitesse de commercialisation du produit.

Test d'acceptation

C'est sans doute le type de test le plus important, car il est effectué par l'équipe d'assurance qualité qui évaluera si l'application répond aux spécifications prévues et satisfait aux exigences du client. L'équipe d'assurance qualité disposera d'un ensemble de scénarios et de cas de test pré-écrits qui seront utilisés pour tester l'application.

Plus d'idées seront partagées sur l'application et plus de tests pourront être effectués dessus pour évaluer sa précision et les raisons pour lesquelles le projet a été lancé. Les tests d'acceptation ne visent pas seulement à signaler de simples fautes d'orthographe, des erreurs esthétiques ou des lacunes d'interface, mais également à signaler tout bogue dans l'application qui entraînera des pannes du système ou des erreurs majeures dans l'application.

En effectuant des tests d'acceptation sur une application, l'équipe de test réduira les performances de l'application en production. Il existe également des exigences légales et contractuelles pour l'acceptation du système.

Test alpha

Ce test est la première étape des tests et sera réalisé entre les équipes (développeurs et équipes QA). Les tests unitaires, les tests d'intégration et les tests système lorsqu'ils sont combinés sont appelés tests alpha. Au cours de cette phase, les aspects suivants seront testés dans l'application -

• Fautes d'orthographe

• Liens brisés

• Directions nuageuses

• L'application sera testée sur des machines avec les spécifications les plus basses pour tester les temps de chargement et les éventuels problèmes de latence.

Tests bêta

Ce test est effectué une fois que le test alpha a été effectué avec succès. Lors des tests bêta, un échantillon du public cible teste l'application. Les tests bêta sont également connus sous le nom depre-release testing. Les versions de test bêta du logiciel sont idéalement distribuées à un large public sur le Web, en partie pour donner au programme un test "réel" et en partie pour fournir un aperçu de la prochaine version. Dans cette phase, le public testera les éléments suivants -

• Les utilisateurs installeront, exécuteront l'application et enverront leurs commentaires à l'équipe du projet.

• Erreurs typographiques, flux d'application déroutant et même plantages.

• En obtenant les commentaires, l'équipe de projet peut résoudre les problèmes avant de diffuser le logiciel aux utilisateurs réels.

• Plus vous résolvez de problèmes qui résolvent de vrais problèmes d'utilisateurs, plus la qualité de votre application sera élevée.

• Avoir une application de meilleure qualité lorsque vous la publiez au grand public augmentera la satisfaction des clients.

Tests non fonctionnels

Cette section est basée sur le test d'une application à partir de ses attributs non fonctionnels. Les tests non fonctionnels consistent à tester un logiciel à partir des exigences qui sont de nature non fonctionnelle mais importantes telles que les performances, la sécurité, l'interface utilisateur, etc.

Certains des types de tests non fonctionnels importants et couramment utilisés sont décrits ci-dessous.

Test de performance

Il est principalement utilisé pour identifier les goulots d'étranglement ou les problèmes de performances plutôt que pour trouver des bogues dans un logiciel. Il existe différentes causes qui contribuent à réduire les performances d'un logiciel -

• Retard du réseau

• Traitement côté client

• Traitement des transactions de base de données

• Équilibrage de charge entre les serveurs

• Rendu des données

Les tests de performance sont considérés comme l'un des types de tests importants et obligatoires en ce qui concerne les aspects suivants:

• Vitesse (c.-à-d. Temps de réponse, rendu et accès aux données)

• Capacity

• Stability

• Scalability

Les tests de performance peuvent être qualitatifs ou quantitatifs et peuvent être divisés en différents sous-types tels que Load testing et Stress testing.

Test de charge

Il s'agit d'un processus de test du comportement d'un logiciel en appliquant une charge maximale en termes d'accès au logiciel et de manipulation de grandes données d'entrée. Cela peut être fait à la fois dans des conditions de charge normales et de pointe. Ce type de test identifie la capacité maximale du logiciel et son comportement aux heures de pointe.

La plupart du temps, les tests de charge sont effectués à l'aide d'outils automatisés tels que Load Runner, AppLoader, IBM Rational Performance Tester, Apache JMeter, Silk Performer, Visual Studio Load Test, etc.

Les utilisateurs virtuels (VUsers) sont définis dans l'outil de test automatisé et le script est exécuté pour vérifier le test de charge du logiciel. Le nombre d'utilisateurs peut être augmenté ou diminué simultanément ou progressivement en fonction des besoins.

Test de stress

Les tests de résistance comprennent le test du comportement d'un logiciel dans des conditions anormales. Par exemple, cela peut inclure la suppression de certaines ressources ou l'application d'une charge au-delà de la limite de charge réelle.

Le but des tests de résistance est de tester le logiciel en appliquant la charge au système et en prenant en charge les ressources utilisées par le logiciel pour identifier le point de rupture. Ce test peut être effectué en testant différents scénarios tels que -

• Arrêt ou redémarrage des ports réseau de manière aléatoire

• Activer ou désactiver la base de données

• Exécuter différents processus qui consomment des ressources telles que le processeur, la mémoire, le serveur, etc.

Tests d'utilisation

Les tests d'utilisabilité sont une technique de boîte noire et sont utilisés pour identifier toute (s) erreur (s) et améliorations du logiciel en observant les utilisateurs à travers leur utilisation et leur fonctionnement.

Selon Nielsen, la convivialité peut être définie en termes de cinq facteurs, à savoir l'efficacité d'utilisation, la capacité d'apprentissage, la capacité de mémoire, les erreurs / la sécurité et la satisfaction. Selon lui, l'utilisabilité d'un produit sera bonne et le système est utilisable s'il possède les facteurs ci-dessus.

Nigel Bevan et Macleod considèrent que la convivialité est l'exigence de qualité qui peut être mesurée comme le résultat d'interactions avec un système informatique. Cette exigence peut être remplie et l'utilisateur final sera satisfait si les objectifs visés sont atteints efficacement avec l'utilisation de ressources appropriées.

Molich a déclaré en 2000 qu'un système convivial devrait remplir les cinq objectifs suivants: facile à apprendre, facile à retenir, efficace à utiliser, satisfaisant à utiliser et facile à comprendre.

En plus des différentes définitions de l'utilisabilité, il existe des normes et des modèles et méthodes de qualité qui définissent l'utilisabilité sous la forme d'attributs et de sous-attributs tels que ISO-9126, ISO-9241-11, ISO-13407 et IEEE std. 610.12, etc.

Test de l'interface utilisateur et de la convivialité

Le test de l'interface utilisateur consiste à tester l'interface utilisateur graphique du logiciel. Les tests d'interface utilisateur garantissent que l'interface graphique fonctionne selon les exigences et testée en termes de couleur, d'alignement, de taille et d'autres propriétés.

D'autre part, les tests d'utilisabilité garantissent une bonne interface graphique conviviale qui peut être facilement manipulée. Les tests d'interface utilisateur peuvent être considérés comme une sous-partie des tests d'utilisabilité.

Test de sécurité

Les tests de sécurité consistent à tester un logiciel afin d'identifier les failles et les lacunes du point de vue de la sécurité et de la vulnérabilité. Voici les principaux aspects que les tests de sécurité devraient garantir -

• Confidentiality

• Integrity

• Authentication

• Availability

• Authorization

• Non-repudiation

• Le logiciel est protégé contre les vulnérabilités connues et inconnues

• Les données du logiciel sont sécurisées

• Le logiciel est conforme à toutes les réglementations de sécurité

• Vérification et validation des entrées

• Attaques d'insertion SQL

• Défauts d'injection

• Problèmes de gestion de session

• Attaques de script intersite

• La mémoire tampon déborde de vulnérabilités

• Attaques par traversée de répertoire

Test de portabilité

Les tests de portabilité comprennent le test d'un logiciel dans le but de garantir sa réutilisabilité et de pouvoir également le déplacer d'un autre logiciel. Voici les stratégies qui peuvent être utilisées pour les tests de portabilité -

• Transfert d'un logiciel installé d'un ordinateur à un autre.

• Construire un exécutable (.exe) pour exécuter le logiciel sur différentes plates-formes.

Les tests de portabilité peuvent être considérés comme l'une des sous-parties des tests de système, car ce type de test comprend le test global d'un logiciel en ce qui concerne son utilisation dans différents environnements. Le matériel informatique, les systèmes d'exploitation et les navigateurs sont au cœur des tests de portabilité. Certaines des conditions préalables aux tests de portabilité sont les suivantes:

• Les logiciels doivent être conçus et codés en tenant compte des exigences de portabilité.

• Des tests unitaires ont été effectués sur les composants associés.

• Des tests d'intégration ont été effectués.

• L'environnement de test a été établi.

La documentation de test implique la documentation des artefacts qui doivent être développés avant ou pendant le test du logiciel.

La documentation pour les tests logiciels aide à estimer l'effort de test requis, la couverture des tests, le suivi / traçage des exigences, etc. Cette section décrit certains des artefacts documentés couramment utilisés liés aux tests logiciels tels que:

• Plan de test
• Scénario de test
• Cas de test
• Matrice de traçabilité

Plan de test

Un plan de test décrit la stratégie qui sera utilisée pour tester une application, les ressources qui seront utilisées, l'environnement de test dans lequel les tests seront effectués, ainsi que les limites des tests et le calendrier des activités de test. En général, le chef de l'équipe d'assurance qualité sera responsable de la rédaction d'un plan de test.

Un plan de test comprend les éléments suivants:

• Introduction au document du plan de test
• Hypothèses lors du test de l'application
• Liste des cas de test inclus dans le test de l'application
• Liste des fonctionnalités à tester
• Quel type d'approche utiliser lors du test du logiciel
• Liste des livrables à tester
• Les ressources allouées pour tester l'application
• Tous les risques encourus pendant le processus de test
• Un calendrier des tâches et des jalons à atteindre

Scénario de test

Il s'agit d'une instruction d'une ligne qui indique quelle zone de l'application sera testée. Des scénarios de test sont utilisés pour garantir que tous les flux de processus sont testés de bout en bout. Un domaine particulier d'une application peut avoir aussi peu qu'un scénario de test à quelques centaines de scénarios en fonction de l'ampleur et de la complexité de l'application.

Les termes «scénario de test» et «cas de test» sont utilisés de manière interchangeable, cependant un scénario de test comporte plusieurs étapes, tandis qu'un scénario de test en a une seule. Vu sous cet angle, les scénarios de test sont des cas de test, mais ils incluent plusieurs cas de test et la séquence dans laquelle ils doivent être exécutés. En dehors de cela, chaque test dépend de la sortie du test précédent.

Cas de test

Les cas de test impliquent un ensemble d'étapes, de conditions et d'entrées qui peuvent être utilisées lors de l'exécution des tâches de test. L'objectif principal de cette activité est de s'assurer qu'un logiciel réussit ou échoue en termes de fonctionnalité et d'autres aspects. Il existe de nombreux types de cas de test tels que fonctionnels, négatifs, erreurs, cas de test logiques, cas de test physiques, cas de test d'interface utilisateur, etc.

De plus, des cas de test sont écrits pour suivre la couverture de test d'un logiciel. En règle générale, aucun modèle formel ne peut être utilisé lors de l'écriture de cas de test. Cependant, les composants suivants sont toujours disponibles et inclus dans chaque cas de test -

• ID de cas de test
• Module produit
• Version de produit
• Historique des révisions
• Purpose
• Assumptions
• Pre-conditions
• Steps
• Résultat attendu
• Résultat réel
• Post-conditions

De nombreux cas de test peuvent être dérivés d'un seul scénario de test. De plus, il arrive que plusieurs scénarios de test soient écrits pour un seul logiciel, appelés collectivement suites de tests.

Matrice de traçabilité

La matrice de traçabilité (également connue sous le nom de matrice de traçabilité des exigences - RTM) est une table utilisée pour suivre les exigences au cours du cycle de vie du développement logiciel. Il peut être utilisé pour le traçage en aval (c'est-à-dire des exigences à la conception ou au codage) ou en arrière (c'est-à-dire du codage aux exigences). Il existe de nombreux modèles définis par l'utilisateur pour RTM.

Chaque exigence du document RTM est liée à son scénario de test associé afin que les tests puissent être effectués conformément aux exigences mentionnées. En outre, Bug ID est également inclus et lié à ses exigences et cas de test associés. Les principaux objectifs de cette matrice sont:

• Assurez-vous que le logiciel est développé conformément aux exigences mentionnées.
• Aide à trouver la cause première de tout bogue.
• Aide à tracer les documents développés au cours des différentes phases de SDLC.

L'estimation des efforts requis pour les tests est l'une des tâches majeures et importantes du SDLC. Une estimation correcte aide à tester le logiciel avec une couverture maximale. Cette section décrit certaines des techniques qui peuvent être utiles pour estimer les efforts requis pour les tests.

Analyse des points fonctionnels

Cette méthode est basée sur l'analyse des besoins fonctionnels des utilisateurs du logiciel avec les catégories suivantes -

• Outputs
• Inquiries
• Inputs
• Fichiers internes
• Fichiers externes

Analyse des points de test

Ce processus d'estimation est utilisé pour l'analyse des points de fonction pour les tests de boîte noire ou d'acceptation. Les principaux éléments de cette méthode sont: la taille, la productivité, la stratégie, l'interfaçage, la complexité et l'uniformité.

Méthode Mark-II

Il s'agit d'une méthode d'estimation utilisée pour analyser et mesurer l'estimation basée sur la vue fonctionnelle de l'utilisateur final. La procédure pour la méthode Mark-II est la suivante -

• Déterminer le point de vue
• Objectif et type de comptage
• Définir la limite du nombre
• Identifiez les transactions logiques
• Identifier et catégoriser les types d'entités de données
• Compter les types d'éléments de données d'entrée
• Comptez la taille fonctionnelle

Divers

Vous pouvez utiliser d'autres techniques d'estimation populaires telles que -

• Technique Delphi
• Estimation basée sur l'analogie
• Estimation basée sur l'énumération des cas de test
• Estimation basée sur les tâches (activités)
• Méthode IFPUG