Briefing de l'automatisation des tests

Tests d'intégration

Ces tests vérifient comment différentes unités de code fonctionnent ensemble. Bien que les unités individuelles puissent fonctionner correctement individuellement, les tests d'intégration garantissent qu'ils fonctionnent ensemble. sont les tests les plus lents et les plus complexes ... une approche de générer automatiquement le test Les cas sont grâce à des tests basés sur un modèle qui utilisent des modèles du système pour la génération de cas de test, mais la recherche continue d'étudier diverses alternatives. Dans certains cas, une approche basée sur un modèle permet aux utilisateurs non techniques de créer des cas de test commerciaux automatisés en anglais simple tel qu'aucune programmation d'aucune sorte n'est nécessaire pour configurer plusieurs systèmes d'exploitation, navigateurs et appareils intelligents.Quoi automatiser, quand automatiser, et même si l'automatisation est vraiment nécessaire sont des décisions clés que l'équipe de test (ou de développement) doit prendre. Une revue de la littérature multipartite de 52 praticiens et 26 sources académiques ont révélé que cinq facteurs principaux à considérer dans Les décisions d'automatisation des tests sont:

1) Le système testé (SUT).

2) Le type et la quantité de tests.

3) Tester les outils.4) Sujets humains et organisationnels

5) Les facteurs de croisement, les facteurs individuels les plus courants identifiés dans l'étude étaient les suivants: le besoin de tests de régression, les facteurs économiques et la maturité du SUT.Une tendance croissante dans le développement de logiciels est l'utilisation de cadres de test unitaires, tels que les cadres Xunit (par exemple, JUnit et Nunit), qui permettent de effectuer des tests unitaires pour déterminer si diverses parties du code se comportent comme prévu dans diverses circonstances. Les cas de test décrivent les tests qui doivent être exécutés sur le programme pour vérifier que le programme fonctionne comme prévu.L'automatisation des tests, principalement à l'aide de tests unitaires, est une caractéristique clé de la programmation extrême et du développement de logiciels agiles, connue sous le nom de développement axé sur les tests (TDD) ou le développement de test. Les tests unitaires peuvent être écrits pour définir les fonctionnalités avant d'écrire du code. Cependant, ces tests unitaires évoluent et se développent au fur et à mesure que le codage progresse, les problèmes sont découverts et le code est refactorisé. Le code est considéré comme complet uniquement lorsque tous les tests pour toutes les fonctionnalités requises. qui peut être testé par le biais de tests exploratoires manuels. Il est considéré comme plus fiable en raison d'une meilleure couverture du code, et parce qu'il fonctionne en continu pendant le développement plutôt que une fois à la fin d'un cycle de développement de la cascade. Les développeurs découvrent les défauts dès qu'ils apportent des modifications, lorsque le coût de leur réparation est le plus bas. Enfin, le refactorisation de code est plus sûr lors de l'utilisation de tests unitaires; Convertir le code en une forme plus simple avec moins de duplication de code mais un comportement équivalent, et lorsque le code refactorisé est couvert par des tests unitaires, les nouveaux défauts sont beaucoup moins susceptibles d'être introduits.

Certaines tâches de test de logiciels, telles que les tests de régression d'interface de bas niveau étendus, peuvent être laborieux et longs à faire manuellement. De plus, les méthodes manuelles peuvent ne pas toujours être efficaces pour trouver certaines classes de défauts.Une fois les tests automatisés développés, ils peuvent être exécutés rapidement et à plusieurs reprises. De nombreux fois, cela peut être une méthode rentable de test de régression pour les produits logiciels avec une longue durée de vie. Même un petit patch dans le cycle de vie de l'application peut provoquer une rupture de la fonctionnalité existante qui était encore valide à un moment précédent.

Alors que les sociétés de développement de logiciels apprécient la réutilisabilité des tests automatisés, cette propriété peut également être considérée comme un inconvénient. Cela conduit à ce que l'on appelle le "pesticide Paradox, " où un script exécuté à plusieurs reprises cesse de détecter des bugs au-delà de son cadre. Dans ce cas, les tests manuels peuvent être un meilleur investissement. Cette ambiguïté conduit à nouveau à la conclusion que les décisions concernant l'automatisation des tests devraient être prises individuellement, en gardant à l'esprit les exigences du projet et les idiosyncrasies.Les outils d'automatisation des tests peuvent être coûteux et sont souvent utilisés en conjonction avec les tests manuels. L'automatisation des tests peut être rendue rentable à long terme, en particulier lorsqu'elle est utilisée à plusieurs reprises dans les tests de régression. Un bon candidat pour l'automatisation des tests est les cas de test pour le général Le flux de l'application, car il doit être exécuté chaque fois qu'une amélioration est effectuée dans l'application (test de régression). .

Dans les tests automatisés, les ingénieurs de test ou le personnel d'assurance qualité des logiciels doivent avoir des capacités de codage logiciel, car les cas de test sont écrits sous forme de code source, et la sortie est générée en fonction des affirmations en informatique lors de l'exécution. Certains outils d'automatisation des tests permettent de réaliser des mots de test via des mots clés au lieu de codage, ce qui ne nécessite aucune programmation.