types automation testing
Découvrez les différents types de tests d'automatisation avec quelques idées fausses sur l'automatisation des tests:
Dans cette deuxième partie de série de didacticiels d'automatisation de test , Je décrirai brièvement les types de tests automatisés et, plus important encore, j'éliminerai certaines idées fausses sur l'automatisation des tests.
Qu'est-ce que les tests d'automatisation?
Les tests d'automatisation peuvent être définis comme un moyen d'exécuter un ensemble de tests encore et encore sans avoir à les exécuter manuellement. L'introduction de tests d'automatisation dans votre stratégie de test est un moyen d'économiser du temps et de l'argent.
Ce que vous apprendrez:
Types de tests d'automatisation
Les types de tests d'automatisation définissent le type de suites de tests qui peuvent être automatisées. De nombreux testeurs confondent ce sujet avec les types de frameworks d'automatisation qui définissent comment vous allez concevoir votre suite de tests dans un pack d'automatisation qui peut être exécuté facilement.
Dans cet article, nous examinerons de près les types de tests d'automatisation et à la fin, nous examinerons brièvement les cadres d'automatisation.
Comprenons les classifications ci-dessus en détail:
Automatisation basée sur le type de test
Automatisation des tests fonctionnels:
Les tests fonctionnels sont écrits pour tester la logique métier derrière une application. Automatiser ces derniers signifie écrire des scripts pour valider la logique métier et les fonctionnalités attendues de l'application.
Automatisation des tests non fonctionnels:
Les tests non fonctionnels définissent les exigences non commerciales de l'application. Ce sont les exigences liées aux performances, à la sécurité, aux bases de données, etc. Ces exigences peuvent rester constantes ou peuvent être mises à l'échelle en fonction de la taille du logiciel.
Automatisation basée sur la phase de test
Automatisation des tests unitaires:
Ces tests sont exécutés pendant la phase de développement elle-même, idéalement par le développeur après la fin du développement et avant de remettre le système aux testeurs pour les tests.
Automatisation des tests API:
Questions et réponses d'entrevue informatica administrateur
Les tests API sont exécutés pendant la phase d'intégration. Ceux-ci peuvent être exécutés par l'équipe de développement ou de test et peuvent être exécutés avant ou après la création de la couche d'interface utilisateur pour l'application. Ces tests ciblent les tests basés sur la demande et la réponse sur lesquelles l'application est construite.
Automatisation des tests basés sur l'interface utilisateur:
Les tests basés sur l'interface utilisateur sont exécutés pendant la phase d'exécution des tests. Ceux-ci sont spécifiquement exécutés par les testeurs et ne sont exécutés qu'une seule fois avant que l'interface utilisateur de l'application ne leur soit transmise. Ceux-ci testent la fonctionnalité et la logique métier de l'application depuis le front-end de l'application.
Automatisation basée sur le type de tests
Tests unitaires:
Les tests unitaires sont les tests conçus pour tester le code d'une application et sont généralement intégrés au code lui-même. Ils ciblent les normes de codage comme la façon dont les méthodes et les fonctions sont écrites.
Ces tests sont plus souvent écrits par les développeurs eux-mêmes, mais dans le monde actuel, les testeurs d'automatisation peuvent également être invités à les écrire.
L'exécution de ces tests et l'absence de bogues de leur part signifiera que votre code sera compilé et exécuté sans aucun problème de code. Ces tests ne ciblent généralement pas les aspects fonctionnels de l'application et lorsqu'ils ciblent le code, il est plus approprié de les automatiser afin qu'ils puissent être exécutés au fur et à mesure des besoins du développeur.
Tests de fumée:
Le test de fumée est un test célèbre effectué dans le cycle de vie du test. Ce sont des tests post-build, ils sont exécutés immédiatement après la sortie de toute build de l'application pour s'assurer que l'application fonctionne toujours une fois la build terminée.
Il s'agit d'une petite suite de tests qui sera exécutée plusieurs fois et il est donc logique de l'automatiser. Ces tests sont généralement de nature fonctionnelle et selon le type d'application, un outil peut être choisi pour eux.
Tests API:
Les tests d'API sont devenus très célèbres ces dernières années. Les applications basées sur l'architecture API peuvent effectuer ces tests.
Lors des tests d'API, les testeurs valident la couche métier de l'application en vérifiant les combinaisons requête-réponse pour les différentes API sur lesquelles l'application est construite. Les tests API peuvent également être effectués dans le cadre des tests d'intégration ci-dessous.
Tests d'intégration:
Le test d'intégration comme son nom l'indique signifie tester l'application en intégrant tous les modules et en vérifiant la fonctionnalité de l'application.
Les tests d'intégration peuvent être effectués via des tests d'API ou via la couche d'interface utilisateur de l'application.
Tests d'interface utilisateur:
Les tests d'interface utilisateur sont effectués à partir de la couche d'interface utilisateur ou du frontend de l'application. Ceux-ci peuvent cibler le test de la fonctionnalité ou simplement tester les éléments d'interface utilisateur d'une application.
L'automatisation de l'interface utilisateur pour tester la fonctionnalité est une pratique courante. Cependant, l'automatisation des fonctionnalités de l'interface graphique est l'une des automatisations les plus compliquées.
Tests de régression:
L'une des suites de tests les plus automatisées est la suite de tests de régression. La régression, comme vous le savez peut-être déjà, est le test qui est effectué à la fin du test d'un nouveau module pour s'assurer qu'aucun des modules existants n'a été affecté par celui-ci.
Il est répété après chaque nouvelle itération de test et les principaux cas de test restent fixes avec généralement quelques nouveaux ajouts après une nouvelle itération. Comme il est fréquemment exécuté, presque toutes les équipes de test essaient d'automatiser ce pack.
L'automatisation comme intégration continue:
L'intégration continue peut à nouveau s'exécuter sur les tests de régression automatisés eux-mêmes, cependant, pour atteindre l'IC, nous permettons à la régression ou à la suite de tests identifiée d'être exécutée chaque fois qu'un nouveau déploiement est effectué.
Tests de sécurité:
Les tests de sécurité peuvent être à la fois fonctionnels et non fonctionnels, ce qui implique de tester l'application pour les vulnérabilités. Les tests fonctionnels composeront des tests liés à l'autorisation, etc., tandis que les exigences non fonctionnelles peuvent être des tests d'injection SQL, de scripts intersites, etc.
Tests de performance et contrôle qualité:
Les tests de performance sont des tests non fonctionnels qui ciblent les exigences telles que les tests de charge, de stress, d'évolutivité de l'application.
Tests d'acceptation:
Les tests d'acceptation relèvent à nouveau des tests fonctionnels qui sont généralement effectués pour s'assurer que les critères d'acceptation donnés par le client ont été remplis.
Jusqu'à présent, nous avons décrit le type de tests qui peuvent être automatisés et diverses classifications de ceux-ci, toutes les classifications aboutiront finalement à l'automatisation des mêmes résultats finaux d'une suite de tests. Comme nous l'avons dit précédemment, un peu de compréhension est nécessaire sur la façon dont ceux-ci sont différents des cadres.
Une fois que vous avez identifié les tests que vous souhaitez automatiser à partir de la classification ci-dessus, vous devrez concevoir votre logique de manière à exécuter ces tests en douceur, sans trop d'intervention manuelle. Cette conception d'une suite de tests manuels en une suite de tests automatisés est l'endroit où les frameworks entrent en jeu.
Nous allons maintenant explorer les 3 principaux types d'automatisation de test
- Test unitaire
- Test API
- Test GUI
#1) Tests unitaires automatisés
Tests unitaires automatisés sont écrits pour tester le niveau de code. Les bogues sont identifiés dans les fonctions, méthodes et routines écrites par les développeurs.
Certaines entreprises demandent aux développeurs de faire les tests unitaires eux-mêmes et certaines embauchent des ressources spécialisées en automatisation de test. Ces ressources ont accès au code source et écrivent des tests unitaires pour casser le code de production.
En raison de la présence de tests unitaires, chaque fois que le code est compilé, tous les tests unitaires s'exécutent et nous indiquent le résultat que si toutes les fonctionnalités fonctionnent. Si un test unitaire échoue, cela signifie qu'il y a maintenant un bogue présent dans le code de production.
Certains des outils les plus populaires présents sur le marché comprennent NUnit et JUnit . Microsoft fournit également son propre cadre de test unitaire appelé MSTest . Parcourez les sites Web de ces outils et ils vous fourniront plus d'exemples et de didacticiels sur la façon d'écrire des tests unitaires.
#deux) Tests de service Web / API automatisés
Une interface de programmation d'application (API) permet au logiciel de communiquer avec d'autres applications logicielles. Comme tout autre logiciel, les API doivent être testées. Dans ce type de test, l'interface graphique n'est généralement pas impliquée.
Ce que nous testons ici, ce sont généralement les problèmes de fonctionnalité, de conformité et de sécurité. Dans les applications Web, nous ne pouvons tester la demande et la réponse de notre application que si elles sont sécurisées et cryptées ou non.
C'est l'un des exemples où nous pouvons utiliser les tests d'API. L'outil le plus populaire pour les tests d'API est SAVON qui a des versions gratuites et payantes. Il existe également d'autres outils que vous pouvez utiliser en fonction de vos besoins.
# 3) Tests GUI automatisés.
Ce type de test automatisé est la forme d'automatisation la plus difficile car il implique le test d'une interface utilisateur de l'application.
C'est difficile car les interfaces graphiques sont très sujettes à changement. Mais ce type de test est également le plus proche de ce que les utilisateurs vont faire avec notre application. Comme l'utilisateur utilisera la souris et le clavier, les tests GUI automatisés imitent également le même comportement en utilisant la souris et le clavier pour cliquer ou écrire sur des objets présents sur l'interface utilisateur.
Pour cette raison, nous pouvons trouver des bogues tôt et il peut être utilisé dans de nombreux scénarios tels que les tests de régression ou le remplissage de formulaires, ce qui prend trop de temps.
Les outils de test GUI les plus populaires incluent Test fonctionnel unifié Micro Focus (UFT) , Sélénium , Test terminé et Interface utilisateur codée Microsoft (qui fait partie des éditions ultime et premium de Visual Studio).
Tout comme les types de tests d'automatisation, il existe également plusieurs types de frameworks.
Cadres d'automatisation
Certains cadres d'automatisation couramment utilisés comprennent:
- Linéaire (enregistrement et lecture)
- Mot-clé
- Axé sur les données
- Modèle d'objet de page
- Modulaire
Lectures complémentaires => Cadres d'automatisation
Comme vous pouvez le voir, la première étape du processus d'automatisation consiste à identifier le type d'automatisation, puis vous pouvez identifier le cadre à concevoir et en gardant cela à l'esprit, vous pouvez sélectionner les outils qui répondent à vos besoins.
Outils d'automatisation
En fonction du type de test que vous ciblez et du type de cadre que vous souhaitez créer autour de celui-ci, les outils suivants sont disponibles:
- Sélénium : Outil très puissant pour tester les applications Web. Fournit une prise en charge de plusieurs navigateurs.
- Junit et Nunit: Outils principalement utilisés pour les tests unitaires par les développeurs.
- QTP : Excellent outil pour les applications non Web et est livré avec un référentiel d'objets intégré.
- Sikuli: Outil open source pour les tests d'interface graphique.
- Soap UI: Outil de test d'API.
- Repos assuré: Bibliothèque pour créer un framework de test API.
- appium : Outil qui prend en charge les tests mobiles, les tests d'applications natives, les tests d'applications Web hybrides et mobiles.
- Jmètre : Un outil utilisé pour les tests de performance.
- TestNG: TestNG n'est pas un outil d'automatisation en soi, cependant, il fournit un excellent support aux cadres d'automatisation construits avec du sélénium, de l'appium, rassurez-vous, etc.
Lectures complémentaires => Outils d'automatisation des tests
Idées fausses sur les tests d'automatisation
Au fil des ans, j'ai entendu certaines idées fausses sur l'automatisation des tests. Je pense que je devrais aussi les effacer dans cet article.
Idée fausse # 1. L'automatisation est là pour remplacer les testeurs manuels.
L'automatisation des tests vise à aider les testeurs à rendre les tests plus rapides et plus fiables. Il ne pourra jamais remplacer les humains.
Pensez à l'automatisation des tests comme à une voiture. Si vous marchez, vous mettrez environ 20 minutes pour rejoindre votre domicile. Mais si vous utilisez une voiture, vous arriverez en deux minutes. Le conducteur de la voiture est toujours vous, un humain, mais .. la voiture aide l'humain à atteindre son objectif plus rapidement. De plus, la majeure partie de votre énergie est économisée, car vous n’avez pas marché. Ainsi, vous pouvez utiliser cette énergie pour effectuer des choses plus importantes.
Il en va de même pour les tests d'automatisation. Vous l'utilisez pour tester rapidement la plupart de vos tests répétés, longs et ennuyeux et économisez votre temps et votre énergie pour vous concentrer et tester de nouvelles fonctionnalités importantes.
Comme James Bach a dit une merveilleuse citation:
«Les outils ne testent pas. Seuls les gens testent. Les outils n'effectuent que des actions qui «aident» les gens à tester. '
Les outils peuvent cliquer sur des objets. Mais où cliquer sera toujours indiqué par un testeur manuel. Je pense que vous comprenez maintenant mon point.
Idée fausse # 2 . Tout sous le soleil peut être automatisé
Si vous essayez d'automatiser 100% de vos scénarios de test, vous pourrez peut-être le faire, mais si vous pouviez le faire, notre premier point deviendrait faux. Si tout est automatisé, que fera un testeur manuel?
Embrouillé? Droite?
En fait, le fait est que vous ne pouvez pas automatiser 100% de vos cas de test. Parce que nous, en tant que testeurs, pensons qu'aucune application ne peut être testée à 100%. Il y aura toujours des scénarios qui nous manqueront. Il y aura toujours des bogues qui surviennent uniquement lorsque votre application sera utilisée par les clients.
Si l'application ne peut pas être testée à 100%, comment promettre une automatisation à 100%?
En outre, il y a de très faibles chances que vous puissiez automatiser tous vos cas de test existants. Il existe toujours des scénarios difficiles à automatiser et plus faciles à réaliser manuellement.
Par exemple , Un utilisateur entrera les données, le deuxième utilisateur approuvera les données, le troisième utilisateur affichera les données et le quatrième utilisateur ne pourra pas voir les données. Ces scénarios peuvent être automatisés, mais ils prendront beaucoup de temps et d'efforts. Ce sera donc plus facile si vous faites cela manuellement.
N'oubliez pas que nous utilisons des voitures pour parcourir des distances, mais il peut y avoir de longs signaux sur le chemin, il y aura de la consommation de carburant, il y aura des problèmes d'espace de stationnement, des frais de stationnement et beaucoup plus de maux de tête. Dans certains scénarios, nous marchons et atteignons notre destination :) .
Ainsi, vous ne devriez pas essayer de tout automatiser. N'automatisez que les scénarios importants et ceux qui prennent beaucoup de temps à faire manuellement.
Idée fausse # 3 . L'automatisation implique uniquement l'enregistrement et la lecture.
Veuillez ne pas vivre dans un monde fantastique. Ce fantasme est en fait créé par de fausses publicités de différents fournisseurs d'outils d'automatisation. Ils disent que vous venez d'enregistrer et de lire vos pas et que vos scénarios de test seront automatisés. Eh bien, c'est un gros mensonge!
L'automatisation est tout et pas seulement l'enregistrement et la lecture. Les ingénieurs d’automatisation purs n’utilisent généralement pas du tout les fonctions d’enregistrement et de lecture. L'enregistrement et la lecture sont généralement utilisés pour avoir une idée de la façon dont l'outil génère un script pour nos étapes.
Une fois que nous connaissons le script, nous utilisons toujours le script pour créer des tests automatisés. Rappelles toi, vous devez connaître la programmation si vous voulez faire de l'automatisation de test . D'un autre côté, ne soyez pas découragés si vous ne connaissez pas la programmation. Comme toute autre tâche, la programmation peut également être apprise avec de la pratique et du dévouement.
Je connais des gens qui ne sont même pas issus de l'informatique, mais ils apprennent à programmer et maintenant ce sont de formidables ingénieurs en automatisation. Chez Microsoft, ils embauchent des testeurs capables de programmer. Ils s'appellent SDET (Ingénieurs en développement logiciel pour test). La première ligne de la description du poste dit 'SDET écrit beaucoup de code…'.
Apprenez à programmer, ne fuyez pas. Cela fera de vous un testeur incroyable .
Conclusion
J'espère que cet article vous aurait aidé à clarifier certains concepts liés à l'automatisation des tests.
Nous avons couvert un niveau élevé de différents types de tests d'automatisation, avec différentes façons de classer.
Les principales classifications comprennent:
- Automatisation basée sur le type de test (fonctionnel ou non fonctionnel).
- Automatisation basée sur la phase de test (unité, API ou UI).
- Automatisation basée sur les différents types de tests (plusieurs types de tests).
Nous avons également répertorié les différents outils pouvant être utilisés pour ces types de tests automatisés.
Dans notre prochain article, nous discuterons de la procédure étape par étape de comment démarrer l'automatisation des tests dans votre organisation .
Tutoriel PREV # 1 | Tutoriel SUIVANT # 3
lecture recommandée
- Test de charge avec les didacticiels HP LoadRunner
- Meilleurs outils de test de logiciels 2021 [Outils d'automatisation des tests QA]
- Les testeurs perdent-ils leur emprise sur les tests en raison de l'automatisation?
- Défis des tests manuels et automatisés
- Processus de test d'automatisation en 10 étapes: comment démarrer les tests d'automatisation dans votre organisation
- Êtes-vous un expert en tests manuels ou automatisés? Travaillez à temps partiel pour nous!
- 11 meilleurs outils d'automatisation pour tester les applications Android (outils de test des applications Android)
- Top 10 des meilleurs livres de tests de logiciels (livres de tests manuels et d'automatisation)