Les tests non fonctionnels et les tests de performance ne pouvaient plus être décalés vers la gauche
Par Jason English
28 mai 2020
4 min lire
Dans les tests de logiciels, les problèmes non fonctionnels sont parmi les plus difficiles à détecter. Voici un article qui explique les tests non fonctionnels et de performance et les meilleures approches que vous pouvez adopter pour les mettre en œuvre.
Aller à la section
Un BrainBlog Intellyx pour Parasoft par Jason English
Avez-vous déjà eu un ami qui était TOC à cause de la blancheur de ses dents ? Ils vont chez un dentiste cosmétique pour un blanchiment au laser, puis se plaignent que ce n'est pas assez blanc ? Finalement, ils atteignent un point asymptotique où la surface de la dent ne peut pas refléter 99.9 % de la lumière, donc obtenir un traitement qui offre des dents blanches à 99.999 % serait trop coûteux — et impossible.
Les ingénieurs de test, les testeurs de performances et les SRE sont obsédés par l'atteinte d'un niveau de fiabilité de cinq neuf (ou parfois même plus) au dernier kilomètre de la livraison de logiciels, là où cela a le plus d'impact sur les clients.
Si vous avez également un TOC concernant la fiabilité des applications, vous avez déjà fait le calcul et réalisé que 5 9 équivaut à environ 5.26 minutes de temps d'arrêt par an, au total. Et vous réalisez également que le coût d'ingénierie des tests et l'effort de dépasser 99.9% pour garantir une disponibilité de 99.999% sont monumentaux.
Faire passer la production de 3 9 à 5 9 consommera bien plus de budget informatique que d'arriver à 3 9 dans la plupart des cas!
Il semble que tous les tests de performances de pré-production dans le monde ne permettront jamais d'éliminer toutes les conditions inconnues qui pourraient causer les 0.001% de temps d'arrêt. Peu importe combien nous dépensons. Out, maudit endroit!
Ah… mais ne nous inquiétons pas de cette seule chose que vous ne pouvez pas améliorer, du bon côté de la livraison de logiciels. Non, non, non… Les problèmes coûtent beaucoup plus cher à résoudre ici, de toute façon, lorsque l'application est complètement cuite. Je ne peux pas être obsédé par ça.
Juste une petite flambée. Personne n'est parfait. Relaxer.
Obtenez une nouvelle perspective avec les premières équipes DevTest
Pourquoi ne pas laisser la production tranquille pendant un moment et passer du temps avec les équipes DevTest au début du cycle de vie du logiciel?
Ici, sur le côté gauche de la livraison logicielle, ils dessinent des cartes, écrivent du code et sélectionnent des composants. Pas un souci au monde. Aucune peur de quoi inconnues inconnues peut se produire lors du déploiement.
Ils exécutent un développement agile axé sur les tests et exécutent de nombreuses vérifications de code structurel avec chaque build, exécutant des suites de tests unitaires et de régression automatisés. Ils se sont tournés vers la gauche pour ce genre de tests.
Ils ne sont pas non plus très inquiets de l'impact des décisions qu'ils prennent. Lorsque divers services, logiciels et composants d'infrastructure sont intégrés derrière une application fonctionnelle, ils peuvent générer une variété infinie de problèmes non fonctionnels lorsqu'ils interagissent sous charge.
Les premières sélections de conception et de développement peuvent apporter de mauvaises nouvelles plus tard, mais les tests non fonctionnels (NFT) et les tests de performances se déroulent généralement plus près de la production.
Attendez, et si vous pouviez amener NFT à la conception et au développement? Cela pourrait-il fournir une alerte précoce suffisante pour éviter les erreurs les plus coûteuses?
Déplacement de NFT et PerfTest vers la gauche
Les problèmes non fonctionnels sont difficiles à détecter tôt dans le logiciel car les conditions du monde réel sont par nature difficiles à reproduire en laboratoire.
Vous pouvez exécuter des suites de tests fonctionnels Selenium sur une interface d'application ou un processus d'autorisation utilisateur, ou exécuter un ensemble d'appels de test de service API et d'ensembles de données pour vérifier les réponses, ou exécuter un ensemble de tests JUnit ou NUnit sur le code. Mais toutes ces méthodes ne peuvent tester que les problèmes que vous vous attendez à trouver à ce stade précoce.
Pour se rapprocher des conditions du monde réel, trois options s'offrent à l'équipe.
1. Insérez des tests fonctionnels pour l'analyse comparative. Si vous insérez des tests fonctionnels Selenium dans le pipeline logiciel CI / CD et que vous les automatisez avec un outil compagnon tel que Parasoft Sélénic pour surveiller les temps d'exécution avec chaque build, vous pouvez capturer un assez bon benchmark pour n'importe quelle application, composant ou service.
S'il y a un écart dans le temps de réponse, pour quelque raison que ce soit, la construction peut informer la plate-forme de construction ou le développeur qu'une exception (probablement non fonctionnelle) a ralenti un composant particulier.
2. Réutilisez les tests et répétez sous charge. Pourquoi attendre la fin et utiliser des outils tels que LoadRunner qui nécessitent des interfaces utilisateur presque terminées, des compétences de test spécialisées et des coûts par poste élevés?
Au lieu de cela, que se passe-t-il si vous avez passé les tests Selenium, ainsi que des contrôles de sécurité et des tests de service et d'intégration à partir d'un outil comme Parasoft SOAtest, puis a commencé à faire des cycles et à les réexécuter, peut-être avec une certaine variabilité des données ou du calendrier, à des fréquences plus élevées? Vous obtiendrez un test de performance à un stade précoce de test de décalage gauche.
À partir de là, vous pouvez combiner différentes combinaisons d'appels de style Web, d'appels d'interface utilisateur, d'appels non d'interface utilisateur vers des API ou de files d'attente d'événements pour un test de performances hybride qui peut exercer plusieurs couches de l'écosystème cible de l'application, sans attendre une application terminée.
3. Isolez-vous des dépendances environnementales. Le dernier obstacle au déplacement de NFT vers la gauche est l'environnement dans lequel les applications vivent réellement. Une application moderne fonctionne dans un monde plein de dépendances de données et de services.
Voici où tests basés sur l'environnement avec une solution de virtualisation de services, il est logique d'instrumenter toutes les dépendances en amont et en aval autour de l'application en direct. Cela vous permet de simuler des éléments tels que le système d'un partenaire bancaire, ou un système national de météo ou de trafic aérien qui ne serait jamais sous votre contrôle ou disponible pour l'importation dans votre propre laboratoire DevTest.
Les dépendances peuvent être écoutées et capturées comme des services virtuels - des composants qui peuvent répondre «mieux que la réalité» en ce qui concerne les tests logiciels.
Une banque canadienne a utilisé une combinaison des trois techniques. Ils ont automatisé des tests fonctionnels pour capturer une référence pour un composant de demande de prêt, puis ont réexécuté les tests avec d'autres tests pour les requêtes de données et les appels d'API à un service de virtualisation "simulé" d'un service de crédit tiers.
Ils étaient inquiets. Si le service d'API virtuelle a répondu trop lentement, qu'arriverait-il au composant testé? Il a répondu comme prévu, mais l'équipe de test a ensuite accéléré le service virtuel de cette réponse tierce dans les plus brefs délais. Une «condition de concurrence» est apparue qui a provoqué l'échec de la transaction du composant lors de l'obtention d'une réponse trop rapide!
La prise d'Intellyx
Dans le logiciel, il n'y a qu'une seule définition de la perfection, mais l'échec est infini.
Peu importe combien nous nous brossons, nous n'aurons jamais de dents 100% blanches. Peu importe combien nous testons, nous ne serons jamais à 100% exempts de défauts en production, où les erreurs sont difficiles à isoler et coûteuses à corriger.
Mais avec une bonne hygiène de test gauche qui comprend des tests non fonctionnels et de performance, nous pouvons obtenir un système d'alerte précoce qui résoudra bon nombre de ces problèmes naissants avant qu'ils n'aient une chance d'émerger dans le laboratoire de performance ou d'échouer devant les clients.
© 2020 Intellyx, LLC. Intellyx conserve le contrôle éditorial sur le contenu de ce document. Au moment de la rédaction de cet article, Parasoft est un client Intellyx. Aucun des autres fournisseurs mentionnés ici n'est un client Intellyx. Sources d'images: Steve Snodgrass, Kristopher Volkman, Jean Reine, Gauthier DELECROIX - 郭 天, flickr open source.