Bonjour, chers lecteurs.
Je veux parler de l'expérience de la construction d'un système d'automatisation des tests lorsqu'il n'y a aucun test sur le projet ou que son degré est minime.
J'espère que l'article sera utile aux autotests pour débutants.
- Dans la première partie, nous privilégions l'approche générale.
- Dans la deuxième partie ( Partie 1 ) avec des exemples nous ferons le projet de tests automatiques sur JAVA + apprendre à tester rapidement l'API.
- Dans la troisième partie, nous compléterons le projet de tests d'interface, nous ferons des tests parallèles.
Quand faire des autotests?
La réponse courte est le plus tôt possible.
Un complet sera révélé ci-dessous. En tout cas, lorsque le projet fonctionne depuis 3 ans, et que tout a été vérifié manuellement, la vie devient très monotone. Et une flotte de 5000 scénarios à automatiser en un mois ou deux est problématique. En règle générale, dans de tels projets, vous devrez recommencer à travailler sur les scripts. Parce que ce sera plus rapide. Et pas le fait que les anciens pourront s'automatiser sans changements importants.
Pourquoi?
Parce que les autotets:
- Accumulez des scénarios de régression
- Impartial
- Rapide
Scénarios accumulés
Plus la flotte de scénarios automatisés est grande, plus il est probable qu'elle trouve une régression, surtout si les données changent à chaque exécution.
Si l'autotest a réussi de manière stable et est tombé sur une branche, ils ont soit changé les exigences, soit un bogue, soit l'infrastructure a échoué.
Impartialité
Si les exigences sont modifiées, l'autotest doit aller à la modification avec la modification de la fonctionnalité principale. C'est pourquoi les testeurs participent à l'approbation des savoirs traditionnels.
Si une exécution de test est automatiquement liée à une tâche, personne ne peut dire qu'elle n'a pas été testée. Ou vice versa, il le peut. En général, il y a nettement moins de problèmes.
La vitesse
Si chaque test satisfait aux conditions fastidieuses:
Condition préalable - Test - Postcondition
Ces tests sont faciles à automatiser.
Et puis, il est facile de paralléliser. Parce qu'ils sont indépendants.
Le nombre de threads - combien de serveurs de test peuvent supporter et afin de ne pas déranger les autres.
Le deuxième point est la vitesse elle-même. En mode manuel, cliquez sur la création du produit, sa recherche et son achat dans la boutique en ligne est de 5 minutes. 4 navigateurs. Total 20 minutes. Dans un seul petit scénario.
L'autotest dans ce scénario prend 1,5 minute. Mais sur 8 navigateurs. (Dernières et avant-dernières versions de chaque navigateur).
Par où commencer?
Avec des scripts personnalisés.
La valeur des tests atomiques diminue tout le temps, notamment sur les microservices. En général, dans un monde idéal, c'est le domaine de responsabilité du programmeur. Ces erreurs doivent être détectées au stade des tests unitaires.
Le contrôle qualité doit fonctionner à partir de la user story. Parce que le programmeur ne la connaît généralement pas et ne veut pas le savoir.
En conséquence, le test logique 1 - 1 cas utilisateur (scénario commercial) est le plus proche de la réalité.
Bien sûr, il y a des difficultés avec la préparation des données, par exemple, dans le cas d'une boutique en ligne, le processus de paiement par carte nécessite la présence de choses dans le panier, et soit des données pour un nouvel utilisateur, soit des données d'autorisation pour un existant.
Oui, les conditions préalables prennent parfois plus de temps qu’un test, mais il n’est pas difficile de réutiliser des scripts.
Quels scripts automatiser
Moins susceptible de changer à court terme. Pour l'automatisation, au moins certains ont vécu.
Ou le plus couramment utilisé. Il est logique d'aider les tests manuels à générer des données de test. Par exemple, dans le tableau d'affichage, il est logique d'automatiser la création d'annonces, car De plus, tout scénario nécessite une annonce créée.
Que faire exactement?
Habituellement dans les projets là-bas
- Backend
- Frontend
- Applications mobiles
- Glandes
Et les deux derniers points - vivent généralement séparément. Les téléphones portables sont testés sur leurs propres scripts, et peu sont capables d'aborder le débogage du fer selon JTAG sans préparation.
Par conséquent, je propose de traiter avec le backend et le front.
Choisissez un scénario
Disons que nous avons une boutique en ligne.
Il y a un panneau d'administration, il y a une façade client et administrateur.
Il existe une API qui sert tout cela.
Par où commencer l'automatisation?
Regardons.
Il y a des clients, il y a des employés.
Le client a le premier cas - visualiser et rechercher le produit, l'ajouter au panier et concevoir.
L'employé a le cas le plus courant - l'ajout d'une carte de produit.
Quel cas sera automatisé en premier? Et comment?
La chose la plus importante pour le magasin est la vente.
Par conséquent, l'historique des clients est le plus important pour les entreprises. Par conséquent, la première chose à faire est de trouver les marchandises, de les mettre dans le panier et de terminer le paiement avec n'importe quel mode de paiement.
Par API. Mais sans front. Ici, vous pouvez discuter, mais le design changera probablement 2-3 fois plus, mais le backend est peu probable. Donc à l'étape 1, vous devez vérifier l'interface manuellement.
Ensuite, faites des vérifications sur l'API qui édite la fiche produit et sa face avant.
Et revenez au client. À ce stade, il y aura déjà des statistiques sur les actions des utilisateurs les plus fréquentes et les chemins d'accès aux clients les plus fréquents. Oui, Yandex Metric et Webvisor aident également les testeurs.
Cela n'a aucun sens au premier stade de vérifier si la fonction de paiement sur le compte de l'entreprise via le système de paiement généré fonctionne si 0,5% des visiteurs utilisent cette fonction. Bien sûr, vous pouvez demander au responsable pourquoi cela est nécessaire ici, mais ce n'est pas tout.
Disons que 40% des personnes paient sur le site avec une carte, 30% en espèces, 20% en espèces à la livraison et 10% toutes les autres méthodes.
Quel type de paiement allons-nous vérifier en premier? Bien sûr, la carte.
Autrement dit, nous devons clairement comprendre quel scénario est le plus important pour l'entreprise en ce moment. Et sa qualité est avant tout.
Postconditions
Nous avons tout créé, tout dans les tests. Litière. Il faudrait nettoyer après vous. Il est nécessaire de prévoir à l'avance quels tests nous nettoierons après nous-mêmes et dans lesquels - pas.
Si les marchandises peuvent être laissées dans le magasin et que rien de mal ne se produira, l'ajout de droits d'administrateur à l'utilisateur régulier doit être retourné. Et puis le prochain test relatif aux droits pourrait tomber. Ou pire - devenez positif, même s'il aurait dû tomber.
Bizarreries
Il existe une approche étrange lorsqu'ils automatisent des scripts dans lesquels les utilisateurs trouvent un bogue. Habituellement, ce sont des scénarios très exotiques, et y consacrer une ressource n'a aucun sens. Il y a eu une situation où la fonctionnalité de mise à jour des données de la banque de contrepartie s'est rompue. La synchronisation avec le répertoire BIC a échoué.
Autrement dit, le nouveau BIC n'a pas été mis à jour. Mais la nouvelle banque a démarré normalement.
Est-il judicieux d'automatiser ce scénario? Si les entrepreneurs changent tous les jours - peut-être. Et puis c'était une faille dans la planification.
Si cela se fait 5 à 6 fois par an, est-il préférable de faire une tâche de plus haute priorité?
Que se passera-t-il ensuite?
Dans le prochain article, je vous dirai comment commencer rapidement à tester l'API, intégrer ces tests dans les versions, paralléliser les tests, comment sélectionner les données pour les tests et ce qu'elles nous apporteront.
Permettez-moi de vous rappeler l'effet d'un pesticide et comment le faire briller au minimum.
Technologies: Java + maven + testng + allure + RestAssured + Pict.