Concept: Test structurel
La clé des tests structurels est que tous les résultats décisionnels doivent se faire de manière indépendante pendant le test et que le nombre de tests requis pour un module logiciel soit égal à la complexité cyclomatique de ce module.
Relations
Eléments connexes
Description principale

Le concept de test structurel est utilisé dans deux contextes principaux. Bien que de nature différente, on peut affirmer que le concept ou l'idée de base derrière le test structurel est le même dans les deux cas.

Test structurel d'éléments internes de code

L'ancienne référence au terme "test structurel" et probablement l'utilisation la plus courante se rapporte au test de la structure interne du code source du logiciel. Cette forme de test structurel est le plus souvent menée en tant que test "statique" par opposition à un test "dynamique", en ce sens que le logiciel lui-même n'est pas exécuté pour réaliser le test. Les outils de diagnostic analysent le code source, à la recherche d'erreurs structurelles et de points faibles, fournissant généralement une liste pour permettre de prendre les mesures correctives qui en découlent. Ce type de test et d'évaluation est mené à bien par les développeurs plutôt que par les testeurs système.

Test structurel de sites Web

Les applications basées sur le Web (celles employant la technologie des applications Internet) sont de plus en plus répandues. Ce mouvement a été encouragé par le fait que cette méthode de développement et de déploiement logiciel offre aux organisations la capacité de tirer parti de plusieurs avantages métier, à savoir :

  • Large public de clients, prospects et partenaires commerciaux sans envoyer de logiciels ni de documents. N'importe qui possédant un navigateur et un accès au réseau (Internet ou Intranet) peut cliquer sur l'URL pour exécuter immédiatement l'application.
  • Contrôle et maintenance centralisés. Le modèle client léger/serveur lourd des applications basées sur le Web place les composants et la logique de l'application sur le serveur Web, ce qui centralise et simplifie le contrôle et la maintenance. Cela permet également aux développeurs de distribuer le logiciel automatiquement. Une fois l'application sur le serveur, elle est immédiatement disponible pour tous les utilisateurs.

Bien que cela présente des avantages pour ceux qui utilisent cette technologie, les applications basées sur le Web exigent davantage de tests. Le test de ces applications basées sur le Web, tout comme celui des autres applications (client/serveur, traditionnelles, etc.), exige des tests abordant les caractéristiques fonctionnelles et de performance des applications. En outre, les applications basées sur le Web présentent le besoin supplémentaire suivant : les tests doivent se concentrer sur la structure de l'application, s'assurant qu'elle est bien formée et que tous les liens sont valides.

Les applications basées sur le Web sont généralement construites à l'aide d'une série de documents (documents texte HTML et graphiques GIF/JPEG) reliés par de nombreux liens statiques et quelques liens actifs ou commandés par un programme. Ces applications peuvent aussi comprendre un "contenu actif", comme des formulaires, des scripts Java, du contenu restitué par des plug-ins ou des applications Java. Ce contenu actif est souvent utilisé en tant que sortie uniquement, par exemple pour une présentation audio ou vidéo. Toutefois, il peut également servir comme une aide à la navigation, pour aider l'utilisateur à se déplacer dans l'application (site Web). La forme libre des applications basées sur le Web (à travers leurs liens) est une force, mais elle présente également des faiblesses car leur intégrité structurelle est vulnérable.

Les tests structurels sont implémentés et exécutés pour vérifier que tous les liens (statiques ou actifs) sont correctement établis. Ces tests comprennent :

  • Vérification que le bon contenu (texte, graphiques, etc.) de chaque lien s'affiche. Différents types de liens sont utilisés pour référencer le contenu cible dans les applications basées sur le Web, comme les signets, les hyperliens vers un autre contenu cible (sur le même site Web ou un autre), ou les zones sensibles. Chaque lien doit être vérifié pour s'assurer que le bon contenu cible est présenté à l'utilisateur.
  • Vérification de l'absence de liens rompus. Les liens rompus sont les liens dont le contenu cible est introuvable. Les liens peuvent être rompus pour de nombreuses raisons, comme le déplacement, la suppression ou le renommage des fichiers du contenu cible. Les liens peuvent également être rompus à cause d'une syntaxe erronée, par exemple des barres obliques, des deux-points ou des lettres manquantes.
  • Vérification de l'absence de contenu orphelin. On entend par 'contenu orphelin' des fichiers pour lesquels il n'y a pas de lien "entrant" sur le site Web actuel, c'est-à-dire qu'il n'y a aucun moyen d'accéder au contenu ou de l'afficher. La recherche du contenu orphelin doit être effectuée soigneusement afin d'en déterminer la cause :
    • A-t-il été oublié parce qu'il n'est plus nécessaire ?
    • A-t-il été oublié à cause d'un lien rompu ?
    • Ou son accès s'effectue-t-il par un lien externe au site Web actuel ?

Une fois cela déterminé, les mesures appropriées doivent être prises, c'est-à-dire respectivement la suppression du fichier de contenu, la réparation du lien rompu, ou l'omission du contenu orphelin.