Test

Qu'est-ce que le test ?

1. Le test est le processus d'évaluation d'un système ou de ses composants dans le but de trouver
s'il satisfait ou non aux exigences spécifiées.
2. En d'autres termes, le test consiste à exécuter un système afin d'identifier d'éventuelles lacunes, erreurs ou

exigences manquantes contrairement aux exigences réelles.

3. Selon la norme ANSI/IEEE 1059,
4. Les tests peuvent être définis 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/bogs) et évaluer les fonctionnalités

de l'élément logiciel.

Qui fait des tests ?

Cela dépend du processus et des parties prenantes associées au(x) projet(s).

2. Dans l'industrie informatique, les grandes entreprises disposent d'une équipe chargée d'évaluer le

logiciel développé dans le contexte des exigences données.

3. De plus, les développeurs effectuent également des tests appelés Tests Unitaires.
4. Dans la plupart des cas, les professionnels suivants sont impliqués dans le test d'un système dans leur

capacités respectives −

Testeur de logiciels

Développeur de logiciels

Directeur/Responsable de projet

Utilisateur final

5. Différentes entreprises ont différentes désignations pour les personnes qui testent le logiciel sur le
sur la base de leur expérience et de leurs connaissances telles que Testeur de logiciels,

Ingénieur en assurance qualité logicielle, Analyste QA, etc.

7. Il n'est pas possible de tester le logiciel à aucun moment de son cycle. Les deux sections suivantes indiquent
Quand les tests devraient-ils commencer et quand doivent-ils se terminer durant le SDLC.
Quand commencer les tests ?

Un début précoce des tests réduit le coût et le temps de retravail et permet de produire un logiciel sans erreur.

qui est livré au client.

2. Cependant, dans le cycle de vie du développement logiciel (SDLC), les tests peuvent commencer dès le

Phase de collecte des exigences et se poursuit jusqu'au déploiement du logiciel.

3. Cela dépend également du modèle de développement qui est utilisé.

4. Par exemple, dans le modèle en cascade, des tests formels sont effectués lors de la phase de test ; mais dan

le modèle itératif.

5. Les tests sont effectués à la fin de chaque incrément/itération et l'ensemble de l'application est
testé à la fin.

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

Lors de la phase de collecte des besoins, l'analyse et la vérification des exigences sont
également considéré comme un test.

Examiner le design lors de la phase de conception avec l'intention d'améliorer le design est également

considéré comme un test.

Les tests effectués par un développeur à l'achèvement du code sont également classés comme
test

Quand arrêter les tests ?

Il est difficile de déterminer quand arrêter les tests, car le test est un processus sans fin et aucun
on peut prétendre qu'un logiciel est testé à 100 %.

2. Les aspects suivants doivent être pris en compte pour arrêter le processus de test −

Tests de délais

Achèvement de l'exécution des cas de test

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

Le taux de bogues tombe en dessous d'un certain niveau et aucun bogue de haute priorité n'est identifié
 Décision de gestion

Introduction aux tests?

1. Le test logiciel est une activité visant à vérifier si les résultats réels correspondent aux résultats attendus.

résultats et pour s'assurer que le système logiciel estDéfautgratuit. Cela implique l'exécution d'un
composant logiciel ou composant système pour évaluer une ou plusieurs propriétés d'intérêt.
2. Les tests logiciels peuvent être décrits comme le processus de vérification et de validation qu'un logiciel ou

l'application est sans bugs, répond aux exigences techniques telles que guidées par son design et
développement et répond aux exigences des utilisateurs de manière efficace et efficiente en gérant tout

les cas exceptionnels et limites.

3. Le processus de test logiciel a pour but non seulement de trouver des défauts dans le logiciel existant mais
également à trouver des mesures pour améliorer le logiciel en termes d'efficacité, de précision et
utilisabilité. Elle vise principalement à mesurer la spécification, la fonctionnalité et la performance d'un

programme ou application de logiciel.

4. Les tests de logiciels aident également à identifier les erreurs, les lacunes ou les exigences manquantes.

exigences actuelles.

Cela peut être fait manuellement ou en utilisant des outils automatisés.

6. Certains préfèrent dire que les tests logiciels sont une boîte blanche etTest de boîte noire.

Le test de logiciel est-il important ?

Les tests sont importants car les bogues logiciels peuvent être coûteux voire dangereux.

2. Les bugs logiciels peuvent potentiellement causer des pertes financières et humaines, l'histoire est pleine de tels exemples.

Quels sont les différents types de tests logiciels ?

Les tests logiciels peuvent être largement classés en deux types :

Tests manuels

2. Tests d'automatisation
 Tests manuels :
1. Les tests manuels incluent le test d'un logiciel manuellement, c'est-à-dire sans utiliser d'automatisation.

outil ou script quelconque.

2. Dans ce type, le testeur prend le rôle d'un utilisateur final et teste le logiciel pour identifier
tout comportement inattendu ou bug.
3. Il existe différentes étapes pour les tests manuels, telles que les tests unitaires, les tests d'intégration,

tests système et tests d'acceptation utilisateur.

Les testeurs utilisent des plans de test, des cas de test ou des scénarios de test pour tester un logiciel afin de garantir le

complétude des tests.

5. Les tests manuels incluent également des tests exploratoires, car les testeurs explorent le logiciel pour
identifier les erreurs dans cela.

Test d'automatisation :
1. Test d'automatisation, également connu sous le nom d'automatisation des tests.

2. Lorsque le testeur écrit des scripts et utilise un autre logiciel pour tester le produit. Ce processus
implique l'automatisation d'un processus manuel.
3. Les tests d'automatisation sont utilisés pour réexécuter les scénarios de test qui ont été effectués manuellement.

rapidement, et de manière répétée.

4. Les tests de régression, les tests d'automatisation sont également utilisés pour tester l'application sous charge.

tests, tests de performance et tests de stress.

 5. Cela augmente la couverture des tests, améliore la précision et fait économiser du temps et de l'argent.

comparaison à des tests manuels.

Que faut-il automatiser ?

Il n'est pas possible d'automatiser tout dans un logiciel.

Les zones où un utilisateur peut effectuer des transactions, comme le formulaire de connexion ou d'inscription

formes

toute zone où un grand nombre d'utilisateurs peuvent accéder au logiciel simultanément devrait être

automatisé.

Tous les éléments de l'interface graphique, les connexions avec les bases de données, les validations de champ, etc. peuvent être effectués efficacement.

testé par l'automatisation du processus manuel.

Quand automatiser ?
L'automatisation des tests doit être utilisée en tenant compte des aspects suivants d'un logiciel −

Projets larges et critiques

Des projets qui nécessitent de tester fréquemment les mêmes zones

Exigences ne changeant pas fréquemment

Accéder à l'application pour la charge et la performance avec de nombreux utilisateurs virtuels

Logiciel stable en ce qui concerne les tests manuels

Disponibilité du temps

Comment automatiser ?

L'automatisation se fait en utilisant un langage informatique de support comme le scripting VB et un

application logicielle automatisée.
There are many tools available that can be used to write automation scripts.

Avant de mentionner les outils, identifions le processus qui peut être utilisé pour automatiser le
processus de test −
 Identifier les domaines au sein d'un logiciel pour l'automatisation

Sélection de l'outil approprié pour l'automatisation des tests

Écriture de scripts de test

Développement de suites de tests

Exécution de scripts

Créer des rapports de résultats

Identifier tout bogue potentiel ou problème de performance

Quels sont les différents niveaux de test de logiciels ?

SoftwareTesting - Levels

Il existe différents niveaux pendant le processus de test.

Les niveaux de test comprennent différentes méthodologies qui peuvent être utilisées lors de la réalisation

test logiciel.

Les principaux niveaux de test de logiciels sont −

Tests fonctionnels

Tests non fonctionnels

Les principaux niveaux de test logiciel sont les suivants :

[Link] fonctionnels

[Link] de non-fonctionnalité

Tests fonctionnels
C'est un type de test en boîte noire basé sur les spécifications du logiciel qui
doit être testé.

Le test fonctionnel d'un logiciel est réalisé sur un système complet et intégré pour
évaluer la conformité du système avec ses exigences spécifiées.
 C'est un type de test en boîte noire qui est basé sur les spécifications du logiciel que
doit être testé.

The application is tested by providing input and then the results are examined that need
se conformer à la fonctionnalité pour laquelle elle était destinée.

Les tests fonctionnels d'un logiciel sont réalisés sur un système complet et intégré pour
évaluer la conformité du système à ses exigences spécifiées.

Il y a cinq étapes impliquées lors du test d'une application pour sa fonctionnalité.

Une pratique de test efficace appliquera les étapes ci-dessus aux politiques de test de
chaque organisation et donc

il veillera à ce que l'organisation maintienne les normes les plus strictes en ce qui concerne
à la qualité logicielle.

Tests en boîte noire :

La technique de test dans laquelle le testeur n'a pas accès au code source du
logiciel et se déroule à l'interface du logiciel sans se soucier de l'interne
La structure logique du logiciel est connue sous le nom de test en boîte noire.

La technique de test sans avoir aucune connaissance du fonctionnement intérieur de

l'application s'appelle test en boîte noire.
Le testeur est inconscient de l'architecture du système et n'a pas accès au code source.
code.

Typiquement, lors de l'exécution d'un test en boîte noire, un testeur interagira avec l'utilisateur du système
interface en fournissant des entrées et en examinant les sorties sans savoir comment et où
les entrées sont traitées.

Il y a cinq étapes impliquées lors du test d'une application pour sa fonctionnalité.

La détermination de la fonctionnalité que l'application prévue est censée

exécuter.

La création de données de test basée sur les spécifications de l'application.

La sortie basée sur les données de test et les spécifications de l'application.

 La rédaction de scénarios de test et l'exécution de cas de test.

La comparaison des résultats réels et attendus basée sur les cas de test exécutés.

Il est utilisé pour la validation.

Dans cela, nous ignorons le mécanisme de fonctionnement interne et

se concentre sur quel est le résultat ?.

Les avantages et les inconvénients des tests en boîte noire sont les suivants.

Avantage des tests en boîte noire

[Link] suited and efficient for large code segments.

L'accès au code n'est pas requis.

3. Sépare clairement la perspective de l'utilisateur de celle du développeur grâce à une visibilité.

rôles définis.

De nombreux testeurs modérément qualifiés peuvent tester l'application sans connaissances.

de mise en œuvre, de langage de programmation ou de systèmes d'exploitation

Inconvénient des tests en boîte noire

[Link] limitée, car seuls un nombre sélectionné de scénarios de test est réellement effectué.

2. Tests inefficaces, en raison du fait que le testeur n'a qu'une connaissance limitée d'un

application.
3. Couverture aveugle, car le testeur ne peut pas cibler des segments de code spécifiques ou des zones sujettes aux erreurs.

4. Les cas de test sont difficiles à concevoir.

Tests non fonctionnels

1. Les tests non fonctionnels sont effectués pour vérifier l'exigence non fonctionnelle c'est-à-dire la performance.

Usability etc.
 2. Il vérifie si le comportement du système est conforme aux exigences ou non.

3. Cela couvre tous les aspects qui ne sont pas abordés danstest fonctionnel.

4. Cette section est basée sur le test d'une application à partir de ses attributs non fonctionnels.

5. Les tests non fonctionnels consistent à tester un logiciel sur la base des exigences qui sont
non fonctionnels par nature mais importants tels que la performance, la sécurité, l'interface utilisateur, etc.

Tests en boîte blanche :

La technique de test dans laquelle le testeur est conscient du fonctionnement interne de la

le produit a accès à son code source et est réalisé en veillant à ce que tout soit interne
les opérations sont effectuées selon les spécifications, ce qui est connu sous le nom de test en boîte blanche.

2. Le test en boîte blanche est l'examen détaillé de la logique interne et de la structure du code.
3. Le test boîte blanche est également appelé test transparent ou test boîte ouverte.

4. Afin de réaliser des tests en boîte blanche sur une application, un testeur doit connaître le
fonctionnement interne du code.

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

Avantages des tests en boîte blanche

1. Comme le testeur a connaissance du code source, il devient très facile de découvrir lequel
Le type de données peut aider à tester l'application efficacement.
2. Cela aide à optimiser le code.

3. Des lignes de code supplémentaires peuvent être supprimées, ce qui peut entraîner des défauts cachés.

4. En raison des connaissances du testeur sur le code, une couverture maximale est atteinte lors du test.

écriture de scénario.

Inconvénients des tests en boîte blanche

1. En raison du fait qu'un testeur qualifié est nécessaire pour effectuer des tests en boîte blanche, les coûts sont

augmenté.
 2. Parfois, il est impossible de regarder dans chaque recoin pour découvrir des erreurs cachées.
cela peut créer des problèmes, car de nombreux itinéraires resteront non testés.

Il est difficile de maintenir des tests en boîte blanche, car cela nécessite des outils spécialisés comme le code

analiseurs et outils de débogage.

Tests de boîte grise

Le test en boîte grise est une technique pour tester l'application avec une connaissance limitée.
du fonctionnement interne d'une application.

Dans les tests logiciels, l'expression plus vous en savez, mieux c'est a beaucoup de poids.
tout en testant une application.

Maîtriser le domaine d'un système donne toujours au testeur un avantage sur quelqu'un qui obtient
connaissances limitées dans le domaine.

Contrairement aux tests boîte noire, où le testeur ne teste que l'interface utilisateur de l'application ; dans
tests en boîte grise

le testeur a accès aux documents de conception et à la base de données.

En ayant cette connaissance, un testeur peut préparer de meilleures données de test et des scénarios de test tout en

élaborer un plan de test.

Avantages du test en boîte grise

Offre des avantages combinés des tests boîte noire et boîte blanche chaque fois que cela est possible.

Les testeurs en boîte grise ne s'appuient pas sur le code source ; ils s'appuient plutôt sur la définition de l'interface.

et spécifications fonctionnelles.

Sur la base des informations limitées disponibles, un testeur en boîte grise peut concevoir d'excellents tests.
scénarios surtout autour des protocoles de communication et de la gestion des types de données.

Le test est effectué du point de vue de l'utilisateur et non du designer.

Inconvénients des tests en boîte grise

 Puisque l'accès au code source n'est pas disponible, la capacité de passer en revue le code et de tester.
la couverture est limitée.

Les tests peuvent être redondants si le concepteur de logiciels a déjà exécuté un cas de test.

Tester chaque flux d'entrée possible est irréaliste car cela prendrait un temps déraisonnable.
la quantité de temps ; par conséquent, de nombreux chemins de programme resteront non testés.

Comparaison des méthodes de test

La différence entre les tests en boîte noire, les tests en boîte grise et les tests en boîte blanche.

Test de boîte noire Tests en boîte grise Test de boîte blanche

Le fonctionnement interne d'un Le testeur a des connaissances limitées Le testeur a une connaissance complète de

l'application n'a pas besoin d'être connue. des rouages internes de la le fonctionnement interne du
application. application.

Également connu sous le nom de boîte fermée Également connu sous le nom de test translucide, Également connu sous le nom de boîte claire

test, test basé sur les données, ou Alors que le testeur a des limites tests, tests structurels, ou
tests fonctionnels. connaissance de l'intérieur du tests basés sur le code.

application.

Effectué par les utilisateurs finaux et Réalisé par des utilisateurs finaux et aussi Normalement fait par des testeurs et
également par les testeurs et les développeurs. par des testeurs et des développeurs. développeurs.

Les tests sont basés sur l'externe Les tests sont effectués sur la base de Le fonctionnement interne est entièrement

attentes - Comportement interne diagrammes de base de données de haut niveau et connu et le testeur peut
de l'application est inconnu. diagrammes de flux de données. concevoir des données de test en conséquence.
C'est exhaustif et le moins Partiellement chronophage et Le plus exhaustif et
chronophage. exhaustif. type chronophage de
test

Pas adapté à l'algorithme Pas adapté pour les tests d'algorithmes. Adapté pour les tests d'algorithmes.

test

Cela ne peut être fait que par essai- Domaines de données et interne Domaines de données et interne
méthode d'essai et d'erreur. les frontières peuvent être testées, si Les limites peuvent être meilleures

connu. testé.

Différents niveaux de tests logiciels

Tests unitaires :

Un niveau du processus de test logiciel où des unités/composants individuels de

les logiciels/systèmes sont testés.

2. L'objectif est de valider que chaque unité du logiciel fonctionne comme prévu.

3. Il se concentre sur la plus petite unité de conception logicielle. Dans ce cas, nous testons une unité individuelle ou un groupe.

d'unités inter liées.

Cela se fait souvent par un programmeur en utilisant des entrées d'échantillon et en observant leur correspondance.

sorties.

5. Ce type de test est effectué par les développeurs avant que la configuration ne soit remise au
équipe de test pour exécuter formellement les cas de test.

6. Les tests unitaires sont effectués par les développeurs respectifs sur les unités individuelles de code source.

zones attribuées par code.

7. Les développeurs utilisent des données de test qui sont différentes des données de test de l'assurance qualité.

équipe.

8. L'objectif des tests unitaires est d'isoler chaque partie du programme et de montrer que chaque élément

les pièces sont correctes en termes d'exigences et de fonctionnalité.

Limitations des tests unitaires

Les tests ne peuvent pas détecter tous les bugs d'une application.

2. Il est impossible d'évaluer chaque chemin d'exécution dans chaque application logicielle. Le même
c'est le cas avec les tests unitaires.

3. Il y a 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.

4. Après avoir épuisé toutes les options, il n'y a d'autre choix que d'arrêter les tests unitaires et
fusionnez le segment de code avec d'autres unités.

Test d'intégration :
1. Un niveau du processus de test logiciel où des unités individuelles sont combinées et testées comme

un groupe.
2. Le but de ce niveau de test est de révéler des défauts dans l'interaction entre

unités intégrées.
3. Les tests d'intégration sont de deux types : (i) de haut en bas (ii) de bas en haut

4. Les tests d'intégration sont définis comme le test des parties combinées d'une application pour

déterminer s'ils fonctionnent correctement.

5. 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 descendante.

test d'intégration descendant.

Intégration ascendante

1. Ce test commence par des tests unitaires, suivis de tests de plus en plus élevés.
combinations de niveaux d'unités appelées modules ou constructions.
 Intégration descendante

Les modules de plus haut niveau sont testés en premier et progressivement, les modules de niveau inférieur.

sont testés par la suite.

6. Dans un environnement de développement logiciel complet, les tests par le bas sont généralement

fait en premier, suivi des tests descendantes.

7. Le processus se termine par plusieurs tests de l'application complète, de préférence dans

scénarios conçus pour imiter des situations réelles

Tests Système :

Un niveau du processus de test de logiciel où un système/logiciel complet et intégré est

testé.
2. Le but de ce test est d'évaluer la conformité du système avec les spécifications.
exigences.
3. Les tests système vérifient le système dans son ensemble. Une fois que tous les composants sont intégrés, le

l'application dans son ensemble est testée.

Ce type de test est effectué par une équipe de test spécialisée.

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

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

L'application est testée en profondeur pour vérifier qu'elle répond aux exigences fonctionnelles et techniques.

spécifications.

L'application est testée dans un environnement très proche de la production.

environnement où l'application sera déployée.

Les tests système nous permettent de tester, vérifier et valider à la fois les exigences commerciales ainsi que

eh bien, comme l'architecture de l'application.

Tests d'acceptation :
Un niveau du processus de test logiciel où un système est testé pour son acceptabilité.
 2. L'objectif de ce test est d'évaluer la conformité du système avec les exigences de l'entreprise.

exigences et évaluer si elles sont acceptables pour la livraison.

3. C'est sans doute le type de test le plus important, car il est effectué par le
Équipe d'Assurance Qualité qui évaluera si l'application répond aux
spécifications prévues et satisfait aux exigences du client.
4. L'équipe QA disposera d'un ensemble de scénarios et de cas de test pré-écrits qui seront
utilisé pour tester l'application.
5. D'autres idées seront partagées concernant l'application et d'autres tests pourront être effectués.

en cela pour évaluer son exactitude et les raisons pour lesquelles le projet a été initié.

6. Les tests d'acceptation ne sont pas seulement destinés à signaler de simples erreurs d'orthographe,

erreurs cosmétiques, ou lacunes d'interface, mais aussi pour signaler tout bogue dans l'application

cela entraînera des pannes système ou des erreurs majeures dans l'application.
7. en effectuant des tests d'acceptation sur une application, l'équipe de test va réduire comment

l'application fonctionnera en production.

8. Il existe également des exigences légales et contractuelles pour l'acceptation du système.

Regression Testing

Chaque fois qu'un nouveau module est ajouté, cela entraîne des modifications dans le programme.
 2. Ce type de test s'assure que l'ensemble du composant fonctionne correctement même après ajout.

composants du programme complet.

3. Chaque fois qu'un changement est apporté à une application logicielle, il est tout à fait possible que d'autres domaines

au sein de l'application ont été affectés par ce changement.

4. Les tests de régression sont effectués pour vérifier qu'un bug corrigé n'a pas entraîné un autre problème.

violation de fonctionnalité ou de règle commerciale.

5. L'objectif des tests de régression est de s'assurer qu'un changement, tel qu'un correctif de bogue, ne devrait pas

résulter en une autre erreur étant découverte dans l'application.

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

Minimisez les lacunes dans les tests lorsqu'une application ayant subi des modifications doit être testée.

Tester les nouveaux changements pour vérifier que les modifications apportées n'ont pas affecté d'autres domaines.

l'application.

Atténue les risques lorsqu'un test de régression est effectué sur l'application.

La couverture de test est augmentée sans compromettre les délais.

Accélérer la mise sur le marché du produit

Tests de fumée
Ce test est effectué pour s'assurer que le logiciel en cours de test est prêt ou stable pour la suite.

test

On appelle cela un test de validation car le test initial est effectué pour vérifier s'il n'a pas pris feu ou

fumé lors de l'allumage initial.

Tests Alpha

Ceci est un type de test de validation. C'est un type de test d'acceptation qui est effectué.
avant que le produit ne soit lancé aux clients.

[Link] est généralement fait par des personnes du contrôle qualité.

 Ce test est la première étape des tests et sera effectué parmi les équipes
(équipes de développement et de QA).

4. Les tests unitaires, les tests d'intégration et les tests système, lorsqu'ils sont combinés, sont

connue sous le nom de test alpha.

5. 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 la plus basse spécification pour tester les temps de chargement et toute autre

problèmes de latence.

Test bêta
1. Le test bêta est effectué sur un ou plusieurs sites clients par l'utilisateur final de la
logiciel.

2. Cette version est publiée pour un nombre limité d'utilisateurs pour des tests en temps réel.
environnement

3. Ce test est effectué après que les tests alpha ont été réussis. Dans la version bêta
tests, un échantillon du public cible teste l'application. Les tests bêta sont également
connu sous le nom de tests de pré-production.

4. Les versions bêta des logiciels sont idéalement distribuées à un large public sur le
Web, en partie pour donner au programme un test "dans le monde réel" et en partie pour fournir un

aperçu de la prochaine sortie.

Phases de test bêta suivantes -

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

Fautes typographiques, flux d'application déroutant, et même des plantages.

En obtenant des retours, l'équipe de projet peut résoudre les problèmes avant de publier le logiciel aux utilisateurs réels.

utilisateurs.
 Plus vous résolvez de problèmes qui concernent réellement les utilisateurs, plus la qualité de votre application sera élevée.

être.

Avoir une application de meilleure qualité lors de son lancement au grand public augmentera la satisfaction des clients

satisfaction.

Test de performance

Les tests de performance sont considérés comme l'un des types de tests importants et obligatoires dans

conditions des aspects suivants -

Il est principalement utilisé pour identifier les goulots d'étranglement ou les problèmes de performance plutôt que pour trouver

bugs dans un logiciel.

Il existe différentes causes qui contribuent à diminuer la performance d'un logiciel -

Vitesse (c'est-à-dire Temps de réponse, rendu des données et accès)

Capacité

Stabilité

Évolutivité

Les tests de performance peuvent être qualitatifs ou quantitatifs et peuvent être divisés en
différents sous-types tels que les tests de charge et les tests de stress.

a) Test de charge

1. It is a process of testing the behavior of a software by applying maximum load in terms of

logiciel accédant et manipulant de grandes données d'entrée.

Cela peut être fait à la fois dans des conditions de charge normale et de charge maximale.

3. Ce type de test identifie la capacité maximale du logiciel et son comportement à son pic.
temps.

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,
Test de charge Visual Studio, etc.
5. Les utilisateurs virtuels (VUsers) sont définis dans l'outil de test automatisé et le script est exécuté pour

vérifiez le test de charge pour le logiciel.

6. Le nombre d'utilisateurs peut être augmenté ou diminué de manière simultanée ou incrémentale en fonction de

selon les exigences

B) Test de résistance

1. Le test de résistance impose des conditions défavorables au système et vérifie comment il performe.
ces conditions.

2. Le test de résistance inclut l'évaluation du comportement d'un logiciel dans des conditions anormales.

3. L'objectif des tests de résistance est de tester le logiciel en appliquant une charge au système et en prenant
sur les ressources utilisées par le logiciel pour identifier le point de rupture.

4. Ce test peut être effectué en testant différents scénarios tels que −

Arrêt ou redémarrage aléatoire des ports réseau

Allumer ou éteindre la base de données

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

Testsd'utilisabilité
a. Les tests d'utilisabilité sont une technique en boîte noire et sont utilisés pour identifier toute erreur(s) et

améliorations du logiciel en observant les utilisateurs à travers leur utilisation et

opération.

b. Les tests d'utilisabilité peuvent être définis en termes de cinq facteurs, c'est-à-dire l'efficacité d'utilisation,

learn-ability, memory-ability, errors/safety, and satisfaction.

c. L'utilisabilité d'un produit sera bonne et le système sera utilisable s'il possède le
facteurs ci-dessus.
 d. Il existe des normes, des modèles et des méthodes de qualité qui définissent l'utilisabilité dans

la forme d'attributs et de sous-attributs tels que l'ISO-9126, l'ISO-9241-11, l'ISO-

13407, et norme IEEE 610.12, etc.

UI contre Test d'Utilisabilité

Le test UI implique de tester l'interface graphique de l'utilisateur du logiciel.

2. Les tests UI garantissent que l'interface graphique fonctionne conformément aux exigences et sont testés en termes de

de couleur, d'alignement, de taille et d'autres propriétés.

D'autre part,

Les tests d'utilisabilité garantissent une interface graphique bonne et conviviale qui peut être facilement manipulée.

Les tests d'interface utilisateur peuvent être considérés comme une sous-partie des tests d'usabilité.

Test de sécurité
Les tests de sécurité impliquent de tester un logiciel afin d'identifier les défauts et les lacunes en matière de sécurité.

et du point de vue de la vulnérabilité.

Les aspects des tests de sécurité sont les suivants :

Confidentialité

Intégrité

Authentification

Disponibilité

Autorisation

Non-répudiation

Le logiciel est sécurisé contre les vulnérabilités connues et inconnues

Les données logicielles sont sécurisées

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

Vérification et validation des entrées

Attaques par injection SQL

 Vulnérabilités d'injection

Problèmes de gestion de session

Attaques par scripts inter-sites

Vulnérabilités de débordements de tampon

Attaques par traversée de répertoire

TestdePortabilité
1. Portability testing includes testing a software with the aim to ensure its reusability and that it
peut également être déplacé depuis un autre logiciel.

2. Voici les stratégies qui peuvent être utilisées pour les tests de portabilité −

Transférer un logiciel installé d'un ordinateur à un autre.

Création d'exécutables (.exe) pour faire fonctionner le logiciel sur différentes plateformes.

3. Les tests de portabilité peuvent être considérés comme l'une des sous-parties des tests système, car ces tests
le type comprend des tests globaux d'un logiciel par rapport à son utilisation dans différents
environnements.

4. Le matériel informatique, les systèmes d'exploitation et les navigateurs sont les principaux axes de la portabilité.

test. Certaines des préconditions pour les tests de portabilité sont les suivantes −

Le logiciel doit être conçu et codé en tenant compte des exigences de portabilité.

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

Les tests d'intégration ont été réalisés.

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

5. La documentation de test implique la documentation des artefacts qui doivent être développés
avant ou pendant les tests de logiciels.

6. La documentation pour les tests logiciels aide à estimer l'effort de test requis, test
couverture, suivi/trace des exigences, etc.

Plan de test
 Scénario de test

Cas de Test

Matrice de traçabilité

Principes de test :-

Tous les tests doivent répondre aux exigences du client

2. Pour que nos logiciels soient testés, cela doit être effectué par un tiers.

3. Les tests exhaustifs ne sont pas possibles. Nous avons besoin de la quantité optimale de tests en fonction de

évaluation des risques de l'application.

4. Tous les tests à réaliser doivent être planifiés avant leur mise en œuvre.

5. Cela suit la règle de Pareto (règle 80/20) qui stipule que 80 % des erreurs proviennent de 20 % de
composants du programme.

6. Commencez à tester avec de petites pièces et étendez-le à de grandes pièces.

Les tests logiciels peuvent être divisés en deux étapes :

[Link]:it refers to the set of tasks that ensure that software correctly implements
une fonction spécifique.

2. Validation : cela fait référence à un ensemble différent de tâches qui garantissent que le logiciel qui a
a été construit est traçable aux exigences des clients.
Vérification : "Construisons-nous le produit correctement ?"

Validation : « Construisons-nous le bon produit ? »

Différences entre vérification et validation

Vérification Validation

1. La vérification répond à la préoccupation : "Êtes-vous

La validation aborde la préoccupation : "Sont-ils
 le construire correctement ? vous construisez la bonne chose ?

2. S'assure que le système logiciel répond à toutes S'assure

les que les fonctionnalités répondent aux
fonctionnalité. comportement prévu.

3. La vérification a lieu en premier et inclut Lalevalidation se produit après la vérification et

vérification de la documentation, du code, etc. touche principalement à la vérification de la

produit global.

Fait par des développeurs. Fait par des testeurs.

5. Il a des activités statiques, car il inclut la collecte.

Il contient des activités dynamiques, car il inclut

avis, guides et inspections pour vérifier un exécuter le logiciel contre le

logiciel. exigences.

6. C'est un processus objectif et non subjectif C'est un processus subjectif et implique

une décision devrait être nécessaire pour vérifier un logiciel. décisions subjectives sur la manière dont un

le logiciel fonctionne.

SoftwareTesting - Documentation

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

La documentation pour les tests logiciels aide à estimer l'effort de test requis, tester
couverture, suivi/de traçabilité des exigences, etc.

Cette section décrit certains des artefacts documentés couramment utilisés liés à
test de logiciels tel que −

Plan de test

Scénario de test
 Cas de test

Matrice de traçabilité

Plandetest
Un plan de test décrit la stratégie qui sera utilisée pour tester une application.

2. Les ressources qui seront utilisées, l'environnement de test dans lequel les tests seront effectués,
et les limitations des tests et le calendrier des activités de test.

3. En général, le Responsable de l'Assurance Qualité sera chargé de rédiger un Plan de Test.

4. Un plan de test comprend ce qui suit −

Introduction au document du plan de test

Hypothèses lors de la test de l'application

Liste des cas de test inclus dans le test de l'application

Liste des fonctionnalités à tester

Quelle approche utiliser lors du test du logiciel

List of deliverables that need to be tested

Les ressources allouées pour tester l'application

Tous les risques impliqués lors du processus de test

Un calendrier des tâches et des jalons à atteindre

Scénariodetest
C'est une déclaration en une ligne qui notifie quelle zone de l'application sera testée.

2. Les scénarios de test sont utilisés pour s'assurer que tous les flux de processus sont testés de bout en bout.

3. Une zone particulière d'une application peut avoir aussi peu qu'un scénario de test à quelques centaines.

scénarios en fonction de l'ampleur et de la complexité de l'application.

4. Les termes 'scénario de test' et 'cas de test' sont utilisés de manière interchangeable, cependant un scénario de test

a plusieurs étapes, tandis qu'un cas de test a une seule étape.

5. Vu sous cet angle, les scénarios de test sont des cas de test, mais ils incluent plusieurs tests.
cas et la séquence dans laquelle ils doivent être exécutés.

Cas de test
1. Les cas de test impliquent un ensemble d'étapes, de conditions et d'entrées qui peuvent être utilisés pendant

réaliser des tâches de test.

2. L'intention principale de cette activité est de garantir si un logiciel réussit ou échoue dans
en termes de fonctionnalité et d'autres aspects.

3. Il existe de nombreux types de cas de test tels que fonctionnels, négatifs, d'erreur, logiques.
cas, cas de test physiques, cas de test UI, etc.

4. des cas de test sont écrits pour suivre la couverture des tests d'un logiciel.

5. There are no formal templates that can be used during test case writing.

6. However, the following components are always available and included in every
cas de test -

ID de cas de test

Module produit
 Version du produit

Historique des révisions

But

Hypothèses

Conditions préalables

Étapes

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, parfois plusieurs tests
Les cas sont rédigés pour un logiciel unique, qui sont collectivement connus sous le nom de 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 un tableau qui est

utilisé pour tracer les exigences durant le Cycle de Vie du Développement Logiciel. Cela peut être utilisé pour
tracing avant (c'est-à-dire de l'exigence au design ou à la codification) ou arrière (c'est-à-dire de la codification à

Exigences). Il existe de nombreux modèles définis par l'utilisateur pour RTM.

Chaque exigence dans le document RTM est liée à son cas de test associé afin que les tests puissent
être fait selon les exigences mentionnées. De plus, l'identifiant de bogue est également inclus et lié
avec ses exigences associées et son cas de test. 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 profonde de tout bug.

Aide à tracer les documents développés lors des différentes phases du SDLC.

Tests de logiciel - Techniques d'estimation

L'estimation des efforts requis pour les tests est l'une des tâches majeures et importantes dans le 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 nécessaires pour les tests.

Analyse des Points Fonctionnels

Cette méthode est basée sur l'analyse des exigences fonctionnelles des utilisateurs du logiciel avec le
catégories suivantes −

Sorties

Enquêtes

Entrées

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 en boîte noire ou les tests d'acceptation.

Les principaux éléments de cette méthode sont : Taille, Productivité, Stratégie, Interface, Complexité,
et Uniformité.

Mark-II Method

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

Déterminez le point de vue

Objectif et type de dénombrement

Définir la limite de compte

Identifiez les transactions logiques

 Identifier et classer 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 par analogie

Estimation basée sur l'énumération des cas de test

Estimation basée sur les tâches (activités)

Méthode IFPUG

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

HP Quick Test Professionnel

Sélénium

IBM Rational Functional Tester

SilkTest

TestComplete

Testing Anywhere

WinRunner

LoadRunner

Visual Studio Test Professional

WATIR
 Testsetdébogage
Test

1. Cela implique d'identifier un bogue/une erreur/un défaut dans un logiciel sans le corriger.

2. Normalement, les professionnels ayant une expérience en assurance qualité sont impliqués dans les bogues.

identification.

[Link] tests sont effectués pendant la phase de test.

Débogage

Cela implique d'identifier, d'isoler et de résoudre les problèmes/bogs.

2. Les développeurs qui codent le logiciel effectuent le débogage lorsqu'ils rencontrent une erreur dans le

code.

3. Le débogage fait partie des tests Boîte Blanche ou des tests unitaires.

4. Le débogage peut être effectué pendant la phase de développement lors de la réalisation de tests unitaires ou dans

phases lors de la correction des bogues signalés.

Tests,assurancequalitéetcontrôlequalité
La plupart des gens sont confus lorsqu'il s'agit de cerner les différences parmi la qualité.

Assurance, Contrôle de Qualité et Tests.

Bien qu'ils soient interconnectés et qu'ils puissent dans une certaine mesure être considérés comme les mêmes.

activités, mais il existe des points distinctifs qui les différencient.

Le tableau suivant montre la différence entre l'assurance qualité (AQ), le contrôle qualité (CQ) et les tests.

Assurance Qualité Contrôle de la qualité Test

1. L'assurance qualité comprend des activitésCela

qui inclut des activités qui Cela inclut des activités
assurer la mise en œuvre de assurer la vérification d'un qui garantissent le
processus, procédures et logiciel développé avec identification de
normes dans le contexte de respect au documenté (ou bugs/erreurs/défauts dans un

vérification des développés pas dans certains cas)

 logiciels et intentionné exigences. logiciel.
exigences.

2. Se concentre sur les processus et Se concentre sur les tests réels Se concentre sur l'actuel

procédures plutôt que en exécutant le logiciel test.

réaliser des tests réels sur dans le but d'identifier
le système. bogue/défaut à travers
mise en œuvre de
procédures et processus.

3. Activités orientées vers le processus.

Product-oriented activities. Orienté produit
activités.

4. Activités préventives. C'est un processus correctif. C'est un préventif

processus.

5. C'est un sous-ensemble des tests logiciels Les tests sont le sous-ensemble de

Le QC peut être considéré comme

Cycle de Vie (STLC). le sous-ensemble de la qualité Contrôle de la qualité.

Assurance.

DIMENSIONS DE LA QUALITÉ DES LOGICIELS

Dimensions de la Qualité

Accessibilité : Le degré auquel un logiciel peut être utilisé confortablement par une grande variété
de personnes, y compris celles qui nécessitent des technologies d'assistance comme des agrandisseurs d'écran ou

reconnaissance vocale.
Compatibilité : L'adéquation d'un logiciel à une utilisation dans différents environnements, comme différents
Systèmes d'exploitation, navigateurs, etc.
 Concurrence : La capacité d'un logiciel à traiter plusieurs demandes pour les mêmes ressources
en même temps.

Efficacité : La capacité d'un logiciel à bien fonctionner ou à atteindre un résultat sans gaspillage

énergie, ressources, effort, temps ou argent.

Fonctionnalité : La capacité d'un logiciel à exécuter les fonctions spécifiées ou désirées.

Installabilité : La capacité d'un logiciel à être installé dans un environnement spécifique.

Localizability:The ability of software to be used in different languages, time zones etc.

Maintenabilité : La facilité avec laquelle un logiciel peut être modifié (ajout de fonctionnalités,
amélioration des fonctionnalités, correction des bugs, etc)

Performance:The speed at which software performs under a particular load.

Portabilité : La capacité d'un logiciel à être transféré facilement d'un endroit à un autre.

Fiabilité : La capacité d'un logiciel à exécuter une fonction requise dans les conditions énoncées.

conditions pour la période stipulée sans aucune erreur.

Scalabilité : La mesure de la capacité d'un logiciel à augmenter ou diminuer ses performances

réponse aux changements dans les exigences de traitement des logiciels.

Sécurité : Le degré de protection des logiciels contre l'accès non autorisé, l'invasion de
vie privée, vol, perte de données, etc.

Testability:The ability of software to be easily tested.

Utilisabilité : Le degré de facilité d'utilisation du logiciel.

Test de logiciels - Normes ISO

Many organizations around the globe develop and implement different standards to improve the
les besoins de qualité de leur logiciel. Ce chapitre décrit brièvement certains des standards largement utilisés

lié à l'assurance qualité et aux tests.

ISO/IEC 9126

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

Modèle de qualité

Métriques externes

Métriques internes

Métriques de qualité en usage

Cette norme présente un ensemble d'attributs de qualité pour tout logiciel, tels que −

Fonctionnalité

Fiabilité

Utilisabilité

Efficacité

Maintenabilité

Portabilité

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

ISO/IEC 9241-11

La partie 11 de cette norme concerne l'ampleur à laquelle un produit peut être utilisé par des utilisateurs spécifiés.

atteindre des objectifs spécifiés avec efficacité, efficience et satisfaction dans un contexte spécifié
d'utilisation.

Cette norme propose un cadre qui décrit les composants d'utilisabilité et le

relation entre eux. Dans cette norme, l'utilisabilité est considérée en termes d'utilisateur
performance et satisfaction. Selon la norme ISO 9241-11, l'utilisabilité dépend du contexte d'utilisation
et le niveau d'utilisabilité changera à mesure que le contexte changera.
ISO/IEC 25000:2005

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

SQuaRE est divisé en sous-parties telles que −

ISO 2500n − Division de la gestion de la qualité

ISO 2501n − Modèle de qualité Division

ISO 2502n − Division de Mesure de la Qualité

ISO 2503n - Exigences de qualité Division

ISO 2504n − Division d'é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 liée à l'ingénierie des besoins (c'est-à-dire spécification, planification, mesure)

et le processus d'évaluation)

logiciels connus collectivement sous le nom de test

Testslogiciels - Mythes

Mythe 1 : Les tests sont trop chers

Réalité− Il y a un proverbe, payez moins pour les tests lors du développement de logiciels ou payez plus pour
une maintenance ou correction ultérieure. Des tests précoces permettent d'économiser à la fois du temps et des coûts dans de nombreux aspects,

Cependant, réduire le coût sans tests peut entraîner un mauvais design d'un logiciel.
application rendant le produit inutilisable.

Mythe 2 : Le test prend du temps

Réalité− Lors des phases du SDLC, les tests ne sont jamais un processus long. Cependant
diagnostiquer et corriger les erreurs identifiées lors de tests appropriés est une tâche chronophage mais

productive activity.

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

Réalité− Sans aucun doute, les tests dépendent du code source mais la révision des exigences et
le développement de cas de test est indépendant du code développé. Cependant, itératif ou incrémental
une approche en tant que modèle de cycle de vie de développement peut réduire la dépendance des tests par rapport au complet

logiciel développé.

Mythe 4 : Des tests complets sont possibles

Réalité - 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 l'occurrence d'un test complet est
jamais possible. Il pourrait 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 peut être exécuté une fois le projet terminé

a été déployé.

Mythe 5 : Un logiciel testé est sans bogue

Réalité - Ceci est un mythe très courant parmi les clients, les chefs de projet et la direction.
l'équipe y croit. Personne ne peut affirmer avec une certitude absolue qu'une application logicielle est à 100%

sans bogues même si un testeur avec d'excellentes compétences en test a testé l'application.

Myth 6: Missed Defects are due to Testers

Réalité - Ce n'est pas une approche correcte de blâmer les testeurs pour les bogues qui restent dans l'application.

même après que des tests ont été effectués. Ce mythe est lié au Temps, au Coût et aux Exigences
changement des contraintes. Cependant, la stratégie de test peut également conduire à des bogues qui sont manqués par le

équipe de test.

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

Réalité - C'est une interprétation erronée très courante que seuls les testeurs ou l'équipe de test devraient être

responsable de la qualité du produit. Les responsabilités des testeurs incluent l'identification des bogues au
parties prenantes et ensuite c'est leur décision de savoir s'ils vont corriger le bogue ou publier le logiciel.

Publier le logiciel à ce moment-là met plus de pression sur les testeurs, car ils seront blâmés pour
n'importe quelle erreur.

Mythe 8 : L'automatisation des tests devrait être utilisée partout où cela est possible pour réduire le temps

Réalité - Oui, il est vrai que l'automatisation des tests réduit le temps de test, mais il n'est pas possible de
commencer l'automatisation des tests à tout moment au cours du développement logiciel. L'automatisation des tests doit être lancée

quand le logiciel a été testé manuellement et est stable dans une certaine mesure. De plus, le test
L'automatisation ne peut jamais être utilisée si les exigences continuent de changer.

Mythe 9 : Tout le monde peut tester une application logicielle

Réalité - Les personnes en dehors de l'industrie informatique pensent et croient même que tout le monde peut tester un logiciel.

et les tests ne sont pas un travail créatif. Cependant, les testeurs savent très bien que c'est un mythe. La pensée
des scénarios alternatifs, essayer de faire 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− Finding bugs in a software is the task of the testers, but at the same time, they are
experts en domaine du logiciel particulier. Les développeurs sont uniquement responsables du spécifique
composant ou domaine qui leur est attribué mais les testeurs comprennent le fonctionnement général de la
logiciel, quelles sont les dépendances et les impacts d'un module sur un autre module.
Audit et Inspection

Audit–

C'est un processus systématique pour déterminer comment le processus de test réel est conduit au sein d'un
organisation ou une équipe.

It is an independent examination of processes involved during the testing of a software.

Selon 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é légale, 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 par
identifier toute erreur ou lacune.

Conformément à l'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

défauts, violations des normes de développement et autres problèmes.

Les réunions d'inspection formelles peuvent inclure les processus suivants : Planification, Aperçu

Préparation, Réunion d'inspection, Réparation, et Suivi.