Les tests de vérification de build (BVT) en bref
Avant de répondre à cette question, je tiens à préciser que j’ai utilisé le mot « surcharge » et non « performance ». En effet, la dégradation des performances n’est que l’un des résultats potentiels d’un bon test de surcharge de CI, les erreurs étant l’autre résultat. Donc, avant de parler de ce qui en fait un bon test, parlons de ce qui ne l’est pas.
Un test comme celui que vous utiliseriez dans le cadre d’un test de charge régulier avant la sortie d’une version n’est pas un bon test pour plusieurs raisons. Ces tests se déroulent normalement pendant un certain temps, jusqu’à une heure ou plus, avec des temps de montée, de maintien et de descente. Nous avons besoin de quelque chose qui ressemble davantage au POST (power on self-test) que subit votre ordinateur portable lorsque vous l’allumez pour la première fois – faire le plus de choses possibles en un minimum de temps, en s’assurant qu’il n’y a pas d’erreurs flagrantes ou de problèmes de dégradation des performances avant de promouvoir le build (ou de lancer Windows sur votre ordinateur portable dans le cas du test POST).
La méthodologie « Engine on Blocks »
La méthodologie que j’utilise s’appelle « Engines on Blocks » (moteurs sur blocs) car elle est calquée sur les harnais de test dans lesquels les moteurs automobiles sont installés et testés avant d’être mis dans une voiture à l’usine. Le test n’est pas long, mais il fait tourner le moteur à 80 ou 90 tours pendant quelques minutes pour voir s’il s’essouffle et meurt. Même si seulement 1 ou 2 % d’entre eux tombent en panne à ce stade, le coût de leur découverte et de leur réparation est beaucoup, beaucoup moins élevé que celui d’une découverte ultérieure. Il en va de même pour votre application, d’où la nécessité d’un test de vérification de build (BVT).
Une chose qui n’est pas nécessaire est le temps de réflexion – qu’y a-t-il à réfléchir de toute façon ? Nous n’essayons pas de modéliser le comportement de l’utilisateur, nous essayons d’exécuter une surcharge de 3 à 5 minutes en utilisant le nombre minimum de threads nécessaires pour faire monter le CPU à 80, tout comme le moteur de la voiture. Et nous devrions tester un chemin à travers la fonctionnalité de base de l’application, et non pas simplement se connecter, parcourir les menus et se déconnecter (bien que même cela soit mieux que rien).
Votre test de vérification de CI ou de build représente la vitesse de votre transaction commerciale principale, où les millisecondes comptent. Comme ce test est exécuté de nombreuses fois, il devient facile de repérer les tendances historiques et de savoir exactement quand la dégradation des performances commence à se produire, afin de pouvoir la corriger avant qu’elle ne s’accentue.
De nombreux défis à relever
L’exécution de tests de charge dans le cadre du pipeline de test CI est un défi pour un certain nombre de raisons. Ils ne se contentent pas de réussir ou d’échouer comme le font les tests fonctionnels, et comme chaque application est différente, il existe différents critères pour déterminer ce qui doit provoquer un échec. Toutes les exigences habituelles d’un test de charge, y compris les données de test et les utilisateurs de test, s’appliquent toujours, y compris l’état de la base de données elle-même, avant et après le test. Il est toujours bon d’effacer les transactions ajoutées pour ne pas laisser de traces derrière soi.
Quelqu’un parmi nos lecteurs a-t-il essayé cette méthode dans son entreprise ? Si oui, souhaitez-vous partager votre expérience avec nous ?
