Test manuel - Manual testing

Comparez avec l' automatisation des tests .

Le test manuel est le processus de test manuel des défauts du logiciel . Cela nécessite qu'un testeur joue le rôle d'un utilisateur final en utilisant la plupart des fonctionnalités de l'application pour garantir un comportement correct. Pour garantir l'exhaustivité des tests, le testeur suit souvent un plan de test écrit qui le guide à travers un ensemble de cas de test importants .

Aperçu

Une étape clé du processus consiste à tester le comportement correct du logiciel avant de le diffuser aux utilisateurs finaux.

Pour les efforts d'ingénierie à petite échelle (y compris les prototypes), des tests exploratoires peuvent être suffisants. Avec cette approche informelle, le testeur ne suit aucune procédure de test rigoureuse, mais explore plutôt l'interface utilisateur de l'application en utilisant autant de ses fonctionnalités que possible, en utilisant les informations obtenues lors des tests précédents pour dériver intuitivement des tests supplémentaires. Le succès des tests manuels exploratoires dépend fortement de l'expertise du domaine du testeur, car un manque de connaissances conduira à des tests incomplets. L'un des principaux avantages d'une approche informelle est d'avoir un aperçu intuitif de ce que l'on ressent lors de l'utilisation de l'application.

Les projets d'ingénierie à grande échelle qui reposent sur des tests logiciels manuels suivent une méthodologie plus rigoureuse afin de maximiser le nombre de défauts pouvant être détectés. Une approche systématique se concentre sur des cas de test prédéterminés et implique généralement les étapes suivantes.

  1. Choisissez un plan de test de haut niveau dans lequel une méthodologie générale est choisie et des ressources telles que des personnes, des ordinateurs et des licences logicielles sont identifiées et acquises.
  2. Rédigez des cas de test détaillés , en identifiant les étapes claires et concises à suivre par le testeur, avec les résultats attendus.
  3. Attribuez les cas de test aux testeurs, qui suivent manuellement les étapes et enregistrent les résultats.
  4. Rédigez un rapport de test, détaillant les conclusions des testeurs. Le rapport est utilisé par les gestionnaires pour déterminer si le logiciel peut être publié, et sinon, il est utilisé par les ingénieurs pour identifier et corriger les problèmes.

Une approche rigoureuse basée sur des cas de test est souvent traditionnelle pour les grands projets d'ingénierie logicielle qui suivent un modèle en cascade . Cependant, au moins une étude récente n'a pas montré de différence dramatique dans l'efficacité de détection des défauts entre les tests exploratoires et les tests basés sur des cas de test.

Le test peut être par black- , blanc- ou test gris boîte . Dans les tests en boîte blanche, le testeur s'occupe de l'exécution des instructions via le code source. Dans les tests en boîte noire, le logiciel est exécuté pour vérifier les défauts et se préoccupe moins de la façon dont le traitement de l'entrée est effectué. Les testeurs de la boîte noire n'ont pas accès au code source. Les tests en boîte grise concernent l'exécution du logiciel tout en ayant une compréhension du code source et des algorithmes.

Une approche de test statique et dynamique peut également être utilisée. Les tests dynamiques impliquent l'exécution du logiciel. Les tests statiques comprennent la vérification des exigences, de la syntaxe du code et de toute autre activité qui n'inclut pas l'exécution réelle du code du programme.

Les tests peuvent être divisés en tests fonctionnels et non fonctionnels . Dans les tests fonctionnels, le testeur vérifierait les calculs, tout lien sur la page ou tout autre champ qui, sur une entrée donnée, peut être attendu. Les tests non fonctionnels comprennent les tests de performance, de compatibilité et d'adéquation du système testé, sa sécurité et sa facilité d'utilisation, entre autres.

Étapes

Il y a plusieurs étapes. Elles sont:

Tests unitaires
Cette étape initiale du test est normalement effectuée par le développeur qui a écrit le code et parfois par un pair utilisant la technique de test de la boîte blanche.
Test d'intégration
Cette étape s'effectue selon deux modes, en package complet ou en incrément du package précédent. La plupart du temps, la technique de test de la boîte noire est utilisée. Cependant, parfois, une combinaison de tests de boîte noire et blanche est également utilisée à cette étape.
Test du système
À ce stade, le logiciel est testé sous toutes les dimensions possibles pour tous les objectifs et plates-formes prévus. À ce stade, la technique de test de la boîte noire est normalement utilisée.
Test d'acceptation par l'utilisateur
Cette étape de test est effectuée afin d'obtenir l'approbation du client du produit fini. Un « laissez-passer » à cette étape garantit également que le client a accepté le logiciel et est prêt à l'utiliser.
Test de version ou de déploiement
L'équipe sur site se rendra sur le site du client pour installer le système dans l'environnement configuré par le client et vérifiera les points suivants :
  1. Que SetUp.exe soit en cours d'exécution ou non.
  2. Il y a des écrans faciles lors de l'installation
  3. Combien d'espace est occupé par le système sur le disque dur
  4. Le système est-il complètement désinstallé lorsque vous avez choisi de le désinstaller du système.

Avantages des tests manuels

  • Opération à faible coût car aucun outil logiciel n'est utilisé
  • La plupart des bogues sont détectés par des tests manuels
  • Les humains observent et jugent mieux que les outils automatisés

Comparaison avec les tests automatisés

L'automatisation des tests peut être en mesure de réduire ou d'éliminer le coût des tests réels. Un ordinateur peut suivre une séquence d'étapes par cœur plus rapidement qu'une personne, et il peut exécuter les tests pendant la nuit pour présenter les résultats le matin. Cependant, le travail économisé dans les tests réels doit être consacré à la création du programme de test. Selon le type d'application à tester et les outils d'automatisation choisis, cela peut nécessiter plus de travail qu'une approche manuelle. De plus, certains outils de test présentent une très grande quantité de données, créant potentiellement une tâche fastidieuse d'interprétation des résultats.

Des éléments tels que les pilotes de périphériques et les bibliothèques de logiciels doivent être testés à l'aide de programmes de test. De plus, les tests d'un grand nombre d'utilisateurs ( tests de performances et tests de charge ) sont généralement simulés dans le logiciel plutôt que effectués dans la pratique.

A l'inverse, les interfaces utilisateur graphiques dont la mise en page change fréquemment sont très difficiles à tester automatiquement. Il existe des frameworks de test qui peuvent être utilisés pour les tests de régression des interfaces utilisateur. Ils s'appuient sur l'enregistrement de séquences de frappes et de mouvements de souris, puis sur leur lecture et sur l'observation que l'interface utilisateur répond de la même manière à chaque fois. Malheureusement, ces enregistrements peuvent ne pas fonctionner correctement lorsqu'un bouton est déplacé ou renommé dans une version ultérieure. Un test de régression automatique peut également être trompé si la sortie du programme varie de manière significative.


Voir également

Les références