Qu'est-ce que le test de thread dans les tests de logiciels ?

Qu’est-ce que le test de thread ?

Test de thread Il s'agit d'un type de test logiciel qui vérifie les fonctionnalités clés d'une tâche spécifique, appelée thread. Il est généralement effectué au début du développement. test d'intégration phase. Les tests basés sur les threads constituent l'une des stratégies incrémentales adoptées lors des tests d'intégration système. C'est pourquoi un test basé sur les threads est plus justement décrit comme une test d'interaction des threads.

Ici, un thread n'est pas seulement un thread du système d'exploitation. génie logiciel En termes de termes, un fil de discussion représente une transaction commerciale complète, par exemple « un client passe une commande ». tracLe test de thread vérifie si ce chemin unique se comporte toujours correctement une fois les modules connectés.

Le schéma ci-dessous montre comment les différents éléments sont intégrés et mis en œuvre en tant que sous-système avant l'assemblage du système complet.

Types de tests de fils

Les tests basés sur les threads sont classés en deux catégories, et cette distinction détermine à la fois les données de test et les défauts que vous êtes susceptible de trouver.

• Test monothread : Un test monothread n'exécute qu'une seule transaction applicative à la fois. Une seule requête est traitée, ce qui garantit un comportement prévisible et facilite la création et la répétition du test.
• Tests multithread : Un test multithread implique plusieurs transactions actives simultanément. Des threads distincts sont préparés pour un même service afin d'observer la réactivité et la gestion de l'état partagé sous une charge simultanée.

Une transaction qui réussit sans problème lors d'un test monothread peut tout de même échouer lors d'une exécution multithread, car la seconde exécution ajoute une contention pour les mêmes enregistrements, connexions et mémoire.

Comment faire des tests de thread

Le processus par fil de discussion se concentre sur les activités d'intégration plutôt que sur l'ensemble du cycle de développement. En pratique, l'approche fonctionne comme suit.

• Les tests basés sur les threads sont une forme généralisée de tests basés sur les sessions, dans le sens où les sessions sont une forme de thread, mais un thread n'est pas nécessairement une session.
• Le thread ou programme (petite fonctionnalité) est intégré et testé de manière incrémentale en tant que sous-système, puis exécuté pour l'ensemble du système.
• Au niveau le plus bas, il permet aux intégrateurs de mieux comprendre l'étendue des tests à effectuer.
• Au lieu de tester directement les composants logiciels, cela exige des intégrateurs qu'ils se concentrent sur le test des chemins d'exécution logiques dans le contexte de l'ensemble du système.

Étant donné que l'unité de travail est un chemin métier plutôt qu'un composant, les tests de threads se situent naturellement entre les deux. test de module et plein test du système.

Conseils pour les tests multithread

Les défauts multithreadés étant liés au timing, un seul test réussi ne suffit pas à les détecter. Les conseils ci-dessous augmentent les chances de les déceler.

• Testez votre programme multithread en l'exécutant de manière répétée avec différentes combinaisons d'applications en cours d'exécution.
• Testez votre programme multithread en exécutant plusieurs instances du programme simultanément.
• Exécutez votre programme multithread sur différents modèles de matériel avec des niveaux de stress et des charges de travail variables.
• Utilisez l'inspection du code, car certaines erreurs de synchronisation sont plus faciles à lire qu'à reproduire.
• Ne collecter que les erreurs et les échecs survenus dans des threads autres que le thread principal.

Défauts courants constatés lors des tests de filetage

Les erreurs de concurrence se manifestent rarement par une pile propre. trace. Les catégories ci-dessous représentent la plupart des éléments exposés par une exécution multithread, et chacune présente un symptôme distinct qu'il convient de reconnaître.

• Conditions de course : Deux threads lisent et écrivent la même valeur sans ordre particulier ; le résultat final dépend donc du thread qui a terminé en premier. Symptôme : les totaux sont corrects dans certains cas et incorrects dans d’autres.
• Impasse: Deux threads détiennent chacun un verrou dont l'autre a besoin, et aucun ne progresse. Symptôme : la transaction reste bloquée indéfiniment au lieu de générer une erreur.
• Conflit de ressources : Les threads s'accumulent dans la file d'attente pour une même connexion, un même descripteur de fichier ou un même enregistrement, et le débit s'effondre bien avant que la limite matérielle ne soit atteinte.
• Corruption de données: Les structures partagées partiellement écrites laissent des enregistrements dans un état qu'aucune transaction valide ne pourrait produire.
• Famine: Un thread de faible priorité n'obtient jamais la ressource dont il a besoin, ce qui provoque l'expiration d'un chemin utilisateur alors que le reste du système semble fonctionner correctement.

Chacune de ces opérations nécessite que l'exécution défaillante soit consignée dans les journaux, car un défaut qui se reproduit une fois sur cinquante est autrement impossible à signaler. processus de gestion des défauts.

Tests de threads vs tests de concurrence vs tests d'intégration

Ces trois termes se recoupent et sont souvent confondus dans les plans de test. Le tableau les distingue selon leur finalité.

En bref, tests de concurrence Le test de thread vérifie l'impact des accès simultanés sur le système, tandis que le test de thread vérifie si un chemin d'accès important survit à l'intégration. Les équipes qui effectuent les deux tests planifient généralement le test de thread en premier.

Avantages du test de filetage

Cette technique trouve sa place dans un plan d'intégration pour plusieurs raisons pratiques.

• Les principaux processus métier sont validés en amont, ce qui permet de détecter une rupture de transmission avant l'assemblage complet du système.
• Les intégrateurs obtiennent une vision claire du périmètre, car l'unité de test est une transaction identifiable plutôt qu'une valeur absolue.tracLimite du composant t.
• Tester les chemins d'exécution logiques dans le contexte du système permet de déceler des défauts isolés. test de composants Je ne peux pas voir.
• L'exécution multithread met en évidence les défauts de concurrence — blocages, conditions de concurrence et conflits de ressources — qui autrement atteindraient la production.
• L'intégration incrémentale permet de limiter la surface de débogage, puisqu'un seul thread est ajouté à la fois.
• Les résultats alimentent directement les tests de régression, car un thread réussi constitue un candidat évident pour la suite de tests de régression.

Inconvénients des tests de thread

• Pour les tests multithread, le plus grand défi consiste à pouvoir programmer un test reproductible pour un test unitaire.
• Écrire des tests unitaires pour du code multithreadé est une tâche complexe.
• Les critères de test multithread diffèrent de ceux des tests monothread. En multithreading, des facteurs tels que la taille de la mémoire, la capacité de stockage et les problèmes de synchronisation varient selon le matériel exécuté.
• Les threads ne peuvent pas être testés avant que les modules qu'ils traversent ne soient disponibles ; la planification dépend donc de l'ordre d'intégration.
• Les pannes intermittentes sont faciles à attribuer à des bruits environnementaux, ce qui rend l'enregistrement rigoureux des données essentiel.

FAQ