Les tests manuels sont un processus de test logiciel dans lequel les cas de test sont exécutés manuellement sans utiliser d'outil automatisé. Tous les cas de test exécutés manuellement par le testeur selon le point de vue de l'utilisateur final. Il garantit si l'application fonctionne, comme mentionné dans le document d'exigences ou non. Des cas de test sont planifiés et mis en œuvre pour compléter près de 100 % de l'application logicielle. Les rapports de cas de test sont également générés manuellement.

Les tests manuels sont l'un des processus de test les plus fondamentaux car ils peuvent détecter les défauts visibles et cachés du logiciel. La différence entre le résultat attendu et le résultat donné par le logiciel est définie comme un défaut. Le développeur a corrigé les défauts et l'a remis au testeur pour qu'il le teste à nouveau.

Les tests manuels sont obligatoires pour chaque logiciel nouvellement développé avant les tests automatisés. Ces tests nécessitent beaucoup d'efforts et de temps, mais ils donnent la garantie d'un logiciel sans bug. Les tests manuels nécessitent une connaissance des techniques de tests manuels, mais pas d'un outil de test automatisé.

Les tests manuels sont essentiels car l'un des tests de logiciels Le principe fondamental est « une automatisation à 100 % n'est pas possible ».

Pourquoi nous avons besoin de tests manuels

Chaque fois qu'une application arrive sur le marché et qu'elle est instable ou présente un bug ou des problèmes ou crée un problème pendant que les utilisateurs finaux l'utilisent.

Si nous ne voulons pas faire face à ce genre de problèmes, nous devons effectuer une série de tests pour rendre l'application stable et exempte de bogues et fournir un produit de qualité au client, car si l'application est exempte de bogues, l'utilisateur final utilisera l'application plus facilement.

Si l'ingénieur de test effectue des tests manuels, il peut tester l'application du point de vue de l'utilisateur final et se familiariser davantage avec le produit, ce qui l'aide à rédiger les cas de test corrects de l'application et à donner un retour rapide sur l'application.

Types de tests manuels

Il existe différentes méthodes utilisées pour les tests manuels. Chaque technique est utilisée selon ses critères de test. Les types de tests manuels sont indiqués ci-dessous :

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

Tests en boîte blanche

Les tests en boîte blanche sont effectués par le développeur, où il vérifie chaque ligne d'un code avant de le transmettre à l'ingénieur de test. Étant donné que le code est visible pour le développeur pendant les tests, c'est pourquoi il est également appelé test en boîte blanche.

Pour plus d’informations sur les tests en boîte blanche, consultez le lien ci-dessous :

https://www.javatpoint.com/white-box-testing

Tests en boîte noire

Les tests en boîte noire sont effectués par l'ingénieur de test, où ils peuvent vérifier la fonctionnalité d'une application ou du logiciel en fonction des besoins du client. En cela, le code n'est pas visible lors de l'exécution des tests ; c'est pourquoi on l'appelle test boîte noire.

Pour plus d’informations sur les tests en boîte noire, consultez le lien ci-dessous :

https://www.javatpoint.com/black-box-testing

Tests de la boîte grise

Les tests en boîte grise sont une combinaison de tests en boîte blanche et en boîte noire. Cela peut être effectué par une personne connaissant à la fois le codage et les tests. Et si une seule personne effectue des tests en boîte blanche, ainsi que des tests en boîte noire pour l'application, on parle de tests en boîte grise.

Pour obtenir plus de détails sur les tests en boîte grise, consultez le lien ci-dessous :

https://www.javatpoint.com/grey-box-testing

Comment effectuer des tests manuels

• Tout d’abord, le testeur observe tous les documents liés au logiciel afin de sélectionner les zones de test.
• Le testeur analyse les documents d’exigences pour couvrir toutes les exigences énoncées par le client.
• Le testeur développe les cas de test conformément au document d'exigences.
• Tous les cas de test sont exécutés manuellement à l'aide de tests en boîte noire et de tests en boîte blanche.
• Si des bugs surviennent, l'équipe de test en informe l'équipe de développement.
• L'équipe de développement corrige les bugs et remet le logiciel à l'équipe de test pour un nouveau test.

Processus de création de logiciels

• Une fois l’exigence collectée, elle sera fournie aux deux équipes différentes de développement et de test.
• Après avoir obtenu l'exigence, le développeur concerné commencera à écrire le code.
• Et entre-temps, l'ingénieur de test comprend les exigences et prépare les documents requis. Jusqu'à présent, le développeur peut compléter le code et le stocker dans le Outil de version de contrôle .
• Après cela, le code change dans l'interface utilisateur et ces modifications sont gérées par une équipe distincte, connue sous le nom de construire une équipe .
• Cette équipe de construction prendra le code et commencera à compiler et compresser le code à l'aide d'un outil de construction. Une fois que nous avons obtenu une sortie, la sortie est placée dans le fichier zip, connu sous le nom de Construire (application ou logiciel). Chaque build aura un numéro unique comme (B001, B002).
• Ensuite, cette version particulière sera installée sur le serveur de test. Après cela, l'ingénieur de test accédera à ce serveur de test à l'aide de l'URL de test et commencera à tester l'application.
• Si l'ingénieur de test trouve un bug, il sera signalé au développeur concerné.
• Ensuite, le développeur reproduira le bogue sur le serveur de test, corrigera le bogue et stockera à nouveau le code dans l'outil de version de contrôle, puis installera le nouveau fichier mis à jour et supprimera l'ancien fichier ; ce processus se poursuit jusqu'à ce que nous obtenions la version stable.
• Une fois que nous aurons obtenu la version stable, elle sera remise au client.

Note 1

• Une fois que nous aurons collecté le fichier à partir de l'outil de version Control, nous utiliserons l'outil de construction pour compiler le code du langage de haut niveau vers le langage de niveau machine. Après la compilation, si la taille du fichier augmente, nous compresserons ce fichier particulier et le transférerons sur le serveur de test.
• Ce processus est effectué par Construire une équipe , développeur (si l'équipe de build n'est pas là, un développeur peut le faire) ou le Responsable des Tests (si l'équipe de construction gère directement le zip, installe l'application sur le serveur de test et informe l'ingénieur de test).
• En général, nous ne pouvons pas obtenir une nouvelle version pour chaque bug ; sinon, la plupart du temps sera perdu uniquement à créer les builds.

Note 2

Construire une équipe

La tâche principale de l'équipe de build est de créer l'application ou le Build et de convertir le langage de haut niveau en langage de bas niveau.

Construire

Il s'agit d'un logiciel utilisé pour convertir le code au format d'application. Et il se compose d'un ensemble de fonctionnalités et de corrections de bogues qui sont transmises à l'ingénieur de test à des fins de test jusqu'à ce qu'il devienne stable.

Outil de contrôle des versions

Il s'agit d'un logiciel ou d'une application utilisé dans le but suivant :

• Dans cet outil, nous pouvons enregistrer différents types de fichiers.
• Il est toujours sécurisé car nous accédons au fichier à partir des outils en utilisant les mêmes informations de connexion.
• L'objectif principal des outils est de suivre les modifications apportées aux fichiers existants.

Exemple de processus de construction

Voyons un exemple pour comprendre comment construire un travail de processus sur des scénarios réels :

Dès que l'ingénieur de test détecte le bug, il l'envoie aux développeurs, et ils ont besoin de temps pour l'analyser ; après cela, il corrige uniquement le bug (l'ingénieur de test ne peut pas donner la collection de bugs).

Le développeur décide du nombre de bugs qu'il peut corriger en fonction de son temps. Et l'ingénieur de test décide quel bug doit être corrigé en premier en fonction de ses besoins, car les ingénieurs de test ne peuvent pas se permettre d'arrêter les tests.

Et l'ingénieur de test qui reçoit le courrier ne peut que savoir quel bug est corrigé par le liste des corrections de bugs .

Le temps va augmenter car lors du premier Build, les développeurs doivent écrire le code dans les différentes fonctionnalités. Et à la fin, il ne pourra faire que corriger les bugs et le nombre de jours sera réduit.

Note 3

Cycle d'essai

Le cycle de test est la durée accordée à l’ingénieur de test pour tester chaque build.

Différences entre les deux versions

Les bogues trouvés dans une version peuvent être corrigés dans n'importe quelle version future, ce qui dépend des exigences de l'ingénieur de test. Chaque nouvelle version est la version modifiée de l'ancienne, et ces modifications peuvent être des corrections de bugs ou l'ajout de nouvelles fonctionnalités.

À quelle fréquence recevions-nous la nouvelle version

Au début, nous avions l'habitude d'obtenir des builds hebdomadaires, mais lors de la dernière étape de test, lorsque l'application devenait stable, nous obtenions également la nouvelle build une fois tous les 3 jours, deux jours ou quotidiennement.

Combien de builds obtenons-nous

Si nous considérons une année de n'importe quelle durée de projet, nous avons obtenu 22 à 26 versions.

Quand nous aurons les corrections de bugs

Généralement, nous comprenons les corrections de bogues seulement une fois le cycle de test terminé, ou lorsque la collection de bogues est corrigée dans une version et transférée dans les versions suivantes.

Avantages des tests manuels

• L’utilisation de la méthode boîte noire ne nécessite aucune connaissance en programmation.
• Il est utilisé pour tester des conceptions d’interface graphique changeant dynamiquement.
• Le testeur interagit avec le logiciel en tant qu'utilisateur réel afin de pouvoir découvrir les problèmes d'utilisabilité et d'interface utilisateur.
• Cela garantit que le logiciel est à cent pour cent exempt de bogues.
• C'est rentable.
• Facile à apprendre pour les nouveaux testeurs.

Inconvénients des tests manuels

• Cela nécessite un grand nombre de ressources humaines.
• Il prend beaucoup de temps.
• Le testeur développe des cas de test en fonction de ses compétences et de son expérience. Rien ne prouve qu’ils aient ou non couvert toutes les fonctions.
• Les cas de test ne peuvent pas être réutilisés. Nécessité de développer des cas de test distincts pour chaque nouveau logiciel.
• Il ne fournit pas de tests sur tous les aspects des tests.
• Étant donné que deux équipes travaillent ensemble, il est parfois difficile de comprendre les motivations de chacun, ce qui peut induire le processus en erreur.

Outils de tests manuels

Dans les tests manuels, différents types de tests comme les tests unitaires, d'intégration, de sécurité, de performances et de suivi des bogues, nous disposons de divers outils tels que Jira, Bugzilla, Mantis, Zap, NUnit, Tessy, LoadRunner, Citrus, SonarQube, etc. marché. Certains outils sont open source et d’autres sont commerciaux.

Pour plus d’informations sur les outils de test, consultez le lien ci-dessous :

https://www.javatpoint.com/software-testing-tools

Comprenons-les un par un :

paramètres du navigateur Internet

LoadRunner

Il s’agit des outils de test de performances les plus couramment utilisés. LoadRunner est principalement utilisé pour prendre en charge les tests de performances pour un large éventail de procédures, de nombres d'approches et d'environnements d'application.

L'objectif principal de l'exécution de l'outil LoadRunner est de classer rapidement les sources les plus courantes de problèmes de performances.

Caractéristiques de LoadRunner

• L'outil LoadRunner contient n nombres d'applications, ce qui réduit le temps de compréhension et de description des rapports.
• Nous pouvons obtenir des rapports de tests de performances approfondis en utilisant l'outil LoadRunner.
• Il réduira le coût des tests de charge distribués et offrira également un outil opérationnel pour le suivi du déploiement.

Agrumes

Citrus est un outil de test d'intégration, qui est le framework de test le plus couramment utilisé. Il est écrit en Programmation Java langue. Il est principalement utilisé pour demander et répondre côté serveur et côté client et valider les fichiers XML JSON.

Pour réaliser les tests de cas d'utilisation de bout en bout, citrus prend en charge plusieurs protocoles HTTP, JMS et SOAP.

Caractéristiques des agrumes

Voici quelques-unes des fonctionnalités importantes de l'outil Citrus :

• Il est utilisé pour envoyer et recevoir des messages.
• Citrus est disponible à la fois en open source et sous licence sur le marché.
• Il offre une solution à faible coût.
• Nous pouvons authentifier la base de données en utilisant l'outil citrus.
• Il décrira la séquence des messages, proposera le plan de test et documentera la couverture des tests.
• Il crée le message et vérifie les réponses.

ZAP

ZAP est un scanner de sécurité d'applications Web open source. Il s'agit d'un symbole Proxy d'attaque Zed . Tout comme certains autres outils, il est également écrit dans le Langage de programmation JAVA . C'est le plus efficace Projets ouverts de sécurité des applications Web [OWASP].

Caractéristiques du ZAP

• Il prend en charge de nombreux systèmes d'exploitation tels que Windows, Linux, OS X.
• Il a une architecture basée sur des plugins.
• Il contient un marché en ligne qui nous permet d'ajouter des fonctionnalités nouvelles ou mises à jour.
• Le panneau de contrôle GUI de ZAP est facile à utiliser.

Religieuse

NUnit est l'un des outils de tests unitaires les plus fréquemment utilisés. Il s'agit d'un outil open source et principalement dérivé du JUnit .

C'était entièrement écrit dans le Langage de programmation C# et adapté à tous Langues .Net .

Autrement dit, on peut dire que l'outil NUnit est entièrement repensé pour bénéficier des nombreuses qualités du langage .Net. Par exemple:

Capacités liées à la réflexion. Autres attributs personnalisés.

Caractéristiques de NUnit

• Il permet les assertions en tant que méthode statique de la classe avantage.
• Il supporte les tests basés sur les données.
• Il prend en charge plusieurs plates-formes, telles que .NET core Xamarin mobile, Silverlight et un framework efficace.
• La capacité de NUnit nous aide à exécuter les tests simultanément.
• Il utilise un exécuteur de console pour charger et exécuter les tests.

JIRA

L'outil de suivi des bogues le plus régulièrement utilisé est JIRA , qui est un outil open source. Il est utilisé pour le suivi des bogues, la gestion de projet et le suivi des problèmes.

Dans cet outil, nous pouvons facilement suivre toutes sortes de bugs ou défauts liés au logiciel et produits par les ingénieurs de test.

Caractéristiques de JIRA

• C'est un outil permettant de gagner du temps.
• Jira est utilisé pour suivre les défauts et les problèmes.
• Il est utilisé pour établir les tâches de documentation.
• Jira est un outil très utile pour suivre l'amélioration de notre documentation.

Pour obtenir les informations complètes sur l'outil Jira, reportez-vous au lien ci-dessous : https://www.javatpoint.com/jira-tutorial .

SonarQube

Un autre outil de test manuel est SonarQube, qui améliore notre flux de travail avec une qualité et une sécurité continues du code. Il est flexible avec l’utilisation de plug-ins.

Il est entièrement écrit dans le langage de programmation JAVA. Il offre une évaluation et une intégration entièrement automatisées avec Ant, Maven, Gradle, MSBuild et des outils d'intégration constante. SonarQube a la capacité d'enregistrer un historique des métriques et donne le graphique d'évolution.

Caractéristiques de Sonarqube

Vous trouverez ci-dessous quelques-unes des fonctionnalités importantes de l'outil SonarQube :

• Il prend en charge plusieurs langages de programmation comme C, C++, Python, JAVA, HTML, CSS, VB.NET, PHP, COBOL, PL/SQL, etc.
• Sous la licence publique générale limitée GNU, Sonarqube est disponible gratuitement.
• SonarQube est affilié à certains outils externes importants tels que GitHub, Active Directory, LDAP et autres.
• SonarQube a fusionné avec les environnements de développement Visual Studio, Eclipse et IntelliJ IDEA en raison de la SonarLint des plug-ins.

JMètre

JMeter est un outil open source utilisé pour tester les performances des ressources statiques et dynamiques et des applications Web dynamiques.

Il est entièrement conçu sur l'application JAVA pour charger le comportement des tests fonctionnels et mesurer les performances de l'application.

Il permet aux utilisateurs ou aux développeurs d'utiliser le code source pour le développement d'autres applications.

Caractéristiques de JMeter

Voici quelques-unes des caractéristiques essentielles de JMeter :

• Il est indépendant de la plate-forme et accepte une JVM comme Windows, Mac et Linux, etc.
• Il prend en charge une interface graphique conviviale, interactive et simple.
• Il est incroyablement extensible pour charger le test de performances sur plusieurs types de serveurs.

Pour plus d'informations sur JMeter, reportez-vous au lien ci-dessous :

https://www.javatpoint.com/jmeter-tutorial.

Avec Bugz

Un autre outil de suivi des bogues utilisé dans les tests manuels est Avec Bugz .

Il est le plus largement utilisé par de nombreuses organisations pour suivre les différents bugs de l’application.

Bugzilla est un outil open source qui aide le client et le client à suivre les défauts. Bugzilla est également considéré comme un outil de gestion de tests car en cela, nous pouvons facilement relier d'autres outils de gestion de cas de test tels que ALM, Quality Centre, etc.

Caractéristiques de Bugzilla

Bugzilla possède quelques fonctionnalités supplémentaires qui nous aident à signaler facilement le bug :

• Il prend en charge divers systèmes d'exploitation tels que Windows, Linux et Mac.
• Avec l'aide de Bugzilla, nous pouvons lister un bug sous plusieurs formats.
• Les préférences utilisateur peuvent mesurer les notifications par courrier électronique.
• Bugzilla possède des capacités de recherche avancées.

Mante

Mantis est un système de suivi des bogues basé sur le Web. ManitsBT signifie Traqueur de bogues Mantis . Il permet de suivre les défauts logiciels et est réalisé dans le langage de programmation PHP. C'est également un outil open source.

Caractéristiques de la Mante

Certaines des fonctionnalités standard de cet outil particulier sont les suivantes :

• Avec l'aide de cet outil, nous disposons d'une accessibilité à la recherche en texte intégral.
• Pistes d’audit des modifications apportées aux problèmes.
• Il fournit l’intégration du système de contrôle de révision.
• Contrôle de révision des champs de texte et des notes

Pour obtenir plus de détails sur les outils de suivi des bogues, reportez-vous au lien suivant : https://www.javatpoint.com/defect-or-bug-tracking-tool .

Tessy

Un autre outil de test d'intégration est Tessy , qui est utilisé pour effectuer l'intégration et les tests unitaires du logiciel embarqué. Cela nous aide également à découvrir la couverture du code du logiciel ou d'une application.

Il peut facilement gérer l'ensemble de l'organisation des tests, y compris les besoins de l'entreprise, la gestion des tests, la quantité de couverture et la traçabilité.

Tessy contient trois fonctions principales, qui sont les suivantes :

commande de retour java

• Éditeur d'interface de test (TIE)
• Éditeur de données de test (TDE)
• Espace de travail.

Caractéristiques de TESSY

Les fonctionnalités standards du TESSY sont les suivantes :

• Il produit le rapport de test pour les résultats d’exécution des tests.
• Il prend en charge divers langages de programmation tels que C et C++.
• Tessy est utilisé pour évaluer l'interface de la fonction et décrit la variable utilisée par cette fonction.

Pour plus d'informations sur les outils de test d'intégration, consultez le lien suivant : https://www.javatpoint.com/integration-testing-tools.

Aperçu

Dans cet article, nous avons vu des informations détaillées sur Tests manuels, qui comprennent la définition des tests manuels, la nécessité des tests manuels, le type de tests manuels, les outils de tests manuels, le processus de tests manuels et certains avantages et inconvénients importants de ceux-ci.

Enfin, nous pouvons dire que c'est un processus où l'ingénieur de test doit être très persévérant, innovant et réactif.

Lors des tests manuels, l'ingénieur de test doit penser et fonctionner comme l'interprétation de l'utilisateur final.

Afin de mettre en œuvre des tests manuels, un ingénieur de test a besoin de compétences productives et d'imagination. Et ils doivent réfléchir à plusieurs situations ou scénarios pour tester une application spécifique.

Même si nous pouvons actuellement tester presque toutes les applications à l’aide de tests d’automatisation, les tests manuels sont néanmoins nécessaires car ils constituent la base des tests logiciels.