Que sont les tests non fonctionnels ?
Dans Effectuer des tests fonctionnels dans Azure Pipelines, vous avez ajouté des tests d’interface utilisateur Selenium au pipeline. Les tests d’interface utilisateur sont une forme de tests fonctionnels. Dans cette partie, vous explorez les types de tests non fonctionnels que vous pouvez exécuter dans un pipeline.
L’équipe définit d’abord des tests non fonctionnels. Ils parlent de quelques-uns de ces types de tests. Ils décident ensuite d’un test non fonctionnel à ajouter à leur pipeline.
Comparaison des tests non fonctionnels et des tests fonctionnels
Dans Exécuter des tests fonctionnels dans Azure Pipelines, nous avons défini les tests fonctionnels et les tests non fonctionnels.
En bref, les tests fonctionnels vérifient que chaque fonction du logiciel fait ce qu’elle doit faire. En d’autres termes, les tests fonctionnels vérifient les fonctionnalités d’une application.
Les tests non fonctionnels vérifient les aspects non fonctionnels d’une application, comme les performances et la fiabilité. Vous pouvez également exécuter des tests non fonctionnels sur des systèmes qui ne sont pas des applications, comme les composants d’une infrastructure. Un exemple de test non fonctionnel est de déterminer combien de personnes peuvent se connecter simultanément à une application sans provoquer de problème, par exemple des temps de réponse plus lents.
En prenant l’exemple du site web Space Game, un test fonctionnel peut vérifier que le tableau des scores apparaît correctement et qu’il montre les enregistrements corrects quand l’utilisateur sélectionne un filtre. Un test non fonctionnel peut vérifier que le filtrage du tableau des scores se fait en moins d’une seconde, même quand de nombreux utilisateurs se connectent au site web en même temps.
Les tests non fonctionnels testent toujours quelque chose qui est mesurable. L’objectif est d’améliorer le produit. Par exemple, vous pouvez faire cela en améliorant l’efficacité de l’utilisation des ressources par l’application ou en améliorant les temps de réponse quand de nombreux clients l’utilisent simultanément. Voici quelques-unes des questions auxquelles les tests non fonctionnels peuvent répondre :
- Quelles sont les performances de l’application dans des circonstances normales ?
- Quelles sont les performances de l’application quand de nombreux utilisateurs se connectent simultanément ?
- Dans quelle mesure l’application est-elle sécurisée ?
Quels sont les types de tests non fonctionnels que je peux effectuer ?
Il existe de nombreux types de tests non fonctionnels. Beaucoup d’entre eux se rattachent aux grandes catégories des tests de performances et des test de sécurité.
Tests de performances
L’objectif des tests de performances est d’améliorer la rapidité, la scalabilité et la stabilité d’une application. Les tests de rapidité déterminent la rapidité avec laquelle une application répond. Les tests de scalabilité déterminent la charge utilisateur maximale qu’une application peut gérer. Les tests de stabilité déterminent si l’application reste stable sous différentes charges. Deux types courants de tests de performances sont les tests de charge et les tests de contrainte.
Test de charge
Les tests de charge déterminent les performances d’une application sous des charges réalistes. Par exemple, les tests de charge peuvent déterminer le niveau de performances d’une application à la limite supérieure de son contrat SLA. Essentiellement, les tests de charge déterminent les comportements de l’application quand plusieurs utilisateurs en ont besoin en même temps.
Les utilisateurs ne sont pas nécessairement des personnes. Par exemple, un test de charge pour un logiciel d’impression peut envoyer de grandes quantités de données à l’application. Un test de charge pour un serveur de messagerie peut simuler des milliers d’utilisateurs simultanés.
Les tests de charge sont aussi un bon moyen de découvrir des problèmes qui surviennent seulement quand l’application fonctionne à ses limites. C’est le moment où des problèmes comme un dépassement de mémoire tampon et des fuites de mémoire peuvent se révéler.
Dans ce module, vous utiliserez Apache JMeter pour effectuer des tests de charge. Vous utiliserez un ensemble d’utilisateurs simulés qui accèdent simultanément au site web.
Tests de contrainte
Les tests de contrainte déterminent la stabilité et la robustesse d’une application sous des charges lourdes. Les charges vont au-delà de ce qui est spécifié pour l’application. Les tests de contrainte déterminent si l’application va planter sous ces charges. Si l’application échoue, le test de contrainte vérifie qu’elle échoue avec un arrêt correct. Un échec avec arrêt correct peut par exemple consister à émettre un message d’erreur avec des informations appropriées.
Les scénarios dans lesquels les applications doivent fonctionner sous des charges anormalement lourdes sont courants. Par exemple, si votre vidéo devient virale, vous voulez savoir dans quelle mesure les serveurs peuvent gérer la charge supplémentaire. Un autre scénario classique est un trafic élevé sur les sites web d’e-commerce pendant les périodes de vacances.
Tests de sécurité
Les tests de sécurité garantissent que les applications sont exemptes de vulnérabilités, de menaces et de risques. Des tests de sécurité complets détectent toutes les failles et les faiblesses possibles du système, susceptibles de provoquer une violation des informations ou une perte de revenus.
Il existe de nombreux types de tests de sécurité. Les tests d’intrusion et les tests de conformité sont deux d’entre eux.
Test d’intrusion
Les tests d’intrusion sont un type de tests de sécurité qui testent les aspects non sécurisés de l’application. En particulier, ils testent les vulnérabilités qu’un attaquant pourrait exploiter. Les tests d’intrusion impliquent généralement une cyberattaque simulée et autorisée.
Test de conformité
Les tests de conformité déterminent si une application est conforme à un ensemble d’exigences, internes ou externes à l’entreprise. Par exemple, aux États-Unis, les organisations du secteur de la santé doivent en général se conformer à la loi HIPAA (Health Insurance Portability and Accountability Act) de 1996, qui spécifie des règles de confidentialité et de sécurité des données pour la protection des informations médicales.
Une organisation peut également avoir ses propres exigences en matière de sécurité. Les logiciels doivent être testés pour vérifier qu’ils respectent ces exigences. Par exemple, sur les systèmes Linux, le masque d’utilisateur par défaut doit être 027 ou plus restrictif. Un test de sécurité doit prouver que cette exigence est respectée.
Le plan
Dans le reste de ce module, vous configurerez votre environnement Azure DevOps, découvrirez la planification des tests de charge à l’aide d’Apache JMeter et exécuterez des tests de charge dans Azure Pipelines.