Commençons par les bases ! Découvrez les deux modes de test généraux et les trois types courants d'automatisation des tests.
Nous sommes tous passés par là: qu'est-ce qu'un mème de codage récurrent qui arrive trop souvent dans la vie réelle ?
Ce mème résume parfaitement la situation: chaque tiroir fonctionne parfaitement bien individuellement, mais lorsqu'il est combiné à l'autre, ils se bloquent mutuellement et ne fonctionnent pas correctement. Les deux tiroirs doivent fonctionner l'un avec l'autre et en même temps.
Appliquez-le au développement Web: vous avez écrit des tests et peut-être même atteint une couverture de test de 100 %, mais votre application doit encore fonctionner une fois que d'autres parties sont en place. Les modules peuvent fonctionner seuls, mais pas les uns par rapport aux autres. La rédaction de quelques tests est essentielle, mais ce n'est qu'une partie de la configuration de test idéale pour votre projet. Dans un premier temps, vous devez déterminer les aspects de la qualité de l'application que vous devez garantir et comment y parvenir.
Pour faire simple, vous avez besoin d'un plan avant de commencer à écrire le code de test. Pour aborder le sujet des tests pratiques, commençons par une nouvelle base et répondons à deux questions fondamentales:
- Comment voulez-vous effectuer le test ?
- Que voulez-vous tester ?
Cet article se concentre sur les choses générales que vous devez savoir pour répondre à la première question. Pour commencer, découvrons d'abord les modes de test disponibles, puis examinons les types de tests les plus courants. Dans les articles suivants, nous répondrons à la deuxième question, combinerons les réponses et trouverons la stratégie de test la plus adaptée à votre projet. C'est parti ! 🙌
Commencez par l'essentiel: modes de test généraux
Lorsque vous répondez à la question de savoir comment tester, le premier point à clarifier est très abstrait. Devez-vous effectuer des tests manuels ou laisser un ordinateur prendre le relais ? Il est cependant important de ne pas tomber dans la pensée binaire ici.
Tests manuels et tests automatisés
Si vous demandez aux ingénieurs de l'assurance qualité de définir les tests, ils les décomposeront probablement en deux « modes » d'abord:
- Tests manuels. Il s'agit d'une méthode de test typique menée par des personnes réelles. Un ingénieur en assurance qualité clique sur l'application, vérifie si elle fonctionne et essaie en même temps de l'interrompre. La méthode la plus courante consiste à effectuer des tests exploratoires, au cours desquels l'ingénieur étudie l'application en s'appuyant sur ses connaissances de l'application en fonction d'un chemin d'accès ou d'une checklist prédéfinis.
- Tests automatisés. Il s'agit d'un type de test réalisé par un ordinateur. Les ingénieurs en assurance qualité l'implémentent pour automatiser l'élimination des tests répétitifs et monotones.
Cette série de guides porte principalement sur les tests automatisés. Cependant, ne vous concentrez pas sur une seule méthode de test. Même si l'automatisation permet d'économiser beaucoup de temps et d'efforts, les tests manuels et les tests manuels joueront toujours un rôle essentiel. L'automatisation des tests devrait plutôt permettre aux employés de se concentrer sur les tests exploratoires et la résolution des problèmes liés aux créations. Par exemple, garantir la qualité des expériences utilisateur ou protéger la logique métier à haut risque. En d'autres termes, vous pouvez compter sur l'automatisation. ❤️
Boîte opaque ou boîte transparente
Vous avez donc défini les modes généraux de test. Cependant, ce n'est pas encore suffisant. Pour planifier la stratégie de test, une autre question est à se poser: devez-vous savoir comment votre application fonctionne en arrière-plan ou est-il préférable de la tester à votre insu ? En fonction de la réponse, vous avez le choix entre deux procédures pour générer et sélectionner des scénarios de test:
- Test par boîte opaque (ou test par boîte noire). Il se base sur l'analyse des exigences fonctionnelles ou non fonctionnelles d'un composant ou d'un système (spécifications), sans tenir compte de sa structure interne.
- La procédure de test par boîte blanche (ou test par boîte blanche) tient compte de la structure interne de cette boîte. En d'autres termes, il s'agit du fonctionnement en arrière-plan de votre application.
Les deux procédures peuvent s'appliquer aux tests manuels et automatisés. Cependant, certains aspects des modes de test généraux peuvent se concentrer davantage sur l'un des deux. Nous y reviendrons plus tard. Pour l'instant, décomposons l'automatisation des tests en types.
Types d'automatisation des tests: comment voulez-vous effectuer les tests ?
Alors que vous vous rapprochez de la réponse à la question "comment", vous avez déjà décidé de procéder à des tests manuels. Toutefois, choisir et appliquer des types d'automatisation des tests est un peu plus difficile. Les types de tests d'automatisation sont étroitement liés aux métriques que vous souhaitez créer dans vos projets. Examinons de plus près les plus importants.
Comme illustré dans le mème mentionné précédemment, vous avez déjà rencontré deux types: les tests unitaires et les tests d'intégration. Le troisième point important à prendre en compte est le test de bout en bout. Mais ce n’est pas encore toutes ces choses encore. Examinons cela de plus près.
Tests unitaires
Les tests unitaires sont des types de tests dans lesquels les parties ou unités mineures d'une application pouvant être testées sont testées individuellement et indépendamment pour vérifier leur bon fonctionnement. Le champ d'application de ces unités peut varier : fonctions, classes, interfaces, services ou composants complets. Leurs attributs principaux sont la vitesse d'exécution, l'isolation et la facilité de gestion. Si vous souhaitez en savoir plus sur les tests unitaires, consultez ce guide sur les tests unitaires.
Tests d'intégration
Les tests d'intégration se concentrent sur les interactions entre les composants ou les systèmes. En d’autres termes, sur la façon dont ils fonctionnent ensemble. Les tests d'API ou de composants sont des exemples typiques de tests d'intégration.
Test de bout en bout
Ces tests sont souvent appelés "tests d'interface utilisateur" et leur nom explique encore mieux leur fonction. Ces tests interagissent avec l'interface utilisateur de votre application, y compris l'ensemble de la pile d'applications, et testent votre application d'un bout à l'autre.
Ils ressemblent à un test système si vous faites référence à la théorie de l'assurance qualité. Ces tests simulent un utilisateur authentique et ses interactions. Les tests de bout en bout nécessitent davantage d'exécution, car ils impliquent l'ensemble du système. Or, plus le temps d'exécution est important, plus la puissance de calcul est élevée. Par conséquent, ces efforts supplémentaires augmentent les coûts de maintenance.
Test de l'interface utilisateur visuelle
Les tests visuels constituent une sous-catégorie intéressante de tests d'interface utilisateur. Il s'agit de tests étendus de bout en bout qui permettent de vérifier la sortie visible d'une application. Ce test effectue une capture d'écran après une modification et une autre contenant le "statu quo" (ou fichier de référence), puis fournit ces résultats à un examinateur manuel pour qu'il procède à une inspection et à une vérification. En d'autres termes, cela permet de détecter des "bugs visuels" dans l'apparence d'une page, au-delà des bugs purement fonctionnels et qui ne sont pas explicitement écrits dans des assertions.
Analyse statique
Il y a encore une chose à introduire: l'analyse statique. Il ne s'agit pas d'un type de test au sens général. Cependant, il s'agira par la suite d'un aspect essentiel des stratégies d'assurance qualité. Vous pouvez imaginer qu'il fonctionne comme une fonction de correcteur orthographique: il analyse votre code à la recherche de défauts plus importants et d'erreurs de syntaxe sans exécuter le programme, détectant ainsi les problèmes de style de code. Cette simple mesure peut éviter de nombreux bugs. C'est un bon point pour en savoir plus sur l'analyse statique si vous souhaitez la connaître plus en détail.
Des tests sous toutes les formes: comment tout cela fonctionne-t-il ensemble ?
En cherchant des réponses à toutes ces questions, vous trouverez peut-être une solution dans certaines analogies. Dans les communautés Web et de test en particulier, les développeurs ont tendance à utiliser ces analogies pour vous donner une idée du nombre de tests à utiliser pour chaque type.
Les cinq stratégies suivantes, présentées dans cette image, sont les plus courantes:
- Pyramide de test
- Diamant de test
- Cône de glace test (également appelé pizza test)
- Test Honeycomb
- Trophée test
Cela représente vraiment beaucoup d'informations à traiter. En vous basant sur tous ces éléments, comment définir une stratégie de test des correspondances ? Ne vous inquiétez pas, nous avons ce qu'il vous faut. Dans l'article suivant, nous aborderons ces différentes stratégies plus en détail et nous vous expliquerons comment choisir celle qui convient le mieux à votre projet. mais revenez plus tard ! 🔥