Test du logiciel - Guide rapide
Qu'est-ce test?
Le test est le processus d'évaluation d'un système ou de son composant (s) dans le but de trouver si elle satisfait aux exigences spécifiées ou non. En termes simples, les tests sont en cours d'exécution d'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, test peut être défini comme - Un processus d'analyse d'un élément de logiciel pour détecter les différences entre les conditions existantes et nécessaires (qui est des défauts / erreurs / bugs) et d'évaluer les caractéristiques de l'élément logiciel.
Qui fait les essais?
Cela dépend du processus et les acteurs associés au projet (s). Dans l'industrie des TI, les grandes entreprises ont une équipe avec des responsabilités pour évaluer les logiciels développés dans le contexte des exigences données. De plus, les développeurs effectuent également des tests que l'on appelle les tests unitaires. Dans la plupart des cas, les professionnels suivants participent à l'essai d'un système selon leurs capacités respectives:
- Tester logiciel
- Développeur de logiciels
- Lead / Chef de projet
- 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 connaissances telles que Software Tester, Software Quality Assurance Engineer, analyste QA, etc.
Quand commencer à tester?
Un démarrage précoce de test réduit le coût et le temps de retravailler et de produire un logiciel sans erreur qui est livré au client. Cependant, dans le développement de logiciels du cycle de vie (SDLC), les tests peuvent être démarré à partir des exigences phase de collecte et a continué jusqu'à ce que le déploiement du logiciel. Il dépend également du modèle de développement qui est utilisé. Par exemple, dans le modèle cascade, test formel est mené dans la phase de test; mais dans le modèle incrémental, les tests sont effectués à la fin de chaque incrément / itération et l'ensemble de l'application est testée à la fin.
Les tests sont effectués sous différentes formes à chaque phase de SDLC:
Au cours de la phase de collecte des besoins, 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 l'essai.
Les tests effectués par un développeur à la fin du code est également classé comme test.
Quand arrêter le test?
Il est difficile de déterminer quand arrêter les tests, comme le test est un processus sans fin et personne ne peut prétendre qu'un logiciel est testé à 100%. Les aspects suivants doivent être pris en considération pour arrêter le processus de test:
Vérification validation
Ces deux termes sont très déroutant pour la plupart des gens, qui les utilisent de manière interchangeable. Le tableau ci-dessous met en évidence les différences entre la vérification et la validation.
QC peut être considéré comme le sous-ensemble de l'assurance qualité.
Le test est le sous-ensemble de contrôle de la qualité.
Vérification et d'inspection
Audit. Il est un processus systématique pour déterminer comment le processus de test réel est effectué au sein d'une organisation ou d'une équipe. En général, il est un examen indépendant des processus impliqués lors de l'essai d'un logiciel. Selon IEEE, il est un examen des processus documentés que les organisations mettent en œuvre et suivent. Les types de vérification comprennent la vérification de la conformité juridique, audit interne et la vérification du système.
Inspection. Il est une technique formelle qui implique des examens techniques formelles ou informelles de tout artefact en identifiant toute erreur ou lacune. Selon IEEE94, l'inspection est une technique d'évaluation formelle dans laquelle les exigences des logiciels, des dessins ou des codes sont examinés en détail par une personne ou un groupe autre que l'auteur de détecter les défauts, les violations des normes de développement, et d'autres problèmes.
Test et débogage
Essai. Il consiste à identifier bug / erreur / défaut dans un logiciel sans le corriger. Normalement, les professionnels avec un fond d'assurance qualité sont impliqués dans l'identification des bugs. Le test est effectué dans la phase de test.
Debugging. Il consiste à identifier, isoler et corriger les problèmes / bugs. Les développeurs qui codent le débogage de conduite du logiciel lors de la rencontre d'une erreur dans le code. Le débogage est une partie de boîte blanche ou les contrôles effectués l'unité. Le débogage peut être réalisée dans la phase de développement tout en effectuant des tests unitaires ou en plusieurs phases tout en fixant les bugs signalés.
De nombreuses organisations du monde entier à développer et mettre en œuvre des normes différentes pour améliorer les besoins de qualité de leur logiciel. Ce chapitre décrit brièvement quelques-unes des normes largement utilisées en relation avec l'assurance de la qualité et essai.
ISO / CEI 9126
Cette norme traite les aspects suivants pour déterminer la qualité d'une application logicielle:
- Modèle de qualité
- mesures externes
- mesures internes
- La qualité dans l'utilisation des mesures
Cette norme présente une série d'attributs de qualité pour tous les logiciels tels que:
- fonctionnalité
- Fiabilité
- facilité d'utilisation
- Efficacité
- maintenabilité
- Portabilité
Les attributs de qualité mentionnés ci-dessus sont divisés en sous-facteurs, que vous pouvez étudier lorsque vous étudiez la norme en détail.
ISO / CEI 9241-11
Partie 11 de cette norme traite de la mesure dans laquelle un produit peut être utilisé par les utilisateurs identifiés, pour atteindre des buts définis avec efficacité, efficience et satisfaction dans un contexte d'utilisation spécifié.
Cette norme a proposé un cadre qui décrit les composantes de la convivialité et la relation entre eux. Dans cette norme, la facilité d'utilisation est considérée en termes de performance de l'utilisateur et la satisfaction. Selon ISO 9241-11, la facilité d'utilisation dépend du contexte d'utilisation et le niveau de la facilité d'utilisation changera à mesure que le contexte change.
Carré est divisé en sous-parties telles que:
- ISO 2500n - Division de la gestion de la qualité
- ISO 2501n - Division modèle 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é
Le contenu principal de SQuaRE sont les suivants:
- Termes et définitions
- Modèles de référence
- Guide général
- guides de division individuels
- Norme relative à l'exigence d'ingénierie (par exemple la spécification, la planification, de mesure et d'évaluation)
ISO / IEC 12119
Cette norme traite des progiciels livrés au client. Il ne se concentre pas ou traiter le processus de production des clients. Le contenu principal sont liés aux éléments suivants:
- Ensemble des exigences pour les packages logiciels.
- Instructions pour tester un logiciel livré par rapport aux exigences spécifiées.
Divers
Certains des autres normes relatives aux processus d'assurance qualité et d'essai sont mentionnés ci-dessous:
Test manuel
test manuel comprend l'essai d'un logiciel manuellement, à savoir sans utiliser un outil automatisé ou tout script. Dans ce type, le testeur prend le rôle d'un utilisateur final et teste le logiciel pour identifier tout comportement inattendu ou bug. Il existe différentes étapes de tests manuels tels que les tests unitaires, tests d'intégration, les tests système et les tests d'acceptation des utilisateurs.
Les testeurs utilisent des plans de test, cas de test, ou des scénarios de test pour tester un logiciel pour assurer l'intégralité des tests. Les tests manuels comprend également des tests d'exploration, comme testeurs explorent le logiciel pour identifier les erreurs en elle.
Test Automation
test d'automatisation, qui est également connu comme l'automatisation des tests, est lorsque le testeur écrit des scripts et utilise un autre logiciel pour tester le produit. Ce processus implique l'automatisation d'un processus manuel. Test Automation est utilisé pour relancer les scénarios de test qui ont été effectuées manuellement, rapidement, et à plusieurs reprises.
En plus des tests de régression, les tests d'automatisation est également utilisé pour tester l'application de la charge, la performance et le point de vue du stress. Il augmente la couverture de test, améliore la précision et fait gagner du temps et de l'argent par rapport aux tests manuels.
Qu'est-ce que Automatiser?
Il est impossible d'automatiser tout dans un logiciel. Les zones où un utilisateur peut effectuer des transactions telles que les formulaires de formulaire de connexion ou d'enregistrement, une zone où un grand nombre d'utilisateurs peuvent accéder au logiciel simultanément doit être automatisé.
De plus, tous les éléments de l'interface graphique, les connexions avec les bases de données, validations sur le terrain, etc., peuvent être efficacement testées en automatisant le processus manuel.
Quand Automatiser?
Automatisation de test doit être utilisé en tenant compte des aspects suivants d'un logiciel:
- Les grands projets et critiques
- Les projets qui exigent des tests les mêmes zones fréquemment
- Exigences ne change pas souvent
- Accéder à la demande de charge et de performance avec de nombreux utilisateurs virtuels
- Logiciel stable par rapport à des tests manuels
- Disponibilité du temps
Comment Automatiser?
L'automatisation se fait à l'aide d'un langage informatique de soutien comme les scripts 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 d'évoquer les outils, identifions le processus qui peut être utilisé pour automatiser le processus de test:
- Identifier les zones à l'intérieur d'un logiciel d'automatisation
- Sélection de l'outil approprié pour l'automatisation des tests
- scripts de test écrit
- Développement de costumes de test
- Exécution de scripts
- Créer des rapports de résultats
- Identifier les problèmes de bugs potentiels ou de performance
Outils de test logiciel
Les outils suivants peuvent être utilisés pour les essais d'automatisation:
- HP Quick Test Professional
- Sélénium
- IBM Rational Functional Tester
- SilkTest
- TestComplete
- Test Partout
- WinRunner
- LaodRunner
- Visual Studio Test Professional
- WATIR
Il existe différentes méthodes qui peuvent être utilisées pour les tests de logiciels. Ce chapitre décrit brièvement les méthodes disponibles.
Black-Box Testing
La technique de test sans avoir aucune connaissance du fonctionnement intérieur de l'application est appelée test boîte noire. Le testeur est inconscient de l'architecture du système et ne dispose pas d'accès au code source. En règle générale, tout en effectuant un test boîte noire, un testeur va interagir avec l'interface utilisateur du système en fournissant des informations et d'examiner les résultats sans savoir comment et où les entrées sont travaillés.
Le tableau suivant présente les avantages et les inconvénients des tests boîte noire.
- Bien adapté et efficace pour les grands segments de code.
- accès au code n'est pas nécessaire.
- Il est clair que la perspective sépare de l'utilisateur du point de vue du développeur à travers des rôles définis visiblement.
- Un grand nombre de testeurs qualifiés modérément peuvent tester l'application sans connaissance de la mise en œuvre, langage de programmation, ou les systèmes d'exploitation.
- La couverture limitée, puisque seulement un certain nombre de scénarios de test est effectivement réalisé.
- tests inefficient, en raison du fait que le testeur n'a que des connaissances limitées sur une application.
- couverture aveugle, puisque le testeur ne peut pas cibler des segments de code spécifiques ou des zones sujettes à l'erreur.
- Les cas de test sont difficiles à concevoir.
Test White-Box
test boîte blanche est l'enquête détaillée de la logique interne et la structure du code. test boîte blanche est aussi appelé test de verre ou de test ouvert boîte. Pour effectuer des tests boîte blanche sur une application, un testeur a besoin de connaître le fonctionnement interne du code.
Le testeur doit avoir un regard à l'intérieur du code source et savoir quelle unité / morceau du code se comporte de façon inappropriée.
Le tableau suivant présente les avantages et les inconvénients des tests boîte blanche.
- Comme le testeur a connaissance du code source, il devient très facile de savoir quel type de données peut aider à tester l'application efficace.
- Il aide à optimiser le code.
- lignes de code supplémentaires peuvent être enlevés qui peuvent apporter des vices cachés.
- En raison de la connaissance du code, une couverture maximale du testeur est atteint lors de l'écriture de scénario de test.
Test Gray-Box
test gris boîte est une technique pour tester l'application d'avoir une connaissance limitée du fonctionnement interne d'une application. Dans les tests de logiciels, l'expression plus vous en savez, mieux porte beaucoup de poids lors du test d'une application.
La maîtrise du domaine d'un système donne toujours le testeur un avantage sur quelqu'un ayant des connaissances de domaine limité. Contrairement à des tests de boîte noire, où le testeur ne teste que l'interface utilisateur de l'application; dans les tests boîte grise, le testeur a accès aux documents de conception et la base de données. Ayant cette connaissance, un testeur peut préparer de meilleurs scénarios de données de test et d'essai tout en faisant un plan de test.
- Offre des avantages combinés de la boîte noire et tests boîte blanche chaque fois que possible.
- testeurs de boîte grise ne comptez pas sur le code source; Au contraire, ils reposent sur la définition de l'interface et des spécifications fonctionnelles.
- Sur la base des informations disponibles, un testeur-boîte grise peut concevoir d'excellents scénarios de test en particulier autour des protocoles de communication et la gestion du type de données.
- Le test se fait à partir du point de vue de l'utilisateur et non le concepteur.
- Depuis l'accès au code source n'est pas disponible, la possibilité d'aller sur le code et la couverture de test est limité.
- Les tests peuvent être redondants si le concepteur du logiciel a déjà exécuté un test.
- Test de tous les flux d'entrée possible est irréaliste car il prendrait beaucoup de temps déraisonnable; Par conséquent, de nombreux chemins de programme iront non testé.
Comparaison des méthodes d'essai
Le tableau suivant répertorie les points qui différencient les tests boîte noire, tests boîte grise et tests boîte blanche.
La comparaison des résultats réels et attendus sur la base des cas de tests exécutés.
Une pratique de test efficace voir les étapes ci-dessus appliquées aux politiques de contrôle de chaque organisation et, par conséquent, il fera en sorte que l'organisation maintient des normes les plus strictes en matière de qualité des logiciels.
Tests unitaires
Ce type de test est effectué par les développeurs avant la configuration est remis à l'équipe de test pour exécuter officiellement les cas de test. Les tests unitaires est effectuée par les développeurs respectifs sur les unités individuelles de code source des zones affectées. Les développeurs utilisent des données de test qui est différent des données de test de l'équipe d'assurance qualité.
L'objectif des tests unitaires est d'isoler chaque partie du programme et de montrer que les pièces individuelles sont correctes en termes d'exigences et de fonctionnalité.
Limites des tests unitaires
Le test ne peut pas attraper chaque bug dans une application. Il est impossible d'évaluer tous les chemins d'exécution dans chaque application logicielle. La même chose est le cas avec les tests unitaires.
Il y a une limite au nombre de scénarios et 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 fusionner le segment de code avec d'autres unités.
Test d'intégration
Les tests d'intégration est définie comme l'essai des parties combinées d'une application pour déterminer si elles fonctionnent correctement. Les tests d'intégration peut se faire de deux façons: les tests d'intégration ascendante et les tests d'intégration descendante.
Intégration Méthode d'essai