Test de la boîte blanche Java

Résumé: Les tests en boîte blanche modernes utilisent des outils automatisés sophistiqués pour aider les développeurs à concevoir de bons tests et à mesurer la couverture du code de manière significative. Des exemples largement utilisés (si rudimentaires) incluent Cobertura, EMMA, EclEmma et JaCoCo .

Comment les tests de boîte blanche sont-ils effectués sur les applications java?

Traditionnellement, les tests de boîte noire signifiaient qu'une autre équipe (pas le développeur) était responsable des tests logiciel, et ils n'ont pas regardé le code source tout en le faisant.

Même avec le passage aux tests unitaires, une approche courante pour concevoir des tests consiste à utiliser une caractérisation de domaine d'entrée plus ou moins boîte noire , c'est-à-dire simplement tester les conditions aux limites et quelques valeurs d'entrée "normales" arbitraires.

Il est clair cependant que cette approche peut ne pas exercer certaines branches de la fonction. Un bon développeur va ouvrir le code{[2] } et dire " hé, j'ai besoin d'ajouter une entrée pour l'exercice de cette branche."

Les tests en boîte blanche modernes poussent cette idée un peu plus loin en automatisant le processus, en produisant une sortie comme celle-ci pour montrer quelles parties d'une méthode n'ont pas encore été exercées par, disons, JUnit (à partir du plugin NetBeans TikiOne):

À quoi devrait ressembler le test de la boîte blanche?

Les outils de couverture de code mentionnés dans le résumé tentent d'automatiser le processus de s'assurer que vous exercez chaque ligne ou branche de code. Lorsqu'il est intégré dans un environnement d'intégration continue comme Jenkins , il permet à votre équipe de garder un œil constant sur non seulement si vos tests sont réussis, mais si vous atteignez vos objectifs de couverture (à partir du plugin NetBeans TikiOne):

Dans la recherche en génie logiciel, les tests en boîte blanche peuvent devenir beaucoup plus sophistiqués que le comptage des lignes. Une grande variété d'outils et de techniques mathématiques ont été développé pour vous aider à vous assurer que les entrées que vous donnez à vos tests couvrent correctement tous les comportements possibles de votre code.

Par exemple, les systèmes d'avertissement pour un système de pilote automatique d'avion qui utilise des prédicats booléens complexes peuvent utiliser des critères de test en boîte blanche enracinés dans la logique formelle pour s'assurer que nous couvrons tous les chemins logiquement possibles à travers le contrôleur.

L'analyse de la couverture des lignes et des branches, les critères les plus courants, est un cas particulier d'utilisation de graph les représentations de logiciels, comme graphe de flot de contrôle ou diagramme de flux de données. Un bon outil lira votre code pour générer le graphique, puis vous pourrez choisir parmi différents critères de couverture de graphique pour recommander automatiquement un ensemble de chemins à travers la logique de contrôle de la méthode (branches) que vous devez exercer afin d'atteindre vos objectifs de test.

Les lignes et les branches sont les critères de couverture de graphe (contrôle) les plus simples et les plus utilisés (correspondant à couvrir les nœuds et les arêtes)-des métriques plus complètes (et difficiles à satisfaire) telles que les paires d'arêtes et les chemins principaux sont disponibles dans certains outils. Ceux-ci demandent non seulement "ai-je descendu tous les choix à chaque branche au moins une fois", mais "est-ce que je suis passé par chaque branche par tous les moyens que j'ai pu y arriver."

C'est toujours au programmeur de trouver un ensemble d'entrées pour exercer ces chemins, et de concevoir un code assez petit et assez simple pour que le nombre de tests requis pour obtenir une bonne couverture avec les critères plus approfondis n'explose pas de manière exponentielle. Mais maintenant, vous avez des moyens formels et quantitatifs pour A) vous dire quels besoins ont été testés, et B) vous dire à quel point vous avez testé votre projet.

Cela signifie - t-il que je dois tester classe par classe?

White-box testing est une méthode pourconcevoir des tests . Il peut s'appliquer à tous les niveaux de test, y compris les tests unitaires, les tests d'intégration et les tests système.

Pour plus d'informations sur les critères de couverture des tests, voir

• Beizer, Boris. Techniques de test de logiciels.Il s'agit de la première édition de Dreamtech.

Ou voir le plus à jour

Il est le fils de Paul et Jeff Offutt. Introduction aux tests de logiciels.[10]} Cambridge University Press, 2008.