Et encore une fois dans notre cassette "Tester Calendar" . Ce mois-ci, Marina Tretyakova, testeur du projet Kontur Livraisons , parlera d'optimisation des tests. Marina analysera des problèmes spécifiques et comment les résoudre, et conseillera également comment optimiser ses tests et réduire le temps de test.

Tout d'abord, divisons tous les tests par le degré d'automatisation afin d'examiner plus en détail chaque type plus en détail.

Selon le degré d'automatisation, les tests sont répartis en:

1. Apprivoisé.
2. Automatisé.
3. Automatique (sans intervention humaine, pour le moment - plutôt un mythe que la réalité).

L'approche de l'optimisation des tests dépend directement du degré d'automatisation.

Optimisations applicables à tous types de tests

Les tests comprennent les étapes suivantes:

• préparation du système de test
• préparation des données d'entrée
• tests (manuellement ou automatiquement, nous considérerons ci-dessous),
• collecte et analyse des résultats.

On pense que la régression manuelle prend le plus de temps aux testeurs. Cependant, dans la plupart des cas, ce n'est pas le cas. Au minimum, vous ne devriez pas dire cela tant que le problème n'est pas mesuré et prouvé.

Envisagez des solutions aux problèmes courants. De nombreux conseils peuvent vous sembler extrêmement évidents, mais comme le montre l'expérience des conférences et discours de collègues d'autres sociétés, ces conseils sont toujours pertinents et ont prouvé leur applicabilité et leur utilité.

Les problèmes:

1. Longue préparation du système de test

Questions importantes à poser avant d'implémenter des optimisations:

• Depuis longtemps quoi?
• Qui est impliqué dans cette formation (testeurs, programmeurs ...)?
• Combien de fois pouvez-vous préparer un système de test au cours d'une journée de travail? Ce nombre correspond-il aux besoins de test?
• Quelle est la plus longue étape de préparation et pourquoi?

Pour trouver la cause de ce problème, il est important de poser la bonne question.
Considérez les exemples suivants:

Compilation longue de tous les modules du système
La bonne question est : tous les modules ont-ils besoin d'être compilés?
Solution : pour ne pas compiler tous les modules système, mais uniquement ceux qui ont été affectés par la tâche et qui participeront à la version.

Le long processus manuel de mise à jour de l'ensemble du système pour différentes "machines virtuelles" sur le banc de test
La bonne question est : à quel stade de la mise à jour la participation humaine est-elle requise et à quel stade?
Solution : automatisez le processus de calcul, utilisez des outils spéciaux de déploiement et de déploiement de services ou des mécanismes de version déboguée pour le «combat», mais utilisez-les uniquement pour le déploiement vers un test.

Le long processus de «renversement» du code source dans des «machines virtuelles» sur un banc de test pour une compilation et un roulement supplémentaires
Problème possible : connectivité réseau.
La bonne question est : combien de temps (collecte sur la machine locale, collecte sur le réseau local)?
Solution : le banc d'essai et l'endroit où se trouvent les sources doivent être sur le même réseau afin de minimiser l'interaction du réseau.

J'ai rencontré ce problème dans mon travail lorsque j'ai décidé de changer le site de test à Iekaterinbourg à Moscou. Et en essayant de «disposer» le site, nous avons rapidement remarqué que la mise à jour du stand commençait à prendre non pas 15 minutes, mais presque 15 minutes. La raison en était que le code source avec un grand nombre de petits fichiers était à Iekaterinbourg, et le stand était à Moscou. Le processus de calcul «reposait» sur le transfert en réseau de petits fichiers pour une compilation ultérieure et un «calcul» sur le stand. En conséquence, le code est également «parti» pour Moscou :)

2. Longue collecte et analyse des résultats

Questions importantes à poser avant d'implémenter des optimisations:

• Depuis longtemps quoi?
• Quelles sont les étapes du processus de collecte et d'analyse des résultats? Quelle étape est la plus longue et pourquoi?
• Qui analyse les résultats?
• Qui décide de la libération et sur quelle base? Combien de temps faut-il pour prendre une décision?

Par exemple :
Les résultats des tests sont publiés selon le modèle, l'enregistrement selon le modèle prend la plupart du temps pendant le test.

Solution (merci, Cap!) : Refusez de remplir les résultats du modèle ou créez un modèle plus facile à remplir. Il faudra se mettre d'accord avec l'équipe et s'informer auprès de ceux qui lisent ces résultats (les lisent-ils?), Existe-t-il vraiment un besoin d'un tel modèle (le risque est d'écrire les résultats du test «sur la table»).

Optimisations applicables aux tests manuels

Ces tests peuvent être divisés en deux grandes classes:

1. effectué régulièrement, par exemple avant la libération (envisager des tests de régression),
2. rarement et uniquement pour tester de nouvelles fonctionnalités.

Si la régression est souvent manuelle, il est logique de penser à l'automatisation et au retour sur investissement de l'automatisation, mais dans cet article, nous ne considérerons pas le retour sur investissement de l'automatisation.

Pour les tests manuels (pas de régression), il ne faut pas parler d' automatisation des tests, mais du support instrumental des tests (comme l'a conseillé Alexei Barantsev lors de la formation que nous avons menée dans notre entreprise). Dans ce cas, les autotests serviront d'outil. Dans ce contexte, la logique et la vision des autotests en général vont changer.

Pour les tests manuels, vous devez tout d'abord rechercher les tâches de routine (tâches, pas les tests!), Et déjà les optimiser (en utilisant l'automatisation ou la redistribution des ressources humaines).

Par exemple, la routine des tests consiste à préparer les données de test. Il existe différentes façons d'effectuer cette préparation:

1. manuellement via l'interface utilisateur,
2. manuellement via l'API,
3. en exécutant des autotests, les données seront un effet secondaire de ces tests,
4. Automatisé via des scripts / utilitaires / outils personnalisés via API ou UI.

Si vous n'avez jamais pensé au temps qu'il vous faut pour préparer manuellement les données de test, alors peut-être qu'il est temps de les mesurer? Et il s'avère qu'il est beaucoup plus efficace d'utiliser au moins la seconde, et de préférence les 3e et 4e approches.

Optimisations applicables aux tests automatisés

Le problème de la préparation des données de test ici est plus aigu qu'avec les tests manuels. La préparation des données d'essai doit être:

1. rapide
2. Résistant aux changements de conception / disposition,
3. résistant aux éventuels essais parallèles,
4. Résistant aux changements dans l'architecture interne du système.

Il est souhaitable que la préparation des données ne nécessite pas de compétences et de temps supplémentaires dans la mise en œuvre de la solution.

Les données de test peuvent être préparées automatiquement:

1. via l'interface utilisateur,
2. via des requêtes API ou HTTP,
3. grâce à des requêtes de base de données.

Considérez les avantages et les inconvénients de ces approches plus en détail dans le tableau:

La préparation des données de test via des requêtes API ou HTTP pour une combinaison d'avantages et d'inconvénients est la plus optimale.

Il existe un certain nombre des optimisations les plus courantes qui s'appliquent aux tests automatisés:

Tester le parallélisme

Si l'un des problèmes des tests est précisément le moment de leur passage, alors qu'il existe des ressources de calcul, vous pouvez les paralléliser et les exécuter dans l'un des trois modes parallèles:

1. Parallélisme sur un ordinateur, parallélisme sur les threads du processeur.
2. Parallélisme sur différents ordinateurs.
3. La combinaison des première et deuxième méthodes, c'est-à-dire s'il y a plusieurs machines informatiques, les tests passent en parallèle le long des flux sur chacune et en parallèle entre toutes les machines.

Supprimer les anciens tests

Si les tests sont écrits, ils réussissent, mais ils ne vérifient pas vraiment quoi que ce soit (par exemple, il y avait une logique métier, maintenant elle n'existe plus et les tests ne vérifient essentiellement rien), alors ces tests doivent être impitoyablement supprimés, car en fait, ils n'ont aucune signification , enlevant ainsi du temps inutile à la course. Il convient également de supprimer les tests, le résultat de la réussite qui n'affecte pas la décision sur la possibilité de libération.

Utilisation de techniques de conception de test pour optimiser les ensembles de cas de test

Pour les tests manuels, pour optimiser les ensembles de cas de test, il est nécessaire d'appliquer diverses techniques de conception de test. Pour les autotests, des méthodes de division en classes d'équivalence, par paires, l'analyse des limites et de nombreuses autres techniques doivent également être utilisées pour optimiser l'ensemble d'autotests.

Transfert des tests et vérifications existants à un autre niveau

Par exemple, il existe un test de navigateur qui ouvre la barre de recherche, saisit «pomme», «pommes», «pomme», «pommes» (et ainsi de suite) et semble qu'à la fin de la recherche, il a reçu une notification concernant l'achat de pommes dans le magasin (test regarde le fait de montrer la notification et pas plus). Ainsi, un long test d'interface utilisateur ne vérifie pas essentiellement l'interface utilisateur, il vérifie la logique qu'un test unitaire peut tester, donc ce test doit être supprimé et un test unitaire écrit à la place.

Décomposition correcte des tests aux niveaux «modulaire - intégration - système»

Je vais vous donner un exemple. Il existe un scénario manuel: sélectionnez le produit dans la boutique en ligne, mettez-le dans le panier et passez à la caisse. Ce qui peut être fait (et ce sera faux): créez exactement un test qui va rechercher le produit, l'ajouter au panier et procéder à la conception.

Il sera correct dans ce cas de diviser d'abord le test en trois sous-scénarios: sélectionner un produit, ajouter un produit au panier et passer une commande. Nous diviserons chaque scénario en plusieurs contrôles atomiques.
Par exemple: «ouvrir un magasin - afficher différentes catégories de produits à sélectionner» - un test; «Sélectionner une catégorie dans différentes catégories de produits» est un autre test. Nous examinons chaque test plus en détail et déterminons le niveau de test nécessaire, l'exemple précédent peut indiquer quel type de test il est préférable de concevoir immédiatement en tant que tests unitaires.

Un schéma de connexion populaire des systèmes testés et de test pour le test automatisé des applications Web:

Pour optimiser les tests automatisés d'une application Web, il est conseillé de considérer l'optimisation de chaque interaction dans le schéma décrit.

Pour plus de simplicité, pensez à optimiser certaines interactions:

1) Interaction «cas de test - navigateur - base de données»
Utiliser l'API non seulement pour préparer les données pour le test, mais également pour effectuer un certain nombre d'étapes dans le test.

Par exemple, si l'objectif est de vérifier l'interface utilisateur à la fin d'une longue chaîne d'actions, il n'est pas nécessaire de mener toutes les actions via l'interface utilisateur. Après tout, si quelque chose s'est cassé au milieu de la chaîne dans l'interface utilisateur, le test n'atteindra jamais la fin et la vérification de la cible. Le testeur devinera, et s'il corrige ce maillon cassé dans la chaîne, alors tout ce qui fonctionne après? Si dans ce cas, tout au long de la chaîne, en plus de la dernière action, une API est utilisée, puis avec une ventilation de l'interface utilisateur de tout lien, le testeur saura si le système fonctionnera comme prévu si les développeurs corrigent le lien rompu.

2) Interaction «cas de test - SeleniumWebDriver - navigateur».

• Fermer les onglets supplémentaires à la fin du test, au lieu de fermer le navigateur.
  Sur mon projet, cette optimisation a permis de gagner 10 minutes en exécutant des tests d'interface utilisateur (au lieu de 1h 10 min, les tests ont commencé à passer en 1h). Cette optimisation est liée à la logique de SeleniumWebDriver, qui est utilisée sur le projet - elle a une très longue préparation pour ouvrir un navigateur, mais la fermeture des onglets se produit presque instantanément.
• Optimisation du cache d'application du système testé, pour que les tests passent plus rapidement.
• Utilisation de navigateurs sans tête afin de rendre le rendu des éléments de page Web gratuit.

En conclusion

Pour toute optimisation, vous devez identifier clairement par vous-même les problèmes actuels dans le processus de test, développer les points dans lesquels ils se trouvent, présenter des options possibles (mieux plusieurs!) Pour les résoudre. Après cela, il est nécessaire de les exprimer en équipe, de «vendre» leurs idées et suggestions pour une solution, et seulement après l'approbation universelle de répartir les efforts et de résoudre les tâches. Une évaluation préliminaire de «Avant» et une évaluation de «Après» aideront à considérer tous les gains de l'optimisation des processus.

Et encore une fois, je voudrais répéter: ne cherchez pas les tests de routine, recherchez les tâches de routine et automatisez-les!

Liste des articles du calendrier:
Essayez une approche différente
Test de paire raisonnable
Commentaires: comment cela se passe
Optimiser les tests
Lire un livre
Tests analytiques
Le testeur doit attraper le bug, lire Caner et organiser le déplacement.
Service de chargement
Mesures de service d'assurance qualité
Test de sécurité
Apprenez à connaître votre client
Prendre l'arriéré