[JAVA] J'ai étudié l'automatisation des tests

J'ai étudié l'automatisation des tests

introduction

«Je n'ai jamais fait de test de code ou d'automatisation de test auparavant, et cela fait un peu plus de six mois que j'ai rejoint l'entreprise actuelle et commencé à écrire du code de test.

• Le langage est principalement php, javascript (nœud) ――Avant d'écrire le code de test Afin d'élever la raison et la motivation de l'écriture du code de test, je vais résumer le code de test et le test, y compris le sentiment que j'écris actuellement.

Historique jusqu'à l'automatisation des tests

• Années 60
• La méthode d'automatisation des tests a été envisagée dès 1962.
• Crise logicielle «L'histoire revendiquée lors de la 1ère Conférence de l'OTAN sur l'ingénierie logicielle à la fin des années 1960, il a été dit que la complexité du développement logiciel s'accélérera en raison des performances plus élevées des ordinateurs. ―― À cette époque, les discussions sur les méthodologies de développement logiciel telles que la programmation structurée et les tests automatisés ont commencé à devenir plus actives en réponse à un développement logiciel devenu plus complexe.
• années 70
• Technique de test de logiciel 1976
• À mesure que la complexité des logiciels augmente, des méthodes de test pour améliorer la qualité des logiciels ont été étudiées et établies. --Programmation orientée objet
• Afin de faire face à la complexité des logiciels, la façon de penser orientée objet selon laquelle la programmation est comparée à un objet réel (chose) a commencé à devenir populaire.
• Années 80
• Mythe de la lune humaine (pas de balle d'argent) 1988
• Un article célèbre sur le développement de logiciels. Dans le développement de logiciels, il a laissé derrière lui la célèbre phrase «il n'y a pas de solution miracle», ce qui signifie qu'il n'y a pas de méthode universelle pour tous les événements. Un autre mot célèbre de la loi de Brooks est que l'ajout de personnel à un projet logiciel qui est retardé ne fait que retarder le projet encore plus. --1990s
• Programmation extrême (communément appelée XP) 1999 La méthode elle-même a été autour de 1996
• Un livre sur les méthodes de développement écrit par Kent Beck, qui est également célèbre en tant que développeur de petites conversations. Il contient les principales idées des idées de tests automatisés modernes. (Les détails seront décrits plus tard)
  • Scrum
• L'une des méthodes de développement agile. J'ai l'image que j'entends le plus récemment. ――Une méthode de création d'un produit en formant un sprint dans un court laps de temps et en collaborant avec le scrum master, le product owner et l'équipe. ――Le Scrum Master vous aidera à présenter Scram, le propriétaire du produit travaillera sur le produit avec les exigences et les responsabilités de l'entreprise, et l'équipe travaillera ensemble pour répondre aux demandes commerciales du propriétaire du produit.
• Bien qu'il n'y ait pas de description détaillée de l'automatisation des tests dans la méthode de développement proposée en même temps que XP, l'automatisation des tests est fondamentalement introduite comme une méthode de développement dans un court laps de temps.

--2000s

• Démarrage allégé ―― À proprement parler, ce n'est pas une méthode de développement logiciel, mais une méthode de création d'entreprise, mais c'est une méthode de développement souvent utilisée par les start-up. Une des méthodes de développement agiles. Une méthode de création d'un produit minimum pratique MVP (Minimum Viable Product), de répétition d'hypothèses et de vérifications et d'amélioration du produit. Les tâches et méthodologies répétitives ont beaucoup en commun avec XP et les méthodes agiles.
  • DevOps
• Une méthode de développement dans laquelle le personnel de développement et le personnel des opérations coopèrent et coopèrent dans un langage de sac qui combine développement et opérations. Une méthode de développement qui relie de manière transparente les opérations, l'infrastructure et le développement. L'introduction de l'automatisation des tests et de l'automatisation de l'infrastructure a été préconisée.

Types de tests logiciels

• Type de test. Les mots suivants peuvent être utilisés comme phase de test, mais ici ils sont classés comme type de test. Il existe différents noms selon l'entreprise.

Test de l'unité

--Test pour vérifier si la fonction de chaque module est satisfaite

• Communément appelé UT (test unitaire)
• Fait essentiellement dans un test de boîte blanche

Test combiné

--Concaténer et tester chaque module

• Communément appelé IT (test d'intégration)
• Le test de fonction de test de fonctionnement est similaire à ici
• Dans certains cas, les tests de connexions externes telles que les API externes sont effectués étape par étape.
• Fondamentalement, un test de boîte noire, parfois une image de test de boîte blanche

Test complet

• Un test qui combine toutes les conditions telles que l'API externe et le navigateur
• Préparez un environnement équivalent à la production et effectuez le test. Ici, nous vérifions si le programme fonctionne comme requis --UAT (test d'acceptation de l'utilisateur)
• Fait essentiellement dans un test de boîte noire

Tester la perspective

• Les points de vue à tester lors de la réalisation de tests logiciels peuvent être largement divisés en «exigences fonctionnelles» et «exigences non fonctionnelles».

Exigences fonctionnelles

• Des pièces qui répondent aux exigences du client
• Vérifiez que le code que vous avez créé répond aux fonctionnalités requises par le client et qu'il fonctionne correctement selon les besoins. ――La partie qui peut être garantie par le code de test est essentiellement cette partie

Prérogatives non fonctionnelles

--Pièces autres que les spécifications et les fonctions

• Sécurité de l'information
• la performance
• Performances du serveur --Conception de réseau
• Méthode de récupération en cas d'échec, etc.

Processus de test

• Analyse de test
• Conception de test

Histoire de code de test

Type de code de test

Test de l'unité

-Test d'unité, communément appelé UT (test unitaire)

• Un test pour confirmer que le code fonctionne comme prévu par le développeur ≠ Un test qui garantit les exigences de l'entreprise --Créez pour chaque méthode. Grain fin --Stub et simulez les pièces qui dépendent d'autres modules et testez
• mérite
• En écrivant du code de test, les développeurs peuvent comprendre plus en profondeur la gamme fonctionnelle de chaque module. ――La granulométrie est correcte et vous pouvez analyser en détail la partie où le bogue s'est produit.
• Le code de test qui exprime la fonction de la méthode est créé, et le développeur peut lire le code de test et lire l'intention de la méthode plus tard.
• Inaptitude
• Comme l'exhaustivité est requise, le coût d'écriture du code de test augmente en fonction du contenu logique.
• Avec un code étroitement couplé, il est difficile d'écrire du code de test, et il est facile de demander du code qui est facile à écrire des tests faiblement couplés.

Test fonctionel

--Test fonctionnel

• La partie où chaque module (API externe et partie DB) est connecté est également testée. Grande granulométrie
• Tester plusieurs modules ensemble, y compris si le programme répond aux exigences
• mérite
• Vous pouvez trouver des bogues causés par les conditions de combinaison de chaque module qui ne peuvent pas être compris par lui-même. --API etc. peut être confirmé jusqu'au niveau des exigences, pas la logique du programme lui-même
• Inaptitude
• Parce que la granularité du test est grande, il est difficile d'identifier où le bogue s'est produit.
• Étant donné que le contenu du test nécessite une logique métier, des exigences et un IF pour la communication avec l'extérieur, il est nécessaire de vérifier le contenu du code simple + comprendre les exigences, de sorte que la plage à comprendre devient grande.

Test de l'interface utilisateur

• Le test utilisant un logiciel qui exécute des navigateurs et des applications réels tels que sélénium et appinum a la plus grande granularité.
• mérite ―― Comme tout peut être connecté et testé, la plage qui peut être confirmée est large et les exigences peuvent être confirmées. ―― Puisque vous pouvez vérifier l'environnement qui fonctionne réellement, vous pouvez également vérifier les facteurs externes tels que la dépendance à l'environnement du navigateur.
• Inaptitude ――Parce que la plage de confirmation est large, le code compliqué a tendance à être volumineux et la maintenance a tendance à être difficile. ――Parce que cela se fait par test de boîte noire, il est difficile de savoir où le bogue s'est produit.

Projets dans lesquels vous devez introduire du code de test

--Un projet à long terme qui tient compte de la maintenance --Projets avec de nombreux changements de spécifications et des changements fréquents de personnes

Raisons d'écrire du code de test

• Pour réduire le coût des tests ―― Puisque le test unitaire fonctionne de manière exhaustive, je pense que le coût du test de régression peut être réduit une fois qu'il est écrit. --Parce que le code est facile à tester, vous serez conscient des programmes faiblement couplés.
• Parce que le code de test lui-même devient une spécification pour les programmeurs ―― En réfléchissant au code de test, vous approfondirez votre compréhension des exigences.

Tester la granularité

• L'importance du code de test est généralement considérée comme importante dans l'ordre test unitaire> test fonctionnel> test UI. ――Il est important pour les tests fins tels que les tests d'intégration car vous pouvez vérifier les spécifications, mais les conditions sont compliquées, ce qui complique la maintenance des tests, et quand un bogue survient, quelle partie est la cause du bogue? Comme il est difficile de comprendre, les bases de l'expansion à partir des tests unitaires où la granularité est faible et il est facile de corriger les tests et de trouver des bogues

L'effet du code de test

--Réduire le stress du programmeur --Le programme est une tâche stressante

• Vous devez comprendre les spécifications ―― Écrivez en tenant compte de diverses choses telles que le système anormal ainsi que le système normal ―― En premier lieu, vous devez réfléchir à la manière de l'exprimer dans le programme ――Si les spécifications changent, vous devez le refaire ...
• Il faut penser aux performances et à la lisibilité ... --Facile à changer etc ... ―― Le programmeur doit écrire le programme avec diverses considérations. ――Il est très difficile d'écrire du code correct à la fois. Il peut y avoir des changements dans les spécifications. --Je ne sais pas où un programme sans code de test se cassera.
• Ecrire le code de test
• → Rendre facile de voir ce qui s'est cassé lors de la refactorisation
• → Réduire le stress du programmeur

À propos du coût du code de test

――Le coût d'écriture du code de test est la moitié de celui de l'implémentation, ce qui est rapide pour les personnes expérimentées, et 1,5 à 2 fois le coût de l'implémentation, qui est le même que celui de l'implémentation pour les personnes inconnues. (Sensation de peau personnelle)

• Lors de l'introduction de code de test dans un code qui n'a pas de code de test, le coût de l'introduction du code de test est souvent élevé car le code lui-même ne sait pas que le code de test est écrit.
• Le code de test entraîne également des coûts de maintenance qui changent en fonction du code de l'unité principale lorsqu'il est modifié.
• Introduction de l'environnement de code de test, coût de l'apprentissage de l'écriture du code de test lui-même

Extreme Programming XP (programmation eXtreme)

--Méthode de développement pour remplacer le type de cascade proposé dans les années 1990

• Le livre a été compilé en 1999 ――Une des origines de la méthode de développement actuelle dite agile —— Comprend 4 valeurs, 5 principes de base et 19 bonnes pratiques ――La cascade conventionnelle se caractérise par une méthode de répétition du développement dans un cycle court et s'améliore petit à petit, par rapport à la méthode de passage au processus suivant une fois le processus précédent complètement terminé.

TDD(Test Driven Development)

• Développement basé sur les tests
• Proposé par kent beck comme l'une des meilleures pratiques de XP --XP et code de test ――XP est basé sur le développement dans un cycle court, les exigences et le code changent constamment, et les programmeurs vont refactoriser alors qu'il est difficile de tous les comprendre pleinement. Le code de test vous aide à modifier courageusement ce code changeant
• Une méthode appelée test-first, dans laquelle vous écrivez un test d'échec avant de l'implémenter, puis commencez à l'implémenter. --BDD et FDD sont des méthodes de développement pour le développement (je ne suis pas familier avec cela car je ne l'ai pas fait auparavant)

Tester d'abord

--Une des méthodologies de base de TDD, une méthode d'écriture d'un test avant l'implémentation, de décider de l'interface du contenu d'implémentation, puis de l'implémenter pour assurer le mouvement de l'implémentation et avoir le code de test en même temps que l'implémentation. .. Améliorez le code en passant par le cycle «Rouge» → «Vert» → «Refactor» pour le code. --Procédure

• Ecrire un test d'échec qui décrit le contenu de la méthode IF et la sortie (rouge) -- Test échoué Poursuivre l'implémentation et réussir le test` (Vert)
• Modifiez le contenu du code pour que le test terminé n'échoue pas, et ajoutez des tests si nécessaire (Refactor)
• S'il y a un changement de code, écrivez à nouveau un "test échoué", implémentez le code en fonction du test et parcourez le cycle.

Framework de code de test

«Fondamentalement, il existe de nombreuses séries xUnit, y compris des matériaux, donc à moins qu'il n'y ait une raison particulière, il est préférable d'utiliser la série xUnit de chaque langage.

• Cadre de test pour chaque langue (exemple)
• php
  • PHPUnit
  • behat
• java
  • jUnit
• javascrpt
  • mocha
  • ava
  • jasmine
• Ruby
  • minitest
  • RSpec
• Python --unittest (inclus dans les fonctions standard)
  • Pytest

CI (intégration continue)

--Dans le projet d'introduction du code de test, il est recommandé d'introduire un environnement pour exécuter automatiquement le code de test introduit. Il est construit à l'aide de jenkins, etc., et récemment, des services spécialisés dans les fonctions CI telles que Circle CI et Travis CI ont été développés.

Ce dont vous avez besoin pour écrire le code de test

--Coopération d'équipe

• Faites l'effort d'écrire le code de test
• Environnement commun pour l'écriture de code de test --Automatiser l'environnement d'exécution des tests --Écrire un exemple de code afin que d'autres personnes puissent l'écrire car il peut être copié dans un premier temps
• Exigences détaillées au début pour écrire le code de test tôt

De côté

Ce que je fais et à quoi je pense récemment

• Lors de la création de MR / PR de l'implémentation, associez le code de test (au moins le système normal) de l'implémentation.
• Le côté révision peut également vérifier le contenu de l'implémentation avec le contenu du code de test, et vous pouvez également tester la confirmation du code.
• Considérez la priorité du code de test ――Il est important d'étendre correctement le test, mais le degré d'avancement du projet et le degré de détermination des exigences déterminent le test qu'il est avantageux d'écrire à ce moment-là. --Exemple --Si les exigences sont moelleuses
• D'abord, rédigez un test fonctionnel qui garantit les exigences avec un contenu de vérification lâche, puis écrivez un test fin après avoir fixé les exigences. --Si les exigences sont cliquées --Écriture à partir du test unitaire (je veux écrire)
• À propos de la portée, du nom et de la signification du test ――Je souhaite séparer la gamme des définitions qui font référence aux tests unitaires et aux tests fonctionnels. ――S'il s'agit d'un test unitaire au sens pur, toutes les parties qui dépendent d'autres méthodes doivent-elles être moquées ou stubées? Je pense aussi que, selon la gamme que vous voulez vérifier, si vous voulez combiner un peu, cela s'appelle un test d'intégration? Si oui, je pense que la gamme à laquelle le mot test d'intégration se réfère est trop large. Ou, je veux des mots qui peuvent organiser la portée et la signification du test Mouchi. .. ..

finalement

Le code de test n'est pas une solution miracle.

―― Le code de test présente divers avantages, mais ce n'est pas une solution miracle efficace dans toutes les situations. «Mais je pense qu'avoir l'option courageuse d'écrire du code de test peut apporter de bons résultats. ――Je pense qu'il y a encore des malentendus et des pénuries en raison du manque d'étude, donc je vous serais reconnaissant de bien vouloir faire diverses demandes d'édition.