Poursuite d'une série d'abrégés avec HL2018. Les gars de Badoo (Vladimir
Yants vyants et Nikolai Krapivny) m'ont aidé à vérifier ce
recueil , dont je les remercie beaucoup. J'espère que cela a un effet positif sur la qualité du message du rapport.
Caractéristiques du processus de développement:
La responsabilité du développeur ne prend pas fin avec la sortie du backend. Il est responsable avant l'implémentation sur les plateformes.
Il y a un test manuel, mais le client n'est pas prêt au moment de la publication et est libéré avec un délai (imprévisible). Souvent, nous ne savons pas quand les clients commenceront à le mettre en œuvre. Parfois (pas souvent), les fonctionnalités commencent à être exécutées après une longue période. Par conséquent, le test avec vos mains est difficile et tout n'est pas possible. Par conséquent, des autotests sont nécessaires.
Les tests
Tests unitaires
Écrit en phpunit.
Testez une petite unité. Ils ne vont pas à la base de données ou aux services (ils ne doivent interagir avec rien).
Legacy a encore et complique le processus de test.
Ils ont développé la bibliothèque softMocks - elle inclut tous les crochets inclus / requis et la remplace par celle modifiée.
Vous pouvez liquider toutes les méthodes: statique, privée, finale.
La bibliothèque est disponible en open source.
Problème: les softmocks se détendent et vous permettent d'écrire du code non testé (et de le couvrir de tests).
Accepté les règles:
- Le nouveau code devrait être facile à tester phpunit
- SoftMocks - cas extrême (ancien code / long / cher / compliqué)
Nous examinons la révision du code pour ces règles.
Test de qualité
Test de mutation
- Prenez le code
- Prenez la couverture du code
- Nous analysons le code et appliquons des mutations (change + => -; true => false, etc.)
- Pour chaque mutation, nous exécutons une suite (ensemble) de tests.
- Si les tests échouent, alors env. Sinon, ils ne sont pas assez efficaces. Nous comprenons, modifions / ajoutons des tests.
Il existe des solutions toutes faites (Humbug, Infection), mais elles ne convenaient pas (non compatible avec les softmocks, il y a des difficultés avec la couverture du code). Par conséquent, ils ont écrit le leur.
Les tests de mutation ne sont pas encore disponibles pour les tests manuels. Disponible pour s'exécuter manuellement, à partir de la console. Maintenant, nous l'implémentons dans le pipeline CI, nous construisons le processus. Le résultat sera sur Habr.
Tests d'intégration
Tester le fonctionnement de plusieurs composants conjointement; Nous vérifions le travail avec la base et / ou les services.
Approche standard des tests de bases de données (DBUnit):
- Augmenter la base de données de test
- Remplissez-le
- Exécutez le test
- Nous nettoyons la base de données
Les problèmes:
- Il est nécessaire de prendre en charge les tables de données et les jeux de données (pertinence du contenu de la base de données)
- Il faut du temps pour préparer la base de données
- Les lancements parallèles rendent les tests instables et provoquent des blocages
Solution: bibliothèque DBMocks (propre solution)
Principe de fonctionnement:
- Méthodes de pilote de base de données interceptées à l'aide de SoftMocks lors du test de configuration
- De la demande parsim db + table
- Tmpfs crée des tables temporaires avec le même schéma
- Toutes les requêtes vont uniquement aux tables temporaires
- Sur TearDown, ils sont supprimés.
La bibliothèque est petite, mais pas encore ouverte en open source.
Résultats:
- Les tests ne peuvent pas corrompre les données des tables d'origine
- Les tests sont isolés les uns des autres (peuvent être exécutés en parallèle)
- Test de la compatibilité des requêtes avec la version MySQL
Tests API
- Imitez une session client
- Capable d'envoyer des demandes backend
- Le backend répond presque comme un vrai client
En règle générale, ces tests nécessitent un utilisateur autorisé. Il doit être créé avant le test et supprimé après. Cela introduit des risques supplémentaires (réplication, tâches d'arrière-plan).
Solution: Nous avons créé un pool d'utilisateurs de test. J'ai appris à les nettoyer.
Les utilisateurs de test sont dans le même environnement que les vrais, car devel! = Prod. Il est nécessaire d'isoler les utilisateurs test et live.
Pour l'isolement, l'indicateur is_test_user a été ajouté pour l'utilisateur. Et ces utilisateurs sont également exclus de l'analyse et des résultats des tests A / B.
Il peut être rendu moins cher en envoyant des utilisateurs de test «en Antarctique», où personne ne les verra (sauf pour les pingouins).
API QA
Un outil pour préparer l'environnement dans les tests api, en fait une porte dérobée dans le backend pour changer rapidement les paramètres utilisateur / environnement.
- Méthodes API bien documentées
- Gérez les données rapidement et facilement.
- Les développeurs écrivent le backend
- Ne peut être appliqué qu'aux utilisateurs de test.
Permet à l'utilisateur de modifier des données immuables (par exemple, la date d'enregistrement).
Protection requise:
- Au niveau du réseau (disponible uniquement depuis le réseau du bureau)
- Un secret est transmis à chaque demande, dont la validité est vérifiée
- Les méthodes fonctionnent uniquement avec les utilisateurs de test.
Il existe un programme BugsBounty sur HackerOne. Ils paient pour les vulnérabilités trouvées. Un problème avec l'API QA a été trouvé en l'utilisant.
Se moquer à distance
Moki pour le backend distant.
Travaillez sur la base de moquettes molles. Le test demande au backend de s'initialiser pour la session fictive. Dès réception de la demande, le backend vérifie la liste des mox pour la session et les applique à l'aide de SoftMocks.
Exemple de test:
Les tests API sont trop pratiques. Il est tentant de les écrire au lieu de Unit. Mais les tests API sont beaucoup plus lents.
Adopté un ensemble de règles:
- Le but des tests API est de tester le protocole et l'intégration
- Vérifier le flux complexe
- Une petite variabilité ne peut pas être testée.
- Lors de la révision du code, nous testons également les tests.
Tests de l'interface utilisateur
La commande backend n'écrit pas.
La fonctionnalité est couverte par les tests Ui lorsqu'elle se stabilise.
Utilisé par le sélénium pour le Web. Pour calebasse mobile.
Essai de fonctionnement
100 000 tests unitaires. 6.000 intégration, 14.000 tests api.
Dans 1 flux, le temps est de 40 min / 90 min / 10 heures.
Made TestCloud - un cloud pour exécuter des tests.
La répartition du test entre les threads:
- Vous pouvez également (mal, tous les tests sont différents, il s'avère inégal dans le temps)
- Exécutez plusieurs threads et alimentez les tests phpunit un à la fois (surcharge d'initialisation. Long!)
Solution:
- Collecte de statistiques sur le temps d'exécution.
- Disposition des tests pour que le morceau ne dure pas plus de 30 secondes
Le problème avec les tests api est long, beaucoup de ressources et ne permettent pas aux autres de s'exécuter.
Pour résoudre, nous avons divisé le cloud en 2 parties:
- Exécute uniquement des tests rapides.
- Exécute les deux types de tests.
Le résultat est une accélération du temps pour:
- Unité - 1 min
- Intégration - 5 min
- API - 15 minutes.
Exécution de la couverture de code
Quels tests effectuer? Affiche la couverture du code.
- Nous obtenons des différences de branche
- Créer une liste de fichiers modifiés
- Obtenez une liste de tests pour ces fichiers.
- nous exécutons la suite exécutée uniquement à partir de ces tests.
La couverture se forme une fois par jour, la nuit, pour la branche maître. Les résultats (diff) sont ajoutés à la base de données.
Avantages:
- Nous exécutons moins de tests: moins de charge matérielle et des retours de test plus rapides
- Vous pouvez exécuter des tests pour les correctifs. Cela vous permet de déployer rapidement le correctif. Dans les patchs, la vitesse est la plus importante.
Inconvénients:
- Sortie backend 2 fois par jour. Après le déjeuner, la couverture est moins pertinente (mais lorsque nous déployons un rythme, nous conduisons toujours une suite complète).
- Les tests Api génèrent une couverture étendue. Pour eux, cette approche n'apporte pas beaucoup d'économies.
Si le développeur a besoin de voir immédiatement la couverture du code, c'est-à-dire un outil qui peut être lancé dans la console et obtenir immédiatement une nouvelle mesure pour la couverture d'un fichier / composant particulier.
Il est considéré comme délicat: les données sur le maître de coverege sont prises, tous les tests modifiés sont ajoutés, il s'avère une petite suite sur laquelle la couverture est déjà considérée.
Résumé
- Besoin de tous les niveaux de test
- Quantité! = Qualité. Examinez le code et testez les mutations
- Isolez les utilisateurs de test des vrais.
- Les backends dans le backend simplifient et accélèrent les tests d'écriture
- Collectez des statistiques sur les tests.
Les références