Exécution de tests non fonctionnels en mode de test continu – Partie 2

Avant d’aller plus loin, comprenons ce qu’est le test continu.

Qu’est-ce que le test continu

Au cours des dernières années, la majorité des projets logiciels ont utilisé la livraison continue, une approche d’ingénierie logicielle dans laquelle les équipes produisent des logiciels en cycles courts, garantissant que les logiciels peuvent être publiés de manière fiable à tout moment.

Apparemment, pour garantir une qualité et une fiabilité élevées, ces projets déploient des tests continus, qui impliquent l’exécution de nombreux types de tests différents (automatisés et manuels) tout au long du processus de livraison du logiciel pour valider et améliorer à plusieurs reprises la qualité du logiciel en cours de construction.

Le quadrant ci-dessous montre les différents types de tests et l’approche (manuelle, automatisation des tests) pour les exécuter :

Source : https://continuousdelivery.com/foundations/test-automation/

Pour les besoins de ce blog, nous limiterons notre discussion aux tests non fonctionnels.

Comme nous pouvons le voir dans le quadrant ci-dessus, l’approche recommandée pour les tests d’acceptation fonctionnelle consiste à les automatiser entièrement et la plupart des projets l’ont fait avec succès. Cependant, les tests non fonctionnels tels que la sécurité et les performances sont toujours considérés comme exécutés après le “gel du code” et ne sont pas exécutés en mode de test continu.

Étant donné que l’objectif derrière la création de logiciels en mode de livraison continue est de garder le code prêt pour le déploiement en production à tout moment, les tests non fonctionnels doivent être traités de la même manière que les tests fonctionnels et ils doivent être « inclus tôt et testés souvent » pour s’assurer que le le code déployé révèle non seulement des problèmes fonctionnels, mais également des problèmes de performances, de sécurité et d’autres problèmes non fonctionnels.

Comment configurer les tests non fonctionnels en mode de test continu

Les deux principales catégories de tests non fonctionnels sont les tests de performance (y compris la charge, le stress, etc.) et les tests de sécurité. Il en existe d’autres, tels que les tests d’utilisabilité, qui sont également considérés comme non fonctionnels, mais nous limitons notre attention aux deux premiers.

L’un des principaux défis de la conception de tests non fonctionnels est généralement que les exigences pour les aspects non fonctionnels du logiciel ne sont pas aussi simples par rapport au comportement fonctionnel du logiciel. Ceci, combiné à d’autres facteurs tels que le temps et le budget, empêche l’exécution de tests non fonctionnels en mode de test continu.

Cependant, avec l’approche de livraison continue, les exigences sont principalement énoncées dans un format omniprésent utilisant le développement piloté par le comportement (BDD) et d’autres pratiques similaires où les exigences fonctionnelles et non fonctionnelles sont spécifiées dans les fichiers de fonctionnalités à l’aide d’un type de langage appelé Gherkin, qui est autant que en le disant dans un anglais simple. Par exemple, regardez cette exigence de test de sécurité de https://devops.com en utilisant BDD :

Voici un autre exemple d’exigence de test de performances utilisant le format Gherkin :

Étant donné qu’il y a 100 000 utilisateurs enregistrés sur le système

Lorsque je crée un nouveau compte

Ensuite, je devrais être redirigé vers mon tableau de bord dans les 5 millisecondes

Voici quelques exemples d’exigences non fonctionnelles qui peuvent être identifiées tôt et incorporées dans le pipeline de livraison continue, automatisées et exécutées en tant que tests continus. Cependant, toutes les exigences ne sont pas aussi simples que nous le voyons ici et nous mettent au défi de les exécuter en tant que tests continus. De quel genre de défis s’agit-il?

(À suivre …)

Read more

Running Non-Functional Tests in Continuous Testing Mode – Part 3

Exécution de tests non fonctionnels en mode de test continu

Messages similaires

Une approche simple pour gérer les échecs de l’automatisation des tests